Re: [TF-LIB] BNode

Hi Andy,

answers below...

On 11 Mar 2010, at 23:43, Andy Seaborne wrote:
> Axel,
> 
> Thank you for responding - as one the people who has been advocating
> functionality in this area to meet the same needs that CONSTRUCT in the
> FROM clause might give, I wanted to understand your position.  At the
> moment, I'm immediately concerned with the syntax but that can't be done
> without knowing what it's for!
> 
> On 09/03/2010 17:08, Axel Polleres wrote:
> >>>> ** 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
> 
> We could, as a special case, but it is making that a special case.
> BNodes are not legal in expressions currently. Providing a function
> seems, to me, more in keeping with the expression design.

Hmmm, on the one hand, yes, I see your point. On the other hand, I am asking 
myself, why/whether this really is an issue. By simply lifting this restriction and
allowing BNODES here with the same behavior we now have in CONSTRUCT, we would have 
a more compact writing, that is "[]" would just amount to what you call "BNODE()".
So, all I say is that it has a bit the flavor of like restricting something which we want 
syntactically and then sneaking it back in through a special function, yes?

> In other words, we'd have to explain ([]+1 AS ?X) as illegal.

Would we? would't that just be resulting in an error and that's that?
i.e., just as  

  BNODE() AS ?X , ?X+1 AS ?Y 

would? 
 
> And FILTER([])
> 
I am not sure about that one... first, let me try to see what that'd do in the current grammar...

[27]   Constraint   ::=   BrackettedExpression | BuiltInCall | FunctionCall

... if I dig down there, it allows arbitrary PrimaryExpressions here,

PrimaryExpression   ::=   BrackettedExpression | BuiltInCall | IRIrefOrFunction | RDFLiteral | NumericLiteral | BooleanLiteral | Var

which indeed don't seem to include BlankNode ... but would it really a burden to allow BlankNodes in Filters?
To understand that, I'd need to know where the restriction not to allow them origins from?

quite obviously, I could get in bnodes into filters with the BNODE() proposal already...
i.e. how would
 {... {SELECT BNODE() AS ?X} FILTER(?X) } 
be 
 different from
 {...  FILTER([]) } 
?

cheers,
Axel



> Agree?
> 
> >
> >>>> BNODE(string)
> >
> >
> > is like _:string in CONSTRUCT, yes?
> 
> That's the question! What's the scope of the label?  Result set, or row?
> 
> row is like _:a in a template.
> 
> This can't be done except in a CONSTRUCT tenplate.
> This feature is, for me, trying to complete the capabilities of SELECT
> to include bnode generation as we are adding IRI and literal generation.
> 
> globals can't be done currently in CONSTRUCT.
> 
> I don't think either allows dynamic list creation but I haven't
> investigated that at all.  I don't think CONSTRUCT can either.  A
> dynamic list,  requires a bnode in one row to be passed to the next row,
> only.
> 
> _:b1 rdf:rest _:b2 .
> _:b1 rdf:first 1 .
> 
> then
> 
> _:b2 rdf:rest rdf:nil .
> _:b2 rdf:first 2 .
> 
> Ideas for clever queries welcome.
> 
> > 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?
> 
> As the person who was, if I recall correctly, advocating the
> functionality, I was looking to you to provide that.  I'm merely doing
> this for that perceived functionality and because the thread had gone
> cold; my only other interest in it is as a sense of completeness.
> 
> >>>> 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?
> 
> What do you mean?
> 
> SELECT *
> {
>     {SELECT (BNODE() AS ?BN) {}}
>     ...
> }
> 
> or
> 
> SELECT *
> {
>     {SELECT (BNODE() AS ?BN) { pattern }}
>     ...
> }
> 
> or somethign else?
> 
> Whether that enables a bnode to span rows in a manner needed to create a
> list, I don't know.  It's not immediately obvious (to me).
> 
> >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
> 
> If there isn't much energy behind this feature, may be we should regard
> it as very-time-permitting and concentrate elsewhere.
> 
>         Andy
>

Received on Friday, 12 March 2010 13:42:16 UTC