W3C home > Mailing lists > Public > public-awwsw@w3.org > March 2011

[Fwd: [Graphs] Fwd: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"]

From: Nathan <nathan@webr3.org>
Date: Fri, 18 Mar 2011 15:10:43 +0000
Message-ID: <4D8375F3.6040404@webr3.org>
To: AWWSW TF <public-awwsw@w3.org>
CC: Jonathan Rees <jar@creativecommons.org>
also fwd'ing here

-------- Original Message --------
Subject: [Graphs] Fwd: Comments on "SPARQL 1.1 Uniform HTTP Protocol for 
Managing RDF Graphs"
Resent-Date: Fri, 18 Mar 2011 14:33:36 +0000
Resent-From: public-rdf-wg@w3.org
Date: Fri, 18 Mar 2011 09:31:20 -0500
From: Pat Hayes <phayes@ihmc.us>
To: RDF Working Group <public-rdf-wg@w3.org>
References: <201103181343.53113.kjekje@ifi.uio.no>

I have taken the liberty of forwarding this to the WG. I suggest that we 
need to sort this issue out, and to liaise with DAWG in order to avoid a 
clash of ideas and terminologies being set in stone by them before we 
can get our ideas clear. Sorry to be so pushy, but this does seem rather 
important and the SPARQL timetable has made it urgent.

The following seem to me to be the key issues.
(1) Getting the basic distinctions clear between RDF 
graphs/documents/resources/g-boxes/g-snaps/g-texts/datasets. Hopefully 
we can all come to agree on this boiling down to a small number of basic 
(2) Getting a single clear voice on what exactly it is that a name 
names, and, to quote Kjetil: "What does the URI of a information 
resource consisting of some RDF triples identify?"
(3) Aligning the answer to (2) with some kind of coherent story about 
HTTP and RDF 'information resources'. Maybe endorsing the http-range-14 
rule about 303 redirects, for example, or maybe not: whatever, but at 
least saying SOMETHING definite about it.


PS. Just to test the water, here is one possible way to make a coherent 
a. RDF graphs are abstractions, which are not information resources. 
(Think parse trees rather than documents.)
b. RDF g-boxes are information resources, which can be identified by a 
URI in the usual Web way. A 'named graph' is actually a named g-box. An 
RDF dataset is a collection of named g-boxes. (If we agree on this, we 
should ask DAWG to make this clear and we must provide them with a 
stable vocabulary that they can use to make it clear. Or we will have to 
use their stable vocabulary.)
c. "RDF document" can mean either a g-box or a g-text, in much the same 
way that an HTML file, suitably located on a server, can be seen as an 
information resource, but a copy of it can also be seen as a 
REST-representation of that resource. So to answer Kjetil: yes, a URI 
can identify an RDF document, but not an RDF graph. But it can also 
identify a resource which emits different RDF documents  from time to time.
d. We endorse http-range-14, so a 'named graph' must be a named g-box, 
if the naming URI  returns a 200-level HTTP response to a GET request. 
If someone wants to name an actual RDF graph with a bare URI, they have 
to use 303 redirection and somehow indicate that it is the actual 
abstract graph, rather than the g-box, that they wish to name. I really 
don't know how to do this indicating. Maybe it could be done by using a 
graph literal and owl:sameAs, for example (??That seems to me to be 
overkill, in that if you already have the entire graph in the literal, 
why bother referring to some other version of it using a name?) Or maybe 
we should provide some reserved vocabulary to say this directly in the 
RDF itself. Whatever, but we do need to specify some way to do it.


Begin forwarded message:

> Resent-From: public-rdf-dawg-comments@w3.org
> From: Kjetil Kjernsmo <kjekje@ifi.uio.no>
> Date: March 18, 2011 7:43:51 AM CDT
> To: public-rdf-dawg-comments@w3.org
> Cc: Tim Berners-Lee <timbl@w3.org>, SW-forum Web <semantic-web@w3.org>
> Subject: Re: Comments on "SPARQL 1.1 Uniform HTTP Protocol for Managing RDF Graphs"
> 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:
> http://www.w3.org/TR/rdf-concepts/#dfn-rdf-graph
> whereas "RDF Document" was defined in RDF/XML Syntax:
> http://www.w3.org/TR/REC-rdf-syntax/#section-conformance
> 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:
> http://www.w3.org/TR/cooluris/#distinguishing
> 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
> -- 
> Kjetil Kjernsmo
> PhD Research Fellow, University of Oslo, Norway
> Semantic Web / SPARQL Query Federation
> kjekje@ifi.uio.no              http://www.kjetil.kjernsmo.net/

IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Friday, 18 March 2011 15:11:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:22 UTC