Re: ACTION summary

CONSTRUCT, like SELECT and BNODE() approaches, can only generate new 
bNodes for each solution matching the pattern, and can't generate new 
bNodes that span solutions  (and hence span CONSTRUCT template 
instantiations). Bnodes in the graph can span instantiations.

e.g. You can't build a new arbitrary length list based on one element 
per pattern match success.

 Andy

On 24/12/2009 17:32, Axel Polleres wrote:
> Just to follow up quickly, I had exchanged some mails with the chileneans on the issue and they also seemed to favor
> CONSTRUCT subqueries for some use cases... I wanted to  try to reformulate these with subselects to see how/whether it is more complicated to write them one or the other way. I was hoping to complete this over christmas, when I find some quiet hour...
>
> for the moment, merry christmas, all together,
>
> Axel
>
> On 23 Dec 2009, at 18:43, Lee Feigenbaum wrote:
>
>> Andy Seaborne wrote:
>>>
>>>
>>> On 22/12/2009 11:59, Axel Polleres wrote:
>>>>> Has this ever been advocated or is it just speculation?
>>>>
>>>> What we have in the notes to this action is the following:
>>>>
>>>> "2009-11-02 23:14:05: [SteveH_]: this should probably do the same
>>>> thing as CONSTRUCT, i.e. mint new bnodes for each solution"
>>>
>>> Err, in context we have:
>>> ----------
>>> ACTION: Axel to followup with Chilleans re: not including sub-constructs
>>> in FROM clauses ←
>>>
>>> Trackbot IRC Bot: Created ACTION-133 - Followup with Chilleans re: not
>>> including sub-constructs in FROM clauses [on Axel Polleres - due
>>> 2009-11-09]. ←
>>>
>>> 22:56:56<LeeF>  discussion that Axel seems to be the main - perhaps sole
>>> - proponent of sub-constructs in FROM clauses in the WG
>>>
>>> discussion that Axel seems to be the main - perhaps sole - proponent of
>>> sub-constructs in FROM clauses in the WG ←
>>>
>>> 23:03:41<AxelPolleres>  Lee: Would " SELECT ( _:b1 AS ?blank) ... "
>>> solve Axel's use case?
>>>
>>> Lee Feigenbaum: Would " SELECT ( _:b1 AS ?blank) ... " solve Axel's use
>>> case? [ Scribe Assist by Axel Polleres ]
>>> ----------
>>>
>>>> I was thinking of converting it into an issue in the light of that we
>>>> haven't got any other mechanism to mint
>>>> bnodes in subselects so far.
>>>
>>> Sure - but do I take it you are advocating this ability?  No point
>>> raising issues about things no one is advocating.  The issue is not
>>> SELECT (_:b ...) but the underlying need?
>>
>> This got briefly mentioned at the TC, but yes, if I understand correctly
>> Axel has at least one FOAF-related use case (the details of which escape
>> me at the moment) that relies on minting new blank nodes.
>>
>>> I thought that would be done as part of TF-LIB as we have discussed
>>> generators for RDF terms before :  BNODE(), URI() and LITERAL().  Inline
>>> syntax _:b1 is the worst of all worlds because it has different meaning
>>> in different places.
>>
>> I think that's a very reasonable approach, personally.
>>
>> Lee
>>
>>>
>>>      Andy
>>>
>>>>
>>>> Axel
>>>
>>>
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Received on Thursday, 24 December 2009 18:05:35 UTC