- From: Lee Feigenbaum <lee@thefigtrees.net>
- Date: Tue, 23 Feb 2010 09:09:37 -0500
- To: Andy Seaborne <andy.seaborne@talis.com>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>
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