OGC Definition server base URI for O&M codeList

[sgrellet]

In the OGC def server there are already non versioned entries but the pattern for the rest is not clear for us.

• A°/ http://www.opengis.net/def/observationType/ -> no reference to the 'source' spec
• B°/ http://www.opengis.net/def/ogc-om/ -> with a reference to the 'source' spec

Is our assumption correct to use approach A°/ as a starting point/rationale to OM V3 related codeLists ?
We have requirements for collectionType that need to point out to specific codeList entries (ex : testing on the entry 'homogenousObservationCollection')

[ilkkarinne]

Continuing on the discussion held in the SWG meeting today.

I completely agree with @sgrellet and @dr-shorthair on getting rid of the version and specification specific URI path parts for the model concepts, including in the code list case the concepts used as codelist values. However, I think we may want to consider a namespacing the ids of the named collections of concepts which are used as vocabularies for particular code list classes included in the v3.0 UML model with the specification that defines it:

ObservationTypeByResultType tag vocabulary=http://www.opengis.net/def/om/observationTypeByResultType

The code list entries would then refer to non-versioned concepts (chosen set of observation classifications in this case):

• http://www.opengis.net/def/TruthObservation,
• http://www.opengis.net/def/CountObservation,
• http://www.opengis.net/def/TemporalObservation etc.

[ilkkarinne]

Based on the SWG discussion again I interpreted that you do not see a reason to distinguish the model concepts realized using soft-typing and codelist entries and the ones realized as UML classes on the OGC Definitions Server. Example:

http://www.opengis.net/def/TruthObservation and http://www.opengis.net/def/ObservingProcedure would both be registered as O&M (OM&S) concepts. Is this correct?

[ilkkarinne]

Related note: these concept definitions would not be the same things as the specification requirements defining the concepts in the context of the specification, such as http://www.opengis.net/spec/om/3.0/req/obs-cpt/ObservingProcedure, although there is of course a tight coupling between the two: The requirement states that the ObservingProcedure class included in this particular specification version SHALL be a representation of the concept named as http://www.opengis.net/def/ObservingProcedure.

[ilkkarinne]

Please review and comment the draft SKOS collections and member concepts to act as vocabularies for the following codelists:

• CollectionTypeByMemberCharacteristicsSemantics
• ObservationTypeByResultType and
• SampleTypeByGeometryType

@ghobona: If the SWG is ok with these IDs and definitions, would these files be in a format that the OGC-NA can process and, as the result, publish in the OGC Definitions Server at http://www.opengis.net/def/? I have used the SKOS concept JSON-LD alternative profiles as the base and made the edits manually.

[cportele]

@ilkkarinne

The use of http://www.opengis.net/def/foo-bar is not consistent with the OGC policy for the "def" scheme. See https://docs.opengeospatial.org/pol/09-048r5.html#_production_rule_for_specification_element_names.

The pattern must be http://www.opengis.net/def/{definition-type}/{authority}/{version}/{code} where {definition-type}and {authority} have to be registered first, too. {authority} will be OGC in this case.

[dr-shorthair]

Yes, I did mention this in the meeting yesterday.

I think the OGC policy (which I was responsible for writing down) is overcomplicated, and inherits some assumptions about what information needs to be in a URI path that I now believe are misplaced*. But it is the policy.

*Implying relationships through the URI structure is bad practice. Relationships should be explicit, not implicit. There may be a governance argument for protecting a 'URI-space' but the OGC policy makes that too granular. The policy should be updated IMHO.

[cportele]

I think that the URI pattern design was mainly driven by the need to ensure uniqueness of the URIs, which is why authority was added to support cases like the multiple CRS registers. I agree that it would be a good idea to simplify the policy for items that will always have OGC as its authority and do not need a version. I still think that it would be a good idea to keep {definition-type} to distinguish the type of the registered item. The sub-path that follows will depend on the type. For example, I assume that for CRS the current pattern with the authority would continue to be used.

[sgrellet]

I concur with Simon's opinion and above proposals to simplify this when feasible

This activity is a semantic definition one.
It's not a common good practice to version the URI of a concept.

For example, even if some definitions of core O&M concepts/classes have been polished, those concepts/classes remain the same (their intent is the same). There is thus no reason to change their identity.

2 examples outside OGC def

• http://www.w3.org/ns/dcat#Dataset : no mention of version number in the URI
• geoloexica concept for 'observation procedure' : https://isotc211.geolexica.org/concepts/1305/
  Current content is based on 19156:2011. I assume the 'pointer' will remain the same and the definition updated accordingly (hopefully with some mechanism to still access the former one)

Simplifying this will also help others OGC SWGs working on defining semantics

[ilkkarinne]

While I think it is good to challenge the OGC policy in constructing the URIs, I do not think we have the time to have this discussion finished by the 19156 DIS submission time.

@cportele: are the existing definition types available somewhere as a list?

As alternatives to propose to NA for the codelist collections I currently see:

• http://www.opengis.net/def/codelist/OGC/1.0/observationTypeByResultType or
• http://www.opengis.net/def/codelist/OGC/observationTypeByResultType or
• http://www.opengis.net/def/codelist/observationTypeByResultType

For the concepts forming the codelist entries (replace concept with a suitable existing definition type):

• http://www.opengis.net/def/concept/OGC/TruthObservation or
• http://www.opengis.net/def/concept/TruthObservation

[cportele]

are the existing definition types available somewhere as a list?

In addition to the documents they should be at http://www.opengis.net/def/def-type, but that collection is empty. I guess, because the definition server is a work-in-progress.

[KathiSchleidt]

A short note on to version or not to version. While I'd prefer the simplicity of no versions, I would like to know where the statement "It's not a common good practice to version the URI of a concept." comes from.

As long as are concepts are VERY stable, think we can get along without versioning. However, if there is ANY chance that the meanings will be "polished", e.g. the intent tightened or shifted, so the new definition only applies to a part of the original definition, we'd have to define a new concept if we cannot version. Otherwise, we run into madness as is common "good practice" in taxonomy, where they eternally split and lump species while retaining names, then get annoyed as you have data pertaining to different concepts (e.g. with and without the split) referencing the same taxon.

Btw - does anybody understand why the SWEET ontology does not provide references to the older versions?

[ghobona]

All, the proposal with the versioned URIs looks good (e.g. http://www.opengis.net/def/codelist/OGC/1.0/observationTypeByResultType).

@ilkkarinne When you are ready please create a GitHub Issue on the NamingAuthority repository, with links to the JSON-LD or TTL files.

[ghobona]

@ilkkarinne One thing to note is that we generally do not state that an entry is a concept in the URL.

Also the positioning of the /codelist segment, although it meets the constraints in the policy, for other specs we placed it after the version. This then enabled us to place the codelist name after the codelist segment, and the code value after the codelist name.

Once you create the GitHub Issue on the NamingAuthority, I will work with @rob-metalinkage to revise the proposal. So you might need to revise the URIs thereafter.

[dr-shorthair]

IMAO it would be helpful to stop talking about 'versioned' URIs, and rather refer to 'different' URIs.
There is no need to mint a different URI if the referent is the same.
OTOH if the thing (e.g. concept) has changed enough to need a new identifier (URI) then just mint a new identifier.
But IMAO again this doesn't happen often with controlled vocabularies, so it is best not to muddy the waters with version numbers, or to use a number in a special field as the mechanism to change the URI.

[ilkkarinne]

@ghobona and @rob-metalinkage: would the following seem acceptable then by the OGC-NA policy?:

• http://www.opengis.net/def/OGC/1.0/codelist/CollectionTypeByMemberCharacteristicsSemantics as the codelist entry (SKOS Collection)
• http://www.opengis.net/def/OGC/SummarizingObservationCollection as an item of the codelist (SKOS Concept, member of the SKOS Collection above)

[ghobona]

From clause 6 of the Definitions policy.

The generic syntax for OGC http URIs is

URI = "http://www.opengis.net/" OGCResource "/" ResourceSpecificPath

The following ABNF adapted from [IETF RFC 3986] provides some basic definitions required in the rest of this document.

segment       = *pchar
segment-nc    = *pchar-nc
segment-nz    = 1*pchar
segment-nz-nc = 1*pchar-nc
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc      = unreserved / pct-encoded / sub-delims / "@"
pct-encoded   = "%" HEXDIG HEXDIG
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved      = gen-delims / sub-delims
gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                / "*" / "+" / "," / ";" / "="

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" ; 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 )

The first proposed URI has the definition type on the right hand-side of the version, when it should be the first segment after the /def/ segment.

The second proposed URI is missing a version number.

Once you have revised the URIs, please remember to create a GitHub issue on the Naming Authority repository so that the proposal can be formally taken through the OGC-NA process.

[ilkkarinne]

Hi @ghobona: I seem to have misunderstood your earlier comment on 4th June stating "Also the positioning of the /codelist segment, although it meets the constraints in the policy, for other specs we placed it after the version."

I had it as http://www.opengis.net/def/codelist/OGC/1.0/observationTypeByResultType and interpreted your comment to mean that the codelist part should come after 1.0. If the earlier version was correct what did you mean by "placing the codelist segment after the version"?

[ilkkarinne]

Regarding the versioning or "naming" the concepts (being used as code list items here), the O&M SWG has yet been unable to reach conclusion on whether we would like to have

• the version number in the URI (concerns about slightly changing the definitions of the concepts although the general semantics would remain the same), or
• no version number in the URI (propose a deviation from the OGC Definition policy) as referent concept is non-versionable (either the same or different concept, but not a version of the concept)

[ilkkarinne]

Reading the Definition policy ABNF considering the version part we should use "0" for "un-versioned names", thus the following would be formally correct (disregarding the missing definition-type for "concepts" used as code list items):

• http://www.opengis.net/def/OGC/0/codelist/CollectionTypeByMemberCharacteristicsSemantics (codelist)
• http://www.opengis.net/def/OGC/0/SummarizingObservationCollection (codelist item)
• http://www.opengis.net/def/OGC/0/HomogenousObservationCollection (codelist item)

Note that I think we do not want to have the items registered as http://www.opengis.net/def/OGC/0/codelist/CollectionTypeByMemberCharacteristicsSemantics/Summarizing as the Summarizing Observation Collection is a concept on it's own and may be referenced outside the scope of this particular codelist. Or am I correct @KathiSchleidt, @sgrellet ?

[ghobona]

Hi @ilkkarinne , apologies, I should have highlighted on the June 4th comment that it meets the constraints in the policy. My response was indeed unclear.

http://www.opengis.net/def/codelist/OGC/1.0/observationTypeByResultType follows the policy, so please leave it as it is.

[ghobona]

Regarding the version number, please follow the policy.

[ilkkarinne]

Updated code list and item definitions as SKOS Collections and Concepts now available at

• CollectionTypeByMemberCharacteristicsSemantics
• ObservationTypeByResultType and
• SampleTypeByGeometryType

All of these are now using the "un-versioned" version numbers (/0/)

[ghobona]

That's great, please create an Issue on the NamingAuthority repo proposing the registrations. You may cross reference this discussion on the new Issue in the NamingAuthority repo.

[ilkkarinne]

Issue created in the NA repo for this now.

@ghobona: Do you think this could still fit on the OGC NA SC agenda on Thu 17th June?