W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: [TF-LIB] IN operator

From: Andy Seaborne <andy.seaborne@talis.com>
Date: Mon, 08 Feb 2010 15:36:05 +0000
Message-ID: <4B702F65.5010400@talis.com>
To: Steve Harris <steve.harris@garlik.com>
CC: Ivan Mikhailov <imikhailov@openlinksw.com>, SPARQL Working Group <public-rdf-dawg@w3.org>


On 08/02/2010 11:50 AM, Steve Harris wrote:
> On 8 Feb 2010, at 11:00, Ivan Mikhailov wrote:
>> IN should be based on equality. For IN based on SAMETERM, a special
>> function might be introduced.
>
> What special function? SPARQL already has sameTerm:
> http://www.w3.org/TR/rdf-sparql-query/#func-sameTerm
>
> Another reason to base it on sameTerm is optimisation. You can replace
> FILTER(?x = <uri1> || ?x = <uri2> ...) with a simple disjunctive
> expression on ?x, but you can't with numeric literals as there are an
> infinite number of literals that are = to "1"^^xsd:integer, for example.
>
> This may not matter in anyone else's engine though, so I didn't bring it
> up before.

It depends on the base storage in my case - I have three cases: stores 
that canonicalize on input, stores that canonicalize at query time and 
stores that don't do value-based graph pattern matching.

 From seeing user questions, IN with URIs is the most important case.

	Andy

>
>> If both scalar subqueries and IN are supported then
>> ?expn IN (SELECT...)
>> should also be supported, of course.
>
> That's a bit of a leap, and I don't think I agree.
>
> - Steve
>
Received on Monday, 8 February 2010 15:36:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT