> Hi Luc, all.
  > 
  > I have gone through the latest draft. I think you and Paolo have done
  > a very good job. You will find my feedback below, although I just
  > realize that some of my points overlap with the ones posted by Khalid.
  > Best, Daniel.
  > 
  > Document reviewed:
  > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120614/prov-dm.html
  > 
  > Questions for the reviewers:
  > 
  >    1. Can the document be released as a WD? Yes, but take into account
  >    the comments about contextualization (I think it is not necessary)
  >    2. Can the document be released as a last call WD? Same response as the previous one.
  >    3. Renaming wasRevisionOf to wasRevisedFrom? +0. Both terms are ok.
  >    4. Primitive datatypes. Do we have to list them all? I think that
  >    for prov types makes sense, but table 8 is unnecessary.
  > 
  > Detailed feedback:
  > 
  > Abstract:
  > 
  >     Provenance is information about entities, activities, and people,
  > involved in producing a piece of data or thing.  I think that:
  > Provenance is information about entities, activities and people
  > involved in producing a piece of data or thing is easier to read.

Removed comma after people.

  > 
  > STATUS:
  > 
  > PROV-O is not an OWL-RL profile completely. The prov-o team decided to
  > relax a bit the constraints in order to be able to be closer to prov
  > dm.
  > 
  > 2. PROV Overview:
  > "A provenance description is an instance of a core and extended
  >     provenance structure described below. " I don't understand very
  >     well this sentence. Provenance description is referred to a lot of
  >     times along the document, but the only definition I found was this
  >     sentence. Please clarify.

Just said "OWL2"

  > 
  > 2.1 Prov Core structures
  > Typo: the title of figure 1 is not placed under the figure.

Fixed.

  > 
  > "In the Core of PROV, all relations are binary".
  > 
  > So we have 2 different relationships for qualifications? are used (a1,
  > e1) and used(a1, e1, [ prov:role="inpu1" ]) different?  This is what
  > it looks when you read this line, and in DM both usages are the same
  > relation. Thus I suggest to remove the binary vs n-ary distinction.

I don't understand why.  We agreed that the core is formed of binary relations.

  > 
  > 2.1.1
  > 
  > "In PROV, things we want to describe the provenance of are called
  > entities and have some fixed aspect."  I would change sentence to "In
  > PROV, things we want to describe the provenance of are called
  > entities.", since you are not saying what a "some fixed aspect" is.

This definition was agreed by the WG.

  > 
  > In usage definition, the activity could not have been affected by the
  > enitity. I remember discussing in PROV-O scenarios where an activity
  > uses the same entity twice with different roles to produce different
  > results. According to this definition, that scenario would not be
  > possible. Therefore I suggest to remove the "affected" part of the
  > definition. This also applies for section 5.1.4.
  > 


Khalid had a similar comment. The definition is with respect to a
given usage.


  > (After example 3)
  > "This is answered by considering that a single artifact may correspond
  > to several entities;" We have not talked about artifact until now. I
  > suggest to change "artifact" with "thing", which has been already used
  > befor in the examples.  We find the artifact reference again at the
  > end of the paragraph : "This breadth of provenance allows descriptions
  > of interactions between physical and digital artifacts"


Artifact is to be understood with its usual meaning.

  > 
  > 2.2.2
  > 
  > Example 13 is not an example, it is just an explanation of the
  > definition. I suggest to rephrase it as an example (one could be
  > having many provenance descriptions about a resource, and a client
  > that wants to see who did them in order to filter them by creator or
  > date of creation)

OK, updated.
  > 
  > Section 3
  > 
  > "PROV-N optional arguments need not be specified:"
  > ->
  > typo: PROV-N optional arguments need not TO be specified:

No change required.

  > 
  > 4.1
  > Caption of figure 2 is out of place. Also happens in figure 3 (section 4.2).

Fixed.
  > 
  > 5
  > 
  > Table 5. I think there is a typo with Revision, Quotation and Primary
  > Source. They do not appear as relationships.

I am not sure what you refer to. Figure 5 is for component 1.

  > 
  > Figure 5: the title is not centered under the figure.
  > 
  > 5.2 (Derivations).
  > The third component of PROV-DM is concerned with: derivations of entities from others, ...
  > I suggest to change slightly the sentence:
  > The third component of PROV-DM is concerned with: derivations of entities from other entities, ...
This was correct, but OK.
  > 
  > Caption of Figure 6 is not under the figure.
  > Caption of Figure 7 is not under the figure.
  > 
  > Typo in Example 34: instead of using prov:role, the example uses prov:type

role is not allowed on attribution.

  > 
  > Figure 8: the caption is not under the figure.
  > 
  > Figure 9: the caption is not under the figure.
  > 
  > 5.5.3: Contextualization
  > 
  > I'm not entirely convinced with this section. It reminds me a lot to
  > what the accounts were trying to do, and we decided to leave accounts
  > out of the DM because they making the model complex.
  > 
  > Example 45, could be modeled without contextualization by just pinning
  > the rating to the activity and the agent. The rating tool could just
  > say: ex:Bob ex:hadGoodPerformanceIn ex:a1.
  > 
  > In example 46, I don't see why do I have to create a different entity
  > for asserting the triples about the rendering. I would just reuse the
  > entity I had in the first bundle. Since the triples are asserted in
  > different bundles, I can allways filter the statements about an entity
  > depending on the bundle it belongs to. I thought that the bundles were
  > there for doing that too.
  > 
  > From a usability point of view, contextualization makes it difficult
  > to retrieve provenance information about an entity, IMO.
  > 
  > However I haven't been participating actively on the discussions about
  > this in the mailing list, so I don't disagree on having it.  I just
  > think that it overcomplicates the model, and I don't think I'll use
  > it.

Please see revised version.

  > 
  > Figure 10: the caption is not under the figure.
  > 
  > Example 54: in the example, it should be Le louvre instead of Le Louvres, right?

yes.
  > 
  > Note after Example 57: No, I don't think prov:encoding is necessary. That is domain specific.

removed

  > 
  > I don't think table 8 is necessary. It would be enough to say that the
  > prov:values are compatible with the xsd stanndard.


table 8 removed as per F2F3 decision
  > 
  >