Re: test cases for fromUnionQuery, please

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

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

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.