Re: Attempt to provide semantics to Sandro's named graph design

On Wed, 2012-04-11 at 10:35 +0200, Ivan Herman wrote:
> On Apr 11, 2012, at 24:49 , Sandro Hawke wrote:
> 
> > On Tue, 2012-04-10 at 15:42 +0200, Ivan Herman wrote:
> >> Guys,
> >> 
> >> As a submission to tomorrow's discussion: I have tried to put some semantics 'meat' on the Sandro's skeleton design[1]. I have put it onto the wiki:
> >> 
> >> http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1/Sem
> >> 
> >> it may provide a way to fold all this into the RDF Semantics with, I believe, a minimal amount of change to the current RDF Semantics (which is a plus for me!), pretty much as a separate section instead of rewriting the whole thing. It may also help in formulating some of the open issues.
> >> 
> >> I believe it reflects what Sandro thinks although I may of course be wrong...
> > 
> > Thanks.
> > 
> > I'm not fluent with formal semantics, but Eric and I took a look at this
> > and tried to make sense of it.   A few thoughts:
> > 
> > * Condition 1 -- shouldn't that be the "range" of I, not the "domain"?
> > That is, the graphs are in the set of things "I" maps to, not the things
> > "I" maps from.
> 
> Oops, of course. Thanks.
> 
> > 
> > * Condition 3 - I agree with Andy -- this condition doesn't belong
> 
> O.k. I removed it altogether and renumbered the various references.
> 
> > 
> > * Condition 4 -- I don't think it's correct to say there can only be one
> > name for a graph, which you're doing with the exclamation point.  I
> > don't see any need to say a name exists at all.  Can't we just say:
> > 
> >        all i in (1...n): <I(ui),Gi> in IEXT(I(rdf:hasGraph))
> > 
> > If I understand the notation right, that's what I had in mind.
> 
> So that is interesting. In a private mail, Pat proposed the same thing. And yes, this does work mathematically.
> 
> The reason I pushed back on this (and followed the approach stipulating the need for a denotation term somwhere) is not because it is mathematically wrong, but because we have to realize the odd-man-out nature of this compared to all the other semantic conditions. Indeed, this means that we put a pair into the cross-product set where one of the element of the pair is not necessarily in I(V). Put it specifically, there is no semantic condition requiring the existence of an 'x', so that I(x) = Gi. This touches on the issues I had with the approach all along: although the _semantics_ talks about a relationship among elements defined by rdf:hasGraph, there isn't any valid RDF triple, necessarily, that can be used to express the rdf:hasGraph relationship for this case. Again, this is mathematically correct; I am just concerned that we do a jump here that not everyone could follow. That is why I used my approach that avoided this pitfall.

I think I understand.   It seems like the kind of thing we could add
later.

> But o.k. I can see that this approach is, mathematically, more elegant, so I changed the page accordingly (we can always use wikipedia's versioning to get back to the old version if we need it later). But should go into this with our eyes open, so to say!
> 
> 
> > 
> > * I think we want another condition that says a given label can only be
> > associated with one graph.   I'm not sure if we say that in the DS
> > conditions and in merging, or somehow say it globally.    Anyway, it
> > would be something like:
> > 
> >  all i,j in (1...n): if (ui,Gi) in DS and 
> >                          (uj,Gj) in DS and
> >                           ui = uj
> >                         then Gi=Gj.
> > 
> > 
> 
> Right. This was not necessary before, that is why I used the ∃! in the formula that has now changed. Except that it is not Gi=Gj, but that the two graphs are equivalent (modulo bnodes...).

Just to make sure I understand you, this equivalence is to deal with the
problem where ig you parse the Turtle document "{} <b> 1; <c> 1" twice,
you're going to get two DIFFERENT graphs, right?   So you're saying Gi
and Gj aren't the same, but are equivalent in this bnode-renaming way.
If so, yes, I agree.

> As for the global thing: I think the semantics can go as far as saying that if you use the same label to two different graphs, then you get into an inconsistent situation. 
> 
> Looking at the result: at the moment I do not see any value in the rdf:Graph class! Indeed, none of the semantic conditions make use of it (except of course its definition). And because this semantics *is* fairly weak after all, this may be fine.

Maybe you're missing Condition 3?   That uses rdf:Graph.

You could make that a bit stronger, too, making it a biconditional.
That is, it is also true that I(ui)=Gi implies {ui rdf:type rdf:Graph}.

> Although... there is still the subgraphing question pending; 

I'd call that the partial-vs-complete graph reference question, but,
yes.   This is one of those cases where people are using DWIM semantics,
so it's painful to switch to standard semantics.

For clarity, we might want to use some syntax like this for now, inside
the group:

<u> {= <a> <b> <c> }    for complete-graph semantics

     read as <u> denotes something which hasGraph <a> <b> <c>.

<u> {+ <a> <b> <c> }    for partial-graph semantics.

     read as <u> denotes something which hasGraph a graph that includes
     at least the triple <a> <b> <c>

(Earlier I suggested using "..." instead of "+", but that gets
confused with metasyntax.  People use "..." all the time in their
examples to mean they're leaving out some details of the example.)

(Also, Eric suggesting using +{...}, but putting an equals outside the
braces has a very different implication.)


> also whether we want to syntactically determine the nature of the default graph.

You mean like whether it's the merge of the named graphs or not?

     -- Sandro

> Ivan
> 
> > 
> > That's it for now...
> > 
> >   -- Sandro
> > 
> > 
> > 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
>

Received on Wednesday, 11 April 2012 14:14:28 UTC