Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new class dcat:DataService, as a subclass of dcat:Resource #73

Open
NatasaSofou opened this issue Sep 12, 2019 · 4 comments

Comments

@NatasaSofou
Copy link
Contributor

commented Sep 12, 2019

Add new class dcat:DataService, subclass of dcat:Resource, as a collection of operations that provides access to one or more datasets or data processing functions, with properties:

  • dcat:servesDataset : A collection of data that this data service can distribute.
  • dcat:endpointURL: the root location or primary endpoint of the service (an IRI
  • dcat:endpointDescription: A description of the services available via the end-points, including their operations, parameters etc
  • dct:license: A legal document under which the service is made available.
  • dct:accessRights: Access Rights MAY include information regarding access or restrictions based on privacy, security, or other policies.
@andrea-perego

This comment has been minimized.

Copy link

commented Sep 12, 2019

As I said in #72 (comment) , GeoDCAT-AP includes the notion of service. So, the question is whether these classes/properties should be added in DCAT-AP itself, or they should rather be in GeoDCAT-AP.

Related GeoDCAT-AP issue: SEMICeu/GeoDCAT-AP#10

@oystein-asnes

This comment has been minimized.

Copy link

commented Sep 19, 2019

+1 from Norway to include both dcat:DataService and dcat:Resource as new classes. FYI: The question raised on formats for dcat:DataService during the august webinar is now raised here: w3c/dxwg#1055

@jakubklimek

This comment has been minimized.

Copy link

commented Sep 19, 2019

+1 from Czechia for inclusion in DCAT-AP. The support for services is broader than just geoservices.

I think GeoDCAT-AP (1.0.1) representation of services will need to be changed according to the development in DCAT 2 and, subsequently, DCAT-AP.

GeoDCAT-AP originally had to cope with the missing support for services in DCAT-AP, and IMHO not in a nice way. When there is proper support for services in DCAT-AP, a GeoDCAT-AP update will be able to adopt and, if necessary specialize this generic approach.

@NatasaSofou

This comment has been minimized.

Copy link
Contributor Author

commented Sep 27, 2019

Proposed resolution: add dcat:DataService as optional class to DCAT-AP with properties:

  • dct:title (mandatory)
  • dcat:endpointURL (mandatory)
  • dcat:servesDataset (recommended)
  • dcat:endpointDescription (recommended)
  • dct:descrpiption (optional)
  • dct:license (optional)
  • dct:accessRights (optiona)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.