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

On 18/03/11 14:31, Pat Hayes wrote:
> 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
> ideas.
> (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.
>
> Pat
>
> PS. Just to test the water, here is one possible way to make a coherent
> story.
> 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.)

Yes. Strictly, SPARQL 1.0 (RDF dataset) just talks about the pair (<u>, 
G) with little about the association happening but in practice, the 
association is g-box naming.  It is for SPARQL Update and the Datatset 
protocol (personal comment).

> 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.

In g-box/g-snap/g-text, there is third concept which is g-snap and the 
word "respresents" is used for g-box->g-snap (inc in Gavin's diagram) 
but in AWWW a representation is the bits (g-text) returned.

Is g-snap->g-text is just a function of the content type?

	Andy

>
> ------
>
> Begin forwarded message:
>
>> *Resent-From: *public-rdf-dawg-comments@w3.org
>> <mailto:public-rdf-dawg-comments@w3.org>
>> *From: *Kjetil Kjernsmo <kjekje@ifi.uio.no <mailto:kjekje@ifi.uio.no>>
>> *Date: *March 18, 2011 7:43:51 AM CDT
>> *To: *public-rdf-dawg-comments@w3.org
>> <mailto:public-rdf-dawg-comments@w3.org>
>> *Cc: *Tim Berners-Lee <timbl@w3.org <mailto:timbl@w3.org>>, SW-forum
>> Web <semantic-web@w3.org <mailto: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://phayesAT-SIGNihmc.us>
> http://www.ihmc.us/users/phayes
>
>
>
>

Received on Friday, 18 March 2011 19:23:33 UTC