RE: Questions about Update 1.1



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Paul Gearon
> Sent: 16 October 2009 19:34
> To: Gregory Williams
> Cc: Steve Harris; public-rdf-dawg@w3.org Group
> Subject: Re: Questions about Update 1.1
> 
> On Fri, Oct 16, 2009 at 2:02 PM, Gregory Williams <greg@evilfunhouse.com>
> wrote:
> > On Oct 16, 2009, at 11:35 AM, Steve Harris wrote:
> >
> >> Yes, agreed. A similar thing happens in 4store, but for different reasons.
> >> The only promise we make is that if you get a bNode ID out in SPARQL
> >> results, then you can reuse that ID in <_:$id> until you do an update on
> the
> >> graph it came from, at which time it may no longer be valid.
> >
> > Thinking ahead here a bit, would it be possible for the implementors of
> such
> > things to define an IRI representing the logic here? In this case, I'd like
> > an IRI I could use with sd:feature for "if you get a bNode ID out in SPARQL
> > results, then you can reuse that ID in <_:$id> until you do an update on
> the
> > graph". Obviously this is outside the scope of the WG, but think it would
> be
> > great to have such things earlier rather than later when it comes to
> > explaining the benefits of service descriptions.
> 
> While convenient, this may not be practical. I suspect that many
> implementations use IDs that consistently map to internal information,
> but this is not required. That could require session information in
> order to maintain your mapping. Also, you 're implying that you can
> expect the IDs to change if the graph changed, but what if someone
> else is modifying the graph between you looking at the bnode and
> wanting to re-use the ID for it?
> 
> Regards,
> Paul Gearon

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.

There would be a concept of "no long valid" either because the process has a notion of session (e.g. the BNODE_REF encodes a session id), or some incompatible event occurred (bnode renumbering).  We don't need to define the events, just say they can occur. The processor can then bounce the request.

I suggest a WG note that describes the practice.  That makes it clearly not mandatory. It would have some value in documenting an approach and the service description can name the feature.

 Andy

Received on Sunday, 18 October 2009 14:06:32 UTC