Re: PROV-ISSUE-519: Data Model Figure 8 [prov-dm]

Hi Luc

I think at the last telco, we agreed that the resolution to this issue
would also attempt to address https://www.w3.org/2011/prov/track/issues/552

In this issue, Alan argues that the term "xxx are particular cases of
influence" implies subclassof but he then argues that what we mean is "kind
of". If we go for the solution below, prov-o cannot implement this as a
subclassof (according to my understanding of the issue).

My concern is that the solution below will be fine for DM but that the
implementation in prov-o using subclassof would be incorrect. You say
"inheritance
would imply that attributes are inherited by the children relation. It is
not the case that wasGeneratedBy has influencer/influencee attributes" but
this is exactly what would have in prov-o, no?

@Tim am I right here?

Thanks
Paul



On Wed, Sep 26, 2012 at 3:10 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk>
wrote:
>
> Dear all,
>
> Both ISSUE-519 and ISSUE-523 relate to Influence.  I drafted a response,
> outlining some changes
> to be made to prov-dm.
>
> I would like the group to make a resolution at the teleconference on
> Thursday, before implementing the changes.
>
> Best regards,
> Luc
>
> PS. Wiki:
>
http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-519_and_ISSUE-523_.28Influence_Inheritance.29
>
> ISSUE-519 and ISSUE-523 (Influence Inheritance)
>
> Original email:
> http://lists.w3.org/Archives/Public/public-prov-wg/2012Sep/0109.html
> Original email:
> http://lists.w3.org/Archives/Public/public-prov-wg/2012Sep/0113.html
> Tracker: http://www.w3.org/2011/prov/track/issues/519
> Tracker: http://www.w3.org/2011/prov/track/issues/523
> Group Response:
>
> First, a reminder that UML diagrams are informative.
> The prov-constraints document provides normative information about
> Influence. See Inference 15.
> For instance, the following inference is permitted, allowing to infer a
> wasInfluencedBy statement from a wasGeneratedBy statement.
>
> IF wasGeneratedBy(id; e,a,_t,attrs) THEN wasInfluencedBy(id; e, a, attrs).
>
> Whatever appears as id/attributes in wasGeneratedBy becomes also
> id/attributes in wasInfluencedBy
> Whatever appears as entity (e) in wasGeneratedBy becomes influencee in
> wasInfluencedBy
> Whatever appears as activity (a) in wasGeneratedBy becomes influencer in
> wasInfluencedBy
> Given this, prov-dm should define the minimalist characteristics for
> wasInfluencedBy in a technology agnostic way.
> Inheritance is a way of implementing Inference 15 of prov-constraints (and
> this approach was successfully followed by prov-o), but it does not have
to
> be implemented that way. For instance, a rule based system could simply
> implement Inference 15 without requiring inheritance. The current prov-xml
> schema does not define WasGeneratedBy as an extension if Influence. A
record
> based system may not rely on inheritance.
> As the author suggests, inheritance would imply that attributes are
> inherited by the children relation. It is not the case that wasGeneratedBy
> has influencer/influencee attributes, but instead, we want to show that
they
> correspond to activity/entity in that case.
> Given this, the Working Group has decided that:
>
> The UML diagram in Figure 8 should not show a Generalization association
> between WasGeneratedBy (and others) and WasInfluencedBy.
> A table should be introduced showing which attributes in
> Generation/Usage/etc are influencer or influencee.
>
> With these changes, the issue raised by the author is no longer
applicable:
> it is no longer the case that wasGeneratedBy etc can be used anywhere
> between agent/activity/entity.
> For the comment "The notion of influence is useful for the PROV model, but
> it is unclear whether this is intended to represent an extension point for
> adopters of the spec. How should it be implemented?", we have shown with
> prov-o, prov-n, and prov-xml various ways of implementing Influence.
> According to Section 6, Influence is not seen as an extensibility point of
> the model, instead, it is seen as a means to express influence in PROV
> without being specific about its nature. We note the following, quoted
from
> the specification:
>
> It is recommended to adopt these more specific relations when writing
> provenance descriptions. It is anticipated that the Influence relation may
> be useful to express queries over provenance information.
>
> References:
>
> Inference 15:
>
http://www.w3.org/TR/2012/WD-prov-constraints-20120911/#influence-inference
> Current xml schema:
> http://dvcs.w3.org/hg/prov/file/f0e8bc2ae457/xml/schema/prov.xsd
> Extensibility section: http://www.w3.org/TR/prov-dm/#extensibility-section
>
> Proposed changes: TODO when vote
> Original author's acknowledgement:
>
> [edit]
>
>
>
> On 10/09/2012 09:47, Provenance Working Group Issue Tracker wrote:
>
> PROV-ISSUE-519: Data Model Figure 8   [prov-dm]
>
> http://www.w3.org/2011/prov/track/issues/519
>
> Raised by: Luc Moreau
> On product: prov-dm
>
>
> http://www.w3.org/2011/prov/wiki/LC_Feedback#Data_Model_Figure_8
>
> ISSUE-463
>
> The figure incorrectly indicates that any child association can be used
> between and among the entity, activity, and agent classes. It would be
more
> accurate to remove the labels from the solid associations and use the
dashed
> lines to trace each relationship to its associated child association
rather
> than to the parent class.
>
>
>
>
>
>
>
> --
> 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
>


-- 
--
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
- The Network Institute
VU University Amsterdam