search

ckan / ckanext-dcat

CKAN ♥ DCAT
164 stars 142 forks source link

Adds support for dcat:accessService in dcat:Distribution #235

Closed seitenbau-govdata closed 1 year ago

seitenbau-govdata commented 1 year ago

The pull request adds support for DCAT.accessService in DCAT.Distribution.

The solution provides a simple way to store the information about the dataservices as JSON.

Following properties are supported: Field Cardinality
DCT.title [1]
DCT.description [0..1]
DCT.license [0..1]
DCT.accessRights [0..1]
DCATAP.availability [0..1]
DCAT.endpointDescription [0..1]
DCAT.endpointURL [1..*]
DCAT.servesDataset [*]
amercader commented 1 year ago

This looks good @seitenbau-govdata , my only comment is about entity mapping between CKAN and DCAT. As we are mapping DCAT Distributions to CKAN resources it makes sense to store Access Services as subfields of resources, but I could also see the argument for creating those as actual resources. I guess that I'm not familiar with the actual use case for Access Services. Is that meant for e.g. APIs that give access to the data of a particular distribution? In any case it makes sense to keep the current hierarchy of CKAN datasets > CKAN resources / dcat:Dataset > dcat:Distribution, so storing access services as you did makes sense.

Another question, is dcat:servesDataset always meant to point to the URI of the current CKAN dataset? should we enforce that? or is better to keep it flexible?

seitenbau-govdata commented 1 year ago

@amercader

Is that meant for e.g. APIs that give access to the data of a particular distribution?

Yes. I think that's the main use case.

Another question, is dcat:servesDataset always meant to point to the URI of the current CKAN dataset? should we enforce that? or is better to keep it flexible?

As it can be a list, it is not restricted to pointing only to the current CKAN dataset. The CKAN dataset can also be used only to publish an API which serves multiple datasets.