- From: Andy Seaborne <andy.seaborne@talis.com>
- Date: Tue, 23 Feb 2010 13:14:28 +0000
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
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? Replace the meaning of BNODE("label") or have another form? ** 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, ....) Then LITERAL(str, IRI) is not needed: ?dt(?str) and it follows the form of: xsd:integer(?str2) ** 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? is possible. My mild pref is LANG/2. ** IN I suggest IN(arg,....) and NOT IN(arg,....) ** IF Yes ** COALESCE Yes BETWEEN has not had much support. 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? Andy
Received on Tuesday, 23 February 2010 13:15:00 UTC