Seth Ladd's Blog

The Semantic Web in Action , originally published in the December 2007 issue of Scientific American , is now online and free. The original article published in the May 2001 issue of Scientific American was certainly due for an update. The original article made a lot of grand promises, while the December 2007 article details current efforts at applying semantic web technologies to real life problems. Check it out if you're interested in how companies are building the semantic web today .

I've been a fan of Iron Chef America for a while. Fast paced and some very interesting dishes, it's entertaining and even a bit educational (for the epicurean viewer). Being a geek at heart, it leaves me wondering what it would take to create an Iron Coder competition. With the right "ingredients" it just might work. First, we'd need a play-by-play announcer and a color commentator . On Iron Chef America, this single role is played by Alton Brown . We might be able to get away with a single person, but I often like the banter of two announcers. It is, of course, their job to explain what is going on and provide insight and entertainment during the battle. There is, of course, the Secret Requirement. This brings us to the question of what type of code are the two Iron Coders creating? I come from a web application background, so this is my first assumption. You can't pit an X-Box programmer against a Perl script kiddie. For now, let's stick with b...

Enjoying Sam Ruby 's latest post titled Connecting , I was reminded that designing a RESTful system means much more than just adhering to a uniform interface (often the first attribute of a ROA that is promoted). When designing a Resource Oriented Architecture, you mustn't forget about hypermedia and how your resources link to one another, and how those links are expressed through your representations. Which brings me to JSON . A nifty little format, indeed. And one that, if you are building a modern web service, you should be investigating and implementing. However , if you are indeed building a hypermedia system with JSON, how do you express your links? I know how to do this in XHTML and RDF, but not sure how to express or render a URI and have it mean "link". I've love to be able to do something like this: { "name": "Cool Beans", "account": "http://example.org/accounts/23242342" } However, any JSON client will hav...

Tim Berners-Lee asks "So do you think Flickr could be persuaded to source FOAF ?" Given what I've heard from Stewart Butterfield (co-founder of Flickr), the answer is a No. Back in 2004 (Mon, Nov 29, 2004 at 8:41 PM to be exact), I wrote Flickr asking if they could add sha1 hashes of user emails (in an obvious attempt to be able to convert the data into FOAF). Here's the original request email: Hello, Would it be possible to add a sha1 hash of a person's email address to the response of flickr.people.getInfo ? I understand that we don't want to give out email addresses, and it's nice that the API doesn't expose them. But to help in uniquely identifying users across systems, a good identifier is often their email address. To safe guard against spam, creating a SHA1 hash is a good way to hide the email, yet still provide a unique identifier for the user. This sha1'ed email address becomes a candidate key to the user, so to speak. Thoughts? Th...

Thinking about REST or need to address some lingering concerns about adopting REST? I found the article Addressing Doubts about REST full of pragmatic, down to earth answers and advice for comparing REST and WS-* (or, RPC). Nothing new, but a solid collection of answers to how you should think about REST and how you should apply it to your system. I especially appreciated how the author points out that if you are worried about transactions across your systems, that's probably a design smell and you want to re-think your approach. Never expect that transactions will work reliably across many systems. Instead, build in logic to recover from error states. This is not a REST issue, but instead a large system design issue. REST simply makes it easy to pass the state of your resources between systems.

I've been using RSpec with my latest project, and it's a welcome change from the traditional Test::Unit for Ruby . RSpec is a more natural way to write tests for your software. It seems to be much easier to compose tests, and anything that makes testing easier is OK in my book. A specific example of why I'm falling for RSpec: You can easily group common tests together, and include this grouping in your main tests. Of course you can do this in any number of ways with Test::Unit, but RSpec makes it so clean and obvious. Here's an example of a very common set of tests that I need to run again all my controllers: describe "Requires Authorization", :shared => true do describe "when not logged in" do describe "when accessing index page" do it "should redirect to login page" do get 'index' response.should redirect_to(new_session_path) end end describe "when accessing new datab...

I've been reading through Advanced Rails Recipes , and so far I like the book. It has a nice collection of tips and tricks for the experienced Rails developer. This is the kind of book that you have to quickly scan through when you get it, so you know what tips are available. Remembering that the book has the solution for your problem at hand is the tough part. One common requirement for web frameworks is being able to handle nested forms on submit. It's too common to present to the user a complex form, representing many different, usually nested, objects. The difficulty isn't really in displaying or formatting the nested HTML form itself, but in handling the submit. How do you save or update all of the objects easily and efficiently? What if there's an error? The excellent and always useful RailsCasts had a series of episodes that handle the nested form issue ( Complex Forms 1 , Complex Forms 2 , and Complex Forms 3 ). There's a problem with their approach,...

The Best Tools for Visualization - ReadWriteWeb (tags: data visualization graphics )

Labnotes » json_request: handling JSON request in Rails 2.0 (tags: rubyonrails json )

generatedata.com (tags: database data )

ELASTRA - The Infinite Database (tags: database snb )