Re: [TF-LIB] BNode

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)

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

???

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.

	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 16:33:11 UTC