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

* Markus Lanthaler <markus.lanthaler@gmx.net> [2013-02-18 17:58+0100]
> On Monday, February 18, 2013 5:17 PM, Andy Seaborne wrote:
> > _:0x1234 {
> >       x:assertions x:expressedAs x:triples .
> >     }
> > 
> > is a labelling of a graph (value).
> > 
> > So there is some relationship (not here defined) to the graph and that
> > is in the dataset structure.  In your previous message you talked about
> > "navigate" and "bnode identifiers".  I understood your description as
> > structural navigation of a datastructure from parsing.  Was that right?
> 
> Yes.
> 
> 
> > You get would get from  _:0x1234 to the graph by looking in the dataset
> > structure (which is a map) if bnodes were allowed.  At this level, of
> > concrete graph structures, bnode label or a IRI string would serve the
> > same purpose using e.g. relative URIs (and a per-parse random base URI
> > making it only findable locally).  It's a local structural identifier.
> 
> Yes. Would that also be the case if bNodes would *not* denote the graph they
> label? As I understand it, if bNodes wouldn't denote the graph, you couldn't
> look up a graph labeled with a bNode ID in a dataset because you wouldn't
> know if that bNode ID denotes that graph or not. Is that correct?

Aha! Would "does not formally denote the graph" mean there's no usable
mapping from label to graph? I believe we can factor out whether
bnodes are permitted as graph labels as this question is arises in
either case.


> If you have the following dataset:
> 
> {
>   _:b1 x:signature "... signature ..." .
> }
> _:b1 {
>   ... some triples ...
> }
> 
> Do the two _:b1 above refer to the same, i.e., the named graph? Does this
> mean that "... signature ..." is the signature of the graph labeled with
> _:b1? Or could it be that the signature is about something completely
> different?

Yeah, it'd really be useless if the system were permitted to have _:b1
(or even <http://a.example/graphs/b1>, for that matter) refer to
something other than the graph which was paired with that signature.
Operationally, I can't imagine this happening. I'm sure that every
test case and every implementer will make sure that parsing that
dataset as a Trig document or constructing it with SPARQL or RIF or
SPIN or OWL will preserve "graph integrity". (Note that this "graph"
is a superset of an RDF graph.)

I don't know how to utter that in the semantics doc 'cause I don't
know what "denotes" means. The semantics that we're trying to avoid
implying is that dataset1's graph <foo> is the same as dataset2's
graph <foo>. (Some systems may make such a promise, but it's not
generally required of e.g. deployed linked data or SPARQL systems.)
All the semantics has to capture is that for a given dataset, there is
a map from graph label to graph. I suspect we don't want to go a
step further and say that the mapping is 1:1 because of:

    {
      <b1> dc:author "Bob" .
      <b2> dc:author "Bob" .
      <b1> owl:sameAs <b2> .
    }
    <b1> { ... some triples ... }
    <b2> { ... some triples ... }

I suspect that saying

    Within a dataset, a graph node label denotes a graph.
   Graph node labels may appear as subjects or objects in graphs.

would do the trick, but again, I don't understand what drove us from
"denotes" to "is paired with".


> RDF-CONCEPTS says:
> 
>    Despite the use of the word "name" in "named graph", the
>    graph name does not formally denote the graph. It is merely
>    syntactically paired with the graph. RDF does not place
>    any formal restrictions on what resource the graph name may
>    denote, nor on the relationship between that resource and the
>    graph.
> 
> I read this as in the example above you wouldn't know to what the signature
> applies. It may or may not be the graph. Manu's use case requires that it is
> the graph to which the signature applies. That's the reason why I argued for
> "bNodes MUST denote the graph".
> 
> 
> Thanks,
> Markus
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 

-- 
-ericP

Received on Monday, 18 February 2013 18:08:24 UTC