Re: function library summary and issues

On 2010-11-27, at 18:48, Andy Seaborne wrote:
> 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.

Given how hard it is to implement SPARQL 1.1, personally I feel that a requirement to handle language tags is irrelevant. OTOH, it could be the straw that breaks the camel's back, but I doubt it.

> 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)

There are legitimate cases where you might have some literals without tags, and some with, and want to concatenate them, without having loads of logic.

Some terms are often common across all languages used by an application, e.g. trademarks, and technical terms.

> 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).

Preference for requiring it. Makes testing easier, better for users to be able to expect support.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  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 Sunday, 28 November 2010 15:15:26 UTC