Mora changes in dc note
authordgarijo
Wed, 20 Feb 2013 01:03:57 +0100
changeset 5608 dc96e81218ce
parent 5593 e481d4d7b1d9
child 5609 f54da97726a4
Mora changes in dc note
dc-note/dc-note.html
dc-note/files/prov-dc-directmappings.ttl
dc-note/img/example1.png
dc-note/img/mapping-example - conflating.png
--- a/dc-note/dc-note.html	Tue Feb 19 16:27:16 2013 +0100
+++ b/dc-note/dc-note.html	Wed Feb 20 01:03:57 2013 +0100
@@ -570,7 +570,7 @@
 	<li> <a href="http://www.w3.org/TR/2013/WD-prov-links-20130312/">PROV-LINKS</a> (To be published as Note) introduces a mechanism to link across bundles [[PROV-LINKS]].</li>
 	</ul>
 
-	<h4>W3C Members Please Review By 09 April 2013</h4>
+<!--	<h4>W3C Members Please Review By 09 April 2013</h4>
 
 	<p>The W3C Director seeks review and feedback from W3C Advisory Committee representatives, via their <a href="http://form-tbd/">review form</a> by 09 April 2013. This will allow the Director to assess consensus and determine whether to issue this document as a W3C Recommendation.</p>
 
@@ -580,7 +580,7 @@
 			  <a href="http://lists.w3.org/Archives/Public/public-prov-comments/">archives</a>). Open discussion among developers is also welcome at
 	<a href="mailto:[email protected]">[email protected]</a> 
 			  (<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
-			  <a href="http://lists.w3.org/Archives/Public/public-prov-comments/">archives</a>).</p>
+			  <a href="http://lists.w3.org/Archives/Public/public-prov-comments/">archives</a>).</p>-->
  </section>  
 
  <section>
@@ -654,7 +654,7 @@
 	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. 
+			– or equivalent relationships in OWL, and can be used to infer 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.
@@ -712,7 +712,7 @@
 	 but as ownership is considered the important provenance information for many resources, like artworks, it is included in this category.
 	</p>
 	<p>
-	<b>Date and Time Terms (When?):</b>This category contains date and time related terms.
+	<b>Date and Time Terms (When?):</b> This category contains date and time related terms.
 	 Dates belong to the provenance record of a resource, as they track when something was created (<code>dct:created</code>), modified 
 	 (<code>dct:modified</code>), published (<code>dct:issued</code>), etc. Two dates can be considered special regarding their relevance for
 	 provenance: <code>dct:available</code> and <code>dct:valid</code>. They are different from the other dates as by definition they can represent a
@@ -835,8 +835,8 @@
 		 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
 		 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 <code>prov:specialization</code> of the document, even if the document
-		 has not changed. Generally, there are two approaches to deal with this issue:</p>
+		 and the issued document. Each of these states correspond to a different <code>prov:specialization</code> of the document. 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
@@ -848,7 +848,7 @@
 			resource has not suffered any further modifications, <code>:_resultingEntity</code> is also a <code>prov:specializationOf</code> the resource
 			<code>ex:doc1</code>.
 		</p><p>
-			<div id = "figure_mapping_example" class="figure" style="text-align: center;">
+			<div id = "figure_mapping_example" style="text-align: center;">
 			<img src="img/example1.png"></img>
 			<div style="text-align: center;">
 			<a href="#figure_mapping_example">Figure 1</a>. A mapping example creating blank nodes for each state of the resource. PROV entities are represented
@@ -864,10 +864,10 @@
 			<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;">
+			<div id = "figure_mapping_example_conflating" 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. 
+			<a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes within the same resource. 
 			The used and generated resources have the same identifier.	This example is an <b>invalid translation</b> of the <code>dct:publisher</code> 
 			statement (as it implies that <code>ex:doc1</code> was generated by <code>_:activity</code> and then used by the same activity).
 			</div>
@@ -961,7 +961,7 @@
 				<td>owl:equivalentProperty</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasRevisionOf</a></td>
 				<td><code>dct:isVersionOf</code> refers to "a related resource to which the current resource is a version, edition or adaptation". 
-				In PROV, a revision is "is a derivation for which the resulting entity is a revised version of some original". No specific attributes about revision
+				In PROV, a revision is "a derivation for which the resulting entity is a revised version of some original". No specific attributes about revision
 				are provided, so editions and adaptations can be considered revisions as well.</td>
 			</tr>	
 			<tr>
@@ -1001,61 +1001,64 @@
 				<td><b id="term_created"><a href="http://purl.org/dc/terms/created">dct:created</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
-				<td><code>dct:created</code> is a property used to describe the time of creation of an entity, which corresponds to the time of its generation. 
-				The rationale to map this property as a subclass of <code>prov:generatedAtTime</code>
- is that resources in Dublin Core may have  
-				many dates associated to them (creation, modification, issue, etc.),
- each of which could correspond to a different version of the document. 
-				In this case, the creation is the first date asserted to the 
-document, but doesn't necessarily correspond to the current version of 
-the resource.</td>
+				<td>Property used to describe the time of creation of a resource  (i.e., the time of its generation).
+				We map it as a subproperty because creation is one of the many ways in which an entity could have been generated (for example, generation includes
+				modification, issue, acceptance, etc.)
+				<!--The rationale for this mapping is that in Dublin Core resources may have associated different dates concerning several versions of themselves 
+				within the same identifier (creation, modification, issue, etc.). --></td>
+				<!-- In this case, the creation is the first date asserted to the 
+				document, but doesn't necessarily correspond to the current version of the resource.-->
 			</tr>
 			<tr>
 				<td><b id="term_issued"><a href="http://purl.org/dc/terms/issued">dct:issued</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
-				<td>Property used to describe the date when the resource was issued. <code>dct:issued</code> is mapped as a subproperty of <code>prov:generatedAtTime</code> because the issued resource is an entity itself,
-				which has been generated at a certain time.</td>
+				<td>Property used to describe the date when the resource was issued. <code>dct:issued</code> is mapped as a subproperty of <code>prov:generatedAtTime</code> 
+				because the issued resource is an entity itself, which has been generated at a certain time.</td>
 			</tr>
 			<tr>
 				<td><b id="term_dateAccepted"><a href="http://purl.org/dc/terms/dateAccepted">dct:dateAccepted</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
-				<td>The rationale is similar to the previous two properties: the 
-version of the resource which was accepted could be different from the 
-created or issued one.</td>
+				<td>Property used to describe the date when the resource was accepted. <code>dct:dateAccepted</code> is mapped as a subproperty of <code>prov:generatedAtTime</code> 
+				because the accepted resource was generated by an "Accept" activity which may have changed it from its previous state.</td>
 			</tr>
 			<tr>
 				<td><b id="term_dateCopyrighted"><a href="http://purl.org/dc/terms/dateCopyRighted">dct:dateCopyrighted</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
-				<td>See <code>dct:dateAccepted</code></td>
+				<td>Property used to describe the date when the resource was copy righted. <code>dct:dateCopyrighted</code> is mapped as a subproperty of <code>prov:generatedAtTime</code> 
+				because the copyrighted resource was generated by a "CopyRight" activity which may have changed it from its previous state.</td>
 			</tr>
 			<tr>
 				<td><b id="term_dateSubmitted"><a href="http://purl.org/dc/terms/dateSubmitted">dct:dateSubmitted</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
-				<td>See <code>dct:dateAccepted</code></td>
+				<td>Property used to describe the date when the resource was submitted. <code>dct:dateSubmitted</code> is mapped as a subproperty of <code>prov:generatedAtTime</code> 
+				because the submitted resource was generated by a "Submit" activity which may have changed it from its previous state.</td>
 			</tr>
 			<tr>
 				<td><b id="term_modified"><a href="http://purl.org/dc/terms/modified">dct:modified</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
-				<td>See <code>dct:dateAccepted</code></td>
+				<td>Property used to describe the date when the resource was modified. <code>dct:modified</code> is mapped as a subproperty of <code>prov:generatedAtTime</code> 
+				because the modified resource was generated by a "Modify" activity that changed it from its previous state.</td>
 			</tr>
 			</tbody>
 		</table>
 		</div>
 		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 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 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. Thus, the mapping produces provenance that complies with the 
-		current definition of entity but it does not comply with all the PROV 
+		the resource (<code>ex:doc1</code>) was <code>prov:generatedAtTime</code> at two different times. This makes sense, since from the PROV
+		point of view the creation of document is an activity that generated an entity, which then was issued (through another activity) creating 
+		another new entity. Dublin Core, on the other hand, groups those two intermediate entities under the same resource, creating the record exposed
+		in <a href="#example1">example 1</a>. Although it may seem inconsistent, 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>
-		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>:
+		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 
+		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"
 		-->
 		</p>
@@ -1082,13 +1085,13 @@
 					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>
+				<!--<tr>
 					<td><a href="http://www.w3.org/TR/prov-o/#wasRevisionOf">prov:wasRevisionOf</a></td>
 					<td>rdfs:subPropertyOf</td>
 					<td><b><a href="http://purl.org/dc/terms/isVersionOf">dct:isVersionOf</a></b></td>
 					<td>Similar to the previous property, <code>prov:wasRevisionOf</code> is more restrictive in the sense that it refers to revised version of a resource, while
 					<code>dct:isVersionOf</code> involves versions, editions or adaptations of the original resource.</td>
-				</tr>
+				</tr>-->
 				</tbody>
 			</table>
 		</div>
@@ -1108,7 +1111,7 @@
 				</tr>
 				<tr>
 					<td><b id="term_hasVersion"><a href="http://purl.org/dc/terms/hasVersion">dct:hasVersion</a></b></td>
-					<td>rdfs:subPropertyOf</td>
+					<td>owl:equivalentProperty</td>
 					<td><a href="http://www.w3.org/TR/prov-o/#hasDerivation">prov:hadRevision</a></td>
 					<td>Inverse property of <code>dct:isVersionOf</code>.</td>
 				</tr>
@@ -1219,7 +1222,7 @@
 	<h3>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
-		always needed, and it is the choice of the implementor whether to use them or not depending on the use case. It is also important to note that not all the
+		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
 		 resulting RDF graph based on another RDF graph found in the original data. We divide the queries in different categories:
@@ -1339,9 +1342,9 @@
 			<h4>Entity-Date mappings (When)</h4>
 			<p>
 			Dates often correspond with a who-property, e.g., creator and created or publisher and issued.
-			 Therefore, they lead to similar complex patterns (providing a date instead of an agent associated with the corresponding activity).
+			 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,
-			 issued, date, etc., but in this phase of the mapping each term is treated independently. 				 
+			 issued, date, etc. In this section each term is treated independently. 				 
 			</p>
 			
 			<section>
@@ -1564,10 +1567,10 @@
 		 </pre>
 		 <a href="#figure_cleanup1">Figure 3</a> shows a graphical representation of the pattern:
 		 
-		<div id = "figure_cleanup1" class="figure" style="text-align: center;">
+		<div id = "figure_cleanup1" style="text-align: center;">
 			<img src="img/cleanup1.png"></img>
 			<div style="text-align: center;">
-			<a href="#figure_cleanup1">Figure 3</a>. Gathering complementing properties to conflate blank nodes.	
+			<a href="#figure_cleanup1">Figure 3</a>. Using complementing properties to conflate blank nodes. Dates are represented in green and roles in purple.	
 			</div>
 		</div>
 	 </p>
@@ -1576,10 +1579,10 @@
 		<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 share the same
 		blank node (<code>_:created_entity</code>).
-		<div id = "figure_cleanup2" class="figure" style="text-align: center;">
+		<div id = "figure_cleanup2" style="text-align: center;">
 			<img src="img/cleanup2.png"></img>
 			<div style="text-align: center;">
-			<a href="#figure_cleanup2">Figure 4</a>. Sorting the activities by date to conflate blank nodes. The creation activity occurs before the publishing activity.	
+			<a href="#figure_cleanup2">Figure 4</a>. Ordering activities to conflate blank nodes. The creation activity occurs before the publishing activity.	
 			</div>
 		</div>
 		</p>
@@ -1601,7 +1604,7 @@
 		-->
 		<p>
 			<table>
-			<caption> <a href="#list_of_excluded_terms"> Table 6:</a> List of terms excluded from the mapping </caption>
+			<caption> <a href="#list-of-terms-excluded-from-the-mapping"> Table 6:</a> List of terms excluded from the mapping </caption>
 			<tbody>
 			<tr>
 				<th>Term</th>
--- a/dc-note/files/prov-dc-directmappings.ttl	Tue Feb 19 16:27:16 2013 +0100
+++ b/dc-note/files/prov-dc-directmappings.ttl	Wed Feb 20 01:03:57 2013 +0100
@@ -18,7 +18,6 @@
  dct:type            owl:equivalentProperty    prov:type .
  
  prov:hadPrimarySource rdfs:subPropertyOf dct:source .
- prov:wasRevisionOf     rdfs:subPropertyOf dct:isVersionOf .
  
  dct:created         rdfs:subPropertyOf    prov:generatedAtTime .
  dct:issued          rdfs:subPropertyOf    prov:generatedAtTime .
Binary file dc-note/img/example1.png has changed
Binary file dc-note/img/mapping-example - conflating.png has changed