RE: Test cases

OK, the first is the test OPTIONAL-FILTER.

In addition to the results given for the test, I also get:

	title="Title 1", price=unbound

I get to this from this transformation:

?book dc:title ?title .
      OPTIONAL
        { ?book x:price ?price .
          FILTER ?price < 15 .
        } .
    }

or 
	A OPTIONAL (B AND C)
or
	(A AND (B AND C)) or (A AND NOT(B AND C))
or 
	(A AND B AND C) or (A AND NOT B) or (A AND NOT C)


the result comes from the last term (A AND NOT C) or

	{?book dc:title ?title } NOT FILTER ?price < 15

I believe the transformations are valid given the current definitions of
various flavors of graph pattern solutions. 

My take is that to get the result specified by the test, FILTERs would have
to be treated as inseparable from the graphs they are constraining -- i.e.
they couldn't be stand-alone graph patterns but would have to always be
paired with a graph. That would seem to imply that the FILTER keyword
doesn't just introduce a filter pattern but is an operator of sorts that
isn't a synonym for AND (so NOT(A FILTER B) != NOT A or NOT B.) 

I think that might be the intent of FILTER patterns, but it's doesn't appear
to be currently supported by the syntax:

"""[23]   GraphPatternNotTriples   ::=   OptionalGraphPattern |
UnionGraphPattern | GroupGraphPattern | GraphGraphPattern | Constraint"""

i.e. a Constraint is treated as a stand alone pattern...

or the semantics:

"""Definition: Graph Pattern

A Graph Pattern is one of:

Basic Graph Pattern 
Group Pattern 
Optional Graph Pattern 
Union Graph Pattern 
RDF Dataset Graph Pattern 
Value Constraints"""

And 

"""Definition: Group Graph Pattern 

A group graph pattern GP is a set of graph patterns, GPi.

A solution of Group Graph Pattern GP on graph G is any solution S such that,
for every element GPi of GP, S is a solution of GPi."""

i.e. this says that a solution of a group pattern must be a solution of GP0
AND GP1 AND....

Hope that makes some sense.

Best,

Geoff 


> -----Original Message-----
> From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
> Sent: Thursday, May 26, 2005 4:56 AM
> To: Geoff Chappell
> Cc: public-rdf-dawg-comments@w3.org
> Subject: RE: Test cases
> 
> Now, please!
> 
> 	Andy
> 
> -------- Original Message --------
> > From: Geoff Chappell <mailto:geoff@sover.net>
> > Date: 25 May 2005 15:14
> >
> > Thanks, Andy, those work better now :-)
> >
> > BTW, I have a few differing results with some tests that involve
> > unbound vars in filters. Would you like me to report my differences
> now
> > or things still in flux in that area?
> >
> > Best,
> >
> > Geoff
> >
> > > -----Original Message-----
> > > From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
> > > Sent: Wednesday, May 25, 2005 8:56 AM
> > > To: Geoff Chappell
> > > Cc: public-rdf-dawg-comments@w3.org
> > > Subject: Re: Test cases
> > >
> > > Geoff,
> > >
> > > I have fixed the dateTimes and also the manifest problem in your
> > > other message.
> > >
> > > 	Thanks
> > > 	Andy
> > >
> > >
> > > Geoff Chappell wrote:
> > > > I notice in a few test cases - e.g:
> > > >
> > > > 	sparql-query-example-Testing-Values-0
> > > > 	sparql-query-example-Testing-Values-1
> > > >
> > > > that seemingly invalid dateTimes are used:
> > > >
> > > > 	xsd:dateTime("2005-01-01T00:00Z")
> > > >
> > > > (i.e. seconds aren't optional are they?)
> > > >
> > > > Is this an error in the test case or does it imply that the
> > > > xsd:dateTime function is supposed to be liberal in what it
> accepts?
> > > >
> > > > Also, BTW, I think those particular two tests would be clearer if
> > > > they didn't used bnodes as subjects.
> > > >
> > > > - Geoff

Received on Thursday, 26 May 2005 11:59:25 UTC