W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2005

Re: test cases for fromUnionQuery, please

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 03 Jun 2005 18:02:48 +0100
Message-ID: <42A08D38.4050906@hp.com>
To: "Eric Prud'hommeaux" <eric@w3.org>
CC: Dan Connolly <connolly@w3.org>, RDF Data Access Working Group <public-rdf-dawg@w3.org>



Eric Prud'hommeaux wrote:
> On Wed, Jun 01, 2005 at 03:51:19PM +0100, Seaborne, Andy wrote:
> 
>>
>>
>>Dan Connolly wrote:
>><snip/>
>>
>>>Also, Andy, can you take TimBL's comment
>>>http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2004Nov/0020.html
>>>
>>>and extract a test case that shows how the difference
>>>between the 12 Oct design and what TimBL is asking for?
>>
>>In the Oct 12 design, expresses in current language, the default graph 
>>(Tim's
>>default KB) is the RDF merge of the named graphs.
>>
>>Tim made two points:
>>
>>1/ There are many ways to create graphs - merge is just one of them.  His
>>example 0 show one that is the OWL closure of the merge.  This seems quite
>>timely again with possible rules work in the air.
>>
>>2/ That the default to believing (Tim's word) all RDF and the merge of the 
>>RDF
>>is dangerous.  The example 2 is FOAF based.
>>
>>
>>Example 0:
>>
>>G1.ttl:
>>:mary foaf:phone   "1234" .
>>
>>G2.ttl
>>:mary owl:sameAs :maryJ .
>>
>>
>>then
>>
>>    SELECT ?phone WHERE { :maryJ foaf:phone ?phone }
>>
>>gives :maryJ has phone "1234" yet no graph made this claim.  G2 can 
>>injected by a third party.
>>
>>------------------------------
>>
>>Suppose we have two graphs that have been got through crawling.  One 
>>happens to
>>be out of date but that's the nature of FOAF:
>>
>>Named graph <G1>
>>_:x foaf:name "Alice" .
>>_:x foaf:mbox <mailto:alice@example.org> .
>>_:x diet:preference "Vegetarian" .
>>
>>Named graph <G2>
>>_:y foaf:name "Alice" .
>>_:y foaf:mbox <mailto:alice@example.org> .
>>_:y diet:preference "Vegan" .
>>
>>Let's try checking dietary preferences:
>>
>>ASK { [ foaf:name "Alice" ; diet:preference "Vegan" ] }
>>
>>=> (Oct 12 design) Yes
>>
>>=> (Tim asks for) No
> 
> 
> Calling them "named graphs" above somewhat pre-decides the answer.
> I think it's interesting to compare the respective expressivities
> of both languages.  Both proposals allow you to ask either question.

Not really.

The test case is what happen when there is no description of the dataset 
provided.  Can the publisher make available, as named graphs, some RDF without 
that always being in the default graph.  The Oct-12 design says "no you can't".

The current design can express a wider range of datasets than the Oct-12 design. 
    It can express the setup of the Oct-12 design if the publisher wishes to.

> 
> In Source (12-Oct) parlance:
> 
>   ASK
>  LOAD <G1> <G2>
> WHERE { [ foaf:name "Alice" ; diet:preference "Vegan" ] }
> => Yes
> 
>   ASK
>  LOAD <G1> <G2>
> WHERE { GRAPH ?g { [ foaf:name "Alice" ; diet:preference "Vegan" ] } .
>         FILTER ?g != <G1> && ?g != <G2> }
> => No

But this isn't the query in the test case because it has added the fact that the 
client knows that there are named graphs present.  It is when a query is sent to 
a service that is executing against the daatset as provided - does the client 
have to discover that the information in the default graph is also in a named 
graph before it can understand the results from a query which use GRAPH at all.

> 
> and in Name Graphs parlance:
> 
>   ASK
>  LOAD <G1> <G2>
> WHERE { [ foaf:name "Alice" ; diet:preference "Vegan" ] }
> => Yes
> 
>   ASK
>  LOAD INTO <G1> <G2>
> WHERE { GRAPH ?g { [ foaf:name "Alice" ; diet:preference "Vegan" ] } }
> => No
> 
> 
>>Tim as asking that this return nothing unless the publisher has decided to 
>>put that information in the default graph.  The publisher is to be made 
>>responsible for claims in the default graph just like a plain graph and 
>>HTTP GET.
>>
>>	Andy
> 
> 
> That's a very interesting point. In Source, the querier needs to be
> able to specify a trust domain, maybe by enumerating a specific set
> of inclusions or exclusions, or maybe something more complicated
> involving data in some trusted document and some logical connection
> expressible in a FILTER.
> 
> The effect of having a LOAD INTO that specifically does *not* affect
> the default graph (contrary to my aggregator needs),

In the Oct12 design there was no way to have a named graph without the triples 
also appearing in the default graph.

	Andy

 > is that queriers
> that use no LOAD directives get a default graph that could have some
> sort of endorsed status. By default, the user is basically protected
> from the data that they loaded, whereas in Source, they would have to
> specifically enumerate certain documents in or out.
> 
> Tim's use case was pretty sketchy; I'm curious about practical use
> cases of this (the use cases that I have experience with don't need
> it). Maybe social environment is part of these use cases.
> 
> 
>><snip/>
> 
> 
Received on Friday, 3 June 2005 17:05:11 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:23 GMT