-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
::CatalogRecord adms:status and ::Distribution adms:status #86
Comments
We think adms:status should be kept for both an the definition and values should be aligned to the version in Distribution. |
This topic might be even more complicated to resolve as we have incompatabilities with between the definitions in the vocabulary adms (https://joinup.ec.europa.eu/release/adms-ap-joinup-version/20) and the one in DCAT-AP. definition adms:status property in de pdf document are
definition adms:status property in the RDF is
definitions in DCAT-AP are
In addition we have to realize that this is a specific DCAT-AP 1.x addition. As a corresponding property does not exists in DCAT 2.0. It only suggests to use Prov-O to express evolution traces. And in Prov-O there is no corresponding property & associated codelist because it defines the notions create, update, remove as activities (Classes). That is a more flexible model. |
proposed resolution: Given the labels are different and the definitions are different, the intentions might be different. This is best clarified out. Secondly, the enforcement of the codelist by adms:status (see RDF definition) makes that only these codes can be used. And as original definition for the catalog record change_type already indicated there might be need for more appropriate codes. Therefore, the proposal is to do a minimal change now for release 2.0. by removing the reference to the possible values. I propose to do the same on page 17 for the Distribution. And put this as an discussion topic for a future release for DCAT-AP 2.x |
I don't remember if this has already been discussed, but an option for a future release of DCAT-AP is to look into the relevant NALs from EU Vocabularies:
The Dataset status NAL has the same values of ADMS status, so it could be an alternative, if need be, for distributions (despite it refers to the status of a dataset). The Concept status NAL is more elaborated, and it is probably fit for catalogue records, which have a workflow similar to the ones used for items in a registry. For the records, the support in DCAT to the notion of "resource status" (possibly by using |
In W3C adms:status has been adopted as with the definition The status of the resource in the context of a particular workflow process Proposal to align the definitions of adms;status in DCAT-AP in similar wordings:
|
During WG 21 Oct 2021, the wg accepted to improve the definitions. |
::CatalogRecord adms:status-> This property refers to the type of the latest revision of a Dataset's entry in the Catalogue. It MUST take one of the values: :created, :updated or :deleted depending on whether this latest revision is a result of a creation, update or deletion. It is controlled by ADMS change type vocabulary (which doesn't exist)
::Distribution adms:status -This property refers to the maturity of the Distribution, it is controlled by ADMS status vocabulary http://purl.org/adms/status/.
The case here is that we have the same property in two different classes, with different definitions. If we refer to the same thing, the definitions must be aligned and
ADMS status vocabulary must be used for both.
If the property in CatalogRecord is about change type, then the property should be changed and a different property name should be used.
The text was updated successfully, but these errors were encountered: