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

* Markus Lanthaler <markus.lanthaler@gmx.net> [2013-02-18 13:48+0100]
> 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.

In
  { _:post1 a sioc:Post .
    _:post1 sioc:topic "RDF is easy" .
    _:post1 sioc:reply _:post2 .
    _:post2 a sioc:Post" .
    _:post2 sioc:topic "Named graphs are easy" . }

the bnode _:post1 serves as an identifier for some node in the graph. It
is neither controversial nor complex that systems must maintain the
integrity of the graph. After parsing, they can throw the names away;
they can replace them with new names, they can simultaneously rename
_:post1 to _:post2 and _:post2 to _:post1. This appears to have been one of
the more trivial points of the RDF model.

Why would our integrity constraints be different for graph labels as
opposed to a garden-variety node labels?
  _:post1 {
      x:assertions x:expressedAs x:triples .
  }

Just as with bnodes in graphs, your system is responsible for
preserving the fact that the thing which had a sioc:topic "RDF is
easy" also has some contents which say that RDF statements are
triples. We can access this information without knowing how the
system keeps track of this:
  SELECT ?expression
   WHERE {
       ?p a sioc:Post .
       GRAPH ?p {
           x:assertions x:expressedAs ?expression
       }
   }
The system can also save this info in a format which other systems
can consume:
  { _:0x1234 a sioc:Post .
    _:0x1234 sioc:topic "RDF is easy" .
    _:0x1234 sioc:reply _:0xabcd .
    _:0xabcd a sioc:Post" .
    _:0xabcd sioc:topic "Named graphs are easy" . }
  _:0x1234 {
    x:assertions x:expressedAs x:triples .
  }


> 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
> 
> 

-- 
-ericP

Received on Monday, 18 February 2013 13:55:09 UTC