Re: test cases for fromUnionQuery, please

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

These two examples have changed the test slightly: one key point is that the query:

ASK { [ foaf:name "Alice" ; diet:preference "Vegan" ] }

does have any FROM/LOAD whatever.  It is a straight question of the published 
dataset.

As Yoshio point out:
http://www.w3.org/2005/Talks/0511-keynote-tbl/ slide 3

The forms you show have the application set up the dataset and the publisher is 
neutral party.

 Andy

> 
> 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), 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 Wednesday, 1 June 2005 16:18:07 UTC