Re: Questions about Update 1.1

On 18 Oct 2009, at 15:05, Seaborne, Andy wrote:
[snip]
> I agree that the use of <_:..> is making an assumption that need not  
> be true everywhere.
>
> For SPARQL-1/Query, the WG decided not to mention it.  But with an  
> update language I think we need to face this again - at the very  
> least, decide explicitly not to cover it although personally I think  
> it does need something.
>
> We need <_:InternalId> but also a way to get internal names.  BNode  
> labels in result sets can be interpreted as scoped to the result set  
> only - i.e. like Turtle syntax _:a.
>
> If we had function  BNODE_REF(?x) then a query could get it and it  
> would allow a system to know a reference had been handed out,  
> allowing a separation between the internal ID and the reference let  
> out.  A processor can track the references and know what's been  
> revealed and what hasn't.  The released ref and the internal id may  
> be different or they may be the same - different system may choose  
> to do things either way.
>
> BNODE_REF returns either a string or a dubious URI of the form _:.....
>
> BNODE_REF or sparql:bNodeRef.  Need not be a keyword.  If give names  
> to all the operators anyway (e.g.. sameTerm), we are going to create  
> a namespace.

Another option would be something like
   SKOLEMIZE(?x)
where the return value will be some URI that has some persistence, or  
a type error. The function could have a more friendly name, obviously.

The gets round the problem where you have things like
   SELECT ?knows WHERE { <uri> foaf:knows ?knows }
and you don't know head of time whether ?knows will be a URI or bNode.  
It would turn a bNode into a persistent identifier, and leave URIs as- 
is.

- Steve

Received on Sunday, 18 October 2009 15:00:39 UTC