W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2011

Re: Strawpoll proposals on terminology

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 12 Oct 2011 20:30:06 -0400
To: Ian Davis <ian.davis@talis.com>
Cc: RDF WG <public-rdf-wg@w3.org>
Message-ID: <1318465806.25065.82.camel@waldron>
On Wed, 2011-10-12 at 22:22 +0100, Ian Davis wrote:
> I think we would get understand the extent of consensus in the group
> if we ran some strawpolls on usage of our terminology with some
> concrete statements
> 
> I restated some definitions from SPARQL 1.1 using explicit RDF Graph
> and RDF Container terminology. I also extended the idea of explaining
> in prose what certain SPARQL queries mean. I finally threw in a few
> statements that push the boundaries of what we discussed today.
> 
> S0) The state of a Graph Container is an RDF Graph.
> 
> S1) A Graph Store contains one (unnamed) slot holding a default Graph
> Container and zero or more named slots holding named Graph Containers.
> 
> S1a) A Graph Store contains one (unnamed) default Graph Container and
> zero or more Graph Containers each associated with a IRI.
> 
> S2) An RDF Dataset is a set { G, (<u1>, G1), (<u2>, G2),... (<un>,
> Gn) } where G and each Gi are RDF Graphs and each <ui> is an IRI. 
> 
> S3) The RDF Graphs in an RDF Dataset are the states of the Graph
> Containers contained in the Graph Store.
> 
> The following all assume <g> is associated with a Graph Container in
> the Graph Store
> 
> S4) When we write SELECT * WHERE { GRAPH <g> {?s ?p ?o} } we mean the
> SPARQL engine should retrieve the RDF Graph that is the state of the
> Graph Container that <g> is associated with and evaluate the graph
> pattern against the RDF Graph.
> 
> S5) When we write INSERT DATA { GRAPH <g> { :s :p :o } }  we mean the
> SPARQL engine should retrieve the RDF Graph that is the state of the
> Graph Container that <g> is associated with, perform an RDF-Merge
> operation between that RDF Graph and :s :p :o and set the state of <g>
> to be the resulting graph.
> 
> S6) When we write DELETE DATA { GRAPH <g> { :s :p :o } } we mean the
> SPARQL engine set the state of the Graph Container that <g> is
> associated with to the empty RDF Graph
> 
> S7) When we write SELECT * WHERE { GRAPH <g> {?s ?p ?o} } the triple
> <g> rdf:type :GraphContainer is true for some <g>
> 
> S7a) When we write SELECT * WHERE { GRAPH <g> {?s ?p ?o} } the triple
> <g> rdf:type :GraphContainer is true for all <g>
> 
> S8) When ASK WHERE { GRAPH <g> { :s :p :o } } evaluates to true and
> <g> is an http IRI then at some time in the past an HTTP GET request
> to <g> has returned a document that when parsed results in a graph
> that contains the triple :s :p :o

I think I agree with all of these except S8, which is a bit too narrow.
I think it's quite possible for g to be never-used but served by this
SPARQL server, so the server knows quite perfectly what the graph
container contents are.    I think it's also fine for g to be a
non-dereferenceable URI (tag or uuid).

     -- Sandro
Received on Thursday, 13 October 2011 00:30:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:45 GMT