Re: [TF-LIB] Finalizing built-ins

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