Re: [TF-LIB] BNode

On 12 Mar 2010, at 16:32, Andy Seaborne wrote:

> 
> 
> On 12/03/2010 1:41 PM, Axel Polleres wrote:
> > 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?
> 
> Not to me .. the syntax is already used for something else in patterns
> and I think that is close enough to expressions.
> 
> >> 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?
> 
> FILTER([]+1)

In my view, that would just result in an error.

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

sorry for being confusing, I didn't mean to imply there was a problem, I meant I had to 
check that back in the grannat, since actually I didn't remember that it was actually 
disallowed :-)

> There's no grammar problem (they even used to be in their in DAWG at one
> point ... as variables).
> 
> >
> > [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
> 
> Blank nodes in patterns are variables over the data.
> 
> Seems more reasonable reading for _:a or [] to be the same in a FILTER.
> 
> Having an explicit generator therefore seems to me a better design
> because the concept of generated term and variable aren't the same.

My point is that this design isn't followed consequently in 
the current Spec either, bnodes in CONSTRUCT being a counter-example.
Frankly, I (*personal view*!) would expect a similar behavior of 
bnodes in expressions as in CONSTRUCTs ... 

I see your point for FILTERs, but also, since they are 
currently forbidden in FILTERs, that would be consistent to treat 
them like in CONSTRUCT there as well.

One should note that - strictly speaking - bnodes aren't really variables in the 
WHERE part, they just "boil down" to variables there by requiring (simple) 
entailment for BGP matching, agree? 

Summarising: I (*chair*) certainly wouldn't be a roadblock to BNODE(), but I see 
two views on this issue, the second being my (*personal*) understanding that treating 
Bnodes BGPs uniformly the same  way as in CONSTRUCTs would not cause harm, but that 
this behavior farily intuitively can be extended to expressions (both in SELECTs and FILTERs).

Now... back to BNODE("string")... thinking about it again, it may have some merit (using the per-result-set semantics) 
for exactly my use case of nesting CONSTRUCTs.

I will explain this in a separate mail on ISSUE-7 (which I still owe for a long time, I realise).

Axel

> 
>         Andy
> 
> >
> >
> >
> >> 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
> >>
> >
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
>

Received on Friday, 12 March 2010 17:00:57 UTC