W3C home > Mailing lists > Public > public-prov-wg@w3.org > December 2011

Re: PROV-ISSUE-153 (complementarity): Complementarity description differs from model definition [Primer]

From: Simon Miles <simon.miles@kcl.ac.uk>
Date: Fri, 2 Dec 2011 15:57:18 +0000
Message-ID: <CAKc1nHdfvdr25Xn8O16Z4CKn1GMxd6vg-9sufeU-cwXBQ-=pKA@mail.gmail.com>
To: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Stian,

Sorry, but it seems my changes to the primer yesterday have
disappeared! So you are just reading the old, uncorrected version of
the primer. I'm certain the link pointed to the updated primer before
the telecon yesterday, but now it does not...

I'll investigate what happened, and try to find my changed text.


On 2 December 2011 15:43, Stian Soiland-Reyes
<soiland-reyes@cs.manchester.ac.uk> wrote:
> On Thu, Dec 1, 2011 at 15:49, Simon Miles <simon.miles@kcl.ac.uk> wrote:
>> Hello all,
>> I have tried to correct the complementarity intuition text in the
>> primer while staying brief and untechnical.
>> Please could you see whether it makes sense to you and resolves the
>> issue (esp. Stian and Graham)?
>> http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html#complementarity
> I'm afraid it still does not make quite sense with reference to
> PROV-DM, although your text reads quite nicely. I wish that your text
> *was* true.
>>  In PROV-DM, we say there is complementarity between one entity and another if everything that characterizes the second is also true of the first. So, both "the second version of document D" and "document D as stored on my filesystem" are complements of "document D", because they are both more specific characterizations of D. If a version of D stored on my filesystem is the second one, then "document D as stored on my filesystem" is a complement of "the second version of document D".
> Unfortunately the core of *complementarity* is that it adds something,
> not that everything is also true for the second entity.
> There is no way in PROV-DM to express that two entities are exactly
> the same and describing the same thing in the world without adding
> anything. So if I've got:
> entity(e1, [ "file": "/tmp/test.txt"] ) .
> entity(e2, [ "file": "/tmp/test.txt"] ) .
> I can't by PROV-DM relate these by wasComplementOf - because neither
> is complementing the other with any new information - stated or
> unstated - because e1==e2.  (Or.. could they be equal in
> characterisation, but different in their provenance?)
> In wasComplementOf(Specific,General) the more specific entity
> complements the more general one. The "second version of document D"
> complements "document D" because it characterises the same thing for
> the overlapping characterisation interval, and because it
> characterises some attributes which document D does not characterise,
> like "version" and "content".
> In fact here what you say about "second version of D" is not 'also
> true for D' - it is only true for the timespan of "second version of
> D" which overlaps the timespan of "document D". Unfortunately PROV-DM
> does not allow us any direct way to state that timespan or the
> overlap, and that's part of why this is difficult to explain in a
> primer.
> It is true that both wasComplementOf(secondVersion, fileOnDisk) and
> wasComplementOf(fileOnDisk, secondVersion) if the file on disk at some
> point had the content of version 2. secondVersion here compliments
> with the "version" attribute being fixed/provided, fileOnDisk
> complements with the "fileLocation" being fixed/provided - but you
> might delete the file from disk while version2 exists, and your file
> might have previously contained version1. So in principle you have a
> very good example here.
> I'm not sure how to express this in a two-paragraph manner, though..
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester

Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

Modelling the Provenance of Data in Autonomous Systems:
Received on Friday, 2 December 2011 15:57:48 UTC

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