Comments on: Semweb Gang talks about Glue http://blog.reallywow.com/archives/12 Really? Wow... That's Reallywow Sat, 29 May 2010 02:17:40 +0000 hourly 1 http://wordpress.org/?v=abc By: axxo http://blog.reallywow.com/archives/12/comment-page-1#comment-18 axxo Fri, 06 Feb 2009 11:39:18 +0000 http://blog.reallywow.com/?p=12#comment-18 Nice post!!<br>Also see: <a href="http://pizory.com/2009/01/16/creative-billboards-that-makes-you-look-twice/" rel="nofollow">http://pizory.com/2009/01/16/creative-billboard...</a> Nice post!!
Also see: http://pizory.com/2009/01/16/creative-billboard...

]]> By: lbjay http://blog.reallywow.com/archives/12/comment-page-1#comment-6 lbjay Fri, 19 Dec 2008 18:45:21 +0000 http://blog.reallywow.com/?p=12#comment-6 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>.<br><br>So, yeah. I don't know why I was on about there. 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.

]]> By: lbjay http://blog.reallywow.com/archives/12/comment-page-1#comment-5 lbjay Fri, 19 Dec 2008 15:54:22 +0000 http://blog.reallywow.com/?p=12#comment-5 U posted some HTML but my blarg ated it. I'm guessing it was this:<br><br><link type="application/rss+xml" rel="alternate" href="/feed/discuss/topic/en/green_monster" title="Discussion about Green Monster" /><br><link type="application/rss+xml" rel="alternate" href="/feed/history/topic/en/green_monster" title="History of Green Monster" /><br><link rel="alternate" type="application/turtle" href="http://rdf.freebase.com/rdf/en.green_monster"> 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”>

]]> By: Ed Summers http://blog.reallywow.com/archives/12/comment-page-1#comment-3 Ed Summers Fri, 19 Dec 2008 02:53:16 +0000 http://blog.reallywow.com/?p=12#comment-3 The thing with <link> header is that you don't have to coordinate identifiers much at all. For example Freebase's page for the <a href="http://www.freebase.com/view/en/green_monster" rel="nofollow">Green Monster</a> 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 <a href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven" rel="nofollow">REST APIs Must be Hypertext Driven</a> has a bunch of points in it that seem relevant for unAPI, in particular: <blockquote> 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.] </blockquote> Dare Obasando's provides a helpful <a href="http://www.25hoursaday.com/weblog/2008/10/24/RESTAPIDesignInventMediaTypesNotProtocolsAndUnderstandTheImportanceOfHyperlinks.aspx" rel="nofollow">gloss</a> on this advice: <blockquote> 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. </blockquote> Sounds familiar right? 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?

]]>