--- a/dc-note/dc-note.html Tue Apr 09 18:54:34 2013 +0200
+++ b/dc-note/dc-note.html Tue Apr 09 20:00:54 2013 +0200
@@ -30,7 +30,11 @@
"URL: <a href=\"http://dublincore.org/documents/dcmi-terms/\">http://dublincore.org/documents/dcmi-terms/</a>",
"RDFS":
"Dan Brickley; Ramanathan V. Guha. RDF Vocabulary Description Language 1.0: RDF Schema. 10 February 2004. W3C Recommendation."+
- "URL: <a href=\"http://www.w3.org/TR/2004/REC-rdf-schema-20040210\">http://www.w3.org/TR/2004/REC-rdf-schema-20040210/</a>"
+ "URL: <a href=\"http://www.w3.org/TR/2004/REC-rdf-schema-20040210\">http://www.w3.org/TR/2004/REC-rdf-schema-20040210/</a>",
+
+ "PROV-DC-REFINEMENTS": "<a href=\"http://www.w3.org/ns/prov-dc-refinements.ttl\"><cite>PROV-O refinements for Dublin Core file</cite></a>. 30 April 2013. URL: <a href=\"http://www.w3.org/ns/prov-dc-refinements.ttl\">http://www.w3.org/ns/prov-dc-refinements.ttl</a>",
+
+ "PROV-DC-DIRECT-MAPPINGS": "<a href=\"http://www.w3.org/ns/prov-dc-directmappings.ttl\"><cite>Dublin Core to PROV mapping file</cite></a>. 30 April 2013. URL: <a href=\"http://www.w3.org/ns/prov-dc-directmappings.ttl\">http://www.w3.org/ns/prov-dc-directmappings.ttl</a>"
};
var respecConfig = {
@@ -211,15 +215,14 @@
<!-- END OF RDFA ANNOTATIONS-->
<section id="abstract">
<p>
- This document describes a partial mapping from Dublin Core Terms [[DCTERMS]] to the PROV-O OWL2 ontology [[PROV-O]]. 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
- properties and classes, which can be found <a href="http://www.w3.org/ns/prov-dc-directmappings.ttl">here</a>.
+ 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 a resource. The mapping is expressed partly by direct RDFS/OWL mappings between
+ properties and classes, which can be found here [[PROV-DC-DIRECT-MAPPINGS]].
</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.
- This set of PROV refinements can be accessed <a href="http://www.w3.org/ns/prov-dc-refinements.ttl">here</a>.
+ 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 here [[PROV-DC-REFINEMENTS]].
</p>
<p>
The PROV Document Overview [[PROV-OVERVIEW]] describes the overall state of PROV, and should be read before other PROV documents.
@@ -267,14 +270,41 @@
</section>
- <section>
-<h2>Introduction</h2>
+ <section id="introduction">
+<!--OddPage--><h2>Introduction</h2>
<p>
- 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 Dublin Core Metadata Initiative (DCMI) [<cite><a href="#bib-DCMI" class="bibref">DCMI</a></cite>] provides a core
+ metadata vocabulary (commonly referred to as Dublin Core) for simple
+ and generic resource descriptions[<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>]. The original Dublin Core Metadata
+ Element Set was created in 1995 and contains fifteen broadly defined
+ properties that are still in use. Properties identified using the
+ original namespace URI <a href="http://purl.org/dc/elements/1.1/">http://purl.org/dc/elements/1.1/</a> have no
+ specified ranges, meaning that arbitrary values can be used as
+ objects. In order to assign ranges, DCMI replicated the fifteen
+ properties using the namespace URI <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a>. Additional
+ properties and classes beyond the original fifteen were coined using
+ this namespace URI. In this document, properties and classes using the
+ /terms/ namespace URI are referred to, simply, as DC Terms.
+ </p>
+<p>
+ This document defines a mapping between the DC Terms and the PROV
+ Ontology (PROV-O) [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>], which defines an OWL2 Ontology encoding the
+ PROV Data Model [<cite><a href="#bib-PROV-DM" class="bibref">PROV-DM</a></cite>]. The PROV vocabulary and data model are focused on expressing actions
+ and resource states in a provenance chain rather than on describing
+ resources in a general sense. The Dublin Core vocabulary is focused on
+ describing resources in a general sense, but a substantial number of
+ terms in the vocabulary provide information related to the provenance
+ of the resource. Mapping statements using Dublin Core into statements
+ using PROV makes the contained provenance information explicit. This mapping has been
+ designed for several purposes:
+ </p>
+ <!--
+ <p>
+ The Dublin Core Metadata Initiative (DCMI) [<cite><a href="#bib-DCMI" class="bibref">DCMI</a></cite>] 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" (DC terms) and currently consists of 55 properties [[DCTERMS]].
+ referred to as "DCMI Terms" (DC terms) and currently consists of 55 properties [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>].
</p>
<p>
The use of DC terms is preferred and the DC elements have been depecreated.
@@ -282,8 +312,9 @@
<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 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:
+ This document defines a mapping between the DC Terms and the PROV Ontology (PROV-O) [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>], which defines an OWL2 Ontology encoding
+ the PROV Data Model [<cite><a href="#bib-PROV-DM" class="bibref">PROV-DM</a></cite>]. The mapping has been designed for several purposes:
+ </p>-->
<ol>
<li><b>Bridge the gap between the DC and PROV communities</b>, in order to provide valuable insights
into the different characteristics of both data models.</li>
@@ -291,42 +322,42 @@
applications.</li>
<li><b>Facilitate PROV adoption</b>. Simple Dublin Core statements can be used as a starting point for more complex PROV data generation.</li>
</ol>
- </p>
+ <p></p>
<p>
- <section>
- <h3 id ="namespaces">Namespaces</h3>
- <p>The namespaces used through the document can be seen in <a href="#ns"> Table 2</a> below:
- <div id="ns" ALIGN="center">
- <table>
- <caption> <a href="#ns"> Table 2</a>: Namespaces used in the document </caption>
+ </p><section id="namespaces-1">
+ <h3 id="namespaces">Namespaces URIs</h3>
+ <p>The namespace URIs used in this document can be seen in <a href="#ns"> Table 2</a>:
+ </p><div id="ns" >
+ <table style="margin-left: auto; margin-right: auto;">
+ <caption> <a href="#ns"> Table 2</a>: Namespaces URIs used in the document </caption>
<tbody>
- <tr><td><b>prefix</b></td><td><b>Namespace IRI</b></td><td><b>Definition</b></td></tr>
- <tr><td>owl</td><td><http://www.w3.org/2002/07/owl#></td><td>The OWL namespace [[OWL2-OVERVIEW]].</td></tr>
- <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><b>prefix</b></td><td><b>Namespace IRI</b></td><td><b>Used for</b></td></tr>
+ <tr><td>owl</td><td><http://www.w3.org/2002/07/owl#></td><td>The OWL vocabulary [<cite><a href="#bib-OWL2-OVERVIEW" class="bibref">OWL2-OVERVIEW</a></cite>].</td></tr>
+ <tr><td>rdfs</td><td><http://www.w3.org/2000/01/rdf-schema#></td><td>The RDFS vocabulary[<cite><a href="#bib-RDFS" class="bibref">RDFS</a></cite>].</td></tr>
+ <tr><td>prov</td><td><http://www.w3.org/ns/prov#></td><td>The PROV vocabulary [<cite><a href="#bib-PROV-DM" class="bibref">PROV-DM</a></cite>].</td></tr>
+ <tr><td>dct</td><td><http://purl.org/dc/terms/></td><td>The DCMI /terms/ vocabulary [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>].</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 URIs. Used in the examples of the document.</td></tr>
</tbody>
</table>
</div>
- </p>
+ <p></p>
</section>
- <section>
+ <section id="structure-of-this-document">
<h3>Structure of this document</h3>
<p>
<a href="#preliminaries">Section 2</a> explains the main considerations to take into account in order to fully understand the mapping:
- <ul>
+ </p><ul>
<li>The DC terms related to the provenance of a resource (<a href="#provenance-in-dublin-core">Section 2.1</a>).</li>
<li>How entities are defined in Dublin Core, along with several examples (<a href="#entities-in-dublin-core">Section 2.2</a>).</li>
</ul>
- </p>
+ <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:
- <ul>
+ 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.
</li>
@@ -335,36 +366,36 @@
</li>
<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.-->
+ <!--Since the mapping produces blank nodes for each DC statement, a cleanup 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 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> 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.
</li>
</ul>
- </p>
+ <p></p>
</section>
- </div>
+
</section>
<section id="preliminaries">
- <h2>Preliminaries</h2>
+ <!--OddPage--><h2>Preliminaries</h2>
<p>
This section explains two main particular considerations that should be taken into account regarding the mapping:
- <ul>
+ </p><ul>
<li><a href="#provenance-in-dublin-core">Section 2.1</a>: The relation of the DC terms with provenance.</li>
<li><a href="#entities-in-dublin-core">Section 2.2</a>: The definition of entities in Dublin Core.</li>
</ul>
- </p>
+ <p></p>
<section id="provenance-in-dublin-core">
<h3>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.
@@ -374,8 +405,8 @@
</p>
<!-- A total of 25 out of 55 terms can be considered provenance related.-->
<p>
- <b> Descriptive Terms (What?):</b> This category contains all the terms describing a resource without refering to its provenance (a total of 30 out of 55 terms).
- Some examples are the <code>dct:title</code>, <code> dct:abstract</code> or <code>dct:description</code> of a resource, the <code>dct:format</code> in which the resource can be found, etc.
+ <b> Descriptive Terms (What?):</b> This category contains all the terms describing a resource without referring to its provenance (a total of 30 out of 55 terms).
+ Some examples are the <code>dct:title</code>, <code> dct:abstract</code>, the <code>dct:description</code> of a resource or the <code>dct:format</code> in which the resource can be found.
</p>
<p>
<b>Agency Terms (Who?):</b> This category contains agent related terms. All properties have <code>dct:Agent</code> as range,
@@ -416,8 +447,8 @@
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>
+ <div id="categories" >
+ <table style="margin-left: auto; margin-right: auto;">
<caption> <a href="#categories"> Table 1:</a> Categorization of the Dublin Core Terms </caption>
<tbody>
<tr>
@@ -462,8 +493,8 @@
</table>
</div>
<p>
- 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]],
+ 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" [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>],
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 cannot be included in any of the aforementioned categories.
<!--Despite being relevant for provenance,
@@ -484,16 +515,14 @@
</p>
<p>
<a href="#example1">Example 1</a>: a simple metadata record:
- <pre class="example" id="example1">
- ex:doc1 dct:title "A mapping from Dublin Core..." ;
- dct:creator ex:kai, ex:daniel, ex:simon, ex:michael ;
- dct:created "2012-02-28" ;
- dct:publisher ex:w3c ;
- dct:issued "2012-02-29" ;
- dct:subject ex:dublincore ;
- dct:replaces ex:doc2 ;
- dct:format "HTML" .
- </pre>
+ </p><pre class="example" id="example1">ex:doc1 dct:title "A mapping from Dublin Core..." ;
+dct:creator ex:kai, ex:daniel, ex:simon, ex:michael ;
+dct:created "2012-02-28" ;
+dct:publisher ex:w3c ;
+dct:issued "2012-02-29" ;
+dct:subject ex:dublincore ;
+dct:replaces ex:doc2 ;
+dct:format "HTML" .</pre>
In <a href="#example1">Example 1</a>, <code>dct:title</code>, <code>dct:subject</code> and <code>dct:format</code>
are descriptions of the resource <code>ex:doc1</code>.
They do not provide any information on how the resource was created or modified in the past.
@@ -502,15 +531,15 @@
of the <code>dct:issued</code> date implies that the document has been published. This information is redundantly
implied by the <code>dct:publisher</code> statement as well. Finally, <code>dct:replaces</code> relates
<code>ex:doc1</code> to the document <code>ex:doc2</code>, a previous resource representing the mapping.<!-- which probably had some kind of influence on <code>ex:doc1</code>.-->
- </p>
+ <p></p>
As a <code>dc</code>
metadata record describes the document as a whole,
it is not clear how this document relates to the different states that the document had until it reached its final state.
For example, a document may have a <code>dct:created</code> date and a <code>dct:issued</code> date. According to
the PROV ontology, the activity of issuing a document involves two different states of the document: the document before it was issued
and the issued document. Each of these states correspond to a different <code>prov:specialization</code> of the document. Generally,
- there are two approaches to deal with this issue:</p>
- </p>
+ there are two approaches to deal with this issue:<p></p>
+ <p></p>
<p>
1) Create new instances of entities that are all related to the original
document by means of <code>prov:specializationOf</code>. For example, consider the
@@ -518,18 +547,18 @@
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>
- <div id = "figure_mapping_example" style="text-align: center;">
- <img src="img/example1.png"></img>
+ </p><div id="figure_mapping_example" style="text-align: center;">
+ <img src="img/example1.png" alt="A mapping example creating blank nodes for each state of the resource">
<div style="text-align: center;">
<a href="#figure_mapping_example">Figure 1</a>. A mapping example creating blank nodes for each state of the resource. PROV entities are represented
with ellipses, activities with rectangles and agents with pentagons. The bold arrow implies how the DC statement (on top of the figure) would be converted
to PROV (the graph on the bottom).
</div>
</div>
- </p><p>
+ <p></p><p>
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>
@@ -537,27 +566,27 @@
<code>_:activity</code> (<code>prov:Entities</code> must exist before being used).
</p><p>
- <div id = "figure_mapping_example_conflating" style="text-align: center;">
- <img src="img/mapping-example - conflating.png"></img>
+ </p><div id="figure_mapping_example_conflating" style="text-align: center;">
+ <img src="img/mapping-example - conflating.png" alt="A mapping example conflating blank nodes within the same resource">
<div style="text-align: center;">
<a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes within 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>
- Since the first option provides a correct interpretation of the DC statements, it has been chosen as guideline in the complex mapping.
+ <p></p><p>
+ 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.
+ leaving the conflating of nodes to the cleanup phase.
</p>
</section>
</section>
-<section>
- <h2>Mapping from Dublin Core to PROV</h2>
+<section id="mapping-from-dublin-core-to-prov">
+ <!--OddPage--><h2>Mapping from Dublin Core to PROV</h2>
<p>
This section describes the mapping between Dublin Core and PROV. The mapping is divided in several subsections:
- <ul>
+ </p><ul>
<li> <a href="#direct-mappings">Section 3.1</a>: Direct mappings between Dublin Core and PROV.</li>
<li> <a href="#prov-refinements">Section 3.2</a>: Extension of PROV classes and properties to represent DC activities.</li>
<li> <a href="#complex-mappings">Section 3.3</a>: Complex mappings between Dublin Core and PROV (inferring activities using blank nodes).</li>
@@ -565,11 +594,11 @@
<li> <a href="#list-of-terms-excluded-from-the-mapping">Section 3.5</a>: Rationale for the terms excluded of the mapping.</li>
<li> <a href="#mapping-from-prov-to-dc">Section 3.6</a>: Mapping PROV to Dublin Core (out of the scope of this mapping).</li>
</ul>
- </p>
- <section>
- <h3></span>Direct mappings</h3>
+ <p></p>
+ <section id="direct-mappings">
+ <h3>Direct mappings</h3>
<p>
- The direct mappings relate the DC Terms to the PROV binary relationships by using the integration mechanisms of RDF.
+ The direct mappings [<cite><a href="#bib-mapping" class="bibref">PROV-DC-DIRECT-MAPPINGS</a></cite>] 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>
@@ -588,8 +617,8 @@
</div>
-->
<p>
- <div id="list_of_direct_terms" ALIGN="center">
- <table>
+ </p><div id="list_of_direct_terms" >
+ <table style="margin-left: auto; margin-right: auto;">
<caption> <a href="#list_of_direct_terms"> Table 3:</a> Direct mappings </caption>
<tbody>
<tr>
@@ -621,7 +650,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>
@@ -633,7 +662,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>
@@ -648,7 +677,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>
@@ -660,7 +689,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>
@@ -775,10 +804,10 @@
</div>
<p>
<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.
+ have been separated in a different table because they do not belong to the core of PROV.
</p>
- <div id="list_of_direct_mappings_no_prov_core" >
- <table>
+ <div id="list_of_direct_mappings_no_prov_core">
+ <table style="margin-left: auto; margin-right: auto;">
<caption> <a href="#list_of_direct_mappings_no_prov_core"> Table 5:</a> Direct mappings to the PROV terms not included in the core </caption>
<tbody>
<tr>
@@ -804,65 +833,65 @@
</div>
</section>
- <section>
+ <section id="prov-refinements">
<h3>PROV refinements</h3>
<p>
- To properly reflect the meaning of the Dublin Core terms, more specific subclasses are needed:
- </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>
-
+ In order to produce complex mappings for the DC terms, we need specific subclasses extending the PROV ontology [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>].
+ These subclases [<cite><a href="#bib-refinements" class="bibref">PROV-DC-REFINEMENTS</a></cite>]
+ 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>
+ <section id="complex-mappings">
<h3>Complex Mappings</h3>
<p>
The complex mappings consist of a set of patterns defined to generate qualified PROV statements from Dublin Core statements. This type of qualification may not be
always needed, and it is the choice of the implementer whether to use them or not depending on the use case. It is also important to note that not all the
direct mappings have a complex mapping associated, just those which imply a specific activity: creation, publication, etc.
The complex mappings are provided in form of SPARQL CONSTRUCT queries, i.e., queries that describe a
- resulting RDF graph based on another RDF graph found in the original data. We divide the queries in different categories:
+ resulting RDF graph based on another RDF graph found in the original data. We divide the queries into different categories:
</p>
- <section>
+ <section id="entity-agent-mappings-who">
<h4>Entity-Agent mappings (Who)</h4>
<p>
In this category, we have three terms: <code>dct:contributor</code>, <code>dct:creator</code> and <code>dct:publisher</code>.
The three of them can be mapped with the same pattern, similar to the one presented in <a href="#figure_mapping_example">Figure 1</a>.
The only changes required are the roles and activities involved for each term.
- <p>
+ </p><p>
In the text below, variables <code>?document</code> and <code>?agent</code> are set to different matching values depending
on the available data. The graph in the CONSTRUCT part can be seen as a template
where the variables are placeholders that are filled with the values found in the data.
The mapping corresponds to the graph in <a href="#figure_mapping_example">Figure 1</a> (with small changes
for creator and rightsHolder). With this mapping,
- the difference in the complexity becomes obvious. Many blank nodes are created, so a subsequent clean-up phase that relates them and provides stable
+ the difference in the complexity becomes obvious. Many blank nodes are created, so a subsequent cleanup phase that relates them and provides stable
URIs for the entities is required. Depending on the implementation, URIs can also be coined here for every specialization.
<!--Sometimes URIs for the specializations are also available and simply not exposed to the Dublin Core record.-->
The implementation proposed in this document is an example that works conservatively. The assumption is that no further
information about the identity of the specializations is available.
</p>
- <section>
- <h5> dct:creator</h5>
+ <section id="dct-creator">
+ <h5>dct:creator</h5>
A creator is the agent in charge of the "Create" activity that generated a specialization of the entity ?document. The agent is assigned the role "creator".
- <pre class="code">
- CONSTRUCT {
+ <pre class="code"> CONSTRUCT {
?document a prov:Entity ;
prov:wasAttributedTo ?agent.
@@ -886,11 +915,10 @@
}
</pre>
</section>
- <section>
+ <section id="dct-contributor">
<h5>dct:contributor</h5>
Contributor is mapped following the previous pattern. Only the roles and activities change:
- <pre class="code">
- CONSTRUCT {
+ <pre class="code"> CONSTRUCT {
?document a prov:Entity ;
prov:wasAttributedTo ?agent .
@@ -914,11 +942,10 @@
}
</pre>
</section>
- <section>
+ <section id="dct-publisher">
<h5>dct:publisher</h5>
In case of publication, a second specialization representing the entity before the publication is necessary:
- <pre class="code">
- CONSTRUCT {
+ <pre class="code"> CONSTRUCT {
?document a prov:Entity ;
prov:wasAttributedTo ?agent .
@@ -946,25 +973,26 @@
?document dct:publisher ?agent .
}
</pre>
- </p>
+ <p></p>
</section>
</section>
- <section>
+ <section id="entity-date-mappings-when">
<h4>Entity-Date mappings (When)</h4>
<p>
Dates often correspond with a who-property, e.g., creator and created or publisher and issued.
Therefore, they lead to similar complex patterns (associating a date to each activity instead of an agent).
When using Dublin Core terms, it is usual to see that a resource is annotated with several <code>dct</code> assertions like creator, publisher,
- issued, date, etc. In this section each term is treated independently. It is important to note that since the range for dates in Dublin Core is a
- <code>rdfs:Literal</code> and <code>xsd:dateTime</code> for the <code>prov:atTime</code> property, the mapping is only valid for those literals
- that are <code>xsd:dateTime</code>.
+ issued, date, etc. In this section each term is treated independently.
+ It is important to note that since the range for DC date properties is
+ <code>rdfs:Literal</code>, and the range of the <code>prov:atTime</code> property is the class
+ of literals with the datatype <code>xsd:dateTime</code>, the mapping is only valid
+ for those literals that have the datatype <code>xsd:dateTime</code>.
</p>
- <section>
- <h5> dct:created</h5>
- </p>
- <pre class="code">
- CONSTRUCT{
+ <section id="dct-created">
+ <h5>dct:created</h5>
+ <p></p>
+ <pre class="code"> CONSTRUCT{
?document a prov:Entity .
_:activity a prov:Activity, prov:Create ;
@@ -985,11 +1013,10 @@
</pre>
</section>
- <section>
+ <section id="dct-issued">
<h5>dct:issued</h5>
<p>
- <pre class="code">
- CONSTRUCT{
+ </p><pre class="code"> CONSTRUCT{
?document a prov:Entity .
_:activity a prov:Activity, prov:Publish ;
@@ -1014,11 +1041,11 @@
?document dct:issued ?date.
}
</pre>
- </p>
+ <p></p>
</section>
- <section>
+ <section id="dct-modified">
<h5>dct:modified</h5>
- <p><pre class="code">
+ <p></p><pre class="code">
CONSTRUCT{
?document a prov:Entity .
@@ -1044,11 +1071,11 @@
?document dct:modified ?date.
}
</pre>
- </p>
+ <p></p>
</section>
- <section>
+ <section id="dct-dateaccepted">
<h5>dct:dateAccepted</h5>
- <p><pre class="code">
+ <p></p><pre class="code">
CONSTRUCT{
?document a prov:Entity .
@@ -1074,12 +1101,11 @@
?document dct:dateAccepted ?date.
}
</pre>
- </p>
+ <p></p>
</section>
- <section>
+ <section id="dct-datecopyrighted">
<h5>dct:dateCopyrighted</h5>
- <p><pre class="code">
-CONSTRUCT{
+ <p></p><pre class="code">CONSTRUCT{
?document a prov:Entity .
_:activity a prov:Activity, prov:Copyright ;
@@ -1103,12 +1129,11 @@
} WHERE {
?document dct:dateCopyrighted ?date.
}
- </pre></p>
+ </pre><p></p>
</section>
- <section>
+ <section id="dct-datesubmitted">
<h5>dct:dateSubmitted</h5>
- <p><pre class="code">
- CONSTRUCT{
+ <p></p><pre class="code"> CONSTRUCT{
?document a prov:Entity .
_:activity a prov:Activity, prov:Submit ;
@@ -1133,32 +1158,31 @@
?document dct:dateSubmitted ?date.
}
</pre>
- </p>
+ <p></p>
</section>
</section>
- <section>
+ <section id="entity-entity-mappings-how">
<h4>Entity-Entity mappings (How)</h4>
<p>
- In Dublin Core, most of the properties relating entities to other entities don't describe the involvement of a specific activity
+ In Dublin Core, most of the properties relating entities to other entities do not imply activities related to provenance
(e.g., <code>dct:format</code>, <code>dct:source</code> or <code>isVersionOf</code>).
The only exception is <code>dct:replaces</code>, further explained below.
</p>
- <section>
+ <section id="dct-replaces">
<h5 id="term_replaces">dct:replaces</h5>
<p>
There is a relation between two resources when the former replaces or displaces the latter. The replacement is
- the result of a "search and replace" Activity, which used a specialization of the replaced entity (<code>_:old_entity</code>) and
- produced a specialization of the replacement (<code>_:new_entity</code>). Thus, <code>_:new_entity</code> was derived from
- <code>_:old_entity</code>, as it couldn't have existed without it. However, the derivation relationship cannot always be applied between the original entities, because they
+ the result of a "replace" Activity, which used a specialization of the replaced entity (<code>_:old_entity</code>) and
+ generated a specialization of the replacement (<code>_:new_entity</code>). Thus, <code>_:new_entity</code> was derived from
+ <code>_:old_entity</code>, as it could not have existed without it. However, the derivation relationship cannot always be applied between the original entities, because they
could have existed before the replacement took place (for example, if a book replaces another in a catalog we cannot say that it was
derived from it).
</p>
<p>
- <pre class="code">
-CONSTRUCT{
+ </p><pre class="code">CONSTRUCT{
?document a prov:Entity .
?document2 a prov:Entity.
@@ -1178,28 +1202,27 @@
} WHERE {
?document dct:replaces ?document2.
}
- </pre></p>
+ </pre><p></p>
</section>
<p>
The term <code>dct:isReplacedBy</code> would produce a similar mapping, inverting the roles of document and document2.
</p>
</section>
</section>
- <section>
+ <section id="cleanup">
<h3>Cleanup</h3>
<p>
- The clean-up phase depends on how implementers interpret the described resources. The approach presented in this document
- leads to the proliferation of blank nodes. Blank nodes could be renamed to specific identifiers
+ The cleanup phase aims to reduce the number of blank nodes produced by the complex mappings. This depends on how implementers interpret the
+ described resources. Blank nodes could be renamed to specific identifiers
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>
<p>The example below shows how to conflate the blank nodes for <code>dct:creator</code> and <code>dct:created</code> properties:
- <pre class="code">
- CONSTRUCT{
+ </p><pre class="code"> CONSTRUCT{
?document a prov:Entity .
_:activity a prov:Activity, prov:Create.
@@ -1227,34 +1250,34 @@
</pre>
<a href="#figure_cleanup1">Figure 3</a> shows a graphical representation of the pattern:
- <div id = "figure_cleanup1" style="text-align: center;">
- <img src="img/cleanup1.png"></img>
+ <div id="figure_cleanup1" style="text-align: center;">
+ <img src="img/cleanup1.png" alt="Using complementing properties to conflate blank nodes">
<div style="text-align: center;">
<a href="#figure_cleanup1">Figure 3</a>. Using complementing properties to conflate blank nodes. Dates are represented in green and roles in purple.
</div>
</div>
- </p>
+ <p></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 with 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. Creation precedes publication, so instead of creating different blank nodes for their respective usage and generation, both activities share the same
blank node (<code>_:created_entity</code>).
- <div id = "figure_cleanup2" style="text-align: center;">
- <img src="img/cleanup2.png"></img>
+ </p><div id="figure_cleanup2" style="text-align: center;">
+ <img src="img/cleanup2.png" alt="Ordering activities to conflate blank nodes">
<div style="text-align: center;">
<a href="#figure_cleanup2">Figure 4</a>. Ordering activities to conflate blank nodes. The creation activity occurs before the publishing activity.
</div>
</div>
- </p>
+ <p></p>
</section>
- <section>
- <h2>List of terms excluded from the mapping</h2>
+ <section id="list-of-terms-excluded-from-the-mapping">
+ <h3>List of terms excluded from the mapping</h3>
<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.
+ either because thay are not suitable or because they do not represent provenance information.
<p>
- <table>
+ </p><table>
<caption> <a href="#list-of-terms-excluded-from-the-mapping"> Table 6:</a> List of terms excluded from the mapping </caption>
<tbody>
<tr>
@@ -1268,7 +1291,7 @@
</tr><tr>
<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>
+ <td>Method by which items are added to a collection. It does not describe the action itself, so it is out of the scope of the mapping.</td>
</tr><tr>
<td><b id="term_accrualPeriodicity"><a href="http://purl.org/dc/terms/accrualPeriodicity">dct:accrualPeriodicity</a></b></td>
<td>Descriptive metadata</td>
@@ -1405,16 +1428,15 @@
<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>
</tbody></table>
- </p>
+ <p></p>
</section>
- <section>
- <h2>Mapping from PROV to DC</h2>
+ <section id="mapping-from-prov-to-dc">
+ <h3>Mapping from PROV to DC</h3>
<p>
The mapping from PROV to Dublin Core is not part of this note. If the refinements proposed in this document are used, then the inverse of the complex mapping
patterns 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
+ For example, when mapping dates there is no information to guess whether an activity with an associated date is a creation, a modification or a publication. Likewise, the agents
involved cannot 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.
@@ -1422,14 +1444,16 @@
</section>
</section>
- <section class="appendix">
- <h2>Acknowledgements</h2>
+ <section id="acknowledgements" class="appendix">
+ <!--OddPage--><h2>Acknowledgements</h2>
<p>
This document is the result of a collaboration between the Provenance Working Group and the Dublin Core Metadata Initiative.
- The editors extend special thanks to Antoine Isaac, Ivan Herman, Timothy Lebo, Luc Moreau, Paul Groth and Satya Sahoo for their feedback; and María Poveda and Idafen Santana for their help with the HTML generation.
+ The editors extend special thanks to Antoine Isaac, Ivan Herman, Timothy Lebo, Luc Moreau, Paul Groth, Satya Sahoo and Tom Baker for their feedback; and María Poveda and Idafen Santana for their help with the HTML generation.
</p>
+ <p>
+ Members of the Provenance Working Group at the time of publication of this document were: Ilkay Altintas (Invited expert), Reza B'Far (Oracle Corporation), Khalid Belhajjame (University of Manchester), James Cheney (University of Edinburgh, School of Informatics), Sam Coppens (iMinds - Ghent University), David Corsar (University of Aberdeen, Computing Science), Stephen Cresswell (The National Archives), Tom De Nies (iMinds - Ghent University), Helena Deus (DERI Galway at the National University of Ireland, Galway, Ireland), Simon Dobson (Invited expert), Martin Doerr (Foundation for Research and Technology - Hellas(FORTH)), Kai Eckert (Invited expert), Jean-Pierre EVAIN (European Broadcasting Union, EBU-UER), James Frew (Invited expert), Irini Fundulaki (Foundation for Research and Technology - Hellas(FORTH)), Daniel Garijo (Ontology Engineering Group, Universidad Politécnica de Madrid), Yolanda Gil (Invited expert), Ryan Golden (Oracle Corporation), Paul Groth (Vrije Universiteit), Olaf Hartig (Invited expert), David Hau (National Cancer Institute, NCI), Sandro Hawke (W3C/MIT), Jörn Hees (German Research Center for Artificial Intelligence (DFKI) Gmbh), Ivan Herman, (W3C/ERCIM), Ralph Hodgson (TopQuadrant), Hook Hua (Invited expert), Trung Dong Huynh (University of Southampton), Graham Klyne (University of Oxford), Michael Lang (Revelytix, Inc.), Timothy Lebo (Rensselaer Polytechnic Institute), James McCusker (Rensselaer Polytechnic Institute), Deborah McGuinness (Rensselaer Polytechnic Institute), Simon Miles (Invited expert), Paolo Missier (School of Computing Science, Newcastle university), Luc Moreau (University of Southampton), James Myers (Rensselaer Polytechnic Institute), Vinh Nguyen (Wright State University), Edoardo Pignotti (University of Aberdeen, Computing Science), Paulo da Silva Pinheiro (Rensselaer Polytechnic Institute), Carl Reed (Open Geospatial Consortium), Adam Retter (Invited Expert), Christine Runnegar (Invited expert), Satya Sahoo (Invited expert), David Schaengold (Revelytix, Inc.), Daniel Schutzer (FSTC, Financial Services Technology Consortium), Yogesh Simmhan (Invited expert), Stian Soiland-Reyes (University of Manchester), Eric Stephan (Pacific Northwest National Laboratory), Linda Stewart (The National Archives), Ed Summers (Library of Congress), Maria Theodoridou (Foundation for Research and Technology - Hellas(FORTH)), Ted Thibodeau (OpenLink Software Inc.), Curt Tilmes (National Aeronautics and Space Administration), Craig Trim (IBM Corporation), Stephan Zednik (Rensselaer Polytechnic Institute), Jun Zhao (University of Oxford), Yuting Zhao (University of Aberdeen, Computing Science).
+ </p>
</section>
- <section class="appendix">
<h2>Changes Since Second Public Working Draft</h2>
<ul>
<li>Added the mapping to prov:has_provenance.</li>