Review of prov-o july 3 2012 for last call

From Provenance WG Wiki
Jump to: navigation, search
Note: This page is maintained by the prov-o team to keep track of all feedback that 
we have received. Pleas submit your review by responding to 
or mentioning "ISSUE 444" in your email to

Please do not edit this page directly.


  • RAISED: We see that you have a point and are working it.
  • WITHDRAWN: You withdrew your point, perhaps after some discussion.
  • OPEN: We understand your point, agree, and are working to resolve.
  • DM: This needs to be pushed back to PROV-DM for a change to happen in PROV-O
  • POSTPONED: The point is valid, but we do not have pressing need to finish it and should revisit later.
  • PENDING-REVIEW: We feel that we have addressed your point and left comments immediately after.
  • CLOSED: You agree that the issue is settled.
  • REOPENED: You do not agree that the issue is settled.
  • OBE: This comment is on a construct that has been removed by a WG resolution.


July 4 5am

Hi prov-o team,

Thanks for producing the document. Here are a few comments on the ontology, before I start reading
the html document.

I think you removed too many of the property characteristics, some of which are prov-o specific
(as opposed to being prov-constraints specific).

Otherwise,  I think the ontology is aligned with prov-dm. I think that Influence and influencer are
quite nice!


1. hadRole: why is domain defined as intersection of Influence and six of its subclasses.
  Why not the subclasses directly?

PENDING-REVIEW EDITORIAL - Added narrative and table justifying the duplicate domains. See

2. qualifiedXXX: shouldn't they be inverseFunctional?
 Otherwise, this would allow for a given Influence instance, to be a qualified Influence
 for multiple subjects. This is not intended.

 The qualified pattern is prov-o specific. It was inverse functional before, but I think
  this characteristic was incorrectly removed.

WITHDRAWN TECHNICAL WORK - is this grounded in DM? "scruffy won"

3 influencer: should it be functional: there is only one influencer per
qualified pattern instance, isn't there.

WITHDRAWN TECHNICAL WORK - is this grounded in DM? "scruffy won"

4. Likewise:
hadPlan: is functional
hadUsage: is functional
hadGeneration: is functional
hadActivity: is functional

WITHDRAWN TECHNICAL WORK - is this grounded in DM? "scruffy won"

  As per prov-dm.

5. generatedAtTime: In owl file: editorialNote "It is the intent that the property chain holds: (prov:qualifiedGeneration o prov:atTime) rdfs:subPropertyOf prov:generatedAtTime."@en

--> It cannot be functional since qualifiedGeneration is not functional.

Also applies to all the others, invalidatedAtTime, startedAtTime, endedAtTime,

PENDING-REVIEW TECHNICAL WORK suggested removing functional characteristic. (done): functional removed from all datatype properties.


July 4 10am

Hi prov-o team, again,

Find below some specific comments about the provo document.

Thanks for the extensive work!
It needs some polishing, but the majority of it, can happen after LC.

Answer to your questions:

1) Are there any issues that should delay the WG's release of PROV-O as Last Call (i.e., is all of the technical work done).

- Minor Issues in the ontology raised in my previous message
- Definition alignment, and make sure that example don't use constructs incorrectly (e..g hadRole)

PENDING-REVIEW EDITORIAL. Responded to all example flaws pointed out below, fixed definition bug.

2) Are the examples and scenario adequate?

- Yes, though I couldn't follow the scenario anymore without a picture. Can a picture be added, with the style adopted by other documents


3) Should the links to prov-dm, prov-constraints, and prov-n stay in the cross reference?

- See comment below.

Specific comments:

Section 1
- owl-rl -> orl-rl ++

PENDING-REVIEW EDITORIAL Since "RL++" is not a recognozed profile, it is rephrased to:

  • "PROV-O is lightweight so that it can be adopted in the widest range of applications.
  • With the exception of five axioms, PROV-O conforms to the OWL-RL profile [OWL-2-PRIMER]."

- para 3: provdm introduces a MINIMAL set of concepts ... delete MINIMAL


- "... which facilitate a fixed interpretation and use of the prov data model concepts based on the formal semantics of owl2: " delete


- reference to xml-schema should be to xml-schema11 (owl2 automatically switched to xml-schema11)

PENDING-REVIEW EDITORIAL ADDED [XMLSCHEMA11-2] Henry S. Thompson; et al. W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes.. 5 April 2012. W3C Recommendation URL:

section 2:
- "the terms in this category ARE APPLIED IN the same way ..." not sure what this mean.

RAISED EDITORIAL How to clarify? "used, exercised, stated, asserted, expressed, …" sent email to Luc.

section 3.1:
- "the starting point category is a small COLLECTION ..." to avoid confusion, use SET instead.


- definitions entity/activity/etc need updating

RAISED TECHNICAL WORK asked Luc by email where they need updating

- "In this case, the Agent that influenced an Activity or Entity prov:actedOnBehalfOf another Agent that MAY HAVE HAD LESS INFLUENCE, but still bears some responsibility for the resulting Activity or Entity."   I am not sure we should say this at all.  The agent may or may not have had more or less influence.


  • In this case, the Agent that influenced an Activity or Entity prov:actedOnBehalfOf another Agent that also bears some responsibility for the resulting Activity or Entity.

- -> ?   everywhere

RAISED EDITORIAL requested clarification from luc via email.

- example after fig 1: it would be nice to see a "prov-style" picture


- example 2 (agent derek) ... it was suggested for prov-dm that
 examples should be described in past tense. It should be done here


- i don't understand wy ex:post9821v1 is a specialization of ex:post9821,
 I can see it's an alternate. (in example code and in text)

PENDING-REVIEW EDITORIAL Daniel (Update) It's neither of them: ex:post9821 is the location for ex:post9821v1. I have fixed it on the text.

- inmediately->immediately

PENDING-REVIEW EDITORIAL changed to "shortly"

- "Since the provenance produced by the activities of Derek and Monica correspond to different user views, the system automatically publish it in different prov:Bundles (ex:bundlePost and ex:bundlePost1)." I don't understand.  It is part of the scenario? or is part of prov?

PENDING-REVIEW Daniel (Update) It's part of the scenario. I have expanded a bit this sentence explaining why the system does that.

- I am lost in the example without a picture

PENDING-REVIEW EDITORIAL Daniel (Update). David has created some diagrams based on the examples. Currently we haven't included all of them because it might be not necessary to follow the example.

- Suggestion: number examples.

OPEN EDITORIAL numbering style that we are using is okay. go do it.

    function updateExamples() { ..}
    function updateExamplesRefs() { ... }


at the beginning of prov-dm.html.

- an example still has prov:hasAnnotation

PENDING-REVIEW TECHNICAL WORK Daniel (Update): I have fixed this. It was a typo.

- "and all the data related to the post is lost. " permanently?

PENDING-REVIEW Daniel (Update): Yes. I have added it to the text.

- example: bundles have not been used, so what is their point?

PENDING-REVIEW Daniel (Update). Bundles were not used directly, but now I have added a motivation to have them in the scenario. Plus, I have added extra annotations to each of them.

- figure 3: can we keep the conventions used elsewhere: agent is represented by pentagon.

PENDING-REVIEW EDITORIAL done for Figure 3. Figs 1 and 2 stay as "class" style, not "prov" style.

- comments in some of the example (e.g. qualified usage) go beyond the box, into the margin


  • new max width is 97 characters.
  • 99 class_ActivityInfluence.ttl
  • 99 class_AgentInfluence.ttl
  • 101 class_Bundle.ttl
  • 101 class_Derivation.ttl
  • 101 class_Derivation.ttl
  • 101 class_SoftwareAgent.ttl
  • 101 property_hadActivity.ttl
  • 102 property_qualifiedDerivation.ttl
  • 102 property_qualifiedTrace.ttl
  • 103 class_Derivation.ttl
  • 103 class_Derivation.ttl
  • 103 property_pair.ttl
  • 103 property_qualifiedMembership.ttl
  • 104 class_Derivation.ttl
  • 106 property_qualifiedQuotation.ttl
  • 107 class_Invalidation.ttl
  • 107 class_Quotation.ttl
  • 107 property_wasQuotedFrom.ttl
  • 107 property_wasQuotedFrom.ttl
  • 108 class_Collection.ttl
  • 110 class_Bundle.ttl
  • 110 class_Generation.ttl
  • 110 class_InstantaneousEvent.ttl
  • 110 property_invalidated.ttl
  • 110 property_value.ttl
  • 110 property_wasInvalidatedBy.ttl
  • 111 property_qualifiedDelegation.ttl
  • 111 property_qualifiedQuotation.ttl
  • 113 property_wasQuotedFrom.ttl
  • 114 property_qualifiedQuotation.ttl
  • 117 class_Influence.ttl
  • 117 property_value.ttl
  • 118 class_Collection.ttl
  • 118 property_qualifiedMembership.ttl
  • 119 property_hadMember.ttl
  • 119 property_pair.ttl
  • 121 property_hadMember.ttl
  • 121 property_pair.ttl
  • 123 class_Collection.ttl
  • 123 property_hadMember.ttl
  • 125 property_hadQuoter.ttl
  • 126 property_asInBundle.ttl
  • 126 property_mentionOf.ttl
  • 127 property_qualifiedMembership.ttl
  • 128 class_Influence.ttl
  • 128 class_Quotation.ttl
  • 128 property_hadQuoted.ttl
  • 128 property_qualifiedInfluence.ttl
  • 129 class_Quotation.ttl
  • 129 property_hadQuoted.ttl
  • 129 property_hadQuoter.ttl
  • 136 class_Collection.ttl
  • 136 class_CompleteCollection.ttl
  • 136 property_hadMember.ttl
  • 136 property_pair.ttl
  • 147 class_ContextualizedEntity.ttl

- cross referencing, I am not against it, I am concern about the additional space it takes.
 Can it be folded in the title section?


 It's probably too early at this stage to link to constraints, though
 this would be valuable once the prov-constraints document is stable.

PENDING-REVIEW links to prov-constraints and prov-n removed.

- examples: dererk -> dereck

PENDING-REVIEW EDITORIAL changed> to, "dereck" and "dererk" no longer appear in the html.

- examples: to save space, can we define all prefixes upfront and avoid repeating them

RAISED EDITORIAL it's worth the space for self-standing examples, no?

- prov:wasDerivedFrom contains definition of entity, and not of derivation

PENDING-REVIEW TECHNICAL WORK at DONE. Bug in the cross reference generator.

- prov:Bundle: the text talks about account

PENDING-REVIEW TECHNICAL WORK renamed to bundle; "account" occurs once in html and is not referring to bundle.

- prov:Bundle: maybe should state the purpose: provenance of provenance


  • prov:Bundle prov:definition "A bundle is a named set of provenance descriptions, and is itself an Entity, so allowing provenance of provenance to be expressed." .

- prov:alternateOf: contains definition of software agent

PENDING-REVIEW TECHNICAL WORK Done. Fixed after the Great Definition Bug of 2012 was resolved.

- <> prov:wasDerivedFrom < .... dm ...>  :
 I guess it's always good to eat our own dog food, but I think this complicates
 the examples.

PENDING-REVIEW EDITORIAL they are removed now.

- prov:invalidatedAtTime the painter seem to be destroyed in 2012???

PENDING-REVIEW EDITORIAL changed all to 1998

- prov:mentionOf/specializationOf: have software agent as definition.

PENDING-REVIEW TECHNICAL WORK fixed when fixing software bug.

- prov:value:  "The main value  ... of a STRUCTURED value."
 What is structured, here?

DM TECHNICAL WORK pushed back to DM

- prov:wasInvalidatedBy example:
Is it right to say swissair_flight_111_crash prov:used <http//db.... swissair_flight_111>?

RAISED TECHNICAL WORK asked Luc for clarification.

- prov:Influence and its subclasses: can they be used alone without a concrete  influence?
 Shouldn't the text say something and RECOMMEND the use of subclasses?

RAISED EDITORIAL awaiting Luc response. Added the following comments into the OWL (and thus the cross reference)

  • Because prov:Influence is a broad relation, the more specific relations (Communication, Delegation, End, etc.) should be used when applicable.
  • Because prov:wasInfluencedBy is a broad relation, the more specific relations (prov:wasInformedBy, prov:actedOnBehalfOf, prov:endedBy, etc.) should be used when applicable.
- prov:Communication is not allowed in the domain of atLocation (see
 example for prov:Communication)

PENDING-REVIEW TECHNICAL WORK (nothing says Communication cannot have it...) Regardless, removed atLocation and put in ex:mediaType "email".

- typo: prov:Actvity in example with policySale


- Delegation is not in the domain of hadRole (see insuranceAgent_Frank)

PENDING-REVIEW TECHNICAL WORK Changed to "ex:rewardScheme "commission".

- example of derivation goes into margin


- EntityInvolvment: comments that appear in the example should be given in the narrative.

PENDING-REVIEW EDITORIAL done. and applied to the other two Influences. See

- Quotation no longer has hadQuoter and hadQuoted in prov-dm

PENDING-REVIEW TECHNICAL WORK removed them, added "ex:fromSection 2;"

- prov:Revision, the binary wasAttributedTo is incorrectly qualified by an Association
 instead of Attribution

PENDING-REVIEW TECHNICAL WORK fixed. added ex:peerReviewed false on revision.

- example for prov:hadGeneration
 has a qulaifiedDerivation,
  dont' you need to specifiy influencer entity?

PENDIDNG-REVIEW TECHNICAL WORK fixed. added "prov:entity  :aggregatedByRegions;"

-  no role allowed in attribution

  a prov:Entity;
  prov:qualifedAttribution [
     a prov:Attribution;
     prov:agent   :civil_action_group;
     prov:hadRole :owner;

PENDING-REVIEW TECHNICAL WORK. moved to ex: namespace.

- no role in delegation

  a prov:Person;
  prov:actedOnBehalfOf :celebrity-in-car;
  prov:qualifiedDelegation [
     a prov:Delegation;
     prov:agent   :celebrity-in-car;
     prov:hadRole :employer; # The celebrity employed the chauffeur during the enforcement.

PENDING-REVIEW TECHNICAL WORK changed role to ex: namespace.

- prov:qualifiedDerivation
  prov:wasDerivedFrom :aggregatedByRegions;
  prov:qualifiedDerivation [
     a prov:Derivation;
     prov:hadGeneration :illustration;

Shouldn't you link to :aggregatedByRegions;?

PENDING-REVIEW EDITORIAL added prov:entity to property_hadGeneration.ttl property_qualifiedDerivation.ttl

- qualifiedInvalidation: check time of crash

PENDING-REVIEW EDITORIAL changed to 1998-09-02T01:31:00Z

- prov:qualifiedQuotation uses quoter/quotedAgent

PENDING-REVIEW TECHNICAL WORK replaced with " my:fromSection 1;"

- qualified source
  a prov:Entity;
  prov:hadOriginalSource :sensorReading20120510;
  prov:qualifiedSource [
     a prov:Source;
     prov:entity         :sensorReading20120510;

Isn't there a RECOMMENDation to use the qualified pattern only if it adds new information?
It does not do it here.

PENDING-REVIEW EDITORIAL added prov:entity sensorReading20120510

- qualified usage

  a prov:Activity;
  prov:used :tsunami_image;
  prov:qualifiedUsage [
     a prov:Usage;
     :hasCopyrightPermission :licensedUse;
     :hasOwner               :reuters;

Need to add prov:influencer tsunami_image



prov:hasAnchor  prov:hasProvenance  prov:hasProvenanceService  prov:provenanceUriTemplate
Should not be described in the html document, but in the paq document.


-  appendix
# Instead of defining their own, modelers should use the
# recommended inverse local name within the PROV namespace:

This is confusing. So, it would be better to say that they are defined in prov namespace
though not defined in prov-o.html ( a bit like paq stuff). It would be informative.

PENDING-REVIEW TECHNICAL WORK See, which now uses phrases like "This document reserves the names of the property inverses" vs. "PROV-O defines" for the preferred directions.

- OWL2 primer should be normative reference




Hi Prov-O Team:

Thanks for all your work. It's both a good ontology and a very
readable document. Here are the answers to the review questions and my
comments below. I'm happy with the document to got to Last Call

1) Are there any issues that should delay the WG's release of PROV-O
as Last Call (i.e., is all of the technical work done).

All the major technical work is done in my opinion. I had a question
about inverses but it is not a blocker more clarification.

2) Are the examples and scenario adequate?
Yes, I believe that some of the examples are being corrected. But the
examples themselves are adequate.

3) Should the links to prov-dm, prov-constraints, and prov-n stay in
the cross reference?

I would remove the links to prov-constraints and prov-n but leave
those to prov-dm.


Specific comments:
- should we add a prov:wasAttributedTo the ontology

RAISED EDITORIAL (w/ roles editor, author, reviewer.. oh, wait. we can't role attribution...)

"It can also be specialized to create new classes and properties to
model provenance information specific to different domain

"It can also be specialized to create new classes and properties to
model provenance information for different applications and domains"


==Status of this Document==

- remove " before the implementation phase."


- in "how to read" change OWL-RL ontology to OWL



- last line paragraph one remove "and management"


- paragraph 2, repeat of the sentence "PROV-O conforms to the OWL-RL
profile and is lightweight so that it can be adopted in the widest
range of applications."


==PROV-o at a glance==

- last sentence first paragraph. you say there are four categories but
now there are only there categories. Remove collections.


==3.1 Starting Point Terms==
- I think the following statement is unnecessary - "A
prov:wasInformedBy relation between Activities suggests that the
informed Activity used an Entity that was generated by the informing
Activity, but the Entity itself is not interesting. So, the
prov:wasInformedBy property allows the assertion of provenance chains
comprising only Activities"


- I wonder if a better example organization instead of ex:chartgen
would be "National Newspaper"

PENDING-REVIEW EDITORIAL Daniel. Tim already did this change :)

==3.2 Expanded Terms==
- I wonder if the 5 categories should be more prominent


- "Activity-centric in addition to Entity-centric modeling" - can we
link to what this means?

PENDING-REVIEW TECHNICAL WORK rephrased to to facilitate Activity-as-subject as well as Entity-as-subject descriptions -- which should be more natural for the RDF-oriented audience.

- before the example you say "Agent Derek", it should just be Derek -

I don't think we're describing a matrix film :-)

PENDING-REVIEW EDITORIAL done. just "Derek" now.

- I think the team was already looking at the consistency of the
examples. It was Chart Generators and now in this example it's Chart
Generators Inc

PENDING-REVIEW EDITORIAL Daniel. It's now :national_newspaper_inc ("National Newspaper, Inc.") in the whole document.

- Can we fit the comments into the text box?


==Section 4==

- it may be nice that the "see alsos" e.g. See also prov:endedAtTime
are linked to the corresponding concept

RAISED EDITORIAL need to work code.

- In both prov:wasAttributedTo and prov:wasDerivedFrom I don't
understand why you repeat the definition of entity?


- Class Bundle: "Note that there are kinds of accounts (e.g.
handwritten letters, audio recordings, etc.) that are not expressed in
PROV-O, but can be still be described by PROV-O." - account needs to
be replaced with bundle


- prov:alternateOf and prov:specializationOf has "A software agent is
running software." as it's definition - this needs to be fixed


- I like the example of wasQuotedFrom :-)

==Section B==
- Inverses - I'm interested in the choice here. I think it's the right
move but I wonder if breaks anything actually not defining the
inverses? I also wondered if you were to define the inverses in a
separate owl file and did an owl import would that solve the problem?
This is more of a question for my edification rather than a

PENDING-REVIEW The "namespace dereference" solution addresses this. The section was reworded to say "reserves the names" of the inverse properties, and it provides a link to a file listing the inverses in OWL.

==Layout Questions==
- These are points that can be addressed or not
-- I guess eventually we may add some rdfa in the document?

RAISED There already is; it states prov-o...

-- I wondered if we could have same javascript that would let us
collapse the parts of section 4. This may make it easier to read.




I've just read through PROV-O, and generally I like the overall structure and approach.  There are a few (editorial) points you might wish to consider in preparing for last call:

(1) would it be possible for term names to be included in the table of contents?  I found some aspects the document could be difficult to navigate/cross-reference in printed form.

REOPENED EDITORIAL should be the "print-friendly index" that you're looking for. It is at the top of the document.

  • Unfortunately, this doesn't really help, as there's no obvious ordering of the terms. (Ideally, they would be page-numbered, but I recognize that HTML isn't very good for that kind of thing (I'm surprised that after all these years, HTML still doesn't support ToC generation as standard). The compromise I usually make is to have a table of contents that matches the document layout, with section numbering, so I can use that as a kind of "map". That you don't section-number the individual term descriptions is part of my problem.)
  • This is just an editorial issue, and rather depends how much you care about usability of the spec in print form.
  • Granularity is a big part of it, but also the section references you mention are buried in text which makes them harder to spot. Also, section numbering of the term descriptions would help (in conjunction with a ToC).
  • FWIW, section 4.1 covers 6 pages in my printed copy, with quite small text - that's quite a bit to flip through when trying to find a particular property. The total of material for which I'd like to see a more detailed ToC is 47 pages.
  • The trouble is, I suppose, is that there isn't really a way to create an index that works on paper without it occupying a whole page. For making a printed version navigable, I think that's a price worth paying, but YMMV.

(2) is there a defined correspondence between the ontology terms and PROV-DM? Maybe a table as an appendix?

(in subsequent email)
I think a table of PROV-N forms and corresponding RDF forms would cover it.  
Maybe as an appendix of the PROV-O document, or woven into the cross-reference?

PENDING-REVIEW TECHNICAL WORK DM added and PROV-O cites it at and within each cross reference entry.

(3) In sections 4.1/4.2, I found a few descriptions that look like cut-and-paste leftovers:  prov:wasAttributedTo, prov:wasDerivedFrom, prov:alternateOf, prov:generatedAtTime, prov:hadmember.

PENDING-REVIEW TECHNICAL WORK this was a software bug and is fixed now.

(4) In section 4.3, there are some repeated headings+content that seem, well, pointless:
  prov-dm: prov-dm
  prov-n: prov-n
  prov-constraints: prov-constraints
I assume this is an artefact of the document generation process.

PENDING-REVIEW EDITORIAL links to prov-n and prov-constraints removed, links to prov-dm rephrased as: "alternate: as in <a>prov-dm</a>".

(later in another email)
Hyperlinks are good, but I think they should also indicate visually how to find what it is they link to, 
because not everyone will be reading an electronic copy.

PENDING-REVIEW now states "PROV-DM term Start" and links to the dm page.

I have some more detailed comments that may be considered before or after last call:

1. Introduction.

"defines the normative OWL 2 ontology" - I think it's the definition that's normative, not the ontology.  Suggest drop the word "normative"


"PROV-O conforms to the OWL-RL profile" - I think a citation fort OWL-RL would be appropriate here.

PENDING-REVIEW EDITORIAL link added to primer.

"Starting point classes and properties" - I note that elsewhere we now refer to these as "Core structures".  
I think "starting point" is OK, but it might be helpful to readers to align usage?

POSTPONDED EDITORIAL the WG agreed that prov-o could have some flexibility on its term organization, and the prov-o team has decided to use starting point. We can revisit this in light of "consistency".

3.1 Starting point terms

para 4: "to provide some ordering information" - I found the choice of term "ordering" a little strange - 
isn't what is being described here "dependency" information?

PENDING-REVIEW EDITORIAL changed to "to provide some dependency information without explicitly providing the activities' start and end times".

papas 4,5:  references to "not interesting" - I'm thinking that the activities/entities concerned may be just "not known".

PENDING-REVIEW EDITORIAL appended "or unknown" to occurrences of "interesting".

3.2 Expanded terms

Para 5:  Staring from "It is important to note that...".  I found this very hard to understand, potentially contradictory, 
and I'm not sure if I entirely agree with it.  I would suggest either dropping this, or radically simplifying the paragraph; e.g.

A prov:Bundle is a named set of provenance descriptions, which may itself have provenance. 
The named provenance descriptions may be expressed as PROV-O or in some other form.

PENDING-REVIEW EDITORIAL The above suggestion was incorporated into A prov:Bundle is a named set of provenance descriptions, which may itself have provenance. The named provenance descriptions may be expressed as PROV-O or in some other form. The subclass of Bundle that contains PROV-O assertions is not provided by PROV-O, since it is more appropriate to do so using other recommendations, standards, or technologies. In any case, a Bundle of PROV-O assertions is an abstract set of RDF triples, and adding or removing a triple creates a distinct Bundle of PROV-O assertions.

Para 9 ("The fourth category..."):  why the two exceptions prov:generated and prov:invalidated to the not-defining-inverse principle? 
(The reason given doesn't seem adequate to me.)

PENDING-REVIEW EDITORIAL changed to to facilitate Activity-as-subject as well as Entity-as-subject descriptions.

Para 13: ("However, immediately after ..."):  typo "inmediately"

PENDING-REVIEW EDITORIAL changed to "shortly".

Para 14: ("Shortly after Derek's..."):  the use here of "ex:monica" as a noun, so closely following use of "Derek" seems, 
at best, inconsistent.  Suggest "Monica".


3.3: Qualified terms

I appreciate this is a tricky topic to explain, especially all in words, but I found it really hard going, even though the basic
 idea is quite easy to understand.  I think a diagram immediately following the first paragraph (along the lines of those that 
appear later in fig 3) to illustrate the idea would make a great difference.

POSTPONDED EDITORIAL at least one person has suggested that one element or another goes first. I'm not sure how to please everyone. I think we need to sit on this for a while and see what the public thinks.

Also, I think the choice of example didn't held, as it's not so easy to remember that "Association" is between an agent and an activity - 
there are no clues in the choice of word.  By comparison, "Usage" as relating an activity and an entity is much easier to remember,
so I think an example based on that would be easier to follow.

PENDING-REVIEW EDITORIAL changed from Association to Usage, per suggestion.

Para 2: (immediately following table 2):  This was hard to follow, and seems to me to be in the  wrong place as it's quite divorced from the 
document parts it actually describes.  I think it would be more useful to introduce this (with a back-ref to this section) at the start of 
section 4 where it's much closer to the occurrences of what it describes.

PENDING-REVIEW EDITORIAL Agreed. Only this remains: The qualification classes and properties shown in the previous two tables can also be found in the cross reference in the next section of this document. and the rest was moved to the cross reference section.

Para 5: (following second example):  I find the use of normative language here to be inappropriate, and verges on dictating application design.  
I argue that it is quite correct and acceptable for an implementer to use qualified or unqualified forms as they choose, and that a consuming 
application should be prepared to recognize either form.  I think it is reasonable to explain the consequences of using the available choices, and 
suggesting an approach to encourage consistency, but I wouldn't go beyond that.  Suggest that SHOULD and SHOULD NOT here be replaced by 
non-normative, more descriptive language.

PENDING-REVIEW TECHNICAL WORK agree. Incorporated into As can be seen in this example, qualifying an influence relation provides a second form (e.g. :e1 prov:qualifiedGeneration :e1Gen) to express an equivalent influence relation (e.g. :e1 prov:wasGeneratedBy :a1). It is correct and acceptable for an implementer to use either qualified or unqualified forms as they choose (or both), and a consuming application should be prepared to recognize either form. Consuming applications should recognize both qualified and unqualified forms, and treat the qualified form as implying the unqualified form. Because the qualification form is more verbose, the unqualified form should be favored in cases where additional properties are not provided. When the qualified form is expressed, including the equivalent unqualified form can facilitate PROV-O consumption, and is thus encouraged.

If there's anything that I think should be normative here, it is that consuming applications SHOULD recognize both qualified and unqualified forms, 
and treat the qualified form as implying the unqualified form.  (I think this would be the most effective invocation of the Postel principle.)

PENDING-REVIEW TECHNICAL WORK agree. done in As can be seen in this example, qualifying an influence relation provides a second form (e.g. :e1 prov:qualifiedGeneration :e1Gen) to express an equivalent influence relation (e.g. :e1 prov:wasGeneratedBy :a1). It is correct and acceptable for an implementer to use either qualified or unqualified forms as they choose (or both), and a consuming application should be prepared to recognize either form. Consuming applications should recognize both qualified and unqualified forms, and treat the qualified form as implying the unqualified form. Because the qualification form is more verbose, the unqualified form should be favored in cases where additional properties are not provided. When the qualified form is expressed, including the equivalent unqualified form can facilitate PROV-O consumption, and is thus encouraged.

4.2 Expanded terms

Class prov:Bundle:  is the notion of provenance *of an entity* actually described anywhere?  
(As opposed to provenance that is "about entities, activities and people".

This is maybe a bit picky, and is a wider issue than just prov:Bundle, but it's the phrasing here that made me ask the question.
I wonder if it wouldn't help to be clear that we all understand the same thing for "provenance of an entity".

Further down, the paragraph starting "Note that there are kinds of accounts...".  
It seems to me this is a statement of what should already be entirely obvious - 
I think it has greater potential to confuse than clarify.  Suggest dropping this.

PENDING-REVIEW EDITORIAL "entirely obvious" in a full read-through of the document, perhaps. But this is a rdfs:comment in the ontology and appears in a cross reference that does not expect the reader to read the entire html document.

Class prov:Organization:  "social institutions" - I think is either tautological or incorrect, depending on how one 
understand "social" here (in the current climate, I regard many companies as being distinctly *anti*-social).  Suggest drop "social" here - I think it's unnecessary.

DM EDITORIAL This is a DM issue. raise it there.

Property prov:hadPrimarySource:  Text further down refers to "An original source..." 
- I think this should (now) be "A primary source...".

PENDING-REVIEW EDITORIAL now says "## Having an primary source is a particular case of derivation." "An original source" no longer appears in html.

Property prov:invalidatedAtTime:  "...began to be invalidated" reads oddly to me.  Suggest just "...was invalidated" 
(as once the invalidation process has started, the essential conditions of being invalidated are already satisfied).


Property prov:value:  I suspect this has already been extensively discussed, but I wanted to question this being a *functional* property.
That would exclude, for example, giving equivalent integer and floating values for an entity.

PENDING-REVIEW TECHNICAL WORK functational was removed on prov:value. Two identical values don't imply the same entity.

But, maybe more fundamentally, is there any specified way to express a value that is itself denoted by a URI?  
In OWL terms, this needs an object property. It's OK if ther4e's no such way, as one can always introduce new properties, 
but it seems odd to me that data values are OK but other values are not.

PENDING-REVIEW TECHNICAL WORK prov:value is the literal analogue to prov:specializationOf. Related issue on def of prov:value at

prov:wasStartedBy:  "The activity did not exist...".  I've come across this phrase several times in reading the PROV documents, 
and each time find it a bit odd.  I would find something like "the activity was not in progress..." to be less jarring.  
(Activities start and stop, rather than winking in an d out of existence.)  It's just a nit, not a big deal.


Property prov:hasAnchor:  I have a suggestion to drop this from PROV-AQ, as its intended use is now covered by prov:specializationOf.  
Maybe should be marked "at risk"?

PENDING-REVIEW all PAQ has been removed. I encourage resuing specializationOf for hasAnchor (mentionOf, really... ;-)

B. Names of inverse properties

Para 1: I count *two* exceptions, not just one (used and invalidated)

PENDING-REVIEW EDITORIAL generated and invalidated.

Para 1, final sentence "This extra effort must be avoided".  
I don't agree - the extra effort may be just what is needed (or I don't understand what is being suggested).  
Suggest drop this sentence.

PENDING-REVIEW EDITORIAL weakened it to This extra effort can be reduced by preferring one inverse over another.

Also, again, why the two exceptions?

Para 4:  
"...they may be motivated to assert the inverse of...".  

I don't think "asserting" the inverse is a problem here.  It's defining a new symbol for it. 

Suggest "...they may be motivated to introduce an inverse property name for..."



End of comments.



July 12

Here is my review of the latest editors draft with specific comments:

1) Are there any issues that should delay the WG's release of PROV-O as
Last Call (i.e., is all of the technical work done).

No major issues. This latest version addresses the items mentioned from
this week's earlier reviews. Some possible remaining minor grammatical
fixes and some improvements for added clarity.

2) Are the examples and scenario adequate?

Yes. It adequately sets the stage for, say, how the Earth Science
community could take the Expanded Terms and qualification pattern to apply
to Earth science data processing provenance.

A minor comment on uniformity of the figures. The figures are not
consistently following the same look and feel, or shape designation of
Agents, Activities, and Entities. It may improve readability to have the
figures use the same look and feel. e.g. qualification Figure 4 uses
intuitive shapes e.g. pentagons for agents. Contrast this with figures 1 &
3 which do not differentiate types. Figure 2 does differentiate type shape
but is inconsistent with figure 4. Figures 1 & 3's arrows appears to be


3) Should the links to prov-dm, prov-constraints, and prov-n stay in the
cross reference?

prov-dm should stay.

4) More specific comments below:

1. Introduction

general: The acronyms "PROV Ontology" (PROV-O) and "PROV Data Model"
[PROV-DM] are introduced in the first sentence. But the acronyms and full
terms are both still used thereafter. Was that intentional for clarity?
Otherwise, what about sticking with the acronym after the first sentence
for uniformity?


second paragraph: 
"and thereby facilitate interoperableŠ" to 
"and thereby facilitates interoperable..."


3.1 Starting Point Terms

Two paragraphs contain prov:wasInformedBy and prov:wasDerivedFrom that are
not hyperlinked like the rest of the properties elsewhere.

RAISED repeated mentions are intentionally not hyperlinked.

3.2 Expanded Terms

In the first paragraph, "The additional terms are illustrated in the
following figure and can be separated into five different categories."
Following that sentence, explicitly stating a concise bulleted list of the
five categories would help guide the next few paragraphs of narratives on
the five categories. (Similar to how it was done at the beginning of
section 4) How about adding a bulleted list after the sentence such as the
one Paul described in his July 9, 2012 email:
 1. Extension of Starting Point Terms
 2. Entities and Abstraction
 3. Describing Entities Further
 4. Entity Lifetimes
 5. Activity Lifetimes

RAISED Paul raised this and dropped it. The intent for not including the bulleted list is to avoid over-structuring it and letting the paragraphs speak for themselves.

Some paragraphs have terms that are not hyperlinked like the rest of the
terms elsewhere.

RAISED Repeated mentions are not hyperlinked.

Second category:
"prov:mentionOf is a special type of prov:specializationOf
 whose subject presents as an aspect a particular prov:Bundle
 in which its more general Entity was described". 

was the intention 
"..whose subject presents an aspect as a particular"

RAISED I'm not sure. :-/

Second category's levels of abstraction almost hints to FRBR. Is it
worthwhile to mentioned it for reference?


3.3 Qualified Terms

Some paragraphs have terms that are not hyperlinked like the rest of the
terms elsewhere.

RAISED duplicate mentions do not get hyperlinked.

After Figure 4: change "chart making example" to "chart-making example".


4. Cross reference for PROV-O classes and properties

Are the following disjoint? Class: prov:EmptyCollection,
prov:IncompleteCollection, prov:CompleteCollection

OBE Only Empty remains.

Noticed some that/which phrasing. "that" is a restrictive clause, while
"which" is a non restrictive clause.

Property: prov:endedAtTime
- reads funny. how about changing from "The activity no longer exists
after its end." to "The activity no longer exists after it ended."


- change from "known as trigger, that terminated" to "known as trigger,
which terminated"


Property: prov:startedAtTime
- reads funny. how about changing from "before its start" to "before it


- change from "trigger, that set off" to "trigger, which set off"


Property: prov:wasGeneratedBy
- misspelling: "Entitites"

PENDING-REVIEW removed entire comment, it wasn't clear anyway.

Class: prov:IncompleteCollection
- fragmented sentence: "A collection that is believed to include more
members in addition to those specified in the entity-set."
  how about: "A collection that is believed to include more members than
those specified in the entity-set."

OBE class removed.

Property: prov:wasEndedBy
- change from "trigger, that terminated" to "trigger, which terminated"


Property: prov:wasRevisionOf
- change from "trigger, that set off" to "trigger, which set off"
- change from "starter, that generated" to "starter, which generated"
- change from "trigger, that initiated" to "trigger, which initiated"


Class: prov:AgentInfluence
- change from "intended to be an general" to "intended to be a general"


Class: prov:InstantaneousEvent
- change from "instantaneous events (or just events), that mark
transitions" to "instantaneous events (or just events), which mark

Class: prov:Source
- change from "as trigger, that set off" to "as trigger, which set off"
- change from "as starter, that generated" to "as starter, which

Property: prov:atTime
- change from "instantaneous events (or just events), that mark
transitions" to "instantaneous events (or just events), which mark


Property: prov:hadRole
- should we change "assumes" to past tense for consistency? "The
_optional_ Role that an Entity assumes in the context of an Activity."

PENDING-REVIEW now 'assumed'

Property: prov:qualifiedEnd
- change from "as trigger, that terminated" to "as trigger, which
- change from "as ender that generated" to "as ender, which generated"

Property: prov:qualifiedStart
- change from "as trigger, that set off" to "as trigger, which set off"


A. PROV-O OWL Profile

Last paragraph: add comma before nonrestrictive "which". Change from "OWL
2 Full profile which also understands the unions." to "OWL 2 Full profile,
which also understands the unions."




First of all, thumbs up for the prov-o team. This is a very good document. I consider this ready for release as of PROV-O as Last Call.
I only have some minor comments listed below. The document reads well, is clearly structured and the examples and scenario are clear. Furthermore, I suggest to keep the cross references with the PROV-DM, PROV-N and PROV-CONSTRAINTS documents.

PENDING-REVIEW: provo team agreed to use DM only and remove N and constraints.

Minor comments on PROV-O:

Section 1: Introduction

Second paragraph,first and last sentence are the same. "PROV-O conforms to the OWL-RL profile and is lightweight so that ..."

PENDING-REVIEW removed second occurrence.

Section 3.1: Starting Point Terms and Section 3.2: Expanded Terms and Section 4.1 (prov:Agent)

Examples: <> instead of <>


Section 3.2: Expanded Terms

Figure 2: Location arrow is not connected to any class.

PENDING-REVIEW: That was intended. Added to the caption that domain of atLocation was omitted in illustration (and gave it in caption).

Section 3.3: Qualified Terms

I would consider putting the example before the two tables listing the properties that can be qualified. This makes the section easier to read and to understand, otherwise you get the tables right away and get lost in them.

RAISED: At least someone has suggested one of {table, example, diagram} to go first, so we can't please everyone.. Not sure how to resolve this.

"In subfigure a the ... of prov:Usage, which in turn ..." instead of "in trun"


Section 4

prov:alternateOf, prov:mentionOf, prov:specializationOf: Definition is wrong, maybe not yet cleared out?

PENDING-REVIEW done. fixed by a bug earlier today.

prov:ActivityInfluence, prov:AgentInfluence, prov:EntityInfluence :Definition is missing here, but they are given a little later at prov:activity, prov:agent and prov:entity. Just a little confusing, when reading the document.

PENDING-REVIEW cross-reference generator updated to expose the prov:editorsDefinition, which now appears for all 3 classes mentioned.

prov:ProvenanceService, prov:hasAnchor, prov:hasProvenance, prov:hasProvenanceService, prov:provenanceURITemplate: These properties need to be introduced. (They come from PAQ, thus maybe a link to PAQ?)

PENDING-REVIEW These terms were removed from provo, will be described in paq.html and paq.owl