--- a/dc-note/dc-note.html Thu Feb 07 01:50:27 2013 +0100
+++ b/dc-note/dc-note.html Thu Feb 07 15:34:49 2013 +0100
@@ -629,6 +629,7 @@
<tr><td>rdfs</td><td><http://www.w3.org/2000/01/rdf-schema#></td><td>The RDFS namespace[[RDFS]]</td></tr>
<tr><td>prov</td><td><http://www.w3.org/ns/prov#></td><td>The PROV namespace [[PROV-DM]]</td></tr>
<tr><td>dct</td><td><http://purl.org/dc/terms/></td><td>Dublin Core Terms namespace [[DCTERMS]]</td></tr>
+ <!--<tr><td>dc</td><td><http://purl.org/dc/elements/1.1/></td><td>Dublin Core elements namespace [[DCTERMS]]</td></tr>-->
<tr><td>ex</td><td><http://example.org></td><td>Application-dependent IRIs</td></tr>
</tbody>
</table>
@@ -690,7 +691,7 @@
<i>who</i> affected it and <i>how</i> it was affected. The rest of the DCMI terms (description metadata), tell us <i>what</i> was affected.
<a href="#categories">Table 1</a> classifies the <code>dct</code> terms according to these four categories (<i>what?</i>, <i>who?</i>, <i>when?</i> and <i>how?</i>).
Each category corresponds to the question it answers regarding the description or provenance of a given resource.
- The classification is by necessity somewhat conservative, as it can be argued that some elements placed in the description metadata terms contain
+ The classification is by necessity somewhat minimalistic, as it can be argued that some elements placed in the description metadata terms contain
provenance information as well, depending on their usage. It is worth mentioning that there is no direct information in Dublin Core describing
<i>where</i> a resource was affected (such information is only available for the publication of a resource). The categories are further explained below:
</p>
@@ -729,7 +730,7 @@
<p>
<b>Derivation Terms (How?):</b> This category contains derivation related terms.
When a resource is derived from other resources, the original resource becomes part of the provenance
- record of the derived resource. In Dublin Core, derivations can be further classified as versions (<code>dct:isVersionOf</code>),
+ chain of the derived resource. In Dublin Core, derivations can be further classified as versions (<code>dct:isVersionOf</code>),
format serializations (<code>dct:isFormatOf</code>), replacements (<code>dct:replaces</code>) and sources of information (<code>dct:source</code>).
<code>dct:references</code> is a weaker relation (having a reference to a resource does not always mean that the content is derived from it),
but it can be assumed that a referenced resource influenced the described resource
@@ -853,7 +854,7 @@
</div>
</div>
</p><p>
- 2) Adopt the original resource (<code>ex:doc1</code>) as the <code>prov:Entity</code> used and then generated by the PublicationActivity
+ 2) Adopt the original resource (<code>ex:doc1</code>) as the <code>prov:Entity</code> used and then generated by the Publish
(<code>:_activity</code>). However, this representation leads to a misinterpretation of the <code>dct</code> statement, as shown in the example of
<a href="#figure_mapping_example_conflating">Figure 2</a>. The representation implies that <code>ex:doc1</code>
was generated by <code>_:activity</code> and then used by <code>_:activity</code> afterwards, instead of being used and then being generated by
@@ -863,7 +864,9 @@
<div id = "figure_mapping_example_conflating" class="figure" style="text-align: center;">
<img src="img/mapping-example - conflating.png"></img>
<div style="text-align: center;">
- <a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes in the same resource. The used and generated resources have the same identifier.
+ <a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes in the same resource.
+ The used and generated resources have the same identifier. This example is an <b>invalid translation</b> of the <code>dct:publisher</code>
+ statement (as it implies that <code>ex:doc1</code> was generated by <code>_:activity</code> and then used by the same activity).
</div>
</div>
</p><p>
@@ -918,84 +921,80 @@
<th>Rationale</th>
</tr>
<tr>
- <td><b>dct:Agent</b></td>
+ <td><b><a href="http://purl.org/dc/terms/Agent">dct:Agent</a></b></td>
<td>owl:equivalentClass</td>
- <td> prov:Agent.</td>
- <td>Both <code>dct:Agent</code> and <code>prov:Agent</code> refer to the same concept: a resource that has the power to act (which then has responsibility for an activity).</td>
- </tr>
- <tr>
- <td><b id="term_rightsHolder">dct:rightsHolder</b></td>
- <td>rdfs:subPropertyOf</td>
- <td>prov:wasAttributedTo</td>
- <td>The rights holder has the attribution of the activity that created the licensed resource.</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#Agent">prov:Agent</a></td>
+ <td>Both <code>dct:Agent</code> and <code>prov:Agent</code> refer to the same concept: a resource that has the power to act (which then has responsibility for an activity, entity or other agent).</td>
</tr>
<tr>
- <td><b id="term_creator">dct:creator</b></td>
+ <td><b id="term_rightsHolder"><a href="http://purl.org/dc/terms/rightsHolder">dct:rightsHolder</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:wasAttributedTo</td>
- <td>A creator is the agent who created the resource. He is the one involved in the creation activity that led to the resource.
- He has the attribution for that activity</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
+ <td>The rights holder has the attribution of the license associated to a resource. Thus, we can say that the resource is attributed in part to the rights holder.</td>
</tr>
<tr>
- <td><b id="term_publisher">dct:publisher</b></td>
+ <td><b id="term_creator"><a href="http://purl.org/dc/terms/creator">dct:creator</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:wasAttributedTo</td>
- <td>A publisher has the attribution of the publishing activity that led to the published resource.</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
+ <td>A creator is one of the agents who participated in the creation of a resource. He has the attribution for the outcome of that activity</td>
</tr>
<tr>
- <td><b id="term_contributor">dct:contributor</b></td>
+ <td><b id="term_publisher"><a href="http://purl.org/dc/terms/publisher">dct:publisher</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:wasAttributedTo</td>
- <td>A contributor is involved either in the creation activity or in
-the updating of the resource. Therefore he/she is attributed to take
- part in those activities.</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
+ <td>A publisher has the attribution of the published resource after participating in the publishing activity that generated it .</td>
</tr>
<tr>
- <td><b id="term_isVersionOf">dct:isVersionOf</b></td>
+ <td><b id="term_contributor"><a href="http://purl.org/dc/terms/contributor">dct:contributor</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:wasDerivedFrom</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
+ <td>A contributor is associated with either the creation activity or the updating of the resource. Therefore he/she has attribution over
+ the outcome of those activities.</td>
+ </tr>
+ <tr>
+ <td><b id="term_isVersionOf"><a href="http://purl.org/dc/terms/isVersionOf">dct:isVersionOf</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></td>
<td><code>dct:isVersionOf</code> refers to "a related resource to which the current resource is a version, edition or adaptation".
Hence the current resource has been derived from the original one.</td>
</tr>
<tr>
- <td><b id="term_isFormatOf">dct:isFormatOf</b></td>
+ <td><b id="term_isFormatOf"><a href="http://purl.org/dc/terms/isFormatOf">dct:isFormatOf</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:alternateOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#isFormatOf">prov:alternateOf</a></td>
<td><code>dct:isFormatOf</code> refers to another resource which is the same but in another format. Thus the mapping is straightforward to <code>prov:alternateOf</code>.</td>
</tr>
<tr>
- <td><b id="term_has_Format">dct:hasFormat</b></td>
+ <td><b id="term_has_Format"><a href="http://purl.org/dc/terms/hasFormat">dct:hasFormat</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:alternateOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#alternateOf">prov:alternateOf</a></td>
<td> See rationale for <code>dct:isFormatOf</code></td>
</tr>
<tr>
- <td><b id="term_replaces">dct:replaces</b></td>
+ <td><b id="term_replaces"><a href="http://purl.org/dc/terms/replaces">dct:replaces</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:wasInfluencedBy</td>
- <td>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 <code>prov:wasInfluencedBy</code></td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasInfluencedBy">prov:wasInfluencedBy</a></td>
+ <td> There is a relation between two resources when the former replaces the latter, but it is not necessarily
+ derivation, revision, specialization or alternate. An example could be a replaced item in a catalog with another item
+ that had nothing to do with the former. Thus, the term is mapped to <code>prov:wasInfluencedBy</code></td>
</tr>
<tr>
- <td><b id="term_source">dct:source </b></td>
+ <td><b id="term_source"><a href="http://purl.org/dc/terms/source">dct:source</a> </b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:wasDerivedFrom</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></td>
<td>In Dublin Core, <code>dct:source</code> is defined as a "related resource from which the described resource is derived", which matches the notion of derivation
in PROV-DM ("a transformation of an entity in another")</td>
</tr>
<tr>
- <td><b>dct:type</b></td>
+ <td><b><a href="http://purl.org/dc/terms/type">dct:type</a></b></td>
<td>owl:equivalentProperty</td>
- <td>prov:type</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#type">prov:type</a></td>
<td>Both properties relate two resources in a similar way: the nature of the resource (or genre).</td>
</tr>
<tr>
- <td><b id="term_created">dct:created</b></td>
+ <td><b id="term_created"><a href="http://purl.org/dc/terms/created">dct:created</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:generatedAtTime</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
<td><code>dct:created</code> is a property used to describe the time of creation of an entity, which corresponds to the time of its generation.
The rationale to map this property as a subclass of <code>prov:generatedAtTime</code>
is that resources in Dublin Core may have
@@ -1006,36 +1005,36 @@
the resource.</td>
</tr>
<tr>
- <td><b id="term_issued">dct:issued</b></td>
+ <td><b id="term_issued"><a href="http://purl.org/dc/terms/issued">dct:issued</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:generatedAtTime</td>
- <td>Date when the resource was issued. It is mapped as a subproperty of <code>prov:generatedAtTime</code> because the issued resource is an entity itself,
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
+ <td>Property used to describe the date when the resource was issued. <code>dct:issued</code> is mapped as a subproperty of <code>prov:generatedAtTime</code> because the issued resource is an entity itself,
which has been generated at a certain time.</td>
</tr>
<tr>
- <td><b id="term_dateAccepted">dct:dateAccepted</b></td>
+ <td><b id="term_dateAccepted"><a href="http://purl.org/dc/terms/dateAccepted">dct:dateAccepted</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:generatedAtTime</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
<td>The rationale is similar to the previous two properties: the
version of the resource which was accepted could be different from the
created or issued one.</td>
</tr>
<tr>
- <td><b id="term_dateCopyrighted">dct:dateCopyrighted</b></td>
+ <td><b id="term_dateCopyrighted"><a href="http://purl.org/dc/terms/dateCopyRighted">dct:dateCopyrighted</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:generatedAtTime</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
<td>See <code>dct:dateAccepted</code></td>
</tr>
<tr>
- <td><b id="term_dateSubmitted">dct:dateSubmitted</b></td>
+ <td><b id="term_dateSubmitted"><a href="http://purl.org/dc/terms/dateSubmitted">dct:dateSubmitted</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:generatedAtTime</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
<td>See <code>dct:dateAccepted</code></td>
</tr>
<tr>
- <td><b id="term_modified">dct:modified</b></td>
+ <td><b id="term_modified"><a href="http://purl.org/dc/terms/modified">dct:modified</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:generatedAtTime</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
<td>See <code>dct:dateAccepted</code></td>
</tr>
</tbody>
@@ -1043,7 +1042,7 @@
</div>
It is worth mentioning that applying the direct mappings to a metadata record such as <a href="#example1">example 1</a> will infer that
the resource was <code>prov:generatedAtTime</code> at two different times. Although this may seem inconsistent, it is supported by PROV and
- it is due to the difference between Dublin Core and PROV resources: while the former conflates more than one version or "state" of
+ it is due to the difference between Dublin Core and PROV entities: while the former conflates more than one version or "state" of
the resource in a single entity, the latter proposes to separate all of them. Thus, the mapping produces provenance that complies with the
current definition of entity but it does not comply with all the PROV
constraints [<cite><a href="#bib-PROV-CONSTRAINTS" class="bibref">PROV-CONSTRAINTS</a></cite>].
@@ -1068,17 +1067,17 @@
<th>Rationale</th>
</tr>
<tr>
- <td>prov:hadPrimarySource</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#hadPrimarySoource">prov:hadPrimarySource</a></td>
<td>rdfs:subPropertyOf</td>
- <td><b>dct:source</b></td>
+ <td><b><a href="http://purl.org/dc/terms/source">dct:source</a></b></td>
<td>The definition of <code>prov:hadPrimarySource</code> ("something produced by some agent with direct experience
and knowledge about the topic") is more restrictive than <code>dct:source</code> ( "A related resource from which the
described resource is derived").</td>
</tr>
<tr>
- <td>prov:wasRevisionOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasRevisionOf">prov:wasRevisionOf</a></td>
<td>rdfs:subPropertyOf</td>
- <td><b>dct:isVersionOf</b></td>
+ <td><b><a href="http://purl.org/dc/terms/isVersionOf">dct:isVersionOf</a></b></td>
<td>Similar to the previous property, <code>prov:wasRevisionOf</code> is more restrictive in the sense that it refers to revised version of a resource, while
<code>dct:isVersionOf</code> involves versions, editions or adaptations of the original resource.</td>
</tr>
@@ -1100,15 +1099,15 @@
<th>Rationale</th>
</tr>
<tr>
- <td><b id="term_hasVersion">dct:hasVersion</b></td>
+ <td><b id="term_hasVersion"><a href="http://purl.org/dc/terms/hasVersion">dct:hasVersion</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:hadDerivation</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#hasDerivation">prov:hadDerivation</a></td>
<td>Inverse property of <code>dct:isVersionOf</code>.</td>
</tr>
<tr>
- <td><b id="term_isReplacedBy">dct:isReplacedBy</b></td>
+ <td><b id="term_isReplacedBy"><a href="http://purl.org/dc/terms/isReplacedBy">dct:isReplacedBy</a></b></td>
<td>rdfs:subPropertyOf</td>
- <td>prov:influenced</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#influenced">prov:influenced</a></td>
<td>Inverse property of <code>dct:replaces</code></td>
</tr>
</tbody>
@@ -1192,14 +1191,14 @@
<pre class="code">
prov:Publish rdfs:subClassOf prov:Activity .
prov:Contribute rdfs:subClassOf prov:Activity .
- prov:Create rdfs:subClassOf prov:Activity, prov:ContributionActivity .
+ prov:Create rdfs:subClassOf prov:Activity, prov:Contribute .
prov:Modify rdfs:subClassOf prov:Activity .
prov:Accept rdfs:subClassOf prov:Activity .
prov:Copyright rdfs:subClassOf prov:Activity .
prov:Submit rdfs:subClassOf prov:Activity .
prov:Publisher rdfs:subClassOf prov:Role .
prov:Contributor rdfs:subClassOf prov:Role .
- prov:Creator rdfs:subClassOf prov:Role, prov:ContributorRole .
+ prov:Creator rdfs:subClassOf prov:Role, prov:Contributor .
</pre>
</p>
@@ -1239,7 +1238,7 @@
</p>
<section>
<h5> dct:creator</h5>
- A creator is the agent associated with role CreatorRole in the CreationActivity that created a specialization of the entity (?document).
+ A creator is the agent associated with role Creator in the Create that created a specialization of the entity (?document).
<pre class="code">
CONSTRUCT {
?document a prov:Entity ;
@@ -1247,12 +1246,12 @@
?agent a prov:Agent .
- _:activity a prov:Activity, prov:CreationActivity ;
+ _:activity a prov:Activity, prov:Create ;
prov:wasAssociatedWith ?agent;
prov:qualifiedAssociation [
a prov:Association;
prov:agent ?agent;
- prov:hadRole prov:CreatorRole .
+ prov:hadRole prov:Creator .
].
_:resulting_entity a prov:Entity ;
@@ -1275,12 +1274,12 @@
?agent a prov:Agent .
- _:activity a prov:Activity, prov:ContributionActivity ;
+ _:activity a prov:Activity, prov:Contribute ;
prov:wasAssociatedWith ?agent ;
prov:qualifiedAssociation [
a prov:Association ;
prov:agent ?agent ;
- prov:hadRole prov:ContributorRole .
+ prov:hadRole prov:Contributor .
].
_:resulting_entity a prov:Entity ;
@@ -1306,13 +1305,13 @@
_:used_entity a prov:Entity;
prov:specializationOf ?document.
- _:activity a prov:Activity, prov:PublicationActivity ;
+ _:activity a prov:Activity, prov:Publish ;
prov:used _:used_entity;
prov:wasAssociatedWith ?agent ;
prov:qualifiedAssociation [
a prov:Association ;
prov:agent ?agent ;
- prov:hadRole prov:PublisherRole .
+ prov:hadRole prov:Publisher .
].
_:resulting_entity a prov:Entity ;
@@ -1344,7 +1343,7 @@
CONSTRUCT{
?document a prov:Entity .
- _:activity a prov:Activity, prov:CreationActivity ;
+ _:activity a prov:Activity, prov:Create ;
# The “output”
_:created_entity a prov:Entity ;
@@ -1369,7 +1368,7 @@
CONSTRUCT{
?document a prov:Entity .
- _:activity a prov:Activity, prov:PublicationActivity ;
+ _:activity a prov:Activity, prov:Publish ;
prov:used _:used_entity .
# The “input”
@@ -1399,7 +1398,7 @@
CONSTRUCT{
?document a prov:Entity .
- _:activity a prov:Activity, prov:ModificationActivity ;
+ _:activity a prov:Activity, prov:Modify ;
prov:used _:used_entity .
# The “input”
@@ -1429,7 +1428,7 @@
CONSTRUCT{
?document a prov:Entity .
- _:activity a prov:Activity, prov:AcceptanceActivity ;
+ _:activity a prov:Activity, prov:Accept ;
prov:used _:used_entity .
# The “input”
@@ -1459,7 +1458,7 @@
CONSTRUCT{
?document a prov:Entity .
- _:activity a prov:Activity, prov:CopyrightingActivity ;
+ _:activity a prov:Activity, prov:Copyright ;
prov:used _:used_entity .
# The “input”
@@ -1532,12 +1531,12 @@
CONSTRUCT{
?document a prov:Entity .
- _:activity a prov:Activity, prov:CreationActivity.
+ _:activity a prov:Activity, prov:Create.
prov:wasAssociatedWith ?agent
prov:qualifiedAssociation [
a prov:Association;
prov:agent ?agent;
- prov:hadRole prov:CreatorRole .
+ prov:hadRole prov:Creator .
] .
# The “output”
@@ -1563,10 +1562,9 @@
<a href="#figure_cleanup1">Figure 3</a>. Gathering complementing properties to conflate blank nodes.
</div>
</div>
-
- </p>
- <p>2) Another solution is to <b>sort all the activities according to their date</b>, if known, and conflate the blank
- nodes result of one activity and the input of the subsequent activity, in case they are both specializations of the same entity.
+ </p>
+ <p>2) Another solution is to <b>sort all the activities according to their logical order</b>, if known, and conflate the blank
+ nodes result of one activity and the input of the subsequent activity. <!-- in case they are both specializations of the same entity -->
<a href="#figure_cleanup2">Figure 4</a> shows a graphical example with two different activities (creation and publication) that happened at different
points in time. Instead of creating different blank nodes for the respective usage and generation, both activities share the same
blank node (<code>_:created_entity</code>).
@@ -1600,159 +1598,159 @@
<th>Category</th>
<th>Rationale</th>
</tr><tr>
- <td><b id="term_abstract">dct:abstract</b></td>
+ <td><b id="term_abstract"><a href="http://purl.org/dc/terms/abstract">dct:abstract</a></b></td>
<td>Descriptive metadata</td>
<td>Summary of the resource. Thus, not part of its provenance.</td>
</tr><tr>
- <td><b id="term_accrualMethod">dct:accrualMethod</b></td>
+ <td><b id="term_accrualMethod"><a href="http://purl.org/dc/terms/accrualMethod">dct:accrualMethod</a></b></td>
<td>Descriptive Metadata</td>
<td>Method by which items are added to a collection. It doesn't describe the action itself, so it is out of the scope of the mapping</td>
</tr><tr>
- <td><b id="term_accrualPeriodicity">dct:accrualPeriodicity</b></td>
+ <td><b id="term_accrualPeriodicity"><a href="http://purl.org/dc/terms/accrualPeriodicity">dct:accrualPeriodicity</a></b></td>
<td>Descriptive metadata</td>
<td>Frequency of the addition of items to a collection.</td>
</tr><tr>
- <td><b id="term_accrualPolicy">dct:accrualPolicy</b></td>
+ <td><b id="term_accrualPolicy"><a href="http://purl.org/dc/terms/accrualPolicy">dct:accrualPolicy</a></b></td>
<td>Descriptive metadata</td>
<td>Policy associated with the insertion of items to a collection. It could be used to enrich the qualified
involvement, but there is no direct mapping of this relationship.</td>
</tr><tr>
- <td><b id="term_alternative">dct:alternative</b></td>
+ <td><b id="term_alternative"><a href="http://purl.org/dc/terms/alternative">dct:alternative</a></b></td>
<td>Descriptive metadata</td>
- <td>Refers to an alternative name of the resource. </td>
+ <td>Refers to an alternative title of the resource. </td>
</tr><tr>
- <td><b id="term_audience">dct:audience</b></td>
+ <td><b id="term_audience"><a href="http://purl.org/dc/terms/audience">dct:audience</a></b></td>
<td>Descriptive metadata</td>
<td>The audience for whom the resource is useful.</td>
</tr><tr>
- <td><b id="term_conformsTo">dct:conformsTo</b></td>
+ <td><b id="term_conformsTo"><a href="http://purl.org/dc/terms/conformsTo">dct:conformsTo</a></b></td>
<td>Descriptive metadata</td>
<td>Indicates the standard to which the resource conforms to (if any).</td>
</tr><tr>
- <td><b id="term_coverage">dct:coverage</b></td>
+ <td><b id="term_coverage"><a href="http://purl.org/dc/terms/coverage">dct:coverage</a></b></td>
<td>Descriptive metadata</td>
<td>Topic of the resource.</td>
</tr><tr>
- <td><b id="term_description">dct:description</b></td>
+ <td><b id="term_description"><a href="http://purl.org/dc/terms/description">dct:description</a></b></td>
<td>Descriptive metadata</td>
<td>An account of the resource.</td>
</tr><tr>
- <td><b id="term_educationLevel">dct:educationLevel</b></td>
+ <td><b id="term_educationLevel"><a href="http://purl.org/dc/terms/educationLevel">dct:educationLevel</a></b></td>
<td>Descriptive metadata</td>
<td>The educational level of the audience for which the resource is intended too.</td>
</tr><tr>
- <td><b id="term_extent">dct:extent</b></td>
+ <td><b id="term_extent"><a href="http://purl.org/dc/terms/extent">dct:extent</a></b></td>
<td>Descriptive metadata</td>
<td>Size or duration of the resource.</td>
</tr><tr>
- <td><b id="term_format">dct:format</b></td>
+ <td><b id="term_format"><a href="http://purl.org/dc/terms/format">dct:format</a></b></td>
<td>Descriptive metadata</td>
<td>Format of the resource. </td>
</tr><tr>
- <td><b id="term_identifier">dct:identifier</b></td>
+ <td><b id="term_identifier"><a href="http://purl.org/dc/terms/identifier">dct:identifier</a></b></td>
<td>Descriptive metadata</td>
<td>An unambiguous reference on a given context. </td>
</tr><tr>
- <td><b id="term_instructionalMethod">dct:instructionalMethod</b></td>
+ <td><b id="term_instructionalMethod"><a href="http://purl.org/dc/terms/instructionalMethod">dct:instructionalMethod</a></b></td>
<td>Descriptive metadata</td>
<td>Method used to create the knowledge that the resource is supposed to support.</td>
</tr><tr>
- <td><b id="term_isPartOf">dct:isPartOf</b></td>
+ <td><b id="term_isPartOf"><a href="http://purl.org/dc/terms/isPartOf">dct:isPartOf</a></b></td>
<td>Descriptive metadata</td>
<td>Inverse of <code>dct:hasPart</code>.</td>
</tr><tr>
- <td><b id="term_isRequiredBy">dct:isRequiredBy</b></td>
+ <td><b id="term_isRequiredBy"><a href="http://purl.org/dc/terms/isRequiredBy">dct:isRequiredBy</a></b></td>
<td>Descriptive metadata</td>
<td>The current resource is required for supporting the function of another resource. This is not related
the provenance, since it refers to something that may not have happened yet (e.g., a library dependency, but the program
that needs it hasn’t been executed yet).</td>
</tr><tr>
- <td><b id="term_language">dct:language</b></td>
+ <td><b id="term_language"><a href="http://purl.org/dc/terms/language">dct:language</a></b></td>
<td>Descriptive metadata</td>
<td>Language of the resource.</td>
</tr><tr>
- <td><b id="term_mediator">dct:mediator</b></td>
+ <td><b id="term_mediator"><a href="http://purl.org/dc/terms/mediator">dct:mediator</a></b></td>
<td>Descriptive metadata</td>
<td>Entity that mediates access to the resource. </td>
</tr><tr>
- <td><b id="term_medium">dct:medium</b></td>
+ <td><b id="term_medium"><a href="http://purl.org/dc/terms/medium">dct:medium</a></b></td>
<td>Descriptive metadata</td>
<td>Material of the resource.</td>
</tr><tr>
- <td><b id="term_requires">dct:requires</b></td>
+ <td><b id="term_requires"><a href="http://purl.org/dc/terms/requires">dct:requires</a></b></td>
<td>Descriptive metadata</td>
<td>Inverse property of <code>dct:isRequiredBy</code> (see <code>dct:isRequiredBy</code>).</td>
</tr><tr>
- <td><b id="term_hasPart">dct:hasPart</b></td>
+ <td><b id="term_hasPart"><a href="http://purl.org/dc/terms/hasPart">dct:hasPart</a></b></td>
<td>Descriptive metadata</td>
<td>A resource that is included in the current resource. Since entity composition is out of the scope of PROV,
this property has been excluded from the mapping</td>
</tr><tr>
- <td><b id="term_spatial">dct:spatial</b></td>
+ <td><b id="term_spatial"><a href="http://purl.org/dc/terms/spatial">dct:spatial</a></b></td>
<td>Descriptive metadata</td>
<td>Spatial characteristics of the content of the resource (e.g., the book is about Spain). Thus it can't be mapped to <code>prov:hadLocation</code>.</td>
</tr><tr>
- <td><b id="term_subject">dct:subject</b></td>
+ <td><b id="term_subject"><a href="http://purl.org/dc/terms/subject">dct:subject</a></b></td>
<td>Descriptive metadata</td>
<td>Subject of the resource.</td>
</tr><tr>
- <td><b id="term_tableOfContents">dct:tableOfContents</b></td>
+ <td><b id="term_tableOfContents"><a href="http://purl.org/dc/terms/tableOfContents">dct:tableOfContents</a></b></td>
<td>Descriptive metadata</td>
<td>List of subunits of the resource.</td>
</tr><tr>
- <td><b id="term_temporal">dct:temporal</b></td>
+ <td><b id="term_temporal"><a href="http://purl.org/dc/terms/temporal">dct:temporal</a></b></td>
<td>Descriptive metadata</td>
<td>Temporal characteristics of which the resource refers to (e.g., a book about 15th century).</td>
</tr><tr>
- <td><b id="term_title">dct:title</b></td>
+ <td><b id="term_title"><a href="http://purl.org/dc/terms/">dct:title</a></b></td>
<td>Descriptive metadata</td>
<td>Title of the resource.</td>
</tr><tr>
- <td><b id="term_type">dct:type</b></td>
+ <td><b id="term_type"><a href="http://purl.org/dc/terms/">dct:type</a></b></td>
<td>Descriptive metadata</td>
<td>Type of the resource.</td>
</tr><tr>
- <td><b id="term_bibliographicCitation">dct:bibliographicCitation</b></td>
+ <td><b id="term_bibliographicCitation"><a href="http://purl.org/dc/terms/bibliographicCitation">dct:bibliographicCitation</a></b></td>
<td>Descriptive metadata</td>
<td>Property that relates the literal representing the bibliographic citation of the resource to the
actual resource (e.g., <code>:el_Quijote dct:bibliographicCitation "Miguel de Cervantes Saavedra: El Quijote, España"</code>).</td>
</tr><tr>
- <td id="term_references"><b>dct:references</b></td>
+ <td id="term_references"><b><a href="http://purl.org/dc/terms/references">dct:references</a></b></td>
<td> Provenance: How </td>
<td>This term could be used to refer to sources that have been used to create the document, but it could
be also used to cite the sources that are not relevant for the current work. For this reason it has been dropped
from the mapping.</td>
</tr><tr>
- <td id="term_isReferencedBy"><b>dct:isRefrencedBy</b></td>
+ <td id="term_isReferencedBy"><b><a href="http://purl.org/dc/terms/isReferencedBy">dct:isRefrencedBy</a></b></td>
<td> Provenance: How </td>
<td>Inverse to <code>dct:references</code>.</td>
</tr><tr>
- <td><b id="term_accessRights">dct:accessRights</b></td>
+ <td><b id="term_accessRights"><a href="http://purl.org/dc/terms/accessRights">dct:accessRights</a></b></td>
<td>Provenance: How</td>
<td>Agents who can access the resource (security status). Since the privileges of the resource are part of the
description of the resource, the property has been excluded from the mapping.</td>
</tr><tr>
- <td><b id="term_license">dct:license</b></td>
+ <td><b id="term_license"><a href="http://purl.org/dc/terms/license">dct:license</a></b></td>
<td>Provenance: How</td>
<td>License of the resource. It has been left out of the mapping because there is no term in PROV-O to represent this information.</td>
</tr><tr>
- <td><b id="term_rights">dct:rights</b></td>
+ <td><b id="term_rights"><a href="http://purl.org/dc/terms/rights">dct:rights</a></b></td>
<td>Provenance: How</td>
<td>Metadata about the rights of the resource.</td>
</tr><tr>
- <td><b id="term_date">dct:date</b></td>
+ <td><b id="term_date"><a href="http://purl.org/dc/terms/date">dct:date</a></b></td>
<td>Provenance: When</td>
<td>Date is a very general property. It is the superproperty which all the other specialize, but there is no equivalent concept in PROV. It has been excluded from the mapping</td>
</tr><tr>
- <td><b id="term_available">dct:available</b></td>
+ <td><b id="term_available"><a href="http://purl.org/dc/terms/available">dct:available</a></b></td>
<td>Provenance: When</td>
<td>Property that states when a resource is available. The group could not reach consensus on how to map this property, so it was finally dropped from the mapping.</td>
</tr><tr>
- <td><b id="term_valid">dct:valid</b></td>
+ <td><b id="term_valid"><a href="http://purl.org/dc/terms/valid">dct:valid</a></b></td>
<td>Provenance: When</td>
<td>Property that states when a resource is valid. The notion of invalidation is defined in PROV-DM, but not the notion of validation. Thus this property is left out of the mapping.</td>
</tr><tr>
- <td><b id="term_relation">dct:relation</b></td>
+ <td><b id="term_relation"><a href="http://purl.org/dc/terms/relation">dct:relation</a></b></td>
<td>Provenance </td>
<td>A related resource. This relationship is very broad and could relate either provenance resources or not.
Therefore it could be seen as a superproperty of <code>prov:wasDerivedFrom</code>, <code>prov:wasInfluencedBy</code>, <code>prov:alternateOf</code>, <code>prov:specializationOf</code>, etc. Thus there is no direct mapping.<td>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/feedback/Luc.txt Thu Feb 07 15:34:49 2013 +0100
@@ -0,0 +1,181 @@
+
+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) a replacement does not allways imply revision: Imagine that you are describing
+a catalogue and you realize that you have made a mistake. 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, 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.
+
+- 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 then 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.
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/feedback/Simon.txt Thu Feb 07 15:34:49 2013 +0100
@@ -0,0 +1,180 @@
+General
+=======
+ - The document is dated 28 October 2012.
+-->Done
+
+ - I think the document would benefit from being clearer how you apply the information contained in it. That is, I'd argue it should be clearly
+ a methodological document from the start, explaining to the reader how to map their data. At the moment, the document discusses and presents
+ information, but without a context of how and when the reader should take it into account. If an overall methodology was articulated at the start
+ of the document, the reader could better understand the mapping and discussion in that context.
+ -->I have added a new subsection (Structure of the document), which aims to summarize each section and direct the users reading the document.
+ I have also added some paragraphs on how to use the mappings in their correspondent sections. Is that enough? I mean, the methodology is just apply
+ the patterns and mappings offered in the document, it is not rocket science.
+
+Abstract
+========
+ - "prov" should be "PROV" in the final line.
+-->Done
+
+ - "here here" in the final line.
+-->Done
+
+ - I don't think readers will know what "direct mappings" or "prov refinements" mean by this point in the document.
+-->Done: removed "direct" and explained what the "refinement" does.
+
+Status of This Document
+=======================
+ - Missing space before [DCTERMS] citation.
+-->Must have been fixed in a previous review (no [DCTERMS] citation in Status)
+
+1. Introduction
+===============
+ - Paragraph 1: "The Dublin Core Metadata Initiative provides a core metadata vocabulary..." - A vocabulary about what? The first two paragraphs provide
+ lots of minor details about DC, but don't give context explaining what it is for, which seems inconsistent.
+-->Done: "The Dublin Core Metadata Initiative (DCMI) provides a core metadata vocabulary for simple and generic resource descriptions..."
+
+ - Paragraph 4: "A classification... is provided in Table 1. This classification is... conservative" - I think we should say what the classification
+ is before talking about its characteristics, otherwise the reader can get lost. What is the classification for?
+--> Done. Paragraph changed to reflect the purpose of the classification.
+
+ - Paragraph 4: "can be considered as provenance related" - Delete "as".
+--> Done
+
+ - Why do the categories in the text not follow the order of the categories in the table? This makes it harder to follow. Similarly, it would be good
+ to have a headed paragraph on the first category, Descriptive, so that it is clear you are explaining the table contents.
+-->Done
+
+ - I don't think the purpose of the paragraphs on the categories ("Dates and Time terms" etc.) is clear. It seems to be a discussion about provenance,
+ but without much context beforehand. This should be clarified.
+--> Done
+
+ - The paragraph about each category talks about just a few of the terms in the category, and it is not clear why. Could we be more rigorous and talk
+ about every term one by one?
+--> We were asked by some reviewers to not include all the terms in each category. They can be found in the tables at the end of the mapping, and
+I don't see the necessity of repeating the definitions twice hear. The purpose of the categories is to explain why are they there and what kind
+of terms are being grouped, but not necessarily the definition of the terms of each category.
+
+ - "Dates and Time terms" - should be "Date and Time terms"
+-->Done
+
+ - Why is "terms" in lowercase for "Dates and Time" but capitalised for the other categories, "Terms"?
+-->Done
+
+ - "Dates typically belong to the provenance record of a resource." - As opposed to belonging to what? Not clear what you are trying to convey.
+--> Done, removed that sentence.
+
+ - "the publication can be seen as an action" - Delete "the".
+-->Done
+
+ - In Agency Terms, the sentence starting "All properties that have..." is not grammatically meaningful. Maybe you need to delete "that"?
+-->Done
+
+ - In Derivation Terms, put "and" before the "dct:source" in the list of derivations.
+-->Done
+
+ - "dct:references is a weaker relation" - Why? Surely it is a form of derivation like the others? If A references B, then part of A's content
+ (the reference) is specifically determined by B. I don't understand how it could be weaker than derivation.
+-->This term created some discussion within the group. The problem is that adding a reference doesn't allways mean that part of the content (reference) is used
+in the current document. A possible example is if my text included the next sentence: "This work has nothing to do with this random reference [REF1]". The
+work has not been derived at all from it. Normally this is not the case, but as it can happen, we cannot assume the derivation.
+I have clarified this in the text
+
+ - Paragraph under Table 1: "Despite being relevant for provenance..." - This is confusing, as you are currently talking about provenance. I assume
+ you need to distinguish between dct:provenance and applicability for mapping to PROV.
+--> Done, added a specific comments saying that it is left out of the mapping
+
+ - What is the conclusion of the discussive paragraph about dct:provenance?
+--> Done
+
+ - Paragraph under Example 1: "ex:doc2 which had probably" - Should be "which probably had"
+-->Done
+
+1.1 Namespaces
+==============
+ - Shouldn't this table come before the introduction text, as that uses dct: plenty of times.
+--> Moved and reestructured some oher parts of the document.
+
+ - Where is it explained what the ex: namespace is?
+--> Added it to the table.
+
+2.1 Basic considerations
+========================
+ - Point 1): "can be expressed in form" - Missing "the".
+--> Fixed
+
+2.2 What is ex:doc1? Entities in Dublin Core
+============================================
+ - Paragraph 1: "As a dc metadata record describes the resulting document as a whole." - Resulting from what?
+--> Fixed (removed "resulting")
+
+ - "According to the PROV ontology, the activity of issuing a document involves two different states of the document" - I don't think PROV-O says
+ this or requires it. It is more that, if you want to use PROV to model an acitivity affecting a document or any other thing, then this is most
+ naturally done using one entity for the state before and one entity for the state after being affected.
+--> I disagree: An entity can't be used before being generated by an activity. Thus, for an "Issue" activity we need 2 states: the article before
+the issue and the issued article, which was generated in that activity. This is taken from the definition of generation:
+http://www.w3.org/TR/2012/CR-prov-dm-20121211/Overview.html#term-Generation
+
+ - "Each of these states corresponds to a different specialization of the document" - Be clear that this is "specialization" in the PROV sense. Maybe
+ there should be a font style used to show when PROV vocabulary is being used in the text?
+--> Done.
+
+ - Paragraph 2: "somehow find some activity and agent" - Delete (or explain) "somehow". What activity? I don't think it is necessarily clear to the reader.
+--> Done
+
+ - I think Figure 1 needs more explanation. What does it show and why?
+--> Added.
+
+ - I think you need to explain what the bold arrow towards the top of the figures mean.
+
+ - It seems confusing to use the same notation in the figures for both RDF resources and PROV entities. The top of Figure 1 seems to show
+ ex:publisher to be an entity, but that isn't shown in the mapped PROV (and probably shouldn't be).
+
+-------> TO DO. Yes, we haven't used PROV notation to refer to dct resources.
+
+2.3 Direct mappings
+===================
+ - Paragraph 1: "The direct mappings provide basic interoperability" - Interoperability of what? Basic in what way?
+--> Rephrased.
+
+ - "By means of OWL 2 RL reasoning, any PROV application can at least make some sense from Dublin Core data." - This seems too vague to mean much.
+ What are you specifically trying to convey?
+--> That by using the mapping, now PROV applications can interoperate with Dublin Core data. Rephrased.
+
+ - Paragraph under Table 3: "a metadata record such as example 1 will infer that" - A record cannot infer.
+--> Fixed.
+
+ - I still find the prov:wasRevisionOf-dct:isVersionOf mapping strange, even though it may well be correct. This is not necessarily for the mapping
+ document itself, but I'd be interested to see an example of an assertion that was expressible in dct:isVersionOf but not in prov:wasRevisionOf.
+--> This could be complicated, as PROV and DC don't specify what are the attributes of a revision. Since prov only included revisions and
+DC included revisions, editions and adaptations, this approach seems more sensible. As an example, I would say that an adaptation to english of a spanish
+book is not a prov:revision of that book. However, it is a dct:version.
+---> The definitions may have changed since we last brought this to the DC community. We could try to raise the debate once again and discuss this particular mapping
+
+ - The column headings in Table 5 are wrong (PROV Term and DC Term need to be switched).
+--> Fixed.
+
+2.4 PROV refinements
+====================
+ - Why is "Activity" or "Role" part of the names? Why not just "prov:Creation" or "prov:Modification"? This does not seem consistent with the other documents.
+--> Fixed
+
+ - Is it correct that the namespace of these new terms is prov: and not a separate namespace for the mapping? I assume it is correct, but just checking.
+--> We originally had a different one. But the group voted on having all PROV family of specifications under the same namespace. So yes, it is correct :)
+
+ - The final paragraph uses "should" a couple of times. It is unclear who this obligates, and might be read as an instruction to the reader/implementer,
+ as this is how "should" is used in the other PROV documents.
+--> Fixed
+
+2.5 Complex Mappings
+====================
+ - Paragraph 1: "consist on a set" - Should be "consist of a set"
+--> Fixed.
+
+ - Figure 4: We need to say, in the figure caption and possibly the accompanying text, which activity is before which other activity (as this is the key point
+ of the conflation).
+--> Added
+
+B.2 Informative references
+==========================
+ - The dates for PROV-CONSTRAINTS, PROV-DM and PROV-O are not correct for the forthcoming release.
+--> Done, taken from prob_bib.js
\ No newline at end of file