W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > March 2011

Re: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"

From: Kjetil Kjernsmo <kjekje@ifi.uio.no>
Date: Fri, 18 Mar 2011 13:43:51 +0100
To: public-rdf-dawg-comments@w3.org
Cc: Tim Berners-Lee <timbl@w3.org>, SW-forum Web <semantic-web@w3.org>
Message-Id: <201103181343.53113.kjekje@ifi.uio.no>
Hi all!

I have previously complained that the "Dataset HTTP Protocol" specification is 
difficult to understand and possibly in conflict with webarch, and I've been 
challenged to be more specific. Now, I've tried to see the issue from more 
sides, and I found an old post from timbl that pinpoints a key issue, and for 
that reason, I have chosen to follow up on that post instead of starting a 
new thread.

Tim Berners-Lee wrote a long time ago:
> 4) So when a GET or PUT is done, this is an implementation of HTTP. It is
> not a new protocol, in that HTTP only is used.  You can't know AND SHOULD
> NOT BE ABLE TO KNOW that in fact there is a SPARQL engine behind it.  That
> bit in caps as it is essential when you provide HTTP that you do totally
> support HTTP, so everything like creation date and expiry etc etc all hold.
> You may well use conneg as well for PUT and GET, for example.  Where GET
> and PUT are concerned this is not a new protocol, and the document should
> take the position as to it is explaining how for a SPARQL service owner to
> support HTTP on those graphs (or rather, virtual RDF documents).

So, the key issue and the root of my confusion is the question: "What does the 
URI of a information resource consisting of some RDF triples identify?" The 
question isn't admittedly not very precise, for a reason that will be 
apparent soon. 

Lets take an example: What does the URI http://www.kjetil.kjernsmo.net/foaf 
identify? Apart from a foaf:PersonalProfileDocument, is it an RDF Graph or an 
RDF Document? 

For reference, "RDF graph" was originally defined in Concepts and Abstract 
Syntax AFAICS:
whereas "RDF Document" was defined in RDF/XML Syntax:

My intuition has always been that http://www.kjetil.kjernsmo.net/foaf 
identifies an RDF Document, and this intuition seems to be shared by at least 
the "Cool URIs for the Semantic Web" Note:
While this is just a Note, and may not even use the term in the meaning of 
RDF/XML Syntax specification.

It is then my interpretation of timbl's post above that if 
http://www.kjetil.kjernsmo.net/foaf identifies an RDF Document and not an RDF 
Graph, then, if that document happens to be served by a SPARQL RDF Dataset 
protocol server rather than from a file on a filesystem on an Apache server 
as today, this MUST NOT change, if the specification insists on a 200 
response (which it should, IMHO).

So, my issue all boils down to whether the URI of the stuff that people have 
been publishing for years identifies RDF Documents or RDF Graphs. If it 
identifies an RDF Graph, then the current spec is OK (if still somewhat 
opaque), but if it identifies an RDF Document, there surely is an 
inconsistency somewhere?

Surely, a resource can't be both an RDF Document and an RDF Graph? Further, 
does it have any bearing on the problem that 
http://www.kjetil.kjernsmo.net/foaf is a foaf:PersonalProfileDocument? Can 
something be both a foaf:PersonalProfileDocument and an RDF Document? (my 
intuition says yes) Can something be both a foaf:PersonalProfileDocument and 
an RDF Graph? (my intuition says no). There are many other conventional 
resources to identify the same way, owl:Ontology and cc:Work comes to mind. 
Would the answer be any different? 

Now, I've possibly exposed myself as totally confused about core Semantic Web 
concepts, but I do so with the confidence that I'm not a n00b, and if I'm 
confused, I'm probably not alone, and the issue should be properly explained 
to the community.

Best regards,

Kjetil Kjernsmo
PhD Research Fellow, University of Oslo, Norway
Semantic Web / SPARQL Query Federation
kjekje@ifi.uio.no              http://www.kjetil.kjernsmo.net/
Received on Friday, 18 March 2011 12:46:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC