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

Hi Paul,

For QualifiedGeneration,  prov:activity is a sub property of prov:influencer
and prov:qualifiedGeneration is a sub property of prov:qualifiedInfluence.


So prov:influencer is exactly what we discuss in prov-dm,
and prov:qualifiedInfluence is inverse of influencee in prov-dm.

The same pattern applies to all other forms of influence.

Luc

On 09/26/2012 04:30 PM, Paul Groth wrote:
> 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 
> <mailto: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 
> <mailto:l.moreau@ecs.soton.ac.uk>
> > United Kingdom http://www.ecs.soton.ac.uk/~lavm 
> <http://www.ecs.soton.ac.uk/%7Elavm>
> >
>
>
> -- 
> --
> Dr. Paul Groth (p.t.groth@vu.nl <mailto:p.t.groth@vu.nl>)
> http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
> Assistant Professor
> - Knowledge Representation & Reasoning Group |
>   Artificial Intelligence Section | Department of Computer Science
> - The Network Institute
> VU University Amsterdam

-- 
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