Prov-o draft review 2 April 2012
From Provenance WG Wiki
This page is managing the feedback from the four reviews of
Changes are being reflected at http://aquarius.tw.rpi.edu/prov-wg/prov-o
Luc's feedback is archived in this email.
Luc ---------------------------------------------------------------------- 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.
PENDING-REVIEW(Luc) Removed ref to OWL2-DIRECT-SEMANTICS. Did you want OWL2-RDF-BASED-SEMANTICS gone, too?
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 http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/spwd/for-internal-wg-review/prov-o.html#prov-starting-point-owl-properties-at-a-glance ? It has:
If I had to "logically order", I'd do:
Would that be better?
5. provo:Trace but provdm:Traceability. We should adopt a single term. I don't mind which.
RAISED(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?
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.
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 . :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 .
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 .
(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.
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
25. prov:hadActivity, prov:hadGeneration, prov:hadUsage must be made functional
26. prov:qualifiedInsertion and prov:qualifiedRemoval should be made inverse functional
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) http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-n.html#expression-types 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"
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 Thanks, Simon
Paul's feedback is archived in [<http://www.w3.org/mid/CAJCyKRqCRQFRp2HxUBaQNHN94+uxJoE00Q7_tuZocvT4tF3zJw@mail.gmail.com this email].
I reviewed PROV-O at http://dvcs.w3.org/hg/prov/raw-file/tip/ontology/spwd/for-internal-wg-review/prov-o.html First, great job. This is a nice product to work with. Especially, the connection between the owl and the document. Good job Tim and everyone. I have formatted my comments below in markdown so it's best to read in a markdown viewer. Thanks Paul #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.
OPEN(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.
OPEN(Tim) infrastructure added. Examples need to be populated at http://dvcs.w3.org/hg/prov/file/tip/examples/eg-24-prov-o-html-examples/rdf/create/rdf https://www.w3.org/2011/prov/track/issues/349
* 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. http://aquarius.tw.rpi.edu/prov-wg/prov-o#Activity
* 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.
##Collections## * 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 created.
##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)
* 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 http://aquarius.tw.rpi.edu/prov-wg/prov-o#Agent
* 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# ##Annotations## * 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 somewhere.
* 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. Best, Sam 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 http://www.w3.org/TR/2011/WD-prov-dm-20111018/#prov-asn--the-provenance-abstract-syntax-notation explaining the motivation behind using ASN. The above referenced section in PROV-DM does a great job of briefly providing the rationale.
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. E.g. 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 PROV-O HTML and OWL. http://www.w3.org/2011/prov/track/issues/336 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 -- <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html> (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 - <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#Activity> - <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#Agent> - <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#Entity> But not seen in - <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#actedOnBehalfOf>
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 <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#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 <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#description-starting-point-terms> 5. The diagram (and explanatory text) lacks prov:wasStartedBy (and new sub-property/ies prov:wasStartedByActivity and prov:wasStartedByAgent).
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 <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#description-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 (ex:postContent1)."
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 <http://dvcs.w3.org/hg/prov/raw-file/fb23031cf708/ontology/spwd/2012-04-18-vote-for-public-release/prov-o.html#description-collections> 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, Ted