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

Re: [TF-LIB] IN operator

From: Steve Harris <steve.harris@garlik.com>
Date: Mon, 8 Feb 2010 14:16:59 +0000
Cc: Andy Seaborne <andy.seaborne@talis.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <3112C712-9340-4797-8DAA-3BEF5E4E1630@garlik.com>
To: Ivan Mikhailov <imikhailov@openlinksw.com>
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: http://www.w3.org/TR/rdf-sparql-query/#func-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  http://www.garlik.com/
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:01 UTC