--- a/dc-note/dc-note.html Tue Feb 05 23:52:54 2013 +0100
+++ b/dc-note/dc-note.html Wed Feb 06 21:31:20 2013 +0100
@@ -596,17 +596,27 @@
</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
- the PROV Data Model [[PROV-DM]]. Substantially, the mapping consists of three parts:
- </p><p>
- 1) <b>Direct mappings</b> between terms that can be expressed in the form of subclass or subproperty relationships in RDFS
- – or equivalent relationships in OWL.
- </p><p>
- 2) Definition of new <b>refinements</b> (subclasses or subproperties) of the target vocabulary to reflect the expressiveness of the source vocabulary.
- </p><p>
- 3) Provision of <b>complex mappings</b> that create statements in the target vocabulary based on statements in the source vocabulary. 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.
- </p>
+ 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
+ into the different characteristics of both data models.</li>
+ <li>Help developers to <b>derive PROV data from the large amount of Dublin Core data</b> available on the web, improving interoperability between DC and PROV
+ 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>
+ <!--
+ A mapping between Dublin Core Terms and PROV-O has many advantages. First, it can provide valuable insights
+ into the different characteristics of both data models (in particular it explains PROV from a Dublin Core point of view).
+ Second, such a mapping can be used to extract PROV data from the large amount of Dublin Core data available on
+ the Web today. Third, the mapping can translate PROV data to Dublin Core and make it accessible for applications that
+ understand Dublin Core. Finally, the mapping can lower the barrier to entry for PROV adoption. Simple Dublin Core
+ statements can be used as starting point for PROV data generation.
</p>
+ MOTIVATION OF THE MAPPING GOES HERE. Instead of listing the advantages, just justify them in a paragraph. End up by describing the mapping a bit?
+ -->
+ </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:
@@ -627,20 +637,53 @@
</section>
<section>
- <h3 id ="namespaces">How to use this document</h3>
+ <h3>Structure of this document</h3>
<p>
- ------------>TO DO, methodology here.<------------
+ <a href="#preliminaries">Section 2</a> explains the main considerations to take into account in order to fully understand the mapping:
+ <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>
+ <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>
+ <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 inferr PROV binary relationships from DC data.
+ </li>
+ <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>
+ <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>
+ 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
+ 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
+ of this document.
+ </li>
+ </ul>
</p>
</section>
</div>
</section>
-<section>
+<section id="preliminaries">
<h2>Preliminaries</h2>
<p>
- --->EXPLAIN HERE THAT BEFORE IDENTIFYING THE MAPPING BETWEEN THE CONCEPTS, WE MUST HIGHLIGHT WHICH TERMS ARE PROVENANCE RELATES (SECTION1)
- PLUS HOW DO THESE TERMS DESCRIBE A RESOURCE IN DC <--
+ This section explains two main particular considerations that should be taken into account regarding the mapping:
+ <ul>
+ <li><a href="#provenance-in-dublin-core">Section 2.1</a>: The relation of the DC terms with provenance.</li>
+ <li><a href="#what-is-ex-doc1--entities-in-dublin-core">Section 2.2</a>: The definition of entities in Dublin Core.</li>
+ </ul>
</p>
- <section>
+ <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,
@@ -756,10 +799,10 @@
is kept out of the mapping.
</p>-->
</section>
- <section>
+ <section id="entities-in-dublin-core">
<h3>What is ex:doc1? Entities in Dublin Core</h3>
<p>
- Consider the example metadata record shown at the beginning of this document (in <a href="#example1">example 1</a>). As a <code>dc</code>
+ Consider the example metadata record below (in <a href="#example1">example 1</a>). As a <code>dc</code>
metadata record describes the resulting 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
@@ -829,12 +872,9 @@
<section>
<h2>Mapping from Dublin Core to PROV</h2>
- <p>A mapping between Dublin Core Terms and PROV-O has many advantages. First, it can provide valuable insights
- into the different characteristics of both data models (in particular it explains PROV from a Dublin Core point of view).
- Second, such a mapping can be used to extract PROV data from the large amount of Dublin Core data available on
- the Web today. Third, the mapping can translate PROV data to Dublin Core and make it accessible for applications that
- understand Dublin Core. Finally, the mapping can lower the barrier to entry for PROV adoption. Simple Dublin Core
- statements can be used as starting point for PROV data generation. </p>
+ --->INTRODUCE THE MAPPING HERE<---
+ Substantially, the mapping consists of three parts:
+
<section>
<h3></span>Direct mappings</h3>
<p>
@@ -1063,6 +1103,7 @@
</tbody>
</table>
</div>
+ <!--
With the direct mapping, 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 the resource in a single entity, the latter
@@ -1071,9 +1112,6 @@
</p>
<p>
Some properties have been found to be superproperties of certain prov concepts. These can be seen below in <a href="#list_of_direct_mappings2">Table 4</a>:
- <!-- SHOULD ADD THIS FOR EACH
- <pre rel="prov:wasQuotedFrom" resource="http://dvcs.w3.org/hg/prov/raw-file/tip/examples/eg-24-prov-o-html-examples/rdf/create/rdf/property_qualifiedAttribution.ttl"
- -->
</p>
<div id="list_of_direct_mappings2" ALIGN="center">
@@ -1133,6 +1171,7 @@
</tbody>
</table>
</div>
+ -->
</section>
<section>
<h3>PROV refinements</h3>