Semweb Gang talks about Glue

December 18th, 2008

Interesting conversation this month. (This is the stuff I listen to on my commute.) I was particularly intrigued by the 10 or so minutes spent discussing the need for a method of embedding identifiers and the location of a web service into HTML. Send the identifier to the service and get back the metadata. This is the exact use case of unAPI.

I was all set to get to work and give them a brrring! on the cluephone, a.k.a., comment on the post. But before I got around to it Ed Summers pointed out on irc that you can achieve the same thing using just <link> elements and/or HTTP Link: headers. In other words, why separate the identifiers from the service URI.

I like how simple unAPI is to implement. Since your metadata service’s base url doesn’t change you don’t have to worry about coordinating attributes of elements that need to appear in both your <head> and page <body>. This is a non-issue for lots of folks, but I bet it’s not so simple if your using WordPress or Drupal for your CMS.

As for the Glue extension thingie, I’ll try it out before passing judgement. But it did strike me funny that they’re not using RDF for anything. Also, and maybe I’m imagining it, but in the 10-minute wrapup at the end of the podcast I think Tom Heath basically takes a some veiled jabs at the Glue guys for being SemWeb poseurs.

4 responses

  1. Ed Summers comments:

    The thing with <link> header is that you don’t have to coordinate identifiers much at all. For example Freebase’s page for the Green Monster has this chunk of HTML in the head:

    There’s just a link to an alternate version of the resource, in this case some RDF which describes the Green Monster in a similar way to how the HTML describes the Green Monster. Your browser can see the relationship right there explicitly in HTML. You don’t have to coordinate some sort of identifier in a piece of content, and then make sure it’s available in some datastore via some cooked up API that nobody really knows much about. It’s just the processing rules for the HTML media type.

    Roy Fielding’s recent blog post about REST APIs Must be Hypertext Driven has a bunch of points in it that seem relevant for unAPI, in particular:

    A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types. Any effort spent describing what methods to use on what URIs of interest should be entirely defined within the scope of the processing rules for a media type (and, in most cases, already defined by existing media types). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]

    Dare Obasando’s provides a helpful gloss on this advice:

    Google has the Contacts Data API, Yahoo! has their Address Book API, Microsoft has the Windows Live Contacts API, Facebook has their friends REST APIs and so on. Each of these APIs claims to be RESTful in its own way yet they are helping to fragment the Web instead of helping to grow it. There have been some moves to address this with the OpenSocial influenced Portable Contacts API but it too shies away from standard MIME types and instead creates dependencies on URL structures to dictate how the data payloads should be retrieved/processed.

    Sounds familiar right?

  2. lbjay comments:

    U posted some HTML but my blarg ated it. I'm guessing it was this:

    <link type=”application/rss+xml” rel=”alternate” href=”/feed/discuss/topic/en/green_monster” title=”Discussion about Green Monster” />
    <link type=”application/rss+xml” rel=”alternate” href=”/feed/history/topic/en/green_monster” title=”History of Green Monster” />
    <link rel=”alternate” type=”application/turtle” href=”http://rdf.freebase.com/rdf/en.green_monster”>

  3. lbjay comments:

    To clarify my (misguided) point, my thinking was that, for example, you have a page that displays a single blog post. It's very easy in a CMS like drupal to tweak your output template/view to include, say, a <abbr> tag that indicates the id of the post. Easier, perhaps, than inserting a post-specific <link> element in your <head>. But I'm not sure why I got that notion, because it can't be much more complicated to include a post-specific <link> than it is to have a post-specific <title>.

    So, yeah. I don't know why I was on about there.

  4. axxo comments:

    Nice post!!
    Also see: http://pizory.com/2009/01/16/creative-billboard...

Leave a comment