URI Structure for registry item identification

[jetgeo]

There should be a consistent way of identifying “registered items” in ISO/TC 211 registers.

[PeterParslow]

Do you mean a pattern for the ISO 19135-1::RegisterItem.itemIdentifier (which is of type CharacterString)? (This is adopted unchanged by 19127)

Or a URI / URL pattern for public access to those items? Which I hope would be a pattern something like https://.tc211.org/XXXXX where XXXX is the itemIdentifier - or perhaps with item class in the path, if the register contains more than one item class

Or perhaps there's an emerging pattern from OGC APIs that would help?

I see that ISO 19127 gives this responsibility to the register manager: to "assign individual registration identifiers". This presumably makes it one of the "Registration Services" in the ISO Registration Authority Agreement. But I'm pleased that Ribose has asked TC211 Resources for their view - that can head us towards consistency across future registers.

When the Geodetic CB agreed ISOGR:{id}, did they specify what they were agreeing? Was it the form of the itemIdentifier, or is that the "id" part, with ISOGR being a kind of namespace in situations where one isn't using a URI/URL? There are some warnings around the use of colons in URIs: specifically, they can cause problems in relative URIs

[ronaldtse]

I see that ISO 19127 gives this responsibility to the register manager: to "assign individual registration identifiers". This presumably makes it one of the "Registration Services" in the ISO Registration Authority Agreement. But I'm pleased that Ribose has asked TC211 Resources for their view - that can head us towards consistency across future registers.

Indeed I think it is useful to have a consistent and unified mechanism for TC 211 registers. This will allow resolvability which is key to two things:

1. From this identifier, the user wants to know where it can be resolved. e.g. when a user sees urn:...epsg... the user knows to resolve them at EPSG.
2. From the identifier (or from resolving the identifier) the user can find out "what data" can be returned. Is it the register item? Or metadata? What format is that going to be in?

With 19157-1 coming along it is important that these questions are answered.

In 6709 there is a notation for CRS as {uri}:{id} or {register-abbrev}:{id}.

• The Geodetic CB agreed that ISOGR:{id} would point to a UUID in the ISO GR. ISOGR:{id} is purely a shorthand for https://geodetic.isotc211.org/item/{id}.
• On the other hand EPSG:{id} indicates it is to EPSG.

Right now this notation is manually defined, not resolvable -- in the future, perhaps it should be.

I know this whole topic ties into the questions "are there going to be different registry systems", and the number/roles of control bodies, so everything here is subject to discussion... nonetheless here are some possible views.

From the registry management point of view, it would be preferable to have unrelated registers (e.g. 19127 vs 19157-1) potentially in different systems because:

• the management process may differ (different control bodies)
• the registers may have different system needs (the needs of 19127 and 19157-1 are quite different)
• allows different people to work on/maintain different registers

Which is ultimately helpful for business continuity, availability and innovation.

@ReesePlews and I have also been discussing about pURLs.

One possible scheme (as an example) is to have a "resolution map" at https://registries.isotc211.org/somelocation that allows resolution of given registry.

e.g. if we have a list of rules in this list, such as (fictitious):

ISOGR:{id} => https://geodetic.isotc211.org/item/{id}
ISODQM:{id} => https://dqm.isotc211.org/{id}

And we define a notation for TC 211 registry items, such as: (since we can't use RFC 5141 urn:iso, this is again fictitious)

urn:isogeo:ISOGR:{item}:{some status/date/version, etc}

Then a user can:

1. When they see urn:isogeo... they go resolve this at https://registries.isotc211.org/somelocation
2. https://registries.isotc211.org/somelocation/ISOGR points them to https://geodetic.isotc211.org/item/{id} (and maybe tells them what data is provided at that endpoint (could be multiple links or multiple types of data)
3. Reach https://geodetic.isotc211.org/item/{id} and resolve/retrieve that data.

Thoughts welcome!