« REST: From Research to Practice | Main | Adobe Acrobat Accessibility »

Wednesday, November 03, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.


Please correct me, when I'm getting wrong here (I come originally from the Semantic Web corner). However, one issue where I stumble up again and again, while trying to understand REST as defined by Roy T. Fielding, is the issue with link types. I know i.e. HTML hasn't much link relation types defined out of the box. For me a link is a binary relation in its nature, which can be type (if its not typed, then we have at least one type ;) ). When looking behind the scene of RDF Model, one will also find that binary relation, that is identified by the predicate position of an RDF triple. Due to its metamodel they are called properties, which are typed. So every property assigns a specific relation type. I don't see any need for a central link relation type registry, since one can simply resolve the property URI and should ideally get a description that describes the processing model of that link type human and machine understandable (processable). Furthermore, I thought decentralization is one of main success criterias of the Web. So why working against this constraint?
All in all, why not simply applying RDF Model for that issue, i.e. as it is propagated recently with RDFa? I think the knowledge representation structure of RDF Model is quite ideal therefore.


http://dret.typepad.com/dretblog/2009/10/links-in-html.html is a list of link types defined in HTML out of the box. some are implicit in the elements (if a link is found in , it must link to an image, which will probably be embedded by the browser's rendering engine). This simple model has made google possible (follow links to hopefully more text to be found in other HTML, and ignore images, unless you're building google image search, of course). how would you envision the "imageness" of a linked resource to be discovered dynamically when encountering such a link? the success of the human web lies in the fact that the simple set of link types is hardcoded in HTML, so all clients (mostly browsers and crawlers) know how to deal with it. the link type registry adds a modest amount of extensibility to that model.

take a brief look at the link types in the registry so far. some for example provide paging mechanisms for paging through an atom feed (those are expected to be found in atom feeds). how would you imagine these semantics to be expressed in a way so that they can be understood at runtime? what the link registry does is provide a place where i can find pointers to conventions/standards for link types, and these are about interaction semantics. clients need to implement/support these interaction semantics to make use of these link types, and i haven't seen a semantic framework that would allow to express the fact that a link found in a feed has the semantics of linking to the "next page of feed entries", and that a GET on this URI will result in a feed that contains this next set of entries. or even more extreme, it is very hard to imagine a semantic framework that could fully express the semantics of the action="URI" in an HTML . you need documentation to describe the protocol, and the link type registry can point you to that documentation.

The comments to this entry are closed.