Prov-o draft review 2 April 2012

From Provenance WG Wiki
Jump to: navigation, search

This page is managing the feedback from the four reviews of

Changes are being reflected at


Luc's feedback is archived in this email.


Answer to questions:

* Does the HTML file provide an adequate overview of the OWL design elements?

Sections 1 to 3 are great. Section 4,  automatically generated I believe, need more attention.

* Do the different organizations of PROV-O HTML and DM complement each other, or is it distracting?

I am not against a different organization. It makes sense to discuss, for instance, the qualified
pattern in the context of the ontology.

My only question is the apparent importance of collections. I would tend to downplay them.


References to the provdm:components are not explained. It linked to
nowhere.  What were the colors for (beyond being the ones in dm)?


* Would any additional comments (or attributes) help you read the cross reference list in PROV-O HTML?

Section 4 is arid, and not systematically handled. Suggestions below.

* Are the comments within the OWL file adequate to familiarize with the structure? If not, what kinds of comments would help?

See suggestions below.

* Should the OWL file contain any links to documentation (e.g., to the DM, to examples, etc.)?

I think it's a question that may also apply to other specs, including
prov-dm. Is it worth linking to constraints?

* Can the document be released as a next public working draft? If no, what are the blocking issues?

Yes, absolutely.  None of the issues I flagged here is blocking.


My comments:

Great piece of work. Sections 1 to 3 read nicely.
Section 4 is a bit arid, some improvement is desirable.

1. SOTD.
 It must be clear to the reader what order documents need to be read in.
 Suggest reusing SOTD from prov-dm.

OPEN(Tim->Luc) Is there respec magic to pull from DM's sotd? Where is the pre-respec original source of the working drafts?

2. section 1: remove reference to OWL semantics.


3. section 1: the prov-dm document no longer contains this example.
   I suggest that you make your presentation self-contained.

PENDING-REVIEW(Luc) changed it to "To demonstrate the use of PROV-O classes and properties, this document uses an example provenance scenario similar to the one introduced in the PROV-Primer PROV-PRIMER."

4. When the ontology stabilizes, you need to manually layout the box with all
  classes and relations.  Alphabetical order is not useful here. I would
  prefer to see a more logical ordering.

RAISED(Tim->Luc) Are you referring to the ? It has:

  • prov:actedOnBehalfOf
  • prov:endedAtTime
  • prov:startedAtTime
  • prov:used
  • prov:wasAssociatedWith
  • prov:wasAttributedTo
  • prov:wasDerivedFrom
  • prov:wasGeneratedBy
  • prov:wasInformedBy
  • prov:wasStartedByActivity

If I had to "logically order", I'd do:

  • prov:startedAtTime
  • prov:used
  • prov:wasGeneratedBy
  • prov:endedAtTime
  • prov:wasDerivedFrom
  • prov:wasAssociatedWith
  • prov:wasAttributedTo
  • prov:actedOnBehalfOf
  • prov:wasInformedBy
  • prov:wasStartedByActivity

Would that be better?

5. provo:Trace but provdm:Traceability.
  We should adopt a single term. I don't mind which.

PENDING-REVIEW(Tim->Luc) The other kinds of DM Derivation are nouns ( 4.3.1 Derivation 4.3.2 Revision 4.3.3 Quotation 4.3.4 Original Source) Can we change DM to Trace? (it now appears that DM uses "Trace")

6. Section 3, text following figure 1 refers to wasStartedBy instead of wasStartedByActivity

PENDING-REVIEW(Luc) fixed. And added them as links.

7. section 3: a picture (in PROV style!) would be desirable to illustrate the example


8. section 3.1: the example includes prov:Organization which is a term defined in section 3.2.


9. Is it necessary to see both foaf:Organization and prov:Organization?
                              foaf:Person and prov:Person?


10. Section 3.2: example has not the correct namespace. Need to check everywhere.

OPEN(Tim) need to edit

11. Section 3.3:
    choice of name: you have prov:qualifiedUsage, etc
                    why not simply prov:usage?

Jun: Because these properties are to be used for expressing "qualified relationships". I think with a qualitied- "prefix", it's easier for people to realize that this is a qualified property. Without it, prov:usage becomes vague and less straightforward, and people have to go and read documentation to understand what this is about.

CLOSED(Luc) "qualified" before each of these is a grouping mechanism in place of what was the prov:qualified super property.

So that these properties follow the same pattern.

## Unqualified form:
:res :unqual :reso .

## is qualified as:
:res prov:qualifiedXX :involvement .

   a prov:XX;
   prov:entity     :reso;
   # or
   prov:activity   :reso;
   # or
   prov:agent      :reso;
   # or
   prov:collection :reso;

12. section 3.3. needs to explain why the qualified pattern is necessary.
   It should say that:  :a prov:used :e means that there is *some* usage of :e by :a
       (possibly more than one!)
   instances of prov:Usage allows usages to be distinguished and counted.

   Also, the pattern allows the expression of a given activity using a given entity,
   multiple times, at different moments.


13. section 3.3 last example: ex:usage, ex:generation, ex:activity are not defined.
   It would be good to see, in particular, ex:usage and ex:generation
   Maybe the names are not great for these instances.

OPEN(Tim) add "_1" and add their descriptions.

14. section 3.4: is the rdf correct?
      :c1 a prov:Collection . <-
           prov:derivedByInsertionFrom ...
   Indentation is not clear either.

CLOSED(Luc) all three collection examples now pass syntax check and had their indent fixed for readability.

15. section 3.4: knownMembership
    I don't think it's a good name for this property. It should be membership,
    since it may be known, inferred, or guessed.

CLOSED(Tim) changed in OWL file and provrdf.

16. Generally speaking, it's quite advanced to see an example on collections so early.
   It seems to give importance to this kind of concept that does not reflect its real
   importance. It's also one of the most speculative bit in the model.


17.  Section 4 is  quite arid to read from beginning to end.
   But I appreciate it's designed mostly for online navigation.

   Generally, section 4 should handle all terms systematically.
   - use the prov-dm definition


   - illustration with an example (generally, these need to be formatted properly,
     otherwise they are not readable)


   - further comments,

OPEN(Tim) there are further comments in OWL, I just need to reconcile styling and presentation.

   - etc.
   - characteristics do not seem to be expressed for all (see below)


   some terms currently have no comment.


18. Definition of agent in section 4 is not the same as in 3.1

OPEN(Tim) section 4 is from DM, need to update 3.1.

19. Text about properties should adopt a same style.

   prov:wasGeneratedBy:  wasGeneratedBy links Entities ...
   prov:used:  A prov:Entity that was used by ...


20. Account: is defined in terms of a mechanism?
   In any case, that's an issue to solve for PROV

RAISED(Tim) that's what DM said recently.

21. traceTo is supposed to link to and from Agents, but they are not listed in domain/range.

OPEN(Tim) That's what I thought it was, but then I thought it was changed to JUST entities (Per Paolo's review on the OWL draft review).

22. prov:Start/prov:End/prov:Generation ... are defined in terms of event as in part II, and not as in prov-dm part I.

RAISED(Tim->Luc) - need some clarification on this.

23. Role is defined in the context of usage, generation, association, start and end,
  but hadRole has all involvments in its domain, including derivation and collection-derivations.

CLOSED(Luc) This is a perennial complaint that can't be fixed using only RL. Also, the axioms do not support this "Derivations must have prov:hadRole" interpretation.

from Jun email:

I think this has is also related to thread [1].

Such similar feedback have come several times. And I would like us to consider two additional things:

1) The prov-o is an OWL-RL ontology that implements DM. Given the set of semantics that can be expressed using OWL-RL, we couldn't have a one-to-one implementation of DM, just like a prov-xml schema cannot either. It's a compromised made for implementation.

2) Even if we do have a perfect prov-o implementation of DM, there is still nothing we can do to prevent people from using it wrongly or saying stupid things. The abuse of ontologies/vocabularies on the Semantic Web is nearly universal.

3) A possibility of saying something is different from being able to automatically infer that something. Our use of OWL-RL does provide a possibility for users to associate a derivation with a role, but the RL semantics would *not* infer that if something is a derivation, then it must have some sort of role. This is the best I can do for explanation and I hope I got it right:). A sensible user of prov-o, if read the spec properly, then would/should not have abused "hadRole".

See also Tim's original example in [2].

(prov:hadActivity rdfs:domain prov:Involvement .

s prov:hadActivity :a

s a prov:Involvement

this is different than saying:

q a prov:Quotation

q prov:hadActivity :activity)

The current implementation of prov-o is a compromise that we made so that we can use OWL-RL. A justification of OWL-RL is a separate issue. The prov-o team were strongly advised to use OWL-RL and that's what we did. I don't think you are *not sympathetic* of their situation and the problems that they had to deal with or had dealt with. :)

I suggest what we can do with this problem is in section 4, when we define the properties like "hadRole" or "hadActivity", we make it clear what/how we exactly expect people to use these properties.

Would that sound like a good compromise to you? If you do, then we will act upon that.

[1] [2]

23 prov:Source.  Do we need to introduce a class for this? Why not just use Entity?

RAISED(Luc) prov:Source is not the sourced Entity, but the qualification between the derived Entity and the sourced Entity. prov:Source is in the same neighborhood as prov:Derivation, prov:Quotation, etc.

24  prov:agent, prov:entity, prov:activity must be made functional

CLOSED(Tim) done.

25. prov:hadActivity, prov:hadGeneration, prov:hadUsage must be made functional

CLOSED(Tim) done.

26. prov:qualifiedInsertion and prov:qualifiedRemoval should be made inverse functional

CLOSED(Tim) done.

27. Delete appendix A since it is out of date.

OPEN(Tim->Luc) delete or update? Is this needed in the final version?


Simon's feedback is archived in this email.

The PROV-O document is good, reads well and is well structured. Section 4 especially will be a handy reference, 
and contains the key information succinctly. I have no reason to block the document's release.

Most of my comments are minor and about presentation. I highlight those about content with a *.

Section 1:
The 2nd paragraph says that the document uses the example scenario from the primer, 
while the 7th paragraph says it uses the example from PROV-DM. I think the former is closer to the truth.

PENDING-REVIEW(Simon) The 7th paragraph was removed.

The 6th paragraph refers to "Classes and Properties", but this capitalisation is not used before or after.

PENDING-REVIEW(Simon) lower cased this.

7th paragraph: "creation of crime statistics file" -> "creation of a crime statistics file"

PENDING-REVIEW(Simon) This paragraph was removed.

Section 2:
4th paragraph: "While those relations are..., these terms are..." It is unclear what "those" and "these" refer to.

PENDING-REVIEW(Simon) changed to "While the relations from the previous two categories are applied as direct, binary assertions, the terms in this category are used to provide additional attributes of the binary relations."

Section 3.1:

The definition of Entity now needs updating to match the current DM following recent discussions, I think.


* 3rd paragraph: "derivation, which is used to specify that the creation/existence of an entity was influenced 
in some way by the consumption of another entity." This doesn't seem to match the DM definition or my intuition. 
Why does the earlier entity need to be consumed? Why is it only the creation/existence that it is influenced 
and not the attributes/content/nature?


While I understand the example is not meant to exactly match the primer's, you might want to update it to
 match the current primer in a couple of regards. Stian suggested that "Chart Generators" should be 
"Chart Generators Inc" to avoid it sounding like an activity. 

OPEN(Tim) need to update dropbox, push to hg, and pull to aqua

Also, the primer now uses the less 
verb/noun-ambiguous "compose" rather than "aggregate".

OPEN(Tim) need to update dropbox, push to hg, and pull to aqua

Section 3.2:
1st paragraph: "to describe address" -> "to describe the address"


Section 3.3:
* I note that PROV-O has a Plan class, but PROV-N has no equivalent (I'll make the same remark in my 
review of PROV-N). This may be fine, but readers may find it odd and translation between the formats 
might easily miss declaring something to be a Plan.

PENDING-REVIEW(Simon) now has prov:Plan reserved.

* Why is "Responsibility" the qualified name for actedOnBehalfOf and not wasAssociatedWith, when the latter 
defines responsibility and the former only defines delegation?


* Why is there a discrepancy between the names of wasInformedBy and Communication? It isn't so important, 
but will make RDF containing both qualified and unqualified relations harder to interpret without matching names.

RAISED(Simon) I totally agree, but this is a DM issue, no?

Section 3.4:
* Why does prov:key have range Literal? If my collection is a webpage and I want to refer to an element which 
is a logo image in the top-right corner, then I'd prefer to use a structure of RDF statements to describe that 
position. Requiring a literal seems a little limiting.

RAISED(Simon) (This is a DM issue, no?) I agree, having a Value (i.e., URI) as a key would be more flexible, but becomes heavier weight. I reconciled my identical concern by convincing myself that the literal value is implicitly contextualized by the collection containing it.

Penultimate paragraph: ":c2, which content" -> ":c2, whose content"

PENDING-REVIEW(Simon) changed.

Section 4:
* Why do most terms include definitions, but some do not? It would be good to check for consistency.


Update definition of Entity following recent discussions.

RAISED(Simon) where is the authoritative "new" definition? Once it makes it to DM, I can push it to PROV-O.

* Location is defined such that it "can also be a non-geographical place such as a directory, row or column". 
This sounds like it directly relates to collection keys and the text at the start of Section 3.4, but no connection is made explicitly.

RAISED(Simon) Very good point. But is a connection made explicitly in DM? Are you proposing that prov:key is a rdfs:subPropertyOf prov:hadLocation? If so, the ranges would need to be reconciled (datatype vs. object).

* Shouldn't wasRevisionOf have super-property alterateOf (as well as wasDerivedFrom)? Isn't part of its
 meaning that it is the both domain and range of wasRevisionOf are revisions of a common thing?

OPEN(Tim) I agree that prov:wasRevisionOf should be subpropertyOf alternateOf. Your second question seems like a reasonable argument for that.

Answers to questions:

Does the HTML file provide an adequate overview of the OWL design elements?
= Yes.
Do the different organizations of PROV-O HTML and DM complement each other, or is it distracting?
= Seemed fine to me. Each should be structured to best convey what they need to.
Would any additional comments (or attributes) help you read the cross reference list in PROV-O HTML?
= I personally liked the brevity but, as mentioned above, all terms should include their definitions.


Are the comments within the OWL file adequate to familiarize with the structure? If not, what kinds of comments would help?
Should the OWL file contain any links to documentation (e.g., to the DM, to examples, etc.)?
= As emailed, I was not clear which OWL file to look at

PENDING-REVIEW(Simon) Sorry for the confusion. The end of the abstract now states "The OWL encoding of the PROV Ontology is available here."

Can the document be released as a next public working draft? If no, what are the blocking issues?
= Definitely



Paul's feedback is archived in [< this email].

I reviewed PROV-O at

First, great job. This is a nice product to work with. Especially, the
connection between the owl and the document.  Good job Tim and

I have formatted my comments below in markdown so it's best to read in
a markdown viewer.


#Responses to Editor's Questions#

* Does the HTML file provide an adequate overview of the OWL design elements?
   * Yes.
* Do the different organizations of PROV-O HTML and DM complement each
other, or is it distracting?
   * I think it's fine as it is. It seems that it takes a different
approach which is fine. I think one should avoid introducing the dm
organization into the prov-o.

CLOSED(Tim) references to DM components were removed in the cross reference section.

* Would any additional comments (or attributes) help you read the
cross reference list in PROV-O HTML?
   * I wonder if one example for each of the constructs should appear
in the cross reference list.

CLOSED(Tim) infrastructure added. Examples need to be populated at

   * A link to the prov-dm document would be good.

OPEN(Tim) They are in the OWL already, just a matter of exposing it in the cross reference script.

* Are the comments within the OWL file adequate to familiarize with
the structure? If not, what kinds of comments would help?
   * Their great. I've asked for some clarification and additions below.
* Should the OWL file contain any links to documentation (e.g., to the
DM, to examples, etc.)?
   * Yes.. see my comments on the annotations of the ontology below.


* Can the document be released as a next public working draft? If no,
what are the blocking issues?
  * Yes. Great work. It's time for the community to see what they think.

# Comments on Document #

## Status of the Document ##

* it would be good to see links to the provenance ontology


* There should be a brief description of the changes since the last
working draft.


## Introduction ##

* I think a link to the ontology itself should be very visible in the
introduction. e.g. "The ontology can be downloaded from here"

PENDING-REVIEW(Paul) done in the abstract.

* The namespace should be more visible in the introduction.


* The following sentence is repetitive - "The PROV Ontology can be
used directly in a domain application, though many domain applications
may require specialization of PROV-O Classes and Properties for
representing domain-specific provenance information."


* OWL-RL is just mentioned. Does this need to be motivated?

PENDING-REVIEW(Paul) Rephrased to "PROV-O conforms to the OWL-RL profile and is lightweight so that it can be adopted in the widest range of applications." and introduces the paragraph on extensibility.

## PROV-O at glance ##
* The classes and properties should be labelled as such in the boxes.

PENDING-REVIEW(Paul) "Class: " or "Property:" appears before the qname/curie in each entry in the cross section.

* It says "additional terms that can be used to relate classes in the
Starting Point category." - is it just used to relate starting point
classes? Maybe a revised sentence could be "additional terms that can
be used to augment provenance information expressed using constructs
from the Starting Points category"


* I wonder if collection classes and properties should become a
subsection or linked from the expanded classes and properties section.
In general, to me they are on par with these other notions and it
seems that we both over and understate their importance with a
separate section.

OPEN(Tim) agreed. this fits well under the intention of "expanded" as additional / specializations of the starting points.

##The PROV-O Ontology Description##
* I really like the diagram!
* It would be good to put links to the definition of the properties as
you introduce them. 


Maybe actually drawing out these definitions as
bullet points ws would be good.


* In the example, can we change the organization from "civil action
group" to "external organization" or a "newspaper"


* The explanation of the example is hard to read because of the
examples in orange.

RAISED(Paul) what do you suggest?

A picture of the example would be good here.


##Expanded Terms##
* Not all the terms are introduced. The section kind of stops with the
example. I would suggest saying that either that this is just an
example or introduce more of the terms


* You talk about shortcuts but what this means is not clear. This
should either be dropped or expanded.


##Qualified Term##
* Great section. Really shows how to use qualification.
* The Qualified Pattern is introduced but I would expect the pattern
itself in its generic form to be introduced and then an example of its
application given.


* A diagram would be especially helpful here showing how each
collection is built up.


* I would emphasize that this is not to represent collections
generically but to represent how collections are constructed or


##Cross reference##
* A very nice reference over all.
* I would remove "in PROV component", it's confusing.

PENDING-REVIEW(Tim) it is removed now.

* The notation should be introduced (e.g op and dp)

PENDING-REVIEW(Tim) added to

* Some of the classes and properties are missing definitions. I assume
this can be fixed by importing from prov-dm

OPEN(Tim) Jun has added rdfs:comments, prov:definitions of classes are there, Tim still needs to work infrastructure to get properties to reuse definitions of their qualifiedForms (some owl annotations and pythoning).

* What is a property and what is a class should be denoted more
clearly. e.g. Class - prov:Activity

PENDING-REVIEW(Tim) prepending "Property" or "Class" now: e.g. "Property: prov:wasAttributedTo" at

* In some places there are additional notes for example in prov:Derivation:
An instance of prov:Derivation provides additional descriptions
about the binary prov:wasDerivedFrom relation from some prov:Entity
to another prov:Entity. For example, :chewed_bubble_gum
prov:wasDerivedFrom :unwrapped_bubble_gum; prov:qualified
[ a prov:Derivation; prov:entity :unwrapped_bubble_gum; :foo :bar ].

   * These should be set-off some how. I assume these are "usage
notes" or something like that.


* There should be a link to the prov-dm definition.


#OWL Document#

* It would be good to define your annotations in the comments to the
owl file. For example, I didn't first grasp the difference between
category and component in the annotations. This could be also given in
the comments of the annotation definitions.

CLOSED(Tim) emailed Paul asking if he has a solution in mind. 16 Apr. Jun and Tim added rdfs:comments directly in the file.

* The class hierarchy is nicely balanced. However, there are some
things that stick out. For example, KeyValuePair, Membership and
Location all seem to be dangling. I wonder if we can collect these


   * Is Membership an Involvement?


* In the comments of Involvement should we note that this is used for
organization purposes?


* properties do not seem to have rdfs:label


* refs:label need to be defined with their language tag


* should we define the category and component with urls. Currently, we
are using keywords to define our vocabulary here. It seems that being
able to dereference these definitions would be good.

RAISED(Paul) we could put them into the ontology as instances with comments. Oh, wait - this is a prov:Collection!

* The links to the dm are nice as annotations.
* __How do we integrate "strings" in the ontology?__ This is important
because we need good ways to integrate application data into the
ontology. I think there should be some patterns to adding these
strings and these should be clear. For example, we may mint new urls
for each entity, but for example, with a quote we may want to easily
add some text.


* It would be good to have back pointers to the ontology document
itself as annotation properties.

OPEN(Tim) using rdfs:isDefinedBy ?

* Hmm… I wonder how in the ontology we can point people to the
involved set of properties, as these are actually the core but it's
not what one sees at the top-level



Sam's feedback is archived in this email.

Below you can find the review. It looks very good and I could only point out some minor things. I recommend it as a public working draft.



Review PROV-O

The document provides certainly a good overview of the design elements of PROV-O. It is well structured and easy to understand and 
to follow. PROV-O and PROV-DM complement each other. Since prior knowledge of PROV-DM is a must, I would insert a link to that document 
in the ontology. 


It is essential background information and provides the rationale behind certain design elements of the PROV-O ontology. 
The examples are not essential in understanding the PROV-O ontology, so I would only include these examples in the html document of PROV-O, 
not in the ontology itself.

The PROV-O documentation can be released the next public working draft.

Some minor comments:

Section 3.1: PROV-O distinguishes between two kinds of dependencies which are specified using the properties wasInformedBy 
and wasStartedBy --> wasStartedByActivity. wasStartedBy is an expanded property, thus I think using wasStartedByActivity is more appropriate.


Section 3.4: Here, prov:Collection is defined. This section needs a motivation why prov:Collection is introduced and why no other collection representation is chosen.


Section 4.2: specializationOf Can`t this property be made transitive? If not, a motivation would clarify this.


Section 4.2: wasRevisionOf Is a revision directly related to the previous `version` of an entity? If not, this property can be made transitive.



Section 2.1:

“As a reader I thought it would be helpful to have a link on the
“Abstract Syntax Notation (ASN) to take me directly to
explaining the motivation behind using ASN.  The  above referenced
section in PROV-DM does a great job of briefly providing the

OPEN(Tim) make sure SOTD covers this concern.

Section 3.1

Direct links corresponding from PROV-O class to PROV-DM model element
would make references between the two documents more intuitive.


Class Description
Entity is defined to be "An Entity represents an identifiable
characterized thing."



Ted's feedback is archived in this email.

All --

On Apr 2, 2012, at 04:12 PM, Timothy Lebo wrote:
Please see ISSUE-336 for the information about reviewing

Apologies for the delay in my review.  

Given the progress made on PROV-O, I've written the following 
with reference to the *current* version, approved April 19 for 
release as FPWD2 --


(Working Drafts being essentially heartbeats that demonstrate work 
is active, and progress is being made, I saw no need to block this 
release... but these comments remain important.)

First, to the key questions --

* Does the HTML file provide an adequate overview of the 
 OWL design elements?

As things stand, yes.

* Do the different organizations of PROV-O HTML and DM 
 complement each other, or is it distracting?

Their differences are fine.

* Would any additional comments (or attributes) help you 
 read the cross reference list in PROV-O HTML?

1. Remove the redundant explanatory text.  It should not follow
  *both* IRI and Example.  Given my choice, I'd say the better
  positioning is between IRI and Example; not between Example
  and Domain/Range/SuperProperty/SubProperty/etc.

  Now seen in at least
  - <>
  - <>
  - <>

  But not seen in
  - <>


2. I would appreciate a repeat of Figure 1 at the start of 
  section 4.1.  


  I would also appreciate a complete
  set of illustrations similar to Figure 2 at the start 
  of section 4.2 


  (and I would find such a complete set of
  illustrations more useful in Section 3.3 than the tables
  with which it currently concludes; I would not necessarily
  *replace* the tables, but the illustrations are *very*
  helpful to correct understanding).

* Are the comments within the OWL file adequate to familiarize 
 with the structure? If not, what kinds of comments would help?
* Should the OWL file contain any links to documentation (e.g., 
 to the DM, to examples, etc.)?

* Can the document be released as a next public working draft? 
 If no, what are the blocking issues?

As noted earlier... Yes.

And now... in depth.

3. First thing, an overall style note for the example notation.  
  I have found that adding extra space characters to pad columns, 
  such that logical columns also *appear* as such, radically 
  increases comprehension.  You can see a bit that (almost) does 
  this in the last stanza of the "Qualified Derivation" example.  
  (I'd add spaces between "a" and "prov:Derivation;" to make the 
  first line match the ones beneath it.)


re: 2. PROV-O at a glance

4. prov:wasStartedByActivity and prov:wasStartedBy should swap 
  positions, between "Starting Point classes and properties"
  and "Expanded classes and properties".  The former is clearly
  a refinement of the latter.


  Further, I think there should be a new prov:wasStartedByAgent
  (and *possibly* prov:wasStartedByEntity, if an Entity can 
  act...), parallel to prov:wasStartedByActivity.

RAISED(Ted) This is an issue on DM, not prov-o.

  It seems to me that prov:wasStartedBy is the indefinite super-
  property, used when you *don't know* what class started the 
  current Activity, with subproperties of prov:wasStartedByAgent 
  and prov:wasStartedByActivity (and *possibly* 
  prov:wasStartedByEntity), which are used when you *do* know 
  the class of the starting, er, entity (not prov:Entity, but 
  general RDF entity).

RAISED(Tim) This is a clean approach, but not what DM says.

  Those changes will necessarily have reflections throughout 
  the following and connected documents... 

re: 3.1 Starting Point Terms

5. The diagram (and explanatory text) lacks prov:wasStartedBy
  (and new sub-property/ies prov:wasStartedByActivity and 


6. I think it's important to clearly state that an RDF entity 
  which is a prov:Agent or prov:Activity in one Provenance 
  document, may be a prov:Entity in another; that an RDF 
  entity which is a prov:Entity in one document may act as 
  a prov:Agent or a prov:Activity in another -- which is all 
  to say, that a prov:Agent or prov:Activity may have its 
  own Provenance...

OPEN(Ted) "The provenance of an prov:Agent may be provided by describing the agent as a prov:Entity, either in the same provenance document or another."

7. This phrasing is problematic --

  "Entities are related to each other using derivation, which is 
  used to specify that the creation/existence of an entity was 
  influenced in some way by the consumption of another entity."

  "Consumption" implies to me some shrinkage or change of the 
  "consumed" entity.  I think this is not necessary, and thus 
  that this wording should change to something like --

  "Entities are related to each other using derivation, which is 
  used to specify that the creation/existence of an entity was 
  influenced in some way by another entity, whether by its simple 
  presence or existence (as with chemical catalysts), physical 
  interaction and/or consumption (as with chemical reactants), 
  or otherwise."


re: 3.2 Expanded Terms

8. "Derek detects a typo. He doesnt' want to record"

  I detect a typo.  "doesnt' want" should be "doesn't want"

CLOSED(Tim) got it. expanded to "does not want"

9. This wording is confusing to me --

  "Thus, the location of the new revision has the same permalink, 
  but a different url for its snapshot (ex:postContent1)."
  The "permalink" abbreviation only replaces 2 words ("permanent 
  link"), but here tries to replace a much larger phrase from the 
  preceding paragraph ("permanent link where the content of the 
  latest version is shown")

  I think this would be better --

  "Thus, the permalink to the latest version 
  (ex:more-crime-happens-in-cities) remains the same in the new 
  revision, but a different url is given for its snapshot 

PENDING-REVIEW(Ted) agreed. I changed to your phrasing.

  I suggest also tweaking all matching lines in the example 
  block, from --

     prov:atLocation ex:more-crime-happens-in-cities;   ##PERMALINK of the post

-- to --

     prov:atLocation ex:more-crime-happens-in-cities;   ##PERMALINK to the (latest revision of the) post

PENDING-REVIEW(Ted) Thanks, that is much clearer, especially for those that are not as familiar with blogs.

re: 3.4 Collections Terms

10. I think there's an error in this text --

   "The example below specifies that the collection :c1 was 
   obtained from the empty collection :c1 by inserting the 
   key-value pairs ("k1", :e1) and ("k2", :e2)."

   I think that the "empty collection" here is ":c" not ":c1".

PENDING-REVIEW(Ted) You're right. Changed.

Though I began this cycle at the conclusion of last week's call,
I've only gotten this far to this point (the morning of this
week's call) ... but it seems better to put this partial review
out now, than to delay it further.

Speak with you soon,