Re: function library summary and issues

On Nov 24, 2010, at 19:40 , Gregory Williams wrote:
> 
>>> 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 think that is fine; there is no proper language tag that could be added here

> I have no preference on whether concat of two literals with the same language tag should yield a language tagged literal.
> 

I have a clear preference to keep the language tag there. I see no reason _why_ to drop it; if I use language tags properly I would certainly expect that language tag to be kept.

Ivan


>> What about CONCAT("1"^^xsd:integer, "2"^^xsd:integer), following F&O strictly it would be "12"^^xsd:string I believe.
> 
> I'm a bit freaked out that this is going to cause confusion if + is also being used for string concat (assuming we follow the strawpoll support for overloading +). + would yield addition over xsd:integers, while the CONCAT() syntax would yield "12" with xsd:integers. Something doesn't seem right about that.
> 
>>> Whether the choice is by new URIs for the functions or punning on XSD F&O is part of this decision point.
>>> 
>>> Suggestion:
>>> 1/ Keywords as below.  No dateTime functions.
> 
> I'm mostly indifferent to whether these functions are available as keywords, but if they are I support not having keywords for the dateTime functions.
> 
>>> 2/ sparqlfn: URIs for all function (our namespace and URIs)
> 
> Yes.
> 
>>> 3/ Definition as XSD F&O except work on simple literals as noted.
>>> 4/ Documentation reference XSD F&O for each function.
> 
> I don't have strong feelings one way or another about the xsd:string stuff that's described in F&O. I just want to see support for simple literals with the string functions.
> 
>>>     7.4.3 fn:substring
>>> Two forms /2 and /3
>>> SUBSTRING
>>> Note it's one-based counting and it's (index, length) unlike some languages.
> 
> One-based? Ick! :)
> 
>>> 	3. fn:error
>>> ERROR()
>>> ERROR(string)
> 
> Has this been discussed before? I don't recall what this is meant to do.
> 
> .greg
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf