RE: Problem with auto-generated fragment IDs for graph names

On Sunday, February 17, 2013 5:41 PM, Gregg Kellogg wrote:

> It seems to me that the problem is that a BNode identifier used as a
> graph name seemingly _must_ denote the graph. Many (most) uses of IRIs
> as graph names also denote the graph, this just seems like common
> sense. The fact that some uses of IRIs for graph names do not denote
> the graphs is allowed, because the group could not reach consensus, but
> perhaps a future WG would be able to go this extra mile. If this is the
> case for IRIs, then I'm not sure why you couldn't say that a BNode
> identifier doesn't necessarily denote the graph either. In fact, if you
> use Andy's proposed inference rules, if the IRI didn't denote the
> graph, then neither would the inferred BNode.

If the bNode (identifier) doesn't denote the graph, how would you be able to
retrieve the graph? bNode identifiers are a serialization artifact and might
change at any point in time, i.e., they are "neither persistent nor
portable" [RDF-CONCEPTS]. If I can't "navigate" to the graph without
explicitly using the bNode identifier I wouldn't be able to access it
anymore. I think that's the reason why bNodes MUST denote graphs if we
decide to introduce this mechanism.

Quite frankly, I find the names-but-doesn't-denote compromise quite
confusing.


> It's clear to me that we have a mechanism for identifying things
> (nodes, graphs) and that making up a new thing, because we've decided
> to be intentionally weak in having graph names denote the graphs is
> just silly.

+1


> Let's just agree that we won't open the door to graph name denotation,
> and will maintain this illusion for BNode graph names too. As I recall,
> a referencing specification could always say that graph names _do_
> denote the graphs, for the purposes of that specification.

I'm afraid that won't work.



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 18 February 2013 12:48:52 UTC