complete vs partial graph semantics

On Wed, 2012-04-11 at 14:55 +0100, Andy Seaborne wrote:
> 
> On 11/04/12 14:24, Sandro Hawke wrote:
> > On Wed, 2012-04-11 at 08:40 +0100, Andy Seaborne wrote:
> >> On 10/04/12 23:38, Sandro Hawke wrote:
> >>> Crawlers wont necessarily report all the data from each source.  For
> >>> instance, they could quite plausibly truncate at 100MB source text.
> >>>
> >>> With 'complete-graphs' semantics, they would have to flag that fact in
> >>> the metadata somewhere; with 'incomplete-graph' semantics, then I expect
> >>> truncating crawlers wouldn't bother to flag it, since their report would
> >>> still be correct.
> >>
> >> RDF is monotonic.
> >
> > You might be overstating the case, but I certainly agree that it's best
> > to use monotonic logics and monotonic modeling with RDF.
> >
> > I mention this only because I have gotten pushback on this from time to
> > time.  For instance, when I was developing the RIF-in-RDF mapping, which
> > lets one convey rules (and graphs) in RDF, I made sure the mapping was
> > monotonic.  That is, I wanted to make sure that if some of the resulting
> > description triples were missing, it would not look like a complete
> > description of something which wasn't true.   BUT several experts in RDF
> > in the RIF Working Group (eg Dave Reynolds, if I recall correctly)
> > argued that this was not a necessary feature.   (We did end up keeping
> > it, though.  http://www.w3.org/TR/rif-in-rdf/
> >
> >>   Adding some triple can not change the meaning of
> >> something else; it can only be a further restriction on the
> >> possibilities described.  Can you show how adding a declaration of
> >> incompleteness of the graph semantics isn't breaking monontonicity?
> >
> > Sorry, I was using the term "flag" rather loosely.  I don't mean a
> > separate triple which acts as a flag, but just some indication in the
> > dataset.
> >
> > Given the modeling and vocabularies used in
> > http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1/Crawler_Example
> >
> > the flagging could be done monotonically by either using a different
> > class...
> >
> >     [ a eg:TruncatedDereferenceOperation;
> >      ....
> >     ]
> >
> > or a different property:
> >
> >     [ a eg:DereferenceOperation;
> >       ...
> >       eg:partialResult ...
> >     ]
> >
> > Okay?
> 
> The critical issue is what happens on the default case of no information.

Put differently, as a test case:

Trig Document 1 (D1):
    <u> { <a> <b> 1 }

Trig Document 2 (D2):
    <u> { <a> <b> 2 }

What is the merge/union of D1 and D2?

OPTION 1:

        It's a contradiction.  You can't merge D1 and D2.
        
OPTION 2:

        Merge the graphs, producing Trig Document 3:
        
        <u> { <a> <b> 1,2 }
        
OPTION 3:

        It depends.  Use out-of-band information.   I argued against
        this in my email to Arnaud yesterday, and seemed to convince
        him.
        http://lists.w3.org/Archives/Public/public-rdf-wg/2012Apr/0054.html
        
OPTION 4:
                
        It's not defined, when asked like this.  We use something
        Trig-Like but different:

          D1A <u> {+ <a> <b> 1 }
          D2A <u> {+ <a> <b> 2 }
        in which case the merge is:
          D3A <u> {+ <a> <b> 1,2 }
        
        ==or==
        
      D1B <u> {= <a> <b> 1 }
      D2B <u> {= <a> <b> 2 }
    in which case there is no merge; they are inconsistent.
        

I'm pretty firmly in the OPTION-1 camp, although I can absolutely see
the appeal of each of the other options.

Oh...!    How about if we just define two operations?   This is kind of
like option-3, but without violating the semantics:

** The "conjunction" of D1 and D2 is logically inconsistent.  I say
"conjunction" because I think this is a strict logical reading of the
proposed semantics.

** The "graph merge" of D1 and D2 is "<u> { <a> <b> 1,2 }".  This is a
data-structure operation that folks are welcome to do in the privacy of
their own homes.

Maybe that's enough.  We can define and talk about both these
operations.   Graph merge is not truth-preserving in the general case,
but can be appropriate in some contexts.

And maybe, if it's not too confusing, we can say that the different
parts of a Trig documents are graph-merged together, like Lee wanted.   

      -- Sandro

Received on Wednesday, 11 April 2012 14:37:31 UTC