GeoDCAT-AP - How to encode resource locator?

Portal Admin

Published on: 21/04/2015 Discussion Archived

Issue: This issue on resource locator was raised during the 2nd WG meeting of 15 April 2015: the resource locator is encoded in RDF using foaf:homepage (consistent considering services to be of type dcat:Catalog). However, during the 2nd GeoDCAT-AP WG call of 15 April 2014, it was discussed that this could also be a dcat:landingPage, dcat:accessURL, or dcat:DownloadURL, depending on the type of resource locator (in IS019139 this is indicated by the gmd:CI_OnLineFunctionCode, which can be of values 'download', 'search', 'order', 'offlineAccess', and 'information').

Proposed resolution by Andrea Perego:

ISO 19115 offers however the ability to specify the “type” of resource locator by using a specific code list (CI_OnlineFunctionCode), described in the following table:

ISO 19115 – CI_OnlineFunctionCode	Description
download	online instructions for transferring data from one storage device or system to another
information	online information about the resource
offlineAccess	online instructions for requesting the resource from the provider
order	online order process for obtaining the resource
search	online search interface for seeking out information about the resource

Based on this, the proposed mappings of element “resource locator” are the following:

foaf:homepage for services;
for data sets and data set series, the mapping will vary depending on the function code (when available), based on the following table.

ISO 19115 – CI_OnlineFunctionCode	Property	Domain	Range
download	dcat:accessURL	dcat:Distribution	rdfs:Resource
information	foaf:page	dcat:Dataset	foaf:Document
offlineAccess	dcat:accessURL	dcat:Distribution	rdfs:Resource
order	dcat:accessURL	dcat:Distribution	rdfs:Resource
search	foaf:page	dcat:Dataset	foaf:Document
-	dcat:landingPage	dcat:Dataset	foaf:Document

The final decision needs however to be aligned with DCAT-AP 2.0, where similar issues are under discussion.

Example
`# Resource metadata in GeoDCAT-AP ## Resource locator for datasets and series [] a dcat:Dataset; foaf:page <http://forest.jrc.ec.europa.eu/forestmap-download> ## Resource locator for services [] a dcat:Catalog; foaf:homepage <http://geohub.jrc.ec.europa.eu/efas_cc?service=WMS&request=GetCapabilities> .`
<!— Resource metadata in ISO19139 --> <gmd:MD_Metadata … ... <gmd:transferOptions> <gmd:MD_DigitalTransferOptions> <gmd:onLine> <gmd:CI_OnlineResource> <gmd:linkage> <gmd:URL> http://forest.jrc.ec.europa.eu/forestmap-download</gmd:URL> </gmd:linkage> <gmd:name> <gco:CharacterString> … </gco:CharacterString> </gmd:name> <gmd:description> <gco:CharacterString> … </gco:CharacterString> </gmd:description> <gmd:function> <CI_OnLineFunctionCode codeListValue="information" codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/ML_gmxCodelists.xml#CI_OnLineFunctionCode" xmlns="http://www.isotc211.org/2005/gmd"/> </gmd:function> </gmd:CI_OnlineResource> </gmd:onLine> </gmd:MD_DigitalTransferOptions> </gmd:transferOptions> ... </gmd:MD_Metadata>

Example

# Resource metadata in GeoDCAT-AP


## Resource locator for datasets and series


[]  a dcat:Dataset;

    foaf:page <http://forest.jrc.ec.europa.eu/forestmap-download>


## Resource locator for services


[]  a dcat:Catalog; foaf:homepage <http://geohub.jrc.ec.europa.eu/efas_cc?service=WMS&request=GetCapabilities> .

<!— Resource metadata in ISO19139 -->


<gmd:MD_Metadata …

...

<gmd:transferOptions>

    <gmd:MD_DigitalTransferOptions>

     <gmd:onLine>

     <gmd:CI_OnlineResource>

          <gmd:linkage>

               <gmd:URL> http://forest.jrc.ec.europa.eu/forestmap-download</gmd:URL>

          </gmd:linkage>

          <gmd:name>

               <gco:CharacterString> … </gco:CharacterString>

          </gmd:name>

          <gmd:description>

               <gco:CharacterString> … </gco:CharacterString>

          </gmd:description>

          <gmd:function>

               <CI_OnLineFunctionCode codeListValue="information" codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/Codelist/ML_gmxCodelists.xml#CI_OnLineFunctionCode" xmlns="http://www.isotc211.org/2005/gmd"/>

          </gmd:function>

     </gmd:CI_OnlineResource>

     </gmd:onLine>

     </gmd:MD_DigitalTransferOptions>

</gmd:transferOptions>

...

</gmd:MD_Metadata>

Component

Code

Comments

stijngoedertier (not verified) Fri, 15/05/2015 - 09:24

During the 3rd WG meeting of 29 April 2015, it was decided by vote that the proposal to differentiate the type of Resource Locator based on the gmd:OnLineFunctionCode is accepted:

The proposed syntax binding for the ‘download’ function code using dcat:accessURL is accepted.
The proposed syntax binding for the ‘missing’ value for function code using dcat:landingPage is accepted.
The proposed syntax binding for the function code ‘order’ using dcat:accessURL is accepted.
The proposed syntax binding for the function code ‘offlineAccess’ to use dcat:landingPage is accepted.
The proposed syntax binding for the function code ‘search’ to use foaf:page is accepted.

ISO 19115 – CI_OnlineFunctionCode	Property	Domain	Range
download	dcat:accessURL	dcat:Distribution	rdfs:Resource
information	foaf:page	dcat:Dataset	foaf:Document
offlineAccess	dcat:landingPage	dcat:Dataset	rdfs:Resource
order	dcat:accessURL	dcat:Distribution	rdfs:Resource
search	foaf:page	dcat:Dataset	foaf:Document
-	dcat:landingPage	dcat:Dataset	foaf:Document

Paul VAN GENUCHTEN Thu, 04/06/2015 - 11:19

hi, i noticed this thread is closed, but I's still want to comment...

For me, when looking at the dcat specification, a dcat:downloadurl should be used to describe a link to a dataset file. If that is the case, no dcat:accesUrl would need to be provided.

My main question would be, why did you decide to make accesUrl mandatory?

In my opinion 5 cases can exist:

- a landingpage link (duplicated in accessURL, as suggested here http://www.w3.org/ns/dcat#accessURL)

- a landingpage link + a service (api) link (service link in accessURL)

- a landingpage link + a download link (landingpage duplicated in accesURL and download link in downloadUrl)

- only a service link (in accessURL)

- only a download link (in downloadUrl, no acessurl)

Andrea PEREGO Thu, 04/06/2015 - 14:32

Hi, Paul.

Before replying to your specific questions, I would like to clarify one point.

In its current version, GeoDCAT-AP mainly focusses on defining harmonised alignments thanks to which you can transform IINSPIRE / ISO 19115 metadata records into a DCAT-AP compliant format. Which means that the result of the mapping must be based on information that is available in the source records.

On the other hand, GeoDCAT-AP does not currently include best practices on how you should "write" metadata records, although this is something that might be included in future versions, is the WG decides to do so.

Coming now to your questions:

For me, when looking at the dcat specification, a dcat:downloadurl should be used to describe a link to a dataset file. If that is the case, no dcat:accesUrl would need to be provided.

My main question would be, why did you decide to make accesUrl mandatory?

Well, the DCAT Rec says that dcat:downloadURL "is a specific form" dcat:accessURL, so there's nothing that prevents you from using it.

The reason of recommending the use of dcat:accessURL is that in INSPIRE / ISO metadata there's nothing that you can use to know whether it's a URL to a download page or to the actual file of the distribution.

In my opinion 5 cases can exist:

- a landingpage link (duplicated in accessURL, as suggested here http://www.w3.org/ns/dcat#accessURL)

- a landingpage link + a service (api) link (service link in accessURL)

- a landingpage link + a download link (landingpage duplicated in accesURL and download link in downloadUrl)

- only a service link (in accessURL)

- only a download link (in downloadUrl, no acessurl)

Again, as said above, there's nothing in the source metadata denoting whether a resource locator is a service, remote file, etc.

Andrea

Paul VAN GENUCHTEN Mon, 15/06/2015 - 23:12

Hi Andrea, related to your statement:

Quite some organisations have always considered this a limitation of iso19139 and have added additional rules to their profiles that require the use of gmd:protocol in gmd:CI_OnlineResource, which value should be one of a codelist. The value can then be used to either map the online resource as access/download and/or landingpage. The Dutch and Swedish national profiles for example have such a codelist in place. It might be a recommendation to miwp-8 to consider such a protocol requirement. A cluster of catalogues started the following codelist to improve this facet of interoperability: https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTabl…

GeoDCAT Application Profile for data portals in Europe

GeoDCAT-AP - How to encode resource locator?

Component

Category

Comments