Hyperdata, interoperable data web and other loosely related concepts
Apologies in advance. I'm attempting to couple loosely related threads here...I have no conclusion.
Leigh Dobbs originally published Connecting Social Content Services using FOAF, RDF and REST for XTech 2005, where he analysed a sample of eight APIs (including the usual suspects - del.icio.us, Last.fm and Upcoming).
Dobbs speculated as to why those services lacked 'hypermedia' support.
Hypermedia: links and pointers to other resouces that are included in a service response to allow further discovery and interaction of those other resources. Or, to paraphrase Danny Ayers, 'Hypermedia should be hyperdata and Hyperdata is 'the Semanitc Web'.
Back to Dobbs (my bold):
"Lack of linking can be attributed to three factors. Firstly, discussion of the REST style have, to date, been largely centred on correct use of HTTP rather than the additional benefits that acrue from use of hypermedia. Secondly, the RPC style that the majority of the services follow, promotes a view of the API as a series of method calls, rather than endpoints within an hypertext of data. Thirdly, the use of API keys prohibits free publishing of links, as given URL is only suitable for use by a single application, the one to which the key was assigned."
Mike Dierken (a 'Senior Troublemaker') last week provided another reason why the desired 'hypermedia' (or 'hyperdata') support might be missing from those services analysed by Dobbs...again, my bold:
"This review notes that nearly all services do not use hypermedia which I think is unfortunate but understandable. I've always had a problem resolving the desire to be flexible in allowing the internal data identifiers to be used in many situations and the desire to be trivally easy for clients to access other resources by simply using links - the mashup problem. One issue I have is that the server-side software that generates the representation might not know all the possible resources made available by sibling services. Think of a US postal zip-code - if you have a service that provides weather based on zip code, should that representation also be responsible for linking to all other services - either provided by your system or some other server - that could potentially take in a zip-code? My approach is to return both direct links to known resources (tagged appropriately) as well as the short-form of the identifier, the plain zip-code for example. Microformats sort of do this, but it's a style that isn't well applied by data services."
I'll give Danny the final word (for this post at least ;-) on Hyperdata:
"I'm still convinced that working at the syntax/grammar level without any common data model/language (i.e. semantics) is fundamentally flawed when it comes to global interop. On the web interop starts with URIs for concepts & resources and their relations, not angle brackets. [PS. reworded - amounts to the same, but sounds less abstract]"
More <loosely> related reading: