Deprecate OGC UoM recommendations, instead QUDT in GeoSPARQL

[nicholascar]

GeoSPARQL 1.0 states that:

8.8.10

Several non-topological query functions use a units of measure URI. The OGC has defined some standard units of measure URIs under the http://opengis.net/def/uom/OGC/1.0/ namespace, for example <http://opengis.net/def/uom/OGC/1.0/metre>

I would like to deprecate this pointer and indicate QUDT in GeoSPARQL 1.1. for use for UoM since it is a far more mature and comprehensive UoM ontology.

Note that there is now a mechanism in QUDT to support community profiles of QUDT - see the Loop3d Vocabulary of Units. This would allow the creation of an OGC or a spatial profile of QUDT as an ontology or a vocabulary, if OGC members wish to see a UoM list presented as a sKOS vocab, not an OWL ontology. (I doubt it: the OGC UoM vocab is so small it can hardly be used).

Will the NA support this deprecation and, if so, will the NA support removal of the OGC UoM vocab in favour of QUDT or QUDT-detived UoM vocabs?

[dr-shorthair]

I would certainly support OGC delegating units-of-measurement descriptions and identifiers to a more general authority.

However, possible also consider changing the data-type for radius and distance to cdt:ucum - see https://github.com/opengeospatial/ogc-geosparql/issues/98#issuecomment-788644317

[ghobona]

The existing uom URIs are used in several standards (e.g. CIS,GMLJP2, O&M, SOS etc) and operational systems. So a case for deprecation would have to be considered at a TC-wide level.

I will add the topic of QUDT to the next OGC-NA meeting (March 22nd, 6:15 PM - 7:45 PM) for discussion. @nicholascar are you available to brief the OGC-NA about QUDT?

[nicholascar]

nicholascar are you available to brief the OGC-NA about QUDT?

Yes I am. @dr-shorthair and I are on the Technical Advisory Board for QUDT so have a pretty good grip on things there.

Please could you send me the details for the OGC-NA meeting and I'll be there.

[ghobona]

That's great! The meeting details are at https://portal.ogc.org/meet/

You will have 15 minutes to cover both the presentation and Q&A.

[nicholascar]

OK, I didn't know to look there (the /meet/ bit), only the main portal calendar.

I've put the details down in my calendar now. Looking forward to attending.

[ghobona]

2021-03-22 OGC-NA meeting outcome

We need to understand the governance more (register owner, register manager etc), long term management

[dr-shorthair]

@nicholascar - haha finding your way around the OGC Portal is the way you really know if you've been initiated.

[ghobona]

Following on from the March 22nd OGC-NA meeting, additional information regarding governance is at:

• QUDT is governed by a board of directors, listed at http://www.qudt.org/pages/BoardOfDirectors.html
• There is also a Technical Advisory Board, listed at http://www.qudt.org/pages/TAB.html

Having reviewed the literature regarding QUDT.org, including publications that reference it, I will make a recommendation to the OGC-NA to create a register for QUDT UOMs.

However, I will also recommend that OGC maintains its existing register of OGC UOMs, as well as links to UCUM UOMs, without deprecation.

As for which UOMs to use in GeoSPARQL, that will have to be a decision for the GeoSPARQL SWG.

Copying in the GeoSPARQL SWG Chairs: @kotzino @jabhay @pvretano

[RogerLott]

The UoM item in a string such as http://opengis.net/def/uom/EPSG//9001 is a component of an EPSG CRS definition. Changing this will break all CRS descriptions. If the authority is something else, such as OGC in http://opengis.net/def/uom/OGC/1.0/metre, this probably will be ok as I think that the CRS definitions in the OGC definitions server (SECORE) probably all use the EPSG units. But if a new general source of units is to be used, it might be better to avoid using "uom" as the objectType element of the string.

[dr-shorthair]

create a register for QUDT UOMs.

What does that mean? Every QUDT unit has a QUDT.org URI. It is counterproductive to mint OGC URIs on top.

[ghobona]

2021-06-17 OGC-NA decision to delegate this issue to the GeoSPARQL SWG.

The OGC-NA also noted that this is an architectural issue and not necessarily a naming issue.

[nicholascar]

2021-06-17 OGC-NA decision to delegate this issue to the GeoSPARQL SWG.

So GeoSPARQL can choose what UoM and what references to them to use, fine, but that doesn't help the OGC as a whole use a well managed set of UoM like QUDT and thus surely duplication of effort will continue with other OGC SWGs and so on reinventing UoM wheels (and probably in inferior form).

I still think the NA needs to make a recommendation here to all of OGC on UoM since UoM is a common concern for many OGC groups but also outside their specific interests - it's background stuff. Just like for modelling vocabularies NA uses/supports/recommends SKOS.

[ghobona]

@nicholascar The OGC-NA recommends use of definitions provided through the Definitions Server (i.e. with an http://www.opengis.net/def base URI).

One suggestion was to register QUDT.org as an authority in the Definitions Server and then to create a mirror of the QUDT.org definitions on the OGC Definitions Server (or to proxy requests through to QUDT.org like is done for EPSG definitions). This would "mint OGC URIs". However, a comment from a member of the QUDT.org Technical Advisory Board (TAB) pushes back on the suggestion of minting OGC URIs.

If the GeoSPARQL SWG uses QUDT.org URIs in the GeoSPARQL Standard it will create inconsistency with other OGC Standards and therefore an architectural risk. So the GeoSPARQL SWG would need to justify to the TC why use of QUDT.org URIs was necessary.

Here are the suggested next steps:

• 1- QUDT.org (or its TAB) confirms whether it endorses a proposal to be registered as an Authority in the Definitions Server so as to enable QUDT.org definitions to be reached through URIs that have a http://www.opengis.net/def base URI
• 2a- If QUDT.org endorses the proposal, I will set up an e-mail vote for the registration (in the interests of time)
• 2b- If QUDT.org rejects the proposal, then the GeoSPARQL SWG would have to justify to the TC why use of QUDT.org URIs was necessary

[cportele]

The OGC-NA recommends use of definitions provided through the Definitions Server (i.e. with an http://www.opengis.net/def base URI).

That wasn't clear to me from the discussion and I am not aware of a policy about this. OGC registers definitions that are governed by OGC or for which no URI is available from the governing body (the reason why EPSG definitions have OGC URIs). I see no reason why OGC should recommend to ~only~ use OGC URIs in OGC standards, we should use existing URIs whenever they fit.

On the other hand, I also do not see why OGC should only allow the use of QUDT for units. If QUDT works and is the best offer, it will be used, otherwise not.

[ghobona]

@cportele The statement said "The OGC-NA recommends use of definitions provided through the Definitions Server (i.e. with an http://www.opengis.net/def base URI)."

There is no use of the word 'only'.

[ghobona]

Please note however that the absence of the word 'only' in the statement above should not be interpreted to mean endorsement of 3rd Party definition URIs.

[cportele]

@ghobona - Yes, there was no "only", I updated the comment, but also without the "only" I do not see why OGC, as a general rule, should recommend the use OGC URIs. We should be using the most appropriate URI/definition for the purpose, whether that is minted by OGC or someone else.

I agree that third-party URIs or their endorsement are not in the scope of the OGC-NA. The NA is a registration authority for OGC definitions. That is, it is not the role of the OGC-NA to recommend or endorse the use of third-party URIs/definitions.

[nicholascar]

I agree that third-party URIs or their endorsement are not in the scope of the OGC-NA. The NA is a registration authority for OGC definitions. That is, it is not the role of the OGC-NA to recommend or endorse the use of third-party URIs/definitions.

OK, I do understand that role limitation. However, the origin of this Issue was about deprecating a very limited, verging on trivial UoM vocabulary, that this authority had set up.

If the GeoSPARQL SWG uses QUDT.org URIs in the GeoSPARQL Standard it will create inconsistency with other OGC Standards and therefore an architectural risk. So the GeoSPARQL SWG would need to justify to the TC why use of QUDT.org URIs was necessary.

Well the case is easily made: the OGC UoM vocab has only 11 distinct UoM in it (and several naming duplicates) and we require far more UoM than that to be available for GeoSPARQL and I'm sure many others need more too.

Here are the suggested next steps:

1- QUDT.org (or its TAB) confirms whether it endorses a proposal to be registered as an Authority in the Definitions Server so as to enable QUDT.org definitions to be reached through URIs that have a http://www.opengis.net/def base URI 2a- If QUDT.org endorses the proposal, I will set up an e-mail vote for the registration (in the interests of time) 2b- If QUDT.org rejects the proposal, then the GeoSPARQL SWG would have to justify to the TC why use of QUDT.org URIs was necessary

Sorry but this cannot be the answer. It cannot be that an established system has to re-register URIs with OGC for use. As @cportele says: "OGC, as a general rule, should recommend the use OGC URIs. We should be using the most appropriate URI/definition for the purpose, whether that is minted by OGC or someone else". Back to the initial request: we might consider the reverse proposal: redirect OGC UoM URIs to QUDT!

I note that there are similar reluctance at ISO TC211 to endorse, or even just allow use of, "external" definitions in vocab terms and yet we all - OGC, TC etc. - use external definitions and term lists all the time for fundamental things like UML, XML, OWL, HTML etc. I don't see how this is any different: there is a better set (several better sets) of UoM out there and UoM isn't OGC's core business, so those UCUM or QUDT sets aren't in competition with OGC. OGC should defer to them just as we defer to UML (OMG product) for class modelling and don't provide OGC class models.

[ghobona]

@cportele Are you suggesting that the OGC-NA should not recommend the use of definitions that it was set up to to control?

@nicholascar Please clarify. Are you revising your proposal to request redirecting OGC UoM URIs to QUDT?

[cportele]

@cportele Are you suggesting that the OGC-NA should not recommend the use of definitions that it was set up to to control?

@ghobona - I don't think this is going in a useful direction and we seem to start splitting hairs. Let me try again:

The primary role of the OGC-NA is "to ensure an orderly process for assigning URIs for OGC resources, such as OGC documents, standards, XML namespaces, ontologies." Of course, these resources are registered, because there is a need for them in the community and they will be used, at least that is the expectation at the time of registration. The resources are registered and published by the OGC-NA via the definition server to make the OGC resources more useful and simpler to use.

However, other organisations are publishing relevant and related resources, too, and OGC as a whole should consider or recommend the use of OGC or third-party resources based on the merit of the resources (including their governance) and not just because something is an OGC resource.

In the OGC API developments this is done a lot. We generally try to use externally-managed resources (by IETF, OpenAPI, etc) whenever it makes sense over (new or existing) OGC resources. In the Web API guidelines this is principle 1.

I hope this clarifies what I meant.

[ghobona]

@cportele Thanks for the clarification.

[nicholascar]

I concur with @cportele above and request that the NA decides the best way forward, from it's experience of whole-of-OGC requirements, regarding this particular case of UoM.

If the NA is able to recommend other UoM vocabs, which I think it is, then yes, I think the NA could apply redirects for those 11 UoM it has defined to the recommended UoM vocab. The OGC defined UoM are standard - ampere, candela, metre, etc. - and all have QUDT and other definitions (http://qudt.org/vocab/unit/A, http://qudt.org/vocab/unit/CD, http://qudt.org/vocab/unit/M) and redirects would ensure those URIs keep working but now lead to the recommended definitions.

This is all about picking the best Linked Data resources out there and then using them widely to increase standards' Semantic Web skill broadly!

In Australian government, we are likely to soon recommend that our government use URIs for licenses in data provided by an international source - the Open Data Initiative, Europe - because they have a large and well-modeled license collection and, after some negotiation, we trust their governance too. They have license definitions in ODRL which allows machine understanding of them, where as "native" license PIDs, including the OGC's Software License, do not lead to such semantic information.

I'll suggest the OGC model its licenses (that software one and the "document" one that appears in standards) in ODRL and add them to the ODI, Europe's pool, if this UoM initiative is successful.

[ghobona]

On 2021-06-17, the OGC-NA discussed a proposal to deprecate OGC Units of Measure (UOM) URIs and to use QUDT.org URIs in GeoSPARQL.

The background to the discussion is at https://github.com/opengeospatial/NamingAuthority/issues/80#issuecomment-863587536

OGC UOM URIs are those that have a base http://www.opengis.net/def/uom

The OGC-NA decided to delegate the issue of which UOM URIs to use in GeoSPARQL to the GeoSPARQL SWG to decide.

The GeoSPARQL SWG's decision will not bind other SWGs that are already using OGC UOM URIs.