- From: Paul Groth <p.t.groth@vu.nl>
- Date: Wed, 09 Nov 2011 21:53:02 +0100
- To: Simon Miles <simon.miles@kcl.ac.uk>
- CC: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Simon, Err.. no. I think dependedUpon is useful. It's a way of saying derivation without implying that there's some activity underneath. I can imagine a hierarchy like wasBasedUpon ---dependedUpon ------derivedFrom I just don't get why you need wasBasedUpon? cheers, Paul Simon Miles wrote: > Hi Paul, > > I take your question to be saying - can't we remove dependedUpon, right? > > This was not something added by me, but I can sort of see the point of > it. If you query some provenance data, you might be looking for > connections, e.g. "find everyone who has been in contact or met > someone who has been in contact with suspected terrorist T". You are > not looking only for those that T has had some effect on, but merely > any leads to pursue in finding T. There are probably better examples > others can give. > > No obviously better suggestion for wasEventuallyDerivedFrom as yet... > wasBasedOn? > > Thanks, > Simon > > On 9 November 2011 20:17, Paul Groth<p.t.groth@vu.nl> wrote: >> Hi Simon, >> >> Couldn't you model the case of the banner image by saying that it was >> used in the activity that generated the page. There is no concrete >> derivation there? >> >> Also, do you have a better name for wasEventuallyDerivedFrom? :-) >> >> thanks, >> Paul >> >> Simon Miles wrote: >>> Hi Luc, >>> >>> Responses interleaved. >>> >>>> We didn't have transitivity on derivation because of the constraint on attributes but it was dropped last week. >>> Yes, but I thought that relaxation merely didn't constrain when >>> transitivity held, not that all derivation was transitive. >>> >>>> If you think that we need a non-transitive relation wasEventuallyDerivedFrom, can you explain why? >>> I've been drafting some text for the primer on derivation that >>> includes an example: >>> >>> "When one entity's existence, content, characteristics and so on are >>> at least partly due to another entity, then we say that the former is >>> derived from the latter. For example, one document may contain >>> material copied from another, a child is derived from his/her >>> ancestors, and a page displayed in a browser is derived from the same >>> page on the web server from which it was downloaded, as well as from >>> the designer's original sketches of what the page would look like. >>> >>> There are different kinds of derivation expressible in Prov-DM. >>> Consider the case of the page in the browser above. It is derived from >>> the designer's sketch in the strictest sense, i.e. if the sketch had >>> been different so would the page. On the other hand, there are >>> entities that are part of the page's history but which did not inform >>> the content of that page, i.e. the page would have been the same even >>> if the earlier entity changed. For example, on creating the original >>> draft of the page, the designer may have included a banner image >>> saying "DRAFT - FOR REVIEW ONLY". This banner was not part of the >>> sketch, nor part of the published page downloaded to the browser, but >>> was part of the page's history, and while not affecting the browsed >>> page's content may have been a factor in its existence. Finally, in >>> some cases, we may be able to say not only that one entity was derived >>> from another, but also how it was derived, i.e. by what process >>> execution. For example, the page in the browser is derived from the >>> page on the web server because a download process sent the bytes of >>> the latter across an HTTP connection to the browser client. >>> >>> In Prov-DM terms, we say that the page in the browser was eventually >>> derived from the sketch, depended on the banner image, and was derived >>> from the page on the web server due to the download process." >>> >>> I still can't agree with Proposal 3 - dependedUpon and >>> wasEventuallyDerivedFrom seem distinct concepts and both important. >>> >>>> Why do you come back on something you had agreed upon? >>> I'm not sure which agreement you are referring to? >>> >>>> If you don't make the link to the PE, how can you decide which PE underpinned the derivation? >>> I don't always want to, I merely want to know from what something is >>> derived (I believe Paul said the same [1]). >>> >>> But on reconsideration, I was wrong that A wasDerivedFrom B could be >>> captured by just A wasEventuallyDerivedFrom B, P used B and A >>> wasGeneratedBy P. I think the difference is only apparent when B >>> occurs multiple times in one account of A's history - if B only >>> occurred once, then I see no need for wasDerivedFrom as only P can be >>> the underpinning of the derivation. But in the case where an account >>> contains A dependedUpon B by multiple paths, then I agree >>> wasDerivedFrom states something otherwise inexpressible. >>> >>> The Prov-O (Stian's) proposal for encoding wasDerivedFrom [2] looks >>> very like my proposed replacement, so might not resolve the ambiguous >>> situation mentioned above. >>> >>>> To me, when generating provenance in a computational context, eg workflow, it's the only derivation that is grounded and can be verified. >>> Sorry, I'm not clear what you mean here - "only derivation" and not what? >>> >>> thanks, >>> Simon >>> >>> [1] http://lists.w3.org/Archives/Public/public-prov-wg/2011Nov/0170.html >>> [2] http://lists.w3.org/Archives/Public/public-prov-wg/2011Nov/0126.html >>> >>> >>>> Professor Luc Moreau >>>> Electronics and Computer Science >>>> University of Southampton >>>> Southampton SO17 1BJ >>>> United Kingdom >>>> >>>> On 7 Nov 2011, at 17:57, "Simon Miles"<simon.miles@kcl.ac.uk> wrote: >>>> >>>>> 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 >>>>> >>> >>> >> -- >> Dr. Paul Groth (p.t.groth@vu.nl) >> http://www.few.vu.nl/~pgroth/ >> Assistant Professor >> Knowledge Representation& Reasoning Group >> Artificial Intelligence Section >> Department of Computer Science >> VU University Amsterdam >> >> > > >
Received on Wednesday, 9 November 2011 20:53:34 UTC