CINXE.COM

<!DOCTYPE html> <html lang="en" dir="ltr"> <head> <title>Dublin Core to PROV Mapping</title> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <link rel="http://www.w3.org/ns/prov#has_provenance" href="https://www.w3.org/2011/prov/provenance/prov-dc"> <style> div.example-title { min-width: 7.5em; color: #b9ab2d; } div.example-title span { text-transform: uppercase; } aside.example, div.example, div.illegal-example { padding: 0.5em; margin: 1em 0; position: relative; clear: both; } div.illegal-example { color: red } div.illegal-example p { color: black } aside.example, div.example { padding:.5em; border-left-width:.5em; border-left-style: solid; border-color: #e0cb52; background: #fcfaee; } aside.example div.example { border-left-width:.1em; border-color: #999; background: #fff; } aside.example div.example div.example-title { color: #999; } table.parameters, table.exceptions { border-spacing: 0; border-collapse: collapse; margin: 0.5em 0; width: 100%; } table.parameters { border-bottom: 1px solid #90b8de; } table.exceptions { border-bottom: 1px solid #deb890; } table { background-color: #F4FFFF; border: 1px solid navy; margin: 20px; } table { text-align: center; vertical-align: middle; } table td { padding: 5px 15px; text-align: left; } table th { background-color: LightGoldenRodYellow; } .parameters th,.exceptions th { color: #fff; padding: 3px 5px; text-align: left; font-family: initial; font-weight: normal; } .parameters th { background: #90b8de; } .exceptions th { background: #deb890; } .parameters td,.exceptions td { padding: 3px 10px; border-top: 1px solid #ddd; vertical-align: top; } .parameters tr:first-child td,.exceptions tr:first-child td { border-top: none; } .parameters td.prmName,.exceptions td.excName,.exceptions td.excCodeName { width: 100px; } .parameters td.prmType { width: 120px; } table.exceptions table { border-spacing: 0; border-collapse: collapse; width: 100%; } pre.code { background-color:#F9F9F9; border:1px dashed #2F6FAB; color:black; line-height:1.1em; padding:1em; } /***************************************************************** * ReSpec 3 CSS * Robin Berjon - http://berjon.com/ *****************************************************************/ /* --- INLINES --- */ em.rfc2119 { text-transform: lowercase; font-variant: small-caps; font-style: normal; color: #900; } h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym, h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr { border: none; } dfn { font-weight: bold; } a.internalDFN { color: inherit; border-bottom: 1px solid #99c; text-decoration: none; } a.externalDFN { color: inherit; border-bottom: 1px dotted #ccc; text-decoration: none; } a.bibref { text-decoration: none; } cite.bibref { font-style: normal; } code { color: #ff4500; } /* --- --- */ ol.algorithm { counter-reset:numsection; list-style-type: none; } ol.algorithm li { margin: 0.5em 0; } ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; } /* --- TOC --- */ .toc a,.tof a { text-decoration: none; } a.secno, a.figno { color: #000; } ul.tof, ol.tof { list-style: none outside none; } .caption { margin-top: 0.5em; font-style: italic; } /* --- TABLE --- */ table.simple { border-spacing: 0; border-collapse: collapse; border-bottom: 3px solid #005a9c; } .simple th { background: #005a9c; color: #fff; padding: 3px 5px; text-align: left; } .simple th[scope="row"] { background: inherit; color: inherit; border-top: 1px solid #ddd; } .simple td { padding: 3px 10px; border-top: 1px solid #ddd; } .simple tr:nth-child(even) { background: #f0f6ff; } /* --- DL --- */ .section dd > p:first-child { margin-top: 0; } .section dd > p:last-child { margin-bottom: 0; } .section dd { margin-bottom: 1em; } .section dl.attrs dd,.section dl.eldef dd { margin-bottom: 0; } </style> <link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" /> </head> <body style="display: inherit;" prefix="prov: http://www.w3.org/ns/prov# foaf: http://xmlns.com/foaf/0.1/ dc: http://purl.org/dc/terms/"> <div class="head"> <p> <a href="https://www.w3.org/"><img height="48" width="72" alt="W3C" src="https://www.w3.org/Icons/w3c_home" /></a> </p> <h1 class="title" id="title">Dublin Core to PROV Mapping</h1> <h2 id="w3c-working-group-note-30-april-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note 30 April 2013</h2> <dl> <dt>This version:</dt> <dd><a href="https://www.w3.org/TR/2013/NOTE-prov-dc-20130430/">http://www.w3.org/TR/2013/NOTE-prov-dc-20130430/</a></dd> <dt>Latest published version:</dt> <dd><a href="https://www.w3.org/TR/prov-dc/">http://www.w3.org/TR/prov-dc/</a></dd>  <dt>Previous version:</dt> <dd><a href="https://www.w3.org/TR/2013/WD-prov-dc-20130312/">http://www.w3.org/TR/2013/WD-prov-dc-20130312/</a></dd> <dt>Editors:</dt> <dd><a href="http://delicias.dia.fi.upm.es/members/DGarijo/">Daniel Garijo</a>, Ontology Engineering Group, Universidad Politécnica de Madrid, Spain</dd> <dd><a href="http://www.kaiec.org/">Kai Eckert</a>, University of Mannheim, Germany</dd> <dt>Contributors:</dt> <dd><span><a href="http://www.inf.kcl.ac.uk/staff/simonm">Simon Miles</a></span>, King's College London, UK</dd> <dd><span><a href="http://www.linkedin.com/in/craigtrim">Craig M. Trim</a></span>, IBM, USA</dd> <dd><span><a href="http://staff.oclc.org/~dewey/michael.htm">Michael Panzer</a></span>, OCLC Online Computer Library Center, USA</dd> </dl> <p class="copyright"> <a href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="https://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. <abbr title="World Wide Web Consortium">W3C</abbr> <a href="https://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="https://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="https://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply. </p> <hr> </div>  <b resource="http://www.w3.org/TR/2013/NOTE-prov-dc-20130430/" typeof="foaf:Document prov:Entity"> <b property="prov:wasRevisionOf" resource="http://www.w3.org/TR/2012/WD-prov-dc-20130312/"></b> <b property="prov:specializationOf" resource="http://www.w3.org/TR/prov-dc/"></b> <b property="prov:wasAttributedTo dc:creator" resource="http://delicias.dia.fi.upm.es/members/DGarijo/#me" typeof="prov:Person foaf:Person"></b> <b property="prov:wasAttributedTo dc:creator" resource="http://www.kaiec.org/#me" typeof="prov:Person foaf:Person"></b> <b property="prov:wasAttributedTo" resource="http://www.inf.kcl.ac.uk/staff/simonm/#me" typeof="prov:Person foaf:Person"></b> <b property="prov:wasAttributedTo" resource="http://staff.oclc.org/~dewey/michael.htm#me" typeof="prov:Person foaf:Person"></b> <b property="prov:wasAttributedTo" resource="http://www.linkedin.com/in/craigtrim" typeof="prov:Person foaf:Person"></b> <b property="prov:wasAttributedTo" resource="http://www.w3.org/2011/prov" typeof="prov:Organization foaf:Organization"></b> <b property="prov:wasInfluencedBy" resource="http://www.w3.org/TR/2013/NOTE-prov-dc-20130430/#acknowledgements"></b> </b>  <section class="introductory" id="abstract"><h2>Abstract</h2> <p> This document describes a partial mapping from Dublin Core Terms [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>] to the PROV-O OWL2 ontology [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>]. A substantial number of terms in the Dublin Core vocabulary provide information about the provenance of a resource. The mapping is expressed partly by direct RDFS/OWL mappings between properties and classes [<cite><a href="#bib-mapping" class="bibref">PROV-DC-DIRECT-MAPPINGS</a></cite>]. </p> <p> Some of the direct mappings can be refined, translating single Dublin Core Terms into an extended representation of the provenance. Therefore, refinements of classes defined in PROV are needed to represent specific Dublin Core activities and roles [<cite><a href="#bib-refinements" class="bibref">PROV-DC-REFINEMENTS</a></cite>]. </p> <p> The PROV Document Overview [<cite><a href="#bib-PROV-OVERVIEW" class="bibref">PROV-OVERVIEW</a></cite>] describes the overall state of PROV, and should be read before other PROV documents. </p> </section><section id="sotd" class="introductory"><h2>Status of This Document</h2> <p> <em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at http://www.w3.org/TR/.</em> </p> <h4 id="prov-family-of-documents">PROV Family of Documents</h4> This document is part of the PROV family of documents, a set of documents defining various aspects that are necessary to achieve the vision of inter-operable interchange of provenance information in heterogeneous environments such as the Web. These documents are listed below. Please consult the [<cite><a href="#bib-PROV-OVERVIEW" class="bibref">PROV-OVERVIEW</a></cite>] for a guide to reading these documents. <ul> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-overview-20130430/">PROV-OVERVIEW</a> (Note), an overview of the PROV family of documents [<cite><a href="#bib-PROV-OVERVIEW" class="bibref">PROV-OVERVIEW</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-primer-20130430/">PROV-PRIMER</a> (Note), a primer for the PROV data model [<cite><a href="#bib-PROV-PRIMER" class="bibref">PROV-PRIMER</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/REC-prov-o-20130430/">PROV-O</a> (Recommendation), the PROV ontology, an OWL2 ontology allowing the mapping of the PROV data model to RDF [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/REC-prov-dm-20130430/">PROV-DM</a> (Recommendation), the PROV data model for provenance [<cite><a href="#bib-PROV-DM" class="bibref">PROV-DM</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/REC-prov-n-20130430/">PROV-N</a> (Recommendation), a notation for provenance aimed at human consumption [<cite><a href="#bib-PROV-N" class="bibref">PROV-N</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/REC-prov-constraints-20130430/">PROV-CONSTRAINTS</a> (Recommendation), a set of constraints applying to the PROV data model [<cite><a href="#bib-PROV-CONSTRAINTS" class="bibref">PROV-CONSTRAINTS</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-xml-20130430/">PROV-XML</a> (Note), an XML schema for the PROV data model [<cite><a href="#bib-PROV-XML" class="bibref">PROV-XML</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-aq-20130430/">PROV-AQ</a> (Note), mechanisms for accessing and querying provenance [<cite><a href="#bib-PROV-AQ" class="bibref">PROV-AQ</a></cite>]; </li> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-dictionary-20130430/">PROV-DICTIONARY</a> (Note) introduces a specific type of collection, consisting of key-entity pairs [<cite><a href="#bib-PROV-DICTIONARY" class="bibref">PROV-DICTIONARY</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-dc-20130430/">PROV-DC</a> (Note) provides a mapping between PROV-O and Dublin Core Terms (this document);</li> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-sem-20130430/">PROV-SEM</a> (Note), a declarative specification in terms of first-order logic of the PROV data model [<cite><a href="#bib-PROV-SEM" class="bibref">PROV-SEM</a></cite>];</li> <li> <a href="https://www.w3.org/TR/2013/NOTE-prov-links-20130430/">PROV-LINKS</a> (Note) introduces a mechanism to link across bundles [<cite><a href="#bib-PROV-LINKS" class="bibref">PROV-LINKS</a></cite>].</li> </ul> <h4 id="implementations-encouraged">Implementations Encouraged</h4> <p> The Provenance Working Group encourages implementation of the material defined in this document. Although work on this document by the Provenance Working Group is complete, errors may be recorded in the <a href="https://www.w3.org/2011/prov/errata.html">errata</a> or and these may be addressed in future revisions. </p> <h4 id="please-send-comments">Please Send Comments</h4>  <p> This document was published by the <a href="https://www.w3.org/2011/prov/">Provenance Working Group</a> as a Working Group Note. If you wish to make comments regarding this document, please send them to <a href="mailto:public-prov-comments@w3.org">public-prov-comments@w3.org</a> (<a href="mailto:public-prov-comments-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-prov-comments/">archives</a>). All comments are welcome. </p><p> Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. </p> <p> This document was produced by a group operating under the <a href="https://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>. <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="https://www.w3.org/2004/01/pp-impl/46974/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="https://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>. </p> </section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a class="tocxref" href="#introduction"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#namespaces-1"><span class="secno">1.1 </span>Namespaces URIs</a></li><li class="tocline"><a class="tocxref" href="#structure-of-this-document"><span class="secno">1.2 </span>Structure of this document</a></li></ul></li><li class="tocline"><a class="tocxref" href="#preliminaries"><span class="secno">2. </span>Preliminaries</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#provenance-in-dublin-core"><span class="secno">2.1 </span>Provenance in Dublin Core</a></li><li class="tocline"><a class="tocxref" href="#entities-in-dublin-core"><span class="secno">2.2 </span>Entities in Dublin Core</a></li></ul></li><li class="tocline"><a class="tocxref" href="#mapping-from-dublin-core-to-prov"><span class="secno">3. </span>Mapping from Dublin Core to PROV</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#direct-mappings"><span class="secno">3.1 </span>Direct mappings</a></li><li class="tocline"><a class="tocxref" href="#prov-refinements"><span class="secno">3.2 </span>PROV refinements</a></li><li class="tocline"><a class="tocxref" href="#complex-mappings"><span class="secno">3.3 </span>Complex Mappings</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#entity-agent-mappings-who"><span class="secno">3.3.1 </span>Entity-Agent mappings (Who)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#dct-creator"><span class="secno">3.3.1.1 </span> dct:creator</a></li><li class="tocline"><a class="tocxref" href="#dct-contributor"><span class="secno">3.3.1.2 </span>dct:contributor</a></li><li class="tocline"><a class="tocxref" href="#dct-publisher"><span class="secno">3.3.1.3 </span>dct:publisher</a></li><li class="tocline"><a class="tocxref" href="#dct-rightsHolder"><span class="secno">3.3.1.4 </span>dct:rightsHolder</a></li></ul></li><li class="tocline"><a class="tocxref" href="#entity-date-mappings-when"><span class="secno">3.3.2 </span>Entity-Date mappings (When)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#term_date"><span class="secno">3.3.2.1 </span>dct:date</a></li><li class="tocline"><a class="tocxref" href="#dct-created"><span class="secno">3.3.2.2 </span>dct:created</a></li><li class="tocline"><a class="tocxref" href="#dct-issued"><span class="secno">3.3.2.3 </span>dct:issued</a></li><li class="tocline"><a class="tocxref" href="#dct-modified"><span class="secno">3.3.2.4 </span>dct:modified</a></li><li class="tocline"><a class="tocxref" href="#dct-dateaccepted"><span class="secno">3.3.2.5 </span>dct:dateAccepted</a></li><li class="tocline"><a class="tocxref" href="#dct-datecopyrighted"><span class="secno">3.3.2.6 </span>dct:dateCopyrighted</a></li><li class="tocline"><a class="tocxref" href="#dct-datesubmitted"><span class="secno">3.3.2.7 </span>dct:dateSubmitted</a></li></ul></li><li class="tocline"><a class="tocxref" href="#entity-entity-mappings-how"><span class="secno">3.3.3 </span>Entity-Entity mappings (How)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#dct-replaces"><span class="secno">3.3.3.1 </span>dct:replaces</a></li></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#cleanup"><span class="secno">3.4 </span>Cleanup</a></li><li class="tocline"><a class="tocxref" href="#list-of-terms-excluded-from-the-mapping"><span class="secno">3.5 </span>List of terms excluded from the mapping</a></li><li class="tocline"><a class="tocxref" href="#mapping-from-prov-to-dc"><span class="secno">3.6 </span>Mapping from PROV to DC</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#changes-since-second-public-working-draft"><span class="secno">B. </span>Changes Since Second Public Working Draft</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">C.1 </span>Informative references</a></li></ul></li></ul></section> <section id="introduction"> <h2><span class="secno">1. </span>Introduction</h2> <p> The Dublin Core Metadata Initiative (DCMI) [<cite><a href="#bib-DCMI" class="bibref">DCMI</a></cite>] provides a core metadata vocabulary (commonly referred to as Dublin Core) for simple and generic resource descriptions [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>]. The original Dublin Core Metadata Element Set was created in 1995 and contains fifteen broadly defined properties that are still in use. Properties identified using the original namespace URI <a href="http://purl.org/dc/elements/1.1/">http://purl.org/dc/elements/1.1/</a> have no specified ranges, meaning that arbitrary values can be used as objects. In order to assign ranges, DCMI replicated the fifteen properties using the namespace URI <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a>. Additional properties and classes beyond the original fifteen were coined using this namespace URI. In this document, properties and classes using the /terms/ namespace URI are referred to, simply, as DC Terms. </p> <p> This document defines a mapping between the DC Terms and the PROV Ontology (PROV-O) [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>], which defines an OWL2 Ontology encoding the PROV Data Model [<cite><a href="#bib-PROV-DM" class="bibref">PROV-DM</a></cite>]. The PROV vocabulary and data model are focused on expressing actions and resource states in a provenance chain rather than on describing resources in a general sense. The Dublin Core vocabulary is focused on describing resources in a general sense, but a substantial number of terms in the vocabulary provide information related to the provenance of the resource. Mapping statements using Dublin Core into statements using PROV makes the contained provenance information explicit. This mapping has been designed for several purposes: </p>  <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 DC data</b> available on the web, improving interoperability between DC and PROV applications.</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> <p> </p><section id="namespaces-1"> <h3 id="namespaces"><span class="secno">1.1 </span>Namespaces URIs</h3> <p>The namespace URIs used in this document can be seen in <a href="#ns"> Table 1</a>: </p><div id="ns" > <table style="margin-left: auto; margin-right: auto;"> <caption> <a href="#ns"> Table 1</a>: Namespaces URIs used in the document </caption> <tbody> <tr><td><b>prefix</b></td><td><b>Namespace IRI</b></td><td><b>Used for</b></td></tr> <tr><td>owl</td><td><http://www.w3.org/2002/07/owl#></td><td>The OWL vocabulary [<cite><a href="#bib-OWL2-OVERVIEW" class="bibref">OWL2-OVERVIEW</a></cite>].</td></tr> <tr><td>rdfs</td><td><http://www.w3.org/2000/01/rdf-schema#></td><td>The RDFS vocabulary[<cite><a href="#bib-RDFS" class="bibref">RDFS</a></cite>].</td></tr> <tr><td>prov</td><td><http://www.w3.org/ns/prov#></td><td>The PROV vocabulary [<cite><a href="#bib-PROV-DM" class="bibref">PROV-DM</a></cite>].</td></tr> <tr><td>dct</td><td><http://purl.org/dc/terms/></td><td>The DCMI /terms/ vocabulary [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>].</td></tr>  <tr><td>ex</td><td><http://example.org></td><td>Application-dependent URIs. Used in the examples of the document.</td></tr> </tbody> </table> </div> <p></p> </section> <section id="structure-of-this-document"> <h3><span class="secno">1.2 </span>Structure of this document</h3> <p> <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 DC, along with several examples (<a href="#entities-in-dublin-core">Section 2.2</a>).</li> </ul> <p></p> <p> <a href="#mapping-from-dublin-core-to-prov">Section 3</a> 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: </p><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 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. </li> <li><a href="#complex-mappings">Section 3.3</a> defines <b>complex mappings</b>. These mappings make use of the refinements introduced in <a href="#prov-refinements">Section 3.2</a> and combine them in order to derive an enhanced provenance chain.  </li> <li>Due to the way in which the complex mappings are defined, blank nodes are produced for each DC statement. <a href="#cleanup">Section 3.4</a> introduces some strategies on how to reduce the amount of blank nodes. </li> <li><a href="#list-of-terms-excluded-from-the-mapping">Section 3.5</a>, on the other hand, describes the rationale for the terms left out of the mapping. Some terms may imply a mapping (e.g., <code>dct:alternative</code> is similar to <code>prov:alternateOf</code>), but do not in fact correspond. Other terms summarize the resolution of the community discussion with examples. </li> <li>Finally, <a href="#mapping-from-prov-to-dc">Section 3.6</a> adds some details about the inverse mapping (PROV to DC), which is out of the scope of this document. </li> </ul> <p></p> </section> </section> <section id="preliminaries"> <h2><span class="secno">2. </span>Preliminaries</h2> <p> 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 to provenance.</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"> <h3><span class="secno">2.1 </span>Provenance in Dublin Core</h3> <p> Many DC terms can be used to describe provenance information about a resource: <i>when</i> it was affected in the past, <i>who</i> affected it and <i>how</i> it was affected. The rest of the DCMI terms (description metadata), tell us <i>what</i> was affected. <a href="#categories-props">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 DC describing <i>where</i> a resource was affected. The categories are further explained below: </p>  <p> <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> <b>Agency Terms (Who?):</b> This category contains agent related terms. All properties have <code>dct:Agent</code> as range, i.e., a resource that acts or has the power to act. The <code>dct:contributor</code>, <code>dct:creator</code>, and <code>dct:publisher</code> clearly influence the resource and therefore are important for its origin. This is not immediately clear for the <code>dct:rightsHolder</code>, but as ownership is considered to be 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. 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 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. </p>  <p> <b>Derivation and Licensing 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 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 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 (<code>dct:license</code>), rights (<code>dct:rights</code>) and their access (<code>dct:accessRights</code>) 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. </p> <div id="categories-props" > <table style="margin-left: auto; margin-right: auto;"> <caption> <a href="#categories-props"> Table 2:</a> Categorization of the DC Terms (properties) </caption> <tbody> <tr> <th>Category</th> <th>Sub-category</th> <th>Terms</th> </tr> <tr> <td><b>Descriptive metadata</b></td> <td>What</td> <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>, <a href="#term_educationLevel">educationLevel</a>, <a href="#term_extent">extent</a>, <a href="#term_format">format</a>, <a href="#term_hasPart"> hasPart</a>, <a href="#term_isPartOf">isPartOf</a>, <a href="#term_identifier">identifier</a>, <a href="#term_instructionalMethod">instructionalMethod</a>, <a href="#term_isRequiredBy">isRequiredBy</a>, <a href="#term_language">language</a>, <a href="#term_mediator">mediator</a>, <a href="#term_medium">medium</a>, <a href="#term_relation">relation</a>, <a href="#term_requires">requires</a>, <a href="#term_spatial">spatial</a>, <a href="#term_subject">subject</a>, <a href="#term_tableOfContents">tableOfContents</a>, <a href="#term_temporal">temporal</a>, <a href="#term_title">title</a>, <a href="#term_type">type</a></td> </tr> <tr> <td><b>Provenance</b></td> <td>Who</td> <td><a href="#term_contributor">contributor</a>, <a href="#term_creator">creator</a>, <a href="#term_publisher">publisher</a>, <a href="#term_rightsHolder">rightsHolder</a></td> </tr> <tr> <td><b>Provenance</b></td> <td>When</td> <td><a href="#term_available">available</a>, <a href="#term_created">created</a>, <a href="#term_date">date</a>, <a href="#term_dateAccepted">dateAccepted</a>, <a href="#term_dateCopyrighted">dateCopyrighted</a>, <a href="#term_dateSubmitted">dateSubmitted</a>, <a href="#term_issued">issued</a>, <a href="#term_modified">modified</a>, <a href="#term_valid">valid</a></td> </tr> <tr> <td><b>Provenance</b></td> <td>How</td> <td><a href="#term_accessRights">accessRights</a>, <a href="#term_has_Format">hasFormat</a>, <a href="#term_hasVersion">hasVersion</a>, <a href="#term_isFormatOf">isFormatOf</a>, <a href="#term_isVersionOf">isVersionOf</a>, <a href="#term_license">license</a>, <a href="#term_isReferencedBy">isReferencedBy</a>, <a href="#term_replaces">isReplacedBy</a>, <a href="#term_references">references</a>, <a href="#term_replaces">replaces</a>, <a href="#term_rights">rights</a>, <a href="#term_source">source</a></td> </tr> </tbody> </table> </div> <p> This leaves one very special term: <a href="#term_provenance">provenance</a>. 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" [<cite><a href="#bib-DCTERMS" class="bibref">DCTERMS</a></cite>], 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 is not included in any of the aforementioned categories. </p> <p> Regarding the classes in DC terms, most of them can be seen as subclasses of <code>prov:Entities</code> (with some exceptions like <code>dct:Agent</code> or <code>dct:ProvenanceStatement</code>). In general, these classes represent types of resources or metadata that can be described with the properties shown in <a href="#categories-props">Table 2</a>, thus most of them are included in the "Descriptive Metadata" category. Although the usage of these classes is reduced when compared to the adoption of the DC term properties, we have also included them as part of the mapping. DCMI Type Vocabulary terms have been excluded from the mapping, as they are not part of the core vocabulary (using a different namespace URI: <a href="http://purl.org/dc/dcmitype/">http://purl.org/dc/dcmitype/</a>). A list of the classes can be seen in <a href="#categories-classes">Table 3</a>.  </p> <div id="categories-classes" > <table style="margin-left: auto; margin-right: auto;"> <caption> <a href="#categories-classes"> Table 3:</a> Categorization of the DC Terms (Classes) </caption> <tbody> <tr> <th>Category</th> <th>Terms</th> </tr> <tr> <td><b>Descriptive metadata</b></td> <td> <a href="#term_AgentClass">AgentClass</a>, <a href="#term_BibliographicResource">BibliographicResource</a>, <a href="#term_FileFormat">FileFormat</a>, <a href="#term_Frequency">Frequency</a>, <a href="#term_Jurisdiction">Jurisdiction</a>, <a href="#term_LicenseDocument">LicenseDocument</a>, <a href="#term_LinguisticSystem">LinguisticSystem</a>, <a href="#term_Location">Location</a>, <a href="#term_LocationPeriodOrJurisdiction">LocationPeriodOrJurisdiction</a>, <a href="#term_MediaType">MediaType</a>, <a href="#term_MediaTypeOrExtent">MediaTypeOrExtent</a>, <a href="#term_MethodOfAccrual">MethodOfAccrual</a>, <a href="#term_MethodOfInstruction">MethodOfInstruction</a>, <a href="#term_PeriodOfTime">PeriodOfTime</a>, <a href="#term_PhysicalMedium">PhysicalMedium</a>, <a href="#term_PhysicalResource">PhysicalResource</a>, <a href="#term_Policy">Policy</a>, <a href="#term_ProvenanceStatement">ProvenanceStatement</a>, <a href="#term_RightsStatement">RightsStatement</a>, <a href="#term_SizeOrDuration">SizeOrDuration</a>, <a href="#term_Standard">Standard</a>. </td> </tr> <tr> <td><b>Provenance (Who)</b></td> <td><a href="#term_Agent">Agent</a></td> </tr> </tbody> </table> </div>  </section> <section id="entities-in-dublin-core"> <h3><span class="secno">2.2 </span>Entities in Dublin Core</h3> <p> Consider the example metadata record below (<a href="#example1">Example 1</a>), where a document (<code>ex:prov-dc-20130312</code>) is described with several DC statements: </p> <p> <a href="#example1" id="example1">Example 1</a>: a simple metadata record in Turtle format [<cite><a href="#bib-TURTLE" class="bibref">Turtle</a></cite>]: </p><div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example"> ex:prov-dc-20130312 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:prov-dc-20121211; dct:format "HTML". </pre></div> In <a href="#example1">Example 1</a>, <code>dct:title</code>, <code>dct:subject</code> and <code>dct:format</code> are <i>descriptions</i> of the resource <code>ex:prov-dc-20130312</code>. They do not provide any information on how the resource was created or modified in the past. On the other hand, some statements imply provenance-related information. For example <code>dct:creator</code> implies that the document has been created and refers to an author. Similarly, the existence of the <code>dct:issued</code> date implies that the document has been published. This information is redundantly implied by the <code>dct:publisher</code> statement as well. Finally, <code>dct:replaces</code> relates <code>ex:prov-dc-20130312</code> to the document <code>ex:prov-dc-20121211</code>, a previous resource representing the mapping. <p></p> As a DC metadata record describes the document as a whole, it is not clear how this document relates to the different stages the document underwent 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: <i>before</i> and <i>after</i> publication. Each of these states correspond to a different <code>prov:specializationOf</code> of the document. Generally, there are two approaches to deal with this issue:<p></p> <p></p> <p> 1) Create new instances of entities that are all related to the original document by means of <code>prov:specializationOf</code>. 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:specializationOf</code> the resource we are describing), and generated the published resource (<code>:_resultingEntity</code>). <code>:_resultingEntity</code> is also a <code>prov:specializationOf</code> the resource <code>ex:prov-dc-20130312</code>, as it describes the document after a particular publication. </p><p> </p><div id="figure_mapping_example" style="text-align: center;"> <img src="img/example1.svg" alt="A mapping example creating blank nodes for each state of the resource"> <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 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). </div> </div> <p></p><p> 2) Adopt the original resource (<code>ex:prov-dc-20130312</code>) as the <code>prov:Entity</code> used and then generated by the Publish activity (<code>:_activity</code>). However, this representation leads to a misinterpretation of the DC statement, as shown in the example of <a href="#figure_mapping_example_conflating">Figure 2</a>. The representation implies that <code>ex:prov-dc-20130312</code> was generated by <code>_:activity</code> and then used by <code>_:activity</code> afterwards, instead of being used and then being generated by <code>_:activity</code> (PROV entities must exist before being used). </p><p> </p><div id="figure_mapping_example_conflating" style="text-align: center;"> <img src="img/mapping-example-conflating.svg" alt="A mapping example conflating blank nodes within the same resource"> <div style="text-align: center;"> <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.  </div> </div> <p></p><p> 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 <a href="#cleanup">cleanup phase</a>. </p> </section> </section> <section id="mapping-from-dublin-core-to-prov"> <h2><span class="secno">3. </span>Mapping from Dublin Core to PROV</h2> <p> 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 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 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 DC (out of the scope of this mapping).</li> </ul> <p></p> <section id="direct-mappings"> <h3><span class="secno">3.1 </span>Direct mappings</h3> <p> The direct mappings [<cite><a href="#bib-mapping" class="bibref">PROV-DC-DIRECT-MAPPINGS</a></cite>] 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 (i.e., they will be able to understand DC statements) by applying OWL 2 RL reasoning. </p> <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> <p> <a href="#list_of_direct_terms_props">Table 4</a>, <a href="#list_of_direct_terms_classes">Table 5</a>, <a href="#list_of_direct_mappings2_props">Table 6</a> and <a href="#list_of_direct_mappings2_classes">Table 7</a> provide the detailed mapping of the properties and classes in DC plus the rationale for each term. The rest of the terms can be found in the <a href="#list-of-terms-excluded-from-the-mapping">list of terms left out of the mapping</a> section. </p> <div id="list_of_direct_terms_props" > <table style="margin-left: auto; margin-right: auto;"> <caption> <a href="#list_of_direct_terms_props"> Table 4:</a> Direct mappings (Properties) </caption> <tbody> <tr> <th>DC Term</th> <th>Relation</th> <th>PROV Term</th> <th>Rationale</th> </tr> <tr> <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="https://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 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.). </td> </tr> <tr> <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="https://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. They have the attribution for the outcome of that activity.</td> </tr> <tr> <td><b id="term_contributor"><a href="http://purl.org/dc/terms/contributor">dct:contributor</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td> <td>A contributor is associated with either the creation activity or the updating of the resource. Therefore, he/she has attribution over the outcome of those activities.</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="https://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></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="https://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td> <td>Property used to describe the date when the resource was copyrighted. <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="https://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></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_has_Format"><a href="http://purl.org/dc/terms/hasFormat">dct:hasFormat</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#alternateOf">prov:alternateOf</a></td> <td> See rationale for <a href="#term_isFormatOf"><code>dct:isFormatOf</code></a> (as <code>prov:alternateOf</code>).</td> </tr> <tr> <td><b id="term_isFormatOf"><a href="http://purl.org/dc/terms/isFormatOf">dct:isFormatOf</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#alternateOf">prov:alternateOf</a></td> <td><code>dct:isFormatOf</code> refers to another resource which is the same but in another format. Thus, the term is mapped to <code>prov:alternateOf</code>.</td> </tr> <tr> <td><b><a href="http://purl.org/dc/terms/isFormatOf">dct:isFormatOf</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></td> <td><code>dct:isFormatOf</code> refers to another "pre-existing" resource which is the same but in another format (according to <a href="http://purl.org/dc/terms/hasFormat"><code>cdt:hasFormat</code></a>), implying that the new resource is based on the former.</td> </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="https://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> </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="https://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></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> <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="https://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> </tr>  <tr> <td><b id="term_references"><a href="http://purl.org/dc/terms/references">dct:references</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></td> <td>In PROV, a derivation is defined as "a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-existing entity". If a resource n1 references another resource o1 then the construction of n1 is based on o1, even if o1 does not influence n1 significantly. Removing the reference to o1 in n1 would lead to the construction of another resource n1', different from n1.</td> </tr> <tr> <td><b id="term_rightsHolder"><a href="http://purl.org/dc/terms/rightsHolder">dct:rightsHolder</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td> <td>The rights holder has the attribution of the license associated to a resource. Thus, we can say that the resource is attributed in part to the rights holder.</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="https://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></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"). However, <code>prov:wasDerivedFrom</code> also covers broader derivations such as "an update of an entity resulting in a new one" which is not covered by dct:source.</td> </tr> </tbody> </table> </div> <div id="list_of_direct_terms_classes" > <table style="margin-left: auto; margin-right: auto;"> <caption> <a href="#list_of_direct_terms_classes"> Table 5:</a> Direct mappings (Classes) </caption> <tbody> <tr> <th>DC Term</th> <th>Relation</th> <th>PROV Term</th> <th>Rationale</th> </tr> <tr> <td><b id="term_Agent"><a href="http://purl.org/dc/terms/Agent">dct:Agent</a></b></td> <td>owl:equivalentClass</td> <td><a href="https://www.w3.org/TR/prov-o/#Agent">prov:Agent</a></td> <td>Both <code>dct:Agent</code> and <code>prov:Agent</code> refer to the same concept: a resource that has the power to act (which then has responsibility for an activity, entity or other agent).</td> </tr> <tr> <td> <b id="term_BibliographicResource"><a href="http://purl.org/dc/terms/BibliographicResource">dct:BibliographicResource</a></b> </td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Entity">prov:Entity</a></td> <td>A bibliographic resource refers to books, articles, etc., which are concrete PROV entities.</td> </tr> <tr> <td> <b id="term_LicenseDocument"><a href="http://purl.org/dc/terms/LicenseDocument">dct:LicenseDocument</a></b> </td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Entity">prov:Entity</a></td> <td>Document granting permission to do something regarding a resource. Thus, it is mapped as a type of <code>prov:Entity</code>.</td> </tr> <tr> <td><b id="term_LinguisticSystem"><a href="http://purl.org/dc/terms/LinguisticSystem">dct:LinguisticSystem</a></b></td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Plan">prov:Plan</a></td> <td>A <code>dct:LinguisticSystem</code> is a system of symbols, sounds, gestures, etc. used in communication. Therefore, the linguistic system defines the plan to follow in order to learn a certain language. </td> </tr> <tr> <td><b id="term_Location"><a href="http://purl.org/dc/terms/Location">dct:Location</a></b></td> <td>owl:equivalentClass</td> <td><a href="https://www.w3.org/TR/prov-o/#Location">prov:Location</a></td> <td>Both <code>dct:Location</code> and <code>prov:Location</code> define locations as "spatial regions or named places".</td> </tr> <tr> <td> <b id="term_MethodOfAccrual"><a href="http://purl.org/dc/terms/MethodOfAccrual">dct:MethodOfAccrual</a></b> </td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Plan">prov:Plan</a></td> <td><code>dct:MethodOfAccrual</code> defines the method by which items are added to a collection (i.e., the <code>prov:Plan</code> followed in the insertion activity). </td> </tr> <tr> <td> <b id="term_MethodOfInstruction"><a href="http://purl.org/dc/terms/MethodOfInstruction">dct:MethodOfInstruction</a></b> </td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Plan">prov:Plan</a></td> <td>"Process that is used to engender knowledge, attitude and skills". Since <code>dct:MethodOfInstruction</code> defines the method associated to an activity, it is mapped as a subClass of <code>prov:Plan</code>. </td> </tr> <tr> <td> <b id="term_RightsStatement"><a href="http://purl.org/dc/terms/RightsStatement">dct:RightsStatement</a></b> </td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Entity">prov:Entity</a></td> <td>Statement about the intellectual rights of a resource (e.g., a Document). Thus, it is mapped as a type of <code>prov:Entity</code>. </td> </tr> <tr> <td> <b id="term_PhysicalResource"><a href="http://purl.org/dc/terms/PhysicalResource">dct:PhysicalResource</a></b>  </td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Entity">prov:Entity</a></td> <td>A material thing, which is a concrete type of <code>prov:Entity</code>.</td> </tr> <tr> <td> <b id="term_Policy"><a href="http://purl.org/dc/terms/Policy">dct:Policy</a></b> </td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Plan">prov:Plan</a></td> <td><code>dct:Policy</code> is defined as "a plan or course of action by an authority, intended to influence and determine decisions, actions, and other matters." This is a specialization of <code>prov:Plan</code>. </td> </tr> <tr> <td><b id="term_ProvenanceStatement"><a href="http://purl.org/dc/terms/ProvenanceStatement">dct:ProvenanceStatement</a></b></td> <td>rdfs:subClassOf</td> <td><a href="https://www.w3.org/TR/prov-o/#Bundle">prov:Bundle</a></td> <td>A <code>dct:ProvenanceStatement</code> is defined as "A statement of any changes in ownership and custody of a resource since its creation", which is a container for any provenance related assertion.</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 (<code>ex:prov-dc-20130312</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. DC, on the other hand, groups those two intermediate entities under the same resource (<code>ex:prov-dc-20130312</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, two properties (<code>dct:source</code> and <code>isVersionOf</code>) and a class (<code>dct:LocationPeriodOrJurisdiction</code>) have been found to be superproperties and superclass of a PROV concept, represented in <a href="#list_of_direct_mappings2_props">Table 6</a> and <a href="#list_of_direct_mappings2_classes">Table 7</a>:  </p>  <div id="list_of_direct_mappings2_props"> <table> <caption> <a href="#list_of_direct_mappings2_props"> Table 6:</a> Direct mappings (Properties generalizing PROV terms)</caption> <tbody> <tr> <th>PROV Term</th> <th>Relation</th> <th>DC Term</th> <th>Rationale</th> </tr> <tr> <td><a href="https://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 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> <td id="term_isVersionOf"><a href="https://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 a revised version of a resource, while <code>dct:isVersionOf</code> involves versions, editions or adaptations of the original resource. As an example, "West Side Story" is a version (adaptation) of "Romeo and Juliet", but not a revision.</td> </tr> </tbody> </table> </div> <div id="list_of_direct_mappings2_classes"> <table> <caption> <a href="#list_of_direct_mappings2_classes"> Table 7:</a> Direct mappings (Classes generalizing PROV terms)</caption> <tbody> <tr> <th>PROV Term</th> <th>Relation</th> <th>DC Term</th> <th>Rationale</th> </tr> <tr> <td><a href="https://www.w3.org/TR/prov-o/#Location">prov:Location</a></td> <td>rdfs:subClassOf</td> <td><b id="term_LocationPeriodOrJurisdiction"><a href="http://purl.org/dc/terms/LocationPeriodOrJurisdiction">dct:LocationPeriodOrJurisdiction</a></b></td> <td><code>dct:LocationPeriodOrJurisdiction</code> is a superclass of <code>dct:Location</code> (equivalent to <code>prov:Location</code>).</td> </tr> </tbody> </table> </div> <p> <a href="#list_of_direct_mappings_no_prov_core">Table 8</a> enumerates the mapping of the DC terms to the PROV terms that do not belong to the core of PROV. </p> <div id="list_of_direct_mappings_no_prov_core"> <table style="margin-left: auto; margin-right: auto;"> <caption> <a href="#list_of_direct_mappings_no_prov_core"> Table 8:</a> Direct mappings to the PROV terms not included in the core </caption> <tbody> <tr> <th>DC Term</th> <th>Relation</th> <th>PROV Term</th> <th>Rationale</th> </tr> <tr> <td><b><a href="http://purl.org/dc/terms/hasFormat">dct:hasFormat</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#inverse-names-table">prov:hadDerivation</a></td> <td>Inverse property of <code>dct:isFormatOf</code>.</td> </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><a href="https://www.w3.org/TR/prov-o/#inverse-names-table">prov:hadRevision</a></td> <td>Inverse property of <code>dct:isVersionOf</code>.</td> </tr> <tr> <td><b id="term_isReferencedBy"><a href="http://purl.org/dc/terms/isReferencedBy">dct:isReferencedBy</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-o/#inverse-names-table">prov:hadDerivation</a></td> <td>Inverse property of <code>dct:references</code>.</td> </tr> <tr> <td><b id="term_provenance"><a href="http://purl.org/dc/terms/provenance">dct:provenance</a></b></td> <td>rdfs:subPropertyOf</td> <td><a href="https://www.w3.org/TR/prov-aq/#resource-accessed-by-http">prov:has_provenance</a></td> <td>Property used to link a resource to its corresponding <code>dct:ProvenanceStatement</code>. Since <code>prov:has_provenance</code> can refer to any type of provenance record, <code>dct:provenance</code> is mapped as a subclass.</td> </tr> </tbody> </table> </div> </section> <section id="prov-refinements"> <h3><span class="secno">3.2 </span>PROV refinements</h3> <p> In order to produce complex mappings for the DC terms, we need specific subclasses extending the PROV ontology [<cite><a href="#bib-PROV-O" class="bibref">PROV-O</a></cite>]. 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 DC can be seen below: </p><pre class="code"> prov:Publish rdfs:subClassOf prov:Activity. prov:Contribute rdfs:subClassOf prov:Activity. prov:Create rdfs:subClassOf prov:Activity, prov:Contribute. prov:RightsAssignment rdfs:subClassOf prov:Activity. 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. prov:RightsHolder rdfs:subClassOf prov:Role. </pre>  </section> <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 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 resulting RDF graph based on another RDF graph found in the original data. We divide the queries into different categories: </p> <section id="entity-agent-mappings-who"> <h4><span class="secno">3.3.1 </span>Entity-Agent mappings (Who)</h4> <p> In this category, we have three terms: <code>dct:contributor</code>, <code>dct:creator</code> and <code>dct:publisher</code>. The three of them can be mapped with the same pattern, similar to the one presented in <a href="#figure_mapping_example">Figure 1</a>. The only changes required are the roles and activities involved for each term. </p><p> In the text below, variables <code>?document</code> and <code>?agent</code> are set to different matching values depending 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 for each term encodes a similar graph to the one presented in <a href="#figure_mapping_example">Figure 1</a> (with small changes for <code>dct:creator</code> and <code>dct:rightsHolder</code>). 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.  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. </p> <section id="dct-creator"> <h5><span class="secno">3.3.1.1 </span> dct:creator</h5> A creator is the agent in charge of the <code>prov:Create</code> activity that generated a specialization of the entity <code>?document</code>. The agent is assigned the role <code>prov:Creator</code>. <pre class="code"> 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 [a prov:Creator]. ]. _:resultingEntity a prov:Entity; prov:specializationOf ?document; prov:wasGeneratedBy _:activity; prov:wasAttributedTo ?agent. } WHERE { ?document dct:creator ?agent. } </pre> </section> <section id="dct-contributor"> <h5><span class="secno">3.3.1.2 </span>dct:contributor</h5> Contributor is mapped following the previous pattern. Only the roles and activities change: <pre class="code"> 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 [a prov:Contributor]. ]. _:resultingEntity a prov:Entity; prov:specializationOf ?document; prov:wasGeneratedBy _:activity; prov:wasAttributedTo ?agent. } WHERE { ?document dct:contributor ?agent. } </pre> </section> <section id="dct-publisher"> <h5><span class="secno">3.3.1.3 </span>dct:publisher</h5> In case of publication, a second specialization representing the entity before the publication is necessary: <pre class="code"> CONSTRUCT { ?document a prov:Entity; prov:wasAttributedTo ?agent. ?agent a prov:Agent. _:usedEntity a prov:Entity; prov:specializationOf ?document. _:activity a prov:Activity, prov:Publish; prov:used _:usedEntity; prov:wasAssociatedWith ?agent; prov:qualifiedAssociation [ a prov:Association; prov:agent ?agent; prov:hadRole [a prov:Publisher]. ]. _:resultingEntity a prov:Entity; prov:specializationOf ?document; prov:wasDerivedFrom _:usedEntity prov:wasGeneratedBy _:activity; prov:wasAttributedTo ?agent. } WHERE { ?document dct:publisher ?agent. } </pre> <p></p> </section> <section id="dct-rightsHolder"> <h5><span class="secno">3.3.1.4 </span>dct:rightsHolder</h5> The rightsHolder manages the rights of a resource, getting some attribution for the ownership by being ascribed to it: <pre class="code"> CONSTRUCT { ?document a prov:Entity; prov:wasAttributedTo ?agent. ?agent a prov:Agent. _:oldRightsEntity a prov:Entity; prov:specializationOf ?document. _:activity a prov:Activity, prov:RightsAssignment; prov:used _:oldRightsEntity; prov:wasAssociatedWith ?agent; prov:qualifiedAssociation [ a prov:Association; prov:agent ?agent; prov:hadRole [a prov:RightsHolder]. ]. _:newRightsEntity a prov:Entity; prov:specializationOf ?document; prov:wasDerivedFrom _:oldRightsEntity prov:wasGeneratedBy _:activity; prov:wasAttributedTo ?agent. } WHERE { ?document dct:rightsHolder ?agent. } </pre> <p></p> </section> </section> <section id="entity-date-mappings-when"> <h4><span class="secno">3.3.2 </span>Entity-Date mappings (When)</h4> <p> Dates often correspond with a who-property. For example, date created implies a creator and date issued implies a publisher. Therefore, they lead to similar complex patterns (associating a date to each activity instead of an agent). 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 of literals with the datatype <code>xsd:dateTime</code>, the mapping is only valid for those literals that have the datatype <code>xsd:dateTime</code>. </p> <section id="term_date"> <h5><span class="secno">3.3.2.1 </span> dct:date</h5> <p><code>dct:date</code> is a term defined as a point or period of time associated with an event in the lifecycle of the resource.</p> <pre class="code"> CONSTRUCT{ _:event a prov:InstantaneousEvent; prov:atTime ?date. } WHERE { ?document dct:date ?date. } </pre> Note that the above inference would not generally be considered useful due to the ambiguity of <code>dct:date</code> (we don't know how the entity is related to the event), however the above mapping is included here for completeness. </section> <section id="dct-created"> <h5><span class="secno">3.3.2.2 </span> dct:created</h5> <p>As stated in <a href="#entity-date-mappings-when">Section 3.3.2</a>, <code>dct:created</code> is mapped to PROV thusly:</p> <pre class="code"> CONSTRUCT{ ?document a prov:Entity. _:activity a prov:Activity, prov:Create; # The “output” _:createdEntity 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. } </pre> </section> <section id="dct-issued"> <h5><span class="secno">3.3.2.3 </span>dct:issued</h5> <p>As stated in <a href="#entity-date-mappings-when">Section 3.3.2</a>, <code>dct:issued</code> is mapped to PROV thusly:</p> <pre class="code"> CONSTRUCT{ ?document a prov:Entity. _:activity a prov:Activity, prov:Publish; prov:used _:usedEntity. # The “input” _:usedEntity a prov:Entity. prov:specializationOf ?document. # The “output” _:issEntity a prov:Entity; prov:specializationOf ?document; prov:wasGeneratedBy _:activity; prov:wasGeneratedAtTime ?date; prov:wasDerivedFrom _:usedEntity; prov:qualifiedGeneration [ a prov:Generation; prov:atTime ?date; prov:activity _:activity. ]. } WHERE { ?document dct:issued ?date. } </pre> <p></p> </section> <section id="dct-modified"> <h5><span class="secno">3.3.2.4 </span>dct:modified</h5> <p>As stated in <a href="#entity-date-mappings-when">Section 3.3.2</a>, <code>dct:modified</code> is mapped to PROV thusly:</p> <pre class="code"> CONSTRUCT{ ?document a prov:Entity. _:activity a prov:Activity, prov:Modify; prov:used _:usedEntity. # The “input” _:usedEntity a prov:Entity. prov:specializationOf ?document. # The “output” _:modifiedEntity a prov:Entity; prov:specializationOf ?document; prov:wasGeneratedBy _:activity; prov:wasGeneratedAtTime ?date; prov:wasDerivedFrom _:usedEntity; prov:qualifiedGeneration [ a prov:Generation; prov:atTime ?date; prov:activity _:activity. ]. } WHERE { ?document dct:modified ?date. } </pre> <p></p> </section> <section id="dct-dateaccepted"> <h5><span class="secno">3.3.2.5 </span>dct:dateAccepted</h5> <p>As stated in <a href="#entity-date-mappings-when">Section 3.3.2</a>, <code>dct:dateAccepted</code> is mapped to PROV thusly:</p> <pre class="code"> CONSTRUCT{ ?document a prov:Entity. _:activity a prov:Activity, prov:Accept; prov:used _:usedEntity. # The “input” _:usedEntity a prov:Entity. prov:specializationOf ?document. # The “output” _:acceptedEntity a prov:Entity; prov:specializationOf ?document; prov:wasGeneratedBy _:activity; prov:wasGeneratedAtTime ?date; prov:wasDerivedFrom _:usedEntity; prov:qualifiedGeneration [ a prov:Generation; prov:atTime ?date; prov:activity _:activity. ]. } WHERE { ?document dct:dateAccepted ?date. } </pre> <p></p> </section> <section id="dct-datecopyrighted"> <h5><span class="secno">3.3.2.6 </span>dct:dateCopyrighted</h5> By creating a resource we gain automatic copyright over it, so <code>_:usedEntity</code> is not required in this complex mapping. <p></p><pre class="code"> CONSTRUCT{ ?document a prov:Entity. _:activity a prov:Activity, prov:Copyright; # The “output” _:copyrightedEntity 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:dateCopyrighted ?date. }</pre> </section> <section id="dct-datesubmitted"> <h5><span class="secno">3.3.2.7 </span>dct:dateSubmitted</h5> <p>As stated in <a href="#entity-date-mappings-when">Section 3.3.2</a>, <code>dct:dateSubmitted</code> is mapped to PROV thusly:</p> <pre class="code"> CONSTRUCT{ ?document a prov:Entity. _:activity a prov:Activity, prov:Submit; prov:used _:usedEntity. # The “input” _:usedEntity a prov:Entity. prov:specializationOf ?document. # The “output” _:submittedEntity a prov:Entity; prov:specializationOf ?document; prov:wasGeneratedBy _:activity; prov:wasGeneratedAtTime ?date; prov:wasDerivedFrom _:usedEntity; prov:qualifiedGeneration [ a prov:Generation; prov:atTime ?date; prov:activity _:activity. ]. } WHERE { ?document dct:dateSubmitted ?date. } </pre> <p></p> </section> </section> <section id="entity-entity-mappings-how"> <h4><span class="secno">3.3.3 </span>Entity-Entity mappings (How)</h4> <p> 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. </p> <section id="dct-replaces"> <h5 id="term_replaces"><span class="secno">3.3.3.1 </span>dct:replaces</h5> <p> There is a relation between two resources when the former replaces or displaces the latter. However, we can't always assume the replacement is derived from the former resource, because the replacement could have existed and been generated independently from the original (for example, if a catalog replaces a book entitled "Introduction to provenance" with one entitled "Provenance in a nutshell). Therefore the "replace" Activity uses a specialization of the replaced entity (<code>_:oldEntity</code>) and generated a specialization of the replacement (<code>_:newEntity</code>). These specializations model the aspect of the resource which is the subject of replacement, thus, <code>_:newEntity</code> was derived from <code>_:oldEntity</code>. </p> <p> </p><pre class="code"> CONSTRUCT{ ?document a prov:Entity. ?document2 a prov:Entity. _:activity a prov:Activity, prov:Replace; prov:used _:oldEntity. # The “input” _:oldEntity a prov:Entity; prov:specializationOf ?document2; # The “output” _:newEntity a prov:Entity; prov:specializationOf ?document; prov:wasGeneratedBy _:activity; prov:wasDerivedFrom _:oldEntity; prov:alternateOf _:oldEntity. } WHERE { ?document dct:replaces ?document2. } </pre><p></p> </section> <p> The term <code>dct:isReplacedBy</code> would produce a similar mapping, inverting the roles of document and document2. </p> </section> </section> <section id="cleanup"> <h3><span class="secno">3.4 </span>Cleanup</h3> <p> 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.</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 DC certain properties refer to the same activity (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: </p><pre class="code"> CONSTRUCT{ ?document a prov:Entity. _:activity a prov:Activity, prov:Create. prov:wasAssociatedWith ?agent prov:qualifiedAssociation [ a prov:Association; prov:agent ?agent; prov:hadRole [a prov:Creator]. ]. # The “output” _:createdEntity 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. } </pre> <a href="#figure_cleanup1">Figure 3</a> shows a graphical representation of the pattern (considering <code>?date</code> as <code>ex:dateCreation</code> and <code>?agent</code> as <code>ex:creator</code>): <div id="figure_cleanup1" style="text-align: center;"> <img src="img/cleanup1.svg" alt="Using complementing properties to conflate blank nodes"> <div style="text-align: center;"> <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></p> <p>2) Another solution is to <b>sort all the activities according to their logical order</b>, if known, and conflate the specialized entity (blank node) result of one activity with the specialized entity (blank node) input of the subsequent activity.  <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. Creation precedes publication, so instead of creating different blank nodes for their respective usage and generation, both activities share the same blank node (<code>_:createdEntity</code>). </p><div id="figure_cleanup2" style="text-align: center;"> <img src="img/cleanup2.svg" alt="Ordering activities to conflate blank nodes"> <div style="text-align: center;"> <a href="#figure_cleanup2">Figure 4</a>. Ordering activities to conflate blank nodes. The creation activity occurs before the publishing activity. </div> </div> <p></p> </section> <section id="list-of-terms-excluded-from-the-mapping"> <h3><span class="secno">3.5 </span>List of terms excluded from the mapping</h3> <p> <a href="#list-of-terms-excluded-from-the-mapping-properties"> Table 9</a> and <a href="#list-of-terms-excluded-from-the-mapping-classes"> Table 10</a> list the properties and classes excluded from the mapping, either because they are not suitable or because they do not represent provenance information. Regarding the classes, it is important to note that when a class is found to be defined as the range of some DC property that does not describe the provenance of a resource (but its descriptive metadata), it has been left out of the mapping rather than adding it as a subclass of <code>prov:Entity</code> (e.g., <code>dct:MediaType</code>, <code>dct:Standard</code>). </p> <table id="list-of-terms-excluded-from-the-mapping-properties"> <caption> <a href="#list-of-terms-excluded-from-the-mapping-properties"> Table 9:</a> List of properties excluded from the mapping </caption> <tbody> <tr> <td><b id="term_abstract"><a href="http://purl.org/dc/terms/abstract">dct:abstract</a></b></td> <td>Descriptive metadata</td> <td>Summary of the resource. Thus, not part of its provenance.</td> </tr> <tr> <td><b id="term_accessRights"><a href="http://purl.org/dc/terms/accessRights">dct:accessRights</a></b></td> <td>Provenance: How</td> <td>Agents who can access the resource (security status). Since the privileges of the resource are part of the description of the resource, the property has been excluded from the mapping.</td> </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. Since this term does not describe the activity or the entities participating on the activity (just the plan followed), 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> <td>Frequency of the addition of items to a collection.</td> </tr><tr> <td><b id="term_accrualPolicy"><a href="http://purl.org/dc/terms/accrualPolicy">dct:accrualPolicy</a></b></td> <td>Descriptive metadata</td> <td>Policy associated with the insertion of items to a collection. It could be used to enrich the qualified involvement, but there is no direct mapping of this relationship.</td> </tr><tr> <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 cannot 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> <td>The audience for whom the resource is useful.</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. There is no direct mapping between this property and the PROV notions of generation and invalidation.</td> </tr> <tr> <td><b id="term_bibliographicCitation"><a href="http://purl.org/dc/terms/bibliographicCitation">dct:bibliographicCitation</a></b></td> <td>Descriptive metadata</td> <td>Property that relates the literal representing the bibliographic citation of the resource to the actual resource (e.g., <code>:el_Quijote dct:bibliographicCitation "Miguel de Cervantes Saavedra: El Quijote, España"</code>).</td> </tr> <tr> <td><b id="term_conformsTo"><a href="http://purl.org/dc/terms/conformsTo">dct:conformsTo</a></b></td> <td>Descriptive metadata</td> <td>Indicates the standard to which the resource conforms to (if any).</td> </tr><tr> <td><b id="term_coverage"><a href="http://purl.org/dc/terms/coverage">dct:coverage</a></b></td> <td>Descriptive metadata</td> <td>Topic of the resource.</td> </tr><tr> <td><b id="term_description"><a href="http://purl.org/dc/terms/description">dct:description</a></b></td> <td>Descriptive metadata</td> <td>An account of the resource.</td> </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.</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> <td>Size or duration of the resource.</td> </tr><tr> <td><b id="term_format"><a href="http://purl.org/dc/terms/format">dct:format</a></b></td> <td>Descriptive metadata</td> <td>Format of the resource. </td> </tr> <tr> <td><b id="term_hasPart"><a href="http://purl.org/dc/terms/hasPart">dct:hasPart</a></b></td> <td>Descriptive metadata</td> <td>A resource that is included in the current resource. Since entity composition is out of the scope of PROV, this property has been excluded from the mapping</td> </tr> <tr> <td><b id="term_identifier"><a href="http://purl.org/dc/terms/identifier">dct:identifier</a></b></td> <td>Descriptive metadata</td> <td>"An unambiguous reference to the resource within a given context." </td> </tr><tr> <td><b id="term_instructionalMethod"><a href="http://purl.org/dc/terms/instructionalMethod">dct:instructionalMethod</a></b></td> <td>Descriptive metadata</td> <td>"A process, used to engender knowledge, attitudes and skills, that the described resource is designed to support".</td> </tr><tr> <td><b id="term_isPartOf"><a href="http://purl.org/dc/terms/isPartOf">dct:isPartOf</a></b></td> <td>Descriptive metadata</td> <td>Inverse of <code>dct:hasPart</code>.</td> </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>Property used to describe that the current resource is required for supporting the function of another resource. This is not related to the provenance of the resource, since it refers to something that may not have happened yet (e.g., a programming scripts' dependency on another dependency).</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> <td>Language of the resource.</td> </tr> <tr> <td><b id="term_license"><a href="http://purl.org/dc/terms/license">dct:license</a></b></td> <td>Provenance: How</td> <td>License of the resource. It has been left out of the mapping because there is no term in PROV-O to represent this information.</td> </tr> <tr> <td><b id="term_mediator"><a href="http://purl.org/dc/terms/mediator">dct:mediator</a></b></td> <td>Descriptive metadata</td> <td>Entity that mediates access to the resource. </td> </tr><tr> <td><b id="term_medium"><a href="http://purl.org/dc/terms/medium">dct:medium</a></b></td> <td>Descriptive metadata</td> <td>Material of the resource.</td> </tr> <tr> <td><b id="term_rights"><a href="http://purl.org/dc/terms/rights">dct:rights</a></b></td> <td>Provenance: How</td> <td>Metadata about the rights of the resource.</td> </tr> <tr> <td><b id="term_relation"><a href="http://purl.org/dc/terms/relation">dct:relation</a></b></td> <td>Descriptive metadata</td> <td>Term used to identify "A related resource", which might not be related to the provenance of the described resource.</td> </tr> <tr> <td><b id="term_requires"><a href="http://purl.org/dc/terms/requires">dct:requires</a></b></td> <td>Descriptive metadata</td> <td>Inverse property of <code>dct:isRequiredBy</code> (see <code>dct:isRequiredBy</code>).</td> </tr> <tr> <td><b id="term_spatial"><a href="http://purl.org/dc/terms/spatial">dct:spatial</a></b></td> <td>Descriptive metadata</td> <td>Spatial characteristics of the content of the resource (e.g., the book is about Spain). Thus it cannot be mapped to <code>prov:hadLocation</code>.</td> </tr><tr> <td><b id="term_subject"><a href="http://purl.org/dc/terms/subject">dct:subject</a></b></td> <td>Descriptive metadata</td> <td>Subject of the resource.</td> </tr><tr> <td><b id="term_tableOfContents"><a href="http://purl.org/dc/terms/tableOfContents">dct:tableOfContents</a></b></td> <td>Descriptive metadata</td> <td>List of subunits of the resource.</td> </tr><tr> <td><b id="term_temporal"><a href="http://purl.org/dc/terms/temporal">dct:temporal</a></b></td> <td>Descriptive metadata</td> <td>Temporal characteristics of which the resource refers to (e.g., a book about 15th century).</td> </tr><tr> <td><b id="term_title"><a href="http://purl.org/dc/terms/">dct:title</a></b></td> <td>Descriptive metadata</td> <td>Title of the resource.</td> </tr><tr> <td><b id="term_type"><a href="http://purl.org/dc/terms/">dct:type</a></b></td> <td>Descriptive metadata</td> <td>Type of the resource.</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> <td>"Date (often a range) of validity of a resource." This property could correspond to PROV's generation and invalidation of the resource or one of its specializations. However, <code>dct:valid</code> can be used to set expiry dates (e.g., resource valid until 2015), which is not provenance (it is not about past events). Thus this property is left out of the mapping.</td> </tr> </tbody></table> <table id="list-of-terms-excluded-from-the-mapping-classes"> <caption> <a href="#list-of-terms-excluded-from-the-mapping-classes"> Table 10:</a> List of classes excluded from the mapping </caption> <tbody> <tr> <th>DC Term</th> <th>Category</th> <th>Rationale</th> </tr> <tr> <td><b id="term_AgentClass"><a href="http://purl.org/dc/terms/AgentClass">dct:AgentClass</a></b></td> <td>Descriptive metadata</td> <td>Specialization of <code>rdfs:Class</code> to define classes or groups of Agents (like <code>dct:Agent</code>. None of the PROV classes are defined similarly, so it is our of the scope of the mapping.</td> </tr> <tr> <td><b id="term_FileFormat"><a href="http://purl.org/dc/terms/FileFormat">dct:FileFormat</a></b></td> <td>Descriptive metadata</td> <td>Format of a digital resource. This class is the range of <code>dct:format</code> and normally is associated to literals (such as ".doc", "jpg", etc.). Therefore it is not part of this mapping.</td> </tr> <tr> <td><b id="term_Frequency"><a href="http://purl.org/dc/terms/Frequency">dct:Frequency</a></b></td> <td>Descriptive metadata</td> <td>Frequency to which items are added to a collection.</td> </tr> <tr> <td><b id="term_Jurisdiction"><a href="http://purl.org/dc/terms/Jurisdiction">dct:Jurisdiction</a></b></td> <td>Descriptive metadata</td> <td>Defined as "The extent or range of judicial, law enforcement, or other authority." This class is used to describe a particular aspect of a resource for which the provenance is not further described. Therefore it is not part of this mapping. </td> </tr> <tr> <td><b id="term_MediaType"><a href="http://purl.org/dc/terms/MediaType">dct:MediaType</a></b></td> <td>Descriptive metadata</td> <td>File format or physical medium. This class is the range of <code>dct:format</code> and normally is associated to literals (such as "paper", "PNG", etc.). Therefore it is not part of this mapping.</td> </tr> <tr> <td><b id="term_MediaTypeOrExtent"><a href="http://purl.org/dc/terms/MediaTypeOrExtent">dct:MediaTypeOrExtent</a></b></td> <td>Descriptive metadata</td> <td>Superclass of <code>dct:MediaType</code>. This class is the range of <code>dct:format</code> and is normally associated to literals (such as "paper", "PNG", etc.). Therefore it is not part of this mapping.</td> </tr> <tr> <td><b id="term_PeriodOfTime"><a href="http://purl.org/dc/terms/PeriodOfTime">dct:PeriodOfTime</a></b></td> <td>Descriptive metadata</td> <td>Interval of time (start and end dates). Although PROV models instantaneous events, and entities and activities can be seen as occupying intervals of time, there is no clear mapping to any of the PROV terms.</td> </tr> <tr> <td><b id="term_PhysicalMedium"><a href="http://purl.org/dc/terms/PhysicalMedium">dct:PhysicalMedium</a></b></td> <td>Descriptive metadata</td> <td>Range of the <code>dct:medium</code> property to associate a resource with its material. This class is usually associated to literals (such as "paper", "CD", etc.). Therefore it is not part of this mapping. </td> </tr> <tr> <td><b id="term_SizeOrDuration"><a href="http://purl.org/dc/terms/SizeOrDuration">dct:SizeOrDuration</a></b></td> <td>Descriptive metadata</td> <td>Dimension or time taken to execute something (e.g., the minutes for a cooking recipe). The "duration" aspect of the size is prospective, while PROV just covers retrospective durations.</td> </tr> <tr> <td><b id="term_Standard"><a href="http://purl.org/dc/terms/Standard">dct:Standard</a></b></td> <td>Descriptive metadata</td> <td>Range of the <code>dct:conformsTo</code> property to associate a resource with its standard. This class is usually associated to literals (such as "ISO Standard 15836:2009", "ANSI/NISO Standard Z39.85-2007", etc.). Therefore it is not part of this mapping.</td> </tr> </tbody> </table> </section> <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 DC is not part of this note. If the refinements proposed in <a href="#prov-refinements">Section 3.2</a> are used, then the inverse of the complex mapping patterns can be applied. 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. This is because DC provides more specific classes of activities. Likewise, the agents involved cannot be mapped to creators, contributors, or publishers. This is because DC provides more specific classes of agency. While DC includes provenance information, its focus lies on the broader description of resources. Because PROV is focused on modeling provenance chains, it does not provide ways to describe the resources being chained together. </p> </section> </section> <section id="acknowledgements" class="appendix"> <h2><span class="secno">A. </span>Acknowledgements</h2> <p> This document is the result of a collaboration between the Provenance Working Group and the Dublin Core Metadata Initiative. The editors extend special thanks to Antoine Isaac, Ivan Herman, Timothy Lebo, Luc Moreau, Paul Groth, Satya Sahoo, Tom Baker and Stian Soiland-Reyes for their feedback; and María Poveda and Idafen Santana for their help with the HTML generation. </p> <p> We would also like to acknowledge <a href="http://www.dagstuhl.de/">Schloss Dagstuhl - Leibniz Center for Informatics</a>, because significant progress was made on this document at <a href="http://www.dagstuhl.de/en/program/calendar/semhp/?semnr=12091">Dagstuhl Seminar 12091 (Principles of Provenance)</a> that took place from February 26 to March 2, 2012. </p> <p> Members of the Provenance Working Group at the time of publication of this document were: Ilkay Altintas (Invited expert), Reza B'Far (Oracle Corporation), Khalid Belhajjame (University of Manchester), James Cheney (University of Edinburgh, School of Informatics), Sam Coppens (iMinds - Ghent University), David Corsar (University of Aberdeen, Computing Science), Stephen Cresswell (The National Archives), Tom De Nies (iMinds - Ghent University), Helena Deus (DERI Galway at the National University of Ireland, Galway, Ireland), Simon Dobson (Invited expert), Martin Doerr (Foundation for Research and Technology - Hellas(FORTH)), Kai Eckert (Invited expert), Jean-Pierre EVAIN (European Broadcasting Union, EBU-UER), James Frew (Invited expert), Irini Fundulaki (Foundation for Research and Technology - Hellas(FORTH)), Daniel Garijo (Ontology Engineering Group, Universidad Politécnica de Madrid), Yolanda Gil (Invited expert), Ryan Golden (Oracle Corporation), Paul Groth (Vrije Universiteit), Olaf Hartig (Invited expert), David Hau (National Cancer Institute, NCI), Sandro Hawke (W3C/MIT), Jörn Hees (German Research Center for Artificial Intelligence (DFKI) Gmbh), Ivan Herman, (W3C/ERCIM), Ralph Hodgson (TopQuadrant), Hook Hua (Invited expert), Trung Dong Huynh (University of Southampton), Graham Klyne (University of Oxford), Michael Lang (Revelytix, Inc.), Timothy Lebo (Rensselaer Polytechnic Institute), James McCusker (Rensselaer Polytechnic Institute), Deborah McGuinness (Rensselaer Polytechnic Institute), Simon Miles (Invited expert), Paolo Missier (School of Computing Science, Newcastle university), Luc Moreau (University of Southampton), James Myers (Rensselaer Polytechnic Institute), Vinh Nguyen (Wright State University), Edoardo Pignotti (University of Aberdeen, Computing Science), Paulo da Silva Pinheiro (Rensselaer Polytechnic Institute), Carl Reed (Open Geospatial Consortium), Adam Retter (Invited Expert), Christine Runnegar (Invited expert), Satya Sahoo (Invited expert), David Schaengold (Revelytix, Inc.), Daniel Schutzer (FSTC, Financial Services Technology Consortium), Yogesh Simmhan (Invited expert), Stian Soiland-Reyes (University of Manchester), Eric Stephan (Pacific Northwest National Laboratory), Linda Stewart (The National Archives), Ed Summers (Library of Congress), Maria Theodoridou (Foundation for Research and Technology - Hellas(FORTH)), Ted Thibodeau (OpenLink Software Inc.), Curt Tilmes (National Aeronautics and Space Administration), Craig Trim (IBM Corporation), Stephan Zednik (Rensselaer Polytechnic Institute), Jun Zhao (University of Oxford), Yuting Zhao (University of Aberdeen, Computing Science). </p> </section> <section id="changes-since-second-public-working-draft" class="appendix"> <h2><span class="secno">B. </span>Changes Since Second Public Working Draft</h2> <ul> <li>Added the mapping to prov:has_provenance.</li> <li>Added dct:ProvenanceStatement as a type of prov:Bundle.</li> <li>Added dct:references as a type of derivation.</li> <li>Added prov:RightsAssignment and complex mapping for rightsHolder.</li> <li>Added DC classes in the mapping.</li> <li>dct:isVersionOf is a superproperty of prov:wasRevisionOf.</li> <li>dct:date complex mapping added.</li> </ul> </section> <section class="appendix" id="references"><h2><span class="secno">C. </span>References</h2><section id="informative-references"><h3><span class="secno">C.1 </span>Informative references</h3><dl class="bibliography"><dt id="bib-DCMI">[DCMI]</dt><dd><a href="http://dublincore.org/"><cite>Dublin Core Metadata Initiative</cite></a>. URL: <a href="http://dublincore.org/">http://dublincore.org/</a> </dd><dt id="bib-DCTERMS">[DCTERMS]</dt><dd><a href="http://dublincore.org/documents/dcmi-terms/"><cite>DCMI Metadata Terms</cite></a>. 14 June 2012. URL: <a href="http://dublincore.org/documents/2012/06/14/dcmi-terms/">http://dublincore.org/documents/2012/06/14/dcmi-terms/</a> </dd><dt id="bib-refinements">[PROV-DC-REFINEMENTS]</dt><dd><a href="https://www.w3.org/ns/prov-dc-refinements.ttl"><cite>PROV-O refinements for Dublin Core file</cite></a>. 30 April 2013. URL: <a href="https://www.w3.org/ns/prov-dc-refinements.ttl">http://www.w3.org/ns/prov-dc-refinements.ttl</a> </dd><dt id="bib-mapping">[PROV-DC-DIRECT-MAPPINGS]</dt><dd><a href="https://www.w3.org/ns/prov-dc-directmappings.ttl"><cite>Dublin Core to PROV mapping file</cite></a>. 30 April 2013. URL: <a href="https://www.w3.org/ns/prov-dc-directmappings.ttl">http://www.w3.org/ns/prov-dc-directmappings.ttl</a> </dd><dt id="bib-OWL2-OVERVIEW">[OWL2-OVERVIEW]</dt><dd>W3C OWL Working Group. <a href="https://www.w3.org/TR/2012/REC-owl2-overview-20121211/"><cite>OWL 2 Web Ontology Language: Overview</cite></a>. 11 December 2012. W3C Recommendation. URL: <a href="https://www.w3.org/TR/2012/REC-owl2-overview-20121211/">http://www.w3.org/TR/2012/REC-owl2-overview-20121211/</a> </dd><dt id="bib-PROV-AQ">[PROV-AQ]</dt><dd>Graham Klyne; Paul Groth; eds. <a href="https://www.w3.org/TR/2013/NOTE-prov-aq-20130430/"><cite>Provenance Access and Query</cite></a>. 30 April 2013, W3C Note. URL: <a href="https://www.w3.org/TR/2013/NOTE-prov-aq-20130430/">http://www.w3.org/TR/2013/NOTE-prov-aq-20130430/</a> </dd><dt id="bib-PROV-CONSTRAINTS">[PROV-CONSTRAINTS]</dt><dd>James Cheney; Paolo Missier; Luc Moreau; eds. <a href="https://www.w3.org/TR/2013/REC-prov-constraints-20130430/"><cite>Constraints of the PROV Data Model</cite></a>. 30 April 2013, W3C Recommendation. URL: <a href="https://www.w3.org/TR/2013/REC-prov-constraints-20130430/">http://www.w3.org/TR/2013/REC-prov-constraints-20130430/</a> </dd><dt id="bib-PROV-DICTIONARY">[PROV-DICTIONARY]</dt><dd>Tom De Nies; Sam Coppens; eds. <a href="https://www.w3.org/TR/2013/NOTE-prov-dictionary-20130430/"><cite>PROV Dictionary: Modeling Provenance for Dictionary Data Structures</cite></a>. 30 April 2013, W3C Note. URL: <a href="https://www.w3.org/TR/2013/NOTE-prov-dictionary-20130430/">http://www.w3.org/TR/2013/NOTE-prov-dictionary-20130430/</a> </dd><dt id="bib-PROV-DM">[PROV-DM]</dt><dd>Luc Moreau; Paolo Missier; eds. <a href="https://www.w3.org/TR/2013/REC-prov-dm-20130430/"><cite>PROV-DM: The PROV Data Model</cite></a>. 30 April 2013, W3C Recommendation. URL: <a href="https://www.w3.org/TR/2013/REC-prov-dm-20130430/">http://www.w3.org/TR/2013/REC-prov-dm-20130430/</a> </dd><dt id="bib-PROV-LINKS">[PROV-LINKS]</dt><dd>Luc Moreau; Timothy Lebo; eds. <a href="https://www.w3.org/TR/2013/NOTE-prov-links-20130430/"><cite>Linking Across Provenance Bundles</cite></a>. 30 April 2013, W3C Note. URL: <a href="https://www.w3.org/TR/2013/NOTE-prov-links-20130430/">http://www.w3.org/TR/2013/NOTE-prov-links-20130430/</a> </dd><dt id="bib-PROV-N">[PROV-N]</dt><dd>Luc Moreau; Paolo Missier; eds. <a href="https://www.w3.org/TR/2013/REC-prov-n-20130430/"><cite>PROV-N: The Provenance Notation</cite></a>. 30 April 2013, W3C Recommendation. URL: <a href="https://www.w3.org/TR/2013/REC-prov-n-20130430/">http://www.w3.org/TR/2013/REC-prov-n-20130430/</a> </dd><dt id="bib-PROV-O">[PROV-O]</dt><dd>Timothy Lebo; Satya Sahoo; Deborah McGuinness; eds. <a href="https://www.w3.org/TR/2013/REC-prov-o-20130430/"><cite>PROV-O: The PROV Ontology</cite></a>. 30 April 2013, W3C Recommendation. URL: <a href="https://www.w3.org/TR/2013/REC-prov-o-20130430/">http://www.w3.org/TR/2013/REC-prov-o-20130430/</a> </dd><dt id="bib-PROV-OVERVIEW">[PROV-OVERVIEW]</dt><dd>Paul Groth; Luc Moreau; eds. <a href="https://www.w3.org/TR/2013/NOTE-prov-overview-20130430/"><cite>PROV-OVERVIEW: An Overview of the PROV Family of Documents</cite></a>. 30 April 2013, W3C Note. URL: <a href="https://www.w3.org/TR/2013/NOTE-prov-overview-20130430/">http://www.w3.org/TR/2013/NOTE-prov-overview-20130430/</a> </dd><dt id="bib-PROV-PRIMER">[PROV-PRIMER]</dt><dd>Yolanda Gil; Simon Miles; eds. <a href="https://www.w3.org/TR/2013/NOTE-prov-primer-20130430/"><cite>PROV Model Primer</cite></a>. 30 April 2013, W3C Note. URL: <a href="https://www.w3.org/TR/2013/NOTE-prov-primer-20130430/">http://www.w3.org/TR/2013/NOTE-prov-primer-20130430/</a> </dd><dt id="bib-PROV-SEM">[PROV-SEM]</dt><dd>James Cheney; ed. <a href="https://www.w3.org/TR/2013/NOTE-prov-sem-20130430"><cite>Semantics of the PROV Data Model</cite></a>. 30 April 2013, W3C Note. URL: <a href="https://www.w3.org/TR/2013/NOTE-prov-sem-20130430">http://www.w3.org/TR/2013/NOTE-prov-sem-20130430</a>. </dd><dt id="bib-PROV-XML">[PROV-XML]</dt><dd>Hook Hua; Curt Tilmes; Stephan Zednik; eds. <a href="https://www.w3.org/TR/2013/NOTE-prov-xml-20130430/"><cite>PROV-XML: The PROV XML Schema</cite></a>. 30 April 2013, W3C Note. URL: <a href="https://www.w3.org/TR/2013/NOTE-prov-xml-20130430/">http://www.w3.org/TR/2013/NOTE-prov-xml-20130430/</a> </dd><dt id="bib-RDFS">[RDFS]</dt><dd>Dan Brickley; Ramanathan V. Guha. RDF Vocabulary Description Language 1.0: RDF Schema. 10 February 2004. W3C Recommendation.URL: <a href="https://www.w3.org/TR/2004/REC-rdf-schema-20040210">http://www.w3.org/TR/2004/REC-rdf-schema-20040210/</a> </dd><dt id="bib-TURTLE">[TURTLE]</dt><dd>Eric Prud'hommeaux, Gavin Carothers; eds.<a href="https://www.w3.org/TR/2011/WD-turtle-20110809/"><cite>Turtle: Terse RDF Triple Language</cite></a>. 9 August 2011. W3C Working Draft. URL:<a href="https://www.w3.org/TR/2011/WD-turtle-20110809/">http://www.w3.org/TR/2011/WD-turtle-20110809/</a> </dd></dl></section></section><script src="https://www.w3.org/scripts/TR/fixup.js"></script></body></html>