Re: New Proposal (6.1) for GRAPHS

On 28 Mar 2012, at 14:53, Andy Seaborne wrote:
> On 28/03/12 12:18, Steve Harris wrote:
>> This seems good to me, assuming that the TriG docs below will have their current behaviour in SPARQL systems when imported, i.e.
>> 
>> SELECT ?type
>> WHERE {
>>    ?g a ?type .
>>    GRAPH ?g {<a>  <b>  <c>  }
>> }
>> 
>> Will return rdf:Graph.
> 
> In the example of:
> 
> <u1>  {<a>  <b>  <c>  }
> 
> as an inference of some kind? (rdf:GraphLabel)
> 
> In:
> 
>   { <u2> a rdf:Graph }
>   <u2> { <a> <b> <c> }
> 
> the base data includes the match to that pattern.

Yes, in that case.

> (modulo the union graph thing but this is loading the default graph explicitly -- what happens in such systems when the data explicitly says "default graph"?)

It doesn't really matter what the data says, it's  what they query engine uses as the "default graph" at query execution time that matters.

- Steve

>> The only reservation I have is relating to systems where (out of the box) the default graph is the Union of the named graphs - this is relatively common. If the TriG also has:
>> 
>> <u3>  {<u2>  a foaf:Person }
>> 
>> Then the answer to the above query would be ?type = rdf:Graph, foaf:Person - which is not what was intended.
>> 
>> In 4store, for example, you could force the issue by instead asking:
>> 
>> SELECT ?type
>> WHERE {
>>    GRAPH<default:>  { ?g a ?type }
>>    GRAPH ?g {<a>  <b>  <c>  }
>> }
>> 
>> but that's not standard SPARQL, uses a system specific ugly URI, and is probably semantically dubious.
>> 
>> - Steve
>> 
>> On 28 Mar 2012, at 03:23, Sandro Hawke wrote:
>> 
>>> I've written up design 6 (originally suggested by Andy) in more
>>> detail.  I've called in 6.1 since I've change/added a few details that
>>> Andy might not agree with.  Eric has started writing up how the use
>>> cases are addressed by this proposal.
>>> 
>>> This proposal addresses all 15 of our old open issues concerning graphs.
>>> (I'm sure it will have its own issues, though.)
>>> 
>>> The basic idea is to use trig syntax, and to support the different
>>> desired relationships between labels and their graphs via class
>>> information on the labels.  In particular, according to this proposal,
>>> in this trig document:
>>> 
>>>   <u1>  {<a>  <b>  <c>  }
>>> 
>>> ... we only know that<u1>  is some kind of label for the RDF Graph<a>
>>> <b>  <c>, like today.  However, in his trig document:
>>> 
>>>   {<u2>  a rdf:Graph }
>>>   <u2>  {<a>  <b>  <c>  }
>>> 
>>> we know that<u2>  is an rdf:Graph and, what's more, we know that<u2>
>>> actually is the RDF Graph {<a>  <b>  <c>  }.  That is, in this case, we
>>> know that URL "u2" is a name we can use in RDF to refer to that g-snap.
>>> 
>>> Details are here: http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1
>>> 
>>> That page includes answers to all the current GRAPHS issues, including
>>> ISSUE-5, ISSUE-14, etc.
>>> 
>>> Eric has started going through Why Graphs and adding the examples as
>>> addressed by Proposal 6.1:
>>> http://www.w3.org/2011/rdf-wg/wiki/Why_Graphs_6.1
>>> 
>>>     -- Sandro (with Eric nearby)
>>> 
>>> 
>> 
> 

-- 
Steve Harris, CTO
Garlik, a part of Experian 
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, Nottinghamshire, England NG80 1ZZ

Received on Wednesday, 28 March 2012 19:00:56 UTC