Define standard identifiers for OGC (and other) resources.

[pvretano]

This is a branch of issue #13 .

There is a need to define standard identifiers for OGC resources and perhaps other resources too. Some work has already been done in this area both inside and outside the OGC. The following source material is a starting point:

• https://portal.opengeospatial.org/files/?artifact_id=58896&version=1
• http://docs.opengeospatial.org/per/16-043.html
• https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv

During the 24-FEB-2020 teleconference the issue of governance arose. This list of standard identifiers should be easily maintainable. The suggestion was made that a document maintained on github might be a good approach. There was also a discussion about the fact that the OGC Naming authority would need to be involved.

[mhogeweg]

easily maintained would not exclude good governance. who 'owns' this list and approves additions/modifications?

[dr-shorthair]

This what OGC-NA does - @rob-metalinkage @ghobona

[pvretano]

@mhogeweg Dunno. We need to speak with the OGC Naming Authority to see (a) if they would be the "owners" of this list (makes sense to me) and (b) how they would propose to manage it. As mentioned, there have been several attempts both in and of the OGC in this direction and in today's SWG discussion it was agreed that perhaps we can push the effort into a more formal posture addressing the ownership and maintenance issues. Like many current efforts in the OGC API domain (e.g. CQL, etc.) we can start the work of getting the list defined in this SWG and then hand it off to the appropriate owner for ongoing maintenance. I have already contacted OGC to give them a heads up about this issue.

[pvretano]

@dr-shorthair Actually I contacted Gobe and Scott. I'll forward the message to Rob as well.

[rob-metalinkage]

hi all,

as it happens I am aiming to take an analysis of the current heterogeneity to a side-meeting at the OGC staff retreat in March. This is good timing to get community pull on the thread!!!

I am keen to do multiple things here:

1. Find all the legacy identifiers in use and cross-reference them in the definitions server (a semantic resource) (sameAs relationships) - and identify canonical URIs for each resource type (if possible)
2. Enrich the model by declaring other relationships between specifications (profileOf, supercedes, uses, related to) and links between docs and Conformance Classes
3. enrich the model to declare relationships between specifications and implementation resources (doc, various XSD, JSON, RDF schema, validation rules, ERs
4. Seek to auto-update from any existing maintained systems
5. Push information out to spec-ref and other systems
6. Improve tooling so new specs use canonical links
7. Explore updating legacy links to use canonical URIs
8. Capture URI derferencing behaviour for canonical URIs to point to the richer information
9. Capture URI dereferencing for non-canonical URIs to point to canonical resources.

I have started a few experiments here:
https://github.com/opengeospatial/NamingAuthority/tree/master/annotations

where i ran into issues about what the actual objects that have relationships are.. and decided I should look at acquiring the ConformanceClass identifiers.

Which leads me to the key concern here: a list of identifiers ( a register) must have a semantic model (i.e. we know what types of things we are registering and how to determine if things fit into that model and whether instances are different from each other). Use ISO 19150 roles to determine who does what - I'll play "Registry Manager" - i.e. look after infrastructure for you, but someone needs to be "Register Manager" - look after content. OGC-NA as "Register Owner" makes sense to me, but its not delegated or resourced to do this currently - lets push on this and see what happens.

Simon drafted an unofficial model of modular specifications - we need to actually model that AND the types of resources we want to identify AND the types of relations between them. I'm happy to take on curation of that model - but is is something we should collaboratively develop? Or just OGC interanal infrastructure and policy design we develop and inform about?

[rob-metalinkage]

Couple of other things:
http://www.opengis.net/def/serviceType
http://www.opengis.net/def/objectType/
exist... but contents do not match those URIs in 14-013r1

http://www.opengis.net/def/serviceType/ogc/0/wfs

we have some urn: identifiers as object notations... but i'm not finding.

If a document is available with ids and cross-references I'm very happy to either restructure it as RDF to load into the defs server to enrich things there, or to wrtie a script to ingest it if you want to update it in the original form.

[ghobona]

@pvretano

OGC Naming Authority policies can be found on this page https://www.ogc.org/standards/na

Start with OGC 09-046r5.

The registered items can be browsed and searched at http://www.opengis.net/def/

[pvretano]

28-DEC-2020: Assigned to Tom Kralidis. Tom will try to compile a list of standard identifiers for all the basic resource types (features, coverages, etc.) and also some of the legacy stuff like W*S services and the data those services operate on. We all need standard relation types as well (e.g. renderedby, offered, etc.).
ANOTHER APPROACH: define how code lists are handled in the catalogue an let each community decide what identifiers to use .... although, that still means that OGC, as a community, should come up with its set of codes/identifiers.

[tomkralidis]

I've broken this into two paths/issues.

1. OGC Definitions Server updates:

Services

For reference, existing identifiers in the NA:

• http://www.opengis.net/def/serviceType/ogc/csw
• http://www.opengis.net/def/serviceType/ogc/wms
• http://www.opengis.net/def/serviceType/ogc/wfs
• http://www.opengis.net/def/serviceType/ogc/wcs
• http://www.opengis.net/def/serviceType/ogc/wps
• http://www.opengis.net/def/serviceType/ogc/sos

Full list is at http://www.opengis.net/def/serviceType/ogc/

Possible new identifiers:

• http://www.opengis.net/def/serviceType/ogc/OAFeat
• http://www.opengis.net/def/serviceType/ogc/OACov
• http://www.opengis.net/def/serviceType/ogc/OARec
• http://www.opengis.net/def/serviceType/ogc/OAMaps
• http://www.opengis.net/def/serviceType/ogc/OAStyles
• http://www.opengis.net/def/serviceType/ogc/OATiles
• http://www.opengis.net/def/serviceType/ogc/OAProc
• http://www.opengis.net/def/serviceType/ogc/EDR

Relation types

Existing list at http://www.opengis.net/def/rel/

Possible new relation types:

• from OAFeat: http://docs.opengeospatial.org/is/17-069r3/17-069r3.html#_link_relations
• form OAProc: https://htmlpreview.github.io/?https://github.com/opengeospatial/wps-rest-binding/blob/master/docs/18-062.html#_link_relations
• from OACov: https://htmlpreview.github.io/?https://github.com/opengeospatial/ogcapi-coverages/blob/master/19-087.html#general-overview
• from OATiles: https://htmlpreview.github.io/?https://github.com/opengeospatial/ogcapi-tiles/blob/master/core/standard/OAPI_Tiles.html#_link_relations
• from OAStyles: describedBy, stylesheet

2. Allowing codelists from other communities

In the same manner as keyword thesauri in traditional metadata, metadata providers should be able to provide values which are coming from a given codelist. An example can be found at https://github.com/wmo-im/wcmp-codelists, which could be used beyond, say, properties.keywords/properties.keywords-codespace). Other properties could include properties.type and properties.associations[].type. In this sense, should we allow a catalogue to advertise its codelists and where they are used, or do we delegate this to community profiles?

[pvretano]

25-JAN-2021: @tomkralidis will review what is in the definition registry with regard to identifiers for OGC resources and link relations types and propose additions via normal OGC NA procedures.

[pvretano]

SWG MEETING 08-FEB-2021: @tomkralidis no update from last comment but is in queue.

[tomkralidis]

Possible additions based on conformance class names:

• http://www.opengis.net/spec/ogcapi-records-1/1.0
• http://www.opengis.net/spec/ogcapi-features-1/1.0
• http://www.opengis.net/spec/ogcapi-coverages-1/1.0
• http://www.opengis.net/spec/ogcapi-maps-1/1.0
• http://www.opengis.net/spec/ogcapi-tiles-1/1.0
• http://www.opengis.net/spec/ogcapi-styles-1/1.0
• http://www.opengis.net/spec/ogcapi-processes-1/1.0
• http://www.opengis.net/spec/ogcapi-edr-1/1.0

Questions:

• should we register the style above or in the style http://www.opengis.net/def/serviceType/ogc/OAFeat? Do we ask NA for recommendation or do we decide/propose?
• link relations: do link relations not already in IANA get proposed to IANA? If yes, then would this be enough (so as not to duplicate them in NA)?

[rob-metalinkage]

Its worth thinking about what the OGC definitions server should say about the entity being defined.

at the moment this is very sparsely populated, however the plan is to link these entities together a lot better.

Resource types of interest here are:

1. Service type
2. Conformance class
3. Requirement (+ tests using the OGC modular spec - but lets leave that out)
4. Specification document (external URI)
5. document number
6. document form
7. schema and other implementation resources

We have a situation where a wide range of resources, and identifiers and resource locations co-exist - and may be used in citations. Somewhere we need to make statements about these resources, including the relationships between them.

in the definitions server we are using the OGC document number as the basis for identifying the specification - e.g.

http://www.opengis.net/def/docs/17-069r3

(This is because past documents have inconsistent use of "external URI" and the OGC document register is automatically synchronisable with the definitions server. If we have statements about this entity this is a good place to start from. Note that Service Type v.s. specification is a tricky thing and will need to be untangled from a user's point of view - its not a 1:1 - ServiceType is more abstract than specification or document, and may be defined by a succession of document versions. What we should be explicit about is what things should be claiming conformance to in the wild - conformance classes need to be richly enough linked to all the other resources to act as a valid entry point (landing page) for the definitional landscape a user needs to operate with, - and hence we need to retrofit conformance class concepts to older specifications.)

e.g. Conformance classes have relationships such as core and extension dependencies, based on the OGC modular specification model. They may also have dependencies on external standards that don't follow that model. What are the relationships between Conformance classes and Service Type?

so please make sure that these fundamental relationships needed to make sense of any citation are included in submissions to OGC-NA - either in a spreadsheet (CSV) form or as SKOS format data. A proposal for a canonical data model for all this stuff is in preparation.

[pvretano]

At the JUN-2021 member meeting there was a discussion about building a geospatial taxonomy give Ingo S. and Topio Networks. This might something that is relevant to this issue.

[pvretano]

09-AUG-2021: @tomkralidis will add an informative annex with a list of type values.

[tomkralidis]

PR in #145 for consideration.

[rob-metalinkage]

Hi all

I think its a good idea to try to formalise the relationship between /def/service-type and /spec - since Conformance Classes in specifications are the normative form for specifying a service behavour, the linkage to service type should be explicit.

The only documentation I inherited for the service types is: " rdfs:label "Service Types register" ;"' :-)

There is an example here: https://www.ogc.org/ogcna with no additional information

There appear to be no specific policies here: https://www.ogc.org/standards/na

The way forward is to define ISO 19135 roles (who owns this register, who may submit, who manages it) - then work with me to add the details.

This one needs a policy based on architecture model of how the register is intended to be used. I know the INSPIRE references some of these entries.

Is the service type vocabulary a taxonomic model of service types that individual specifications should be registered in, and if so using what identifier? As a straw man perhaps the "leaf nodes" of this taxonomy should be versioned /spec conformance classes?

I stand by ready to implement what is deemed necessary - but the membership needs to determine what that is.

[ghobona]

@rob-metalinkage Attached are the mappings from service type to SWGs.

OGCBodyOfKnowledgeMappings_Extract_20210920.xlsx

@pvretano There is a policy on construction on the identifiers of OGC API Standards.

Please see Clause 6.8 of the policy document Naming of OGC API Standards, Repositories & Specification Elements.

For OGC API - Records, the URI is http://www.opengis.net/def/interface/ogcapi-records

We have not enabled the URI yet because it is not yet a standard. Once the TC votes to approve the standard, the risk of a name change is diminished, so that is when we aim to enable the URI.

[pvretano]

Related issues ... part of an overall requirement across the OGC.
opengeospatial/ogcapi-styles#30
https://docs.opengeospatial.org/DRAFTS/17-083r3.html#parts-of-data-type-code-enum
@tomkralidis FYI this issue has greater implications than records but since records is usually the starting point for discovering these resources we have the most pressing need to (a) identify what are the OGC resources (both old and new) and (b) assign identifiers to them via the OGCNA. See @ghobona comment above about the policies.

[tomkralidis]

Update from SWG meeting 2021-11-15: agreed/consensus to merge via #145. We still need to work through the OGCNA processes.

[pzaborowski]

As discussed recently I'm linking the slidedeck from the Dec21 Conceptual Modeling MM:
https://portal.ogc.org/files/?artifact_id=99630
It documents some of the recent efforts on the Definition Server data ingestion as well as propose the PoC Google Spreadsheet tool to provide and manipulate directly into the Server (dev environment for the moment.
there is a link to the spreadsheet under https://portal.ogc.org/index.php?m=projects&a=view&project_id=82&tab=2&artifact_id=99495

There were some changes in the back processes recently and wanted to make them stabilised.
The next steps are to play with the tool and curate already ingested specifications, encourage you to find a way to keep data updated and extend to other specification elements. The priority is to be defined.

[pvretano]

31-MAR-2023: Had a long discussion about this issue. The conclusions were as follows:

1. For now the values to use for the properties.type member will not be specified in the standard.
2. The standard will include informative text to say that the value of properties.type should be taken from some formal vocabulary defined by some organization (e.g. ISO) or community of interest (e.g. WMO).
3. For catalogues that describe OGC resources (e.g. WMS, WFS, OAFeat, Styles, Symbols, etc.) we will direct people to the vocabularies available in the definition server. Basically, if you want to describe a WMS (for example) the value of the type identifier would be http://www.opengis.net/def/serviceType/ogc/wms.

@tomkralidis will add this text.

[tomkralidis]

PR in #225. Note that the OGC API identifiers put forth in the PR are in the absence of same in the OGC Definitions Server (cc @ghobona).

[pvretano]

07-APR-2023: @tomkralidis added content to the specification about identifiers (#225) which was merged at the last SWG meeting.