feedback sought on ISSUE-529, ISSUE-524, ISSUE5-519, ISSUE-523

Dear all,

I drafted a response to ISSUE-529, ISSUE-524, ISSUE5-519, ISSUE-523.
It can be found at
http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#PROV-DM_issues_involving_inheritance,
and is copied below for information.

Feedback welcome!
Cheers,
Luc

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


    PROV-DM issues involving inheritance


      [edit
      <http://www.w3.org/2011/prov/wiki/index.php?title=ResponsesToPublicComments&action=edit&section=34>]ISSUE-529
      (Empty Collection)

  * Original
    email:http://lists.w3.org/Archives/Public/public-prov-wg/2012Sep/0119.html
  * Tracker:http://www.w3.org/2011/prov/track/issues/529
  * Group Response:
      o In an open world context, absence of the relation hadMember(c,e)
        does not imply that a collection c is empty. Hence, the group
        introduced a class EmptyCollection to indicate when a collection
        is empty.
      o Figure 11, like UML diagrams, is informative. It shows that
        Collection and EmptyCollection are linked with Entity, by means
        of a Generalization association. Therefore, a Collection and
        EmptyCollection are also entities with an id and attributes.
      o Concretely, prov-dm (prov-n) sees all the sub-types (e.g.
        prov:type='prov:Collection' ) as type information is expressed
        by the prov:type attribute.
      o The handling of these subtypes is consistent with other subtypes
        in the model, e.g. revision, softwareAgent, etc
      o Prov-dm, as a conceptual model, leaves the implementation of
        these inherited types to concrete serializations.
  * References:
  * Implemented changes:
      o Changed the text to indicate that PROV defines no collection
        specific attributes.
      o http://dvcs.w3.org/hg/prov/diff/9fb92e012cec/model/prov-dm.html
  * Original author's acknowledgement:


      [edit
      <http://www.w3.org/2011/prov/wiki/index.php?title=ResponsesToPublicComments&action=edit&section=35>]ISSUE-524
      (Bundle/Collection)

  * Original
    email:http://lists.w3.org/Archives/Public/public-prov-wg/2012Sep/0114.html
  * Tracker:http://www.w3.org/2011/prov/track/issues/524
  * Group Response:
      o The group has already addressed ISSUE-504, explaining that
        Bundles are not Collections.
  * References:
      o ISSUE-504:http://www.w3.org/2011/prov/wiki/ResponsesToPublicComments#ISSUE-504_.28collection.2Fbundle.29
  * References:
  * Proposed changes:
      o Changed the text to indicate that PROV defines no
        collection/bundle specific attributes.
      o http://dvcs.w3.org/hg/prov/diff/9fb92e012cec/model/prov-dm.html
  * Original author's acknowledgement:


      [edit
      <http://www.w3.org/2011/prov/wiki/index.php?title=ResponsesToPublicComments&action=edit&section=36>]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:
      o First, a reminder that UML diagrams are informative.
      o The prov-constraints document provides normative information
        about Influence. See Inference 15.
      o 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).

  *
      o Whatever appears as id/attributes in wasGeneratedBy becomes also
        id/attributes in wasInfluencedBy
      o Whatever appears as entity (e) in wasGeneratedBy becomes
        influencee in wasInfluencedBy
      o Whatever appears as activity (a) in wasGeneratedBy becomes
        influencer in wasInfluencedBy
      o Given this, prov-dm should define the minimalist characteristics
        for wasInfluencedBy in a technology agnostic way.
      o 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.
      o 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.
      o Given this, the document should be changed as follows:
          + 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.
      o 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.
      o 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:
      o Inference
        15:http://www.w3.org/TR/2012/WD-prov-constraints-20120911/#influence-inference
      o Current xml
        schema:http://dvcs.w3.org/hg/prov/file/f0e8bc2ae457/xml/schema/prov.xsd
      o Extensibility
        section:http://www.w3.org/TR/prov-dm/#extensibility-section
  * Implemented changes:
      o Changed figure 8, removing Generalization relation between
        WasGeneratedBy,etc and WasInfluencedBy
      o Added table 7.
      o http://dvcs.w3.org/hg/prov/diff/9fb92e012cec/model/prov-dm.html
  * Original author's acknowledgement:


    [edit
    <http://www.w3.org/2011/prov/wiki/index.php?title=ResponsesToPublicComments&action=edit&section=37>]