[Mulgara-general] SPARQL filter not being applied.

[Paul Gearon]

On Mon, Jun 22, 2009 at 1:32 PM, Jim Irwin <jimirwin at acm.org> wrote:
>
> > Hmmm, I'm not sure if I properly coded for cascading filters. I'm
> > expecting that this is the issue. You can confirm for me by trying the
> > filters in the opposite order. If this changes which one is being
> > ignored, then it's an issue with the parsing.
> >
> > Until I have it fixed, you can always just use an "and" operator to
> > join the conditions:
> >
> >  SELECT ?instance ?rvtx_auto_label
> >  WHERE {{?instance rbrnr:Object-Name ?rvxtmp_1 .
> >      FILTER (?rvxtmp_1 = "Gesture" && !isBLANK(?instance))}
> >  OPTIONAL {?instance rdfs:label ?rvtx_auto_label .}}
> >
> > Regards,
> > Paul
>
> I tried both variants: using the and, and also changing the order of the filters.  Both worked,
> to a degree.

When the filters are reversed I was expecting it to filter by the
?rvxtmp_1 variable equaling "Gesture", and NOT by the ?instance
variable being blank (meaning that only the second filter was being
applied). Is that what happened? Perhaps your data is set up so that
the domain of rbrnr:Object-Name is not likely to be blank? (meaning
that your data is shaped such that this condition is inherent and
needn't be filtered on)

>  There is one remaining problem, which is that Mulgara didn't evaluate FILTER(rvxtmp_1 =
> "Gesture") to true when rvxtmp_1 actually had a value of "x"^^xsd:string rather than an
> untyped "x".

Actually, that is designed behavior. Reading the SPARQL spec on
RDFterm-equals at
http://www.w3.org/TR/rdf-sparql-query/#func-RDFterm-equal-foot1 says
the following:
---
Returns TRUE if term1 and term2 are the same RDF term as defined in
Resource Description Framework (RDF): Concepts and Abstract Syntax
[CONCEPTS]; produces a type error if the arguments are both literal
but are not the same RDF term *; returns FALSE otherwise. term1 and
term2 are the same if any of the following is true:

    * term1 and term2 are equivalent IRIs as defined in 6.4 RDF URI
References of [CONCEPTS].
    * term1 and term2 are equivalent literals as defined in 6.5.1
Literal Equality of [CONCEPTS].
    * term1 and term2 are the same blank node as described in 6.6
Blank Nodes of [CONCEPTS].
---

This refers to RDF literal equality at
http://www.w3.org/TR/rdf-concepts/#section-Literal-Equality which
says:
---
Two literals are equal if and only if all of the following hold:

    * The strings of the two lexical forms compare equal, character by
character.
    * Either both or neither have language tags.
    * The language tags, if any, compare equal.
    * Either both or neither have datatype URIs.
    * The two datatype URIs, if any, compare equal, character by character.
---

You are describing a case where the first three conditions hold, but
the last two do not (the literals differ by datatype URI).

> I thought the SPARQL specification requires (or perhaps merely allows?) a FILTER to do
> type conversions?  Jena did return the expected instance when the property had an
> xsd:string value.

I'm surprised at this. My reading of the spec says that it shouldn't,
hence I implemented it that way. Mind you, now that I look at it, I
see that the datatype builtin function will return xsd:string on an
untyped literal. So maybe Jena is using this method as a part of its
string equality test? That doesn't seem to mesh with the requirement
of "Either both or neither have datatype URIs."

It certainly be convenient to allow for easy string comparisons, but I
don't see how, given the spec. Of course, you can always filter by:
  FILTER( str(?rvxtmp_1) = "Gesture" )

But if there's a chance that "Gesture" could appear with another
datatype (unlikely, but I'm covering my bases here) then you'd have to
also filter by type:
  FILTER( str(?rvxtmp_1) = "Gesture" && datatype(?rvxtmp_1) = xsd:string )

Fortunately you don't have to test for null-vs-xsd:string because
simple literals also return xsd:string.

> For Mulgara, I had to modify the query to FILTER(?rvxtmp_1 = "Gesture"^^xsd:string) in
> order to get the expected result.

As you should. I'm really surprised (and concerned) that Jena doesn't
behave this way.

If someone is able to explain how I have this wrong, then I'll be more
than happy to change it. (That's a hint Andy, if you're reading).  :-)

Meanwhile, I'm going to leave it as I believe it's supposed to be, and
recommend adding in the datatype expression that I demonstrated above.

Regards,
Paul