Whether to use @version, @validFrom, or @validTo values in URI

[csarven]

Some publishers use versions, validFrom, or validTo for their CodeLists. In order to distinguish one CL from another, the consideration here is whether to use @Version, @validfrom, or @validto values in URI. This is going to turn out butt ugly but the alternative is to generate some other token, and in the end, that's not achieving much. What would be the best way to get around this since adding these type of values in URIs is not considered to be good practice?

Currently if both @validfrom and @validto are present, their values are appended to the URI in order to make the CLs unique.

If no action is taken to make them unique, statements from multiple CLs (i.e., with different versions of the same CL) is piled under the same subject resource.

I'm leaning towards adding @Version:

http://example.org/code/CL_FOO/{$version}

where perhaps if version is "1.0" it will not be added - this is since SDMX 2.0 states that if no version is given, it is assumed to be 1.0. Hence, no version and version 1.0 can be treated equally and omitted from the URI. Looking at some sample metadata, @Version is most likely to occur i.e., there is no case where either validFrom or validTo occurs without a @Version. And since SDMX 2.0 says that "the validFrom and validTo attributes provide inclusive dates for providing supplemental validity information about the version", it might be sufficient to only include the version.

Reserving the URI without the version as an alias for the latest version of the CL, with a change history, might help in some ways, but may also be unreliable if applications use that URI and expect a particular list of codes 😟

On the plus side of all this, perhaps placing the @Version in the URI is not all that bad. Given that a KeyFamily will use a particular version of a CL, it needs to be able to point at that particular version. Although this goes against the general recommendation out there for not including the version in the URI, I think it is a good exception 😄 Otherwise, how would creating new terms for the CL URIs without the version information be any different? It seems equally arbitrary.

[cygri]

Stick the version into the URI. I would put the version before the code because that's friendlier for prefixed names (mycl:CL_FOO). Stick the 1.0 in there even if it's not explicitly set in the data, for consistency.

Putting dates and versions in IRIs is good if you need the ability to link to specific versions, which is the case here.

I agree that having a URI for the latest version of the code list would be good, even if the semantics of these URIs will be subject to change. Users of the code list can then decide whether they want to do early binding (referencing a specific version) or late binding (referencing whatever version is available at the time of client access).

[csarven]

Ditto on using version before code in URI and sticking 1.0 in there if no version given. I also realized that if 1.0 is not placed in the URI, then it would conflict with the latest version URI. I'll open a new issue to deal with the latest version URI i.e., the URI without the version which might have a hasVersion with change history etc.

For now, commit ca8e2f6 only puts in the version number in the URI, as opposed to also adding in the dates (removed validFrom and validTo). As stated earlier, I didn't see a case where the validFrom or validTo exists without version being stated. This is okay for now until shown otherwise. Keeps the URI simpler.

In addition to code URIs, this commit also applies to concept, and class URIs.