W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2013

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

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 19 Feb 2013 00:01:28 -0600
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, 'Andy Seaborne' <andy.seaborne@epimorphics.com>, public-linked-json@w3.org, 'RDF-WG' <public-rdf-wg@w3.org>
Message-Id: <AF25B164-27B8-4539-BD6E-332BA76D6AC9@ihmc.us>
To: Eric Prud'hommeaux <eric@w3.org>

On Feb 18, 2013, at 12:07 PM, Eric Prud'hommeaux wrote:

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

No. It means that when the IRI is used in an RDF triple, what it refers to might not be what you get by following the label-to-graph mapping. 

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

? What do you mean by "graph integrity"? That sounds like some kind of syntactic condition, but the issue isn't anything to do with syntax. It isn't something that any kind of parser could possibly fix. 

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

<knocks head repeatedly against wall>

A denotes B =
A refers to B (except we don't mean 'refer' as in "dereferencing a pointer") = 
A names B (except "name" as in "named graph" has been defined to mean something else) =
When you use A to talk about something, you are talking about B

Got it now, Eric? 

> The semantics that we're trying to avoid
> implying is that dataset1's graph <foo> is the same as dataset2's
> graph <foo>.

Are we? That is news to me. But this surely isn't the main issue here. 

>  (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 ... }

How is this a problem? The IRIs in the first two triples have nothing to do with their use as graph labels immediately below. You could have written this:

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

and it would have the same effective meaning. There is nothing in the RDF specs which could lead any reader of your example to know that b1 refers to a graph. 

> 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

Not really, since there is no idea in RDF of denoting something "in a dataset" or indeed "in" anything. That would require RDF to be some kind of context logic, where the same name can refer to one thing in one context and something else in a different context. RDF just isn't designed that way. 

Several people have suggested it should be. For example:

http://www.w3.org/2004/12/rules-ws/paper/98/ (1998)
http://www.ninebynine.org/RDFNotes/RDFContexts.html (2000)
http://www.slideshare.net/PatHayes/rdf-with-contexts (2012)

But the WG has not elected to take up this idea, so RDF right now does not have contexts. 

> , but again, I don't understand what drove us from
> "denotes" to "is paired with".

See previous comment. 


IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 19 February 2013 06:02:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:36 UTC