Closed rob-metalinkage closed 10 months ago
The behaviour is being specified in the Policy Issue https://github.com/opengeospatial/NamingAuthority/issues/116
@rob-metalinkage @ghobona
As I incidentally see this alias above, let me mention that /0/ by definition is an alias for the latest version available, which incidentally for WMS is 1.3, so the additional alias is consistent. The caveat of hardwiring this reference is that any future new version would lead to a deviation = inconsistency.
/0/ by definition is an alias for the latest version available
That statement is not correct. A version "0" identifies un-versioned definitions, which is something different. See the policy: https://docs.opengeospatial.org/pol/09-048r5.html#_production_rule_for_specification_element_names
For the CRS84 alias, this basically makes the CRS84 definition "un-versioned", which is a good step.
A similar change was previously introduced for the EPSG definitions, which were also used with a version in the past (in the time when OGC-NA still used URNs).
documentation on the OGC resolver wiki says:
Can we clarify this maybe from OGC-NA decision records?
Whatever the final mechanics is, there should be common behavior. If 0 means "unversioned then it implies that there is no versioned entity in the database in parallel, this should be part of the definition. Plus, a clarification is needed as to what a URI with 0 resolves to in case there are versions in the database.
-Peter
On 03.12.21 14:57, Clemens Portele wrote:
/0/ by definition is an alias for the latest version available
That statement is not correct. A version "0" identifies un-versioned definitions, which is something different. See the policy: https://docs.opengeospatial.org/pol/09-048r5.html#_production_rule_for_specification_element_names https://docs.opengeospatial.org/pol/09-048r5.html#_production_rule_for_specification_element_names
For the CRS84 alias, this basically makes the CRS84 definition "un-versioned", which is a good step.
A similar change was previously introduced for the EPSG definitions, which were also used with a version in the past (in the time when OGC-NA still used URNs).
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/NamingAuthority/issues/121#issuecomment-985540990, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOR5DW757XZLQRJMJVXHBTUPDEEDANCNFSM47NLIPKA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
-- Dr. Peter Baumann
OK thanks for the link. That clarifies it, although section 7.4 of the OGC-NA policy "Names for EPSG definitions" really should have been updated with this information, if there was an OGC-NA decision how to treat version "0". (As an aside, I do not understand why CRS84, which is not an EPSG definition, is discussed in section 7.4.)
The wording
version "0" shall always point to the latest version of the corresponding EPSG definition
states two things:
Solution implemented as described at https://github.com/opengeospatial/NamingAuthority/issues/108
There are many existing cases and new ones such as #120 where it is desired to host "aliases".
These may be declared to be owl:sameAs
The simple solution is to entail ?p ?o where ?p ?o (and vice versa) - copy properties so both URI1 and 2 look the same content wise for all forms (HTML UI as well as RDF etc)
Other options: 1) make the vocab UI do more work - follow sameAs links at query time 2) make the redirect layer do more work (redirect to the canonical form)
Regardless, if we are going to prefer one form over another (what canonical URI should people cite) we'll need to add information about the canonical version (the definition server can't really inspect URIs to see if the have both the /0/ and the information to find the canonical form.
If the necessary extra content is not, or only partially, populated, how should behaviour gracefully degrade?
The UI should also probably be tuned to flag this situation explicitly.
How would you expect user's to interact with aliases? Use Case might be worth while and options and prototypes can be explored.