W3C home > Mailing lists > Public > public-dxwg-comments@w3.org > January 2019

FW: comments on Data Catalog Vocabulary (DCAT) - Working Draft 16 October 2018

From: Ine de Visser <i.devisser@geonovum.nl>
Date: Mon, 14 Jan 2019 08:34:57 +0000
To: "public-dxwg-comments@w3.org" <public-dxwg-comments@w3.org>
Message-ID: <AM0PR05MB56984ECA21731F7571AEC1339A800@AM0PR05MB5698.eurprd05.prod.outlook.com>
Dear DXWG working group,

It seems I gave not in time permission to publish this to the group.
Second try..

Best regards Ine

Van: Ine de Visser
Verzonden: donderdag 20 december 2018 16:21
Aan: 'public-dxwg-comments@w3.org' <public-dxwg-comments@w3.org>
Onderwerp: comments on Data Catalog Vocabulary (DCAT) - Working Draft 16 October 2018

Dear DXWG working group,

It's good to see that an extention is made to provide service metadata for the organisations where this kind of metadata is managed. In the Netherlands, the service metadata (based on ISO 19119) is never fully accepted and implemented. It is only, in general terms, used where it is mandatory for INSPIRE.
If the service is described with metadata itself, then an unambiguously relationship between dataset description and service description is important. The chosen solution, with dcat:AccessService seems to fulfil this. This solution gives also the opportunity to relate more services to one dataset via the dcat:Distribution.

In our case, a good unambiguously use of properties in the dataset metadata linking to the service is important. If unambiguously use of properties is not he case, it's not clear what a user can expect and therefore not to use.

There I see some issues, with the examples/definitions of the properties:


In INSPIRE is in the commission regulation<https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R1312&from=EN> accesspoint defined as follows:

""access point" means an internet address containing a detailed description of a spatial data service, including a list of end points to allow its execution,"

An accesspoint can be an WSDL, getCapabilities request or XML etc. so a description of the service that is more or less part of the service itself and contains descriptions of the service operations and parameters.

dcat:accessURL seems to match the access point

But why the recommendation/requirement on usage "If the distribution(s) are accessible only through a landing page (i.e. direct download URLs are not known), then the landing page link SHOULD be duplicated as dcat:accessURL on a distribution" Then dcat:accessURL becomes useless, it's not machine readable anymore.

Can the usage of dcat:accessURL be narrowed to machine readable descriptions containing detailed description of a data service, including a list of end points to allow its execution? And use the dcat:landingPage for human access?

dcat:endpointDescription also seems to match the accesspoint. Can the same property (dcat:accessURL) used for the same thing at dcat:DataService and replace dcat:EndpointDescription?

In INSPIRE is in the commission regulation<https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32014R1312&from=EN> end point defined as follows:

""end point" means the internet address used to directly call an operation provided by a spatial data service, "

An endpoint can contain a link to a directly downloadable file such as a CSV or GML, but can also contain a service request that downloads a dataset in a certain format. An endpoint can also result in an image of a map.

dcat:downloadURL seems to match the end point, it can also contain a base url with an request resulting in downloading an image of a map

dcat:endpointURL seems not conformant to end point. In the examples dcat:endpointURL http://sdi.eea.europa.eu/catalogue/srv/eng/csw is used. This URL can't be used without operations and parameters and is mostly seen as dead link (although this is not the case), due to unfamiliarity with the service type.  Can the dcat:endpointURL be made more usefull and in line with INSPIRE definitions, by requiring that the endpoint should be an  URL  presented in such a way that it always immediately gives a result, without being separately questioned? Or other way around, be more precise in specifying dcat:endpointURL whit a good definition what exactly is meant with endpoint, something what I should call the base URL. Perhaps also rename the property to dcat:baseURL. With the information provided in endpointDescription (dact:baseURLDescription) it's possible to use this base URL. I prefer this second option , I think it's more clear.

Examples of access point:

Examples of end point:
Issue 411
The definition of the phrase "informationally equivalent" works only for us if the visual representation of a dataset and the downloaded objects of this same dataset is seen as "informationally equivalent".

Other issue is about dct:identifier. In the ISO world, we have a metadata identifier  and an identifier of the resource (dataset). The metadata identifier is useful in automatic harvesting of catalogs. Can dct:identifier be added as member of the dcat:CatalogRecord to support this?

Hope my input is clear, if further information is needed, feel free to contact me.

Best regards Ine


Ine de Visser
a: Barchman Wuytierslaan 10, 3818 LH Amersfoort
p: Postbus 508, 3800 AM Amersfoort
m: + 31 (0)6 13 54 50 52
e: i.devisser@geonovum.nl<mailto:i.devisser@geonovum.nl>
i: www.geonovum.nl<https://mail.geonovum.nl/exchweb/bin/redir.asp?URL=https://mail.geonovum.nl/exchweb/bin/redir.asp?URL=http://mail.geonovum.nl/exchweb/bin/redir.asp?URL=http://www.geonovum.nl/>

Aanwezig: maandag t/m donderdag


Wanneer u een vraag stelt aan een helpdesk over een standaard bij Geonovum in beheer, vragen we om u persoonsgegevens te verstrekken. Het betreft uw e-mail adres en telefoonnummer. Deze gegevens worden gebruikt om de dienst uit te kunnen voeren. De gegevens worden opgeslagen op beveiligde servers. Wij zullen deze gegevens niet combineren met andere persoonlijke gegevens waarover wij beschikken. Wij delen de gegevens niet met derden. U heeft het recht o uw gegevens in te zien, ons te vragen deze gegevens wijzigen dan wel te verwijderen. Neem hiervoor contact met ons op via info@geonovum.nl<mailto:info@geonovum.nl>

(image/jpeg attachment: image002.jpg)

Received on Tuesday, 15 January 2019 10:42:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 15 January 2019 10:42:07 UTC