--- a/dc-note/dc-note.html Wed Feb 20 01:03:57 2013 +0100
+++ b/dc-note/dc-note.html Wed Feb 20 15:18:54 2013 +0100
@@ -436,12 +436,6 @@
}
/* --- EXAMPLES --- */
-pre.example {
- border-top: 1px solid #ff4500;
- border-bottom: 1px solid #ff4500;
- padding: 1em;
- margin-top: 1em;
-}
pre.code {
background-color:#F9F9F9;
@@ -451,17 +445,7 @@
padding:1em;
}
-pre.example:before {
- content: "Example";
- display: block;
- width: 150px;
- background: #ff4500;
- color: #fff;
- font-family: initial;
- padding: 3px;
- font-weight: bold;
- margin: -1em 0 1em -1em;
-}
+
/* --- EDITORIAL NOTES --- */
.issue {
@@ -586,19 +570,19 @@
<section>
<h2>Introduction</h2>
<p>
- The Dublin Core Metadata Initiative (DCMI, commonly referred to as Dublin Core) [[DCMI]] provides a core metadata vocabulary for simple and generic resource descriptions.
- The original element set was created in 1995 and contains 15 broadly-defined elements still in use.
+ The Dublin Core Metadata Initiative (DCMI) [[DCMI]] provides a core metadata vocabulary (commonly referred to as Dublin Core) for simple and generic resource descriptions.
+ The original element set (DC elements) was created in 1995 and contains 15 broadly-defined elements still in use.
The core elements have no range specification, and arbitrary values can be used as objects. The core elements have been
expanded beyond the original fifteen. Existing elements have been refined and new elements have been added. This expanded vocabulary is
- referred to as "DCMI Terms" and currently consists of 55 properties [[DCTERMS]].
+ referred to as "DCMI Terms" (DC terms) and currently consists of 55 properties [[DCTERMS]].
</p>
<p>
- The use of DCMI terms is preferred and the Dublin Core element set has been depecreated.
- Both element sets have different namespaces. The original element set is typically referred with the
- <code>dc</code> prefix, while <code>dct</code> (or <code>dcterms</code>) is used as prefix for the newer DCMI element set.
+ The use of DC terms is preferred and the DC elements have been depecreated.
+ Both sets have different namespaces. The original element set is typically referred with the
+ <code>dc</code> prefix, while <code>dct</code> (or <code>dcterms</code>) is used as prefix for the DC Terms.
</p>
<p>
- This document defines a mapping between the <code>dct</code> terms and the PROV Ontology (PROV-O) [[PROV-O]], which defines an OWL2 Ontology encoding
+ This document defines a mapping between the DC Terms and the PROV Ontology (PROV-O) [[PROV-O]], which defines an OWL2 Ontology encoding
the PROV Data Model [[PROV-DM]]. The mapping has been designed for several purposes:
<ol>
<li><b>Bridge the gap between the DC and PROV communities</b>, in order to provide valuable insights
@@ -659,15 +643,15 @@
<li> <a href="#prov-refinements">Section 3.2</a> explains the definition of new <b>refinements</b> (subclasses or subproperties) of the PROV vocabulary to reflect
the expressiveness of the DC vocabulary. These refinements can be used to enrich DC statements with additional PROV relationships.
</li>
- <li><a href="#complex-mappings">Section 3.3</a> defines <b>complex mappings</b>. These mappings make use and combine the refinements introduced
- in <a href="#prov-refinements">Section 3.2</a> in order to derive an enhanced provenance chain.
- <!--Since the mapping produces blank nodes for each <code>dct</code> statement, a clean-up phase with strategies for reducing the blank nodes is also necessary.-->
+ <li><a href="#complex-mappings">Section 3.3</a> defines <b>complex mappings</b>. These mappings make use of the refinements introduced in <a href="#prov-refinements">Section 3.2</a> and combine them
+ in order to derive an enhanced provenance chain.
+ <!--Since the mapping produces blank nodes for each DC statement, a clean-up phase with strategies for reducing the blank nodes is also necessary.-->
</li>
- <li>Due to the way in which the complex mappings are defined, blank nodes are produced for each <code>dct</code> statement. <a href="#cleanup">Section 3.4 </a>
+ <li>Due to the way in which the complex mappings are defined, blank nodes are produced for each DC statement. <a href="#cleanup">Section 3.4 </a>
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>), that have nothing to do with the provenance of a resource. Other terms summarize the
+ 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.
</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
@@ -692,7 +676,7 @@
<p>
DCMI terms hold a lot of 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 <code>dct</code> terms according to these four categories (<i>what?</i>, <i>who?</i>, <i>when?</i> and <i>how?</i>).
+ <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.
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
@@ -740,8 +724,8 @@
and therefore it is relevant for its provenance. The respective inverse properties do not necessarily contribute to
the provenance of the described resource, e.g., a resource is usually not directly affected by being referenced or
by being used as a source. However, inverse properties belong to the provenance related terms as they can be used to describe the relations
- between the resources involved. Finally, licensing and rights are considered part of the provenance of the resource as well,
- since they restrict how the resource has been used by its owners.
+ between the resources involved. Finally, licensing (<code>dct:license</code>), rights (<code>dct:rights</code>) and their access (<code>accessRights</code>)
+ are considered part of the provenance of the resource as well, since they restrict and explain how the resource can be used for further derivation.
</p>
<div id="categories" ALIGN="center">
<table>
@@ -789,7 +773,7 @@
</table>
</div>
<p>
- This leaves one very special term: <i>provenance</i>. This term is defined as a "statement of any changes in ownership and
+ This leaves one very special term: <a href ="#term_provenance">provenance</a>. This term is defined as a "statement of any changes in ownership and
custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation" [[DCTERMS]],
a definition that corresponds to the notion of provenance for artworks. This term can be considered a link between the resource and any
provenance statement about the resource, so it can't be included in any of the aforementioned categories and it is out of the scope of this mapping.
@@ -807,7 +791,7 @@
<h3>Entities in Dublin Core</h3>
<p>
Consider the example metadata record below (<a href="#example1">Example 1</a>), where a document (<code>ex:doc1</code>) is described
- with several <code>dct</code> statements:
+ with several DC statements:
</p>
<p>
<a href="#example1">Example 1</a>: a simple metadata record:
@@ -840,7 +824,7 @@
</p>
<p>
1) Create new instances of entities, typically as blank nodes, that are all related to the original
- document by means of <code>prov:specializationOf</code>. This leads to bloated and not very intuitive data models. For example, consider the
+ document by means of <code>prov:specializationOf</code>. This leads to bloated and not very intuitive data representations. For example, consider the
about the translation of a single <code>dct:publisher</code> statement (as shown on the top of <a href="#figure_mapping_example">Figure 1</a>):
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
@@ -857,8 +841,8 @@
</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 Publish
- (<code>:_activity</code>). However, this representation leads to a misinterpretation of the <code>dct</code> statement, as shown in the example of
+ 2) Adopt the original resource (<code>ex:doc1</code>) as the <code>prov:Entity</code> used and then generated by the Publish activity
+ (<code>:_activity</code>). However, this representation leads to a misinterpretation of the DC 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
<code>_:activity</code> (<code>prov:Entities</code> must exist before being used).
@@ -873,7 +857,7 @@
</div>
</div>
</p><p>
- Since the first option provides a correct interpretation of the <code>dct</code> 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 guideline in the complex mapping.
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>
@@ -896,8 +880,8 @@
<section>
<h3></span>Direct mappings</h3>
<p>
- The direct mappings relate the <code>dct</code> terms to the PROV binary relationships by using the integration mechanisms of RDF.
- PROV applications will be able to interoperate with these <code>dct</code> statements by applying means of OWL 2 RL reasoning, (i.e.,
+ The direct mappings relate the DC Terms to the PROV binary relationships by using the integration mechanisms of RDF.
+ PROV applications will be able to interoperate with these DC statements by applying means of OWL 2 RL reasoning, (i.e.,
they will be able to understand DC statements). The direct mappings also
contribute to the formal definition of the vocabularies by translating them to PROV.</p>
<p>Dublin Core, while less complex from a modeling perspective,
@@ -980,9 +964,10 @@
<td><b id="term_replaces"><a href="http://purl.org/dc/terms/replaces">dct:replaces</a></b></td>
<td>rdfs:subPropertyOf</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>
+ <td> There is a relation between two resources when the former replaces or displaces the latter, but it is not necessarily
+ derivation, revision, specialization or alternate. For example an item of a catalog can replaced with another item
+ that had nothing to do with the former (in case of mistake of the provider of the catalogue, or catalogue renovation).
+ Thus, the term is mapped to <code>prov:wasInfluencedBy</code></td>
</tr>
<tr>
<td><b id="term_source"><a href="http://purl.org/dc/terms/source">dct:source</a> </b></td>
@@ -1096,7 +1081,7 @@
</table>
</div>
<p>
- <a href="#list_of_direct_mappings_no_prov_core">Table 5</a> enumerates the mapping of the <code>dct</code> properties that map to inverse relationships in PROV. These
+ <a href="#list_of_direct_mappings_no_prov_core">Table 5</a> enumerates the mapping of the DC terms that map to inverse relationships in PROV. These
have been separated in a different table because they don't belong to the core of PROV.
</p>
<div id="list_of_direct_mappings_no_prov_core" >
@@ -1214,7 +1199,7 @@
</p>
<p>
- Custom refinements of the properties have been as they would be identical to the Dublin Core terms. If these more
+ Custom refinements of the properties have been omitted as they would be identical to the Dublin Core terms. If these more
specific properties are needed, the Dublin Core terms can be used directly, according to the direct mappings presented in section 2.3.
</p>
</section>
@@ -1249,7 +1234,7 @@
</p>
<section>
<h5> dct:creator</h5>
- A creator is the agent associated with role Creator in the Create that created a specialization of the entity (?document).
+ A creator is the agent associated with role Creator in the activity that generated a specialization of the entity ?document.
<pre class="code">
CONSTRUCT {
?document a prov:Entity ;
@@ -1597,6 +1582,8 @@
</section>
<section>
<h2>List of terms excluded from the mapping</h2>
+ <a href="#list-of-terms-excluded-from-the-mapping"> Table 6</a> lists the terms excluded from the mapping,
+ either because thay are not suitable or because they don't represent provenance information.
<!--
<div class="note">
<p>Some of the terms of the list are still under discussion: <code>dct:alternative</code> and <code>dct:references</code>.</p>
@@ -1630,7 +1617,8 @@
</tr><tr>
<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 title of the resource. </td>
+ <td>Refers to an alternative title of the resource. For example "The Bible" might be also known as "The Holy Book". Titles are not identifiers,
+ so this property can't be mapped to <code>prov:alternateOf</code></td>
</tr><tr>
<td><b id="term_audience"><a href="http://purl.org/dc/terms/audience">dct:audience</a></b></td>
<td>Descriptive metadata</td>
@@ -1730,11 +1718,13 @@
</tr><tr>
<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>
+ <td>Term used to point out, refer or cite a related resource to the resource being described. The references normally point
+ out to resources from which the current resource was derived, or that the current resource quoted. However, this is not
+ always the case. For example, if a resource A included a reference
+ to a resource B stating :"Reference [B] has nothing to do with the work described here", then we can't consider the reference as a derivation
+ or a quotation. For this reason, <code>dct:references</code> has been dropped from the mapping.</td>
</tr><tr>
- <td id="term_isReferencedBy"><b><a href="http://purl.org/dc/terms/isReferencedBy">dct:isRefrencedBy</a></b></td>
+ <td id="term_isReferencedBy"><b><a href="http://purl.org/dc/terms/isReferencedBy">dct:isReferencedBy</a></b></td>
<td> Provenance: How </td>
<td>Inverse to <code>dct:references</code>.</td>
</tr><tr>
@@ -1766,7 +1756,13 @@
<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>
+ 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. <td>
+ </tr>
+ <tr>
+ <td><b id="term_provenance"><a href="http://purl.org/dc/terms/provenance">dct:provenance</a></b></td>
+ <td>Provenance </td>
+ <td>This term is a link between the resource and any provenance statement about the resource. Since PROV-O doesn't specify any mechanisms to link a bundle of provenance statements to an entity,
+ this term is considered out of the scope of the mapping.<td>
</tr>
</tbody></table>
</p>
@@ -1774,13 +1770,15 @@
<section>
<h2>Mapping from PROV to DC</h2>
<p>
- The mapping from PROV to Dublin Core is not part of this note.
- It can be questioned, if a mapping without additional information would provide meaningful data.
- If refinements are used, the mapping would be straight forward using the inverse of the
- mapping patterns used in this document. However, without such refinements, few Dublin Core statements can be inferred,
- apart from some unqualified dates. Dublin Core includes provenance information, but the focus lies on
- the description of the resources. Pure PROV data models a provenance chain, but it contains almost
- no information about the resulting resource itself. </p>
+ The mapping from PROV to Dublin Core is not part of this note. It can be questioned whether a mapping without the refinements defined above would provide
+ meaningful data. If the refinements are used, then the inverse of the mapping patterns used in this document can be applied.
+ However, if the refinements are not used then only a few Dublin Core statements can be inferred from plain PROV statements.
+ For example, when mapping dates only unqualified properties can be extracted,
+ as there is no information if an activity with an associated date is a creation or a modification or a publication. Likewise, the agents
+ involved can't be mapped to creators, contributors, or publishers. While Dublin Core includes provenance information, its focus
+ lies on the broader description of resources. PROV models a provenance chain, but it provides almost no information about the involved
+ resources themselves.
+ </p>
</section>
</section>