- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 23 Feb 2010 13:33:10 +0000
- To: Andy Seaborne <andy.seaborne@talis.com>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
On 23 Feb 2010, at 13:14, Andy Seaborne wrote: > In an effort to progress the syntax issues ... > > http://www.w3.org/2009/sparq/wiki/Design:FunctionLibrary#SPARQL_specific > > We have some built-in functions proposed: > > ** BNODE() -> fresh blank node every call. > > ** BNODE(string) -> same blank node as other use of BNODE(string) > > Scope is per binding (row) so > BNODE("a") is like _:a in CONSTRUCT templates. > > Do we also way bnodes scoped to the whole result set? Ah, maybe, I think I'd thought that's what this function did. Result- set scoped bNodes are not something you can mint currently. Related: do we have any consensus around a skolemisation function? SKOLEMISE(?bnode) -> URI. I'm not sure how many people want / could support such a thing. > Replace the meaning of BNODE("label") or have another form? We maybe need both forms. Axel has some usecase IIRC? > ** LITERAL(str) -> > > This is a restricted STR(x) > I propose dropping LITERAL/1 > > ** LITERAL(str, IRI) > > This is a dynamic cast - currently, casts are done as function calls > of one argument so the datatype IRI is fixed at parse time. > > This would be possible: > ?str = "IV" > ?dt = my:RomanNumeral > > then a call of > LITERAL(?str , ?dt) ==> "IV"^^my:RomanNumeral > > > This one is a special case of calling a function dynamically (the > IRI is not known at parse/compile time). > > We could support dynamic function call. Possibilities include: > > ?function(?arg1, ?arg2, ....) > CALL(?function, ?arg1, ?arg2, ....) Getting perl flashbacks. And not in a good way :) I can imagine this playing havoc with peoples extension function implementations, and security models. > Then LITERAL(str, IRI) is not needed: > > ?dt(?str) > > and it follows the form of: > > xsd:integer(?str2) We'd still need a function for language tags though, right? Could be a 2-arg form of STR() I guess. > ** LITERAL(str, string) -> literal with language tag > > This is the one remaining literal constructor. I don't have a good > name for it. Even if we have LITERAL(?str, ?datatype) I think we > need a different name because two nearly identical functions are > just switching on the type of their second argument. I don't see a > UC to make that useful - I do see possible confusion as people do > mix strings and IRIs. > > We already have LANG(?lit) built-in meaning get the language tag. > > Suggestions for a name? > > LANG(?str, ?langTag) > LITERAL(?str, ?langTag) > other? Prefer STRDT(?str, ?dt) and STRLANG(?str, ?lang) or something similar, for consistency. Agreed that making this polymorphic is maybe not a good idea. No strong feelings though. > is possible. My mild pref is LANG/2. > > ** IN > > I suggest IN(arg,....) and NOT IN(arg,....) Full syntax would be "val [NOT] IN (arg,...)" - right? IN (...) on it's own would not be legal. > ** IF > Yes +1, if it's a ternary IF(condition, value-if-true, value-if-false) type if. > ** COALESCE > Yes +1 > BETWEEN has not had much support. -1 to BETWEEN > If this is OK, some TF-LIB tasks remaining are: > > 1/ Make URIs for all built-ins > 2/ Choose subset of F&O as the common library. > 3/ Test cases > 4/ Document built-ins in (what was) sec 11. > > Is it worth splitting out sec 11 which is quite large already? Splitting out to? - Steve -- Steve Harris, Garlik Limited 2 Sheen Road, Richmond, TW9 1AE, UK +44 20 8973 2465 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 Tuesday, 23 February 2010 13:33:40 UTC