--- a/dc-note/Overview.html Wed Sep 26 11:33:57 2012 +0100
+++ b/dc-note/Overview.html Thu Sep 27 02:56:55 2012 +0200
@@ -628,13 +628,14 @@
<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
+ the element set. The 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
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. Both have different namespaces,
-usually the elements are used with the <span class="repeated">dc</span>, the terms with <span class="repeated">dct</span> or <span class="repeated">dcterms</span>.
+The Dublin Core elements are considered legacy and the use of the DCMI terms is preferred. They have different namespaces;
+ if abbreviated, the elements are usually used with the <code>dc</code> prefix, while <code>dct</code> or <code>dcterms</code>
+ prefix is used for the terms.
Consider the following example for a metadata record:
<pre class="example" id="example1">
@@ -661,7 +662,7 @@
This is a pattern that applies generally to metadata, i.e., we can distinguish
description metadata and provenance metadata. To be more precise, we define provenance
metadata 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.
+the Provenance Working Group [<a href="#bib-PROV-DEF">PROV-DEF</a>] and description metadata as all other metadata.
</p>
<p>
Based on this definition, the DCMI terms can be classified as follows:
@@ -673,17 +674,17 @@
medium, relation, requires, spatial, subject, tableOfContents, temporal, title, type.
</p>
<p>
-<b>Provenance metadata </b>: available, contributor, created, creator, date, dateAccepted, dateCopyrighted,
+<b>Provenance metadata</b>: available, contributor, created, creator, date, dateAccepted, dateCopyrighted,
dateSubmitted, hasFormat, hasVersion, isFormatOf, isReferencedBy, isReplacedBy, issued, isVersionOf, license, modified,
provenance, publisher, references, replaces, rightsHolder, rights, source, valid.
</p><p>
This classification can certainly be questioned and was already subject to many discussions. We use a very
conservative strategy: if the group can't reach consensus about if an element should be mapped to PROV or not,
- we exclude it from tha mapping list. This way, we want to ensure that rather less, but correct provenance
+ we exclude it from the mapping list. This way, we want to ensure that rather less, but correct provenance
data is created than more, but possibly incorrect data.
</p><p>
According to our classification, there are 25 terms out of 55 that can be considered as provenance related.
- Based on their different aspects of provenance, we discuss them below:
+ As a next step, we consider sub-categories of the provenance related terms as follows:
</p><p>
<b>Who?</b> (contributor, creator, publisher, rightsHolder) Category that includes all properties that have the range dct:Agent,
i.e., a resource that acts or has the power to act. The contributor, creator, and publisher clearly influence
@@ -764,7 +765,7 @@
This leaves one very special term: <i>provenance</i>. It 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 from the
-W3C Provenance Incubator Group's persepctive, this definition it may overlap partially with almost half of the DCMI terms, which
+W3C Provenance Incubator Group's persepctive, 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
@@ -821,7 +822,7 @@
For the context-free mapping, first, only single DC statements are mapped to PROV. Relations between several statements affecting the resulting
PROV statements are not yet taken into account. The input and output of all activities are identified as separate specializations of
the original resource mentioned in the DC statement. A specialization in PROV identifies a state of a resource during its lifetime that
- is partt of the provenance chain. However, if a specialization of a document is generated by one activity and a specialization is used by
+ is part of the provenance chain. However, if a specialization of a document is generated by one activity and a specialization is used by
a different activity later in time, it can be assumed that both are the same entities, if the second activity directly follows the first
activity. These conflations and other clean-up steps are performed separately, as there are several possibilities to perform them.
</p><p>
@@ -834,18 +835,18 @@
<h3><span class="secno">2.2 </span>What is ex:document1? Entities in Dublin Core</h3>
<p>
Consider the example metadata record above (<a href="#example1">example 1)</a>. As a DC 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.
+ 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 dct:created date and a dct:issued date. The activity of issuing a document
does not necessarily change the document, but regarding the PROV ontology, there are two different specializations of
this document before and after the issuing activity, distinguishable by the property of the document that states if
the document was issued. Generally, there are two possibilities to deal with this issue:</p>
</p><p>
- 1): We can always create new instances of entities, typically as blank nodes, that all are related to the original
+ 1) We can always create new instances of entities, typically as blank nodes, that all are related to the original
document by means of prov:specializationOf. This leads to bloated and not very intuitive data models, e.g. think
about the translation of a single dct:creator statement, where you 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>).
</p><p>
- 2): We can always use the original document as the instance that is used as prov:Entity. The implications regarding
+ 2) We can always use the original document as the instance that is used as prov:Entity. The implications regarding
the semantics of a prov:Activity are not yet totally clear, however, it contradicts the above mentioned definition
to have an activity that uses an entity and generates the same entity. If an activity actually generates an entity,
it is semantically incorrect to have several activities that all generate the same entity at different points in time.
@@ -886,7 +887,7 @@
</p>
<p>
<a href="#list_of_direct_terms">Table 3</a> and <a href="#list_of_direct_mappings2">Table 4</a> provide the detailed mapping plus the rationale for each term.
- Those mappings in which the group could not find consensus have been dropped. For more information see the
+ Those mappings for which the group could not find consensus have been dropped. For more information see the
<a href="#list_of_excluded_terms">list of terms left out of the mapping</a>.
</p><p>
<div id="list_of_direct_terms" ALIGN="center">
@@ -935,7 +936,7 @@
<td><b>dct:isVersionOf</b></td>
<td>rdfs:subPropertyOf</td>
<td>prov:wasDerivedFrom</td>
- <td>dct:isVersion of refers to "a related resource to which the current resource is a version, edition or adaptation". Hence we can
+ <td>dct:isVersionOf refers to "a related resource to which the current resource is a version, edition or adaptation". Hence we can
conclude that the current resource has been derived from the original one.</td>
</tr>
<tr>
@@ -948,13 +949,13 @@
<td><b>dct:isFormatOf</b></td>
<td>rdfs:subPropertyOf</td>
<td>prov:alternateOf</td>
- <td>dct.isFormatOf refers to another resource which is the same but in another format. Thus the mapping is straightforward to prov:alternateOf</td>
+ <td>dct:isFormatOf refers to another resource which is the same but in another format. Thus the mapping is straightforward to prov:alternateOf</td>
</tr>
<tr>
<td><b>dct:hasFormat</b></td>
<td>rdfs:subPropertyOf</td>
<td>prov:alternateOf</td>
- <td> See rationale for dct:hasFormat</td>
+ <td> See rationale for dct:isFormatOf</td>
</tr>
<tr>
<td><b>dct:replaces</b></td>