Namespaces URIs

The namespace URIs used in this document can be seen in Table 2:

Structure of this document

Section 2 explains the main considerations to take into account in order to fully understand the mapping:

• The DC terms related to the provenance of a resource (Section 2.1).
• How entities are defined in Dublin Core, along with several examples (Section 2.2).

Section 3 describes the mapping between DC and PROV. The mapping is divided in different sections, depending on the level of complexity that different users might be interested in when translating their DC data to PROV:

• Section 3.1 introduces the direct mappings 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 infer PROV binary relationships from DC data.
• Section 3.2 explains the definition of new refinements (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.
• Section 3.3 defines complex mappings. These mappings make use of the refinements introduced in Section 3.2 and combine them in order to derive an enhanced provenance chain.
• Due to the way in which the complex mappings are defined, blank nodes are produced for each DC statement. Section 3.4 introduces some strategies on how to reduce the amount of blank nodes.
• Section 3.5, on the other hand, describes the rationale for the terms left out of the mapping. Some terms may imply a mapping (e.g., dct:alternative is similar to prov:alternateOf), but do not in fact correspond. Other terms summarize the resolution of the community discussion with examples.
• Finally, Section 3.6 adds some details about the inverse mapping (PROV to DC), which is out of the scope of this document.

Provenance in Dublin Core

Many DCMI terms can be used to describe provenance information about a resource: when it was affected in the past, who affected it and how it was affected. The rest of the DCMI terms (description metadata), tell us what was affected. Table 1 classifies the DC Terms according to these four categories (what?, who?, when? and how?). 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 where a resource was affected. The categories are further explained below:

Descriptive Terms (What?): This category contains all the terms describing a resource without referring to its provenance (a total of 30 out of 55 terms). Some examples are the dct:title, dct:abstract, the dct:description of a resource or the dct:format in which the resource can be found.

Agency Terms (Who?): This category contains agent related terms. All properties have dct:Agent as range, i.e., a resource that acts or has the power to act. The dct:contributor, dct:creator, and dct:publisher clearly influence the resource and therefore are important for its origin. This is not immediately clear for the dct:rightsHolder, but as ownership is considered the important provenance information for many resources, like artworks, it is included in this category.

Date and Time Terms (When?): This category contains date and time related terms. Dates belong to the provenance record of a resource, as they track when something was created (dct:created), modified (dct:modified), published (dct:issued), etc. Two dates can be considered special regarding their relevance for provenance: dct:available and dct: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 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, then it is relevant for its provenance.

Derivation Terms (How?): 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 (dct:isVersionOf), format serializations (dct:isFormatOf), replacements (dct:replaces) and sources of information (dct:source). dct:references 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 and therefore it is relevant for its provenance. The respective inverse properties do not necessarily contribute to the provenance of the described resource, e.g., a resource is usually not directly affected by being referenced or by being used as a source. However, inverse properties belong to the provenance related terms as they can be used to describe the relations between the resources involved. Finally, licensing (dct:license), rights (dct:rights) and their access (accessRights) are considered part of the provenance of the resource as well, since they restrict and explain how the resource can be used for further derivation.

This leaves one very special term: provenance. 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" [DCTERMS], a definition that corresponds to the notion of provenance for artworks. This term can be considered a link between the resource and any provenance statement about the resource, so it cannot be included in any of the aforementioned categories.

Entities in Dublin Core

Consider the example metadata record below (Example 1), where a document (ex:doc1) is described with several DC statements:

Example 1: a simple metadata record:

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 ;
dct:issued "2012-02-29" ;
dct:subject ex:dublincore ;
dct:replaces ex:doc2 ;
dct:format "HTML" .

1) Create new instances of entities that are all related to the original document by means of prov:specializationOf. For example, consider the translation of a single dct:publisher statement (as shown on the top of Figure 1): having a publisher implies a "Publish" activity (represented with a blank node), which is related to the ex:publisher agent. The activity must have taken as input the document to be published (:_usedEntity, which is a prov:sprecializationOf the resource we are describing), and generated the published resource (:_resultingEntity). Since we cannot ensure that the published resource has not gone through any further modifications, :_resultingEntity is also a prov:specializationOf the resource ex:doc1.

Figure 1. A mapping example creating blank nodes for each state of the resource. PROV entities are represented with ellipses, activities with rectangles and agents with pentagons. The bold arrow implies how the DC statement (on top of the figure) would be converted to PROV (the graph on the bottom).

2) Adopt the original resource (ex:doc1) as the prov:Entity used and then generated by the Publish activity (:_activity). However, this representation leads to a misinterpretation of the DC statement, as shown in the example of Figure 2. The representation implies that ex:doc1 was generated by _:activity and then used by _:activity afterwards, instead of being used and then being generated by _:activity (prov:Entities must exist before being used).

Figure 2. A mapping example conflating blank nodes within the same resource. The used and generated resources have the same identifier. This example is an invalid translation of the dct:publisher statement (as it implies that ex:doc1 was generated by _:activity and then used by the same activity).

Since the first option provides a correct interpretation of the DC statements, it has been chosen as the approach for the complex mapping defined in this document.. Blank nodes are used for the mapping, although any naming mechanism could be provided if necessary, leaving the conflating of nodes to the cleanup phase.

Direct mappings

The direct mappings [PROV-DC-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).

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.

Table 3 and Table 4 provide the detailed mapping plus the rationale for each term. The rest of the terms can be found in the list of terms left out of the mapping.

Regarding the rest of the direct mappings, a property (prov:hadPrimarySource) has been found to be superproperty of a PROV concept, represented in Table 4:

Table 5 enumerates the mapping of the DC terms that map to inverse relationships in PROV. These have been separated in a different table because they do not belong to the core of PROV.

PROV refinements

In order to produce complex mappings for the DC terms, we need specific subclasses extending the PROV ontology [PROV-O]. These subclases [PROV-DC-REFINEMENTS] are designed to qualify the DC properties in the complex mappings. For example, a dc:publisher 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:

 
 prov:Publish        rdfs:subClassOf     prov:Activity .
 prov:Contribute     rdfs:subClassOf     prov:Activity .
 prov:Create         rdfs:subClassOf     prov:Activity, prov:Contribute .
 prov:Modify         rdfs:subClassOf     prov:Activity .
 prov:Accept         rdfs:subClassOf     prov:Activity .
 prov:Copyright      rdfs:subClassOf     prov:Activity .
 prov:Submit         rdfs:subClassOf     prov:Activity .
 prov:Replace        rdfs:subClassOf     prov:Activity .
 prov:Publisher      rdfs:subClassOf     prov:Role .
 prov:Contributor    rdfs:subClassOf     prov:Role . 
 prov:Creator        rdfs:subClassOf     prov:Role, prov:Contributor .
		

Additional refinements of the PROV properties have been ommitted, since the direct mappings presented in Section 3.1 already define the relationship between both vocabularies.

Complex Mappings

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 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 into different categories:

  CONSTRUCT {
	?document a prov:Entity ;
			prov:wasAttributedTo ?agent.				
	
	?agent a prov:Agent .
					
	_:activity a prov:Activity, prov:Create ;
			prov:wasAssociatedWith ?agent;
			prov:qualifiedAssociation [
				a prov:Association;
				prov:agent ?agent;
				prov:hadRole prov:Creator .
		].
						
	_:resulting_entity a prov:Entity ;
			prov:specializationOf ?document ;
			prov:wasGeneratedBy _:activity ;
			prov:wasAttributedTo ?agent.		
						
 } WHERE {
	?document dct:creator ?agent.
 }
				

 CONSTRUCT {
	?document a prov:Entity ;
			prov:wasAttributedTo ?agent .
				
	?agent a prov:Agent .
					
	_:activity a prov:Activity, prov:Contribute ;
			prov:wasAssociatedWith ?agent ;
			prov:qualifiedAssociation [ 
				a prov:Association ;
				prov:agent ?agent ;
				prov:hadRole prov:Contributor .
			].
						
	_:resulting_entity a prov:Entity ;		
			prov:specializationOf ?document ;
			prov:wasGeneratedBy _:activity ;
			prov:wasAttributedTo ?agent .
						
 } WHERE {
	?document dct:contributor ?agent .
 }
				

  CONSTRUCT {
	?document a prov:Entity ;
			prov:wasAttributedTo ?agent .
						
	?agent a prov:Agent .
					
	_:used_entity a prov:Entity;
			prov:specializationOf ?document.
						
	_:activity a prov:Activity, prov:Publish ;
			prov:used _:used_entity;
			prov:wasAssociatedWith ?agent ;
			prov:qualifiedAssociation [ 
					a prov:Association ;
					prov:agent ?agent ;
					prov:hadRole prov:Publisher .
			].
						
	_:resulting_entity a prov:Entity ;
			prov:specializationOf ?document ;		
			prov:wasDerivedFrom _:used_entity
			prov:wasGeneratedBy _:activity ;
			prov:wasAttributedTo ?agent .
						
 } WHERE {
	?document dct:publisher ?agent .
 }
				

 CONSTRUCT{
	 ?document a  prov:Entity .
							
	 _:activity a prov:Activity, prov:Create ;
							 
	 # The “output”
	 _:created_entity a prov:Entity ;
			prov:specializationOf ?document ;
			prov:wasGeneratedBy _:activity ;
			prov:wasGeneratedAtTime ?date;
			prov:qualifiedGeneration [ 
					a prov:Generation ;
					prov:atTime ?date  ;
					prov:activity _:activity . 
			] .
 } WHERE { 
  ?document dct:created ?date.
 }
				

 CONSTRUCT{
	 ?document a prov:Entity .
	 
	 _:activity a prov:Activity, prov:Publish ;
			prov:used _:used_entity .
					  
	# The “input”
	 _:used_entity a prov:Entity .
			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 . 
			] .   
 } WHERE { 
	  ?document dct:issued ?date.
 }
				

 
 CONSTRUCT{
	?document a prov:Entity .
	 
	 _:activity a prov:Activity, prov:Modify ;
			prov:used _:used_entity .
					  
	# The “input”
	 _:used_entity a prov:Entity .
			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 . 
			] .   
 } WHERE { 
  ?document dct:modified ?date.
 }
				

 
 CONSTRUCT{
	 ?document a prov:Entity .
	 
	 _:activity a prov:Activity, prov:Accept ;
			prov:used _:used_entity .
					  
	# The “input”
	 _:used_entity a prov:Entity .
			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 . 
			] .   
 } WHERE { 
  ?document dct:dateAccepted ?date.
 }
				

CONSTRUCT{
	 ?document a prov:Entity .
	 
	 _:activity a prov:Activity, prov:Copyright ;
			prov:used _:used_entity .
					  
	# The “input”
	 _:used_entity a prov:Entity .
			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 . 
			] .   
 } WHERE { 
  ?document dct:dateCopyrighted ?date.
 }
				

 CONSTRUCT{
	 ?document a prov:Entity .
	 
	 _:activity a prov:Activity, prov:Submit ;
			prov:used _:used_entity .
					  
	# The “input”
	 _:used_entity a prov:Entity .
			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 . 
			] .   
 } WHERE { 
  ?document dct:dateSubmitted ?date.
 }
				

CONSTRUCT{
 	 ?document a prov:Entity .
 	 ?document2 a prov:Entity.
					
 	 _:activity a prov:Activity, prov:Replace ;
			prov:used _:old_entity.
				 
	  # The “input”
 	 _:old_entity a prov:Entity;
			prov:specializationOf ?document2 ;
			
 	 # The “output”
 	 _:new_entity a prov:Entity ;
			prov:specializationOf ?document ;
			prov:wasGeneratedBy _:activity;
			prov:wasDerivedFrom _:old_entity .
                     
 } WHERE { 
  ?document dct:replaces ?document2.
 }
				

Cleanup

The cleanup phase aims to reduce the number of blank nodes produced by the complex mappings. This depends on how implementers interpret the described resources. 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.

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:

1) Conflate properties referring to the same state of the resource: 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.

The example below shows how to conflate the blank nodes for dct:creator and dct:created properties:

	 CONSTRUCT{
	 ?document a prov:Entity .
	 
	 _:activity a prov:Activity, prov:Create.
				prov:wasAssociatedWith ?agent
				prov:qualifiedAssociation [
					 a prov:Association;
					 prov:agent ?agent;
					 prov:hadRole prov:Creator .
				] .
				  
	 # The “output”
	 _:created_entity a prov:Entity ;
				prov:specializationOf ?document ;
				prov:wasGeneratedBy _:activity ;
				prov:wasGeneratedAtTime   ?date;                 
				prov:qualifiedGeneration  [ 
					 a prov:Generation ;
					 prov:atTime ?date  ;			
					 prov:activity _:activity . 
			 ] .   
	 } WHERE { 
	  ?document dct:creator  ?agent;
				dct:created  ?date.
	 }
		 

Figure 3. Using complementing properties to conflate blank nodes. Dates are represented in green and roles in purple.

2) Another solution is to sort all the activities according to their logical order, if known, and conflate the blank nodes result of one activity with the input of the subsequent activity. Figure 4 shows a graphical example with two different activities (creation and publication) that happened at different 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 (_:created_entity).

Figure 4. Ordering activities to conflate blank nodes. The creation activity occurs before the publishing activity.

List of terms excluded from the mapping

Mapping from PROV to DC

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 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. 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. Likewise, the agents involved cannot be mapped to creators, contributors, or publishers. While Dublin Core 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.