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

Hi Daniel,

There is nothing new, really, in proposal 2, except that we make it 
clear that

             wasDerivedFrom(e2,e1,[pe, ...]) implies dependedUpon(e2,e1).

Otherwise, all the rest is the same.

Luc

On 11/08/2011 10:24 AM, Daniel Garijo wrote:
> +1 For proposal 1, *?* for proposal 2 and +1 for proposal 3.
>
> I'm a bit confused by proposal 2. I don't see what is special in that 
> type of derivation
> that currently doesn't exist in the model. Could you please give more 
> details, please?
>
> Also, I thought that the inference was that if dependedUpon(e2,e1) 
> holds, then implies wasDerivedFrom(e2,e1).
>
> According to what is proposed, if we have wasDerivedFrom(e2,e1), 
> wasDerivedFrom(e1,e0) (but e2 not being
> derived from e0, because it is not transitive), it would imply: 
> dependedUpon(e2,e1), dependedUpon(e1,e0). Since
> dependedUpon is transitive, we would also inferr dependedUpon(e2,e0), 
> and that would be wrong.
>
> Thanks,
> Daniel
>
> 2011/11/7 Luc Moreau <l.moreau@ecs.soton.ac.uk 
> <mailto:l.moreau@ecs.soton.ac.uk>>
>
>     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
>
>
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm