--- a/dc-note/releases/NOTE-prov-dc-20130430/Overview.html Tue Apr 09 10:00:58 2013 +0100
+++ b/dc-note/releases/NOTE-prov-dc-20130430/Overview.html Tue Apr 09 15:18:58 2013 +0200
@@ -304,13 +304,12 @@
<section class="introductory" id="abstract"><h2>Abstract</h2>
<p>
This document describes a partial mapping from Dublin Core Terms [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>] to the PROV-O OWL2 ontology [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>]. A substantial number of
- terms in the Dublin Core vocabulary provide information about the provenance of the resource. Translating these terms to PROV makes the
- contained provenance information explicit within a provenance chain. The mapping is expressed partly by direct RDFS/OWL mappings between
+ terms in the Dublin Core vocabulary provide information about the provenance of a resource. The mapping is expressed partly by direct RDFS/OWL mappings between
properties and classes, which can be found <a href="http://www.w3.org/ns/prov-dc-directmappings.ttl">here</a>.
</p>
<p>
Some of the direct mappings can be refined, translating single Dublin Core Terms into an extended
- representation of the provenance chain. Therefore, refinements of classes defined in PROV are needed to represent specific Dublin Core activities and roles.
+ representation of the provenance. Therefore, refinements of classes defined in PROV are needed to represent specific Dublin Core activities and roles.
This set of PROV refinements can be accessed <a href="http://www.w3.org/ns/prov-dc-refinements.ttl">here</a>.
</p>
<p>
@@ -472,7 +471,7 @@
<p></p>
<p>
<a href="#mapping-from-dublin-core-to-prov">Section 3</a> describes the mapping between DC and PROV. The mapping is divided in different sections,
- depending on the level of complexity that different users might be interested on when translating their DC data to PROV:
+ depending on the level of complexity that different users might be interested in when translating their DC data to PROV:
</p><ul>
<li><a href="#direct-mappings">Section 3.1</a> introduces the <b>direct mappings</b> between DC terms and PROV. These simple mappings can be expressed in the form of subclass or subproperty relationships in RDFS
– or equivalent relationships in OWL, and can be used to infer PROV binary relationships from DC data.
@@ -488,8 +487,8 @@
introduces some strategies on how to reduce the amount of blank nodes.
</li>
<li><a href="#list-of-terms-excluded-from-the-mapping">Section 3.5</a>, on the other hand, describes the rationale for the terms left out of the mapping.
- Some terms may have misleading names (e.g., <code>dct:alternative</code> is similar to <code>prov:alternateOf</code>), but have nothing to do with the provenance of a resource. Other terms summarize the
- resolution of the community discussions with examples.
+ Some terms may imply a mapping (e.g., <code>dct:alternative</code> is similar to <code>prov:alternateOf</code>), but do not in fact correspond. Other terms summarize the
+ resolution of the community discussion with examples.
</li>
<li>Finally, <a href="#mapping-from-prov-to-dc">Section 3.6</a> adds some details about the inverse mapping (PROV to DC), which is out of the scope
of this document.
@@ -511,7 +510,7 @@
<section id="provenance-in-dublin-core">
<h3><span class="secno">2.1 </span>Provenance in Dublin Core</h3>
<p>
- DCMI terms hold a lot of provenance information about a resource: <i>when</i> it was affected in the past,
+ Many DCMI terms can be used to describe provenance information about a resource: <i>when</i> it was affected in the past,
<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 DC 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.
@@ -663,7 +662,7 @@
having a publisher implies a "Publish" activity (represented with a blank node), which is related to the <code>ex:publisher</code> agent. The
activity must have taken as input the document to be published (<code>:_usedEntity</code>, which is a <code>prov:sprecializationOf</code> the
resource we are describing), and generated the published resource (<code>:_resultingEntity</code>). Since we cannot ensure that the published
- resource has not suffered any further modifications, <code>:_resultingEntity</code> is also a <code>prov:specializationOf</code> the resource
+ resource has not gone through any further modifications, <code>:_resultingEntity</code> is also a <code>prov:specializationOf</code> the resource
<code>ex:doc1</code>.
</p><p>
</p><div id="figure_mapping_example" style="text-align: center;">
@@ -691,7 +690,7 @@
</div>
</div>
<p></p><p>
- Since the first option provides a correct interpretation of the DC statements, it has been chosen as guideline in the complex mapping.
+ Since the first option provides a correct interpretation of the DC statements, it has been chosen as the approach for the complex mapping defined in this document..
Blank nodes are used for the mapping, although any naming mechanism could be provided if necessary,
leaving the conflating of nodes to the clean-up phase.
</p>
@@ -766,7 +765,7 @@
<td><b id="term_creator"><a href="http://purl.org/dc/terms/creator">dct:creator</a></b></td>
<td>rdfs:subPropertyOf</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>
+ <td>A creator is one of the agents who participated in the creation of a resource. They have the attribution for the outcome of that activity.</td>
</tr>
<tr>
<td><b id="term_publisher"><a href="http://purl.org/dc/terms/publisher">dct:publisher</a></b></td>
@@ -778,7 +777,7 @@
<td><b id="term_contributor"><a href="http://purl.org/dc/terms/contributor">dct:contributor</a></b></td>
<td>rdfs:subPropertyOf</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
+ <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>
@@ -793,7 +792,7 @@
<td><b id="term_isFormatOf"><a href="http://purl.org/dc/terms/isFormatOf">dct:isFormatOf</a></b></td>
<td>rdfs:subPropertyOf</td>
<td><a href="http://www.w3.org/TR/prov-o/#alternateOf">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>
+ <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"><a href="http://purl.org/dc/terms/hasFormat">dct:hasFormat</a></b></td>
@@ -805,7 +804,7 @@
<td><b id="term_references"><a href="http://purl.org/dc/terms/references">dct:references</a></b></td>
<td>rdfs:subPropertyOf</td>
<td><a href="http://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></td>
- <td>In PROV a derivation is defined as "a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a
+ <td>In PROV, a derivation is defined as "a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a
pre-existing entity". If a resource n1 references another resource o1 then the construction of n1 is based on o1, even if
o1 does not influence n1 significantly. Removing the reference to o1 in n1 would lead to the construction of another resource n1', different from n1.</td>
</tr>
@@ -952,25 +951,26 @@
<section id="prov-refinements">
<h3><span class="secno">3.2 </span>PROV refinements</h3>
<p>
- To properly reflect the meaning of the Dublin Core terms, more specific subclasses are needed:
- </p><p>
- </p><pre class="code"> prov:Publish rdfs:subClassOf prov:Activity .
- prov:Contribute rdfs:subClassOf prov:Activity .
- 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:Contributor .
- </pre>
- <p></p>
-
+ In order to produce complex mappings for the DC terms, we need specific subclasses extending the PROV ontology. These subclases
+ are designed to qualify the DC properties in the complex mappings. For example, a <code>dc:publisher</code> relationship implies a "Publish"
+ activity which used some entity to be published, produced a published entity and was associated with a publisher.
+ The PROV extensions for Dublin Core can be seen below:
+ </p><pre class="code">
+ prov:Publish rdfs:subClassOf prov:Activity .
+ prov:Contribute rdfs:subClassOf prov:Activity .
+ 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:Replace rdfs:subClassOf prov:Activity .
+ prov:Publisher rdfs:subClassOf prov:Role .
+ prov:Contributor rdfs:subClassOf prov:Role .
+ prov:Creator rdfs:subClassOf prov:Role, prov:Contributor .
+ </pre>
<p>
- Custom refinements of the properties have been omitted as they would be identical to the DC terms. If these more
- specific properties are needed, the Dublin Core terms can be used directly, according to the direct mappings presented in
- <a href="#direct-mappings">Section 3.1</a>.
+ Additional refinements of the PROV properties have been ommitted, since the direct mappings presented in <a href="#direct-mappings">Section 3.1</a>
+ already define the relationship between both vocabularies.
</p>
</section>
<section id="complex-mappings">
@@ -1329,7 +1329,7 @@
by the implementer, in order to avoid obtaining additional blank nodes when reapplying the construct queries presented
in the previous section.</p>
<p> Providing a set of rules to conflate the blank nodes is not in the scope of this document. However, the group has
- created a list of suggestions for implementers with proposals on how this could be achieved:</p>
+ created two suggestions for implementers with proposals on how this could be achieved:</p>
<p>1) <b>Conflate properties referring to the same state of the resource</b>: In Dublin Core certain properties complement each other (e.g.,
creator and created, publisher and issued, modified and contributor, etc.). By combining some of the queries, some of the records
could be grouped creating more complete PROV assertions.</p>