--- a/dc-note/dc-note.html Fri Nov 30 15:01:08 2012 +0100
+++ b/dc-note/dc-note.html Fri Nov 30 17:20:44 2012 +0100
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<html>
<head>
- <title>Dublin Core to Prov Mapping</title>
+ <title>Dublin Core to PROV Mapping</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<!--
=== NOTA BENE ===
@@ -569,7 +569,7 @@
<li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL2 ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. </li>
<li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
<li>Readers seeking to implement other PROV serializations
- should focus on PROV-DM and PROV-CONSTRAINTS. PROV-O and PROV-N offer examples of mapping to RDF and text, respectively.</li>
+ should focus on PROV-DM and PROV-CONSTRAINTS. PROV-O and PROV-N offer examples of mapping to RDF and text, respectively.</li>
</section>
<section>
@@ -753,9 +753,9 @@
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 specialization of the document, even if the document
- has not changed. Generally, there are two possibilities to deal with this issue:</p>
+ has not changed. Generally, there are two approaches to deal with this issue:</p>
</p><p>
- 1) Create new instances of entities, typically as blank nodes, that are all related to the original
+ 1) To 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, e.g. think
about the translation of a single <code>dct:publisher</code> statement, where anyone would expect to somehow find some activity and
agent that are directly related to the document (as in <a href="#figure_mapping_example">Figure 1</a>).
@@ -768,10 +768,12 @@
</div>
</div>
</p><p>
- 2) Use the original resource (<code>ex:doc1</code>) as the instance used and generated as <code>prov:Entity</code>. However, to have an activity that uses
- an entity and generates the same entity or to have different activities that generate the same entity at different points in time
- is not compliant with the PROV constraints [[PROV-CONSTRAINTS]]. <a href="#figure_mapping_example_conflating">Figure 2</a>
- provides an example that illustrates this approach.
+ 2) To adopt the original resource (<code>ex:doc1</code>) as the <code>prov:Entity</code> used and then generated by the PublicationActivity
+ (<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
+ <code>_:activity</code> (<code>prov:Entities</code> must exist before being used).
+
</p><p>
<div id = "figure_mapping_example_conflating" class="figure" style="text-align: center;">
<img src="img/mapping-example - conflating.png"></img>
@@ -780,7 +782,7 @@
</div>
</div>
</p><p>
- Since the first option is the most conservative with respect to the underlying semantics, it has been chosen as guideline in the complex mapping.
+ Since the first option provides a correct interpretation of the <code>dct</code> 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>
@@ -1392,14 +1394,14 @@
</div>
</div>
</p>
- <p>3) Finally, another solution is to <b>ignore all the specializations of <code>ex:doc1</code> and use the resource itself</b>. This solution
+ <!--<p>3) Finally, another solution is to <b>ignore all the specializations of <code>ex:doc1</code> and use the resource itself</b>. This solution
would avoid the majority of the blank nodes, linking all the activities with the resource. However, the results would be confusing in
case there are several Dublin Core statements describing the same resource (like <code>dct:publisher</code> and <code>creator</code>), since most of the
activities would use and generate the same resource at different times (all the provenance of the different versions of the resource
would be conflated in the same entity). A graphical representation of an example can be seen in <a href="#figure_mapping_example_conflating">Figure 2</a>.
</p>
<p>
- </p>
+ </p>-->
</section>
<section>
<h2>List of terms excluded from the mapping</h2>