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

Dear Ine,

Thank you very much for providing feedback on the DCAT revision.

We will analyse the points your raised in detail and get back to you as
soon as possible.

Kind regards,

Alejandra


On Tue, 15 Jan 2019 at 10:42, Ine de Visser <i.devisser@geonovum.nl> wrote:

> 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:
>
>
>
> dcat:downloadURL
>
> dcat:accessURL
>
> dcat:landingPage
>
> dcat:endpointDescription
>
> dcat:endpointURL
>
>
>
>
>
> 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:
>
>
> http://services.rce.geovoorziening.nl/rce/wms?&request=GetCapabilities&service=WMS
>
>
> http://services.rce.geovoorziening.nl/www/download/data/Rijksmonumenten_nl.xml
>
>
>
> Examples of end point:
>
> http:*//services.rce.geovoorziening.nl/rce/ows?SERVICE=WMS*
> &VERSION=1.3.0&REQUEST=GetMap&FORMAT=image/png&LAYERS=rce:ArcheologicalMonuments&CRS=EPSG:28992
> &WIDTH=1650&HEIGHT=830&BBOX=-16020,396426,161387,485667
> <http://services.rce.geovoorziening.nl/rce/ows?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image/png&LAYERS=rce:ArcheologicalMonuments&CRS=EPSG:28992&WIDTH=1650&HEIGHT=830&BBOX=-16020,396426,161387,485667>
>
> http:*//services.rce.geovoorziening.nl/rce/wfs?request=GetFeature*
> &service=WFS&version=2.0.0&typeName=NationalListedMonuments
> &outputFormat=json&Count=50
> <http://services.rce.geovoorziening.nl/rce/wfs?request=GetFeature&service=WFS&version=2.0.0&typeName=NationalListedMonuments&outputFormat=json&Count=50>
>
> 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
>
>
>
> *_________________________________________*
>
> *Geonovum*
>
>
>
>
> *Ine de Visser **geo-standaarden*
>
> *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
>
> *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
>
>
>
> [image: cid:image001.jpg@01D4ABEC.39C3ECC0]
>
>
>
> *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* <info@geonovum.nl>
>
>
>