Policy: what and when?
There are three types of changes that can be distinguished for the specification of DCAT-AP according to their implications for interoperability:
Bug fixes: First of all, the specification may contain errors in the text or unresolved references. These types of errors will not affect interoperability in any way.
These errors may be corrected in a ‘bug fix’ release on a six-month schedule – every May and November, if not combined with one of the following types of releases. This type of release will not be published if there are no changes requests for this category.
Minor semantic changes: Secondly, there may be a need for changes that do affect interoperability but only in non-disruptive ways. Examples include the addition of optional properties or ‘deprecation’ of unused, optional properties.
These changes may be made on a yearly schedule – every November, if not combined with the following type of release. This type of release will not be published if there are no change requests for this category. If it is published, it will also include any bug fixes if any were requested.
Major semantic changes: Thirdly, there may be a need for changes that have more serious consequences for interoperability, such as addition of mandatory properties or changes in the mandatory controlled vocabularies.
These changes will not be made more frequently than once every two years in November. This type of release will not be published if there are no change requests for this category. If it is published, it will also include any bug fixes and minor semantic changes if any were requested.
In case requests have been received that are classified as major semantic changes, at least eight months before a scheduled date for a major release, a decision is taken by the ISA2 Programme Management Team and communicated to the Working Group to open a discussion round in the Working Group in order to discuss and agree major semantic changes.
Evolution of the W3C Recommendation could lead to the need for major semantic changes. Whenever W3C plans to publish a new version of DCAT, it may be foreseen that the process towards a major semantic release will be scheduled to enable the Working Group to review W3C work and determine implications for DCAT-AP.
The current release schedule is available on Joinup and below. The schedule concerns the two years to come: 2018 and 2019, starting in January 2018.
Stakeholder involvement: who?
All stakeholders are invited to become members of the existing DCAT-AP Working Group. This includes stakeholders like maintainers of national and regional application profiles, developers of solutions that implement DCAT-AP and managers of systems that are built on the functionality of DCAT-AP implementations. Other types of interested parties may contribute and comment but in such case, they will be invited to join the DCAT-AP Working Group.
The DCAT-AP Working Group will be informed of all releases ahead of time. Its role varies depending on the type of release:
- For a bug fix release, the DCAT-AP Working Group will be informed at least two weeks ahead of publication during which time the members can voice objections;
- Minor semantic changes will be communicated to the DCAT-AP Working Group for review at least six weeks ahead of publication;
- Major semantic changes will be discussed and agreed by the DCAT-AP Working Group using the process and methodology as defined by the SEMIC Process and methodology for developing semantic agreements with at least a three-month discussion period and at least a one-month public review of the proposed new release.
Process for change requests: how?
Any problems encountered, or suggestions for new functionalities can be submitted as issues on the DCAT-AP repository on GitHub. Submitters of issues need to register for a free user account by clicking "Sign up for GitHub" on the GitHub start page.
There is no strict structure for submissions, but it will be helpful if information like submitter name, affiliation, portal represented, clear and concise description of the requirement and proposed solution, if any, so that the editor of the specification has enough information to be able to classify and process the request. A short guideline for submission of change requests is available on GitHub and on Joinup.
The editor will classify every received change request and schedule its processing depending on an initial evaluation of severity, and respond to the issue within two weeks, noting next steps as part of the issue on GitHub. At least every three months, the editor will prepare a status report for the DCAT-AP Working Group with an overview of change requests received in each of the three categories. Change requests are taken into account up until a specific moment before a release:
- Bug fix: until one month ahead of the release date;
- Minor semantic change: until three months ahead of the release date; and
- Major semantic change: until eight months ahead of the release date.
If a change request is opened after this moment, it will not be considered for the upcoming release, but for a future release. The release schedule below starts in January 2018 and ends in December 2019.
Final versions of releases are submitted to the European Commission for acceptance. Both minor and major semantic releases are submitted to the ISA² Committee for formal endorsement.
Implications for implementers
The three types of releases have different implications for implementations of DCAT-AP.
Bug fixes will have no implications for implementations. Everything can continue to work as before.
Releases with minor semantic changes will not need immediate implementation in operational systems or inclusion in a national or regional profile, as the existing implementations and profiles will remain conformant. Every implementation can choose to implement additional features at a time at the convenience of the maintainer of the system and every profile can be updated independently. Existing systems can continue to operate unchanged, but before they upgrade they will not be able to access functionality that is provided by the new model elements.
Releases with major semantic changes will in general not be backward compatible; software solutions that implement the changes cannot fully interoperate with the software that was based on the previous version of the specification. In such cases, the introduction of a release needs to be accompanied by a well-managed software upgrade process. Especially in cases were multiple software vendors are involved, such upgrades need to be carefully planned and executed with ample time for testing and verification.
In parallel with the development of a release with major semantic changes, implementers of systems and maintainers of profiles will need to plan the upgrade process alongside the development of the DCAT-AP specification.