SEMICeu / DCAT-AP

This is the issue tracker for the maintenance of DCAT-AP
https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
72 stars 24 forks source link

HVD C5. API representation #255

Closed bertvannuffelen closed 6 months ago

bertvannuffelen commented 1 year ago

In the HVD an API is defined as a set of functions, procedures, definitions and protocols for machine-to-machine communication and the seamless exchange of data .

The reporting requirement 5.3.c requires persistent links for APIs.

In the general requirements API should be accompanied with documentation on terms of use and quality of service.

proposal This corresponds to the definition of DataService in DCAT-AP.

DCAT-AP recommends persistency of the DataService URI, but does not impose any requirements on the Endpoint URL.
It is recommended to perform efforts to maintain persistency for both.

The proposal is to consider for terms of use the licence information associated with the DataService.

For the quality of service documentation information can be added to dcat:LandingPage.

jakubklimek commented 1 year ago

Agree with API ~ DataService.

However, shouldn't we try to make the "quality of service" documentation, i.e. quality of service criteria on its performance, capacity and availability machine readable, e.g. using the Data Quality Vocabulary or maybe something more aligned with the HVD document?

jakubklimek commented 1 year ago

Just a note, in the call, we agreed that it is OK if the persistency of the URLs is achieved e.g. by an HTTP-level redirection service like w3id.org. Maybe it can be mentioned in the DCAT-AP spec as an example of how this can be done, including an example? Or at least link to a document saying what persistent URLs actually mean to illustrate that it is not that trivial to achieve, especially in combination with URL dereference to RDF data, etc., and that persistency is actually a big part of this HVD requirement.

bertvannuffelen commented 1 year ago

@jakubklimek on the persistent URLs we will include additional information. And I agree, it is non trivial challenge. In general, each domain should also reflect on what that mean. I raised it for the geospatial domain (INSPIRE). But actually each domain in the Annex that has its own metadata requirements should come with its definition here.

bertvannuffelen commented 9 months ago

In the Candidate Release a section is devoted to persistent identifiers. It is split in two aspects: a) on the need for high quality identifiers: https://semiceu.github.io/uri.semic.eu-generated/DCAT-AP/releases/2.2.0-hvd/#c2 b) on the business challenges that the persistency requirement brings . https://semiceu.github.io/uri.semic.eu-generated/DCAT-AP/releases/2.2.0-hvd/#c5

Suggestions for a technical approach are not included.