- From: Steve Harris <steve.harris@garlik.com>
- Date: Mon, 8 Feb 2010 14:16:59 +0000
- To: Ivan Mikhailov <imikhailov@openlinksw.com>
- Cc: Andy Seaborne <andy.seaborne@talis.com>, SPARQL Working Group <public-rdf-dawg@w3.org>
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
9AD
Received on Monday, 8 February 2010 14:24:18 UTC