- From: Paul Gearon <gearon@ieee.org>
- Date: Fri, 16 Oct 2009 14:33:49 -0400
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: Steve Harris <steve.harris@garlik.com>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
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
Received on Friday, 16 October 2009 18:34:26 UTC