Adds support for dcat:accessService in dcat:Distribution

[seitenbau-govdata]

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

• dcat:accessService: https://www.w3.org/TR/vocab-dcat-2/#Property:distribution_access_service

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]

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]

@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.