Dublin Core mapping note document
authordgarijo
Wed, 25 Jul 2012 02:47:14 +0200
changeset 4246 ff940ee82d3d
parent 4245 5eb93b64c29e
child 4247 ad586d021111
Dublin Core mapping note document
dc-note/Overview.html
dc-note/extra.css
dc-note/files/DirectMappings.ttl
dc-note/files/Refinements.ttl
dc-note/files/construct queries/entity-agent/contributor.ttl
dc-note/files/construct queries/entity-agent/creator.ttl
dc-note/files/construct queries/entity-agent/publisher.ttl
dc-note/files/construct queries/entity-agent/rightsHolder.ttl
dc-note/files/construct queries/entity-date/created.ttl
dc-note/files/construct queries/entity-date/dateAccepted.ttl
dc-note/files/construct queries/entity-date/dateCopyRighted.ttl
dc-note/files/construct queries/entity-date/dateSubmitted.ttl
dc-note/files/construct queries/entity-date/issued.ttl
dc-note/files/construct queries/entity-date/modified.ttl
dc-note/files/construct queries/entity-entity/isFormatOf.ttl
dc-note/files/construct queries/entity-entity/isReferencedBy.ttl
dc-note/files/construct queries/entity-entity/isReplacedBy.ttl
dc-note/files/construct queries/entity-entity/isVersionOf.ttl
dc-note/files/construct queries/entity-entity/source.ttl
dc-note/img/ComplexMapping.png
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/Overview.html	Wed Jul 25 02:47:14 2012 +0200
@@ -0,0 +1,1765 @@
+<?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;
+}
+
[email protected] 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-WD" rel="stylesheet" type="text/css" charset="utf-8" /></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-10-january-2012">
+ <acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 19 August 2012</h2>
+ <dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2012/WD-prov-primer-20120110/">TO ADD</a></dd>
+ <dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/prov-primer/">TO ADD</a></dd>
+ <dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/primer/Primer.html">TO ADD</a></dd>
+ <dt>Editors:</dt>
+ <dd><a href="http://www.oeg-upm.net/index.php/en/phdstudents/28-dgarijo">Daniel Garijo</a></span>, Universidad Politécnica de Madrid</dd>
+<dd><a href="http://www.bib.uni-mannheim.de/279.html">Kai Eckert</a>, Manheim University Library, Manheim, Germany</dd>
+<dt>Authors:</dt>
+<dd><a href="http://www.inf.kcl.ac.uk/staff/simonm">Simon Miles</a>, King's College London, UK</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>
+
+
+  </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,
+   intuitive introduction and guide to the [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-DM">PROV-DM</a></cite>] data model for
+   provenance. It includes simple worked examples applying the [<cite><a class="bibref" rel="biblioentry" href="#bib-PROV-O">PROV-O</a></cite>]
+   OWL2 ontology. 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 a First Public Working Draft.
+   If you wish to make comments regarding this document, please send them to 
+   <a href="mailto:[email protected]">[email protected]</a>
+   (<a href="mailto:[email protected]?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 a Working 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:document1? 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>
+					</ul>
+				<li class="tocline"><a href="#cleanup" class="tocxref"><span class="secno">2.6 </span>Cleanup</a></li>
+				<li class="tocline"><a href="#list_of_excluded_terms" class="tocxref"><span class="secno">2.7 </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 refered to as Dublin Core. Originally, it consisted of 15 elements that are still available and called
+	the element set . The elements are defined very broadly, in particular they have no
+	range specification, i.e., they can be used with arbitrary values as objects. The elements have been further
+	refined and types have been introduced. This more specific vocabulary is called the terms and currently consists
+	of 55 properties [<a href="#bib-DCTERMS">DCTERMS</a>].
+	</p>
+The Dublin Core elements are considered legacy and the use of the DCMI terms is preferred. Both have different namespaces, 
+usually the elements are used with the <span class="repeated">dc</span>, the terms with <span class="repeated">dct</span> or <span class="repeated">dcterms</span>.
+
+Consider the following example for a metadata record:
+<pre class="example" id="example1">
+ ex:document1 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. 
+For instance, dct:title, dct:subject and dct:format are descriptions of the resource ex:document1. 
+They do not provide any information how the resource was created or modified in the past.
+ On the other hand, some statements imply provenance-related information, e.g., dct:creator 
+ implies that the document has been created and refers to the author. Similarly, the existence 
+ of the dct:issued date implies that the document has been published. This information is redundantly 
+ implied by the dct:publisher statement as well. Finally, dct:replaces relates 
+ our document to another document ex:doc2 and it can be inferred that this document had probably
+ some kind of influence on our document ex:document1, which also gives us some provenance related information.
+</p><p>
+This is a pattern that applies generally to metadata, i.e., we can distinguish 
+description metadata and provenance metadata. To be more precise, we define provenance 
+metadata 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>
+This classification can certainly be questioned and was already subject to many discussions. We use a very
+ conservative strategy: if the group can't reach consensus about if an element should be mapped to PROV or not, 
+ we exclude it from tha mapping list. This way, we want to ensure that rather less, but correct provenance
+ data is created than more, but possibly incorrect data.
+</p><p>
+According to our classification, there are 25 terms out of 55 that can be considered as provenance related.
+ Based on their different aspects of provenance, we discuss them below:
+</p><p>
+<b>Who?</b> (contributor, creator, publisher, rightsHolder) Category that includes all properties that have the range dct:Agent,
+ i.e., a resource that acts or has the power to act. The contributor, creator, and publisher clearly influence
+ the resource and therefore are important for its origin. This is not immediately clear for the rightsHolder,
+ but as ownership is considered the important provenance information for artworks, we have decided to include it in this category.
+</p><p>
+<b>When?</b> (available, created, date, dateAccepted, dateCopyrighted, dateSubmitted, issued, modified, valid)
+ Dates typically belong to the provenance record of a resource. It can be questioned whether a resource changes by
+ being published or not. However, we consider the publication as an action that affects the state of the resource and
+ therefore it is relevant for the provenance. Two dates can be considered special regarding their relevance for
+ provenance: available and valid. They are different from the other dates as by definition they can represent a
+ date range. Often, the range of availability or validity of a resource is inhererent to the resource and known
+ beforehand – consider the validity of a passport or a credit card or the availability of a limited special offer.
+ 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, this is relevant for its provenance.
+</p><p>
+<b>How?</b> (isVersionOf, hasVersion, isFormatOf, hasFormat, references, isReferencedBy, replaces, isReplacedBy, source, rights, license)
+ 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 isVersionOf, isFormatOf, replaces, source.
+ references 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>. It 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 refers to the traditional definition of provenance for artworks. Despite being relevant for provenance from the
+W3C Provenance Incubator Group's persepctive, this definition it 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, when it was affected in the past, who affected it and how it was affected.
+ The description metadata, i.e., the other DCMI terms, tells us what was affected. There is 
+ no direct information in Dublin Core describing where a resource was affected. Such information is usually only available for the
+ publication of a resource, i.e., this action is located at the address of the publisher. Note that spatial is not related
+ to this question, as this is a descriptive property that tells us for instance that a book is about Berlin, but not that
+ it was created in Berlin – 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. -->
+</p>
+<h3 id ="namespaces">1.1 Namespaces</h3> 
+<p>In this document we use namespaces from different vocabularies to create the mapping.
+ The namespaces we will be using 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>&lt;http://www.w3.org/2002/07/owl#&gt;</td></tr>
+	<tr><td><b>rdfs</b></td><td>&lt;http://www.w3.org/2000/01/rdf-schema#&gt;</td></tr>
+	<tr><td><b>prov</b></td><td>&lt;http://www.w3.org/ns/prov#&gt;</td></tr>
+	<tr><td><b>dct</b></td><td>&lt;http://purl.org/dc/terms/&gt;</td></tr>
+	<tr><td><b>dcprov</b></td><td>&lt;TO_BE_DETERMINED&gt;</td></tr>
+	</tbody>
+  </table>
+  </div>
+</p>
+</div>
+<div id="Mapping" class="section"> 
+<h2>2. Mapping from Dublin Core to PROV</h2>
+<p>Why are we concerned with a mapping between Dublin Core and PROV? First, such a mapping can provide valuable insights
+ into the different characteristics of both data models, in particular it "explains" PROV from a Dublin Core view point.
+ Second, such a mapping can be used to extract PROV data from the huge amount of Dublin Core data that is available on 
+ the Web today. Third, it can translate PROV data to Dublin Core and therefore make it accessible for applications that
+ understand Dublin Core. And not least, it can lower the barrier to adopt PROV, as simple Dublin Core statements can be
+ used as starting point to generate PROV data. </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.
+</p><p>
+
+</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 partt 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. Based on the context-free mapping, reasoning patterns can be employed to clean-up the data, e.g. by conflating blank nodes
+ that are actually the same or by identifying a final specialization of the original document that is identical to this document.
+</p>
+<p>
+</div>
+<div id="entities_in_dc" class="section">
+<h3><span class="secno">2.2 </span>What is ex:document1? Entities in Dublin Core</h3>
+<p>
+Consider the example metadata record above (<a href="#example1">example 1)</a>. As a DC 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 can have assigned a dct:created date and a dct:issued date. The activity of issuing a document
+ does not necessarily change the document, but regarding the PROV ontology, there are two different specializations of
+ this document before and after the issuing activity, distinguishable by the property of the document that states if
+ the document was issued. Generally, there are two possibilities to deal with this issue:</p>
+</p><p>
+    1): We can always create new instances of entities, typically as blank nodes, that all are related to the original
+	document by means of prov:specializationOf. This leads to bloated and not very intuitive data models, e.g. think
+	about the translation of a single dct:creator statement, where you 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>	
+    2): We can always use the original document as the instance that is used as prov:Entity. The implications regarding
+	the semantics of a prov:Activity are not yet totally clear, however, it contradicts the above mentioned definition
+	to have an activity that uses an entity and generates the same entity. If an activity actually generates an entity,
+	it is semantically incorrect to have several activities that all generate the same entity at different points in time.
+	<!--<b>This has to be investigated and discussed further. For references, see PROV-DM Generation, PROV-DM Derivation,
+	PROV-O Activity</b>.-->
+</p><p>
+	<div id = "figure_mapping_example" class="figure" style="text-align: center;">
+	<img src="img/ComplexMapping.png"></img>
+	<div style="text-align: center;">
+<a href="#figure_mapping_example">Figure 1</a>. A mapping example	
+	</div>
+	</div>
+</p><p>	
+As the first option is the more conservative one with respect to the underlying semantics, our proposal is to use
+ it in for the context-free mapping. We will use blank nodes, although any naming mechanism could be provided if necessary,
+leaving the conflating of nodes to the clean-up phase. 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 ex:document1? We could create two entities based on the actual creation activity:
+	ex:document1 and a first specialization. We could further declare the last produced specialization as the same entity as ex:document1.
+	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 RDFS-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.
+ Those mappings in which the group could not find consensus have been dropped. For more information see 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 dct:Agent and prov:Agent refer to the same thing: a resource that has the power to act (which then has responsability 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 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>dct:isVersion of refers to "a related resource to which the current resource is a version, edition or adaptation". Hence we can
+		conclude that the current resource has been derived from the original one.</td>
+	</tr>
+	<tr>
+		<td><b>dct:hasVersion</b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:hadDerivation</td>
+		<td>Inverse property of the previous one.</td>
+	</tr>
+	<tr>
+		<td><b>dct:isFormatOf</b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:alternateOf</td>
+		<td>dct.isFormatOf refers to another resource which is the same but in another format. Thus the mapping is straightforward to prov:alternateOf</td>
+	</tr>
+	<tr>
+		<td><b>dct:hasFormat</b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:alternateOf</td>
+		<td> See rationale for dct:hasFormat</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 2 resources when the former replaces the latter, but it is not necessarily
+		derivation, revision, specification or alternate. Since we want to state some influence but we don't find any specific relation that matches
+		the dct term, we propose to map it to the abstract term prov:wasInfluencedBy</td>
+	</tr>
+	<tr>
+		<td><b>dct:isReplacedBy</b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:influenced</td>
+		<td>Inverse property of the previous one</td>
+	</tr>
+	<tr>
+		<td><b>dct:source </b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:wasDerivedFrom</td>
+		<td>In Dublin Core, dct:source 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 refer to the same thing: the nature of the resource (or genre). It could be mapped to rdf:type if we map the document against PROV-O</td>
+	</tr>
+	<tr>
+		<td><b>dct:created</b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:generatedAtTime</td>
+		<td>dct:created is a property to describe the time of cretion of the entity, which is the time of its generation as well. We have decided
+		to map it as a subclass because the resources in Dublin Core have associated many dates, which could be associated to each of their versions.
+		In this case, we see the creation as the first one, but not necessarily 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 prov:generatedAtTime 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 2 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 previous property</td>
+	</tr>
+	<tr>
+		<td><b>dct:dateSubmitted</b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:generatedAtTime</td>
+		<td>See previous property</td>
+	</tr>
+	<tr>
+		<td><b>dct:modified</b></td>
+		<td>rdfs:subPropertyOf</td>
+		<td>prov:generatedAtTime</td>
+		<td>See previous property</td>
+	</tr>
+	</tbody>
+</table>
+</div>
+Regarding the dates mappings, we realize that if we have a metadata record such as <a href="#example1">example 1</a>, the direct mapping will infer that 
+the resource was prov:generatedAtTime at two different times. Although this may seem inconsistent, it is supported by PROV and it is due 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. It would produce "scruffy" provenance (i.e., valid provenance which will not comply with all the PROV consraints [<a href="#bib-Constraints">PROV_CONSTRAINTS]</a>)
+</p>
+<p>
+We end the direct mapping with the properties that have been found to be superproperties of certain prov concepts. The summary 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>It is surprising to see that some terms of Dublin Core are more general than the ones defined in PROV. However the definition of prov:hadPrimarySource
+			("something produced by some agent with direct experience and knowledge about the topic") is more restrictive than dct:source ( "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, prov:wasRevisionOf is more restrictive in the sense that it refers to revised version of a resource, while
+			dct:isVersionOf involves versions, editions or adaptations of the original resource.</td>
+		</tr>
+		</tbody>
+	</table>
+</div>
+</p>
+
+<!--<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, we need refinements,
+ i.e. more specific subclasses:
+</p><p>
+<pre class="code">
+ dcprov:PublicationActivity      rdfs:subClassOf     prov:Activity .
+ dcprov:ContributionActivity     rdfs:subClassOf     prov:Activity .
+ dcprov:CreationActivity         rdfs:subClassOf     prov:Activity, dcprov:ContributionActivity .
+ dcprov:ModificationActivity     rdfs:subClassOf     prov:Activity .
+ dcprov:AcceptanceActivity       rdfs:subClassOf     prov:Activity .
+ dcprov:CopyrightingActivity     rdfs:subClassOf     prov:Activity .
+ dcprov:SubmissionActivity       rdfs:subClassOf     prov:Activity .
+ dcprov:PublisherRole            rdfs:subClassOf     prov:Role .
+ dcprov:ContributorRole          rdfs:subClassOf     prov:Role . 
+ dcprov:CreatorRole              rdfs:subClassOf     prov:Role, dcprov: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 wanted, 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 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 four terms: contributor, creator, publisher, and rightsHolder. The former three
+ can be mapped with the same pattern, similar to the one presented in <a href="#figure_mapping_example">Figure 1</a>.
+ The only main changes changes are the roles and activities involved in each term.
+ 
+ <p>
+ In the text below, variables ?document and ?agent 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. A lot of 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.
+ Our implementation is only an example that works conservatively, i.e., we assume that there is no further
+ information about the identity of specializations available. 
+
+</p>
+ 
+</p><p>
+<h5 id="term_creator"><span class="secno">2.5.1.1 </span>dct:creator</h5>
+The creator is the agent associated with role CreatorRole in the CreationActivity that created a specialization of the entity (?document). 
+We avoid using the Dublin Core entity because it may have other statements referring to it (about publishing, licensing, modifying it, etc.). 
+<pre class="code">
+ CONSTRUCT {
+    ?document a prov:Entity .
+		prov:wasAttributedTo ?agent.
+    ?agent a prov:Agent .
+    _:activity a prov:Activity, dcprov:CreationActivity ;
+		prov:wasAssociatedWith ?agent;
+		prov:qualifiedAssociation [
+			a prov:Association;
+			prov:agent ?agent;
+			prov:hadRole dcprov: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>
+In the same way, publisher and contributor can be mapped, 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, dcprov:ContributionActivity ;
+		prov:wasAssociatedWith ?agent ;
+		prov:qualifiedAssociation [ 
+			a prov:Association ;
+			prov:agent ?agent ;
+			prov:hadRole dcprov: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 .
+    _:activity a prov:Activity, dcprov:PublicationActivity ;
+		prov:wasAssociatedWith ?agent ;
+		prov:qualifiedAssociation [ 
+			a prov:Association ;
+			prov:agent ?agent ;
+			prov:hadRole dcprov:PublisherRole .
+		]
+    _:resulting_entity a prov:Entity ;
+		prov:specializationOf ?document ;
+		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
+ prov:wasAttributedTo. 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>
+The dates often correspond with a who-property, e.g., creator and created or publisher and issued.
+ Therefore, they lead to similar statements, only providing a date instead of an agent associated with the activity.
+ We use issued as an example here, because from issued, two specializations can be inferred: something must be available
+ before it can be published.
+</p>
+<p>
+When using Dublin Core terms, it is usual to see that a resource is annotated with several dc assertions like creator, publisher,
+ issued, date, etc. Therefore if we assume that each date corresponds to the generation date by an activity (creationActivity,
+ publishingActivity, etc.) then we can't say that all those activities generated the resource. Instead, in order to generate "proper"
+ provenance records, we say that all those activities generated an entity which for which the resource is a specialization.
+</p>
+<h5 id="term_created"><span class="secno">2.5.2.1 </span>dct:created</h5> 
+</p><p><pre class="code">
+ CONSTRUCT{
+ ?document           a                         prov:Entity .
+					
+ _:activity          a                         prov:Activity, dcprov: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, dcprov: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>
+As seen with the following terms, most entity/date properties will have a similar structure.
+</p><p><pre class="code"> 
+ CONSTRUCT{
+ ?document             a                         prov:Entity .
+ 
+ _:activity            a                         prov:Activity, dcprov: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><p>
+<h5 id="term_dateAccepted"><span class="secno">2.5.2.4 </span>dct:dateAccepted</h5> 
+</p><p><pre class="code"> 
+ CONSTRUCT{
+ ?document             a                         prov:Entity .
+ 
+ _:activity            a                         prov:Activity, dcprov: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, dcprov: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, dcprov: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 id="entity_entity_mappings">
+<h4><span class="secno">2.5.3 </span>Entity-Entity mappings (How)</h4>
+<p>
+Most Dublin Core terms in this category are related to the prov:wasDerivedFrom property.
+ They can be mapped directly, but also a complex mapping can be provided. In these cases, a specialty of SPARQL 
+ CONSTRUCT queries can be used to deal with the inverse properties in Dublin Core.
+</p>
+<h5 id="term_has_Version"><span class="secno">2.5.3.1 </span>dct:isVersionOf / dct:hasVersion</h5>
+<p>
+I would say that prov:wasDerivedFrom>dct:isVersionOf>prov:wasRevisionOf. Thus:
+</p><p><pre class="code">
+ CONSTRUCT {
+    ?document1 a prov:Entity ;
+       prov:wasDerivedFrom ?document2.
+    ?document2 a prov:Entity .
+ } WHERE {
+    OPTIONAL { ?document1 dct:isVersionOf ?document2 . }
+    OPTIONAL { ?document2 dct:hasVersion ?document1 .}
+ }
+</pre>
+</p><p>
+ The OPTIONAL keyword means that the included statement does not need to exist.
+ Triples in the resulting graph with variables that have no binding simply are omitted.
+ In this case this leads to the correct PROV statement, if either or both source statements are present.
+ From the entity/entity relations, <b>an activity can also be inferred (e.g., the activity that led to the creation of the new version)
+ . We omit it here for brevity.</b>
+ </p>
+ <!--<p>
+ In essence, these examples sketch the first part of the mapping. As everything is provided as 
+ RDF statements or SPARQL CONSTRUCT queries, this mapping can simply applied to arbitrary RDF data by
+ adding the statements and the resulting graphs from the queries to the data. 
+ </p>-->
+ <p>
+<h5 id="term_has_Format"><span class="secno">2.5.3.2 </span>dct:isFormatOf / dct:hasFormat</h5>
+</p><p>
+isFormatOf is defined as “A related resource that is substantially the same as the described resource, but in another format”. This
+ would map to prov:alternateOf. We don’t know which entities are both of them specializing, but we know that one is an alternate of the other.
+</p><p> <pre class="code">
+ CONSTRUCT {
+    ?document1 a prov:Entity ;
+       prov:alternateOf ?document2.
+    ?document2 a prov:Entity .
+ } WHERE {
+    OPTIONAL { ?document1 dct:isFormatof ?document2 . }
+    OPTIONAL { ?document2 dct:hasFormat ?document1 .}
+ }
+</pre></p><p>
+ 
+<!--
+dct:isReferencedBy / dct:references
+</p><p>
+IsReferencedBy: A related resource that references, cites, or otherwise points to the described resource.
+</p><p><pre class="code">
+ 
+  CONSTRUCT {
+    ?document1 a prov:Entity ;
+    ?document2 a prov:Entity .
+       prov:wasDerivedFrom ?document2.
+ } WHERE {
+    OPTIONAL { ?document1 dct:isReferencedBy ?document2 . }
+    OPTIONAL { ?document2 dct:references ?document1 .}
+ }
+ 
+</pre></p><p>-->
+</p>
+<h5 id="term_replaces"><span class="secno">2.5.3.3 </span>dct:replaces / dct:isReplacedBy</h5>
+<p><pre class="code">
+ CONSTRUCT {
+    ?document1 a prov:Entity ;
+       prov:wasInfluencedBy ?document2.
+    ?document2 a prov:Entity .
+ } WHERE {
+    OPTIONAL { ?document1 dct:replaces ?document2 . }
+    OPTIONAL { ?document2 dct:isReplacedBy ?document1 .}
+ }
+</pre></p><p>
+<h5 id="term_source"><span class="secno">2.5.3.4 </span>dct:source</h5>
+</p><p><pre class="code">
+ CONSTRUCT{
+   ?document1     a   prov:Entity ;
+                  prov:wasDerivedFrom    :subj2 .
+   ?document2     a   prov:Entity .
+  } WHERE { 
+   ?document1 dct:source ?document2.
+  }
+</pre>
+</p>
+</div>
+</div>
+<div id="cleanup" class="section">
+<h2><span class="secno">2.6 </span>Cleanup</h2>
+<p>
+The clean-up phase depends on the intensions of the implementor and the answer to the question,
+ <i>what is the described resource (ex:document1)?</i> in the resulting provenance data. 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 implementor, 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 implementors with ideas 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, we could group
+ some of the records and create more complete PROV assertions.</p>
+ <p>Example: Combining created and creator:
+ <pre class="code">
+ CONSTRUCT{
+ ?document               a                         prov:Entity .
+ 
+ _:activity              a                         prov:Activity, dcprov:CreationActivity.
+                         prov:wasAssociatedWith ?agent;
+		                 prov:qualifiedAssociation [
+			                  a prov:Association;
+			                  prov:agent ?agent;
+			                  prov:hadRole dcprov:CreatorRole .
+                         ]
+			  
+ # The “output”
+ _:created_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:creator  ?agent;
+            dct:created  ?date.
+ }
+ </pre>
+ </p>
+ <p>2) Another solution would be 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. </p>
+<p>3) Finally, another simpler idea is to <b>ignore all the specializations of ex:document1 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 publisher and creator), 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).
+</p>
+<p>
+</p>
+</div>
+<div id="list_of_excluded_terms" class="section">
+<h2><span class="secno">2.7. </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 itslef, so we decided to leave this term out of the mpping</td>
+	</tr><tr>
+		<td><b id="term_accrualPeriodicity">dct:accrualPeriodicity</b></td>
+		<td>Descriptive metadata</td>
+		<td>Frequency of the items added 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. We could use it 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. Descriptive metadata.</td>
+	</tr><tr>
+		<td><b id="term_identifier">dct:identifier</b></td> 
+		<td>Descriptive metadata</td>
+		<td>An unambiguous reference on a given context. Note: it could be mapped to the PROV-DM' ID for entities. </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 hasPart.</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 isRequiredBy (see isRequiredBy).</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. Entity composition is out of the scope of DM, so 
+	we leave it out of the mapping list as well</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 resource (e.g., the book is about Spain). Thus it can't be mapped to prov:hadLocation.</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., :el_Quijote dct:bibliographicCitation "Miguel de Cervantes Saavedra: El Quijote, España").</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. Since we could not reach consensus on how 
+			to map it to prov, we have left it out of the mapping</td>
+	</tr><tr>
+		<td id="term_isReferencedBy"><b>dct:isRefrencedBy</b></td> 
+		<td> Provenance: How </td>
+		<td>Inverse to dct:references.</td>
+	</tr><tr>
+		<td><b id="term_accessRights">dct:accessRights</b></td>
+		<td>Provenance: How</td>
+		<td>Who can access the resource (security status). Since the privileges of the resource are part of the 
+	description of the resource, it’s not included in the list.</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 list because there is no term in PROV-O to map to.</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. We have decided to leave it with no 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. We couldn't find consensus on how to map this property, so it was dropped.</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. We have the notion of invalidation in PROV-O, but not the notion of validation. Thus we leave this property 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. 
+			It could be seen as a superproperty of wasDerivedFrom, wasInfluencedBy, alternateOf, specializationOf, 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 DC 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 and more or less the inverse of the
+ mapping patterns that we used. However, without such refinements, almost no DC statements can be inferred,
+ besides 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, Timothy Lebo, Simon Miles, and Satya Sahoo for their feedback. 
+   </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
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/extra.css	Wed Jul 25 02:47:14 2012 +0200
@@ -0,0 +1,75 @@
+
+/* --- EDITORIAL NOTES --- */
+.pending {
+    padding:    1em;
+    margin: 1em 0em 0em;
+    border: 1px solid #f00;
+    background: #BFEFFF;
+}
+
+.pending::before {
+    content:    "Pending Review";
+    display:    block;
+    width:  150px;
+    margin: -1.5em 0 0.5em 0;
+    font-weight:    bold;
+    border: 1px solid #f00;
+    background: #fff;
+    padding:    3px 1em;
+}
+
+
+.resolved {
+    padding:    1em;
+    margin: 1em 0em 0em;
+    border: 1px solid #f00;
+    background: #9BCD9B;
+}
+
+.resolved::before {
+    content:    "Resolved";
+    display:    block;
+    width:  150px;
+    margin: -1.5em 0 0.5em 0;
+    font-weight:    bold;
+    border: 1px solid #f00;
+    background: #fff;
+    padding:    3px 1em;
+}
+
+
+.inference {
+    padding:    1em;
+    margin: 1em 0em 0em;
+    border: 0px solid #f00;
+    background: #fff;
+}
+
+.inference::before {
+    content:    "Inference";
+    display:    block;
+    width:  150px;
+    margin: -1.5em 0 0.5em 0;
+    font-weight:    bold;
+    border: 1px solid #f00;
+    background: #fff;
+    padding:    3px 1em;
+}
+
+.constraint {
+    padding:    1em;
+    margin: 1em 0em 0em;
+    border: 1px solid #00f;
+    background: #fff;
+}
+
+.constraint::before {
+    content:    "Constraint";
+    display:    block;
+    width:  150px;
+    margin: -1.5em 0 0.5em 0;
+    font-weight:    bold;
+    border: 1px solid #00f;
+    background: #fff;
+    padding:    3px 1em;
+}
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/files/DirectMappings.ttl	Wed Jul 25 02:47:14 2012 +0200
@@ -0,0 +1,26 @@
[email protected] prov: <http://www.w3.org/ns/prov#>.
[email protected] dct: <http://purl.org/dc/terms/>.
[email protected] dcprov: <to be determined>.
[email protected] owl: <http://www.w3.org/2002/07/owl#>.
[email protected] rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+
+ dct:Agent           owl:equivalentClass       prov:Agent.
+ dct:rightsHolder    rdfs:subPropertyOf        prov:wasAttributedTo .
+ dct:creator         rdfs:subPropertyOf        prov:wasAttributedTo .
+ dct:publisher       rdfs:subPropertyOf        prov:wasAttributedTo .
+ dct:contributor     rdfs:subPropertyOf        prov:wasAttributedTo .
+ dct:isVersionOf     rdfs:subPropertyOf        prov:wasDerivedFrom .
+ dct:isFormatOf      rdfs:subPropertyOf        prov:alternateOf .
+ dct:replaces        rdfs:subPropertyOf        prov:tracedTo .
+ dct:source          rdfs:subPropertyOf        prov:wasDerivedFrom .
+ dct:type            owl:equivalentProperty    prov:type .
+ 
+ prov:hadOriginalSource rdfs:subPropertyOf dct:source .
+ prov:wasRevisionOf     rdfs:subPropertyOf dct:isVersionOf .
+ 
+ dct:created         rdfs:subPropertyOf    prov:generatedAtTime .
+ dct:issued          rdfs:subPropertyOf    prov:generatedAtTime .
+ dct:dateAccepted    rdfs:subPropertyOf    prov:generatedAtTime .
+ dct:dateCopyRighted rdfs:subPropertyOf    prov:generatedAtTime .
+ dct:dateSubmitted   rdfs:subPropertyOf    prov:generatedAtTime .
+ dct:modified        rdfs:subPropertyOf    prov:generatedAtTime .
\ No newline at end of file
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/files/Refinements.ttl	Wed Jul 25 02:47:14 2012 +0200
@@ -0,0 +1,12 @@
[email protected] prov: <http://www.w3.org/ns/prov#>.
[email protected] dct: <http://purl.org/dc/terms/>.
[email protected] dcprov: <to be determined>.
[email protected] owl: <http://www.w3.org/2002/07/owl#>.
[email protected] rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+
+ dcprov:PublicationActivity      rdfs:subClassOf     prov:Activity .
+ dcprov:ContributionActivity     rdfs:subClassOf     prov:Activity .
+ dcprov:CreationActivity         rdfs:subClassOf     prov:Activity, dcprov:ContributionActivity .
+ dcprov:PublisherRole            rdfs:subClassOf     prov:Role .
+ dcprov:ContributorRole          rdfs:subClassOf     prov:Role . 
+ dcprov:CreatorRole              rdfs:subClassOf     prov:Role, dcprov:ContributorRole .
\ No newline at end of file
Binary file dc-note/img/ComplexMapping.png has changed