Make version optional in /def/ URIs

[dr-shorthair]

I strongly recommend against having an explicit version-number in a URI identifier.

If a version is present, then it usually requires you to change all the URIs when you issue a new version, even for things that haven’t changed. That can really interfere and break things.

If a definition does change, then it is a new thing and should have a new identifier, which can be done in a better way than changing a version number.

In https://docs.opengeospatial.org/pol/09-048r5.html, update S6.2 to make the 'version' field optional.

---

6.2. Production rule for definition names

The basic form for an OGC name that identifies a definition shall be produced using the following rule:

OGCResource   = "def"
ResourceSpecificPath = definition-type "/" authority [ "/" version ] "/" code
ResourceSpecificString = definition-type ":" authority ":" versionURN ":" codeURN
definition-type = segment-nz-nc ; a token from the register of OGC definition types1
authority     = segment-nz-nc ; a token from the register of OGC authorities2
version       = segment-nz-nc / "0" ; optionally use 0 for un-versioned names
code          = segment-nz-nc *( "/" segment-nz-nc )
versionURN    = segment-nc ; this may be a zero-length string
codeURN       = segment-nz-nc *( ":" segment-nz-nc )

"version" is optional. For un-versioned definitions:

• within the http URI form the version field shall either be "0", else the token and delimiter may be omitted
• within the URN form versionURN shall be a zero-length string—so an un-versioned definition can be detected by a pair of colons "::".

[pebau]

The convention existing since many years is that a version "0" refers to the latest version available, which seems to be the desired effect.

Version numbering as such appears important - how would we otherwise cope with EPSG changes where the original CRS number is retained by OGP? Ex: "Long" -> "Lon" in EPSG:4326.

[dr-shorthair]

If you really need the version number then use it. I'm just proposing to make it optional, so applications that do not need it don't have to fake it. (FWIW /0/ was always a kluge, to get around the :: inherited from the URN standard.)

'The latest version available' assumes that 'versions' of definitions exist, which are different to each other enough to need a different URI, but somehow not different enough to change the last element of the URI. That does not apply to all applications.

[rob-metalinkage]

In the definitions server we should aim to include (or entail) explicit prev/next/current links to versions.

on a side note I'm currently exploring mechanisms to reduce "old version clutter" from browse facilities :-)

[pebau]

I understand - there are many more interesting things than the pure version numbering captures.

What about adopting the old fact / rules distinction and have a semantic layer on top of the basic URIs? I recall anyway that at some time the community preferred URIs without interpretation of path components, just as opaque strings. So for bw compatibility the current state could remain, and a reasoning component could come on top of that, with the way more powerful reasoning mechanisms.

[ghobona]

The OGC-NA approved this Motion on 2021-12-10.

"The OGC Naming Authority Sub-Committee approves the proposal to amend the OGC Name Type Specification - definitions - part 1 – basic name (OGC 09-048r5) policy document to make the version segment of the URIs optional. Use of the version number is still allowed. Upon approval of this motion, the Chair of the Sub-Committee will proceed to update the policy document ahead of submitting the revised document to the Technical Committee for approval."

[ghobona]

The fix has been moved to the master branch.

An HTML version of the policy document will be generated once metanorma Issue 369 has been fixed.

[ghobona]

Draft Policy revision sent to OGC-NA for review. This issue is addressed in Clause 5.2

[ghobona]

The revised policy has been published.