Define `ndc` application profile

[ioggstream]

I expect

Every vocabulary has the following properties:

• ndc:keyConcept - an ascii 7bit string identifier that is unique in each repository and with regard to a specific NDC namespace; it is used to identify the vocabulary to be published as REST API, eg. /vocabularies/v1/vocabularies/{keyConcept}

• ndc:controlledVocabularyURI - a property to correlate a vocabulary with the REST API server url.

Notes

Property names may be changed

[ioggstream]

It seems that dcat has the proper keywords to reference APIs in the semantic world.

This as the advantage of not touching the Dataset entry. We can derive a new profile on that.

@prefix ndc: <http://...>

<https://w3id.org/italia/data/data-service/licence>
  a ndc:DataService;
  ndc:endpointURL <http://api.ndc.gov.it/vocabularies/v1/vocabularies/licences>
  ndc:servesDataset <https://w3id.org/italia/controlled-vocabulary/licences>
.

[giorgialodi]

No @ioggstream unfortunately we have to pay attention here because, as I have already said on this point, DCAT-AP_IT, used at the time being in the datasets of this repo, is based on the previous versions of DCAT and DCAT-AP, not the new ones. In the current version of DCAT-AP_IT, DataService class is not available and there is instead Distribution. BTW: a DataService is not a Distribution so the URI you are suggesting here should be .../data/data-service/licence-api

However, I think we should have a more semantic driven approach here. NDC application profile is an extension of DCAT-AP_IT for the NDC application. Therefore, according to what I have already delivered to you all for the NDC profile, based on the current DCAT-AP_IT, the official one in our country, we have:

• ndc:keyConcept - it is a string defined in the NDC application profile (within NDC namespace); it is used to identify the key concept that a controlled vocabulary represents and it is used to create the related REST API URL of the vocabulary, eg. /vocabularies/v1/vocabularies/{keyConcept}
• either we define a direct property named ndc:jsonSchemaURL (it is already there in the NDC I delivered) from Dataset, or we use Distribution with accessURL property. But we need to understand what we want to represent here: the API itself for getting the content of the vocabulary or only the schema? Because if it is the API itself, we can reuse Distribution with accessURL property, if not we need to think about the other alternative.

There is another possibility but this implies deviating from DCAT-AP_IT if we consider the new version of DCAT. I need to think a little bit about it in terms of semantics. The real problem is that DCAT-AP_IT is old and should be up-to-date (I started saying that in 2019 more or less with no results) especially according to all these works here on schemas and APIs!

[ioggstream]

@giorgialodi ok of not using directli dcat v2. See #121 comments to the PR.

DataService is not a Distribution so the URI you are suggesting here should be .../data/data-service/licence-api

I edited the comment above ;)

WRT the REST API, we just want to provide the URL here. It's not important that's based on json-schema (each API itself can support different payloads in different and they are expressed in the OAS document which can reference in the future both json-schema and xmlschema using content negotiation via the Accept header).

The json-schema indexing is related to another task.

[ioggstream]

The real problem is that DCAT-AP_IT is old and should be up-to-date (I started saying that in 2019 more or less with no results) especially according to all these works here on schemas and APIs!

Agree... I think there are a lot of opportunities here.

[giorgialodi]

Yes I agree. I see only opportunities in updating it. But this is AGID's responsibility. Take into account that changes in that profile means also changes in the CKAN extension for DCAT-AP_IT used in many open data catalogues of Italian PAs. There was an action point in the ICT plan. Do you know results from that?

For the rest, do you want to represent the API URL through which anyone can get the content of the vocabulary? If so, let's use Distribution and accessURL which is what we can do in this case with DCAT version 1, used in DCAT-AP_IT. So let's remove the jsonSchemaURL or whatever you want to call it from the NDC profile. The only thing is that we need to add the additional distribution in all OntoPiA's vocs.

[giorgialodi]

This has been defined. I think we can close the issue. The ndc profile includes: 1) keyConcept property as in the past; 2) for the endpoint of the APIs, I reproduced the modelling of the new DCAT (version 2) because DCAT-AP_IT is based on the previous version of DCAT. In essence, there is a new class in the namespace of ndc that is DataService and attached to this there are three properties: endpointURL, servesDataset (to link it to the dataset) and endpointDescription. I also created the inverse property from Dataset to DataService (which is not in DCAT), in the case it can be helpful at a certain moment in time. The previous property I introduced and named jsonSchemaURL has been fully removed. I also included some cardinality constraints: keyConcept is mandatory for the dataset (1 and only 1); if DataService is specified the endpointURL is mandatory (1 and only 1

[ioggstream]

@giorgialodi reopening with the associated PR.