Re: function library summary and issues

On 24/11/10 18:40, Gregory Williams wrote:
> On Nov 24, 2010, at 1:12 PM, Steve Harris wrote:
>
>> On 2010-11-24, at 15:20, Andy Seaborne wrote:
>>
>>> Practicality suggests simple literals are important.
>>> We can overlay on XSD F&O so for example:
>>>
>>> CONCAT("a"^^xsd:string, "b"^^xsd:string) ->  "ab"^^xsd:string
>>> CONCAT("a", "b") ->  "ab"
>>> CONCAT("a"^^xsd:string, "b") ->  "ab"^^xsd:string (?? choice point)
>
> I think I'd want this to produce a simple literal, but as Steve says, without experience here it's hard to know.
>
>>> CONCAT("a"@en, "b"@fr) ->  error? (choice point [*])
>>> CONCAT(str("a"@en), str("b"@fr)) ->  "ab"
>>>
>>> [*] lang tag support in comparisons etc is not required by base SPARQL so it's an error. The question is whether to provide guidance to implementations that wish to provide it.
>>
>> Re. [*], for impl's which choose to implement it, I would favour "ab" as a result. We use language tags quite a bit, and though we haven't been able to concatenate them up to now, I would like/expect CONCAT("a"@en, "b"@fr) ->  "ab". Less straightforward is CONCAT("a"@en", "b"@en), should that be "ab"@en, or "ab". Dropping the lang tag in all cases seems fine to me.
>
> I also would prefer CONCAT("a"@en, "b"@fr) ->  "ab". I have no preference on whether concat of two literals with the same language tag should yield a language tagged literal.
>
>> What about CONCAT("1"^^xsd:integer, "2"^^xsd:integer), following F&O strictly it would be "12"^^xsd:string I believe.

If we adding in simple literal and, maybe, language tags, we are 
defining a new function.  I'm not keen for SPARQL to have implicit cast 
because SPARQL doesn't do it on, say, numeric operations.

CONCAT works on simple literals and xsd:string.
(these are semantic equivalent by RDF-MT rules xsd1a and xsd1b).

If any of the arguments are simple literals, the result is a simple literal.

If all xsd:string then returns a xsd:string.

 From what I have seen of RDF applications, simple literals are more 
common than xsd:strings.  I could support a fixed return of simple 
literal for xsd:string but I think it will be confusing for applications 
that use xsd:string exclusively.

If we add language tag handling (note: SPARQL 1.0 does not require 
language tag handling for, e.g., "<").  That is a good argument for not 
including mandatory support for language tags.

I suggest we do not require language tag handling in this specification.

If we require it, it seems natural to me to have:

   CONCAT("a"@en, "b"@en) -> "ab"@en
   CONCAT("a"@en, "b"@fr) -> "ab"  (or error)
   CONCAT("a"@en, "b") -> "ab"  (or error)

Working proposal:
   CONCAT is n-ary, minimum of 2 arguments.
   CONCAT(xsd:string, xsd:string) -> xsd:string
   CONCAT(simple literal, simple literal) -> simple literal
   CONCAT(xsd:string, simple literal) -> simple literal

no specification for lang tags (can be added as an extension).

	Andy

Received on Saturday, 27 November 2010 18:49:19 UTC