HEAS and RDF

HEAS = Hypermedia as Engine of Application State (REST constraint #4)
----
Hi Roy and all,

  first,  Roy, thank you for answering all these fuzzy questions about
  almost any aspect of REST, HTTP, OO, the web, and life ;-)

  I try to see the semantic web as a part of the web and describe this
  in  terms  of  REST. In particular, I am asking myself how a "web of
  data"  as  described by timbl can be woven by resources which return
  representations as content-type application/rdf+xml.

  Clearly   defined   by  REST  (and  HTTP)  we  have  some  kind  of
  web:resources, which give a requesting component a representation of
  their  state.  Then  we have rdf:resources, which are concepts which
  are   described  in the knowledge representation language RDF, RDFS,
  or  OWL.  Now,  if  we  want to marry the two, we have to check what
  happens to the REST contraints:

---
REST is defined by four interface constraints: -- Fielding's Thesis, p. 82

(R1) "identification of resources;"
Ok,  both web:resources and rdf:resources are clearly identified, even
via  the  same  namespace:  URIs.  (Today,  URIs even include fragment
identifiers,  so  thats  fine,  although  the  resolving  process  is
content-type specific wrt to the fragID part).

(R2) "manipulation of resources through representations;"
In   the  web,  clear.  For  RDF,  well, not clear. For RDF, one could
imagine
to  PUT  a  document  to  a URI serving it, in order to update it. Ok.
Using    hash-URIs   (like   http://example.com/doc1#concept3)   for
rdf:resources,  a  single  PUT to http://example.com/doc1 would change
the state of all concepts. Some would even disappear, others be added.
A PUT to an rdf:resource URI using a hash is not even possible. Hmm.

Ok, let's try 303-URIs, as dictated by http-range-14 (@@add link). If
we  have an rdf:resource a which redirects to the web:resource b, then
we  can PUT to a, which gets redirected to b, so we put to b. This, in
turn,  has  changed  the state of what we GET when we GET a and follow
redirects again.

Now,  if  we have an rdf:triple (x,y,z) that we want to save, to which
URI  do  we  PUT  it?  To x? To z? To x and z? PUTing to x and z would
really  weave  the  web of data, allowing someone GETing x to find out
(x,y,z) and then navigate to z - and the other way round. But PUTin to
two URIs seems a bit wired. Any comments on these ideas?

Second  round: SPARQL endpoint. We can POST to the endpoint-URI and we
can  GET from many, many URIs. A SPARQL endpoint exposes a "data set",
which  is  a  set  of  RDF  graphs. How can we set the state of such a
SPARQL  endpoint?  By PUTing a TRiX-representation? How can we PUT the
state of a single graph?

(R3) "self-descriptive messages;"
This  seems  easly  possible  with  RDF,  as  it was designed for this
purpose.  The  only  drawback  is,  you  cannot  just look at the HTTP
headers to know what's inside.

(R4) "hypermedia as the engine of application state." = ~ stateless servers  
So,  this where I am really lost. Which "links" in an RDF graph should
one follow? Don't we need a way in RDF to distinguish between

- pure rdf:resources (those which are not a web:resource = not an
information resource = not returning HTTP 200 OK)

- web:resources

- SPARQL endpoints, where we have a recipe to construct URIs

In  HTML,  all  links  make sense to follow, but in RDF they don't. Of
course,  one  can  try  to dereference all given URIs, but this is not
very  efficient  for  large  documents. Why not send the flag "you can
retrieve  this"/"you don't have to try, it's not a web:resource" along
with   the  RDF?  If  we  don't  do  this, the meaning of our RDF also
partially  depends  on  whether some remote server is running properly
or  not.  This  is something which should be possible to avoid in some
cases.

I  would be really happy to receive some comments on these thoughts and
questions.  I  hope that neither the semweb people nor the REST people
say: "this is not our business" :-)


Kind regards,

  Max Völkel
--
Dipl.-Inform. Max Völkel, Universität Karlsruhe / FZI
            nepomuk.semanticdesktop.org
voelkel@fzi.de   +49 721 9654-854   www.xam.de

Received on Saturday, 11 November 2006 09:52:06 UTC