Re: [TF-LIB] BNode (was: Finalizing built-ins)

>>> ** BNODE() -> fresh blank node every call.

is like [] in a CONSTRUCT, yes? Do we really need the function, or could we simply allow 
  []
in a project expression?

e.g. SELECT [] as ?X

>>> BNODE(string) 


is like _:string in CONSTRUCT, yes? whereas it makes sense in CONSTRUCTs to create correlations between blank nodes, 
I am not entirely sure it is needed in SELECTs... we don't really have correlation, which couldn't just be made explicit by 
reusing the same variable ... What I mean is: What expressivity do we gain by BNODE("label")?
Could someone give an example?

>>> Do we also way bnodes scoped to the whole result set?
>>> Replace the meaning of BNODE("label") or have another form?

Well, I'd expect that (correct me if I am wrong) blank nodes per result set could be 
done by nested queries, or no? At least, that was the point for me suggesting to consider nested CONSTRUCTs, 
since by nesting/modularisation one could do exactly that.

> BNODE("label", boolean) with "true" for result set (and BNODE/1 being default true).
> 
> BNODE("A", false) and BNODE("A", true) are different bNodes.

That workaround seems a bit "hacky" to be honest, and said the above, 
I am not convinced this is strictly needed. Other opinions? Examples?

Axel

On 23 Feb 2010, at 14:26, Andy Seaborne wrote:
> On 23/02/2010 2:09 PM, Lee Feigenbaum wrote:
>> 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)?
> 
> It's actually illegal currently (phew!) because you can't have a constant bnode in an expression.
> 
> The general case of:
> 
> ?x = _:a  or <_:a>
> SELECT (?x = BNODE("a") AS ?match)
> 
> I suggest should be false.
> 
> BNODE("a") does not create a bnode with that string - it creates a new bnode distinct from all other bnodes except those created by BNODE("a").
> 
> So the bnode from the data can't the same as the bnode from BNODE (any form).
> 
> Steve wrote:
> >
> > 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.
> 
> As an "illegal" URI like <_:label>?
> 
> I support that.
> 
> Alternative is to register a URI scheme.  Or purloin some urn: scheme like urn:x-bnode:label.
> 
> >
> >> Replace the meaning of BNODE("label") or have another form?
> >
> > We maybe need both forms. Axel has some usecase IIRC?
> 
> Yes - I think we do indeed need both.  No idea how just at the moment how to express in syntax.
> 
> BNODE("label", boolean) with "true" for result set (and BNODE/1 being default true).
> 
> BNODE("A", false) and BNODE("A", true) are different bNodes.
> 
> ----
> 
> Because you can't pass a bnode from one row to another, I don't think you can construct lists over result rows under any proposal so far.  Is this an issue?
> 
> 	Andy
> 
>

Received on Tuesday, 9 March 2010 17:09:29 UTC