Re: [TF-LIB] IN operator

On 8 Feb 2010, at 13:28, Ivan Mikhailov wrote:

> On Mon, 2010-02-08 at 11:50 +0000, 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:
> I mean a new function, say, SAMETERM_IN(needle, value1, value2,
> value3...).
> With some composite datatype like array or list or dictionary it might
> be SAMETERM_IN(needle, haystack), but we do not have one.

Oh, I see. I misunderstood what you meant.

An alternative would be a generic list predicate application function  
like PREDICATE(sparql:sameTerm, needle, value1, value2, ...) ->  
xsd:boolean, but that's maybe a bit abstract for SPARQL as it stands.

>>> 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.
> Fine. The simpler the better. From my perspective, it's not a  
> problem if
> a feature is not in spec even if we've implemented it already. A  
> problem
> might appear only if a feature is made by two vendors in two different
> ways.

The only major contentious issues I could see would be the number of  
columns projected (SQL only allows one right?) and whether there's {}s  
or not.

- Steve

Steve Harris, Garlik Limited
2 Sheen Road, Richmond, TW9 1AE, UK
+44 20 8973 2465
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  

Received on Monday, 8 February 2010 14:24:18 UTC