REST and Linked Data (was Minting URIs)

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 10:28:37 UTC