W3C home > Mailing lists > Public > public-lod@w3.org > April 2011

Re: REST and Linked Data (was Minting URIs)

From: Bob Ferris <zazi@elbklang.net>
Date: Sun, 17 Apr 2011 14:13:29 +0200
Message-ID: <4DAAD969.4050604@elbklang.net>
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

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:32 UTC