--- a/dc-note/Overview.html Thu Oct 18 09:46:07 2012 -0600
+++ b/dc-note/Overview.html Mon Oct 22 18:46:59 2012 +0200
@@ -515,9 +515,9 @@
<img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C" /></a></p>
<h1 class="title" id="title">Dublin Core to PROV Mapping</h1><h2 id="w3c-working-draft-19-august-2012">
<acronym title="World Wide Web Consortium">W3C</acronym> Editor's Draft 19 August 2012</h2>
- <dl><dt>This version:</dt><dd><a href="https://dvcs.w3.org/hg/prov/raw-file/37f9692fb7a0/dc-note/Overview.html">https://dvcs.w3.org/hg/prov/raw-file/37f9692fb7a0/dc-note/Overview.html</a></dd>
- <dt>Latest published version:</dt><dd><a href="https://dvcs.w3.org/hg/prov/raw-file/37f9692fb7a0/dc-note/Overview.html">https://dvcs.w3.org/hg/prov/raw-file/37f9692fb7a0/dc-note/Overview.html</a></dd>
- <dt>Latest editor's draft:</dt><dd><a href="https://dvcs.w3.org/hg/prov/raw-file/37f9692fb7a0/dc-note/Overview.html">https://dvcs.w3.org/hg/prov/raw-file/37f9692fb7a0/dc-note/Overview.html</a></dd>
+ <dl><dt>This version:</dt><dd><a href="https://dvcs.w3.org/hg/prov/raw-file/ff940ee82d3d/dc-note/Overview.html/">https://dvcs.w3.org/hg/prov/raw-file/ff940ee82d3d/dc-note/Overview.html</a></dd>
+ <dt>Latest published version:</dt><dd><a href="https://dvcs.w3.org/hg/prov/raw-file/ff940ee82d3d/dc-note/Overview.html">https://dvcs.w3.org/hg/prov/raw-file/ff940ee82d3d/dc-note/Overview.html</a></dd>
+ <dt>Latest editor's draft:</dt><dd><a href="https://dvcs.w3.org/hg/prov/raw-file/ff940ee82d3d/dc-note/Overview.html">https://dvcs.w3.org/hg/prov/raw-file/ff940ee82d3d/dc-note/Overview.html</a></dd>
<dt>Editors:</dt>
<dd><a href="http://www.bib.uni-mannheim.de/279.html">Kai Eckert</a>, Manheim University Library, Manheim, Germany</dd>
<dd><a href="http://www.oeg-upm.net/index.php/en/phdstudents/28-dgarijo">Daniel Garijo</a></span>, Universidad Politécnica de Madrid</dd>
@@ -577,7 +577,7 @@
<li class="tocline"><a href="#Mapping" class="tocxref"><span class="secno">2. </span>Mapping Dublin Core to PROV</a></li>
<ul class="toc">
<li class="tocline"><a href="#basic" class="tocxref"><span class="secno">2.1 </span>Basic considerations</a></li>
- <li class="tocline"><a href="#entities_in_dc" class="tocxref"><span class="secno">2.2 </span>What is ex:document1? Entities in Dublin Core</a></li>
+ <li class="tocline"><a href="#entities_in_dc" class="tocxref"><span class="secno">2.2 </span>What is ex:doc1? Entities in Dublin Core</a></li>
<li class="tocline"><a href="#mappings" class="tocxref"><span class="secno">2.3 </span>Direct Mappings</a></li>
<li class="tocline"><a href="#refinements" class="tocxref"><span class="secno">2.4 </span>PROV Refinements</a></li>
<li class="tocline"><a href="#complex_mappings" class="tocxref"><span class="secno">2.5 </span>Complex Mappings</a></li>
@@ -626,10 +626,10 @@
<h2><span class="secno">1. </span>Introduction</h2>
<p>
The Dublin Core Metadata Initiative (DCMI) [<a href="#bib-DCMI">DCMI</a>] provides a core metadata vocabulary,
- commonly refered to as Dublin Core. Originally, it consisted of 15 elements that are still available and called
- the element set. The elements are defined very broadly, in particular they have no
+ commonly referred to as Dublin Core. The original element set consisted of 15 elements that are still available nowadays.
+ These elements are defined very broadly, in particular they have no
range specification, i.e., they can be used with arbitrary values as objects. The elements have been further
- refined and types have been introduced. This more specific vocabulary is called the terms and currently consists
+ refined and new types have been introduced. This more specific vocabulary is called the terms and currently consists
of 55 properties [<a href="#bib-DCTERMS">DCTERMS</a>].
</p>
The Dublin Core elements are considered legacy and the use of the DCMI terms is preferred. They have different namespaces;
@@ -638,7 +638,7 @@
Consider the following example for a metadata record:
<pre class="example" id="example1">
- ex:document1 dct:title "A mapping from Dublin Core..." ;
+ 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 ;
@@ -649,18 +649,18 @@
</pre>
<p>
Clearly not all metadata statements deal with provenance.
- <code>dct:title</code>, <code>dct:subject</code> and <code>dct:format</code> are descriptions of the resource <code>ex:document1</code>.
-They do not provide any information how the resource was created or modified in the past.
+ <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.
On the other hand, some statements imply provenance-related information. For example <code>dct:creator</code>
- implies that the document has been created and refers to the author. Similarly, the existence
+ implies that the document has been created and refers an author. Similarly, the existence
of the <code>dct:issued</code> date implies that the document has been published. This information is redundantly
- implied by the dct:publisher statement as well. Finally, <code>dct:replaces</code> relates
- our document to another document <code>ex:doc2</code> which had probably
- some kind of influence on <code>ex:document1</code>.
+ implied by the <code>dct:publisher</code> statement as well. Finally, <code>dct:replaces</code> relates
+ the document to another document <code>ex:doc2</code> which had probably
+ some kind of influence on <code>ex:doc1</code>.
</p><p>
-Following this pattern, we can generally categorize the existing metadata as
-description metadata and provenance metadata. To be more precise, we define provenance
-metadata as metadata providing provenance information according to the definition of
+Following this pattern, the existing metadata can be categorized as
+description metadata and provenance metadata. To be more precise, provenance
+metadata is defined as metadata providing provenance information according to the definition of
the Provenance Working Group [<a href="#bib-PROV-DEF">PROV-DEF</a>] and description metadata as all other metadata.
</p>
<p>
@@ -680,12 +680,12 @@
This is a conservative classification of provenance metadata. It can be argued that other elements contain
provenance information as well, depending on their usage in a concrete implementation or application.
</p><p>
-According to our classification, there are 25 terms out of 55 that can be considered as provenance related.
+According to the proposed classification, there are 25 terms out of 55 that can be considered as provenance related.
The terms can further be categorized according to the question they answer regarding the provenance of a resource:
</p><p>
<b>Who?</b> (contributor, creator, publisher, rightsHolder): Category that includes all properties that have <code>dct:Agent</code> as range,
i.e., a resource that acts or has the power to act. The contributor, creator, and publisher clearly influence
- the resource and therefore are important for its origin. This is not immediately clear for the rightsHolder,
+ the resource and therefore are important for its origin. This is not immediately clear for the <code>dct:rightsHolder</code>,
but as ownership is considered the important provenance information for many resources, like artworks, it is included in this category.
</p><p>
<b>When?</b> (available, created, date, dateAccepted, dateCopyrighted, dateSubmitted, issued, modified, valid):
@@ -693,11 +693,11 @@
being published or not. Depending on the application, however, the publication can be seen as an action that changes
the state of the resource. Two dates can be considered special regarding their relevance for
provenance: available and valid. They are different from the other dates as by definition they can represent a
- date range. Often, the range of availability or validity of a resource is inhererent to the resource and known
- beforehand – consider the validity of a passport or a credit card or the availability of a limited special offer.
+ date range. Often, the range of availability or validity of a resource is inherent to the resource and known
+ beforehand – consider the validity of a passport or the availability of a limited special offer published on the web.
In these cases, there is no action involved that makes the resource invalid or unavailable, it is simply determined
by the validity range. On the other hand, if an action is involved, e.g., a resource is declared invalid because
- a mistake has been found, this is relevant for its provenance.
+ a mistake has been found, then it is relevant for its provenance.
</p><p>
<b>How?</b> (isVersionOf, hasVersion, isFormatOf, hasFormat, references, isReferencedBy, replaces, isReplacedBy, source, rights, license):
Resources are often derived from other resources. In this case, the original resource becomes part of the provenance
@@ -759,19 +759,19 @@
</table>
</div>
<p>
-This leaves one very special term: <i>provenance</i>. It is defined as a "statement of any changes in ownership and
+This leaves one very special term: <i>provenance</i>. 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" [<a href="#bib-DCTERMS">DC-TERMS</a>],
-which refers to the traditional definition of provenance for artworks. Despite being relevant for provenance,
+which corresponds to the traditional definition of provenance for artworks. Despite being relevant for provenance,
this definition may overlap partially with almost half of the DCMI terms, which
specify concrete aspects of provenance of a resource.
</p><p>
In summary, the DCMI terms – and therefore any Dublin Core metadata record – hold a lot of provenance information and
- tell us about a resource, when it was affected in the past, who affected it and how it was affected.
- The description metadata, i.e., the other DCMI terms, tells us what was affected. There is
- no direct information in Dublin Core describing where a resource was affected. Such information is usually only available for the
- publication of a resource, i.e., this action is located at the address of the publisher. Note that spatial is not related
- to this question, as this is a descriptive property that tells us for instance that a book is about Berlin, but not that
- it was created in Berlin – or even that it has ever been or is otherwise related to Berlin. <!--And finally, the question,
+ tell us 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 other DCMI terms (description metadata), tell us <i>what</i> was affected. There is
+ no direct information in Dublin Core describing <i>where</i> a resource was affected. Such information is usually only available for the
+ publication of a resource (i.e., an action located at the address of the publisher). Note that spatial is not related
+ to this question, as it is a descriptive property that links a resource to the location referred to in its content, but not to the
+ location where it was created, modified, issued or published. <!--– or even that it has ever been or is otherwise related to Berlin. <!--And finally, the question,
why a resource was affected, lacks – apart from subtle hints from terms like replaces – as usual a satisfying answer. -->
</p>
<h3 id ="namespaces">1.1 Namespaces</h3>
@@ -792,15 +792,15 @@
<div id="Mapping" class="section">
<h2>2. 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 view point).
+ 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 huge amount of Dublin Core data that is available on
- the Web today. Third, it can translate PROV data to Dublin Core and therefore make it accessible for applications that
+ the Web today. Third, it can translate PROV data to Dublin Core and make it accessible for applications that
understand Dublin Core. And not least, it can lower the barrier to adopt PROV, as simple Dublin Core statements can be
used as starting point to generate PROV data. </p>
<div id="basic" class="section">
<h3>2.1 Basic considerations </h3>
<p>
-Substantially, a complete mapping from Dublin Core to PROV consists of four parts:
+Substantially, a complete mapping from Dublin Core to PROV consists of three parts:
</p><p>
1) <b>Direct mappings</b> between terms that can be expressed in form of subclass or subproperty relationships in RDFS
– or equivalent relationships in OWL.
@@ -828,13 +828,13 @@
<p>
</div>
<div id="entities_in_dc" class="section">
-<h3><span class="secno">2.2 </span>What is ex:document1? Entities in Dublin Core</h3>
+<h3><span class="secno">2.2 </span>What is ex:doc1? Entities in Dublin Core</h3>
<p>
-Consider the example metadata record shown at the beggining of the document (<a href="#example1">example 1)</a>. As a <code>dc</code>
+Consider the example metadata record shown at the beginning of this document (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 can have assigned 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 beffore it was issued
+ 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>
</p><p>
@@ -850,10 +850,10 @@
</div>
</div>
</p><p>
- 2) Use the original document as the instance used as <code>prov:Entity</code>. However, to have an activity that uses
- an entity and generates the same entity is not compliant with the prov constraints [<a href="#bib-Constraints">PROV-CONTRAINTS</a>.]
- Also, if an activity actually generates an entity,
- it is semantically incorrect to have several activities that generate the same entity at different points in time.
+ 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 [<a href="#bib-Constraints">PROV-CONTRAINTS</a>]. <a href="#figure_mapping_example_conflating">Figure 2</a>
+ provides an example that illustrates this approach.
<!--<b>This has to be investigated and discussed further. For references, see PROV-DM Generation, PROV-DM Derivation,
PROV-O Activity</b>.
Removed this from the text above: The implications regarding
@@ -863,11 +863,11 @@
<div id = "figure_mapping_example_conflating" class="figure" style="text-align: center;">
<img src="img/mapping-example - conflating.png"></img>
<div style="text-align: center;">
- <a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes in the same resource. The used and generated resource have the same identifier.
+ <a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes in the same resource. The used and generated resources have the same identifier.
</div>
</div>
</p><p>
-As the first option is the most conservative with respect to the underlying semantics, it has been chosen as guideline in the context-free mapping.
+Since the first option is the most conservative with respect to the underlying semantics, it has been chosen as guideline in the context-free 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.
<!-- I comment this because it repeats what it has already been stated
@@ -876,12 +876,12 @@
How do we reduce the number of specializations, e.g., by stating that the specialization that is generated by activity
1 is the same entity that is used by activity 2?
</p><p>
- How do we relate the specializations to <code>ex:document1</code>? We could create two entities based on the actual creation activity:
- <code>ex:document1</code> and a first specialization. We could further declare the last produced specialization as the same entity as <code>ex:document1</code>.
+ How do we relate the specializations to <code>ex:doc1</code>? We could create two entities based on the actual creation activity:
+ <code>ex:doc1</code> and a first specialization. We could further declare the last produced specialization as the same entity as <code>ex:doc1</code>.
Depending on the underlying data, this can be the entity that is identified by the URI of the original document. However,
we have to be careful to avoid cycles in the provenance we produce. For now, this remains undecided.
+-->
</p>
--->
</div>
<div id="mappings" class="section">
<h3><span class="secno">2.3 </span>Direct mappings</h3>
@@ -914,7 +914,7 @@
<td><b>dct:Agent</b></td>
<td>owl:equivalentClass</td>
<td> prov:Agent.</td>
- <td>Both <code>dct:Agent</code> and <code>prov:Agent</code> refer to the same concept: a resource that has the power to act (which then has responsability for an activity)</td>
+ <td>Both <code>dct:Agent</code> and <code>prov:Agent</code> refer to the same concept: a resource that has the power to act (which then has responsibility for an activity).</td>
</tr>
<tr>
<td><b>dct:rightsHolder</b></td>
@@ -933,13 +933,13 @@
<td><b>dct:publisher</b></td>
<td>rdfs:subPropertyOf</td>
<td>prov:wasAttributedTo</td>
- <td>A publisher has the attribution of the publishing activity that led to the published resource</td>
+ <td>A publisher has the attribution of the publishing activity that led to the published resource.</td>
</tr>
<tr>
<td><b>dct:contributor</b></td>
<td>rdfs:subPropertyOf</td>
<td>prov:wasAttributedTo</td>
- <td>A contributor is involved either in the creation activity or in the updating of the resource. Therefore he is attributed to take
+ <td>A contributor is involved either in the creation activity or in the updating of the resource. Therefore he/she is attributed to take
part in those activities.</td>
</tr>
<tr>
@@ -953,7 +953,7 @@
<td><b>dct:isFormatOf</b></td>
<td>rdfs:subPropertyOf</td>
<td>prov:alternateOf</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>dct:hasFormat</b></td>
@@ -1028,10 +1028,10 @@
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 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
proposes to separate all of them. Thus, the mapping would produce provenance that would comply with the current definition of entity but
-it would not comply with all the PROV consraints [<a href="#bib-Constraints">PROV_CONSTRAINTS]</a>.
+it would not comply with all the PROV constraints [<a href="#bib-Constraints">PROV_CONSTRAINTS]</a>.
</p>
<p>
-Some properties have been found to be superproperties of certain prov concepts. The summary can be seen below in <a href="#list_of_direct_mappings2">Table 4</a>
+Some properties have been found to be superproperties of certain prov concepts. The summary 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"
-->
@@ -1051,8 +1051,9 @@
<td>prov:hadPrimarySource</td>
<td>rdfs:subPropertyOf</td>
<td><b>dct:source</b></td>
- <td>It is surprising to see that some terms of Dublin Core are more general than the ones defined in PROV. However the definition of <code>prov:hadPrimarySource</code>
- ("something produced by some agent with direct experience and knowledge about the topic") is more restrictive than <code>dct:source</code> ( "A related resource from which the described resource is derived").</td>
+ <td>The definition of <code>prov:hadPrimarySource</code> ("something produced by some agent with direct experience
+ and knowledge about the topic") is more restrictive than <code>dct:source</code> ( "A related resource from which the
+ described resource is derived").</td>
</tr>
<tr>
<td>prov:wasRevisionOf</td>
@@ -1142,19 +1143,20 @@
<div id="entity_agent_mappings">
<h4><span class="secno">2.5.1 </span>Entity-Agent mappings (Who)</h4>
<p>
-In this category, we have four terms: contributor, creator, publisher, and rightsHolder. The former three
+In this category, we have four terms: <code>dct:contributor</code>, <code>dct:creator</code>, <code>dct:publisher</code>, and <code>dct:rightsHolder</code>.
+The former three
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>
- In the text below, variables ?document and ?agent are set to different matching values depending
+ In the text below, variables <code>?document</code> and <code>?agent</code> are set to different matching values depending
on the data found in the triple store. 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
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.
+ <!--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.
@@ -1170,12 +1172,12 @@
?agent a prov:Agent .
- _:activity a prov:Activity, dcprov:CreationActivity ;
+ _:activity a prov:Activity, prov:CreationActivity ;
prov:wasAssociatedWith ?agent;
prov:qualifiedAssociation [
a prov:Association;
prov:agent ?agent;
- prov:hadRole dcprov:CreatorRole .
+ prov:hadRole prov:CreatorRole .
].
_:resulting_entity a prov:Entity ;
@@ -1269,7 +1271,7 @@
</p>
<p>
When using Dublin Core terms, it is usual to see that a resource is annotated with several dc assertions like creator, publisher,
- issued, date, etc. In this phase of the mapping each term is trated independently.
+ issued, date, etc. In this phase of the mapping each term is treated independently.
</p>
<h5 id="term_created"><span class="secno">2.5.2.1 </span>dct:created</h5>
</p><p><pre class="code">
@@ -1528,16 +1530,16 @@
<div id="cleanup" class="section">
<h3><span class="secno">2.5.3 </span>Cleanup</h3>
<p>
-The clean-up phase depends on how implementors interpret the described resources. The approach presented in this document
+The clean-up phase depends on how implementers interpret the described resources. The approach presented in this document
is conservative and it leads to the proliferation of blank nodes. Blank nodes could be renamed to specific identifiers
- by the implementor, in order to avoid obtaining additional blank nodes when reapplying the construct queries presented
+ 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 implementors 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, we could group
- some of the records and create more complete PROV assertions.</p>
- <p>The example below shows how a modification to the previous pattern would conflate the blank nodes for <code>dct:creator</code> and <code>dct:created</code> properties:
+ created a list of 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{
?document a prov:Entity .
@@ -1570,7 +1572,7 @@
<div id = "figure_cleanup1" class="figure" style="text-align: center;">
<img src="img/cleanup1.png"></img>
<div style="text-align: center;">
- <a href="#figure_mapping_example">Figure 3</a>. Gathering complementing properties to conflate blank nodes.
+ <a href="#figure_cleanup1">Figure 3</a>. Gathering complementing properties to conflate blank nodes.
</div>
</div>
@@ -1578,18 +1580,18 @@
<p>2) Another solution is to <b>sort all the activities according to their date</b>, if known, and conflate the blank
nodes result of one activity and 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. Instead of creating different blank nodes for the respective usage and generation, both activities shared the same
-blank node (_:created_entity).
+points in time. Instead of creating different blank nodes for the respective usage and generation, both activities share the same
+blank node (<code>_:created_entity</code>).
<div id = "figure_cleanup2" class="figure" style="text-align: center;">
<img src="img/cleanup2.png"></img>
<div style="text-align: center;">
- <a href="#figure_mapping_example">Figure 4</a>. Sorting the activities by date to conflate blank nodes.
+ <a href="#figure_cleanup2">Figure 4</a>. Sorting the activities by date to conflate blank nodes.
</div>
</div>
</p>
-<p>3) Finally, another solution is to <b>ignore all the specializations of ex:document1 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 publisher and creator), since most of the
+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>
@@ -1613,15 +1615,15 @@
</tr><tr>
<td><b id="term_accrualMethod">dct:accrualMethod</b></td>
<td>Descriptive Metadata</td>
- <td>Method by which items are added to a collection. It doesn't describe the action itslef, so we decided to leave this term out of the mpping</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>
</tr><tr>
<td><b id="term_accrualPeriodicity">dct:accrualPeriodicity</b></td>
<td>Descriptive metadata</td>
- <td>Frequency of the items added to a collection.</td>
+ <td>Frequency of the addition of items to a collection.</td>
</tr><tr>
<td><b id="term_accrualPolicy">dct:accrualPolicy</b></td>
<td>Descriptive metadata</td>
- <td>Policy associated with the insertion of items to a collection. We could use it to enrich the qualified
+ <td>Policy associated with the insertion of items to a collection. It could be used to enrich the qualified
involvement, but there is no direct mapping of this relationship.</td>
</tr><tr>
<td><b id="term_alternative">dct:alternative</b></td>
@@ -1654,7 +1656,7 @@
</tr><tr>
<td><b id="term_format">dct:format</b></td>
<td>Descriptive metadata</td>
- <td>Format of the resource. Descriptive metadata.</td>
+ <td>Format of the resource. </td>
</tr><tr>
<td><b id="term_identifier">dct:identifier</b></td>
<td>Descriptive metadata</td>
@@ -1666,7 +1668,7 @@
</tr><tr>
<td><b id="term_isPartOf">dct:isPartOf</b></td>
<td>Descriptive metadata</td>
- <td>Inverse of hasPart.</td>
+ <td>Inverse of <code>dct:hasPart</code>.</td>
</tr><tr>
<td><b id="term_isRequiredBy">dct:isRequiredBy</b></td>
<td>Descriptive metadata</td>
@@ -1688,16 +1690,16 @@
</tr><tr>
<td><b id="term_requires">dct:requires</b></td>
<td>Descriptive metadata</td>
- <td>Inverse property of isRequiredBy (see isRequiredBy).</td>
+ <td>Inverse property of <code>dct:isRequiredBy</code> (see <code>dct:isRequiredBy</code>).</td>
</tr><tr>
<td><b id="term_hasPart">dct:hasPart</b></td>
<td>Descriptive metadata</td>
- <td>A resource that is included in the current resource. Entity composition is out of the scope of DM, so
- we leave it out of the mapping list as well</td>
+ <td>A resource that is included in the current resource. Since entity composition is out of the scope of PROV,
+ this property has been excluded from the mapping</td>
</tr><tr>
<td><b id="term_spatial">dct:spatial</b></td>
<td>Descriptive metadata</td>
- <td>Spatial characteristics of the content of the resource resource (e.g., the book is about Spain). Thus it can't be mapped to <code>prov:hadLocation</code>.</td>
+ <td>Spatial characteristics of the content of the resource (e.g., the book is about Spain). Thus it can't be mapped to <code>prov:hadLocation</code>.</td>
</tr><tr>
<td><b id="term_subject">dct:subject</b></td>
<td>Descriptive metadata</td>
@@ -1721,27 +1723,27 @@
</tr><tr>
<td><b id="term_bibliographicCitation">dct:bibliographicCitation</b></td>
<td>Descriptive metadata</td>
- <td>Property that relates the Literal representing the bibliographic citation of the resource to the
+ <td>Property that relates the literal representing the bibliographic citation of the resource to the
actual resource (e.g., <code>:el_Quijote dct:bibliographicCitation "Miguel de Cervantes Saavedra: El Quijote, España"</code>).</td>
</tr><tr>
<td id="term_references"><b>dct:references</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. Since we could not reach consensus on how
- to map it to prov, we have left it out of the mapping</td>
+ 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>
</tr><tr>
<td id="term_isReferencedBy"><b>dct:isRefrencedBy</b></td>
<td> Provenance: How </td>
- <td>Inverse to dct:references.</td>
+ <td>Inverse to <code>dct:references</code>.</td>
</tr><tr>
<td><b id="term_accessRights">dct:accessRights</b></td>
<td>Provenance: How</td>
- <td>Who can access the resource (security status). Since the privileges of the resource are part of the
- description of the resource, it’s not included in the list.</td>
+ <td>Agents who can access the resource (security status). Since the privileges of the resource are part of the
+ description of the resource, the property has been excluded from the mapping.</td>
</tr><tr>
<td><b id="term_license">dct:license</b></td>
<td>Provenance: How</td>
- <td>License of the resource. It has been left out of the list because there is no term in PROV-O to map to.</td>
+ <td>License of the resource. It has been left out of the mapping because there is no term in PROV-O to represent this information.</td>
</tr><tr>
<td><b id="term_rights">dct:rights</b></td>
<td>Provenance: How</td>
@@ -1749,30 +1751,30 @@
</tr><tr>
<td><b id="term_date">dct:date</b></td>
<td>Provenance: When</td>
- <td>Date is a very general property. It is the superproperty which all the other specialize. We have decided to leave it with no mapping</td>
+ <td>Date is a very general property. It is the superproperty which all the other specialize, but there is no equivalent concept in PROV. It has been excluded from the mapping</td>
</tr><tr>
<td><b id="term_available">dct:available</b></td>
<td>Provenance: When</td>
- <td>Property that states when a resource is available. We couldn't find consensus on how to map this property, so it was dropped.</td>
+ <td>Property that states when a resource is available. The group could not reach consensus on how to map this property, so it was finally dropped from the mapping.</td>
</tr><tr>
<td><b id="term_valid">dct:valid</b></td>
<td>Provenance: When</td>
- <td>Property that states when a resource is valid. We have the notion of invalidation in PROV-O, but not the notion of validation. Thus we leave this property out of the mapping</td>
+ <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><tr>
<td><b id="term_relation">dct:relation</b></td>
<td>Provenance </td>
<td>A related resource. This relationship is very broad and could relate either provenance resources or not.
- It could be seen as a superproperty of wasDerivedFrom, wasInfluencedBy, alternateOf, specializationOf, 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. Thus there is no direct mapping.<td>
</tr>
</tbody></table>
</p>
<div id="prov_to_dc" class="section">
<h2><span class="secno">3. </span>Mapping from PROV to DC</h2>
<p>
-The mapping from PROV to DC is not part of this note.
+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 and more or less the inverse of the
- mapping patterns that we used. However, without such refinements, almost no DC statements can be inferred,
+ If refinements are used, the mapping would be straight forward using the inverse of the
+ mapping patterns that we used. However, without such refinements, few Dublin Core statements can be inferred,
besides 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>
@@ -1783,7 +1785,7 @@
<!-- OddPage -->
<h2><span class="secno">A. </span>Acknowledgements</h2>
<p>
- We would like to thank Antoine Isaac, Timothy Lebo, Simon Miles, Satya Sahoo and Ivan Herman for their feedback.
+ We would like to thank Antoine Isaac, Ivan Herman, Timothy Lebo, Simon Miles and Satya Sahoo for their feedback.
</p>
</div>