Define alias behaviour/requirements for the Definitions Server.

[rob-metalinkage]

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.

[ghobona]

The behaviour is being specified in the Policy Issue #116

[pebau]

@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.

[cportele]

/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).

[pebau]

documentation on the OGC resolver wiki says: * final solution, as per OGC-NA decision in March 2019: o version "0" shall always point to the latest version of the corresponding EPSG definition. (Caveat: this may imply unnoticed changes by EPSG) See https://external.ogc.org/twiki_public/CRSdefinitionResolver/CRSdefinitionDiscussion#Abbreviation_Changes_in_EPSG_Database 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 <#121 (comment)>, 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 - Executive Director, rasdaman GmbH Bremen (HRB 26793) https://rasdaman.com, mail: ***@***.*** tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 - Professor of Computer Science, Jacobs University Bremen https://www.faculty.jacobs-university.de/pbaumann mail: ***@***.*** tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

[cportele]

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:

• This rule only applies to definitions from the EPSG authority, not to any other definitions with an OGC URI.
• This clarifies how "un-versioned" is interpreted for EPSG definitions. While EPSG has versions of its definitions, the definitions are only versioned with clarifications, so "un-versioned" means that always the latest version applies, hence this rule. If an EPSG definition needs a substantive change, there will be a new definition with a new code.

[ghobona]

Solution implemented as described at #108