--- a/dc-note/releases/NOTE-prov-dc-20130430/Overview.html Thu Apr 18 03:41:04 2013 +0200
+++ b/dc-note/releases/NOTE-prov-dc-20130430/Overview.html Thu Apr 18 10:14:19 2013 +0200
@@ -460,9 +460,9 @@
<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
+ <li>Help developers to <b>derive PROV data from the large amount of DC 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>
+ <li><b>Facilitate PROV adoption</b>. Simple DC statements can be used as a starting point for more complex PROV data generation.</li>
</ol>
<p></p>
@@ -493,7 +493,7 @@
<a href="#preliminaries">Section 2</a> explains the main considerations to take into account in order to fully understand the mapping:
</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>
+ <li>How entities are defined in DC, along with several examples (<a href="#entities-in-dublin-core">Section 2.2</a>).</li>
</ul>
<p></p>
<p>
@@ -531,7 +531,7 @@
This section explains two main particular considerations that should be taken into account regarding the mapping:
</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>
+ <li><a href="#entities-in-dublin-core">Section 2.2</a>: The definition of entities in DC.</li>
</ul>
<p></p>
<section id="provenance-in-dublin-core">
@@ -542,12 +542,12 @@
<a href="#categories">Table 2</a> classifies the DC Terms according to these four categories (<i>what?</i>, <i>who?</i>, <i>when?</i> and <i>how?</i>).
Each category corresponds to the question it answers regarding the description or provenance of a given resource.
The classification is by necessity somewhat minimalistic, as it can be argued that some elements placed in the description metadata terms contain
- provenance information as well, depending on their usage. It is worth mentioning that there is no direct information in Dublin Core describing
+ provenance information as well, depending on their usage. It is worth mentioning that there is no direct information in DC describing
<i>where</i> a resource was affected. The categories are further explained below:
</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 referring to its provenance (a total of 30 out of 55 terms).
+ <b> Descriptive Terms (What?):</b> This category contains all the terms describing a resource without referring to its provenance (a total of 25 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>
@@ -579,7 +579,7 @@
<p>
<b>Derivation Terms (How?):</b> This category contains derivation related terms.
When a resource is derived from other resources, the original resource becomes part of the provenance
- chain of the derived resource. In Dublin Core, derivations can be further classified as versions (<code>dct:isVersionOf</code>),
+ chain of the derived resource. In DC, derivations can be further classified as versions (<code>dct:isVersionOf</code>),
format serializations (<code>dct:isFormatOf</code>), replacements (<code>dct:replaces</code>) and sources of information (<code>dct:source</code>).
<code>dct:references</code> is a weaker relation (having a reference to a resource does not always mean that the content is based on it),
but it can be assumed that a referenced resource influenced the described resource
@@ -591,7 +591,7 @@
</p>
<div id="categories" >
<table style="margin-left: auto; margin-right: auto;">
- <caption> <a href="#categories"> Table 2:</a> Categorization of the Dublin Core Terms </caption>
+ <caption> <a href="#categories"> Table 2:</a> Categorization of the DC Terms </caption>
<tbody>
<tr>
<th>Category</th>
@@ -732,14 +732,14 @@
<section id="mapping-from-dublin-core-to-prov">
<!--OddPage--><h2><span class="secno">3. </span>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:
+ This section describes the mapping between DC and PROV. The mapping is divided in several subsections:
</p><ul>
- <li> <a href="#direct-mappings">Section 3.1</a>: Direct mappings between Dublin Core and PROV.</li>
+ <li> <a href="#direct-mappings">Section 3.1</a>: Direct mappings between DC 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>
+ <li> <a href="#complex-mappings">Section 3.3</a>: Complex mappings between DC and PROV (inferring activities using blank nodes).</li>
<li> <a href="#cleanup">Section 3.4</a>: Strategies for cleaning up some of the blank nodes produced by the approach presented in <a href="#complex-mappings">Section 3.3</a>.</li>
<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>
+ <li> <a href="#mapping-from-prov-to-dc">Section 3.6</a>: Mapping PROV to DC (out of the scope of this mapping).</li>
</ul>
<p></p>
<section id="direct-mappings">
@@ -749,7 +749,7 @@
PROV applications will be able to interoperate with these DC statements by applying means of OWL 2 RL reasoning, (i.e.,
they will be able to understand DC statements). <!--The direct mappings also
contribute to the formal definition of the vocabularies by translating them to PROV.--></p>
- <p>Dublin Core, while less complex from a modeling perspective,
+ <p>DC, while less complex from a modeling perspective,
is more specific about the type of the activity taking place. PROV provides general attribution, and
the details about the kind of influence that an activity or an agent had are left to custom refinements of the PROV classes and properties.
</p>
@@ -997,14 +997,14 @@
It is worth mentioning that applying the direct mappings to a metadata record such as <a href="#example1">example 1</a> will infer that
the resource (<code>ex:doc1</code>) was <code>prov:generatedAtTime</code> at two different times (two generation dates are associated to the document:
<code>dct:created</code> and <code>dct:issued</code>). This is valid, since from the PROV
- point of view the "creation" and "issue" activities generate new entities. Dublin Core, on the other hand, groups those two intermediate entities under the same resource (<code>ex:doc1</code>), creating the record exposed
+ point of view the "creation" and "issue" activities generate new entities. DC, on the other hand, groups those two intermediate entities under the same resource (<code>ex:doc1</code>), creating the record exposed
in <a href="#example1">Example 1</a>. This approach is supported by PROV but it does not comply with all the PROV
constraints [<cite><a href="#bib-PROV-CONSTRAINTS" class="bibref">PROV-CONSTRAINTS</a></cite>].
<p></p>
<p>
Regarding the rest of the direct mappings, a property (<code>prov:hadPrimarySource</code>) has been found to be superproperty of a PROV concept, represented in <a href="#list_of_direct_mappings2">Table 4</a>:
<!-- SHOULD ADD THIS FOR EACH
- it is due to the difference between Dublin Core and PROV entities: while the former conflates more than one version or "state" of
+ it is due to the difference between DC and PROV entities: 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
<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"
-->
@@ -1093,7 +1093,7 @@
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:
+ The PROV extensions for DC can be seen below:
</p><pre class="code">
prov:Publish rdfs:subClassOf prov:Activity .
prov:Contribute rdfs:subClassOf prov:Activity .
@@ -1117,7 +1117,7 @@
<section id="complex-mappings">
<h3><span class="secno">3.3 </span>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
+ The complex mappings consist of a set of patterns defined to generate qualified PROV statements from DC 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
@@ -1138,7 +1138,7 @@
for creator and rightsHolder). With this mapping,
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.-->
+ <!--Sometimes URIs for the specializations are also available and simply not exposed to the DC 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.
@@ -1269,7 +1269,7 @@
<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,
+ When using DC 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 DC date properties is
<code>rdfs:Literal</code>, and the range of the <code>prov:atTime</code> property is the class
@@ -1467,7 +1467,7 @@
<section id="entity-entity-mappings-how">
<h4><span class="secno">3.3.3 </span>Entity-Entity mappings (How)</h4>
<p>
- In Dublin Core, most of the properties relating entities to other entities do not imply activities related to provenance
+ In DC, 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.
@@ -1520,7 +1520,7 @@
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 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.,
+ <p>1) <b>Conflate properties referring to the same state of the resource</b>: In DC 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:
@@ -1795,11 +1795,11 @@
<section id="mapping-from-prov-to-dc">
<h3><span class="secno">3.6 </span>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
+ The mapping from PROV to DC 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.
+ However, if the refinements are not used then only a few DC statements can be inferred from plain PROV statements.
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 activity. Likewise, the agents
- involved cannot be mapped to creators, contributors, or publishers. While Dublin Core includes provenance information, its focus
+ involved cannot be mapped to creators, contributors, or publishers. While DC includes provenance information, its focus
lies on the broader description of resources. PROV models a provenance chain, but it provides almost no information about the involved
resources themselves.
</p>