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

[NatasaSofou]

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]

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]

+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]

+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]

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)

[matthiaspalmer]

I think it is unclear what the range of dct:accessRights is supposed to be. The specification document is currently rather vague. The DCAT2 has a section discussing license and rights outlining three options where the use of dct:accessRights seems to be very much along the lines of how it is used on dcat:Dataset. I.e. with the three options public/non-public/restricted that outlines if the dataset can be accessed by anyone or it requires specific authorization.

Hence, I would assume the same is the case for dct:accessRights on the dcat:DatasetService. But since the text in the specification is not formulated the same way (does not refer to the same controlled vocabulary) the reader is left wondering.

Unless there is another intention I suggest to specify that the same vocabulary should be used.

[bertvannuffelen]

@matthiaspalmer there will be future discussions on the usage of accessRights and licences. I close this issue as your concern will be tackled there.