W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2010

Re: function library summary and issues

From: Ivan Herman <ivan@w3.org>
Date: Sun, 28 Nov 2010 06:22:21 +0100
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <CE69ED6C-83C7-47B3-ABF0-A8066987CECF@w3.org>
To: Gregory Williams <greg@evilfunhouse.com>

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.


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

Received on Sunday, 28 November 2010 05:20:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:02 UTC