Finish identifier class

[roomthily]

Merging some issues into one comprehensible thing.

Remaining tasks:

• [x] Generate a URN based on cat-interop/esip discussions (see #19, #13)
• [x] First, sort out a solid URN (or trace through the issues, mailing list posts, etc, for existing work)
• [x] Finish testing the prioritized list (check filters for accuracy! across protocols and services)
• [x] Finish adding version filters for prioritized list (if version available)
• [x] Add the "is dataset" check (see #14)
• [x] Add "is metadata" check (and by metadata, we mean an actual ISO or FGDC record only) No, we need it to handle the internal standard (oai-pmh:dc or csw:iso, etc).
• [x] Add additional error filters to the prioritized list (see also #22)
• [x] Build out the full service identification config (for metrics)
• [x] Add some service type (metadata v dataset v service v ...) to the configs (re: URNs)
• [x] Make sure the URN can be generated by the Identity class
• [x] Verify that the version check can handle multiple options (may have some xpath option or a default value, depending, not oddly, on the version) IT DOES NOT! it should be good now. see https://github.com/b-cube/semantics-preprocessing/commit/f89d8c44f0b1b8f78e72986f40ede874990129b1
• [x] Add CSW to the priority list (this one can be awkward with the nested response - it's CSW with blocks of some other XML-based metadata like ISO, DC, etc, and so those namespaces are present).
• [x] Revise the opensearch filtering for opensearch but not ATOM?
• [x] Update version check for checking both default/checks option.

There is some known wonkiness in the yaml configuration (list v dict) so that should also be added to the list.

Regarding the CSW situation (and this applies also to oai-pmh at a minimum), we may need to switch from a binary check based on ordering of the services in the config to some scoring function - 67% likely to be Service A or something. I think we're good for now as long as we're careful about the filters and the secondary "is dataset?" or "is metadata?" can help mitigate this problem.

[roomthily]

On Version Identification

In some cases, the service response will have an explicit version element (root.attrib['version'] for many OGC responses, for example). Sometimes we don't have that or we have an implied version (OpenSearch namespace URI or THREDDS catalog URI). So we have two definitions - some default value for the URI-type situations (if match, version='1.1') and a pull from the response.

  versions:
      defaults:
        ors:
          - type: simple
            object: content
            value: 'http://a9.com/-/spec/opensearch/1.1/'
            text: '1.1'

    versions: 
      checks:
        ors:
          - type: xpath
            # fully qualified xpath which is lovely and short here
            value: '@version'

Related commits: https://github.com/b-cube/semantics-preprocessing/commit/e48dc058bb3e52ef841dcf3c56cfa0af57bc7cbf

https://github.com/b-cube/semantics-preprocessing/commit/f89d8c44f0b1b8f78e72986f40ede874990129b1

[roomthily]

On URNs

Based on the OSGeo/geopython/ESIP Discovery work.

consider

• urn:{protocol}:{service}:{version}
• urn:{type}:{protocol}:{service}:{version}
• urn:{type}:{protocol}:serviceType:{service}:{version}
• {protocol}:{service}-{version}-{access: http|ftp|etc}-{method as dash-delimited string}

Of course, this all assumes that you have some service response that is well-contained, which we do not. WxS GetCapabilities describe enough to get at the data service so could be classified as both service and dataset (specific to this project, mind).

[roomthily]

For the OpenSearch vs. ATOM with OS elements:

<feed xmlns='http://www.w3.org/2005/Atom' 
    xmlns:georss='http://www.georss.org/georss' 
    xmlns:opensearch='http://a9.com/-/spec/opensearch/1.1/'>

where we're just pinging for the namespace URI without understanding its relationship in the XML, ie it is not the default namespace and there are other namespaces present.

[roomthily]

It is catching OpenSearch errors :+1:

[roomthily]

High priority services are running reasonably. Everything else will be a discrete bug. Cheers.