W3C home > Mailing lists > Public > public-rdf-wg@w3.org > February 2013

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

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Fri, 15 Feb 2013 19:38:42 +0000
Message-ID: <511E8EC2.2040800@epimorphics.com>
To: RDF-WG <public-rdf-wg@w3.org>

On 15/02/13 16:59, Pat Hayes wrote:
> But let me ask you about this example. You are assuming here that the
> _:doc1 in the triple in the default graph, and the _:doc1 used as a
> graph label, refer to the same thing, which is the moon-green-cheese
> graph, right? What is interesting here is that this assumption seems
> inevitable when we have a bnode involved, as here, but (the WG has
> decided) it cannot be assumed when an IRI is used. So this data:
> {ex:doc1 :author "Bob" }
 > ex:doc1 {:TheMoon :madeOf :greenCheese }
> does *not* entail that Bob is the author of the graph (since
> 'ex:doc1' might denote something else, which is what the default
> graph would be about, and not about the graph.) So this actually
> gives us a new, Manu-independent, reason to allow bnodes as graph
> labels in datasets: they provide exactly the missing expressivity
> that is needed to have the default graph act as genuine metadata.

I don't understand this bit - why do bNodes force a specific 
relationship between graph label and graph in a way that URIs don't?

If ex:docs is the "location has state" relationship of URI to graph, 
surely _:x can have that relationship.

One simple entailment design would be:

{ex:doc1 :author "Bob" }
ex:doc1 {:TheMoon :madeOf :greenCheese }


{_:x :author "Bob" }
_:x {:TheMoon :madeOf :greenCheese }

Received on Friday, 15 February 2013 19:39:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:25 UTC