Re: Possible Errata re CONCAT and COALESCE for SPARQL 1.1 Query

On 21 Aug 2013, at 18:09, Andy Seaborne <andy@apache.org> wrote:

> On 21/08/13 13:05, james anderson wrote:
>> good afternoon;
>> 
>> On 21 Aug 2013, at 11:29 AM, Steve Harris wrote:
>> 
>>> On 20 Aug 2013, at 23:42, Rob Vesse <rvesse@dotnetrdf.org
>>> <mailto:rvesse@dotnetrdf.org>> wrote:
>>> 
>>>> I have some comments around the definitions of CONCAT and COALESCE
>>>> that have originated from private discussions with a user and may
>>>> lead to additional errata for the SPARQL 1.1 Query specification
>>>> 
>>>> ---
>>>> 
>>>> Starting with Section 17.4.3.12 CONCAT
>>>> (http://www.w3.org/TR/sparql11-query/#func-concat) it states the
>>>> following:
>>>> 
>>>>> The |CONCAT| function corresponds to the XPath fn:concat
>>>>> <http://www.w3.org/TR/xpath-functions/#func-concat> function. The
>>>>> function accepts string literals as arguments.
>>>> 
>>>> If you follow the link to the fn:concat definition it states the
>>>> following:
>>>> 
>>>>> Accepts two or more |xs:anyAtomicType| arguments
>>>> 
>>>> However the grammar allows zero or more through use of the
>>>> ExpressionList production and so various implementations (including
>>>> my own) happily allow zero or one arguments to be used.
>>>> 
>>>> In this case the specification should really explicitly
>>>> allow/disallow those cases.  If the intention was to fully align with
>>>> fn:concat then a minimum or two arguments should be required, if
>>>> zero/one should be permitted then the spec should note this deviation
>>>> from the XPath definition.
>>> 
>>> Yes, agreed. My preference would be to allow zero or one - zero being
>>> an error(?), and one returning the string of the argument.
>> 
>> if no argument is supplied, a zero length string would be better.
> 
> I agree : zero=> "" and one => the one argument.
> 
> This would make CONCAT like GROUP_CONCAT.

OK, that would make sense then.

What does STR() return? If that's "" as well, then I think it's pretty clear that's the right answer.

> It is worth defining as cases
> 
> CONCAT() -> ""
> CONCAT("abc") -> "abc"
> and the fn:concat for the other cases so as not to redefine "fn:concat"
> 
> GROUP_CONCAT already gets this right.
> 
>>> This may help code that generates queries.
>>> 
>>>> ---
>>>> 
>>>> Then we have Section 17.4.1.3 COALESCE
>>>> (http://www.w3.org/TR/sparql11-query/#func-coalesce) where the
>>>> function definition is given as follows:
>>>>> 
>>>>> The |COALESCE| function form returns the RDF term value of the first
>>>>> expression that evaluates without error. In SPARQL, evaluating an
>>>>> unbound variable raises an error.
>>>>> 
>>>>> If none of the arguments evaluates to an RDF term, an error is
>>>>> raised. If no expressions are evaluated without error, an error is
>>>>> raised.
>>>>> 
>>>> Between this and the examples it is implied that COALESCE requires at
>>>> least one argument yet again the grammar allows for zero arguments.
>>>> 
>>>> Obviously zero arguments means COALESCE will always give an error so
>>>> it is a pointless expression to write yet legal per the grammar, so
>>>> again it would be nice if the specification explicitly stated this as
>>>> being allowed/disallowed.
>>> 
>>> I don't think this requires an erratum. As far as I remember, SPARQL
>>> doesn't really have a concept of "disallowing" expressions that can be
>>> written in the grammar, other than it being an error, and as you've
>>> seen it's clearly an error by the description of the function.
> 
> Agreed.
> 
>>> 
>>> Cheers,
>>>    Steve
>> 
> 
> 	Andy
> 

-- 
Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ

Received on Thursday, 22 August 2013 09:45:56 UTC