Policy on resolving namespace URIs and URI fragments?

[dblodgett-usgs]

Noting that many URIs in the opengis.net space either don't resolve anything or atleast don't resolve anything useful, would it be worth putting in place a rule that these should resolve to something that helps a user get to nested sub-resources and/or to a relevant parent resource to understand what the URI is about?

e.g. http://opengis.net http://www.opengis.net/spec/ http://www.opengis.net/spec/ogcapi-features-1/ http://www.opengis.net/spec/ogcapi-features-1/1.0 (shows up as a clickable link in the API Features spec) http://www.opengis.net/ogcapi-features-1/1.0/sf (also shows up as a clickable link in the API Features spec)

This was discussed on a recent OAB call and the suggestion was to raise it with the NA.

[ghobona]

We have an on-going activity to extract URIs of specification elements from published OGC standards. The activity has previously been conducted in a private repo, however in response to this Issue#58 the code and mappings have been moved into this public repo.

The code folder contains the python scripts.

The specifications folder contains the specification documents in text or html format.

The mappings folder contains the CSV files linking the URL of the specification documents to the URI of the specification elements.

Once the URIs have been extracted, they are then used to configure the server at opengis.net - which makes them resolvable.

So we are moving the material into this public repo, with the hope that OGC Members can join in the effort to extract the URIs.

[ghobona]

Note that we considered using text extraction tools such as Apache UIMA or Baleen but ruled the tools out because some of the URIs are formulaic.

[rob-metalinkage]

We should be able to put all the relevant details into the definitions server, and we have a much more flexible option for a presentation UI in progress

we need a spec for what additional forms of machine readable fragments may be required - for example things which are OAS based perhaps should support an OAS view as an optional link,

I need to do some experimentation to work out what needs to be done to allow the defs server redirection capability to listen on multiple paths - currently it only gets /def - but this should be achievable.

[ghobona]

@rob-metalinkage

The URIs are supposed to resolve to the relevant specs. See OGC API - Features and the configured mappings.

[dblodgett-usgs]

What about URI fragments? and namespace URIs that aren't supposed to link to particular sections of specs?

[ghobona]

@dblodgett-usgs If I understand your question correctly, then yes, in order to extract the URIs we have to extract the URI fragments and namespaces also. Remember that in several specifications, the namespace is introduced once in the Conventions section and then all other URIs are specified as 'fragments' relative to that namespace.

[dblodgett-usgs]

It's not about extracting URIs from specifications. It's about URIs like: http://opengis.net/ or: http://www.opengis.net/spec/ giving you something useful.

You should put it on the SWGs to ensure that URIs in their documents are resolvable. Building software to search for URIs isn't a good use of time, IMHO.

[ghobona]

@dblodgett-usgs I agree with both points.

[ghobona]

@dblodgett-usgs I will discuss the topic with the SWG and DWG representatives at the next OGC-NA meeting. This will most likely be a mid-quarter telecon, so that they can discuss with their SWG/DWG colleagues at (or before) the next OGC Member Meeting.

[ghobona]

Pull Request https://github.com/opengeospatial/NamingAuthority/pull/117 created to fix this issue.

Clause 6.3 added to require descriptive information returned at segments along the URI of specification elements.