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

Re: mergeg in current Semantics ED

From: Peter Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 8 Mar 2013 10:52:37 -0800
Message-ID: <CAMpDgVwnF8yTkqwYriGXMuq2nuU_SbzgtVi8_pxL8cGkzuSUxQ@mail.gmail.com>
To: Pat Hayes <phayes@ihmc.us>
Cc: Antoine Zimmermann <antoine.zimmermann@emse.fr>, RDF WG <public-rdf-wg@w3.org>
How is this all supposed to work in practice?

Does it mean that an implementation has to do something special for bnodes
that cross between graphs?

Or is this just something to make the semantics work right, and has no
external consequences?  If this is not the case, and I think that it may
not be, then the WG should discuss the issue.

A different way to go would be to just have interpretations map b-nodes
directly.  This would treat bnodes as skolems - the only difference between
a bnode and a skolem is that a bnode *cannot* escape into the wild.


On Fri, Mar 8, 2013 at 10:43 AM, Pat Hayes <phayes@ihmc.us> wrote:

> Ah. Yes, now I see your (and Antoine's) point. Antoine, sorry I was slow.
> I think we need a new idea to handle this.
> Observation: a bnode scope might extend over several graphs, but a graph
> cannot cross bnode scopes. So bnode scopes are a 'larger' syntactic unit
> than graphs. Given a bnode scope, the set of triples contained in it is an
> RDF graph, call it the /scope graph/. Every RDF graph is a subgraph of some
> scope graph.
> A graph is /complete/ (/saturated/? /scoped/? /whole/? /coherent/?
> /molecular/?) when, if it contains a bnode, then it contains all triples in
> the scope graph which contain that bnode. That is, for each bnode b in the
> scope, it either does not contain b, or it contains every triple containing
> b.
> Ground graphs and scope graphs are always complete. A union (= merge) of
> complete graphs is complete.  Any set of complete graphs entails its union.
> Antoine's example shows that this may not be true for incomplete graphs.
> Comments, before I start editing?
> Pat
Received on Friday, 8 March 2013 18:53:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:11 UTC