Change of name according to the pubrules
authordgarijo
Fri, 30 Nov 2012 18:35:41 +0100
changeset 5224 b7c37d15cc00
parent 5223 2e4addf19b08
child 5225 c810db4fb43a
Change of name according to the pubrules
dc-note/releases/NOTE-prov-dc-20121211/Overview.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/dc-note/releases/NOTE-prov-dc-20121211/Overview.html	Fri Nov 30 18:35:41 2012 +0100
@@ -0,0 +1,2050 @@
+<!DOCTYPE html>
+<html dir="ltr" lang="en"><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="img/toggles.js"></script> -->
+  
+
+  
+  <!-- check why this import doesn't work <script src="../model/prov-magic.js" class="remove"></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;
+}
+
[email protected] screen {
+    p.practicedesc {
+        position: relative;
+        top: -2em;
+        padding: 0;
+        margin: 1.5em 0.5em -1em 1em;
+    }
+}
+
+  </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; }
+
+.parameters th, .exceptions th {
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+    font-family:    initial;
+    font-weight:    normal;
+    text-shadow:    #666 1px 1px 0;
+}
+.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.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 charset="utf-8" type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css"></head>
+ <body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p><h1 class="title" id="title">Dublin Core to PROV Mapping</h1><h2 id="w3c-working-draft-30-november-2012"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 30 November 2012</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2012/WD-prov-dc-20121130/">http://www.w3.org/TR/2012/WD-prov-dc-20121130/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/prov-dc/">http://www.w3.org/TR/prov-dc/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/dc-note.html">http://dvcs.w3.org/hg/prov/raw-file/default/dc-note/dc-note.html</a></dd><dt>Editors:</dt><dd><a href="http://delicias.dia.fi.upm.es/members/DGarijo/">Daniel Garijo</a>, Universidad Politécnica de Madrid, Spain</dd>
+<dd><a href="http://www.kaiec.org/">Kai Eckert</a>, Manheim University Library, Germany</dd>
+<dt>Authors:</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 class="introductory section" id="abstract"><h2>Abstract</h2>
+	   <p>
+		This document provides a mapping between the PROV-O OWL2
+		ontology [<cite><a href="#bib-PROV-O" rel="biblioentry" class="bibref">PROV-O</a></cite>] and
+		the Dublin Core Terms Vocabulary [<cite><a href="#bib-DCTERMS" rel="biblioentry" class="bibref">DCTERMS</a></cite>]. 
+	   </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>
+	  <h4 id="prov-family-of-documents">PROV Family of Documents</h4>
+		This document is part of the PROV family of documents, a set of 
+documents defining various aspects that are necessary to achieve the 
+vision of inter-operable
+		interchange of provenance information in heterogeneous environments 
+such as the Web.  These documents are:
+		<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 [<cite><a href="#bib-PROV-OVERVIEW" rel="biblioentry" class="bibref">PROV-OVERVIEW</a></cite>];</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 [<cite><a href="#bib-PROV-PRIMER" rel="biblioentry" class="bibref">PROV-PRIMER</a></cite>];</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 [<cite><a href="#bib-PROV-O" rel="biblioentry" class="bibref">PROV-O</a></cite>];</li>
+		<li> <a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/">PROV-DM</a> (Recommendation), the PROV data model for provenance [<cite><a href="#bib-PROV-DM" rel="biblioentry" class="bibref">PROV-DM</a></cite>];</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 [<cite><a href="#bib-PROV-N" rel="biblioentry" class="bibref">PROV-N</a></cite>];</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 [<cite><a href="#bib-PROV-CONSTRAINTS" rel="biblioentry" class="bibref">PROV-CONSTRAINTS</a></cite>];</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 [<cite><a href="#bib-PROV-AQ" rel="biblioentry" class="bibref">PROV-AQ</a></cite>]; </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 [<cite><a href="#bib-PROV-XML" rel="biblioentry" class="bibref">PROV-XML</a></cite>].</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 id="how-to-read-the-prov-family-of-documentation">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>
+ </ul><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-comments/">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 class="section" id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a class="tocxref" href="#introduction"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a class="tocxref" href="#mapping-from-dublin-core-to-prov"><span class="secno">2. </span>Mapping from Dublin Core to PROV</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#basic-considerations"><span class="secno">2.1 </span>Basic considerations </a></li><li class="tocline"><a class="tocxref" href="#what-is-ex-doc1--entities-in-dublin-core"><span class="secno">2.2 </span>What is ex:doc1? Entities in Dublin Core</a></li><li class="tocline"><a class="tocxref" href="#direct-mappings"><span class="secno">2.3 </span>Direct mappings</a></li><li class="tocline"><a class="tocxref" href="#prov-refinements"><span class="secno">2.4 </span>PROV refinements</a></li><li class="tocline"><a class="tocxref" href="#complex-mappings"><span class="secno">2.5 </span>Complex Mappings</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#entity-agent-mappings--who"><span class="secno">2.5.1 </span>Entity-Agent mappings (Who)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#dct-creator"><span class="secno">2.5.1.1 </span> dct:creator</a></li><li class="tocline"><a class="tocxref" href="#dct-contributor"><span class="secno">2.5.1.2 </span>dct:contributor</a></li><li class="tocline"><a class="tocxref" href="#dct-publisher"><span class="secno">2.5.1.3 </span>dct:publisher</a></li></ul></li><li class="tocline"><a class="tocxref" href="#entity-date-mappings--when"><span class="secno">2.5.2 </span>Entity-Date mappings (When)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#dct-created"><span class="secno">2.5.2.1 </span> dct:created</a></li><li class="tocline"><a class="tocxref" href="#dct-issued"><span class="secno">2.5.2.2 </span>dct:issued</a></li><li class="tocline"><a class="tocxref" href="#dct-modified"><span class="secno">2.5.2.3 </span>dct:modified</a></li><li class="tocline"><a class="tocxref" href="#dct-dateaccepted"><span class="secno">2.5.2.4 </span>dct:dateAccepted</a></li><li class="tocline"><a class="tocxref" href="#dct-datecopyrighted"><span class="secno">2.5.2.5 </span>dct:dateCopyrighted</a></li><li class="tocline"><a class="tocxref" href="#dct-datesubmitted"><span class="secno">2.5.2.6 </span>dct:dateSubmitted</a></li></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#cleanup"><span class="secno">2.6 </span>Cleanup</a></li><li class="tocline"><a class="tocxref" href="#list-of-terms-excluded-from-the-mapping"><span class="secno">2.7 </span>List of terms excluded from the mapping</a></li><li class="tocline"><a class="tocxref" href="#mapping-from-prov-to-dc"><span class="secno">2.8 </span>Mapping from PROV to DC</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div>  
+   
+
+ <div class="section" id="introduction">
+<!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
+
+   <p>
+    The Dublin Core Metadata Initiative (DCMI) [<cite><a href="#bib-DCMI" rel="biblioentry" class="bibref">DCMI</a></cite>]
+ 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 [<cite><a href="#bib-DCTERMS" rel="biblioentry" class="bibref">DCTERMS</a></cite>].
+	</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>
+	<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" [<cite><a href="#bib-DCTERMS" rel="biblioentry" class="bibref">DCTERMS</a></cite>],
+	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:
+	</p><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></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:
+	 </p><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>
+		</tbody>
+	  </table>
+	  </div>
+	<p></p>
+	
+</div>
+
+<div class="section" id="mapping-from-dublin-core-to-prov"> 
+	<!--OddPage--><h2><span class="secno">2. </span>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 class="section" id="basic-considerations">
+		<h3><span class="secno">2.1 </span>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>
+	</p></div>
+	<div class="section" id="what-is-ex-doc1--entities-in-dublin-core">
+		<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 approaches to deal with 
+this issue:</p>
+		<p></p><p>
+			1) To 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>
+			</p><div id="figure_mapping_example" class="figure" style="text-align: center;">
+			<img src="img/example1.png">
+			<div style="text-align: center;">
+			<a href="#figure_mapping_example">Figure 1</a>. A mapping example creating blank nodes for each state of the resource. In PROV entities are represented
+		with ellipses, activities with rectangles and agents with pentagons.	
+			</div>
+			</div>
+		<p></p><p>	
+			2) To adopt the original resource (<code>ex:doc1</code>) as the <code>prov:Entity</code> used and then generated by the PublicationActivity 
+			(<code>:_activity</code>). However, this representation leads to a misinterpretation of the <code>dct</code> statement, as shown in the example of 
+			<a href="#figure_mapping_example_conflating">Figure 2</a>.	The representation implies that <code>ex:doc1</code>
+			was generated by <code>_:activity</code> and then used by <code>_:activity</code> afterwards, instead of being used and then being generated by 
+			<code>_:activity</code> (<code>prov:Entities</code> must exist before being used).
+						
+		</p><p>
+			</p><div id="figure_mapping_example_conflating" class="figure" style="text-align: center;">
+			<img src="img/mapping-example%2520-%2520conflating.png">
+			<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><p>	
+		Since the first option provides a correct interpretation of the <code>dct</code> statements, it has been chosen as guideline in the complex mapping. 
+		Blank nodes are used for the mapping, although any naming mechanism could be provided if necessary,
+		leaving the conflating of nodes to the clean-up phase. 		
+		</p>
+	</div>
+	<div class="section" id="direct-mappings"> 
+		<h3><span class="secno">2.3 </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>
+		<div class="note">
+		<p>Some of the terms of the list are still under discussion: <code>dct:replaces</code> and <code>dct:isVersionOf</code>.</p> 
+		</div>
+		<p>
+		</p><div 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 [<cite><a href="#bib-PROV-CONSTRAINTS" rel="biblioentry" class="bibref">PROV-CONSTRAINTS</a></cite>].
+		<p></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>
+	</div>
+	<div class="section" id="prov-refinements"> 
+		<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>
+		</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>
+		 
+		<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 class="section" id="complex-mappings">
+	<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 class="section" id="entity-agent-mappings--who">
+			<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><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>
+			<div class="section" id="dct-creator">
+				<h5><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>
+			</div>
+			<div class="section" id="dct-contributor">
+				<h5><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>
+			</div>
+			<div class="section" id="dct-publisher">
+				<h5><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>		
+				<p></p>
+			</div>
+		</div>
+		<div class="section" id="entity-date-mappings--when">
+			<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>
+			
+			<div class="section" id="dct-created">
+				<h5><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, 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>
+			</div>
+	 
+			<div class="section" id="dct-issued">
+				<h5><span class="secno">2.5.2.2 </span>dct:issued</h5> 
+				<p>
+				</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></p>
+			</div>
+			<div class="section" id="dct-modified">
+				<h5><span class="secno">2.5.2.3 </span>dct:modified</h5> 
+				<p></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></p>
+			</div>
+			<div class="section" id="dct-dateaccepted">
+				<h5><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, 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></p>
+			</div>
+			<div class="section" id="dct-datecopyrighted">
+				<h5><span class="secno">2.5.2.5 </span>dct:dateCopyrighted</h5> 
+				<p></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></p>
+			</div>
+			<div class="section" id="dct-datesubmitted">
+				<h5><span class="secno">2.5.2.6 </span>dct:dateSubmitted</h5> 
+				<p></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></p>
+			</div>
+		</div>
+
+	</div>
+	<div class="section" id="cleanup">
+	<h3><span class="secno">2.6 </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: 
+		 </p><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">
+			<div style="text-align: center;">
+			<a href="#figure_cleanup1">Figure 3</a>. Gathering complementing properties to conflate blank nodes.	
+			</div>
+		</div>
+	 
+		 <p></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>).
+		</p><div id="figure_cleanup2" class="figure" style="text-align: center;">
+			<img src="img/cleanup2.png">
+			<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>
+		<!--<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 class="section" id="list-of-terms-excluded-from-the-mapping">
+		<h3><span class="secno">2.7 </span>List of terms excluded from the mapping</h3>
+		<div class="note">
+		<p>Some of the terms of the list are still under discussion: <code>dct:alternative</code> and <code>dct:references</code>.</p> 
+		</div>
+		<p>
+			</p><table>
+			<caption> <a href="#list_of_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><td>
+			</td></tr>
+			</tbody></table>
+		<p></p>
+	</div>
+	<div class="section" id="mapping-from-prov-to-dc"> 
+		<h3><span class="secno">2.8 </span>Mapping from PROV to DC</h3>
+			<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>
+
+	<div id="acknowledgements" class="appendix section">
+		<!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2>
+	    <p>
+		 We would like to thank Antoine Isaac, Ivan Herman, Timothy Lebo and 
+Satya Sahoo for their feedback; and María Poveda and Idafen Santana 
+Pérez for his help with the HTML generation. 
+	    </p>
+	</div>
+
+<div class="appendix section" id="references"><!--OddPage--><h2><span class="secno">B. </span>References</h2><div class="section" id="normative-references"><h3><span class="secno">B.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-PROV-CONSTRAINTS">[PROV-CONSTRAINTS]</dt><dd>James Cheney; Paolo Missier; Luc Moreau; eds. <a href="http://www.w3.org/TR/2012/CR-prov-constraints-20121211/"><cite>Constraints of the PROV Data Model</cite></a>. 11 December 2012, W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/2012/CR-prov-constraints-20121211/">http://www.w3.org/TR/2012/CR-prov-constraints-20121211/</a>
+</dd><dt id="bib-PROV-N">[PROV-N]</dt><dd>Luc Moreau; Paolo Missier; eds. <a href="http://www.w3.org/TR/2012/CR-prov-n-20121211/"><cite>PROV-N: The Provenance Notation</cite></a>. 11 December 2012, W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/2012/CR-prov-n-20121211/">http://www.w3.org/TR/2012/CR-prov-n-20121211/</a>
+</dd><dt id="bib-PROV-O">[PROV-O]</dt><dd>Timothy Lebo; Satya Sahoo; Deborah McGuinness; eds. <a href="http://www.w3.org/TR/2012/CR-prov-o-20121211/"><cite>PROV-O: The PROV Ontology</cite></a>. 11 December 2012, W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/2012/CR-prov-o-20121211/">http://www.w3.org/TR/2012/CR-prov-o-20121211/</a>
+</dd></dl></div><div class="section" id="informative-references"><h3><span class="secno">B.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-DCMI">[DCMI]</dt><dd><a href="http://dublincore.org/"><cite>Dublin Core Metadata Initiative</cite></a>. URL: <a href="http://dublincore.org/">http://dublincore.org/</a>
+</dd><dt id="bib-DCTERMS">[DCTERMS]</dt><dd><a href="http://dublincore.org/documents/dcmi-terms/"><cite>Dublin Core Terms Vocabulary</cite></a>. 8 December 2010. URL: <a href="http://dublincore.org/documents/dcmi-terms/">http://dublincore.org/documents/dcmi-terms/</a>
+</dd><dt id="bib-PROV-AQ">[PROV-AQ]</dt><dd>Graham Klyne; Paul Groth; eds. <a href="http://www.w3.org/TR/2012/WD-prov-aq-20120619/"><cite>Provenance Access and Query</cite></a>. 19 June 2012, Working Draft. URL: <a href="http://www.w3.org/TR/2012/WD-prov-aq-20120619/">http://www.w3.org/TR/2012/WD-prov-aq-20120619/</a>
+</dd><dt id="bib-PROV-DM">[PROV-DM]</dt><dd>Luc Moreau; Paolo Missier; eds. <a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/"><cite>PROV-DM: The PROV Data Model</cite></a>. 11 December 2012, W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/2012/CR-prov-dm-20121211/">http://www.w3.org/TR/2012/CR-prov-dm-20121211/</a>
+</dd><dt id="bib-PROV-OVERVIEW">[PROV-OVERVIEW]</dt><dd>Paul Groth; Luc Moreau; eds. <a href="http://www.w3.org/TR/2012/WD-prov-overview-20121211/"><cite>PROV-OVERVIEW: An Overview of the PROV Family of Documents</cite></a>. 11 December 2012, Working Draft. URL: <a href="http://www.w3.org/TR/2012/WD-prov-overview-20121211/">http://www.w3.org/TR/2012/WD-prov-overview-20121211/</a>
+</dd><dt id="bib-PROV-PRIMER">[PROV-PRIMER]</dt><dd>Yolanda Gil; Simon Miles; eds. <a href="http://www.w3.org/TR/2012/WD-prov-primer-20121211/"><cite>PROV Model Primer</cite></a>. 11 December 2012, Working Draft. URL: <a href="http://www.w3.org/TR/2012/WD-prov-primer-20121211/">http://www.w3.org/TR/2012/WD-prov-primer-20121211/</a>
+</dd><dt id="bib-PROV-XML">[PROV-XML]</dt><dd>Hook Hua; Curt Tilmes; Stephan Zednik; eds. <a href="http://www.w3.org/TR/2012/WD-prov-xml-20121211/"><cite>PROV-XML: The PROV XML Schema</cite></a>. 11 December 2012, Working Draft. URL: <a href="http://www.w3.org/TR/2012/WD-prov-xml-20121211/">http://www.w3.org/TR/2012/WD-prov-xml-20121211/</a>
+</dd></dl></div></div></body></html>
\ No newline at end of file