Tom Heath's Displacement Activities

How difficult can it be to find a comma-separated list of HTTP Status Codes and their associated labels? Quite hard, apparently, so I made one:

100, Continue
101, Switching Protocols
200, OK
201, Created
202, Accepted
203, Non-Authoritative Information
204, No Content
205, Reset Content
206, Partial Content
300, Multiple Choices
301, Moved Permanently
302, Found
303, See Other
304, Not Modified
305, Use Proxy
306, (Unused)
307, Temporary Redirect
400, Bad Request
401, Unauthorised
402, Payment Required
403, Forbidden
404, Not Found
405, Method Not Allowed
406, Not Acceptable
407, Proxy Authentication Required
408, Request Timeout
409, Conflict
410, Gone
411, Length Required
412, Precondition Failed
413, Request Entity Too Large
414, Request-URI Too Long
415, Unsupported Media Type
416, Requested Range Not Satisfiable
417, Expectation Failed
500, Internal Server Error
501, Not Implemented
502, Bad Gateway
503, Service Unavailable
504, Gateway Timeout
505, HTTP Version Not Supported

For the full documentation try http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

A little while back I wrote briefly about first impressions of Twine. Now that the recent flurry of Twine-related analysis has died down, and a few more people have had the chance to actually use the system, it's probably a good time to look at what Twine has to offer from a Semantic Web point of view. Given Tim's recent post that emphasises the importance of Linked Data to the Semantic Web concept, and Nova Spivack's follow-up post, the timing is even better.

Speaking briefly as Joe User, my first impression was that Twine doesn't yet offer me any clear benefits over del.icio.us. Yet Another Popularity Arms Race is kind of fun while people build up their number of connections, but this masks a bigger issue that I'll get to in a moment. Despite not planning to ditch del.icio.us any time soon, I'm not going to criticise Twine particularly from a user perspective. Getting these things right is hard, and it is still in private beta. However, the one area where I have to comment (constructively, I hope) is regarding Twine's use (or otherwise) of external data.

For me (and many others) the Semantic Web is all about structured, linked data, and the reuse potential this creates. I don't get the impression that this is at all divergent with the view held at Radar Networks. Unfortunately this principle isn't yet fully embodied in Twine as far as I can tell. That's a real shame, and a missed opportunity to demonstrate the power of non-silos.

This issue struck me from the moment I signed up. There was no option to provide the URI of a FOAF file from which my profile could be populated with people I know, a photo, location data and links to other online accounts I hold. Instead I had to recreate all this information manually, despite much of it being out there on the public Web here, and here, and also here ready for consumption. I even had to upload a photo.

For an application that claims to be Semantic Web enabled this is almost unforgiveable. Sure, not everyone has a FOAF file (but how many more have a photo online?), but for those who do and have wondered what to do with it this would be a great payback, and would in turn encourage more people to create one, or sign up with services like MyOpera (hey, that's why I blog here) and Revyu that create FOAF on their behalf.

For me, probably the low point of this signup process from a Linked Data perspective was having to enter my location as a text string. In a world graced by DBpedia and Geonames this really shouldn't be happening. In fact I've since gone back and replaced the textual location with the URI of Birmingham (UK) from DBpedia (http://dbpedia.org/resource/Birmingham) but of course it's not actually a link in either the HTML or RDF output.

Just in case anyone missed it, yes, there's RDF data describing things in Twine. Hurray! Let's not underestimate the significance of this. But, and I'm afraid there is one, Marshall Kirkpatrick's comment about the lack of RSS output is just the tip of the iceberg. I don't just want RSS, or fragments of RDF, I want Linked Data in RDF.

Sticking with the profile theme, when I signed up I added a number of links to Web pages with which I'm associated, such as this blog, my profile page on Revyu and the Platform site at Talis. To Twine's credit these are all exposed in the RDF document about me that is generated from my profile data. Great. Umm, except that they're referenced using the property http://www.radarnetworks.com/2007/09/12/basic#url rather than something in more widespread use, such as http://xmlns.com/foaf/0.1/page. Likewise my "account" is not a sioc:User, and there's no statement here saying that the URI that identifies me (http://www.twine.com/item/1tjtp3mx-185) identifies a thing of type foaf:Person.

One of the key things about creating network effects on the Web of Data is not just reusing those URIs that identify "things" (like the place "Birmingham"), but reusing widely adopted properties and classes from vocabularies/ontologies such as FOAF, that are widely understood by applications. Of course there may be a mapping defined between http://www.radarnetworks.com/2007/09/12/basic#url and foaf:page, but unfortunately I can't tell, as the ontology URI http://www.radarnetworks.com/2007/09/12/basic# just 404s. Linked Data principle number 3: "When someone looks up a URI, provide useful information."

It is pleasing to see that Twine has minted a URI for me (http://www.twine.com/item/1tjtp3mx-185) that is distinct from the page on the site that describes me (http://www.twine.com/user/tomheath). This is definitely good. To really play nice in the world of Linked Data, however, there are a couple of other tweaks that are needed. If I dereference the URI that identifies me, I currently get a 302 Found response that redirects me to the page about me at (http://www.twine.com/user/tomheath). The important bits of the headers look like this:

GET /item/1tjtp3mx-185 HTTP/1.1
Host: www.twine.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

HTTP/1.x 302 Found
Content-Length: 0
Date: Fri, 28 Mar 2008 18:06:21 GMT
Location: http://www.twine.com/user/tomheath
Content-Type: text/plain; charset=UTF-8

This needs to be changed to a "HTTP 303 See Other" redirect in order to be in line with the finding on httpRange-14. There is also some work to be done with the content negotation on the site. At present, if I dereference my URI and ask for application/rdf+xml, I get a 200 OK response and an RDF document returned. It's seems that I am not my homepage, but I am my RDF description.

(The "How to Publish Linked Data..." tutorial has more on these issues.)

Weirdly the RDF I get back from this request is different to that from the RDF version of my profile page. This time I am a basic:Person (but not a foaf:Person), there's no sign of my location or links to my other Web pages, but links to all my connections are given.

I imagine that all these sorts of niggles will be ironed out as the site develops further, but in the meantime Nova might like to slightly tame the claims he makes about support for Linked Data in Twine. Despite saying that "You can learn more about Twine's support for Linked Data and see some examples here", the example given does not show Linked Data, but simply an RDF fragment describing the book Jurassic Park. Perhaps the next iteration will have owl:sameAs links to http://dbpedia.org/resource/Jurassic_Park and http://www4.wiwiss.fu-berlin.de/bookmashup/books/0394588169, and say that the author is http://dbpedia.org/resource/Michael_Crichton. Then there'll really be some claims to make

Having picked many holes, and hopefully provided some useful feedback, my final comment is a feature request. I think is on Radar's, err, radar, but deserves to be aired for the sake of completeness. One of the features I'd most like to see in Twine is greater native handling of different types of things. Right now I can only add one of a finite list of things (audio, book, bookmark, event, person, etc). In order to truly scale I think an open world view needs to be taken on this, where even the "Add Item > Other" menu has an "Other" option, and types can be drawn from data on the Semantic Web at large.

For example, right now "Review" is not an explicitly supported type. Nor is "Cheese". I would like to be able to add a URI such as this http://revyu.com/reviews/e707061801ce1f020d8ca1ed75e50d0e4daeb6e3 to Twine, and the system then tell me that it's a review, not the other way around. At that point the claim of being able to tie it all together will really hit home.

David Peterson was kind enough to send me a Twine invite (thanks David Aside from the obligatory half hour spent making lots of friends (again) and adding a few items to try things out, I haven't really spent enough time with it to form strong impressions. However, the one thing that struck me while I was signing up was: why do I have to upload another photo of myself, that's the same as the one I use on countless other sites and even bother to define in my FOAF file? This isn't very Webby, let alone Semantic Webby. Hmm.

A couple of weeks ago Danny blogged about an Amaya hack that made it easier to insert microformat class names into an HTML document. It's a neat little trick, but the title of the post ("Easy microformat authoring") only reinforces the received wisdom that microformats are easily implemented, especially relative to something like RDF. Predictably this issue raised its head at SemanticCamp in London and led to a brief intellectual scuffle that sadly fizzled out without any real conclusions being reached. I sensed that Premasagar "got" it - he seems like a pretty smart guy - but there seemed to be a lot of microformats enthusiasts suffering from a kind of weapon focus: someone lunges at you demanding data interoperability, but you don't properly take in their face or fully assess the situation because you're focusing on the microformat they're holding in their hand.

In my experience this view that microformats are easy is a myth. It may be trivial to construct snippets of HTML marked up with microformats, but what I found when implementing hReview in Revyu.com is that adding the appropriate classes to the kind of code that exists in the wild is anything but easy.

In most cases it was not adding the class names themselves that was the problem (although not even the hReview "spec" seems to know what the semantics of "url" actually are). The big issue was getting the structure right. Despite the claim that microformats are for "humans first, machines second", checking that I'd applied the right classes to the right elements within my HTML source required me to think like an HTML parser in order to check that elements were correctly nested and therefore reflected the meaning I intended.

After a couple of hours of peering at the hReview classes in my HTML I was fairly confident that I'd got the structure right, but wanted some validation. So I went in search of a microformats validator. This was quite funny. Apparently nothing of the sort exists, then or now. The best answer I got was to run my hReview through an XSL transformation and check that the RDF/XML that came out the other side looked OK. Excuse me while I choke on my coffee.

Therein lies the issue with microformats. Without an underlying abstract data model, validation becomes a bit like standing back looking at a used car, kicking the tyres, concluding "yeah, looks alright", and then handing over the cash.

Maybe none of this matters. Maybe the Web can handle microformat garbage just like it handles so much other rubbish. What really drives me mad are the claims that microformats are up to the same jobs as RDF, and so much easier to implement.

The "humans first, machines second" claim is perverse. What my little anecdote suggests is that, in spite of these claims, microformats are neither easy to use for humans, or particularly likely to yield much reliable data for machines.

I'm here at SemanticCamp in London. We're getting close to the end now, but it's been a great couple of days. The guys from the Centre for Digital Music at Queen Mary are here in force, as are the BBC guys working on RDF export of BBC Programmes. Yves and the guys from C4DM showed a lot of cool stuff yesterday about music info on the Semantic Web, followed by a talk from the BBC guys. Michael Smethurst and co. have already got the TOTP/Later data online as linked data; arrival of the Programmes data will be a huge milestone.

One of the highlights of the day for me was hearing what Chris Jackson, Lee Denison and Ashok Argent-Katwala are doing with URI Play. They're working really hard at making sense of the architectural options, but their plans for providing easy access to TV shows across different service providers and potentially a hub for linking these together look awesome.

Later in the day Georgi gave a great talk about DBpedia, with a particularly nice slide about the SEMANTIC Web community and the Semantic WEB community. This was followed by an interesting but sobering talk from iand about Open Data Licensing.

I was suprised in the morning intro session by the number of people present who chose Microformats (big M as one of their three tags. On the one hand I'm please that the title "SemanticCamp" didn't put this community off; i.e. the event obviously wasn't perceived as a purely Semantic Web show. On the other hand, mid-afternoon yesterday it became obvious that all the Semantic Web people were in one room and all the Microformats community were next door. We haven't had an open flame war yet about upper vs lowercase Semantic Web (thankfully), but there does seem to be a clear divide in where people's loyalties or priorities lie, and I'm a bit sad that the uF community here still seems pretty infatuated with Microformats. Sigh.

It's been good to see some new faces, and catch with some that are more familiar. Aside from the excellent meal at Memories of India on Gloucester Road, the highlight for me was the lengthy, late-night, beer-fuelled discussion with danbri about information resources, non-information resources, and 303 redirects. More on that later I guess.