Re: prov-dm derivation: three proposals to vote on (deadline Wednesday midnight GMT)

Hello Luc,

+1 for Proposal 1; 0 for Proposal 2; -1 for Proposal 3

Proposal 1 sounds fine, but in what way do Proposals 1 and 2 differ
from what exists at the moment?

More importantly, I can't see anything in the text about
wasEventuallyDerivedFrom being transitive, or see why it would be, so
why does Proposal 3 make sense?

With the two separate links, we are able to assert and query for an
actual connection between one entity's content and another's
(wasEventuallyDerivedFrom), while also allowing the entities involved
somewhere in an entity's history to be browsed (dependedUpon). This
seems to allow for two clear classes of use case for two common
interpretations of provenance.

The one I still don't see the value of is wasDerivedFrom. If you can
say that A wasEventuallyDerivedFrom B, that P used B and P generated
A, then what more is there to say? If wasDerivedFrom is just a
shortcut for this information, why is it significant enough to warrant
being added to the model? Why would you assert an account where you
can say A wasDerivedFrom B, because you know about P, but you do not
say P used B and P generated A?

>From our earlier discussions, I understand the distinction of
derivation types, but wasDerivedFrom just seems a less useful and more
complex to understand version of wasEventuallyDerivedFrom.

Thanks,
Simon

On 7 November 2011 10:06, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
> Dear all,
>
> Can you express your support or not for the following proposals. We will
> confirm
> the outcome at the teleconference.
>
> Best regards,
> Luc
>
>
> In the interest of simplification, we would like to make the following
> proposal about derivations in prov-dm.
>
> Context: prov-dm currently contains 3 different notions of
> derivations, in particular with names that are not intuitive.  The
> constraint derivation-attributes [1] prevented derivations to be
> transitive. These constraints were removed from the prov-dm document
> last week [2].
>
>
>
> Proposal 1. Transitive derivation is expressed using 'dependedUpon'
>             between two entities.  dependedUpon can be asserted or
> inferred.
>
> Proposal 2.  There exists a special case of derivation, where a
>              process execution is known or known to exist.  This is
> expressed using:
>              wasDerivedFrom(e2,e1,[pe, ...])  and its compact form
>              wasDerivedFrom(e2,e1).
>
>              Furthermore, there exists an inference:
>              wasDerivedFrom(e2,e1,[pe, ...]) implies dependedUpon(e2,e1).
>
> Proposal 3.  In the current version of the document,
> wasEventuallyDerivedFrom and dependedOn intended to
>               express the same notion of (transitive) derivation, and
> thus can be
>               removed as redundant.
>
>
>
> Instead of 3 relations wasDerivedFrom, wasEventuallyDerivedFrom, and
> dependedOn, we would now only have 2 relations wasDerivedFrom and
> dependedUpon. The awkward term 'wasEventuallyDerivedFrom' is also
> abandonned.  Overall, this should contribute towards a simplification
> of the model.
>
>
> Note: the text will describe the conditions under which the binary
> form of wasDerivedFrom is transitive.
>
>
>
>
> [1] http://www.w3.org/TR/2011/WD-prov-dm-20111018/#derivation-attributes
> [2] http://www.w3.org/2011/prov/meeting/2011-11-03#resolution_5
>
>
>



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

Received on Monday, 7 November 2011 17:57:17 UTC