--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/releases/WD-prov-dc-20130312/Overview.html Mon Mar 04 00:52:26 2013 +0100
@@ -0,0 +1,1779 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
+<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <title>Dublin Core to PROV Mapping</title>
+ <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
+
+
+<!-- PM -->
+
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script type="text/javascript" src="toggles.js"></script>
+
+
+
+
+ <style type="text/css">
+
+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;
+}
+
+ </style>
+<style>/*****************************************************************
+ * 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><style>/* --- EXAMPLES --- */
+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;
+}
+</style><link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD" />
+<!--[if lt IE 9]><script src='http://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
+</head>
+ <body prefix="prov: http://www.w3.org/ns/prov# foaf: http://xmlns.com/foaf/0.1/ dc: http://purl.org/dc/terms/" style="display: inherit;"><div class="head">
+ <p>
+
+ <a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a>
+
+ </p>
+ <h1 id="title" class="title">Dublin Core to PROV Mapping</h1>
+
+ <h2 id="w3c-working-draft-04-march-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft 12 March 2013</h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a href="http://www.w3.org/TR/2013/WD-prov-dc-20130304/">http://www.w3.org/TR/2013/WD-prov-dc-20130304/</a></dd>
+ <dt>Latest published version:</dt>
+ <dd><a href="http://www.w3.org/TR/prov-dc/">http://www.w3.org/TR/prov-dc/</a></dd>
+
+
+ <dt>Latest editor's draft:</dt>
+ <dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/dc-note.html">http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/dc-note.html</a></dd>
+
+
+
+
+
+ <dt>Previous version:</dt>
+ <dd><a href="http://www.w3.org/TR/2012/WD-prov-dc-20121211/">http://www.w3.org/TR/2012/WD-prov-dc-20121211/</a></dd>
+
+
+ <dt>Editors:</dt>
+ <dd><a href="http://delicias.dia.fi.upm.es/members/DGarijo/">Daniel Garijo</a>, 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="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+ 2013
+
+ <a href="http://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="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+ <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
+ </p>
+
+
+ <hr />
+</div>
+
+<!-- RDFA ANNOTATIONS. Since the version data is created automatically, I'll add the statements here
+ <http://www.w3.org/TR/2013/WD-prov-dc-20130312/>
+ prov:wasRevisionOf <http://www.w3.org/TR/2012/WD-prov-dc-20121211/>;
+ prov:specializationOf <http://www.w3.org/TR/prov-dc/>;
+ prov:wasAttributedTo <http://delicias.dia.fi.upm.es/members/DGarijo/#me>;
+ prov:wasAttributedTo <http://www.kaiec.org/#me>;
+ #add other authors/editors here
+ prov:wasAttributedTo <http://www.w3.org/2011/prov>;
+ prov:wasInfluencedBy <http://www.w3.org/TR/2013/WD-prov-dc-20130312/#acknowledgements>.
+<http://delicias.dia.fi.upm.es/members/DGarijo/#me> a prov:Person .
+<http://www.kaiec.org/#me> a prov:Person .
+<http://www.w3.org/2011/prov> a prov:Organization .
+ -->
+
+ <b typeof="foaf:Document prov:Entity" resource="http://www.w3.org/TR/2013/WD-prov-dc-20130312/">
+ <b resource="http://www.w3.org/TR/2012/WD-prov-dc-20121211/" property="prov:wasRevisionOf"></b>
+ <b resource="http://www.w3.org/TR/prov-dc/" property="prov:specializationOf"></b>
+ <b typeof="prov:Person foaf:Person" resource="http://delicias.dia.fi.upm.es/members/DGarijo/#me" property="prov:wasAttributedTo dc:creator"></b>
+ <b typeof="prov:Person foaf:Person" resource="http://www.kaiec.org/#me" property="prov:wasAttributedTo dc:creator"></b>
+ <b typeof="prov:Person foaf:Person" resource="http://www.inf.kcl.ac.uk/staff/simonm/#me" property="prov:wasAttributedTo"></b>
+ <b typeof="prov:Person foaf:Person" resource="http://staff.oclc.org/~dewey/michael.htm#me" property="prov:wasAttributedTo"></b>
+ <b typeof="prov:Person foaf:Person" resource="http://www.linkedin.com/in/craigtrim" property="prov:wasAttributedTo"></b>
+ <b typeof="prov:Organization foaf:Organization" resource="http://www.w3.org/2011/prov" property="prov:wasAttributedTo"></b>
+ <b resource="http://www.w3.org/TR/2013/WD-prov-dc-20130312/#acknowledgements" property="prov:wasInfluencedBy"></b>
+ </b>
+
+<!-- END OF RDFA ANNOTATIONS-->
+
+ <section id="abstract" class="introductory"><h2>Abstract</h2>
+ <p>
+ This document describes a partial mapping from Dublin Core Terms [<cite><a class="bibref" href="#bib-DCTERMS">DCTERMS</a></cite>] to the PROV-O OWL2 ontology [<cite><a class="bibref" href="#bib-PROV-O">PROV-O</a></cite>]. A substantial number of
+ terms in the Dublin Core vocabulary provide information about the provenance of the resource. Translating these terms to PROV makes the
+ contained provenance information explicit within a provenance chain. The mapping is expressed partly by direct RDFS/OWL mappings between
+ properties and classes, which can be found <a href="http://www.w3.org/ns/prov-dc-directmappings.ttl">here</a>.
+ </p>
+ <p>
+ Some of the direct mappings can be refined, translating single Dublin Core Terms into an extended
+ representation of the provenance chain. Therefore, refinements of classes defined in PROV are needed to represent specific Dublin Core activities and roles.
+ This set of PROV refinements can be accessed <a href="http://www.w3.org/ns/prov-dc-refinements.ttl">here</a>.
+ </p>
+ <p>
+ The PROV Document Overview [<cite><a class="bibref" href="#bib-PROV-OVERVIEW">PROV-OVERVIEW</a></cite>] describes the overall state of PROV, and should be read before other PROV documents.
+ </p>
+
+<!--
+ This document provides a mapping between the PROV-O OWL2 ontology [[PROV-O]] and the Dublin Core Terms Vocabulary [[DCTERMS]].
+ </p>
+ <p style="text-align: center;">
+ The mapping between Dublin Core and PROV is available <a href="http://www.w3.org/ns/prov-dc-directmappings.ttl">here</a>.
+ </p>
+ <p style="text-align: center;">
+ A set of PROV refinements for representing Dublin Core activities and roles can be accessed <a href="http://www.w3.org/ns/prov-dc-refinements.ttl">here</a>.
+ </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 class="introductory" id="sotd"><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="http://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 class="bibref" href="#bib-PROV-OVERVIEW">PROV-OVERVIEW</a></cite>] for a guide to reading these documents.
+ <ul>
+ <li> <a href="http://www.w3.org/TR/2013/WD-prov-overview-20130312/">PROV-OVERVIEW</a> (To be published as Note), an overview of the PROV family of documents [<cite><a class="bibref" href="#bib-PROV-OVERVIEW">PROV-OVERVIEW</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/WD-prov-primer-20130312/">PROV-PRIMER</a> (To be published as Note), a primer for the PROV data model [<cite><a class="bibref" href="#bib-PROV-PRIMER">PROV-PRIMER</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/PR-prov-o-20130312/">PROV-O</a> (Proposed Recommendation), the PROV ontology, an OWL2 ontology allowing the mapping of PROV to RDF [<cite><a class="bibref" href="#bib-PROV-O">PROV-O</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/PR-prov-dm-20130312/">PROV-DM</a> (Proposed Recommendation), the PROV data model for provenance [<cite><a class="bibref" href="#bib-PROV-DM">PROV-DM</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/PR-prov-n-20130312/">PROV-N</a> (Proposed Recommendation), a notation for provenance aimed at human consumption [<cite><a class="bibref" href="#bib-PROV-N">PROV-N</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/PR-prov-constraints-20130312/">PROV-CONSTRAINTS</a> (Proposed Recommendation), a set of constraints applying to the PROV data model [<cite><a class="bibref" href="#bib-PROV-CONSTRAINTS">PROV-CONSTRAINTS</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/WD-prov-xml-20130312/">PROV-XML</a> (To be published as Note), an XML schema for the PROV data model [<cite><a class="bibref" href="#bib-PROV-XML">PROV-XML</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/WD-prov-aq-20130312/">PROV-AQ</a> (To be published as Note), the mechanisms for accessing and querying provenance [<cite><a class="bibref" href="#bib-PROV-AQ">PROV-AQ</a></cite>]; </li>
+ <li> <a href="http://www.w3.org/TR/2013/WD-prov-dictionary-20130312/">PROV-DICTIONARY</a> (To be published as Note) introduces a specific type of collection, consisting of key-entity pairs [<cite><a class="bibref" href="#bib-PROV-DICTIONARY">PROV-DICTIONARY</a></cite>];</li>
+ <li> <a href="http://www.w3.org/TR/2013/WD-prov-dc-20130312/">PROV-DC</a> (To be published as Note) provides a mapping between PROV and Dublic Core Terms (this document);</li>
+ <li> <a href="http://www.w3.org/TR/2013/WD-prov-links-20130312/">PROV-LINKS</a> (To be published as Note) introduces a mechanism to link across bundles [<cite><a class="bibref" href="#bib-PROV-LINKS">PROV-LINKS</a></cite>].</li>
+ </ul>
+
+
+<!-- <h4>W3C Members Please Review By 09 April 2013</h4>
+
+ <p>The W3C Director seeks review and feedback from W3C Advisory Committee representatives, via their <a href="http://form-tbd/">review form</a> by 09 April 2013. This will allow the Director to assess consensus and determine whether to issue this document as a W3C Recommendation.</p>
+
+ <p>Others are encouraged by the Provenance Working Group to continue to send reports of implementation experience, and other feedback, 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>). Open discussion among developers is also welcome at
+ <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>).</p>-->
+
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2011/prov/">Provenance Working Group</a> as a Working Draft.
+
+ This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
+
+
+ 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 Draft 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="http://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 rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/46974/status">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="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the
+ information in accordance with <a href="http://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 href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#namespaces-1" class="tocxref"><span class="secno">1.1 </span>Namespaces</a></li><li class="tocline"><a href="#structure-of-this-document" class="tocxref"><span class="secno">1.2 </span>Structure of this document</a></li></ul></li><li class="tocline"><a href="#preliminaries" class="tocxref"><span class="secno">2. </span>Preliminaries</a><ul class="toc"><li class="tocline"><a href="#provenance-in-dublin-core" class="tocxref"><span class="secno">2.1 </span>Provenance in Dublin Core</a></li><li class="tocline"><a href="#entities-in-dublin-core" class="tocxref"><span class="secno">2.2 </span>Entities in Dublin Core</a></li></ul></li><li class="tocline"><a href="#mapping-from-dublin-core-to-prov" class="tocxref"><span class="secno">3. </span>Mapping from Dublin Core to PROV</a><ul class="toc"><li class="tocline"><a href="#direct-mappings" class="tocxref"><span class="secno">3.1 </span>Direct mappings</a></li><li class="tocline"><a href="#prov-refinements" class="tocxref"><span class="secno">3.2 </span>PROV refinements</a></li><li class="tocline"><a href="#complex-mappings" class="tocxref"><span class="secno">3.3 </span>Complex Mappings</a><ul class="toc"><li class="tocline"><a href="#entity-agent-mappings-who" class="tocxref"><span class="secno">3.3.1 </span>Entity-Agent mappings (Who)</a><ul class="toc"><li class="tocline"><a href="#dct-creator" class="tocxref"><span class="secno">3.3.1.1 </span> dct:creator</a></li><li class="tocline"><a href="#dct-contributor" class="tocxref"><span class="secno">3.3.1.2 </span>dct:contributor</a></li><li class="tocline"><a href="#dct-publisher" class="tocxref"><span class="secno">3.3.1.3 </span>dct:publisher</a></li></ul></li><li class="tocline"><a href="#entity-date-mappings-when" class="tocxref"><span class="secno">3.3.2 </span>Entity-Date mappings (When)</a><ul class="toc"><li class="tocline"><a href="#dct-created" class="tocxref"><span class="secno">3.3.2.1 </span> dct:created</a></li><li class="tocline"><a href="#dct-issued" class="tocxref"><span class="secno">3.3.2.2 </span>dct:issued</a></li><li class="tocline"><a href="#dct-modified" class="tocxref"><span class="secno">3.3.2.3 </span>dct:modified</a></li><li class="tocline"><a href="#dct-dateaccepted" class="tocxref"><span class="secno">3.3.2.4 </span>dct:dateAccepted</a></li><li class="tocline"><a href="#dct-datecopyrighted" class="tocxref"><span class="secno">3.3.2.5 </span>dct:dateCopyrighted</a></li><li class="tocline"><a href="#dct-datesubmitted" class="tocxref"><span class="secno">3.3.2.6 </span>dct:dateSubmitted</a></li></ul></li><li class="tocline"><a href="#entity-entity-mappings-how" class="tocxref"><span class="secno">3.3.3 </span>Entity-Entity mappings (How)</a><ul class="toc"><li class="tocline"><a href="#dct-replaces" class="tocxref"><span class="secno">3.3.3.1 </span>dct:replaces</a></li></ul></li></ul></li><li class="tocline"><a href="#cleanup" class="tocxref"><span class="secno">3.4 </span>Cleanup</a></li><li class="tocline"><a href="#list-of-terms-excluded-from-the-mapping" class="tocxref"><span class="secno">3.5 </span>List of terms excluded from the mapping</a></li><li class="tocline"><a href="#mapping-from-prov-to-dc" class="tocxref"><span class="secno">3.6 </span>Mapping from PROV to DC</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
+
+
+ <section id="introduction">
+
+<!--OddPage-->
+<h2><span class="secno">1. </span>Introduction</h2>
+ <p>
+ The Dublin Core Metadata Initiative (DCMI) [<cite><a class="bibref" href="#bib-DCMI">DCMI</a></cite>] provides a core metadata vocabulary (commonly referred to as Dublin Core) for simple and generic resource descriptions.
+ The original element set (DC elements) was created in 1995 and contains 15 broadly-defined elements still in use.
+ The core elements have no range specification, and arbitrary values can be used as objects. The core elements have been
+ expanded beyond the original fifteen. Existing elements have been refined and new elements have been added. This expanded vocabulary is
+ referred to as "DCMI Terms" (DC terms) and currently consists of 55 properties [<cite><a class="bibref" href="#bib-DCTERMS">DCTERMS</a></cite>].
+ </p>
+ <p>
+ The use of DC terms is preferred and the DC elements have been depecreated.
+ Both sets have different namespaces. The original element set is typically referred with the
+ <code>dc</code> prefix, while <code>dct</code> (or <code>dcterms</code>) is used as prefix for the DC Terms.
+ </p>
+ <p>
+ This document defines a mapping between the DC Terms and the PROV Ontology (PROV-O) [<cite><a class="bibref" href="#bib-PROV-O">PROV-O</a></cite>], which defines an OWL2 Ontology encoding
+ the PROV Data Model [<cite><a class="bibref" href="#bib-PROV-DM">PROV-DM</a></cite>]. The 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 Dublin Core data</b> available on the web, improving interoperability between DC and PROV
+ applications.</li>
+ <li><b>Facilitate PROV adoption</b>. Simple Dublin Core statements can be used as a starting point for more complex PROV data generation.</li>
+ </ol>
+
+<!--
+ A mapping between Dublin Core Terms and PROV-O has many advantages. First, it can provide valuable insights
+ into the different characteristics of both data models (in particular it explains PROV from a Dublin Core point of view).
+ Second, such a mapping can be used to extract PROV data from the large amount of Dublin Core data available on
+ the Web today. Third, the mapping can translate PROV data to Dublin Core and make it accessible for applications that
+ understand Dublin Core. Finally, the mapping can lower the barrier to entry for PROV adoption. Simple Dublin Core
+ statements can be used as starting point for PROV data generation.
+ </p>
+ MOTIVATION OF THE MAPPING GOES HERE. Instead of listing the advantages, just justify them in a paragraph. End up by describing the mapping a bit?
+ -->
+
+ <p></p>
+
+ <p>
+ </p><section id="namespaces-1">
+ <h3 id="namespaces"><span class="secno">1.1 </span>Namespaces</h3>
+ <p>The namespaces used through the document can be seen in <a href="#ns"> Table 2</a> below:
+ </p><div align="center" id="ns">
+ <table>
+ <caption> <a href="#ns"> Table 2</a>: Namespaces used in the document </caption>
+ <tbody>
+ <tr><td><b>prefix</b></td><td><b>Namespace IRI</b></td><td><b>Definition</b></td></tr>
+ <tr><td>owl</td><td><http://www.w3.org/2002/07/owl#></td><td>The OWL namespace [<cite><a class="bibref" href="#bib-OWL2-OVERVIEW">OWL2-OVERVIEW</a></cite>].</td></tr>
+ <tr><td>rdfs</td><td><http://www.w3.org/2000/01/rdf-schema#></td><td>The RDFS namespace[<cite><a class="bibref" href="#bib-RDFS">RDFS</a></cite>].</td></tr>
+ <tr><td>prov</td><td><http://www.w3.org/ns/prov#></td><td>The PROV namespace [<cite><a class="bibref" href="#bib-PROV-DM">PROV-DM</a></cite>].</td></tr>
+ <tr><td>dct</td><td><http://purl.org/dc/terms/></td><td>Dublin Core Terms namespace [<cite><a class="bibref" href="#bib-DCTERMS">DCTERMS</a></cite>].</td></tr>
+
+<!--<tr><td>dc</td><td><http://purl.org/dc/elements/1.1/></td><td>Dublin Core elements namespace [[DCTERMS]]</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 Dublin Core, 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 on 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.
+
+<!--Since the mapping produces blank nodes for each DC statement, a clean-up phase with strategies for reducing the blank nodes is also necessary.-->
+
+ </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 have misleading names (e.g., <code>dct:alternative</code> is similar to <code>prov:alternateOf</code>), but have nothing to do with the provenance of a resource. Other terms summarize the
+ resolution of the community discussions 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">
+
+<!--OddPage-->
+<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 with provenance.</li>
+ <li><a href="#entities-in-dublin-core">Section 2.2</a>: The definition of entities in Dublin Core.</li>
+ </ul>
+ <p></p>
+ <section id="provenance-in-dublin-core">
+ <h3><span class="secno">2.1 </span>Provenance in Dublin Core</h3>
+ <p>
+ DCMI terms hold a lot of 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">Table 1</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 Dublin Core describing
+ <i>where</i> a resource was affected. The categories are further explained below:
+ </p>
+
+<!-- A total of 25 out of 55 terms can be considered provenance related.-->
+
+ <p>
+ <b> Descriptive Terms (What?):</b> This category contains all the terms describing a resource without refering to its provenance (a total of 30 out of 55 terms).
+ Some examples are the <code>dct:title</code>, <code> dct:abstract</code> or <code>dct:description</code> of a resource, the <code>dct:format</code> in which the resource can be found, etc.
+ </p>
+ <p>
+ <b>Agency Terms (Who?):</b> This category contains agent related terms. All properties have <code>dct:Agent</code> as range,
+ 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 the important provenance information for many resources, like artworks, it is included in this category.
+ </p>
+ <p>
+ <b>Date and Time Terms (When?):</b> This category contains date and time related terms.
+ 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>
+
+<!--
+ It can be questioned whether a resource changes by
+ being published or not. Depending on the application, however, the publication can be seen as an action that changes
+ the state of the resource.
+
+ – at most indirectly, as the validity state can change if a resource is replaced by a new
+ version
+ -->
+
+ <p>
+ <b>Derivation 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 Dublin Core, 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 derived from 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>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 align="center" id="categories">
+ <table>
+ <caption> <a href="#categories"> Table 1:</a> Categorization of the Dublin Core Terms </caption>
+ <tbody>
+ <tr>
+ <th>Category</th>
+ <th>Sub-category</th>
+ <th>Terms</th>
+ </tr>
+ <tr>
+ <td><b>Descriptive metadata</b></td>
+ <td>-</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_hasPart"> hasPart</a>,
+ <a href="#term_isPartOf">isPartOf</a>, <a href="#term_format">format</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_isVersionOf">isVersionOf</a>, <a href="#term_hasVersion">hasVersion</a>, <a href="#term_isFormatOf">isFormatOf</a>, <a href="#term_has_Format">hasFormat</a>, <a href="#term_license">license</a>,
+ <a href="#term_references">references</a>, <a href="#term_isReferencedBy">isReferencedBy</a>, <a href="#term_replaces">replaces</a>, <a href="#term_replaces">isReplacedBy</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 class="bibref" href="#bib-DCTERMS">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 cannot be included in any of the aforementioned categories and it is out of the scope of this mapping.
+
+<!--Despite being relevant for provenance,
+ this definition may overlap partially with almost half of the DCMI terms, which
+ specify concrete aspects of provenance of a resource.-->
+
+ </p>
+
+<!--<p>
+ The mapping is based on the categories presented in <a href="#categories">Table 1</a>, and has been divided
+ The term provenance
+ is kept out of the mapping.
+ </p>-->
+
+ </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:doc1</code>) is described
+ with several DC statements:
+ </p>
+ <p>
+ <a href="#example1">Example 1</a>: a simple metadata record:
+ </p><div class="example"><div class="example-title"><span>Example 1</span></div><pre id="example1" class="example">ex:doc1 dct:title "A mapping from Dublin Core..." ;
+dct:creator ex:kai, ex:daniel, ex:simon, ex:michael ;
+dct:created "2012-02-28" ;
+dct:publisher ex:w3c ;
+dct:issued "2012-02-29" ;
+dct:subject ex:dublincore ;
+dct:replaces ex:doc2 ;
+dct:format "HTML" .</pre></div>
+ In <a href="#example1">Example 1</a>, <code>dct:title</code>, <code>dct:subject</code> and <code>dct:format</code>
+ are descriptions of the resource <code>ex:doc1</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:doc1</code> to the document <code>ex:doc2</code>, a previous resource representing the mapping.
+<!-- which probably had some kind of influence on <code>ex:doc1</code>.-->
+
+ <p></p>
+ As a <code>dc</code>
+ metadata record describes the document as a whole,
+ it is not clear how this document relates to the different states that the document had until it reached its final state.
+ For example, a document may have a <code>dct:created</code> date and a <code>dct:issued</code> date. According to
+ the PROV ontology, the activity of issuing a document involves two different states of the document: the document before it was issued
+ and the issued document. Each of these states correspond to a different <code>prov:specialization</code> of the document. 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:sprecializationOf</code> the
+ resource we are describing), and generated the published resource (<code>:_resultingEntity</code>). Since we cannot ensure that the published
+ resource has not suffered any further modifications, <code>:_resultingEntity</code> is also a <code>prov:specializationOf</code> the resource
+ <code>ex:doc1</code>.
+ </p><p>
+ </p><div style="text-align: center;" id="figure_mapping_example">
+ <img src="img/example1.png" />
+ <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:doc1</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:doc1</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> (<code>prov:Entities</code> must exist before being used).
+
+ </p><p>
+ </p><div style="text-align: center;" id="figure_mapping_example_conflating">
+ <img src="img/mapping-example - conflating.png" />
+ <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 (as it implies that <code>ex:doc1</code> was generated by <code>_:activity</code> and then used by the same activity).
+ </div>
+ </div>
+ <p></p><p>
+ Since the first option provides a correct interpretation of the DC statements, it has been chosen as guideline in the complex mapping.
+ Blank nodes are used for the mapping, although any naming mechanism could be provided if necessary,
+ leaving the conflating of nodes to the clean-up phase.
+ </p>
+ </section>
+</section>
+
+<section id="mapping-from-dublin-core-to-prov">
+
+<!--OddPage-->
+<h2><span class="secno">3. </span>Mapping from Dublin Core to PROV</h2>
+ <p>
+ This section describes the mapping between Dublin Core and PROV. The mapping is divided in several subsections:
+ </p><ul>
+ <li> <a href="#direct-mappings">Section 3.1</a>: Direct mappings between Dublin Core and PROV.</li>
+ <li> <a href="#prov-refinements">Section 3.2</a>: Extension of PROV classes and properties to represent DC activities.</li>
+ <li> <a href="#complex-mappings">Section 3.3</a>: Complex mappings between Dublin Core and PROV (inferring activities using blank nodes).</li>
+ <li> <a href="#cleanup">Section 3.4 </a>: Strategies for cleaning up some of the blank nodes produced by the approach presented in <a href="#complex-mappings">Section 3.3</a>.</li>
+ <li> <a href="#list-of-terms-excluded-from-the-mapping">Section 3.5</a>: Rationale for the terms excluded of the mapping.</li>
+ <li> <a href="#mapping-from-prov-to-dc">Section 3.6</a>: Mapping PROV to Dublin Core (out of the scope of this mapping).</li>
+ </ul>
+ <p></p>
+ <section id="direct-mappings">
+ <h3><span class="secno">3.1 </span>Direct mappings</h3>
+ <p>
+ The direct mappings relate the DC Terms to the PROV binary relationships by using the integration mechanisms of RDF.
+ PROV applications will be able to interoperate with these DC statements by applying means of OWL 2 RL reasoning, (i.e.,
+ they will be able to understand DC statements).
+<!--The direct mappings also
+ contribute to the formal definition of the vocabularies by translating them to PROV.-->
+</p>
+ <p>Dublin Core, while less complex from a modeling perspective,
+ is more specific about the type of the activity taking place. PROV provides general attribution, and
+ the details about the kind of influence that an activity or an agent had are left to custom refinements of the PROV classes and properties.
+ </p>
+ <p>
+ <a href="#list_of_direct_terms">Table 3</a> and <a href="#list_of_direct_mappings2">Table 4</a> provide the detailed mapping plus the rationale for each term.
+ 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>.
+ </p>
+
+<!--
+ <div class="note">
+ <p>Some of the terms of the list are still under discussion: <code>dct:replaces</code> and <code>dct:isVersionOf</code>.</p>
+ </div>
+ -->
+
+ <p>
+ </p><div align="center" id="list_of_direct_terms">
+ <table>
+ <caption> <a href="#list_of_direct_terms"> Table 3:</a> Direct mappings </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/Agent">dct:Agent</a></b></td>
+ <td>owl:equivalentClass</td>
+ <td><a href="http://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_rightsHolder"><a href="http://purl.org/dc/terms/rightsHolder">dct:rightsHolder</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://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_creator"><a href="http://purl.org/dc/terms/creator">dct:creator</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
+ <td>A creator is one of the agents who participated in the creation of a resource. He has the attribution for the outcome of that activity.</td>
+ </tr>
+ <tr>
+ <td><b id="term_publisher"><a href="http://purl.org/dc/terms/publisher">dct:publisher</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasAttributedTo">prov:wasAttributedTo</a></td>
+ <td>A publisher has the attribution of the published resource after participating in the publishing activity that generated it.</td>
+ </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="http://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_isVersionOf"><a href="http://purl.org/dc/terms/isVersionOf">dct:isVersionOf</a></b></td>
+ <td>owl:equivalentProperty</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasRevisionOf</a></td>
+ <td><code>dct:isVersionOf</code> refers to "a related resource to which the current resource is a version, edition or adaptation".
+ In PROV, a revision is "a derivation for which the resulting entity is a revised version of some original". No specific attributes about revision
+ are provided, so editions and adaptations can be considered revisions as well.</td>
+ </tr>
+ <tr>
+ <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="http://www.w3.org/TR/prov-o/#isFormatOf">prov:alternateOf</a></td>
+ <td><code>dct:isFormatOf</code> refers to another resource which is the same but in another format. Thus the mapping is straightforward to <code>prov:alternateOf</code>.</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="http://www.w3.org/TR/prov-o/#alternateOf">prov:alternateOf</a></td>
+ <td> See rationale for <code>dct:isFormatOf</code>.</td>
+ </tr>
+
+<!--<tr>
+ <td><b id="term_replaces"><a href="http://purl.org/dc/terms/replaces">dct:replaces</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasInfluencedBy">prov:wasInfluencedBy</a></td>
+ <td> There is a relation between two resources when the former replaces or displaces the latter, but it is not necessarily
+ derivation, revision, specialization or alternate. For example an item of a catalog can replaced with another item
+ that had nothing to do with the former (in case of mistake of the provider of the catalogue, or catalogue renovation).
+ Thus, the term is mapped to <code>prov:wasInfluencedBy</code>.</td>
+ </tr> -->
+
+ <tr>
+ <td><b id="term_source"><a href="http://purl.org/dc/terms/source">dct:source</a> </b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#wasDerivedFrom">prov:wasDerivedFrom</a></td>
+ <td><code>dct:source</code> is defined as a "related resource from which the described resource is derived", which matches the notion of derivation
+ in PROV-DM ("a transformation of an entity in another").</td>
+ </tr>
+
+<!--<tr>
+ <td><b><a href="http://purl.org/dc/terms/type">dct:type</a></b></td>
+ <td>owl:equivalentProperty</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#type">prov:type</a></td>
+ <td>Both properties relate two resources in a similar way: the nature of the resource (or genre).</td>
+ </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="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
+ <td>Property used to describe the time of creation of a resource (i.e., the time of its generation).
+ We map it as a subproperty of <code>prov:generatedAtTime</code> because "creation" is one of the many activities that generate an entity (for example, generation includes
+ modification, issue, acceptance, etc.).
+
+<!--The rationale for this mapping is that in Dublin Core resources may have associated different dates concerning several versions of themselves
+ within the same identifier (creation, modification, issue, etc.). -->
+</td>
+
+<!-- In this case, the creation is the first date asserted to the
+ document, but doesn't necessarily correspond to the current version of the resource.-->
+
+ </tr>
+ <tr>
+ <td><b id="term_issued"><a href="http://purl.org/dc/terms/issued">dct:issued</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
+ <td>Property used to describe the date when the resource was issued. <code>dct:issued</code> is mapped as a subproperty of <code>prov:generatedAtTime</code>
+ because the issued resource is an entity itself, which has been generated at a certain time.</td>
+ </tr>
+ <tr>
+ <td><b id="term_dateAccepted"><a href="http://purl.org/dc/terms/dateAccepted">dct:dateAccepted</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
+ <td>Property used to describe the date when the resource was accepted. <code>dct:dateAccepted</code> is mapped as a subproperty of <code>prov:generatedAtTime</code>
+ because the accepted resource was generated by an "Accept" activity which may have changed it from its previous state.</td>
+ </tr>
+ <tr>
+ <td><b id="term_dateCopyrighted"><a href="http://purl.org/dc/terms/dateCopyRighted">dct:dateCopyrighted</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
+ <td>Property used to describe the date when the resource was copy righted. <code>dct:dateCopyrighted</code> is mapped as a subproperty of <code>prov:generatedAtTime</code>
+ because the copyrighted resource was generated by a "CopyRight" activity which may have changed it from its previous state.</td>
+ </tr>
+ <tr>
+ <td><b id="term_dateSubmitted"><a href="http://purl.org/dc/terms/dateSubmitted">dct:dateSubmitted</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
+ <td>Property used to describe the date when the resource was submitted. <code>dct:dateSubmitted</code> is mapped as a subproperty of <code>prov:generatedAtTime</code>
+ because the submitted resource was generated by a "Submit" activity which may have changed it from its previous state.</td>
+ </tr>
+ <tr>
+ <td><b id="term_modified"><a href="http://purl.org/dc/terms/modified">dct:modified</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#generatedAtTime">prov:generatedAtTime</a></td>
+ <td>Property used to describe the date when the resource was modified. <code>dct:modified</code> is mapped as a subproperty of <code>prov:generatedAtTime</code>
+ because the modified resource was generated by a "Modify" activity that changed it from its previous state.</td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+ It is worth mentioning that applying the direct mappings to a metadata record such as <a href="#example1">example 1</a> will infer that
+ the resource (<code>ex:doc1</code>) was <code>prov:generatedAtTime</code> at two different times (two generation dates are associated to the document:
+ <code>dct:created</code> and <code>dct:issued</code>). This is valid, since from the PROV
+ point of view the "creation" and "issue" activities generate new entities. Dublin Core, on the other hand, groups those two intermediate entities under the same resource (<code>ex:doc1</code>), creating the record exposed
+ in <a href="#example1">Example 1</a>. This approach is supported by PROV but it does not comply with all the PROV
+ constraints [<cite><a class="bibref" href="#bib-PROV-CONSTRAINTS">PROV-CONSTRAINTS</a></cite>].
+ <p></p>
+ <p>
+ Regarding the rest of the direct mappings, a property (<code>prov:hadPrimarySource</code>) has been found to be superproperty of a PROV concept, represented in <a href="#list_of_direct_mappings2">Table 4</a>:
+
+<!-- SHOULD ADD THIS FOR EACH
+ it is due to the difference between Dublin Core and PROV entities: while the former conflates more than one version or "state" of
+ the resource in a single entity, the latter proposes to separate all of them
+ <pre rel="prov:wasQuotedFrom" resource="http://dvcs.w3.org/hg/prov/raw-file/tip/examples/eg-24-prov-o-html-examples/rdf/create/rdf/property_qualifiedAttribution.ttl"
+ -->
+
+ </p>
+
+<!--
+ <div class="note">
+ <p>Some of the terms of the list are still under discussion: <code>dct:isVersionOf</code>.</p>
+ </div>
+ -->
+
+ <div id="list_of_direct_mappings2">
+ <table>
+ <caption> <a href="#list_of_direct_mappings2"> Table 4:</a> Direct mappings (2) </caption>
+ <tbody>
+ <tr>
+ <th>PROV Term</th>
+ <th>Relation</th>
+ <th>DC Term</th>
+ <th>Rationale</th>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/TR/prov-o/#hadPrimarySource">prov:hadPrimarySource</a></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><b><a href="http://purl.org/dc/terms/source">dct:source</a></b></td>
+ <td>The definition of <code>prov:hadPrimarySource</code> ("something produced by some agent with direct experience
+ 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><a href="http://www.w3.org/TR/prov-o/#wasRevisionOf">prov:wasRevisionOf</a></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><b><a href="http://purl.org/dc/terms/isVersionOf">dct:isVersionOf</a></b></td>
+ <td>Similar to the previous property, <code>prov:wasRevisionOf</code> is more restrictive in the sense that it refers to revised version of a resource, while
+ <code>dct:isVersionOf</code> involves versions, editions or adaptations of the original resource.</td>
+ </tr>-->
+
+ </tbody>
+ </table>
+ </div>
+ <p>
+ <a href="#list_of_direct_mappings_no_prov_core">Table 5</a> enumerates the mapping of the DC terms that map to inverse relationships in PROV. These
+ have been separated in a different table because they don't belong to the core of PROV.
+ </p>
+ <div id="list_of_direct_mappings_no_prov_core">
+ <table>
+ <caption> <a href="#list_of_direct_mappings_no_prov_core"> Table 5:</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 id="term_hasVersion"><a href="http://purl.org/dc/terms/hasVersion">dct:hasVersion</a></b></td>
+ <td>owl:equivalentProperty</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#hasDerivation">prov:hadRevision</a></td>
+ <td>Inverse property of <code>dct:isVersionOf</code>.</td>
+ </tr>
+
+<!--<tr>
+ <td><b id="term_isReplacedBy"><a href="http://purl.org/dc/terms/isReplacedBy">dct:isReplacedBy</a></b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td><a href="http://www.w3.org/TR/prov-o/#influenced">prov:influenced</a></td>
+ <td>Inverse property of <code>dct:replaces</code></td>
+ </tr>-->
+
+ </tbody>
+ </table>
+ </div>
+
+<!--
+ With the direct mapping, a metadata record such as <a href="#example1">example 1</a> will infer that
+ the resource was <code>prov:generatedAtTime</code> at two different times. Although this may seem inconsistent, it is supported by PROV and it is due to the difference
+ between Dublin Core and PROV resources: while the former conflates more than one version or "state" of the resource in a single entity, the latter
+ proposes to separate all of them. Thus, the mapping produces provenance that complies with the current definition of entity but
+ it does not comply with all the PROV constraints [[PROV-CONSTRAINTS]]</a>.
+ </p>
+ <p>
+ Some properties have been found to be superproperties of certain prov concepts. These can be seen below in <a href="#list_of_direct_mappings2">Table 4</a>:
+ </p>
+
+ <div id="list_of_direct_mappings2" ALIGN="center">
+ <table>
+ <caption> <a href="#list_of_direct_mappings2"> Table 4:</a> Direct mappings (2) </caption>
+ <tbody>
+ <tr>
+ <th>PROV Term</th>
+ <th>Relation</th>
+ <th>DC Term</th>
+ <th>Rationale</th>
+ </tr>
+ <tr>
+ <td>prov:hadPrimarySource</td>
+ <td>rdfs:subPropertyOf</td>
+ <td><b>dct:source</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>prov:wasRevisionOf</td>
+ <td>rdfs:subPropertyOf</td>
+ <td><b>dct:isVersionOf</b></td>
+ <td>Similar to the previous property, <code>prov:wasRevisionOf</code> is more restrictive in the sense that it refers to revised version of a resource, while
+ <code>dct:isVersionOf</code> involves versions, editions or adaptations of the original resource.</td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+ <p>
+ <a href="#list_of_direct_mappings_no_prov_core">Table 5</a> enumerates the mapping of the <code>dct</code> properties that map to inverse relationships in PROV. These
+ have been separated in a different table because they don't belong to the core of PROV.
+ </p>
+ <div id="list_of_direct_mappings_no_prov_core" ALIGN="center">
+ <table>
+ <caption> <a href="#list_of_direct_mappings_no_prov_core"> Table 5:</a> Direct mappings to the PROV terms not included in the core </caption>
+ <tbody>
+ <tr>
+ <th>PROV Term</th>
+ <th>Relation</th>
+ <th>DC Term</th>
+ <th>Rationale</th>
+ </tr>
+ <tr>
+ <td><b>dct:hasVersion</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:hadDerivation</td>
+ <td>Inverse property of <code>dct:isVersionOf</code>.</td>
+ </tr>
+ <tr>
+ <td><b>dct:isReplacedBy</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:influenced</td>
+ <td>Inverse property of <code>dct:replaces</code></td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+ -->
+
+ </section>
+ <section id="prov-refinements">
+ <h3><span class="secno">3.2 </span>PROV refinements</h3>
+ <p>
+ To properly reflect the meaning of the Dublin Core terms, more specific subclasses are needed:
+ </p><p>
+ </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:Modify rdfs:subClassOf prov:Activity .
+ prov:Accept rdfs:subClassOf prov:Activity .
+ prov:Copyright rdfs:subClassOf prov:Activity .
+ prov:Submit rdfs:subClassOf prov:Activity .
+ prov:Publisher rdfs:subClassOf prov:Role .
+ prov:Contributor rdfs:subClassOf prov:Role .
+ prov:Creator rdfs:subClassOf prov:Role, prov:Contributor .
+ </pre>
+ <p></p>
+
+ <p>
+ Custom refinements of the properties have been omitted as they would be identical to the DC terms. If these more
+ specific properties are needed, the Dublin Core terms can be used directly, according to the direct mappings presented in
+ <a href="#direct-mappings">Section 3.1</a>.
+ </p>
+ </section>
+ <section 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 Dublin Core statements. This type of qualification may not be
+ always needed, and it is the choice of the implementer whether to use them or not depending on the use case. It is also important to note that not all the
+ direct mappings have a complex mapping associated, just those which imply a specific activity: creation, publication, etc.
+ The complex mappings are provided in form of SPARQL CONSTRUCT queries, i.e., queries that describe a
+ resulting RDF graph based on another RDF graph found in the original data. We divide the queries in 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 corresponds to the graph in <a href="#figure_mapping_example">Figure 1</a> (with small changes
+ for creator and rightsHolder). With this mapping,
+ the difference in the complexity becomes obvious. Many blank nodes are created, so a subsequent clean-up 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.
+
+<!--Sometimes URIs for the specializations are also available and simply not exposed to the Dublin Core record.-->
+
+ 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 "Create" activity that generated a specialization of the entity ?document. The agent is assigned the role "creator".
+ <pre class="code"> CONSTRUCT {
+ ?document a prov:Entity ;
+ prov:wasAttributedTo ?agent.
+
+ ?agent a prov:Agent .
+
+ _:activity a prov:Activity, prov:Create ;
+ prov:wasAssociatedWith ?agent;
+ prov:qualifiedAssociation [
+ a prov:Association;
+ prov:agent ?agent;
+ prov:hadRole prov:Creator .
+ ].
+
+ _:resulting_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasAttributedTo ?agent.
+
+ } WHERE {
+ ?document dct:creator ?agent.
+ }
+ </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 prov:Contributor .
+ ].
+
+ _:resulting_entity 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 .
+
+ _:used_entity a prov:Entity;
+ prov:specializationOf ?document.
+
+ _:activity a prov:Activity, prov:Publish ;
+ prov:used _:used_entity;
+ prov:wasAssociatedWith ?agent ;
+ prov:qualifiedAssociation [
+ a prov:Association ;
+ prov:agent ?agent ;
+ prov:hadRole prov:Publisher .
+ ].
+
+ _:resulting_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasDerivedFrom _:used_entity
+ prov:wasGeneratedBy _:activity ;
+ prov:wasAttributedTo ?agent .
+
+ } WHERE {
+ ?document dct:publisher ?agent .
+ }
+ </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, e.g., creator and created or publisher and issued.
+ Therefore, they lead to similar complex patterns (associating a date to each activity instead of an agent).
+ When using Dublin Core terms, it is usual to see that a resource is annotated with several <code>dct</code> assertions like creator, publisher,
+ issued, date, etc. In this section each term is treated independently. It is important to note that since the range for dates in Dublin Core is a
+ <code>rdfs:Literal</code> and <code>xsd:dateTime</code> for the <code>prov:atTime</code> property, the mapping is only valid for those literals
+ that are <code>xsd:dateTime</code>.
+ </p>
+
+ <section id="dct-created">
+ <h5><span class="secno">3.3.2.1 </span> dct:created</h5>
+ <p></p>
+ <pre class="code"> CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:Create ;
+
+ # The “output”
+ _:created_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasGeneratedAtTime ?date;
+ prov:qualifiedGeneration [
+ a prov:Generation ;
+ prov:atTime ?date ;
+ prov:activity _:activity .
+ ] .
+ } WHERE {
+ ?document dct:created ?date.
+ }
+ </pre>
+ </section>
+
+ <section id="dct-issued">
+ <h5><span class="secno">3.3.2.2 </span>dct:issued</h5>
+ <p>
+ </p><pre class="code"> CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:Publish ;
+ prov:used _:used_entity .
+
+ # The “input”
+ _:used_entity a prov:Entity .
+ prov:specializationOf ?document .
+
+ # The “output”
+ _:iss_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasGeneratedAtTime ?date;
+ prov:wasDerivedFrom _:used_entity ;
+ prov:qualifiedGeneration [
+ a prov:Generation ;
+ prov:atTime ?date ;
+ prov:activity _:activity .
+ ] .
+ } WHERE {
+ ?document dct:issued ?date.
+ }
+ </pre>
+ <p></p>
+ </section>
+ <section id="dct-modified">
+ <h5><span class="secno">3.3.2.3 </span>dct:modified</h5>
+ <p></p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:Modify ;
+ prov:used _:used_entity .
+
+ # The “input”
+ _:used_entity a prov:Entity .
+ prov:specializationOf ?document .
+
+ # The “output”
+ _:modified_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasGeneratedAtTime ?date;
+ prov:wasDerivedFrom _:used_entity ;
+ prov:qualifiedGeneration [
+ a prov:Generation ;
+ prov:atTime ?date ;
+ prov:activity _:activity .
+ ] .
+ } WHERE {
+ ?document dct:modified ?date.
+ }
+ </pre>
+ <p></p>
+ </section>
+ <section id="dct-dateaccepted">
+ <h5><span class="secno">3.3.2.4 </span>dct:dateAccepted</h5>
+ <p></p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:Accept ;
+ prov:used _:used_entity .
+
+ # The “input”
+ _:used_entity a prov:Entity .
+ prov:specializationOf ?document .
+
+ # The “output”
+ _:accepted_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasGeneratedAtTime ?date;
+ prov:wasDerivedFrom _:used_entity ;
+ prov:qualifiedGeneration [
+ a prov:Generation ;
+ prov:atTime ?date ;
+ prov:activity _:activity .
+ ] .
+ } WHERE {
+ ?document dct:dateAccepted ?date.
+ }
+ </pre>
+ <p></p>
+ </section>
+ <section id="dct-datecopyrighted">
+ <h5><span class="secno">3.3.2.5 </span>dct:dateCopyrighted</h5>
+ <p></p><pre class="code">CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:Copyright ;
+ prov:used _:used_entity .
+
+ # The “input”
+ _:used_entity a prov:Entity .
+ prov:specializationOf ?document .
+
+ # The “output”
+ _:copyrighted_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasGeneratedAtTime ?date;
+ prov:wasDerivedFrom _:used_entity ;
+ prov:qualifiedGeneration [
+ a prov:Generation ;
+ prov:atTime ?date ;
+ prov:activity _:activity .
+ ] .
+ } WHERE {
+ ?document dct:dateCopyrighted ?date.
+ }
+ </pre><p></p>
+ </section>
+ <section id="dct-datesubmitted">
+ <h5><span class="secno">3.3.2.6 </span>dct:dateSubmitted</h5>
+ <p></p><pre class="code"> CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:Submit ;
+ prov:used _:used_entity .
+
+ # The “input”
+ _:used_entity a prov:Entity .
+ prov:specializationOf ?document .
+
+ # The “output”
+ _:submitted_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasGeneratedAtTime ?date;
+ prov:wasDerivedFrom _:used_entity ;
+ prov:qualifiedGeneration [
+ a prov:Generation ;
+ prov:atTime ?date ;
+ prov:activity _:activity .
+ ] .
+ } WHERE {
+ ?document dct:dateSubmitted ?date.
+ }
+ </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 Dublin Core, most of the properties relating entities to other entities don't describe the involvement of a specific activity
+ (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. The replacement is
+ the result of a "search and replace" Activity, which used a specialization of the replaced entity (<code>_:old_entity</code>) and
+ produced a specialization of the replacement (<code>_:new_entity</code>). Thus, <code>_:new_entity</code> was derived from
+ <code>_:old_entity</code>, as it couldn't have existed without it. However, the derivation relationship cannot always be applied between the original entities, because they
+ could have existed before the replacement took place (for example, if a book replaces another in a catalog we cannot say that it was
+ derived from it).
+ </p>
+ <p>
+ </p><pre class="code">CONSTRUCT{
+ ?document a prov:Entity .
+ ?document2 a prov:Entity.
+
+ _:activity a prov:Activity, prov:Replace ;
+ prov:used _:old_entity.
+
+ # The “input”
+ _:old_entity a prov:Entity;
+ prov:specializationOf ?document2 ;
+
+ # The “output”
+ _:new_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity;
+ prov:wasDerivedFrom _:old_entity .
+
+ } WHERE {
+ ?document dct:replaces ?document2.
+ }
+ </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 clean-up phase depends on how implementers interpret the described resources. The approach presented in this document
+ leads to the proliferation of blank nodes. Blank nodes could be renamed to specific identifiers
+ by the implementer, in order to avoid obtaining additional blank nodes when reapplying the construct queries presented
+ in the previous section.</p>
+ <p> Providing a set of rules to conflate the blank nodes is not in the scope of this document. However, the group has
+ created a list of 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 Dublin Core certain properties complement each other (e.g.,
+ creator and created, publisher and issued, modified and contributor, etc.). By combining some of the queries, some of the records
+ could be grouped creating more complete PROV assertions.</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 prov:Creator .
+ ] .
+
+ # The “output”
+ _:created_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasGeneratedAtTime ?date;
+ prov:qualifiedGeneration [
+ a prov:Generation ;
+ prov:atTime ?date ;
+ prov:activity _:activity .
+ ] .
+ } WHERE {
+ ?document dct:creator ?agent;
+ dct:created ?date.
+ }
+ </pre>
+ <a href="#figure_cleanup1">Figure 3</a> shows a graphical representation of the pattern:
+
+ <div style="text-align: center;" id="figure_cleanup1">
+ <img src="img/cleanup1.png" />
+ <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 blank
+ nodes result of one activity with the input of the subsequent activity.
+<!-- in case they are both specializations of the same entity -->
+
+ <a href="#figure_cleanup2">Figure 4</a> shows a graphical example with two different activities (creation and publication) that happened at different
+ points in time. Creation precedes publication, so instead of creating different blank nodes for their respective usage and generation, both activities share the same
+ blank node (<code>_:created_entity</code>).
+ </p><div style="text-align: center;" id="figure_cleanup2">
+ <img src="img/cleanup2.png" />
+ <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>
+
+<!--<p>3) Finally, another solution is to <b>ignore all the specializations of <code>ex:doc1</code> and use the resource itself</b>. This solution
+ would avoid the majority of the blank nodes, linking all the activities with the resource. However, the results would be confusing in
+ case there are several Dublin Core statements describing the same resource (like <code>dct:publisher</code> and <code>creator</code>), since most of the
+ activities would use and generate the same resource at different times (all the provenance of the different versions of the resource
+ would be conflated in the same entity). A graphical representation of an example can be seen in <a href="#figure_mapping_example_conflating">Figure 2</a>.
+ </p>
+ <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>
+ <a href="#list-of-terms-excluded-from-the-mapping"> Table 6</a> lists the terms excluded from the mapping,
+ either because thay are not suitable or because they don't represent provenance information.
+
+<!--
+ <div class="note">
+ <p>Some of the terms of the list are still under discussion: <code>dct:alternative</code> and <code>dct:references</code>.</p>
+ </div>
+ -->
+
+ <p>
+ </p><table>
+ <caption> <a href="#list-of-terms-excluded-from-the-mapping"> Table 6:</a> List of terms excluded from the mapping </caption>
+ <tbody>
+ <tr>
+ <th>Term</th>
+ <th>Category</th>
+ <th>Rationale</th>
+ </tr><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_accrualMethod"><a href="http://purl.org/dc/terms/accrualMethod">dct:accrualMethod</a></b></td>
+ <td>Descriptive Metadata</td>
+ <td>Method by which items are added to a collection. It doesn't describe the action itself, so it is out of the scope of the mapping.</td>
+ </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_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 to.</td>
+ </tr><tr>
+ <td><b id="term_extent"><a href="http://purl.org/dc/terms/extent">dct:extent</a></b></td>
+ <td>Descriptive metadata</td>
+ <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_identifier"><a href="http://purl.org/dc/terms/identifier">dct:identifier</a></b></td>
+ <td>Descriptive metadata</td>
+ <td>An unambiguous reference on 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>Method used to create the knowledge that the resource is supposed 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
+ the provenance of the reosource, since it refers to something that may not have happened yet (e.g., a library dependency in script program).</td>
+ </tr><tr>
+ <td><b id="term_language"><a href="http://purl.org/dc/terms/language">dct:language</a></b></td>
+ <td>Descriptive metadata</td>
+ <td>Language of the resource.</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_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_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_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_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 id="term_references"><b><a href="http://purl.org/dc/terms/references">dct:references</a></b></td>
+ <td> Provenance: How </td>
+ <td>Term used to point out, refer or cite a related resource to the resource being described. The references normally point
+ out to resources from which the current resource was derived, or that the current resource quoted. However, this is not
+ always the case. For example, if a resource A included a reference
+ to a resource B stating :"Reference [B] has nothing to do with the work described here", then we cannot consider the reference as a derivation
+ or a quotation. For this reason, <code>dct:references</code> has been dropped from the mapping.</td>
+ </tr><tr>
+ <td id="term_isReferencedBy"><b><a href="http://purl.org/dc/terms/isReferencedBy">dct:isReferencedBy</a></b></td>
+ <td> Provenance: How </td>
+ <td>Inverse to <code>dct:references</code>.</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_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_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_date"><a href="http://purl.org/dc/terms/date">dct:date</a></b></td>
+ <td>Provenance: When</td>
+ <td>Date is a very general property. It is the superproperty which all the other dates specialize, but there is no equivalent concept in PROV. It has been excluded from the mapping.</td>
+ </tr><tr>
+ <td><b id="term_available"><a href="http://purl.org/dc/terms/available">dct:available</a></b></td>
+ <td>Provenance: When</td>
+ <td>Property that states when a resource is available. There is no direct mapping between this property and the notion of invalidation in PROV.</td>
+ </tr><tr>
+ <td><b id="term_valid"><a href="http://purl.org/dc/terms/valid">dct:valid</a></b></td>
+ <td>Provenance: When</td>
+ <td>Property that states when a resource is valid. The notion of invalidation is defined in PROV-DM, but not the notion of validation. Thus this property is left out of the mapping.</td>
+ </tr><tr>
+ <td><b id="term_relation"><a href="http://purl.org/dc/terms/relation">dct:relation</a></b></td>
+ <td>Provenance </td>
+ <td>A related resource. This relationship is very broad and could relate either provenance resources or not.
+ Therefore it could be seen as a superproperty of <code>prov:wasDerivedFrom</code>, <code>prov:wasInfluencedBy</code>, <code>prov:alternateOf</code>, <code>prov:specializationOf</code>, etc. </td><td>
+ </td></tr>
+ <tr>
+ <td><b id="term_provenance"><a href="http://purl.org/dc/terms/provenance">dct:provenance</a></b></td>
+ <td>Provenance </td>
+ <td>This term is a link between the resource and any provenance statement about the resource. Since PROV-O doesn't specify any mechanisms to link a bundle of provenance statements to an entity,
+ this term is considered out of the scope of the mapping.</td><td>
+ </td></tr>
+ </tbody></table>
+ <p></p>
+ </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 Dublin Core is not part of this note. If the refinements proposed in this document are used, then the inverse of the complex mapping
+ patterns can be applied.
+ However, if the refinements are not used then only a few Dublin Core statements can be inferred from plain PROV statements.
+ For example, when mapping dates only unqualified properties can be extracted,
+ as there is no information if an activity with an associated date is a creation or a modification or a publication. Likewise, the agents
+ involved cannot be mapped to creators, contributors, or publishers. While Dublin Core includes provenance information, its focus
+ lies on the broader description of resources. PROV models a provenance chain, but it provides almost no information about the involved
+ resources themselves.
+ </p>
+ </section>
+ </section>
+
+ <section class="appendix" id="acknowledgements">
+
+<!--OddPage-->
+<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 and Satya Sahoo for their feedback; and María Poveda and Idafen Santana for their help with the HTML generation.
+ </p>
+ </section>
+
+<section id="references" class="appendix">
+<!--OddPage-->
+<h2><span class="secno">B. </span>References</h2><section id="informative-references"><h3><span class="secno">B.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>Dublin Core Terms Vocabulary</cite></a>. 8 December 2010. URL: <a href="http://dublincore.org/documents/dcmi-terms/">http://dublincore.org/documents/dcmi-terms/</a>
+</dd><dt id="bib-OWL2-OVERVIEW">[OWL2-OVERVIEW]</dt><dd>W3C OWL Working Group. <a href="http://www.w3.org/TR/2009/REC-owl2-overview-20091027/"><cite>OWL 2 Web Ontology Language: Overview</cite></a>. 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-overview-20091027/">http://www.w3.org/TR/2009/REC-owl2-overview-20091027/</a>
+</dd><dt id="bib-PROV-AQ">[PROV-AQ]</dt><dd>Graham Klyne; Paul Groth; eds. <a href="http://www.w3.org/TR/2013/WD-prov-aq-20130312/"><cite>Provenance Access and Query</cite></a>. 12 March 2013, Working Draft. URL: <a href="http://www.w3.org/TR/2013/WD-prov-aq-20130312/">http://www.w3.org/TR/2013/WD-prov-aq-20130312/</a>
+</dd><dt id="bib-PROV-CONSTRAINTS">[PROV-CONSTRAINTS]</dt><dd>James Cheney; Paolo Missier; Luc Moreau; eds. <a href="http://www.w3.org/TR/2013/PR-prov-constraints-20130312/"><cite>Constraints of the PROV Data Model</cite></a>. 12 March 2013, W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2013/PR-prov-constraints-20130312/">http://www.w3.org/TR/2013/PR-prov-constraints-20130312/</a>
+</dd><dt id="bib-PROV-DICTIONARY">[PROV-DICTIONARY]</dt><dd>Tom De Nies; Sam Coppens; eds. <a href="http://www.w3.org/TR/2013/WD-prov-dictionary-20130312/"><cite>PROV Dictionary</cite></a>. 12 March 2013, Working Draft. URL: <a href="http://www.w3.org/TR/2013/WD-prov-dictionary-20130312/">http://www.w3.org/TR/2013/WD-prov-dictionary-20130312/</a>
+</dd><dt id="bib-PROV-DM">[PROV-DM]</dt><dd>Luc Moreau; Paolo Missier; eds. <a href="http://www.w3.org/TR/2013/PR-prov-dm-20130312/"><cite>PROV-DM: The PROV Data Model</cite></a>. 12 March 2013, W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2013/PR-prov-dm-20130312/">http://www.w3.org/TR/2013/PR-prov-dm-20130312/</a>
+</dd><dt id="bib-PROV-LINKS">[PROV-LINKS]</dt><dd>Luc Moreau; Timothy Lebo; eds. <a href="http://www.w3.org/TR/2013/WD-prov-links-20130312/"><cite>Linking Across Provenance Bundles</cite></a>. 12 March 2013, Working Draft. URL: <a href="http://www.w3.org/TR/2013/WD-prov-links-20130312/">http://www.w3.org/TR/2013/WD-prov-links-20130312/</a>
+</dd><dt id="bib-PROV-N">[PROV-N]</dt><dd>Luc Moreau; Paolo Missier; eds. <a href="http://www.w3.org/TR/2013/PR-prov-n-20130312/"><cite>PROV-N: The Provenance Notation</cite></a>. 12 March 2013, W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2013/PR-prov-n-20130312/">http://www.w3.org/TR/2013/PR-prov-n-20130312/</a>
+</dd><dt id="bib-PROV-O">[PROV-O]</dt><dd>Timothy Lebo; Satya Sahoo; Deborah McGuinness; eds. <a href="http://www.w3.org/TR/2013/PR-prov-o-20130312/"><cite>PROV-O: The PROV Ontology</cite></a>. 12 March 2013, W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2013/PR-prov-o-20130312/">http://www.w3.org/TR/2013/PR-prov-o-20130312/</a>
+</dd><dt id="bib-PROV-OVERVIEW">[PROV-OVERVIEW]</dt><dd>Paul Groth; Luc Moreau; eds. <a href="http://www.w3.org/TR/2013/WD-prov-overview-20130312/"><cite>PROV-OVERVIEW: An Overview of the PROV Family of Documents</cite></a>. 12 March 2013, Working Draft. URL: <a href="http://www.w3.org/TR/2013/WD-prov-overview-20130312/">http://www.w3.org/TR/2013/WD-prov-overview-20130312/</a>
+</dd><dt id="bib-PROV-PRIMER">[PROV-PRIMER]</dt><dd>Yolanda Gil; Simon Miles; eds. <a href="http://www.w3.org/TR/2013/WD-prov-primer-20130312/"><cite>PROV Model Primer</cite></a>. 12 March 2013, Working Draft. URL: <a href="http://www.w3.org/TR/2013/WD-prov-primer-20130312/">http://www.w3.org/TR/2013/WD-prov-primer-20130312/</a>
+</dd><dt id="bib-PROV-XML">[PROV-XML]</dt><dd>Hook Hua; Curt Tilmes; Stephan Zednik; eds. <a href="http://www.w3.org/TR/2013/WD-prov-xml-20130312/"><cite>PROV-XML: The PROV XML Schema</cite></a>. 12 March 2013, Working Draft. URL: <a href="http://www.w3.org/TR/2013/WD-prov-xml-20130312/">http://www.w3.org/TR/2013/WD-prov-xml-20130312/</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="http://www.w3.org/TR/2004/REC-rdf-schema-20040210">http://www.w3.org/TR/2004/REC-rdf-schema-20040210/</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file