W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2012

Re: complete vs partial graph semantics

From: William Waites <wwaites@tardis.ed.ac.uk>
Date: Wed, 11 Apr 2012 18:40:56 +0100 (BST)
Message-Id: <20120411.184056.531534198.wwaites@tardis.ed.ac.uk>
To: sandro@w3.org
Cc: andy.seaborne@epimorphics.com, public-rdf-wg@w3.org
On Wed, 11 Apr 2012 10:37:22 -0400, Sandro Hawke <sandro@w3.org> said:

    sandro> Put differently, as a test case:
    sandro> Trig Document 1 (D1): <u> { <a> <b> 1 }
    sandro> Trig Document 2 (D2): <u> { <a> <b> 2 }
    sandro> What is the merge/union of D1 and D2?
    sandro> It's not defined, when asked like this.  We use
    sandro> something Trig-Like but different:
    sandro>     D1A <u> {+ <a> <b> 1 } D2A <u> {+ <a> <b> 2 }
    sandro> in which case the merge is:
    sandro>     D3A <u> {+ <a> <b> 1,2 }
    sandro>         ==or==
    sandro>     D1B <u> {= <a> <b> 1 } D2B <u> {= <a> <b> 2 } in
    sandro> which case there is no merge; they are inconsistent.

Reading some of the background discussion, talking about crawler dumps
and such, it seems to me there is quite a bit more information we
might want to carry around in the "header" of a trig document.

For example, if D1 was downloaded at time t1 and D2 at t2, one could
reasonably conclude that even with the + notation it is inappropriate
to merge them, D2 having superceded D1.

Or perhaps D1 comes from a reliable source and D2 comes from someone
whose data I'll use if I don't have anything better but otherwise I
wouldn't trust. So when combining the information I'll throw out the
second version. But perhaps I would nevertheless keep it around and do
a straight additive merge if I know the cardinality of <b> to be
greater than 1.

My point is that combining data from different sources, or the same
source at different times, is likely to need to take into account more
than just the +/= hints. Some of this information can be in-band
(e.g. time, source) and some must necessarily be out of band (e.g. how
much I trust that source).


Received on Wednesday, 11 April 2012 17:41:11 UTC

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