Re: [TF-LIB] Finalizing built-ins

Hi Andy,

Thanks - my thoughts are below.

On 2/23/2010 8:14 AM, 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 blan k 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?

I don't have a strong feeling for this as I tend to shun bnodes anyway 
:) - but I do have a question: if BNODE("a") had result-set scope, is

SELECT (_:a = BNODE("a") AS ?match) ... true or false (or illegal)?

> ** LITERAL(str) ->
>
> This is a restricted STR(x)
> I propose dropping LITERAL/1

In the absence of use cases, yes, indeed.

> ** 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, ....)

I don't think dynamic function calls are a good idea at this point. 
Mainly because I don't think we really have time to consider the issue 
in any significant depth.

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

I have a mild preference to rename LITERAL(STR, IRI) as 
TYPED_LITERAL(STR, IRI) and to rename LITERAL(STR, STR) as PLAIN_LITERAL 
or LANG_LITERAL.

I am not a big fan (just personal preference) of having LANG act as both 
accessor and constructor depending on the arguments.

> ** IN
>
> I suggest IN(arg,....) and NOT IN(arg,....)

OK, no strong feeling.

> ** IF
> Yes
>
> ** COALESCE
> Yes

Indeed.

> BETWEEN has not had much support.

Happy to leave it out and let implementers slug it out.

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

Again, just my personal preference, but I'd rather keep it where it is 
in the document. I tend to prefer one-stop specs vs. more modular specs.

lee

>
> Andy
>
>

Received on Tuesday, 23 February 2010 14:17:10 UTC