Registry support for release versions of codes

[amilan17]

No description provided.

[mo-marqh]

assumptions:

1. A release represents a point in time view on the registered content
2. registered Entities are referenced by a release, as URIs only
   • if a change made to a core entity, e.g. a spelling change, the difference would not be represented as different across old and new versions
   • the release is thus a list of contained URI, but not any detail differences between releases
3. A release is defined within the github repository, using a control csv file
4. A release is defined once, with a release date
5. A release defines a namespace (e.g. http://codes.wmo.int/wmdr/2021-2​ and register structure (e.g. http://codes.wmo.int/wmdr/2021-2​/ClImateZone but these release registers will contain references to non-versioned entities (e.g. http://codes.wmo.int/wmdr/ClimateZone/steppeColdArid)
   • this protects users against accidental use on of non-standardised identifiers within their XML
   • this URI is not for use in data!! http://codes.wmo.int/wmdr/2021-2/ClimateZone/steppeColdArid must not be used
     • the register must be as clear as possible about this
     • can we make it such that this entity does not exist?

given these assumptions, I think we may be able to represent releases using the following indirection:
The managed central content is published (as now):

http://codes.wmo.int/wmdr/ClImateZone
skos:member http://codes.wmo.int/wmdr/ClImateZone/steppeColdArid ;
skos:member http://codes.wmo.int/wmdr/ClImateZone/steppeHotArid ;
  ...

Each individual release then contains a defined list of items, as defined in the central register:

http://codes.wmo.int/wmdr/2021-2/ClImateZone 
skos:member http://codes.wmo.int/wmdr/ClImateZone/steppeColdArid ;
skos:member http://codes.wmo.int/wmdr/ClImateZone/steppeHotArid ;
  ...

thus the individual entities are defined once, e.g.
http://codes.wmo.int/wmdr/ClImateZone/steppeColdArid

and these are the only standardised URIs

but, these URIs are referenced multiple times from different releases

this is implemented by registerItems, so the register managed locator:
http://codes.wmo.int/wmdr/2021-2/ClImateZone/_steppeColdArid
(which is not a URI, just a URL, not to be used in payloads)
is defined by
http://codes.wmo.int/wmdr/ClImateZone/steppeColdArid

validation is only based on the controlled URIs, such as http://codes.wmo.int/wmdr/ClImateZone/steppeColdArid (as currently standardised)

[mo-marqh]

if this seems like a useful proposal, then we can prepare a workflow to support this and publish content onto the test registry, with limited access, to enable exploration of this option

[joergklausen]

Not sure I fully understand. The requirement is to be able to support several versions of WMDR XSD primarily. These may or may not use different code lists. Exemplary use case:

• WMDR XSD version x needs a variable 'soil temperature' with notation nnn from a code list 'observed variable'.
• WMDR XSD version y needs a matrix 'soil' with notation 'soil' from a code list 'matrix' and a variable 'temperature' from a code list 'observed variable' with a notation mmm.

An application such as OSCAR/Surface parsing corresponding XML files will map both to the same observed variable with notation nnn in this case. So the difference is in the way the information is modeled, whereby the WMDR XSD version y supports better normalization of the entities (nnn = soil & mmm).
So the registry needs to support different codelists as a function of the version of the XSD, not the FT.

[marqh]

thank you for the feedback @joergklausen

please may i explore this in some more detail?

Each code list is published within the registry within the /wmdr namespace
so, a code list
http://codes.wmo.int/wmdr/ObservedVariableTerrestrial
exists
and contains an entity
http://codes.wmo.int/wmdr/ObservedVariableTerrestrial/596 (soil temperature)

that is available for use in XML

for a given release-version x this code is to be asserted to be available. Is this a correct requirement?

for a different release-version y, where some changes have been made, is this entity:
http://codes.wmo.int/wmdr/ObservedVariableTerrestrial/596 (soil temperature)
also available to be used?

Or, is the requirement that this entity is not available for use at release-version y?

Similarly, is there a code list that does not exist at the point where release-version x is tagged, but is then later published and is available for use in release-version y?

[joergklausen]

Hi @marqh
coming back a bit late with my reply, perhaps we can simplify the requirement by stating that for each version of the XSD (and the approach to versioning still needs to be decided!), there is a need to know which code table(s) are valid. Or, vice-versa, the code tables should carry a tag that indicates which version of the XSD they support. There are code tables that will support multiple versions of XSD (hopefully, the majority fall into this category), but there will be others that may only support a specific version. In terms of URL, I think the best approach is to work towards https://codes.wmo.int/wmdr/{version}/{code_table}/{notation_of_element}. It may well be that URLs that are different only in resolve to the very same element, but this approach gives flexibility and full control.