- From: Bob Ferris <zazi@elbklang.net>
- Date: Sun, 17 Apr 2011 14:13:29 +0200
- To: public-lod@w3.org
Hi Ed, this topic was recently discussed in the Semantic Web community [1] and the REST community [2,3] as well. It might be an interesting read re. this topic. Cheers, Bob [1] http://answers.semanticweb.com/questions/2763/the-relation-of-linked-datasemantic-web-to-rest [2] http://tech.groups.yahoo.com/group/rest-discuss/message/17242 [3] http://tech.groups.yahoo.com/group/rest-discuss/message/17281 On 4/17/2011 12:28 PM, Ed Summers wrote: > Hi Michael, > > On Fri, Apr 15, 2011 at 1:57 PM, Michael Hausenblas > <michael.hausenblas@deri.org> wrote: >> I find [1] a very useful page from a pragmatic perspective. If you're more >> into books and not only focusing on the data side (see 'REST and Linked >> Data: a match made for domain driven development?' [2] for more details on >> data vs. API), I can also recommend [3], which offers some more practical >> guidance in terms of URI space management. > > Thanks for the reference to the recent REST and Linked Data [1] paper, > I had missed it till now. I had some comments and questions, which I > figured couldn't hurt (too much?) to be discussed here: > > """ > Typically a REST service will assume the resource > being transferred in these representations can be considered > a document; in the terminology of the following section, an > ‘information resource’. > """ > > I guess in some ways this is a minor quibble, but this seems to me to > be a fairly common misconception of REST in the Linked Data community. > In his dissertation Roy says this about resources [2]: > > """ > The key abstraction of information in REST is a resource. Any > information that can be named can be a resource: a document or image, > a temporal service (e.g. "today's weather in Los Angeles"), a > collection of other resources, a non-virtual object (e.g. a person), > and so on. > """ > > It is actually pretty common to use URLs to identify "real world" > things when designing a REST API for a domain model. However, if a > developer implements some server side functionality to allow (for > example) a product to be deleted with an HTTP DELETE to the right URL, > they would typically be more concerned with practical issues such as > authentication, than with the existential ramifications of deleting > the product (should all instances of the product be recalled and > destroyed?). > > Section 3.3 of the REST and Linked Data paper goes on to say: > > """ > Linked Data services, in implementing the “HTTP range > issue 14” solution [12], add semantics to the content negoti- > ation to distinguish between URIs that are non-information > resources (identifiers for conceptual or real-world objects) > and URIs that are information resources (documents) that > describe the non-information resources. This is because as- > sertions in the RDF graph are usually relationships that ap- > ply to the non-information resource, but Linked Data over- > loads URI usage so that it is also a mechanism for retrieving > triples describing that resource (in a document, i.e. an in- > formation resource). (This is a change iin behaviour from > earlier use of HTTP URIs in RDF, when they were not ex- > pected to be dereferenced.) > """ > > Was there really a chapter in the history of the Semantic Web where > HTTP URIs in RDF were not expected to resolve? Wouldn't that have > removed all the machinery for the "Web" from the "Semantic Web"? I > only really started paying attention to RDF when the Linked Data > effort (SWEO) picked up, so I'm just generally interested in this > pre-history, and other people's memory of it. > > Minor quibbles aside, as a web developer I'm a big supporter of the > paper's conclusions, which promote REST's notion of Hypertext As The > Engine Of Application State (HATEOS), and the semantics that the HTTP > Connector provides, in the Linked Data space: > > """ > 3. Services that publish Linked Data resources should pay > careful consideration to HATEOAS as a viable altern- > ative SPARQL, and identify resources to enable REST- > ful use of the API. > 4. RESTful methods should be developed for the write- > enabled Web of Data. > """ > > Thanks to the authors (cc'd here) for writing that down and presenting > it forcefully. > > //Ed > > [1] http://ws-rest.org/2011/proc/a5-page.pdf > [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2 >
Received on Sunday, 17 April 2011 12:14:00 UTC