Merge branch 'gh-pages' into dcat-issue127-simon

CONTRIBUTING.md

@@ -0,0 +1,23 @@
+### W3C Legal
+Contributions to the DXWG Working Group repositories are intended to become part of Recommendation-track documents governed by the
+[W3C Patent Policy](http://www.w3.org/Consortium/Patent-Policy-20040205/) and
+[Document License](http://www.w3.org/Consortium/Legal/copyright-documents). To make substantive contributions to specifications, you must either participate
+in the relevant W3C Working Group or make a non-member patent licensing commitment.
+
+If you are not the sole contributor to a contribution (pull request), please identify all
+contributors in the pull request comment.
+
+To add a contributor (other than yourself, that's automatic), mark them one per line as follows:
+
+```
++@github_username
+```
+
+If you added a contributor by mistake, you can remove them in a comment with:
+
+```
+-@github_username
+```
+
+If you are making a pull request on behalf of someone else but you had no part in designing the
+feature, you can remove yourself with the above syntax.

README.md

@@ -2,6 +2,7 @@
 
 - [DXWG's home page](https://www.w3.org/2017/dxwg/)
 - [Charter](https://www.w3.org/2017/dxwg/charter)
+- [Contribution Guidelines](CONTRIBUTING.md) cover the W3C legal aspects of contributing to this Github repository 
 
 ### Working Documents
 

dcat/index.html

@@ -836,7 +836,7 @@ <h4>Property: endpoint address</h4>
 <section id="Property:dataservice_endpointdescription">
 <h4>Property: endpoint description</h4>
 <table class="definition">
-  <thead><tr><th>RDF Property:</th><th><a href="http://purl.org/dc/terms/conformsTo">dct:endpointDescription</a></th></tr></thead>
+  <thead><tr><th>RDF Property:</th><th><a href="http://www.w3.org/ns/dcat#endpointDescription">dcat:endpointDescription</a></th></tr></thead>
   <tbody>
     <tr><td class="prop">Definition:</td><td>Link to a description of the service end-point, for example an OpenAPI (Swagger) description, an OGC getCapabilities response, a SD Service, an OpenSearch or WSDL document.  </td></tr>
 		<tr><td class="prop">Domain:</td><td><a href="http://www.w3.org/ns/dcat#DataService">dcat:DataService</a> </td></tr>

ucr/index.html

@@ -800,7 +800,7 @@ <h2>Requirements for data citation [ID10]</h2>
       </ul>
         </p>
         <p class="existing_approaches">
-          <p><a rel="nofollow" class="external text" href="https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/datacite-to-dcat-ap/">A study</a> has been carried out at the <a rel="nofollow" class="external text" href="https://ec.europa.eu/jrc/">European Commission's Joint Research Centre (JRC)</a>, in order to create mappings between [[DataCite]] (the current <i>de facto</i> standard for data citation) and [[DCAT-AP]]. </p>
+          <p><a rel="nofollow" class="external text" href="https://github.com/ec-jrc/datacite-to-dcat-ap/">A study</a> has been carried out at the <a rel="nofollow" class="external text" href="https://ec.europa.eu/jrc/">European Commission's Joint Research Centre (JRC)</a>, in order to create mappings between [[DataCite]] (the current <i>de facto</i> standard for data citation) and [[DCAT-AP]]. </p>
           <p>The results show that [[DCAT-AP]] covers most of the required [[DataCite]] metadata elements, but some of them are missing. In particular:</p>
           <ul>
         <li> Mandatory elements:<ul><li> Dataset creator (but [[GeoDCAT-AP]] supports it)</li></ul></li>
@@ -813,7 +813,7 @@ <h2>Requirements for data citation [ID10]</h2>
           <ul>
         <li><a rel="nofollow" class="external text" href="https://www.w3.org/2016/11/sdsvoc/SDSVoc16_paper_27#data-citation"><i>Using DCAT-AP for research data</i>.</a> Smart Descriptions &amp; Smarter Vocabularies (SDSVoc). Amsterdam, 30 Nov - 1 Dec 2016.</li>
         <li>
-          <a rel="nofollow" class="external text" href="https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/datacite-to-dcat-ap/">
+          <a rel="nofollow" class="external text" href="https://github.com/ec-jrc/datacite-to-dcat-ap/">
             <i>DataCite to DCAT-AP Mapping</i>
           </a>
         </li>
@@ -1300,6 +1300,7 @@ <h2>Modeling service-based data access [ID18]</h2>
       -->
       </p>
     </section>
+
     <section id="ID19" class="usecase">
       <h2>Guidance on the use of qualified forms [ID19]</h2>
       <p class="contributor"><a href="/2017/dxwg/wiki/User:Aperego" title="User:Aperego">Andrea Perego</a> - <a rel="nofollow" class="external text" href="https://ec.europa.eu/jrc/">European Commission, Joint Research Centre (JRC)</a></p>
@@ -1319,8 +1320,35 @@ <h2>Guidance on the use of qualified forms [ID19]</h2>
       <div class="visible">
         <p class="description">
           <p>In most cases, the relationships between datasets and related resources (e.g., author, publisher, contact point, publications / documentation, input data, model(s) / software used to create the dataset) can be specified with simple, binary properties available from widely used vocabularies - as [[DCTerms]] and [[VOCAB-DCAT]].</p>
-          <p>However, there may be the need of providing additional information concerning, e.g., the temporal context of a relationship, which requires the use of a more sophisticated representation, similar to the "qualified" forms used in [[PROV-O]]. </p>
-          <p>Besides [[PROV-O]], vocabularies as [[VOCAB-DQV]] and [[VOCAB-DUV]] can be used for this purpose. However, there is the need of providing guidance on how to use them consistently, since the lack of modeling patterns results in the difficulty of aggregating this information across metadata records and catalogs.</p>
+          <p>As an example, <code>dcterms:source</code> can be used to specify a relationship between a dataset (<code>output:Dataset</code>), and the dataset it was derived from (<code>input:Dataset</code>):</p>
+          <pre>
+output:Dataset a dcat:Dataset ;
+  dcterms:source input:Dataset .
+
+input:Dataset a dcat:Dataset .
+          </pre>
+          <p>However, there may be the need of providing additional information concerning, e.g., the temporal context of a relationship, which requires the use of a more sophisticated representation, similar to the "qualified" forms used in [[PROV-O]]. 
+          For instance, the previous example may be further detailed by saying that the output dataset is an anonymized version of the input dataset, and that the anonymization process started at time <var>t</var> and ended at time <var>t&prime;</var>. By using [[PROV-O]], this information can be expressed as follows:</p>
+          <pre>
+output:Dataset a dcat:Dataset ;
+  prov:qualifiedDerivation [
+    a prov:Derivation ;
+    prov:entity input:Dataset ; 
+    prov:hadActivity   :data_anonymization 
+] .
+
+input:Dataset a dcat:Dataset .
+
+# The process of anonymizing the data (load the data, process it, and generate the anonymized version)
+
+:data_anonymization
+  a prov:Activity ;
+# When the process started  
+  prov:startedAtTime  "2018-01-23T01:52:02Z"^^xsd:dateTime;
+# When the process ended  
+  prov:endedAtTime "2018-01-23T02:00:02Z"^^xsd:dateTime .
+          </pre>
+          <p>Besides [[PROV-O]], vocabularies as [[VOCAB-DQV]] and [[VOCAB-DUV]] can be used to specify relationships between datasets and related resources. However, there is the need of providing guidance on how to use them consistently, since the lack of modeling patterns results in the difficulty of aggregating this information across metadata records and catalogs.</p>
           <p>Moreover, it is important to define mappings between qualified and non-qualified forms (e.g., along the lines of what done in [[PROV-DC]]), not only to make it clear their semantic relationships (e.g., <code>dcterms:source</code> is the non-qualified form of <code>prov:qualifiedDerivation</code>), but also to enable metadata sharing and re-use across catalogs that may support only one of the two forms (qualified / non-qualified).</p>
         </p>
         <p class="existing_approaches">
@@ -1347,6 +1375,7 @@ <h2>Guidance on the use of qualified forms [ID19]</h2>
       -->
       </p>
     </section>
+
     <section id="ID20" class="usecase">
       <h2>Modelling resources different from datasets [ID20]</h2>
       <p class="contributor"><a href="/2017/dxwg/wiki/User:Aperego" title="User:Aperego">Andrea Perego</a> - <a rel="nofollow" class="external text" href="https://ec.europa.eu/jrc/">European Commission, Joint Research Centre (JRC)</a></p>
@@ -1378,14 +1407,14 @@ <h2>Modelling resources different from datasets [ID20]</h2>
         <li> Services are modeled as <code>dcat:Catalog</code>, in case of a catalog service, and with <code>dctype:Service</code> [[DCTerms]] in all the other cases.</li>
         <li> The type of service (discovery, download, view, etc.) is modeled by using <code>dcterms:type</code>.</li>
       </ul>
-          <p>A similar approach has been adopted in <a rel="nofollow" class="external text" href="https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/datacite-to-dcat-ap/">the study</a> carried out by the <a rel="nofollow" class="external text" href="https://ec.europa.eu/jrc/">European Commission's Joint Research Centre (JRC)</a> to map [[DataCite]] to [[DCAT-AP]]. </p>
+          <p>A similar approach has been adopted in <a rel="nofollow" class="external text" href="https://github.com/ec-jrc/datacite-to-dcat-ap/">the study</a> carried out by the <a rel="nofollow" class="external text" href="https://ec.europa.eu/jrc/">European Commission's Joint Research Centre (JRC)</a> to map [[DataCite]] to [[DCAT-AP]]. </p>
           <p>The resource types supported in [[DataCite]] are 14. Most of them fall into the generic [[VOCAB-DCAT]] definition of "dataset", so they are modeled with <code>dcat:Dataset</code>. Moreover, the DCMI Type Vocabulary [[DCTerms]] is used to model both the dataset "type", and those resource types that cannot be modeled as datasets (events, physical objects, services).</p>
         </p>
         <p class="links">
           <ul>
         <li> [[GeoDCAT-AP]]</li>
         <li>
-          <a rel="nofollow" class="external text" href="https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/datacite-to-dcat-ap/">
+          <a rel="nofollow" class="external text" href="https://github.com/ec-jrc/datacite-to-dcat-ap/">
             <i>DataCite to DCAT-AP Mapping</i>
           </a>
         </li>
@@ -1846,7 +1875,7 @@ <h2>Standard APIs for metadata profile negotiation [ID30]</h2>
           <p>HTTP content negotiation may be the most viable solution, since HTTP is the protocol Web-based catalog services makes use of. However, although the HTTP protocol would allow metadata to be served in different formats, it does not support the ability to negotiate the metadata profile.</p>
         </p>
         <p class="existing_approaches">
-          <p>The <a rel="nofollow" class="external text" href="https://webgate.ec.europa.eu/CITnet/stash/projects/ODCKAN/repos/iso-19139-to-dcat-ap/browse/api">GeoDCAT-AP API</a> was designed to enable [[CSW]] endpoints to serve [[ISO-19115-1]] metadata based on the [[GeoDCAT-AP]] profile, by using the standard [[CSW]] interface - i.e., parameters <code>outputSchema</code> (for the metadata profile) and <code>outputFormat</code> (for the metadata format).</p>
+          <p>The <a rel="nofollow" class="external text" href="https://github.com/SEMICeu/iso-19139-to-dcat-ap/tree/master/api">GeoDCAT-AP API</a> was designed to enable [[CSW]] endpoints to serve [[ISO-19115-1]] metadata based on the [[GeoDCAT-AP]] profile, by using the standard [[CSW]] interface - i.e., parameters <code>outputSchema</code> (for the metadata profile) and <code>outputFormat</code> (for the metadata format).</p>
           <p>HTTP content negotiation is supported to determine the returned metadata format, without the need of using parameter <code>outputSchema</code>. The ability to negotiate also the profile would enable a client to query a [[CSW]] endpoint without the need of knowing the supported harvesting protocol.</p>
           <p>Besides the resulting RDF serialisation of the source [[ISO-19115-1]] records, the API returns a set of HTTP <code>Link</code> headers, using the following <a rel="nofollow" class="external text" href="https://www.iana.org/assignments/link-relations/">relationship types</a>:</p>
           <ul>