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

Hi Luc,

My overall point is that derivation is both commonly not transitive,
and you may not want or be able to assert anything about the
underlying activities causing a derivation. If we want a transitive
derivation-like relation (which I'm agnostic about, but accept the
general desire), then it must have an explicitly weak semantics to
allow it to be transitive.

> I didn't understand in your example of
> the webpage why you decided to choose dependedOn or
> wasEventuallyDerived.
> It felt to me that you could have swapped them, and it would have still been
> OK.

In my example, the designer may assert that the first draft page was
derived from the banner image ("DRAFT") that it contains, while the
publisher may assert that the published page (excluding the banner)
was derived from the first draft. But the published page is not
derived from the banner image, because it would not make any
difference should the banner have been different, or even not been
present at all, e.g. the first draft could still have existed even if
the banner had been deleted earlier. To allow a transitive
derivation-like relation to exist, it must have semantics so weak as
to allow the published page to be linked to the banner. I understood
this weakened relation to be dependedOn. This relation does not remove
the need for an actual derivation relation to be expressed. I don't
have a strong opinion on whether a transitive relation needs to exist.

The transitive-or-not distinction is also separate from whether
derivation is tied to an activity or not. I might assert that a
student's essay includes material from Wikipedia, without being
involved in or observing the plagiarism itself. If the material had
been copied from Wikipedia to a blog and the student copied from the
blog, the derivation would still hold. I might be wrong in my
assertion, but that is separate from the assertion's meaning. It seems
that only allowing non-transitive derivation to be tied to an activity
(i.e. having wasDerivedFrom and dependedOn without
wasEventuallyDerivedFrom) requires us to constrain what the asserter
knows in making an assertion, but surely the model should only say
what the assertions mean?

> I would argue that there are two sketches, one conceptual leading
> to the webpage, the other physical, created with the pen. And yes
> one is complement of the other!

I agree it could be asserted that way, but it would not be intuitive
to me that these are separate entities, as it is the same thing at the
same instant. I also can't see why the asserters of the two derivation
relations would consider using different attributes to describe the
sketch, unless they knew about the derivations each other was
asserting and chose the attributes to avoid implying the invalid
transitivity.

Thanks,
Simon

On 9 November 2011 21:42, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:
> Hi again,
>
> There was a consensus in the group that we wanted a transitive
> derivation relation,
> and that's why dependedOn was defined to be transitive.
>
> With the current prov-dm, we would be able to infer
> dependedOn(webpage,pencil).
>
> You are arguing here, it's not the case. So, something is definitely broken.
> So, this may question the existence of dependedOn.
>
> Of course, maybe your example is misleading.
>
>   wasEventuallyDerivedFrom(webpage, sketch1)
>   wasEventuallyDerivedFrom(sketch, pencil)
>
> I would argue that there are two sketches, one conceptual leading
> to the webpage, the other physical, created with the pen. And yes
> one is complement of the other!
>
> So, this may not be a good counter for the non-transitivity of
> wasEventuallyDerivedFrom.
> Can you find another example where transitivity does not work for
> wasEventuallyDerivedFrom?
>
> Further comment interleaved.
>
>
> On 09/11/11 21:01, Simon Miles wrote:
>> Hi Luc,
>>
>>
>>> I don't see why wasEventuallyDericedFrom can't be transitive?
>>>
>> Do you mean an instance or in general? If you mean in general, then
>> for example, the webpage in the example was derived from the sketch,
>> which was a pencil drawing on a sheet of paper. The sketch then was
>> derived from the pencil. But the webpage was not derived from the
>> pencil, as it would have been the same if the sketch was written in
>> pen.
>>
>>
>>> It's also unclear how you decide between wasEventuallyDericed and dependendOn?
>>>
>> I'm not sure the kind of decision procedure you're looking for, but I
>> might go for:
>>
>> A wasEventuallyDerivedFrom B if B being different would have meant A
>> was different.
>> If B was used in a process that generated an entity, C, and A
>> wasEventuallyDerivedFrom C or A dependedOn C, then A dependedOn B.
>>
>>
>
> I don't see how what you suggest can work:
>
> used(p,B)
> wasGeneratedBy(C,p)
> wasEventuallyDerivedFrom(A,C)
>
> B could be used by p after C was generated.  How can you derive
> a dependency between A and B?
>
> Let me repharse my question, I didn't understand in your example of
> the webpage why you decided to choose dependedOn or wasEventuallyDerived.
> It felt to me that you could have swapped them, and it would have still been
> OK.
>
> Luc
>
>> Thanks,
>> Simon
>>
>>
>>> Professor Luc Moreau
>>> Electronics and Computer Science
>>> University of Southampton
>>> Southampton SO17 1BJ
>>> United Kingdom
>>>
>>> On 9 Nov 2011, at 20:06, "Simon Miles"<simon.miles@kcl.ac.uk>  wrote:
>>>
>>>
>>>> If you think that we need a non-transitive relation wasEventuallyDerivedFrom, can you explain why?
>>>>
>>>
>>>
>>
>>
>>
>
>



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

Received on Thursday, 10 November 2011 10:47:26 UTC