Re: [TF-LIB] IN operator

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
>