Re: [SKOS] subsection of Primer about ISSUE-36

Hi Alistair,

>> Hi Alistair,
>>
>> Interesting comments, thanks!
>> I guess that though in many cases the outcome of the two options would be the same, the formal semantics are completely different ;-)
>>
>> One question though: should "GRAPH" really replace "FROM NAMED", or just be added to the existing queries?
> 
> Well, I'm not sure. Personally, I'm still confused about what exactly
> FROM and FROM NAMED really mean, or how they should be implemented by
> a sparql query engine, or how they should/must/must not be used with
> the GRAPH keyword. I should reread the spec, if it was clear on first
> reading it didn't stick in my mind.
> 
> In my own work I only ever use SPARQL endpoints over fixed RDF
> datasets, and use the GRAPH keyword to access different graphs in the
> underlying quad store. I know operationally how the GRAPH keyword is
> handled by the query engine, so I'm only confident using examples with
> only GRAPH keywords in.

OK, so if you're confident with only GRAPH, let's do it like this. 
Once GRAPH is there, it should be implicit that the query has to be fired against a store that defines that graph...

Antoine

> 
> Cheers,
> 
> Alistair
> 
>> Antoine
>>
>>
>>> Hi Antoine,
>>>
>>> Sorry for not responding sooner on this, for the most part it looks
>>> fine, however I would change the SPARQL queries to use the GRAPH
>>> keyword instead of FROM NAMED, see below.
>>>
>>> On Sun, Dec 14, 2008 at 08:09:02PM +0100, Antoine Isaac wrote:
>>>> Hi everyone,
>>>>
>>>> About the following action:
>>>>
>>>>>    [PENDING] ACTION: Antoine propose 1 or 2 SPARQL examples showing
>>>>>    named graph usage [recorded in
>>>>>    [36]http://www.w3.org/2008/11/25-swd-minutes.html#action14]
>>>> I'd like to propose to add to the Primer the sub-section below (it would be at the very end of the Primer).
>>>> I hope this capture the spirit of our resolution for ISSUE-36 [1] appropriately, while not going too much in the direction of not yet stabilized practices.
>>>>
>>>> Feedback of the WG is highly welcome!
>>>>
>>>> Cheers,
>>>>
>>>> Antoine
>>>>
>>>> [1] http://www.w3.org/2006/07/SWD/track/issues/36
>>>>
>>>> ===============
>>>>
>>>> 5.3 SKOS, RDF Datasets and Information Containment
>>>>
>>>> In a context of networked KOSs, some applications may require 
>>>> tracking provenance or ownership of SKOS statements, for instance for 
>>>> trust purposes. A specific issue is how to establish explicit links 
>>>> between a concept scheme and every piece of information that is 
>>>> stated in the original KOS it represents, including for instance 
>>>> semantic relationships between concepts. 
>>>>
>>>> Such functionality, albeit identified as a candidate requirement [SKOS-UCR], is currently outside the scope of SKOS. In RDF, statements comes as context-free triples, which makes it difficult to represent containment and provenance.
>>>>
>>>> However, solutions for such problems have been proposed, like named graphs [NAMED-GRAPHS], and the use of RDF Datasets in SPARQL [SPARQL]. A SKOS concept scheme can be related to an RDF Dataset, or even asserted to be such a Dataset, which enables to create SPARQL queries dealing with some form of provenance/containment. Continuing the example of Section 3.2, and assuming that ex1:referenceAnimalScheme and ex2:catScheme have been managed as appropriate RDF Datasets (here, named graphs), the query
>>>>
>>>> SELECT  ?x ?y
>>>> FROM NAMED <ex2:catScheme>
>>>> WHERE   { ?x skos:broader ?y }
>>> SELECT ?x ?y
>>> WHERE {
>>>   GRAPH ex2:catScheme {
>>>     ?x skos:broader ?y
>>>   }
>>> }
>>>
>>>> may return (ex2:abyssinian, ex1:cat) as a result, while this tuple 
>>>> would not appear among the results of 
>>>>
>>>> SELECT  ?x ?y
>>>> FROM NAMED <ex1:referenceAnimalScheme>
>>>> WHERE   { ?x skos:broader ?y }
>>> SELECT ?x ?y
>>> WHERE {
>>>   GRAPH ex1:referenceAnimalScheme {
>>>     ?x skos:broader ?y
>>>   }
>>> }
>>>
>>>> Readers should nevertheless be aware that these mechanisms have not been widely used at the time of writing, and that different standard practices could emerge in the future.
>>>>
>>>>
>>
>

Received on Tuesday, 24 March 2009 17:28:49 UTC