Final edits to the DC note
authordgarijo
Wed, 20 Feb 2013 17:57:09 +0100
changeset 5619 7109462ccdb1
parent 5610 60ba893c80b2
child 5620 985710a453e6
Final edits to the DC note
dc-note/dc-note.html
--- a/dc-note/dc-note.html	Wed Feb 20 15:19:43 2013 +0100
+++ b/dc-note/dc-note.html	Wed Feb 20 17:57:09 2013 +0100
@@ -612,12 +612,12 @@
 		<caption> <a href="#ns"> Table 2</a>: Namespaces used in the document </caption>
 		<tbody>
 		<tr><td><b>prefix</b></td><td><b>Namespace IRI</b></td><td><b>Definition</b></td></tr>
-		<tr><td>owl</td><td>&lt;http://www.w3.org/2002/07/owl#&gt;</td><td>The OWL namespace [[OWL2-OVERVIEW]]</td></tr>
-		<tr><td>rdfs</td><td>&lt;http://www.w3.org/2000/01/rdf-schema#&gt;</td><td>The RDFS namespace[[RDFS]]</td></tr>
-		<tr><td>prov</td><td>&lt;http://www.w3.org/ns/prov#&gt;</td><td>The PROV namespace [[PROV-DM]]</td></tr>
-		<tr><td>dct</td><td>&lt;http://purl.org/dc/terms/&gt;</td><td>Dublin Core Terms namespace [[DCTERMS]]</td></tr>
+		<tr><td>owl</td><td>&lt;http://www.w3.org/2002/07/owl#&gt;</td><td>The OWL namespace [[OWL2-OVERVIEW]].</td></tr>
+		<tr><td>rdfs</td><td>&lt;http://www.w3.org/2000/01/rdf-schema#&gt;</td><td>The RDFS namespace[[RDFS]].</td></tr>
+		<tr><td>prov</td><td>&lt;http://www.w3.org/ns/prov#&gt;</td><td>The PROV namespace [[PROV-DM]].</td></tr>
+		<tr><td>dct</td><td>&lt;http://purl.org/dc/terms/&gt;</td><td>Dublin Core Terms namespace [[DCTERMS]].</td></tr>
 		<!--<tr><td>dc</td><td>&lt;http://purl.org/dc/elements/1.1/&gt;</td><td>Dublin Core elements namespace [[DCTERMS]]</td></tr>-->
-		<tr><td>ex</td><td>&lt;http://example.org&gt;</td><td>Application-dependent IRIs</td></tr>
+		<tr><td>ex</td><td>&lt;http://example.org&gt;</td><td>Application-dependent URIs. Used in the examples of the document.</td></tr>
 		</tbody>
 	  </table>
 	  </div>
@@ -629,8 +629,8 @@
 	<p>
 	<a href="#preliminaries">Section 2</a> explains the main considerations to take into account in order to fully understand the mapping:
 		<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>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>
 		</ul>
 	</p>
 	<p>
@@ -680,13 +680,12 @@
 	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 
-	<i>where</i> a resource was affected (such information is only available for the publication of a resource). The categories are further explained below:
+	<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 refering to its provenance (a total of 30 out of 55 terms). 
-	Some examples are the <code>dct:title</code>, <code> dct:abstract</code> or <code>dct:description</code> of a resource, the <code>dct:accessRights</code> that other agents have to 
-	access the resource, the <code>dct:format</code> in which the resource can be found, etc.
+	Some examples are the <code>dct:title</code>, <code> dct:abstract</code> or <code>dct:description</code> of a resource, the <code>dct:format</code> in which the resource can be found, etc.
 	</p>
 	<p>
 	<b>Agency Terms (Who?):</b> This category contains agent related terms. All properties have <code>dct:Agent</code> as range,
@@ -739,7 +738,7 @@
 		<tr>
 			<td><b>Descriptive metadata</b></td>
 			<td>-</td>
-			<td><a href="#term_abstract">abstract</a>, <a href="#term_accessRights">accessRights</a>, <a href="#term_accrualMethod">accrualMethod</a>,
+			<td><a href="#term_abstract">abstract</a>, <a href="#term_accrualMethod">accrualMethod</a>,
 			<a href="#term_accrualPeriodicity">accrualPeriodicity</a>, <a href="#term_accrualPolicy">accrualPolicy</a>,
 			<a href="#term_alternative">alternative</a>, <a href="#term_audience">audience</a>, <a href="#term_bibliographicCitation">bibliographicCitation</a>,
 			<a href="#term_conformsTo">conformsTo</a>, <a href="#term_coverage"> coverage</a>, <a href="#term_description">description</a>, 
@@ -765,7 +764,7 @@
 		<tr>
 			<td><b>Provenance</b></td>
 			<td>How</td>
-			<td><a href="#term_isVersionOf">isVersionOf</a>, <a href="#term_hasVersion">hasVersion</a>, <a href="#term_isFormatOf">isFormatOf</a>, <a href="#term_has_Format">hasFormat</a>, <a href="#term_license">license</a>,
+			<td><a href="#term_accessRights">accessRights</a>, <a href="#term_isVersionOf">isVersionOf</a>, <a href="#term_hasVersion">hasVersion</a>, <a href="#term_isFormatOf">isFormatOf</a>, <a href="#term_has_Format">hasFormat</a>, <a href="#term_license">license</a>,
 			<a href="#term_references">references</a>, <a href="#term_isReferencedBy">isReferencedBy</a>, <a href="#term_replaces">replaces</a>, <a href="#term_isReplacedBy">isReplacedBy</a>,  <a href="#term_rights">rights</a>,
 			<a href="#term_source">source</a></td>
 		</tr>
@@ -824,8 +823,8 @@
 	</p>		
 		<p>
 			1) 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 representations. For example, consider the
-			about the translation of a single <code>dct:publisher</code> statement (as shown on the top of <a href="#figure_mapping_example">Figure 1</a>): 
+			document by means of <code>prov:specializationOf</code>. This leads to bloated and not very intuitive data representations. For example, consider the 
+			translation of a single <code>dct:publisher</code> statement (as shown on the top of <a href="#figure_mapping_example">Figure 1</a>): 
 			having a publisher implies a "Publish" activity (represented with a blank node), which is related to the <code>ex:publisher</code> agent. The
 			activity must have taken as input the document to be published (<code>:_usedEntity</code>, which is a <code>prov:sprecializationOf</code> the 
 			resource we are describing), and generated the published resource (<code>:_resultingEntity</code>). Since we can't ensure that the published 
@@ -872,7 +871,7 @@
 		<li> <a href="#direct-mappings">Section 3.1</a>: Direct mappings between Dublin Core 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="#cleanup">Section 3.4 </a>: Strategies for cleaning up some of the blank nodes of <a href="#complex-mappings">Section 3.3</a>.</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>
 	</ul>
@@ -882,8 +881,8 @@
 		<p>
 		The direct mappings relate the DC Terms to the PROV binary relationships by using the integration mechanisms of RDF. 
 		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>
+		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,
 		 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. 
@@ -925,13 +924,13 @@
 				<td><b id="term_creator"><a href="http://purl.org/dc/terms/creator">dct:creator</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
-				<td>A creator is one of the agents who participated in the creation of a resource. He has the attribution for the outcome of that activity</td>
+				<td>A creator is one of the agents who participated in the creation of a resource. He has the attribution for the outcome of that activity.</td>
 			</tr>
 			<tr>
 				<td><b id="term_publisher"><a href="http://purl.org/dc/terms/publisher">dct:publisher</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
-				<td>A publisher has the attribution of the published resource after participating in the publishing activity that generated it .</td>
+				<td>A publisher has the attribution of the published resource after participating in the publishing activity that generated it.</td>
 			</tr>
 			<tr>
 				<td><b id="term_contributor"><a href="http://purl.org/dc/terms/contributor">dct:contributor</a></b></td>
@@ -958,7 +957,7 @@
 				<td><b id="term_has_Format"><a href="http://purl.org/dc/terms/hasFormat">dct:hasFormat</a></b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#alternateOf">prov:alternateOf</a></td>
-				<td> See rationale for <code>dct:isFormatOf</code></td>
+				<td> See rationale for <code>dct:isFormatOf</code>.</td>
 			</tr>
 			<tr>
 				<td><b id="term_replaces"><a href="http://purl.org/dc/terms/replaces">dct:replaces</a></b></td>
@@ -967,14 +966,14 @@
 				<td> There is a relation between two resources when the former replaces or displaces the latter, but it is not necessarily
 				derivation, revision, specialization or alternate. For example an item of a catalog can replaced with another item
 				that had nothing to do with the former (in case of mistake of the provider of the catalogue, or catalogue renovation). 
-				Thus, the term is mapped to <code>prov:wasInfluencedBy</code></td>
+				Thus, the term is mapped to <code>prov:wasInfluencedBy</code>.</td>
 			</tr>	
 			<tr>
 				<td><b id="term_source"><a href="http://purl.org/dc/terms/source">dct:source</a> </b></td>
 				<td>rdfs:subPropertyOf</td>
 				<td><a href="http://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></td>
-				<td>In Dublin Core, <code>dct:source</code> is defined as a "related resource from which the described resource is derived", which matches the notion of derivation
-				in PROV-DM ("a transformation of an entity in another")</td>
+				<td><code>dct:source</code> is defined as a "related resource from which the described resource is derived", which matches the notion of derivation
+				in PROV-DM ("a transformation of an entity in another").</td>
 			</tr>
 			<tr>
 				<td><b><a href="http://purl.org/dc/terms/type">dct:type</a></b></td>
@@ -987,8 +986,8 @@
 				<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 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.)
+				We map it as a subproperty of <code>prov:generatedAtTime</code> because "creation" is one of the many activities that generate an entity (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 
@@ -1033,14 +1032,14 @@
 		</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 (<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 
+		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
+		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>
-		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>:
+		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 
 		the resource in a single entity, the latter	proposes to separate all of them
@@ -1063,7 +1062,7 @@
 					<th>Rationale</th>
 				</tr>
 				<tr>
-					<td><a href="http://www.w3.org/TR/prov-o/#hadPrimarySoource">prov:hadPrimarySource</a></td>
+					<td><a href="http://www.w3.org/TR/prov-o/#hadPrimarySource">prov:hadPrimarySource</a></td>
 					<td>rdfs:subPropertyOf</td>
 					<td><b><a href="http://purl.org/dc/terms/source">dct:source</a></b></td>
 					<td>The definition of <code>prov:hadPrimarySource</code> ("something produced by some agent with direct experience 
@@ -1199,8 +1198,9 @@
 		</p>
 		 
 		<p>
-		Custom refinements of the properties have been omitted as they would be identical to the Dublin Core terms. If these more
-		 specific properties are needed, the Dublin Core terms can be used directly, according to the direct mappings presented in section 2.3. 
+		Custom refinements of the properties have been omitted as they would be identical to the DC terms. If these more
+		 specific properties are needed, the Dublin Core terms can be used directly, according to the direct mappings presented in 
+		 <a href="#direct-mappings">Section 3.1</a>. 
 		</p>
 	</section>
 	<section>
@@ -1221,7 +1221,7 @@
 			 
 			 <p>
 			 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
+			 on the available data. 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,
@@ -1234,7 +1234,7 @@
 			</p>
 			<section>
 				<h5> dct:creator</h5>
-				A creator is the agent associated with role Creator in the activity that generated a specialization of the entity ?document.  
+				A creator is the agent in charge of the "Create" activity that generated a specialization of the entity ?document. The agent is assigned the role "creator".  
 				<pre class="code">
   CONSTRUCT {
 	?document a prov:Entity ;
@@ -1245,9 +1245,9 @@
 	_:activity a prov:Activity, prov:Create ;
 			prov:wasAssociatedWith ?agent;
 			prov:qualifiedAssociation [
-			a prov:Association;
-			prov:agent ?agent;
-			prov:hadRole prov:Creator .
+				a prov:Association;
+				prov:agent ?agent;
+				prov:hadRole prov:Creator .
 		].
 						
 	_:resulting_entity a prov:Entity ;
@@ -1365,23 +1365,23 @@
 	 ?document a prov:Entity .
 	 
 	 _:activity a prov:Activity, prov:Publish ;
-				prov:used _:used_entity .
+			prov:used _:used_entity .
 					  
 	# The “input”
 	 _:used_entity a prov:Entity .
-				prov:specializationOf ?document .
+			prov:specializationOf ?document .
 					  
 	 # The “output”
 	 _:iss_entity a prov:Entity ;
-				prov:specializationOf ?document ;
-				prov:wasGeneratedBy _:activity ;
-				prov:wasGeneratedAtTime ?date;
-				prov:wasDerivedFrom _:used_entity ;
-				prov:qualifiedGeneration [ 
-					 a prov:Generation ;
-					 prov:atTime ?date  ;
-					 prov:activity _:activity . 
-				] .   
+			prov:specializationOf ?document ;
+			prov:wasGeneratedBy _:activity ;
+			prov:wasGeneratedAtTime ?date;
+			prov:wasDerivedFrom _:used_entity ;
+			prov:qualifiedGeneration [ 
+				 a prov:Generation ;
+				 prov:atTime ?date  ;
+				 prov:activity _:activity . 
+			] .   
  } WHERE { 
 	  ?document dct:issued ?date.
  }
@@ -1395,23 +1395,23 @@
 	?document a prov:Entity .
 	 
 	 _:activity a prov:Activity, prov:Modify ;
-				prov:used _:used_entity .
+			prov:used _:used_entity .
 					  
 	# The “input”
 	 _:used_entity a prov:Entity .
-				prov:specializationOf ?document .
+			prov:specializationOf ?document .
 					  
 	 # The “output”
 	 _:modified_entity a prov:Entity ;
-				prov:specializationOf ?document ;
-				prov:wasGeneratedBy _:activity ;
-				prov:wasGeneratedAtTime ?date;
-				prov:wasDerivedFrom _:used_entity ;
-				prov:qualifiedGeneration  [ 
-					 a prov:Generation ;
-					 prov:atTime ?date  ;
-					 prov:activity _:activity . 
-				] .   
+			prov:specializationOf ?document ;
+			prov:wasGeneratedBy _:activity ;
+			prov:wasGeneratedAtTime ?date;
+			prov:wasDerivedFrom _:used_entity ;
+			prov:qualifiedGeneration  [ 
+				 a prov:Generation ;
+				 prov:atTime ?date  ;
+				 prov:activity _:activity . 
+			] .   
  } WHERE { 
   ?document dct:modified ?date.
  }
@@ -1425,23 +1425,23 @@
 	 ?document a prov:Entity .
 	 
 	 _:activity a prov:Activity, prov:Accept ;
-				prov:used _:used_entity .
+			prov:used _:used_entity .
 					  
 	# The “input”
 	 _:used_entity a prov:Entity .
-				prov:specializationOf ?document .
+			prov:specializationOf ?document .
 					  
 	 # The “output”
 	 _:accepted_entity a prov:Entity ;
-				prov:specializationOf ?document ;
-				prov:wasGeneratedBy _:activity ;
-				prov:wasGeneratedAtTime   ?date;
-				prov:wasDerivedFrom       _:used_entity ;
-				prov:qualifiedGeneration  [ 
-					 a prov:Generation ;
-					 prov:atTime ?date  ;
-					 prov:activity _:activity . 
-				] .   
+			prov:specializationOf ?document ;
+			prov:wasGeneratedBy _:activity ;
+			prov:wasGeneratedAtTime   ?date;
+			prov:wasDerivedFrom       _:used_entity ;
+			prov:qualifiedGeneration  [ 
+				 a prov:Generation ;
+				 prov:atTime ?date  ;
+				 prov:activity _:activity . 
+			] .   
  } WHERE { 
   ?document dct:dateAccepted ?date.
  }
@@ -1455,23 +1455,23 @@
 	 ?document a prov:Entity .
 	 
 	 _:activity a prov:Activity, prov:Copyright ;
-				prov:used _:used_entity .
+			prov:used _:used_entity .
 					  
 	# The “input”
 	 _:used_entity a prov:Entity .
-				prov:specializationOf ?document .
+			prov:specializationOf ?document .
 					  
 	 # The “output”
 	 _:copyrighted_entity a prov:Entity ;
-				prov:specializationOf ?document ;
-				prov:wasGeneratedBy _:activity ;
-				prov:wasGeneratedAtTime ?date;
-				prov:wasDerivedFrom _:used_entity ;
-				prov:qualifiedGeneration [ 
-					 a prov:Generation ;
-					 prov:atTime ?date  ;
-					 prov:activity _:activity . 
-				] .   
+			prov:specializationOf ?document ;
+			prov:wasGeneratedBy _:activity ;
+			prov:wasGeneratedAtTime ?date;
+			prov:wasDerivedFrom _:used_entity ;
+			prov:qualifiedGeneration [ 
+				 a prov:Generation ;
+				 prov:atTime ?date  ;
+				 prov:activity _:activity . 
+			] .   
  } WHERE { 
   ?document dct:dateCopyrighted ?date.
  }
@@ -1483,24 +1483,24 @@
  CONSTRUCT{
 	 ?document a prov:Entity .
 	 
-	 _:activity a prov:Activity, prov:SubmissionActivity ;
-				prov:used _:used_entity .
+	 _:activity a prov:Activity, prov:Submit ;
+			prov:used _:used_entity .
 					  
 	# The “input”
 	 _:used_entity a prov:Entity .
-				prov:specializationOf ?document .
+			prov:specializationOf ?document .
 				  
 	 # The “output”
 	 _:submitted_entity a prov:Entity ;
-				prov:specializationOf ?document ;
-				prov:wasGeneratedBy _:activity ;
-				prov:wasGeneratedAtTime ?date;
-				prov:wasDerivedFrom _:used_entity ;
-				prov:qualifiedGeneration  [ 
-					 a prov:Generation ;
-					 prov:atTime ?date  ;
-					 prov:activity _:activity . 
-				] .   
+			prov:specializationOf ?document ;
+			prov:wasGeneratedBy _:activity ;
+			prov:wasGeneratedAtTime ?date;
+			prov:wasDerivedFrom _:used_entity ;
+			prov:qualifiedGeneration  [ 
+				 a prov:Generation ;
+				 prov:atTime ?date  ;
+				 prov:activity _:activity . 
+			] .   
  } WHERE { 
   ?document dct:dateSubmitted ?date.
  }
@@ -1514,7 +1514,7 @@
 	<h3>Cleanup</h3>
 		<p>
 		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
+	    leads to the proliferation of blank nodes. Blank nodes could be renamed to specific identifiers
 		 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
@@ -1560,9 +1560,9 @@
 		</div>
 	 </p>
 		 <p>2) Another solution is to <b>sort all the activities according to their logical order</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 -->
+		nodes result of one activity with 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 share the same
+		points in time. Creation precedes publication, so instead of creating different blank nodes for their respective usage and generation, both activities share the same
 		blank node (<code>_:created_entity</code>).
 		<div id = "figure_cleanup2" style="text-align: center;">
 			<img src="img/cleanup2.png"></img>
@@ -1604,7 +1604,7 @@
 			</tr><tr>
 				<td><b id="term_accrualMethod"><a href="http://purl.org/dc/terms/accrualMethod">dct:accrualMethod</a></b></td>
 				<td>Descriptive Metadata</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>
+				<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"><a href="http://purl.org/dc/terms/accrualPeriodicity">dct:accrualPeriodicity</a></b></td>
 				<td>Descriptive metadata</td>
@@ -1618,7 +1618,7 @@
 				<td><b id="term_alternative"><a href="http://purl.org/dc/terms/alternative">dct:alternative</a></b></td>
 				<td>Descriptive metadata</td>
 				<td>Refers to an alternative title of the resource. For example "The Bible" might be also known as "The Holy Book". Titles are not identifiers,
-				so this property can't be mapped to <code>prov:alternateOf</code></td>
+				so this property can't be mapped to <code>prov:alternateOf</code>.</td>
 			</tr><tr>
 				<td><b id="term_audience"><a href="http://purl.org/dc/terms/audience">dct:audience</a></b></td>
 				<td>Descriptive metadata</td>
@@ -1638,7 +1638,7 @@
 			</tr><tr>
 				<td><b id="term_educationLevel"><a href="http://purl.org/dc/terms/educationLevel">dct:educationLevel</a></b></td>
 				<td>Descriptive metadata</td>
-				<td>The educational level of the audience for which the resource is intended too.</td>
+				<td>The educational level of the audience for which the resource is intended to.</td>
 			</tr><tr>
 				<td><b id="term_extent"><a href="http://purl.org/dc/terms/extent">dct:extent</a></b></td>
 				<td>Descriptive metadata</td>
@@ -1662,9 +1662,8 @@
 			</tr><tr>
 				<td><b id="term_isRequiredBy"><a href="http://purl.org/dc/terms/isRequiredBy">dct:isRequiredBy</a></b></td>
 				<td>Descriptive metadata</td>
-				<td>The current resource is required for supporting the function of another resource. This is not related
-			the provenance, since it refers to something that may not have happened yet (e.g., a library dependency, but the program 
-			that needs it hasn’t been executed yet).</td>
+				<td>Property used to describe that the current resource is required for supporting the function of another resource. This is not related
+			the provenance of the reosource, since it refers to something that may not have happened yet (e.g., a library dependency in script program).</td>
 			</tr><tr>
 				<td><b id="term_language"><a href="http://purl.org/dc/terms/language">dct:language</a></b></td>
 				<td>Descriptive metadata</td>
@@ -1743,11 +1742,11 @@
 			</tr><tr>
 				<td><b id="term_date"><a href="http://purl.org/dc/terms/date">dct:date</a></b></td>
 				<td>Provenance: When</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>
+				<td>Date is a very general property. It is the superproperty which all the other dates specialize, but there is no equivalent concept in PROV. It has been excluded from the mapping.</td>
 			</tr><tr>
 				<td><b id="term_available"><a href="http://purl.org/dc/terms/available">dct:available</a></b></td>
 				<td>Provenance: When</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>
+				<td>Property that states when a resource is available. There is no direct mapping between this property and the notion of invalidation in PROV.</td>
 			</tr><tr>
 				<td><b id="term_valid"><a href="http://purl.org/dc/terms/valid">dct:valid</a></b></td>
 				<td>Provenance: When</td>