Luc Moreau

1. I don't think that what you say about prov-constraints is correct.
  The example of Figure 2 is perfectly valid.  The activity generated
  doc1, and *then* used ex:doc1.  That's probably not what you want to express here,
  and so the text needs to be rewritten to reflect that.

--> This was fixed before going to Working Draft

2. A couple of issues about the mapping:
2.1 It's unfortunate that you map dct:replaces to prov:wasInfluencedBy.
   PROV specs suggest to use more specific relations.

--> The more specific relationships(revision, specialization) don't seem to fit under the definition of replacement. See detailed comments within the rest of the responses.

2.2 For dct:isVersionOf, I suggest below to look at an example in prov-dm.
   THis looks like a subproperty of prov:specializationOf

--> Simon raised some comments with wasRevisionOf that we might have to consider. I'll bring this to the rest of the mapping group for discussion, in order to try to find particular examples and counter examples. Take into account that when we had the discussion about the mapping, some of the examples and part of the definitions were missing/out of date.

3. I am really keen we adopt the layout conventions for graphs. In particular,
  Figure 1 does not follow it.
  Since you seem to adopt the top down layout,
  I also suggest that the activity should appear above the entity ex:doc1 in  Figure 2.

--> Will do.

With this addressed, I think it's good to go to FPWD.

Cheers,
Luc

---

- this more specific vocabulary is called the *TERMS*
 I don't understand what you mean? 'Metadata Terms'

--> They are description metadata terms. I have reorganized and rephrased part of the introduction to clarify this.

-  "Finally, dct:replaces relates the document to another document ex:doc2 which had probably some kind of influence on ex:doc1."
  Why don't you say wasRevisionOf?

--> Because 1) It is an example of the Dublin Core Terms, so prov:wasRevisionOf might not be adequate thete, and 2) Imagine that you are describing a catalogue and you replace an item. Element 2 might be replaced by element 4 (which might not be related to it). You could say that element 2 had some influence in the replacement (it is what it was there before), but element 4 it is not a derivation or a revision of element 2. Another example are the proteins in a database superseeded by new discoveries. The protein superseeding the previous record is not a revision, derivation or specialization of the former, but it replaces it.

- to the definition of the  Provenance Working Group [PROV-DEF] a

 Write:

  to the <a href="http://www.w3.org/TR/2012/WD-prov-dm-20120724/#dfn-provenance">definition of provenance</a> of the PROV Working Group [PROV-DM]

--> I haven't found this reference. I think it may have been removed in a previous version

- Description metadat: alternative??? Has it anything to do with prov:alternate?

--> No. It refers to an alternative TITLE of the book. For example: <http://someID/BOOK1> dct:title "The Bible"; dct:alternative "The Holy Book". Titles are not identifiers. It is an additional description of a single resource. (If you considered alternative in the mapping, you would have to consider title as well).

- It is conservative classification?
 In what way is it conservative. You seem to indicate that others elements
 could still be classified as provenance. May be you mean minimalistic?

--> Done. Replaced with minimailistic (reads better)

- "The original resource becomes part of the provenance record of the
 derived resource. "  I don't think it's what you mean.
 May be you wan to say
 "The DESCRIPTION of the original resource becomes part of the provenance
  record of the derive resource".

--> What we want to express is that the original resource becomes part of the provenance chain of the derived resource. I have rephrased it.

- section 2.1: I was getting confused : which one is source, which one is target?

--> Rephrased, fixed.

- The layout of the diagram should follow the conventions in:
http://www.w3.org/2011/prov/wiki/Diagrams
In particular, the directionality of edges is crucial.

--> PROV statements are expressed according to this notation, but not the DC statements. I'll add the notation in the DC statements as well in order to avoid confusion. Directionality of the edges has been respected.

- section 2.2: replace " is not compliant with the PROV constraints"

 Why is not compliant? you mean not valid, yes?  I think
 this is a valid graph, which states that ex:doc1 was generated by
 activity, and *then* used by the same activity.  It is valid
 according to prov-constraints.  It may not be what you want to say.

--> This was fixed before going to FPWD.

- Figure 2: IN caption: If figure is invalid, state it in the caption.

--> Fixed.

- table 3: add links to definitions of dc terms and prov terms.

--> Done

- table 3: agent: which then has responsibility for an activity,
 ... and entities and other agents

--> Done

- table 3: "The rights holder has the attribution of the activity that created the licensed resource." ... 
strange to talk about activity, since prov:wasAttributedTo does not have an activity.

--> True, rephrased

- table 3: likewise: "He is the one involved in the creation activity that led to the resource. He has the attribution for that activity"

-->Done

 why *the one*?  he is an agent involved ... (there may be others).

- table3 : same issue for publishe and contributer.
  It is strage to read " he is attributed to take part in those activities".
   Either you should said "he is associated with those activities" or "this entity is attributed to this agent".

-->Done

- "dct:replaces    rdfs:subPropertyOf    prov:wasInfluencedBy This mapping is not straightforward. There is a relation between two resources when the former replaces the latter, but it is not necessarily derivation, revision, specification or alternate. Thus, the term is mapped to prov:wasInfluencedBy"

It's unclear why the mapping is not straightforward. In any case, the document should not say it.  I am unclear why it is not necessarily a derivation/revision. It's kind of anoying that this is mapped to influence, since we say it's better to use more specific relations.  What's wrong with derivation/revision?

--> Quoting examples from above: a replacement does not allways imply revision: Imagine that you are describing a catalogue and you replace an item. Element 2 might be replaced by element 4 (which might not be related to it). You could say that element 2 had some influence in the replacement (it is what it was there before), but element 4 it is not a derivation or a revision of element 2. Another example are the proteins in a database superseeded by new discoveries. The protein superseeding the previous record is not a revision, derivation or specialization of the former, but it replaces it.

This mapping does not reflect a single opinion. It reflects the consensus reached by the people who participated in the effort. At the beggining I was a bit dissapointed by this particular resolution, but I must admit that the particular counter examples raised make sense.

specification ---> specialization?

-->Fixed

- dct:issued ... ". It is mapped as a subproperty " What is mapped? grammatically, it is the date, but this doesn't seem to work.

-->Fixed

- It's difficult to understand the text for mapping of dates

--> TO DO

-  "it is supported by PROV and it is due to the difference between Dublin Core and PROV resources" ->
  it is supported by PROV and it is due to the difference between Dublin Core RESOURCES and PROV ENTITIES:

--> Fixed

- it does not comply with all the PROV constraints
 See note above, I think it implies something different.

--> Fixed

- table 4, second row:

- Similar to the previous property??? what do you mean? --> Fixed

- "prov:wasRevisionOf is more restrictive in the sense that it refers to revised version of a resource, while dct:isVersionOf involves 
versions, editions or adaptations of the original resource." I don't understand what you mean.

--> This implied that PROV refers to "version", while DC refers to "version, edition and adaptation", which is a wider concept. However the concept of version for PROV could include editions and adaptations. I will bring this term for discussion.

YOu may want to look at http://www.w3.org/TR/prov-dm/#anexample-alternate2
Wouldn't you say that

tr:WD-prov-dm-20111215 dct:isVersionOf <http://www.w3.org/TR/prov-dm/>

So, this looks like a specialization?

--> I am not convined by this. This is an example, but would you say that an adaptation is a specialization of a resource? A version in the DC sense might not share any aspects with a former version of a document. What if we start up with a specific document that we generalize? The general document would be a dct:isVersionOf of the specific document, but NOT a prov:specialization.

- section 2.4: naming conversion for prov:PublicationActivity should
 be reconsidered.
 Why not prov:Publish?

-->Agreed, renamed all Classes.

- What happens if a same entity has both dc:created and dct:issued. Can you relate the Creation and Publication activities ?

--> Yes, you can. I'll add a note about this to the text :)

- Section 2.5.3, clean up solution 2)
Does Dublin Core make assumptions about dates? Are they all the same clock, or all synchronized? If not, then we can't order by date.

--> I'll add a note about this.

In fact, isn't there a logical order, where creation takes place before publication?
--> Yes. In fact I added the part about the logical order, which makes more sense, and I removed the bit with the dates. This includes your previous point about issued and created.