Re: test cases for fromUnionQuery, please

On Tue, May 31, 2005 at 12:07:46PM -0500, Dan Connolly wrote:
> 
> So I was almost prepared to put the question ala:
> 
>   address fromUnionQuery ala http://www.w3.org/2001/sw/DataAccess/rq23/
>   1.367 plus multiple FROMs allowed 
> 
> but I didn't put the question because discussion of other designs
> didn't seem to be done. We ran out of time in the teleconference,
> but now that I think about it, this design seems quite mature and
> I wonder how we would get the other designs to be as mature; I haven't
> seen proposed text for other designs; the 12 Oct spec didn't have
> formal definitions; I didn't realize that people thought of it
> as sharply different until today. It's understandable that other
> people are counting on Andy to work out the details, since we're
> all busy... but I think it's fair to ask for test cases.
> 
> For each of these options, and any other designs anybody wants
> the WG to consider, would you please send a test case that
> distinguishes it from the design in the editor's draft?
> Bonus points for suggesting textual changes.
> 
> 
> POLL OPTIONS:
>   (0) take out GRAPH; query against one RDF graph punt SOURCE and
>    fromUnionQuery issues
> 
>   (1) address fromUnionQuery ala
>    http://www.w3.org/2001/sw/DataAccess/rq23/ 1.367 plus multiple
>    FROMs allowed
> 
>   (1b) ala 1 but with no FROM/FROM NAMED in the QL, only in the protocol
> 
>   (2) use 12 Oct design
>   (2b) ala PatH: bg graph always contains (vs is) the (er... something)
> 
>   (3) ala Yoshio, no implicit dataset; all data to be queried
>   is specified in the query
> 
> I'll give a few:
> 
> for (0), take out section "7 RDF Dataset" and "8 Querying the Dataset"
> and "9 Specifying RDF Datasets" and cauterize dangling references;
> similarly for the protocol spec. As for a test case, take all the SOURCE
> tests and mark them as illegal syntax.
> 
> For (1), here's a test case that clarifies how multiple
> FROMs work:
> 
>   SELECT ?who FROM <u1> FROM <u2> FROM <u3>
>    WHERE { ?who foaf:knows :fred, :wilma, :barney }.
> 
>  <u1> has { :bambam foaf:knows :fred }
>  <u2> has { :bambam foaf:knows :wilma }
>  <u3> has { :bambam foaf:knows :barney }
> 
> I don't think (1b) has much/any support.
> 
> For option (2), I'm starting to understand how it's interestingly
> different, but I'm not sure I have my finger on it. Would EricP
> or SteveH or somebody please sketch a test case that makes the
> difference crisp?
> 
> 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?

I took at stab at this with the predjudice that they were not different:

Tim's example 0, source of inferred graphs (note the 'J'):

  document foo.rdf :
	mary  foaf:phone   1234 .
 +
  document bar.rdf :
	mary  owl:sameAs   maryJ .
 +
  OWL
 =
  graph _:x :
	maryJ foaf:phone   1234 .

named graph query:
	GRAPH  ?s {  maryJ   foaf:phone   ?y } .
	?s inferredFromRule ?r

source (12 -Oct) query:
	SOURCE ?s {  maryJ   foaf:phone   ?y } .
	?s inferredFromRule ?r


Tim's example 2 is, I think, getting at trust chains. I couldn't quite
work out what he was saying SPARQL should be able to do, so I'm
re-expressing examples from
  http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0067
in the hopes that they are at least nearby:

  DEFAULT TRUST
  -------------

named graph and source queries are the same:
  SELECT ?payee ?amount ?refStr
    LOAD d:bobsBills
   WHERE {
		?check f:payTo ?payee .
		?check f:amount ?amount .
		?check f:reference ?refStr }


  SINGLE TRUST DOMAIN
  -------------------

named graph:
  SELECT ?payee ?amount ?refStr
    LOAD INTO d:bobsBills
   WHERE { GRAPH d:bobsBills {
		?check f:payTo ?payee .
		?check f:amount ?amount .
		?check f:reference ?refStr } }

source:
  SELECT ?payee ?amount ?refStr
    LOAD d:bobsBills
   WHERE { SOURCE d:bobsBills {
		?check f:payTo ?payee .
		?check f:amount ?amount .
		?check f:reference ?refStr } }


  PREDICATED TRUST
  ----------------

named graph:
  SELECT ?payee ?amount ?refStr
    LOAD INTO a:bobsBills h:Bob
   WHERE { GRAPH d:bobsBills {
		?check f:payTo ?payee .
		?check f:amount ?amount } .
	    GRAPH j:Bob {
		?check f:reference ?refStr } }

source:
  SELECT ?payee ?amount ?refStr
    LOAD a:bobsBills h:Bob
   WHERE { SOURCE d:bobsBills {
		?check f:payTo ?payee .
		?check f:amount ?amount } .
	    SOURCE j:Bob {
		?check f:reference ?refStr } }


Both have the capacity to have more complex trust chains:

named graph:
  SELECT ?payee ?amount ?refStr ?venue
    LOAD INTO my:trusts a:bobsBills h:Bob z:events
    LOAD z:events
   WHERE { GRAPH <my:trusts> {
		<I> my:trustWriter ?checkWriters .
		<I> my:trustCounter ?beanCounter } .
	   GRAPH ?checkWriters {
		?check f:payTo ?payee .
		?check f:amount ?amount } .
	   GRAPH ?beanCounters {
		?check f:reference ?refStr } .
	   GRAPH <z:events> {
		?event z:happenedAt ?refStr } .
	   ?event venue ?venue } # venue data not secure

source:
  SELECT ?payee ?amount ?refStr ?venue
    LOAD my:trusts a:bobsBills h:Bob z:events
   WHERE { SOURCE <my:trusts> {
		<I> my:trustWriter ?checkWriters .
		<I> my:trustCounter ?beanCounter } .
	   SOURCE ?checkWriters {
		?check f:payTo ?payee .
		?check f:amount ?amount } .
	   SOURCE ?beanCounters {
		?check f:reference ?refStr } .
	   SOURCE <z:events> {
		?event z:happenedAt ?refStr } .
	   ?event venue ?venue } # venue data not secure


> For (3), we one degenerate test case that distinguishes it
> from rq23 is the 1st example in the spec:
> 
> SELECT ?title
> WHERE  { <http://example.org/book/book1>
> <http://purl.org/dc/elements/1.1/title> ?title }
> 
> that becomes illegal. Some specification of the data
> to query is required; so the "hello world" example
> would change to semething like:
> 
> SELECT ?title FROM <books.rdf> WHERE { ?book dc:title ?title }.
> 
> That seems like a significant change in direction, so
> I'd like to see explicit support from several WG members
> before we explore it further.
> 
> Other things that become illegal in this design are answers
> that come from beyond the graphs given in the query. I doubt
> that can be expressed in our current test harness, but I suppose
> we could figure out some way to do it.
> 
> 

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