Dear users, creation of new accounts is temporarily disabled. Please check again later. We apologise for any inconvenience caused.

GeoDCAT-AP - How to encode resource locator?

Published on: 21/04/2015
Discussion

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').

(related issue: 142437  - GeoDCAT-AP - how to encode services in GeoDCAT-AP Core)

(related issue: 138935 - IM2 - How to describe datasets available via services with specific access methods)

 

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>

 

Component

Code

Category

feature

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

 

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)

 

 

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

Mon, 15/06/2015 - 23:12

Hi Andrea, related to your statement:

 

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. 

 

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…