Re: [TF-LIB] BNode

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.

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

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 Thursday, 11 March 2010 23:44:02 UTC