From Provenance WG Wiki
Revision as of 14:25, 14 March 2013 by Tlebo (Talk | contribs)

Jump to: navigation, search



  • Original email:
  • Tracker:
  • Group Response
    • The commenter suggests that "instead of the wasDerivedFrom property, a dummy instance of Activity could always be used". The PROV model was designed to satisfy two different -- but complementary -- provenance user communities. "Entity-centric" users tend to focus on data and are less concerned about the activities involved. "Activity-centric" users tend use workflow environments where executions have relatively more prominence. Each is a valid perspective on the world, and it was important for the Working Group to provide constructs that would satisfy both. The commenter is correct that choosing only one of these perspectives would lead to a "more homogenous" design, it would exclude essentially half of the provenance community and would thus inhibit PROV's adoptability. From the example provided by the commenter, a modeler that is uninterested or simply unaware of the activity that derived one entity from another would be forced to clutter their model with "clutter".
      • In addition to the perspective that a modeler may wish to take, it is important to note that an activity having used an entity and generated another does not necessarily mean that the latter entity was derived from the former. So adding a dummy activity actually conveys less information than wasDerivedFrom.
    • The second comment "wasAttributedTo seems unnecessary to me, as we already can express the same with wasAssociatedWith from the Activity that led to the Entity." follows the same pattern as just described. "wasAttributedTo" allows "entity-centric" modelers to describe their entities without a "dummy" Activity, and "activity-centric" modelers may ascribe responsibility in the latter approach.
      • The commenter mentions the use of "cardinality constraints". The Working Group strived for an OWL ontology that would be lightweight enough for the entire semantic web community to adopt, which includes the Linked Data community that prefers minimal OWL constructs. This rationale is described in the appendix
    • The commenter suggests to rename prov:actedOnBehalfOf to prov:actsOnBehalfOf (s/ed/s/) "since it is independent of the activity". It is not the case that prov:actedOnBehalfOf applies "independent of the activity"; instead it applies "with the applicable activity unspecified". As with all of the qualifiable properties (e.g., prov:used; see for more details), the binary relation does not provide the full details in which an agent acted on behalf of another. To provide (and find) the specifics about how, why, or when an agent acted on behalf of another, an instance of prov:Delegation qualification class is used to specify the context in which the agent acted on behalf of another (specifically, prov:hadActivity indicates the activity in which it was the case).
      • Further, tt is important that provenance describes the past, regardless of the level of detail expressed. actsOnBehalfOf would incorrectly imply that the delegation relationship holds _currently_. This might or might not be the case, but is not part of provenance, so not expressible in PROV.
  • References:
  • Changes to the document:
    • No changes made.
  • Original author's acknowledgement: