--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/dc-note.html Fri Nov 30 12:57:38 2012 +0100
@@ -0,0 +1,1590 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>Dublin Core to Prov Mapping</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+ <!-- PM -->
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+ <script src="http://www.w3.org/2007/OWL/toggles.js"></script>
+ <script src="http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js" class="remove"></script>
+
+ <script src="../model/provbib.js" class="remove"></script>
+ <!-- check why this import doesn't work <script src="../model/prov-magic.js" class="remove"></script>-->
+ <script class="remove">
+ var addExtraReferences = function() {
+ for (var k in extraReferences)
+ berjon.biblio[k] = extraReferences[k];
+ };
+ var extraReferences = {
+ "DCMI":
+ "<a href=\"http://dublincore.org/\"><cite>Dublin Core Metadata Initiative</cite></a>. "+
+ "URL: <a href=\"http://dublincore.org/\">http://dublincore.org/</a>",
+
+ "DCTERMS":
+ "<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>"
+ };
+
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ //specStatus: "WD-NOTE",
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "prov-dc",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ subtitle : "",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ //previousPublishDate: "2012-07-24",
+ //previousMaturity: "WD-NOTE",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/dc-note.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Daniel Garijo", url: "http://delicias.dia.fi.upm.es/members/DGarijo/",
+ company: "Universidad Politécnica de Madrid, Spain" },
+ { name: "Kai Eckert", url: "http://www.kaiec.org/",
+ company: "Manheim University Library, Germany" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ authors: [
+ { name: "<a href=\"http://www.inf.kcl.ac.uk/staff/simonm\">Simon Miles</a>",
+ company: "King's College London, UK" },
+ { name: "Craig M. Trim",
+ company: "IBM, USA" },
+ { name: "Michael Panzer",
+ company: "OCLC Online Computer Library center, USA" },
+ ],
+
+ // name of the WG
+ wg: "Provenance Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/prov/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-prov-comments",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/46974/status",
+
+ // Add extraReferences to bibliography database
+ preProcess: [addProvReferences,addExtraReferences]//,setContributors]
+ };
+ </script>
+ <style type="text/css">
+ /*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- 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;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl:before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID, .idlDictionaryID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType, .idlMemberType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName, .idlMemberName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a, .idlMemberName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code, .dictionary-members dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
+ margin-bottom: 1em;
+}
+
+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%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- 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;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.code {
+ background-color:#F9F9F9;
+ border:1px dashed #2F6FAB;
+ color:black;
+ line-height:1.1em;
+ padding:1em;
+}
+
+pre.example:before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue:before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note:before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+ </style>
+</head>
+ <body style="display: inherit;">
+ <section id="abstract">
+ <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 direct mappings are available <a href="http://dvcs.w3.org/hg/prov/raw-file/e3d298ff8c78/dc-note/files/DirectMappings.ttl">here</a>.
+ </p>
+ <p style="text-align: center;">
+ The prov refinements for Dublin Core can be accessed here <a href="http://dvcs.w3.org/hg/prov/raw-file/e3d298ff8c78/dc-note/files/Refinements.ttl">here</a>.
+ </p>
+ </section>
+ <section id="sotd">
+ <h4>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:
+ <ul>
+ <li> <a href="http://www.w3.org/TR/2012/WD-prov-overview-20121211/">PROV-OVERVIEW</a> (Note), an overview of the PROV family of documents [[PROV-OVERVIEW]];</li>
+ <li> <a href="http://www.w3.org/TR/2012/WD-prov-primer-20121211/">PROV-PRIMER</a> (Note), a primer for the PROV data model [[PROV-PRIMER]];</li>
+ <li> <a href="http://www.w3.org/TR/2012/CR-prov-o-20121211/">PROV-O</a> (Recommendation), the PROV ontology, an OWL2 ontology allowing the mapping of PROV to RDF [[!PROV-O]];</li>
+ <li> <a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/">PROV-DM</a> (Recommendation), the PROV data model for provenance [[PROV-DM]];</li>
+ <li> <a href="http://www.w3.org/TR/2012/CR-prov-n-20121211/">PROV-N</a> (Recommendation), a notation for provenance aimed at human consumption [[!PROV-N]];</li>
+ <li> <a href="http://www.w3.org/TR/2012/CR-prov-constraints-20121211/">PROV-CONSTRAINTS</a> (Recommendation), a set of constraints applying to the PROV data model [[!PROV-CONSTRAINTS]];</li>
+ <li> <a href="http://www.w3.org/TR/2012/WD-prov-aq-20120619/">PROV-AQ</a> (Note), the mechanisms for accessing and querying provenance [[PROV-AQ]]; </li>
+ <li> <a href="http://www.w3.org/TR/2012/WD-prov-xml-20121211/">PROV-XML</a> (Note), an XML schema for the PROV data model [[PROV-XML]].</li>
+ <li> <a href="http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/dc-note.html">PROV-DC</a> (Note), a mapping between Dublin Core and PROV (this document).</li>
+
+ </ul>
+ <h4>How to read the PROV Family of Documentation</h4>
+ <ul>
+ <li>The primer is the entry point to PROV offering an introduction to the provenance model.</li>
+ <li>The Linked Data and Semantic Web community should focus on PROV-O defining PROV classes and properties specified in an OWL2 ontology. For further details, PROV-DM and PROV-CONSTRAINTS specify the constraints applicable to the data model, and its interpretation. </li>
+ <li>Developers seeking to retrieve or publish provenance should focus on PROV-AQ.</li>
+ <li>Readers seeking to implement other PROV serializations
+ should focus on PROV-DM and PROV-CONSTRAINTS. PROV-O and PROV-N offer examples of mapping to RDF and text, respectively.</li>
+ </section>
+
+ <section>
+<h2>Introduction</h2>
+
+ <p>
+ The Dublin Core Metadata Initiative (DCMI) [[DCMI]] provides a core metadata vocabulary,
+ commonly referred to as Dublin Core. The original element set, from 1995, 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" and currently consists of 55 properties [[DCTERMS]].
+ </p>
+ The use of DCMI terms is preferred and the Dublin Core element set has been depecreated.
+ Both element 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 newer DCMI element set.
+ </p>
+ <p>
+ DCMI terms hold a lot of provenance information and tell us 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.
+ There is no direct information in Dublin Core describing <i>where</i> a resource was affected. Such information is usually
+ only available for the publication of a resource (i.e., an action located at the address of the publisher).
+ </p>
+ <p>
+ A classification of the <code>dct</code> terms is provided in <a href="#categories">Table 1</a>. This classification is by necessity
+ somewhat conservative, as it can be argued that elements placed in the description metadata terms contain
+ provenance information as well, depending on their usage. Based on this, 25 (out of 55) terms can be considered as
+ provenance related. These terms can be further categorized according to the question they answer regarding the
+ provenance of a resource:
+ </p><p>
+
+ <b>Dates and Time terms (When?):</b>This category contains date and time related terms.
+ Dates typically belong to the provenance record of a resource. 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. Two dates can be considered special regarding their relevance for
+ provenance: <code>dct:available</code> and <code>dct:valid</code>. They are different from the other dates as by definition they can represent a
+ date range. Often, the range of availability or validity of a resource is inherent to the resource and known
+ beforehand – consider the validity of a passport or the availability of a limited special offer published on the web.
+ In these cases, there is no action involved that makes the resource invalid or unavailable, it is simply determined
+ by the validity range. On the other hand, if an action is involved, e.g., a resource is declared invalid because
+ a mistake has been found, then it is relevant for its provenance.
+ </p><p>
+
+ <b>Agency Terms (Who?):</b> This category contains agent related terms. All properties that 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>Derivation Terms (How?):</b> This category contains derivation related terms.
+ Resources are often derived from other resources. In this case, the original resource becomes part of the provenance
+ record of the derived resource. Derivations can be further classified as <code>dct:isVersionOf, dct:isFormatOf, dct:replaces, dct:source</code>.
+ <code>dct:references</code> is a weaker relation, 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 – at most indirectly, as the validity state can change if a resource is replaced by a new
+ version. However, inverse properties belong to the provenance related terms as they can be used to describe the relations
+ between the resources involved. Finally, licensing and rights are considered part of the provenance of the resource as well,
+ since they restrict how the resource has been used by its owners.
+ </p>
+ <div id="categories" ALIGN="center">
+ <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_accessRights">accessRights</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_rights_holder">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_has_Version">isVersionOf</a>, <a href="#term_has_Version">hasVersion</a>, <a href="#term_has_Format">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: <i>provenance</i>. 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" [[DC-TERMS]],
+ which corresponds to the traditional definition of provenance for artworks. 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>
+ An example of a simple metadata record annotated with <code>dct</code> terms can be seen below:
+ </p><p>
+ <a href="#example1">Example 1</a>: a simple metadata record:
+ <pre class="example" id="example1">
+ 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>
+ 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
+ the document to another document <code>ex:doc2</code> which had probably
+ some kind of influence on <code>ex:doc1</code>.
+ </p>
+ <h3 id ="namespaces">1.1 Namespaces</h3>
+ <p>The namespaces used through the document can be seen in <a href="#ns"> Table 2</a> below:
+ <div id="ns" ALIGN="center">
+ <table>
+ <caption> <a href="#ns"> Table 2</a>: Namespaces used in the document </caption>
+ <tbody>
+ <tr><td><b>owl</b></td><td><http://www.w3.org/2002/07/owl#></td></tr>
+ <tr><td><b>rdfs</b></td><td><http://www.w3.org/2000/01/rdf-schema#></td></tr>
+ <tr><td><b>prov</b></td><td><http://www.w3.org/ns/prov#></td></tr>
+ <tr><td><b>dct</b></td><td><http://purl.org/dc/terms/></td></tr>
+ </tbody>
+ </table>
+ </div>
+ </p>
+ </div>
+</section>
+
+<section>
+ <h2>Mapping from Dublin Core to PROV</h2>
+ <p>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>
+ <section>
+ <h3>Basic considerations </h3>
+ <p>
+ Substantially, a complete mapping from Dublin Core to PROV consists of three parts:
+ </p><p>
+ 1) <b>Direct mappings</b> between terms that can be expressed in form of subclass or subproperty relationships in RDFS
+ – or equivalent relationships in OWL.
+ </p><p>
+ 2) Definition of new <b>refinements</b> (subclasses or subproperties) of the target vocabulary to reflect the expressiveness of the source vocabulary.
+ </p><p>
+ 3) Provision of <b>complex mappings</b> that create statements in the target vocabulary based on statements in the source vocabulary. Since
+ the mapping produces blank nodes for each <code>dct</code> statement, a clean-up phase with strategies for reducing the blank nodes is also necessary.
+ </p>
+ <p>
+ </section>
+ <section>
+ <h3>What is ex:doc1? Entities in Dublin Core</h3>
+ <p>
+ Consider the example metadata record shown at the beginning of this document (in <a href="#example1">example 1</a>). As a <code>dc</code>
+ metadata record describes the resulting 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 specialization of the document, even if the document
+ has not changed. Generally, there are two possibilities to deal with this issue:</p>
+ </p><p>
+ 1) Create new instances of entities, typically as blank nodes, that are all related to the original
+ document by means of <code>prov:specializationOf</code>. This leads to bloated and not very intuitive data models, e.g. think
+ about the translation of a single <code>dct:publisher</code> statement, where anyone would expect to somehow find some activity and
+ agent that are directly related to the document (as in <a href="#figure_mapping_example">Figure 1</a>).
+ </p><p>
+ <div id = "figure_mapping_example" class="figure" style="text-align: center;">
+ <img src="img/example1.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_mapping_example">Figure 1</a>. A mapping example creating blank nodes for each state of the resource. In PROV entities are represented
+ with ellipses, activities with rectangles and agents with pentagons.
+ </div>
+ </div>
+ </p><p>
+ 2) Use the original resource (<code>ex:doc1</code>) as the instance used and generated as <code>prov:Entity</code>. However, to have an activity that uses
+ an entity and generates the same entity or to have different activities that generate the same entity at different points in time
+ is not compliant with the PROV constraints [[PROV-CONSTRAINTS]]. <a href="#figure_mapping_example_conflating">Figure 2</a>
+ provides an example that illustrates this approach.
+ </p><p>
+ <div id = "figure_mapping_example_conflating" class="figure" style="text-align: center;">
+ <img src="img/mapping-example - conflating.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes in the same resource. The used and generated resources have the same identifier.
+ </div>
+ </div>
+ </p><p>
+ Since the first option is the most conservative with respect to the underlying semantics, 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>
+ <h3></span>Direct mappings</h3>
+ <p>
+ The direct mappings provide basic interoperability using the integration mechanisms of RDF. By means
+ of OWL 2 RL reasoning, any PROV application can at least make some sense from Dublin Core data. 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_excluded_terms">list of terms left out of the mapping</a>.
+ </p><p>
+ <div id="list_of_direct_terms" ALIGN="center">
+ <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>dct:Agent</b></td>
+ <td>owl:equivalentClass</td>
+ <td> prov:Agent.</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).</td>
+ </tr>
+ <tr>
+ <td><b>dct:rightsHolder</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>The rights holder has the attribution of the activity that created the licensed resource.</td>
+ </tr>
+ <tr>
+ <td><b>dct:creator</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>A creator is the agent who created the resource. He is the one involved in the creation activity that led to the resource.
+ He has the attribution for that activity</td>
+ </tr>
+ <tr>
+ <td><b>dct:publisher</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>A publisher has the attribution of the publishing activity that led to the published resource.</td>
+ </tr>
+ <tr>
+ <td><b>dct:contributor</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>A contributor is involved either in the creation activity or in the updating of the resource. Therefore he/she is attributed to take
+ part in those activities.</td>
+ </tr>
+ <tr>
+ <td><b>dct:isVersionOf</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasDerivedFrom</td>
+ <td><code>dct:isVersionOf</code> refers to "a related resource to which the current resource is a version, edition or adaptation".
+ Hence the current resource has been derived from the original one.</td>
+ </tr>
+ <tr>
+ <td><b>dct:isFormatOf</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:alternateOf</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>dct:hasFormat</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:alternateOf</td>
+ <td> See rationale for <code>dct:isFormatOf</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:replaces</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasInfluencedBy</td>
+ <td>This mapping is not straightforward. There is a relation between two resources when the former replaces the latter, but it is not necessarily
+ derivation, revision, specification or alternate. Thus, the term is mapped to <code>prov:wasInfluencedBy</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:source </b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasDerivedFrom</td>
+ <td>In Dublin Core, <code>dct:source</code> is defined as a "related resource from which the described resource is derived", which matches the notion of derivation
+ in PROV-DM ("a transformation of an entity in another")</td>
+ </tr>
+ <tr>
+ <td><b>dct:type</b></td>
+ <td>owl:equivalentProperty</td>
+ <td>prov:type</td>
+ <td>Both properties relate two resources in a similar way: the nature of the resource (or genre).</td>
+ </tr>
+ <tr>
+ <td><b>dct:created</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td><code>dct:created</code> is a property used to describe the time of creation of an entity, which corresponds to the time of its generation.
+ The rationale to map this property as a subclass of <code>prov:generatedAtTime</code> is that resources in Dublin Core may have
+ many dates associated to them (creation, modification, issue, etc.), each of which could correspond to a different version of the document.
+ In this case, the creation is the first date asserted to the document, but doesn't necessarily correspond to the current version of the resource.</td>
+ </tr>
+ <tr>
+ <td><b>dct:issued</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>Date when the resource was issued. It 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>dct:dateAccepted</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>The rationale is similar to the previous two properties: the version of the resource which was accepted could be different from the created or issued one.</td>
+ </tr>
+ <tr>
+ <td><b>dct:dateCopyrighted</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>See <code>dct:dateAccepted</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:dateSubmitted</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>See <code>dct:dateAccepted</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:modified</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>See <code>dct:dateAccepted</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>:
+ <!-- SHOULD ADD THIS FOR EACH
+ <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 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>
+ <h3>PROV refinements</h3>
+ <p>
+ To properly reflect the meaning of the Dublin Core terms, more specific subclasses are needed:
+ </p><p>
+ <pre class="code">
+ prov:PublicationActivity rdfs:subClassOf prov:Activity .
+ prov:ContributionActivity rdfs:subClassOf prov:Activity .
+ prov:CreationActivity rdfs:subClassOf prov:Activity, prov:ContributionActivity .
+ prov:ModificationActivity rdfs:subClassOf prov:Activity .
+ prov:AcceptanceActivity rdfs:subClassOf prov:Activity .
+ prov:CopyrightingActivity rdfs:subClassOf prov:Activity .
+ prov:SubmissionActivity rdfs:subClassOf prov:Activity .
+ prov:PublisherRole rdfs:subClassOf prov:Role .
+ prov:ContributorRole rdfs:subClassOf prov:Role .
+ prov:CreatorRole rdfs:subClassOf prov:Role, prov:ContributorRole .
+ </pre>
+ </p>
+
+ <p>
+ Custom refinements of the properties should be omitted as they would be identical to the Dublin Core terms. If these more
+ specific properties are needed, the Dublin Core terms should be used directly, according to the direct mappings presented in section 2.3.
+ </p>
+ </section>
+ <section>
+ <h3>Complex Mappings</h3>
+ <p>
+ The complex mappings consist on a set of patterns defined to generate qualified PROV statements from Dublin Core statements. This type of qualification may not be
+ always needed, and it is the choice of the implementor whether to use them or not depending on the use case. It is also important to note that not all the
+ 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>
+ <h4>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>
+ In the text below, variables <code>?document</code> and <code>?agent</code> are set to different matching values depending
+ on the data found in the triple store. The graph in the CONSTRUCT part can be seen as a template
+ 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>
+ <h5> dct:creator</h5>
+ A creator is the agent associated with role CreatorRole in the CreationActivity that created a specialization of the entity (?document).
+ <pre class="code">
+ CONSTRUCT {
+ ?document a prov:Entity ;
+ prov:wasAttributedTo ?agent.
+
+ ?agent a prov:Agent .
+
+ _:activity a prov:Activity, prov:CreationActivity ;
+ prov:wasAssociatedWith ?agent;
+ prov:qualifiedAssociation [
+ a prov:Association;
+ prov:agent ?agent;
+ prov:hadRole prov:CreatorRole .
+ ].
+
+ _:resulting_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasAttributedTo ?agent.
+
+ } WHERE {
+ ?document dct:creator ?agent.
+ }
+ </pre>
+ </section>
+ <section>
+ <h5 id="term_contributor"><span class="secno">2.5.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:ContributionActivity ;
+ prov:wasAssociatedWith ?agent ;
+ prov:qualifiedAssociation [
+ a prov:Association ;
+ prov:agent ?agent ;
+ prov:hadRole prov:ContributorRole .
+ ].
+
+ _:resulting_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasAttributedTo ?agent .
+
+ } WHERE {
+ ?document dct:contributor ?agent .
+ }
+ </pre>
+ </section>
+ <section>
+ <h5>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:PublicationActivity ;
+ prov:used _:used_entity;
+ prov:wasAssociatedWith ?agent ;
+ prov:qualifiedAssociation [
+ a prov:Association ;
+ prov:agent ?agent ;
+ prov:hadRole prov:PublisherRole .
+ ].
+
+ _: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>
+ </section>
+ </section>
+ <section>
+ <h4>Entity-Date mappings (When)</h4>
+ <p>
+ Dates often correspond with a who-property, e.g., creator and created or publisher and issued.
+ Therefore, they lead to similar complex patterns (providing a date instead of an agent associated with the corresponding activity).
+ When using Dublin Core terms, it is usual to see that a resource is annotated with several <code>dct</code> assertions like creator, publisher,
+ issued, date, etc., but in this phase of the mapping each term is treated independently.
+ </p>
+
+ <section>
+ <h5> dct:created</h5>
+ </p>
+ <pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:CreationActivity ;
+
+ # 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>
+ <h5>dct:issued</h5>
+ <p>
+ <pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:PublicationActivity ;
+ 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>
+ </section>
+ <section>
+ <h5>dct:modified</h5>
+ <p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:ModificationActivity ;
+ 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>
+ </section>
+ <section>
+ <h5>dct:dateAccepted</h5>
+ <p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:AcceptanceActivity ;
+ 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>
+ </section>
+ <section>
+ <h5>dct:dateCopyrighted</h5>
+ <p><pre class="code">
+CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:CopyrightingActivity ;
+ 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>
+ </section>
+ <section>
+ <h5>dct:dateSubmitted</h5>
+ <p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:SubmissionActivity ;
+ 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>
+ </section>
+ </section>
+
+ </section>
+ <section>
+ <h3>Cleanup</h3>
+ <p>
+ The clean-up phase depends on how implementers interpret the described resources. The approach presented in this document
+ is conservative and it leads to the proliferation of blank nodes. Blank nodes could be renamed to specific identifiers
+ 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:
+ <pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:CreationActivity.
+ prov:wasAssociatedWith ?agent
+ prov:qualifiedAssociation [
+ a prov:Association;
+ prov:agent ?agent;
+ prov:hadRole prov:CreatorRole .
+ ] .
+
+ # 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 id = "figure_cleanup1" class="figure" style="text-align: center;">
+ <img src="img/cleanup1.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_cleanup1">Figure 3</a>. Gathering complementing properties to conflate blank nodes.
+ </div>
+ </div>
+
+ </p>
+ <p>2) Another solution is to <b>sort all the activities according to their date</b>, if known, and conflate the blank
+ nodes result of one activity and the input of the subsequent activity, in case they are both specializations of the same entity.
+ <a href="#figure_cleanup2">Figure 4</a> shows a graphical example with two different activities (creation and publication) that happened at different
+ points in time. Instead of creating different blank nodes for the respective usage and generation, both activities share the same
+ blank node (<code>_:created_entity</code>).
+ <div id = "figure_cleanup2" class="figure" style="text-align: center;">
+ <img src="img/cleanup2.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_cleanup2">Figure 4</a>. Sorting the activities by date to conflate blank nodes.
+ </div>
+ </div>
+ </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>
+ <h2>List of terms excluded from the mapping</h2>
+ <p>
+ <table>
+ <caption> <a href="#list_of_excluded_terms"> 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">dct:abstract</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">dct:accrualMethod</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">dct:accrualPeriodicity</b></td>
+ <td>Descriptive metadata</td>
+ <td>Frequency of the addition of items to a collection.</td>
+ </tr><tr>
+ <td><b id="term_accrualPolicy">dct:accrualPolicy</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">dct:alternative</b></td>
+ <td>Descriptive metadata</td>
+ <td>Refers to an alternative name of the resource. </td>
+ </tr><tr>
+ <td><b id="term_audience">dct:audience</b></td>
+ <td>Descriptive metadata</td>
+ <td>The audience for whom the resource is useful.</td>
+ </tr><tr>
+ <td><b id="term_conformsTo">dct:conformsTo</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">dct:coverage</b></td>
+ <td>Descriptive metadata</td>
+ <td>Topic of the resource.</td>
+ </tr><tr>
+ <td><b id="term_description">dct:description</b></td>
+ <td>Descriptive metadata</td>
+ <td>An account of the resource.</td>
+ </tr><tr>
+ <td><b id="term_educationLevel">dct:educationLevel</b></td>
+ <td>Descriptive metadata</td>
+ <td>The educational level of the audience for which the resource is intended too.</td>
+ </tr><tr>
+ <td><b id="term_extent">dct:extent</b></td>
+ <td>Descriptive metadata</td>
+ <td>Size or duration of the resource.</td>
+ </tr><tr>
+ <td><b id="term_format">dct:format</b></td>
+ <td>Descriptive metadata</td>
+ <td>Format of the resource. </td>
+ </tr><tr>
+ <td><b id="term_identifier">dct:identifier</b></td>
+ <td>Descriptive metadata</td>
+ <td>An unambiguous reference on a given context. </td>
+ </tr><tr>
+ <td><b id="term_instructionalMethod">dct:instructionalMethod</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">dct:isPartOf</b></td>
+ <td>Descriptive metadata</td>
+ <td>Inverse of <code>dct:hasPart</code>.</td>
+ </tr><tr>
+ <td><b id="term_isRequiredBy">dct:isRequiredBy</b></td>
+ <td>Descriptive metadata</td>
+ <td>The current resource is required for supporting the function of another resource. This is not related
+ the provenance, since it refers to something that may not have happened yet (e.g., a library dependency, but the program
+ that needs it hasn’t been executed yet).</td>
+ </tr><tr>
+ <td><b id="term_language">dct:language</b></td>
+ <td>Descriptive metadata</td>
+ <td>Language of the resource.</td>
+ </tr><tr>
+ <td><b id="term_mediator">dct:mediator</b></td>
+ <td>Descriptive metadata</td>
+ <td>Entity that mediates access to the resource. </td>
+ </tr><tr>
+ <td><b id="term_medium">dct:medium</b></td>
+ <td>Descriptive metadata</td>
+ <td>Material of the resource.</td>
+ </tr><tr>
+ <td><b id="term_requires">dct:requires</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">dct:hasPart</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">dct:spatial</b></td>
+ <td>Descriptive metadata</td>
+ <td>Spatial characteristics of the content of the resource (e.g., the book is about Spain). Thus it can't be mapped to <code>prov:hadLocation</code>.</td>
+ </tr><tr>
+ <td><b id="term_subject">dct:subject</b></td>
+ <td>Descriptive metadata</td>
+ <td>Subject of the resource.</td>
+ </tr><tr>
+ <td><b id="term_tableOfContents">dct:tableOfContents</b></td>
+ <td>Descriptive metadata</td>
+ <td>List of subunits of the resource.</td>
+ </tr><tr>
+ <td><b id="term_temporal">dct:temporal</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">dct:title</b></td>
+ <td>Descriptive metadata</td>
+ <td>Title of the resource.</td>
+ </tr><tr>
+ <td><b id="term_type">dct:type</b></td>
+ <td>Descriptive metadata</td>
+ <td>Type of the resource.</td>
+ </tr><tr>
+ <td><b id="term_bibliographicCitation">dct:bibliographicCitation</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>dct:references</b></td>
+ <td> Provenance: How </td>
+ <td>This term could be used to refer to sources that have been used to create the document, but it could
+ be also used to cite the sources that are not relevant for the current work. For this reason it has been dropped
+ from the mapping.</td>
+ </tr><tr>
+ <td id="term_isReferencedBy"><b>dct:isRefrencedBy</b></td>
+ <td> Provenance: How </td>
+ <td>Inverse to <code>dct:references</code>.</td>
+ </tr><tr>
+ <td><b id="term_accessRights">dct:accessRights</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">dct:license</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">dct:rights</b></td>
+ <td>Provenance: How</td>
+ <td>Metadata about the rights of the resource.</td>
+ </tr><tr>
+ <td><b id="term_date">dct:date</b></td>
+ <td>Provenance: When</td>
+ <td>Date is a very general property. It is the superproperty which all the other specialize, but there is no equivalent concept in PROV. It has been excluded from the mapping</td>
+ </tr><tr>
+ <td><b id="term_available">dct:available</b></td>
+ <td>Provenance: When</td>
+ <td>Property that states when a resource is available. The group could not reach consensus on how to map this property, so it was finally dropped from the mapping.</td>
+ </tr><tr>
+ <td><b id="term_valid">dct:valid</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">dct:relation</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. Thus there is no direct mapping.<td>
+ </tr>
+ </tbody></table>
+ </p>
+ </section>
+ <section>
+ <h2>Mapping from PROV to DC</h2>
+ <p>
+ The mapping from PROV to Dublin Core is not part of this note.
+ It can be questioned, if a mapping without additional information would provide meaningful data.
+ If refinements are used, the mapping would be straight forward using the inverse of the
+ mapping patterns used in this document. However, without such refinements, few Dublin Core statements can be inferred,
+ apart from some unqualified dates. Dublin Core includes provenance information, but the focus lies on
+ the description of the resources. Pure PROV data models a provenance chain, but it contains almost
+ no information about the resulting resource itself. </p>
+ </section>
+ </section>
+
+ <section class="appendix">
+ <h2>Acknowledgements</h2>
+ <p>
+ We would like to thank Antoine Isaac, Ivan Herman, Timothy Lebo and Satya Sahoo for their comments and feedback, and María Poveda and Idafen Santana Pérez for his help with the HTML generation.
+ </p>
+ </section>
+</body>
+</html>
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/old-version/Overview.html Fri Nov 30 12:57:38 2012 +0100
@@ -0,0 +1,1790 @@
+<?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 http-equiv="Content-Type" content="text/html; charset=UTF-8" />
+
+<!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+
+
+<!-- PM -->
+
+ <style type="text/css">
+ .note { font-size:small; margin-left:50px }
+ </style>
+
+
+
+
+ <style type="text/css">
+/*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- 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;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl:before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID, .idlDictionaryID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType, .idlMemberType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName, .idlMemberName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a, .idlMemberName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code, .dictionary-members dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
+ margin-bottom: 1em;
+}
+
+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%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- 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;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.code {
+ background-color:#F9F9F9;
+ border:1px dashed #2F6FAB;
+ color:black;
+ line-height:1.1em;
+ padding:1em;
+}
+
+pre.example:before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue:before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note:before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+/* --- SYNTAX HIGHLIGHTING --- */
+pre.sh_sourceCode {
+ background-color: white;
+ color: black;
+ font-style: normal;
+ font-weight: normal;
+}
+
+pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
+pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
+pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
+pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
+pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
+pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
+pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
+pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
+pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
+pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
+pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
+pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
+pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
+
+/* Predefined variables and functions (for instance glsl) */
+pre.sh_sourceCode .sh_predef_var { color: #00008B; }
+pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
+
+/* for OOP */
+pre.sh_sourceCode .sh_classname { color: teal; }
+
+/* line numbers (not yet implemented) */
+pre.sh_sourceCode .sh_linenum { display: none; }
+
+/* Internet related */
+pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
+
+/* for ChangeLog and Log files */
+pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
+pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
+pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
+
+/* for Prolog, Perl... */
+pre.sh_sourceCode .sh_variable { color: #006400; }
+
+/* for LaTeX */
+pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
+pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
+pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
+pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
+pre.sh_sourceCode .sh_argument { color: #006400; }
+pre.sh_sourceCode .sh_optionalargument { color: purple; }
+pre.sh_sourceCode .sh_math { color: orange; }
+pre.sh_sourceCode .sh_bibtex { color: blue; }
+
+/* for diffs */
+pre.sh_sourceCode .sh_oldfile { color: orange; }
+pre.sh_sourceCode .sh_newfile { color: #006400; }
+pre.sh_sourceCode .sh_difflines { color: blue; }
+
+/* for css */
+pre.sh_sourceCode .sh_selector { color: purple; }
+pre.sh_sourceCode .sh_property { color: blue; }
+pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
+
+/* other */
+pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
+pre.sh_sourceCode .sh_paren { color: red; }
+pre.sh_sourceCode .sh_attribute { color: #006400; }
+
+</style><link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8" />
+<script src="http://www.w3.org/2007/OWL/toggles.js"></script>
+</head>
+ <body style="display: inherit; ">
+ <div class="head"><p><a href="http://www.w3.org/">
+ <img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C" /></a></p>
+ <h1 class="title" id="title">Dublin Core to PROV Mapping</h1><h2 id="w3c-working-draft-19-august-2012">
+ <acronym title="World Wide Web Consortium">W3C</acronym> Editor's Draft 28 October 2012</h2>
+ <dl><dt>This version:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/Overview.html">http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/Overview.html</a></dd>
+ <dt>Latest published version:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/Overview.html">http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/Overview.html</a></dd>
+ <dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/Overview.html">http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/Overview.html</a></dd>
+ <dt>Editors:</dt>
+<dd><span><a href="http://www.kaiec.org/">Kai Eckert</a>, Manheim University Library, Germany</dd>
+<dd><span><a href="http://www.oeg-upm.net/index.php/en/phdstudents/28-dgarijo">Daniel Garijo</a></span>, Universidad Politécnica de Madrid, Spain</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>Craig M. Trim</span>, IBM, USA</dd>
+<dd><span>Michael Panzer</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> © 2012 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <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>
+ <div id="abstract" class="introductory section"><h2>Abstract</h2>
+ <p>
+ This document provides a mapping between the PROV-O OWL2
+ ontology [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>] and
+ the Dublin Core Terms Vocabulary [<a href="#bib-DCTERMS">DCTERMS</a>].
+ </p>
+ <p style="text-align: center;">
+ The direct mappings are available <a href="http://dvcs.w3.org/hg/prov/raw-file/e3d298ff8c78/dc-note/files/DirectMappings.ttl">here</a>.
+ </p>
+ <p style="text-align: center;">
+ The prov refinements for Dublin Core can be accessed here <a href="http://dvcs.w3.org/hg/prov/raw-file/e3d298ff8c78/dc-note/files/Refinements.ttl">here</a>.
+ </p>
+
+
+ </div><div id="sotd" class="introductory section"><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 <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision
+ of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">
+ W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
+
+ This document is part of a set of specifications aiming to define the
+ various aspects that are necessary to achieve the vision of
+ interoperable interchange of provenance information in heterogeneous
+ environments such as the Web. This document is a non-normative
+ mapping between the [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>] OWL ontology
+ and the Dublin Core Terms vocabulary[<a href="#bib-DCTERMS">DCTERMS</a>]. The document is expected to become a Note once it is stable.
+ <p>This document was published by the <a href="http://www.w3.org/2011/prov/">Provenance Working Group</a> as an Editor's Draft.
+ If you wish to make comments regarding this document, please send them to
+ <a href="mailto:public-prov-wg@w3.org">public-prov-wg@w3.org</a>
+ (<a href="mailto:public-prov-wg-request@w3.org?subject=subscribe">subscribe</a>
+ , <a href="http://lists.w3.org/Archives/Public/public-prov-wg/">archives</a>).
+ All feedback is welcome.</p><p>Publication as an Editor's Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">
+ W3C</acronym> 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 <acronym title="World Wide Web Consortium">W3C</acronym>
+ Patent Policy</a>. The group does not expect this document to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation.
+ <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a href="http://www.w3.org/2004/01/pp-impl/46974/status" rel="disclosure">
+ public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for
+ disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
+ <a href="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 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div>
+
+ <div id="toc" class="section"><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></li>
+ <ul class="toc">
+ <li class="tocline"><a href="#namespaces" class="tocxref"><span class="secno">1.1 </span>Namespaces</a></li>
+ </ul>
+ <li class="tocline"><a href="#Mapping" class="tocxref"><span class="secno">2. </span>Mapping Dublin Core to PROV</a></li>
+ <ul class="toc">
+ <li class="tocline"><a href="#basic" class="tocxref"><span class="secno">2.1 </span>Basic considerations</a></li>
+ <li class="tocline"><a href="#entities_in_dc" class="tocxref"><span class="secno">2.2 </span>What is ex:doc1? Entities in Dublin Core</a></li>
+ <li class="tocline"><a href="#mappings" class="tocxref"><span class="secno">2.3 </span>Direct Mappings</a></li>
+ <li class="tocline"><a href="#refinements" class="tocxref"><span class="secno">2.4 </span>PROV Refinements</a></li>
+ <li class="tocline"><a href="#complex_mappings" class="tocxref"><span class="secno">2.5 </span>Complex Mappings</a></li>
+ <ul class="toc">
+ <li class="tocline"><a href="#entity_agent_mappings" class="tocxref"><span class="secno">2.5.1 </span>Entity-Agent (Who) mappings</a></li>
+ <ul class="toc">
+ <li class="tocline"><a href="#term_creator" class="tocxref"><span class="secno">2.5.1.1 </span>dct:creator</a></li>
+ <li class="tocline"><a href="#term_contributor" class="tocxref"><span class="secno">2.5.1.2 </span>dct:contributor</a></li>
+ <li class="tocline"><a href="#term_publisher" class="tocxref"><span class="secno">2.5.1.3 </span>dct:publisher</a></li>
+ <!--<li class="tocline"><a href="#term_rights_holder" class="tocxref"><span class="secno">2.5.1.4 </span>dct:rightsHolder</a></li>-->
+ </ul>
+ <li class="tocline"><a href="#entity_date_mappings" class="tocxref"><span class="secno">2.5.2 </span>Entity-Date (When) mappings</a></li>
+ <ul class="toc">
+ <li class="tocline"><a href="#term_created" class="tocxref"><span class="secno">2.5.2.1 </span>dct:created</a></li>
+ <li class="tocline"><a href="#term_issued" class="tocxref"><span class="secno">2.5.2.2 </span>dct:issued</a></li>
+ <li class="tocline"><a href="#term_modified" class="tocxref"><span class="secno">2.5.2.3 </span>dct:modified</a></li>
+ <li class="tocline"><a href="#term_dateAccepted" class="tocxref"><span class="secno">2.5.2.4 </span>dct:dateAccepted</a></li>
+ <li class="tocline"><a href="#term_dateCopyRighted" class="tocxref"><span class="secno">2.5.2.5 </span>dct:dateCopyRighted</a></li>
+ <li class="tocline"><a href="#term_dateSubmitted" class="tocxref"><span class="secno">2.5.2.6 </span>dct:dateSubmitted</a></li>
+ </ul>
+ <!--<li class="tocline"><a href="#entity_entity_mappings" class="tocxref"><span class="secno">2.5.3 </span>Entity-Entity (How) mappings</a></li>
+ <ul class="toc">
+ <li class="tocline"><a href="#term_has_Version" class="tocxref"><span class="secno">2.5.3.1 </span>dct:isVersionOf/hasVersion</a></li>
+ <li class="tocline"><a href="#term_has_Format" class="tocxref"><span class="secno">2.5.3.2 </span>dct:isFormatOf/hasFormat</a></li>
+ <li class="tocline"><a href="#term_replaces" class="tocxref"><span class="secno">2.5.3.3 </span>dct:replaces/replacedBy</a></li>
+ <li class="tocline"><a href="#term_source" class="tocxref"><span class="secno">2.5.3.4 </span>dct:source</a></li>
+ </ul>-->
+ <li class="tocline"><a href="#cleanup" class="tocxref"><span class="secno">2.5.3 </span>Cleanup</a></li>
+ </ul>
+ <li class="tocline"><a href="#list_of_excluded_terms" class="tocxref"><span class="secno">2.6 </span>List of the terms excluded from the mapping</a></li>
+ </ul>
+ <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></li>
+ <ul class="toc">
+ <li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li>
+ <li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.1 </span>Informative references</a></li>
+ </ul>
+ </ul>
+ </div>
+
+
+
+ <div id="introduction" class="section">
+
+<!-- OddPage (DCMI Usage Board, 2010b) -->
+<h2><span class="secno">1. </span>Introduction</h2>
+ <p>
+ The Dublin Core Metadata Initiative (DCMI) [<a href="#bib-DCMI">DCMI</a>] provides a core metadata vocabulary,
+ commonly referred to as Dublin Core. The original element set, from 1995, 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" and currently consists of 55 properties [<a href="#bib-DCTERMS">DCTERMS</a>].
+ </p>
+The use of DCMI terms is preferred and the Dublin Core element set has been depecreated.
+Both element 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 newer DCMI element set.
+</p>
+<p>
+DCMI terms hold a lot of provenance information and tell us 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.
+There is no direct information in Dublin Core describing <i>where</i> a resource was affected. Such information is usually
+only available for the publication of a resource (i.e., an action located at the address of the publisher). <!--Note that
+spatial is not related to this question, as it is a descriptive property that links a resource to the location
+referred to in its content, but not to the location where it was created, modified, issued or published. -->
+</p>
+<!--
+Consider the following example for a metadata record:
+</p><p>
+<a href="#example1">Example 1</a>: a simple metadata record:
+<pre class="example" id="example1">
+ 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>
+
+<p>
+Clearly not all metadata statements deal with provenance.
+ <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 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
+ the document to another document <code>ex:doc2</code> which had probably
+ some kind of influence on <code>ex:doc1</code>.
+</p><p>
+Following this pattern, the existing metadata can be categorized as
+description metadata and provenance metadata. To be more precise, provenance
+metadata is defined as metadata providing provenance information according to the definition of
+the Provenance Working Group [<a href="#bib-PROV-DEF">PROV-DEF</a>] and description metadata as all other metadata.
+</p>
+<p>
+Based on this definition, the DCMI terms can be classified as follows:
+</p>
+<p>
+<b>Description metadata</b>: abstract, accessRights, accrualMethod, accrualPeriodicity, accrualPolicy,
+ alternative, audience, bibliographicCitation, conformsTo, coverage, description, educationLevel, extent,
+ hasPart, isPartOf, format, identifier, instructionalMethod, isRequiredBy, language, mediator,
+ medium, relation, requires, spatial, subject, tableOfContents, temporal, title, type.
+</p>
+<p>
+<b>Provenance metadata</b>: available, contributor, created, creator, date, dateAccepted, dateCopyrighted,
+ dateSubmitted, hasFormat, hasVersion, isFormatOf, isReferencedBy, isReplacedBy, issued, isVersionOf, license, modified,
+ provenance, publisher, references, replaces, rightsHolder, rights, source, valid.
+</p>
+-->
+<p>
+A classification of the <code>dct</code> terms is provided in <a href="#categories">Table 1</a>. This classification is by necessity
+somewhat conservative, as it can be argued that elements placed in the description metadata terms contain
+provenance information as well, depending on their usage. Based on this, 25 (out of 55) terms can be considered as
+provenance related. These terms can be further categorized according to the question they answer regarding the
+provenance of a resource:
+</p><p>
+
+<b>Dates and Time terms (When?):</b>This category contains date and time related terms.
+ Dates typically belong to the provenance record of a resource. 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. Two dates can be considered special regarding their relevance for
+ provenance: <code>dct:available</code> and <code>dct:valid</code>. They are different from the other dates as by definition they can represent a
+ date range. Often, the range of availability or validity of a resource is inherent to the resource and known
+ beforehand – consider the validity of a passport or the availability of a limited special offer published on the web.
+ In these cases, there is no action involved that makes the resource invalid or unavailable, it is simply determined
+ by the validity range. On the other hand, if an action is involved, e.g., a resource is declared invalid because
+ a mistake has been found, then it is relevant for its provenance.
+ </p><p>
+
+<b>Agency Terms (Who?):</b> This category contains agent related terms. All properties that 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>Derivation Terms (How?):</b> This category contains derivation related terms.
+ Resources are often derived from other resources. In this case, the original resource becomes part of the provenance
+ record of the derived resource. Derivations can be further classified as <code>dct:isVersionOf, dct:isFormatOf, dct:replaces, dct:source</code>.
+ <code>dct:references</code> is a weaker relation, 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 – at most indirectly, as the validity state can change if a resource is replaced by a new
+ version. However, inverse properties belong to the provenance related terms as they can be used to describe the relations
+ between the resources involved. Finally, licensing and rights are considered part of the provenance of the resource as well,
+ since they restrict how the resource has been used by its owners.
+</p>
+<!--<p>
+<a href="#categories">Table 1</a> summarizes the terms in their respective categories:
+</p>-->
+<div id="categories" ALIGN="center">
+ <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_accessRights">accessRights</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_rights_holder">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_has_Version">isVersionOf</a>, <a href="#term_has_Version">hasVersion</a>, <a href="#term_has_Format">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: <i>provenance</i>. 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" [<a href="#bib-DCTERMS">DC-TERMS</a>],
+which corresponds to the traditional definition of provenance for artworks. 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>
+<!--In summary, the DCMI terms – and therefore any Dublin Core metadata record – hold a lot of provenance information and
+ tell us 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 other DCMI terms (description metadata), tell us <i>what</i> was affected. There is
+ no direct information in Dublin Core describing <i>where</i> a resource was affected. Such information is usually only available for the
+ publication of a resource (i.e., an action located at the address of the publisher). Note that spatial is not related
+ to this question, as it is a descriptive property that links a resource to the location referred to in its content, but not to the
+ location where it was created, modified, issued or published. <!--– or even that it has ever been or is otherwise related to Berlin. <!--And finally, the question,
+ why a resource was affected, lacks – apart from subtle hints from terms like replaces – as usual a satisfying answer. -->
+ An example of a simple metadata record annotated with <code>dct</code> terms can be seen below:
+</p><p>
+<a href="#example1">Example 1</a>: a simple metadata record:
+<pre class="example" id="example1">
+ 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>
+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
+ the document to another document <code>ex:doc2</code> which had probably
+ some kind of influence on <code>ex:doc1</code>.
+</p>
+<h3 id ="namespaces">1.1 Namespaces</h3>
+<p>The namespaces used through the document can be seen in <a href="#ns"> Table 2</a> below:
+ <div id="ns" ALIGN="center">
+ <table>
+ <caption> <a href="#ns"> Table 2</a>: Namespaces used in the document </caption>
+ <tbody>
+ <tr><td><b>owl</b></td><td><http://www.w3.org/2002/07/owl#></td></tr>
+ <tr><td><b>rdfs</b></td><td><http://www.w3.org/2000/01/rdf-schema#></td></tr>
+ <tr><td><b>prov</b></td><td><http://www.w3.org/ns/prov#></td></tr>
+ <tr><td><b>dct</b></td><td><http://purl.org/dc/terms/></td></tr>
+ </tbody>
+ </table>
+ </div>
+</p>
+</div>
+<div id="Mapping" class="section">
+<h2>2. Mapping from Dublin Core to PROV</h2>
+<p>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>
+<div id="basic" class="section">
+<h3>2.1 Basic considerations </h3>
+<p>
+Substantially, a complete mapping from Dublin Core to PROV consists of three parts:
+</p><p>
+ 1) <b>Direct mappings</b> between terms that can be expressed in form of subclass or subproperty relationships in RDFS
+ – or equivalent relationships in OWL.
+</p><p>
+ 2) Definition of new <b>refinements</b> (subclasses or subproperties) of the target vocabulary to reflect the expressiveness of the source vocabulary.
+</p><p>
+ 3) Provision of <b>complex mappings</b> that create statements in the target vocabulary based on statements in the source vocabulary. Since
+ the mapping produces blank nodes for each <code>dct</code> statement, a clean-up phase with strategies for reducing the blank nodes is also necessary.
+</p>
+<!--<p>
+For the third part (complex mappings), we provide context free mappings that do not depend on the existence of any other statements.
+ We briefly describe strategies on how to refine and clean the complex mapping results taking the context into account.
+</p><p>
+For the context-free mapping, first, only single DC statements are mapped to PROV. Relations between several statements affecting the resulting
+ PROV statements are not yet taken into account. The input and output of all activities are identified as separate specializations of
+ the original resource mentioned in the DC statement. A specialization in PROV identifies a state of a resource during its lifetime that
+ is part of the provenance chain. However, if a specialization of a document is generated by one activity and a specialization is used by
+ a different activity later in time, it can be assumed that both are the same entities, if the second activity directly follows the first
+ activity. These conflations and other clean-up steps are performed separately, as there are several possibilities to perform them.
+</p><p>
+Clean-up. The context free mapping produces blank nodes for each <code>dct</code> statement. The number of blank nodes can be reduced
+by applying reasoning patterns to clean up the data, e.g. by conflating nodes that are actually the same (e.g., an issued document could
+be the same as the created document).
+</p>-->
+<p>
+</div>
+<div id="entities_in_dc" class="section">
+<h3><span class="secno">2.2 </span>What is ex:doc1? Entities in Dublin Core</h3>
+<p>
+Consider the example metadata record shown at the beginning of this document (in <a href="#example1">example 1</a>). As a <code>dc</code>
+metadata record describes the resulting 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 specialization of the document, even if the document
+ has not changed. Generally, there are two possibilities to deal with this issue:</p>
+</p><p>
+ 1) Create new instances of entities, typically as blank nodes, that are all related to the original
+ document by means of <code>prov:specializationOf</code>. This leads to bloated and not very intuitive data models, e.g. think
+ about the translation of a single <code>dct:publisher</code> statement, where anyone would expect to somehow find some activity and
+ agent that are directly related to the document (as in <a href="#figure_mapping_example">Figure 1</a>).
+</p><p>
+ <div id = "figure_mapping_example" class="figure" style="text-align: center;">
+ <img src="img/example1.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_mapping_example">Figure 1</a>. A mapping example creating blank nodes for each state of the resource. In PROV entities are represented
+with ellipses, activities with rectangles and agents with pentagons.
+ </div>
+ </div>
+</p><p>
+ 2) Use the original resource (<code>ex:doc1</code>) as the instance used and generated as <code>prov:Entity</code>. However, to have an activity that uses
+ an entity and generates the same entity or to have different activities that generate the same entity at different points in time
+ is not compliant with the PROV constraints [<a href="#bib-Constraints">PROV-CONTRAINTS</a>]. <a href="#figure_mapping_example_conflating">Figure 2</a>
+ provides an example that illustrates this approach.
+ <!--<b>This has to be investigated and discussed further. For references, see PROV-DM Generation, PROV-DM Derivation,
+ PROV-O Activity</b>.
+ Removed this from the text above: The implications regarding
+ the semantics of a <code>prov:Activity</code> are not yet totally clear, h
+ -->
+</p><p>
+ <div id = "figure_mapping_example_conflating" class="figure" style="text-align: center;">
+ <img src="img/mapping-example - conflating.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_mapping_example_conflating">Figure 2</a>. A mapping example conflating blank nodes in the same resource. The used and generated resources have the same identifier.
+ </div>
+ </div>
+</p><p>
+Since the first option is the most conservative with respect to the underlying semantics, 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.
+<!-- I comment this because it repeats what it has already been stated
+Here, we can deal with more specific questions like the following:
+</p><p>
+ How do we reduce the number of specializations, e.g., by stating that the specialization that is generated by activity
+ 1 is the same entity that is used by activity 2?
+</p><p>
+ How do we relate the specializations to <code>ex:doc1</code>? We could create two entities based on the actual creation activity:
+ <code>ex:doc1</code> and a first specialization. We could further declare the last produced specialization as the same entity as <code>ex:doc1</code>.
+ Depending on the underlying data, this can be the entity that is identified by the URI of the original document. However,
+ we have to be careful to avoid cycles in the provenance we produce. For now, this remains undecided.
+-->
+</p>
+</div>
+<div id="mappings" class="section">
+<h3><span class="secno">2.3 </span>Direct mappings</h3>
+<p>
+<!--Direct mappings can particularly be provided for classes and the “shortcuts”, i.e. the direct relationships in PROV between
+ an entity and an agent or an entity and a date.-->
+The direct mappings provide basic interoperability using the integration mechanisms of RDF. By means
+ of OWL 2 RL reasoning, any PROV application can at least make some sense from Dublin Core data. 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_excluded_terms">list of terms left out of the mapping</a>.
+</p><p>
+<div id="list_of_direct_terms" ALIGN="center">
+<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>dct:Agent</b></td>
+ <td>owl:equivalentClass</td>
+ <td> prov:Agent.</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).</td>
+ </tr>
+ <tr>
+ <td><b>dct:rightsHolder</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>The rights holder has the attribution of the activity that created the licensed resource.</td>
+ </tr>
+ <tr>
+ <td><b>dct:creator</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>A creator is the agent who created the resource. He is the one involved in the creation activity that led to the resource.
+ He has the attribution for that activity</td>
+ </tr>
+ <tr>
+ <td><b>dct:publisher</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>A publisher has the attribution of the publishing activity that led to the published resource.</td>
+ </tr>
+ <tr>
+ <td><b>dct:contributor</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasAttributedTo</td>
+ <td>A contributor is involved either in the creation activity or in the updating of the resource. Therefore he/she is attributed to take
+ part in those activities.</td>
+ </tr>
+ <tr>
+ <td><b>dct:isVersionOf</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasDerivedFrom</td>
+ <td><code>dct:isVersionOf</code> refers to "a related resource to which the current resource is a version, edition or adaptation".
+ Hence the current resource has been derived from the original one.</td>
+ </tr>
+ <tr>
+ <td><b>dct:isFormatOf</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:alternateOf</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>dct:hasFormat</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:alternateOf</td>
+ <td> See rationale for <code>dct:isFormatOf</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:replaces</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasInfluencedBy</td>
+ <td>This mapping is not straightforward. There is a relation between two resources when the former replaces the latter, but it is not necessarily
+ derivation, revision, specification or alternate. Thus, the term is mapped to <code>prov:wasInfluencedBy</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:source </b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:wasDerivedFrom</td>
+ <td>In Dublin Core, <code>dct:source</code> is defined as a "related resource from which the described resource is derived", which matches the notion of derivation
+ in PROV-DM ("a transformation of an entity in another")</td>
+ </tr>
+ <tr>
+ <td><b>dct:type</b></td>
+ <td>owl:equivalentProperty</td>
+ <td>prov:type</td>
+ <td>Both properties relate two resources in a similar way: the nature of the resource (or genre).</td>
+ </tr>
+ <tr>
+ <td><b>dct:created</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td><code>dct:created</code> is a property used to describe the time of creation of an entity, which corresponds to the time of its generation.
+ The rationale to map this property as a subclass of <code>prov:generatedAtTime</code> is that resources in Dublin Core may have
+ many dates associated to them (creation, modification, issue, etc.), each of which could correspond to a different version of the document.
+ In this case, the creation is the first date asserted to the document, but doesn't necessarily correspond to the current version of the resource.</td>
+ </tr>
+ <tr>
+ <td><b>dct:issued</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>Date when the resource was issued. It 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>dct:dateAccepted</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>The rationale is similar to the previous two properties: the version of the resource which was accepted could be different from the created or issued one.</td>
+ </tr>
+ <tr>
+ <td><b>dct:dateCopyrighted</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>See <code>dct:dateAccepted</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:dateSubmitted</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>See <code>dct:dateAccepted</code></td>
+ </tr>
+ <tr>
+ <td><b>dct:modified</b></td>
+ <td>rdfs:subPropertyOf</td>
+ <td>prov:generatedAtTime</td>
+ <td>See <code>dct:dateAccepted</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 [<a href="#bib-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>:
+<!-- SHOULD ADD THIS FOR EACH
+<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 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>
+
+<!--<p>
+Under discussion (dropped out from the inicial draft):
+</p><p>
+<pre>
+ dct:hasPart rdfs:subPropertyOf prov:wasDerivedFrom .
+ dct:hasAccrualMethod (related to collections, to be discussed).
+ </pre>
+</p><p>
+The following has been dropped: valid often refers to a range of dates
+</p><p>
+<pre>
+ dct:valid rdfs:subPropertyOf prov:generatedAtTime .
+</pre></p>
+-->
+
+</div>
+<div id="refinements" class="section">
+<h3><span class="secno">2.4 </span>PROV refinements</h3>
+<p>
+To properly reflect the meaning of the Dublin Core terms, more specific subclasses are needed:
+</p><p>
+<pre class="code">
+ prov:PublicationActivity rdfs:subClassOf prov:Activity .
+ prov:ContributionActivity rdfs:subClassOf prov:Activity .
+ prov:CreationActivity rdfs:subClassOf prov:Activity, prov:ContributionActivity .
+ prov:ModificationActivity rdfs:subClassOf prov:Activity .
+ prov:AcceptanceActivity rdfs:subClassOf prov:Activity .
+ prov:CopyrightingActivity rdfs:subClassOf prov:Activity .
+ prov:SubmissionActivity rdfs:subClassOf prov:Activity .
+ prov:PublisherRole rdfs:subClassOf prov:Role .
+ prov:ContributorRole rdfs:subClassOf prov:Role .
+ prov:CreatorRole rdfs:subClassOf prov:Role, prov:ContributorRole .
+</pre> </p>
+
+<p>
+Custom refinements of the properties should be omitted as they would be identical to the Dublin Core terms. If these more
+ specific properties are needed, the Dublin Core terms should be used directly, according to the direct mappings presented in section 2.3.
+</p>
+</div>
+<div id="complex_mappings" class="section">
+<h3><span class="secno">2.5 </span>Complex Mappings</h3>
+<p>
+The complex mappings consist on a set of patterns defined to generate qualified PROV statements from Dublin Core statements. This type of qualification may not be
+always needed, and it is the choice of the implementor whether to use them or not depending on the use case. It is also important to note that not all the
+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>
+<div id="entity_agent_mappings">
+<h4><span class="secno">2.5.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>
+ In the text below, variables <code>?document</code> and <code>?agent</code> are set to different matching values depending
+ on the data found in the triple store. The graph in the CONSTRUCT part can be seen as a template
+ 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>
+
+</p><p>
+<h5 id="term_creator"><span class="secno">2.5.1.1 </span>dct:creator</h5>
+A creator is the agent associated with role CreatorRole in the CreationActivity that created a specialization of the entity (?document).
+<pre class="code">
+ CONSTRUCT {
+ ?document a prov:Entity ;
+ prov:wasAttributedTo ?agent.
+
+ ?agent a prov:Agent .
+
+ _:activity a prov:Activity, prov:CreationActivity ;
+ prov:wasAssociatedWith ?agent;
+ prov:qualifiedAssociation [
+ a prov:Association;
+ prov:agent ?agent;
+ prov:hadRole prov:CreatorRole .
+ ].
+
+ _:resulting_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasAttributedTo ?agent.
+
+ } WHERE {
+ ?document dct:creator ?agent.
+ }
+</pre>
+<h5 id="term_contributor"><span class="secno">2.5.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:ContributionActivity ;
+ prov:wasAssociatedWith ?agent ;
+ prov:qualifiedAssociation [
+ a prov:Association ;
+ prov:agent ?agent ;
+ prov:hadRole prov:ContributorRole .
+ ].
+
+ _:resulting_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasGeneratedBy _:activity ;
+ prov:wasAttributedTo ?agent .
+
+ } WHERE {
+ ?document dct:contributor ?agent .
+ }
+</pre>
+<h5 id="term_publisher"><span class="secno">2.5.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:PublicationActivity ;
+ prov:used _:used_entity;
+ prov:wasAssociatedWith ?agent ;
+ prov:qualifiedAssociation [
+ a prov:Association ;
+ prov:agent ?agent ;
+ prov:hadRole prov:PublisherRole .
+ ].
+
+ _:resulting_entity a prov:Entity ;
+ prov:specializationOf ?document ;
+ prov:wasDerivedFrom _:used_entity
+ prov:wasGeneratedBy _:activity ;
+ prov:wasAttributedTo ?agent .
+
+ } WHERE {
+ ?document dct:publisher ?agent .
+ }
+</pre>
+<!--
+<h5 id="term_rights_holder"><span class="secno">2.5.1.4 </span>dct:rightsHolder</h5>
+The rightsHolder concept mapping is slightly different. Here we propose to omit the activity and just add the rights holder to the entity by means of
+ <code>prov:wasAttributedTo</code>. This mapping could actually be omitted as the statements can be inferred from the direct mapping.
+<pre class="code">
+ CONSTRUCT {
+ ?document a prov:Entity .
+ ?agent a prov:Agent .
+ ?document prov:wasAttributedTo ?agent .
+ } WHERE {
+ ?document dct:rightsHolder ?agent .
+ }
+</pre>
+-->
+</p>
+
+</div>
+<div id="entity_date_mappings">
+<h4><span class="secno">2.5.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 (providing a date instead of an agent associated with the corresponding activity).
+ When using Dublin Core terms, it is usual to see that a resource is annotated with several <code>dct</code> assertions like creator, publisher,
+ issued, date, etc., but in this phase of the mapping each term is treated independently.
+
+</p>
+
+<h5 id="term_created"><span class="secno">2.5.2.1 </span>dct:created</h5>
+</p>
+<pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:CreationActivity ;
+
+ # 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>
+
+<h5 id="term_issued"><span class="secno">2.5.2.2 </span>dct:issued</h5>
+<p>
+<pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:PublicationActivity ;
+ 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>
+
+<h5 id="term_modified"><span class="secno">2.5.2.3 </span>dct:modified</h5>
+<p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:ModificationActivity ;
+ 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>
+
+<h5 id="term_dateAccepted"><span class="secno">2.5.2.4 </span>dct:dateAccepted</h5>
+<p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:AcceptanceActivity ;
+ 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>
+<h5 id="term_dateCopyRighted"><span class="secno">2.5.2.5 </span>dct:dateCopyrighted</h5>
+<p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:CopyrightingActivity ;
+ 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>
+<h5 id="term_dateSubmitted"><span class="secno">2.5.2.6 </span>dct:dateSubmitted</h5>
+<p><pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:SubmissionActivity ;
+ 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>
+</div>
+
+</div>
+<div id="cleanup" class="section">
+<h3><span class="secno">2.5.3 </span>Cleanup</h3>
+<p>
+The clean-up phase depends on how implementers interpret the described resources. The approach presented in this document
+ is conservative and it leads to the proliferation of blank nodes. Blank nodes could be renamed to specific identifiers
+ 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:
+ <pre class="code">
+ CONSTRUCT{
+ ?document a prov:Entity .
+
+ _:activity a prov:Activity, prov:CreationActivity.
+ prov:wasAssociatedWith ?agent
+ prov:qualifiedAssociation [
+ a prov:Association;
+ prov:agent ?agent;
+ prov:hadRole prov:CreatorRole .
+ ] .
+
+ # 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 id = "figure_cleanup1" class="figure" style="text-align: center;">
+ <img src="img/cleanup1.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_cleanup1">Figure 3</a>. Gathering complementing properties to conflate blank nodes.
+ </div>
+</div>
+
+ </p>
+ <p>2) Another solution is to <b>sort all the activities according to their date</b>, if known, and conflate the blank
+nodes result of one activity and the input of the subsequent activity, in case they are both specializations of the same entity.
+<a href="#figure_cleanup2">Figure 4</a> shows a graphical example with two different activities (creation and publication) that happened at different
+points in time. Instead of creating different blank nodes for the respective usage and generation, both activities share the same
+blank node (<code>_:created_entity</code>).
+<div id = "figure_cleanup2" class="figure" style="text-align: center;">
+ <img src="img/cleanup2.png"></img>
+ <div style="text-align: center;">
+ <a href="#figure_cleanup2">Figure 4</a>. Sorting the activities by date to conflate blank nodes.
+ </div>
+</div>
+</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>
+</div>
+<div id="list_of_excluded_terms" class="section">
+<h2><span class="secno">2.6. </span>List of terms excluded from the mapping</h2>
+<p>
+ <table>
+ <caption> <a href="#list_of_excluded_terms"> 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">dct:abstract</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">dct:accrualMethod</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">dct:accrualPeriodicity</b></td>
+ <td>Descriptive metadata</td>
+ <td>Frequency of the addition of items to a collection.</td>
+ </tr><tr>
+ <td><b id="term_accrualPolicy">dct:accrualPolicy</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">dct:alternative</b></td>
+ <td>Descriptive metadata</td>
+ <td>Refers to an alternative name of the resource. </td>
+ </tr><tr>
+ <td><b id="term_audience">dct:audience</b></td>
+ <td>Descriptive metadata</td>
+ <td>The audience for whom the resource is useful.</td>
+ </tr><tr>
+ <td><b id="term_conformsTo">dct:conformsTo</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">dct:coverage</b></td>
+ <td>Descriptive metadata</td>
+ <td>Topic of the resource.</td>
+ </tr><tr>
+ <td><b id="term_description">dct:description</b></td>
+ <td>Descriptive metadata</td>
+ <td>An account of the resource.</td>
+ </tr><tr>
+ <td><b id="term_educationLevel">dct:educationLevel</b></td>
+ <td>Descriptive metadata</td>
+ <td>The educational level of the audience for which the resource is intended too.</td>
+ </tr><tr>
+ <td><b id="term_extent">dct:extent</b></td>
+ <td>Descriptive metadata</td>
+ <td>Size or duration of the resource.</td>
+ </tr><tr>
+ <td><b id="term_format">dct:format</b></td>
+ <td>Descriptive metadata</td>
+ <td>Format of the resource. </td>
+ </tr><tr>
+ <td><b id="term_identifier">dct:identifier</b></td>
+ <td>Descriptive metadata</td>
+ <td>An unambiguous reference on a given context. </td>
+ </tr><tr>
+ <td><b id="term_instructionalMethod">dct:instructionalMethod</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">dct:isPartOf</b></td>
+ <td>Descriptive metadata</td>
+ <td>Inverse of <code>dct:hasPart</code>.</td>
+ </tr><tr>
+ <td><b id="term_isRequiredBy">dct:isRequiredBy</b></td>
+ <td>Descriptive metadata</td>
+ <td>The current resource is required for supporting the function of another resource. This is not related
+ the provenance, since it refers to something that may not have happened yet (e.g., a library dependency, but the program
+ that needs it hasn’t been executed yet).</td>
+ </tr><tr>
+ <td><b id="term_language">dct:language</b></td>
+ <td>Descriptive metadata</td>
+ <td>Language of the resource.</td>
+ </tr><tr>
+ <td><b id="term_mediator">dct:mediator</b></td>
+ <td>Descriptive metadata</td>
+ <td>Entity that mediates access to the resource. </td>
+ </tr><tr>
+ <td><b id="term_medium">dct:medium</b></td>
+ <td>Descriptive metadata</td>
+ <td>Material of the resource.</td>
+ </tr><tr>
+ <td><b id="term_requires">dct:requires</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">dct:hasPart</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">dct:spatial</b></td>
+ <td>Descriptive metadata</td>
+ <td>Spatial characteristics of the content of the resource (e.g., the book is about Spain). Thus it can't be mapped to <code>prov:hadLocation</code>.</td>
+ </tr><tr>
+ <td><b id="term_subject">dct:subject</b></td>
+ <td>Descriptive metadata</td>
+ <td>Subject of the resource.</td>
+ </tr><tr>
+ <td><b id="term_tableOfContents">dct:tableOfContents</b></td>
+ <td>Descriptive metadata</td>
+ <td>List of subunits of the resource.</td>
+ </tr><tr>
+ <td><b id="term_temporal">dct:temporal</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">dct:title</b></td>
+ <td>Descriptive metadata</td>
+ <td>Title of the resource.</td>
+ </tr><tr>
+ <td><b id="term_type">dct:type</b></td>
+ <td>Descriptive metadata</td>
+ <td>Type of the resource.</td>
+ </tr><tr>
+ <td><b id="term_bibliographicCitation">dct:bibliographicCitation</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>dct:references</b></td>
+ <td> Provenance: How </td>
+ <td>This term could be used to refer to sources that have been used to create the document, but it could
+ be also used to cite the sources that are not relevant for the current work. For this reason it has been dropped
+ from the mapping.</td>
+ </tr><tr>
+ <td id="term_isReferencedBy"><b>dct:isRefrencedBy</b></td>
+ <td> Provenance: How </td>
+ <td>Inverse to <code>dct:references</code>.</td>
+ </tr><tr>
+ <td><b id="term_accessRights">dct:accessRights</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">dct:license</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">dct:rights</b></td>
+ <td>Provenance: How</td>
+ <td>Metadata about the rights of the resource.</td>
+ </tr><tr>
+ <td><b id="term_date">dct:date</b></td>
+ <td>Provenance: When</td>
+ <td>Date is a very general property. It is the superproperty which all the other specialize, but there is no equivalent concept in PROV. It has been excluded from the mapping</td>
+ </tr><tr>
+ <td><b id="term_available">dct:available</b></td>
+ <td>Provenance: When</td>
+ <td>Property that states when a resource is available. The group could not reach consensus on how to map this property, so it was finally dropped from the mapping.</td>
+ </tr><tr>
+ <td><b id="term_valid">dct:valid</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">dct:relation</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. Thus there is no direct mapping.<td>
+ </tr>
+ </tbody></table>
+</p>
+<div id="prov_to_dc" class="section">
+<h2><span class="secno">3. </span>Mapping from PROV to DC</h2>
+<p>
+The mapping from PROV to Dublin Core is not part of this note.
+It can be questioned, if a mapping without additional information would provide meaningful data.
+ If refinements are used, the mapping would be straight forward using the inverse of the
+ mapping patterns used in this document. However, without such refinements, few Dublin Core statements can be inferred,
+ apart from some unqualified dates. Dublin Core includes provenance information, but the focus lies on
+ the description of the resources. Pure PROV data models a provenance chain, but it contains almost
+ no information about the resulting resource itself. </p>
+ </div>
+
+ <div class="appendix section" id="acknowledgements">
+
+<!-- OddPage -->
+<h2><span class="secno">A. </span>Acknowledgements</h2>
+ <p>
+ We would like to thank Antoine Isaac, Ivan Herman, Timothy Lebo, Simon Miles and Satya Sahoo for their comments and feedback, and Idafen Santana Pérez for his help with the HTML generation.
+ </p>
+ </div>
+
+<!-- OddPage -->
+<div id="references" class="section">
+<h2><span class="secno">B. </span>References</h2>
+ <div id="normative-references" class="section"><h3><span class="secno">
+ B.1 </span>Normative references</h3>
+ <p>No normative references.</p>
+ </div>
+ <div id="informative-references" class="section">
+ <h3><span class="secno">B.2 </span>Informative references</h3>
+
+ <dl class="bibliography"><dt id="bib-DCMI">
+ [DCMI]</dt><dd><cite>Dublin Core Metadata Initiative</cite>. URL: <a href="http://dublincore.org/">http://dublincore.org/</a>
+ </dd></dl>
+
+ <dl class="bibliography"><dt id="bib-DCTERMS">
+ [DCTERMS]</dt><dd><cite>Dublin Core Terms Vocabulary</cite>. URL: <a href="http://dublincore.org/documents/dcmi-terms/">http://dublincore.org/documents/dcmi-terms/</a>
+ </dd></dl>
+
+ <dl class="bibliography"><dt id="bib-Constraints">
+ [PROV-CONTRAINTS]</dt><dd>James Cheney, Paolo Missier, and Luc Moreau (eds.) <a href="http://www.w3.org/TR/prov-constraints/"><cite>
+ Constraints of the PROV Data Model.</cite></a>. 2011. W3C Working Draft.
+ URL: <a href="http://www.w3.org/TR/prov-constraints/">http://www.w3.org/TR/prov-constraints/</a>
+ </dd></dl>
+
+ <dl class="bibliography"><dt id="bib-PROV-DM">
+ [PROV-DM]</dt><dd>Luc Moreau, Paolo Missier<a href="http://www.w3.org/TR/2011/WD-prov-dm-20120724/"><cite>
+ The PROV Data Model and Abstract Syntax Notation</cite></a>. 15 December 2011. W3C Working Draft. (Work in progress.)
+ URL: <a href="http://www.w3.org/TR/2011/WD-prov-dm-20111215/">http://www.w3.org/TR/2011/WD-prov-dm-20111215/</a>
+ </dd></dl>
+
+ <dl class="bibliography"><dt id="bib-PROV-DEF">
+ [PROV-DEF]</dt><dd> W3C Provenance Working Group's Definition of Provenance.URL: <a href="http://www.w3.org/TR/2012/WD-prov-dm-20120724/#dfn-provenance">http://www.w3.org/TR/2012/WD-prov-dm-20120724/#dfn-provenance</a>
+ </dd></dl>
+
+ <dl class="bibliography"><dt id="bib-PROV-O">[PROV-O]</dt><dd>Timothy Lebo, Satya Sahoo, Deborah McGuinness<a href="http://www.w3.org/TR/2011/WD-prov-o-20111213/">
+ <cite>The PROV Ontology: Model and Formal Semantics</cite></a>. 13 December 2011. W3C Working Draft. (Work in progress.)
+ URL: <a href="http://www.w3.org/TR/2011/WD-prov-o-20111213/">http://www.w3.org/TR/2011/WD-prov-o-20111213</a>
+ </dd></dl></div>
+</div>
+</body>
+</html>
\ No newline at end of file