Re: Strawpoll proposals on terminology

On Oct 12, 2011, at 4:22 PM, 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.

Since the containers are mutable, why do we need 'slots' to put them in? That sounds like an unnecessary extra level of indirection.

> 
> S1a) A Graph Store contains one (unnamed) default Graph Container and zero or more Graph Containers each associated with a IRI.

That is better.

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

UM...what graph store? Do you mean that the dataset is the state of 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

Why not just remove <g> (and its name) from the GC altogether?  

> 
> S7) When we write SELECT * WHERE { GRAPH <g> {?s ?p ?o} } the triple <g> rdf:type :GraphContainer is true for some <g>

1. for *some* <g> ??  What does that mean? 
2. As we have decided that <g> doesnt necessarily refer to the graph, the truth of that triple (which does depend on what <g> refers to) has no relationship at all with any facts about the graph that <g> is associated with. 

> 
> S7a) When we write SELECT * WHERE { GRAPH <g> {?s ?p ?o} } the triple <g> rdf:type :GraphContainer is true for all <g>

Similarly

> 
> 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 would prefer to state this in terms of graph naming than http GET. And then the connection between naming and http GET (and  codes) should be stated separately, and more generally. I think it would be a serious mistake for SPARQL to have one notion of graph naming and other systems to have a different notion with a possibly different connection to HTTP GET. So lets state this naming//HTTP connection once and use it consistently everywhere else.

Pat



> 
> 
> 
> 
> 
> -- 
> Ian Davis, Chief Technology Officer, Talis Group Ltd.
> http://www.talis.com/ | Registered in England and Wales as 5382297

------------------------------------------------------------
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 Thursday, 13 October 2011 01:52:51 UTC