[TF-LIB] Finalizing built-ins

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