Search engine for discovering works of Art, research articles, and books related to Art and Culture
ShareThis
Javascript must be enabled to continue!

Transition to Version 2 of the PDS4 Information Model.

View through CrossRef
IntroductionThe NASA Planetary Data System (PDS) released version 1.0 of the PDS4 Information Model (IM) in May 2013. Now in version 1.22, the PDS4 IM has undergone a series of regular releases, plus a number of additional point releases. Updates have varied from the addition of new permissible values and minor bug fixes, to major non-backward compatible changes. The PDS IM is now reaching the level of maturity that will warrant transition to Version 2.This presentation is intended both to announce the intention to undertake a major version upgrade of the PDS4 IM, and to solicit community input on the criteria and processes involved. IM Version 2 and Associated ChangesA plan is under discussion in PDS to move to major version 2 of the PDS4 IM upon the implementation of the next non-backward compatible change with or after the June 2025 release. In addition to the model changes proposed and anticipated for the release of a major new version of the IM, three significant policy and procedure issues are being discussed in connection with the transition to version 2.. PDS is seeking community input on these decisions.Policy and procedures for non-backward compatible changes. In keeping with industry standards for introducing non-backwards-compatible changes, the PDS4 IM now contains a number of deprecated “features” that would normally be removed over a major version boundary. However, the nature and mandate of the PDS archive is to span generations of both humans and technology. It is not practical, given ongoing budget constraints, for either users of the PDS4 IM or PDS itself to undertake migration efforts repeatedly to expunge unsupported constructs from the legacy archive, yet it is critical for modern programmatic support to ensure well-defined and homogeneous metadata practices for data coming in, with an IM that supports programmatic access to the entirety of the archive.  It is not clear that the best service to the user community is to require software to be cognizant of IM major versions when attempting to gather data from multiple sources ingested at various epics of PDS history. However, if the deprecated features remain visible, how effective can PDS be in enforcing that they not be used in new data submissions? PDS is currently weighing the question of whether to continue the current practice of retaining deprecated elements in the IM or permanently removing them at major version transitions following a period of deprecation.Policy and procedures for determining the need for a major version update. The PDS4 IM was released at version 1 and is still at version 1, 10+ years later. Given the circumstances mentioned previously regarding the issue of removing deprecated constructs, it is consequently not easy to determine if, let alone when, the IM should be versioned for anything other than a major shift in either design or implementation technology. The PDS4 DDWG has been presented with a challenge to propose criteria for considering a major version upgrade, especially in view of the age and history of the current version. It is particularly important to get feedback from the community of users, programmers, and IPDA partners on these criteria.Semantic versioning throughout the PDS4 namespaces. The PDS4 IM is divided into namespaces, and adding a new namespace is the primary method for extending the IM into new domains. For historical reasons, the core IM and each of the namespace models extending it have independent four-element version numbers. As it has evolved, there has been no pressing need for four elements in any of these version numbers, and semantic versioning has become the industry standard for software and similar technologies. Semantic versioning for the IM seems desirable, but the role of version numbers of namespaces and their relationship to the core version needs to be well-defined, and perhaps even re-defined, within the semantic context.References: [1] Planetary Data System Standards Reference, Version 1.21.0, JPL D-7669, Part 2, 1 Oct. 2023.
Copernicus GmbH
Title: Transition to Version 2 of the PDS4 Information Model.
Description:
IntroductionThe NASA Planetary Data System (PDS) released version 1.
0 of the PDS4 Information Model (IM) in May 2013.
Now in version 1.
22, the PDS4 IM has undergone a series of regular releases, plus a number of additional point releases.
Updates have varied from the addition of new permissible values and minor bug fixes, to major non-backward compatible changes.
The PDS IM is now reaching the level of maturity that will warrant transition to Version 2.
This presentation is intended both to announce the intention to undertake a major version upgrade of the PDS4 IM, and to solicit community input on the criteria and processes involved.
 IM Version 2 and Associated ChangesA plan is under discussion in PDS to move to major version 2 of the PDS4 IM upon the implementation of the next non-backward compatible change with or after the June 2025 release.
In addition to the model changes proposed and anticipated for the release of a major new version of the IM, three significant policy and procedure issues are being discussed in connection with the transition to version 2.
PDS is seeking community input on these decisions.
Policy and procedures for non-backward compatible changes.
In keeping with industry standards for introducing non-backwards-compatible changes, the PDS4 IM now contains a number of deprecated “features” that would normally be removed over a major version boundary.
However, the nature and mandate of the PDS archive is to span generations of both humans and technology.
It is not practical, given ongoing budget constraints, for either users of the PDS4 IM or PDS itself to undertake migration efforts repeatedly to expunge unsupported constructs from the legacy archive, yet it is critical for modern programmatic support to ensure well-defined and homogeneous metadata practices for data coming in, with an IM that supports programmatic access to the entirety of the archive.
  It is not clear that the best service to the user community is to require software to be cognizant of IM major versions when attempting to gather data from multiple sources ingested at various epics of PDS history.
However, if the deprecated features remain visible, how effective can PDS be in enforcing that they not be used in new data submissions? PDS is currently weighing the question of whether to continue the current practice of retaining deprecated elements in the IM or permanently removing them at major version transitions following a period of deprecation.
Policy and procedures for determining the need for a major version update.
The PDS4 IM was released at version 1 and is still at version 1, 10+ years later.
Given the circumstances mentioned previously regarding the issue of removing deprecated constructs, it is consequently not easy to determine if, let alone when, the IM should be versioned for anything other than a major shift in either design or implementation technology.
The PDS4 DDWG has been presented with a challenge to propose criteria for considering a major version upgrade, especially in view of the age and history of the current version.
It is particularly important to get feedback from the community of users, programmers, and IPDA partners on these criteria.
Semantic versioning throughout the PDS4 namespaces.
The PDS4 IM is divided into namespaces, and adding a new namespace is the primary method for extending the IM into new domains.
For historical reasons, the core IM and each of the namespace models extending it have independent four-element version numbers.
As it has evolved, there has been no pressing need for four elements in any of these version numbers, and semantic versioning has become the industry standard for software and similar technologies.
Semantic versioning for the IM seems desirable, but the role of version numbers of namespaces and their relationship to the core version needs to be well-defined, and perhaps even re-defined, within the semantic context.
References: [1] Planetary Data System Standards Reference, Version 1.
21.
0, JPL D-7669, Part 2, 1 Oct.
2023.

Related Results

A Provenance Model for the Planetary Data System
A Provenance Model for the Planetary Data System
Provenance is critical to the scientific integrity of archived data. It establishes the authenticity of science data by providing a detailed account of its origin, ownership, proce...
Fertility Transition Across Major Sub-Saharan African Cities: The Role of Proximate Determinants
Fertility Transition Across Major Sub-Saharan African Cities: The Role of Proximate Determinants
Abstract Background Sub-Saharan Africa’s fertility transition has lagged behind other regions despite rapid urbanization, resulting in persistently high fertility rates. S...
Updates to the PDS/PPI Website
Updates to the PDS/PPI Website
IntroductionA new version of the NASA Planetary Data System (PDS) Planetary Plasma Interactions (PPI) Node website (https://pds-ppi.igpp.ucla.edu/) was released in April 2024. This...
Updates on SPICE for ESA Missions
Updates on SPICE for ESA Missions
Introduction:  SPICE is an information system the purpose of which is to provide scientists the observation geometry needed to plan scientific observations and to analyze ...
SPICE Status and Updates for ESA Missions
SPICE Status and Updates for ESA Missions
Introduction:  SPICE is an information system the purpose of which is to provide scientists the observation geometry needed to plan scientific observations and to analyze the data ...
Model-checking ecological state-transition graphs
Model-checking ecological state-transition graphs
Abstract Model-checking is a methodology developed in computer science to automatically assess the dynamics of discrete systems, by checking if a system modelled as...
The Mercury Radiometer and Thermal Infrared imaging Spectrometer (mertis) onboard Bepi Colombo: 2020 Moon flybys data results.
The Mercury Radiometer and Thermal Infrared imaging Spectrometer (mertis) onboard Bepi Colombo: 2020 Moon flybys data results.
Introduction: The MErcury Radiometer and Thermal Infrared Spectrometer (MERTIS) is an instrument to study the mineralogy and temperature distribution of Mercury’s surface...
Wastewater QC workflow in GalaxyTrakr (SSQuAWK4) v2
Wastewater QC workflow in GalaxyTrakr (SSQuAWK4) v2
PURPOSE: Step-by-step instructions for checking sequence quality for SARS-CoV-2 wastewater samples using SSQuAWK: SARS - CoV - 2 Sequence Quality Assurance Workflow and Kontrapti...

Back to Top