URN or HTTP URI?

[smrgeoinfo]

OGC has switched from URN to HTTP URIs for their identifiers. See The case for HTTP URIs and OGC Name Authority.

HTTP URIs are pretty much the same in terms of user friendliness, and the URNs can be mapped to HTTP URIs in a straightforward way. The advantage of the HTTP URI is that they can be dereferenced using standard web architecture, and if the naming authority goes to the trouble, the identifiers can be dereferenced to provide useful information about the identifier scheme and the resource that is identified. This works better in the linked data world, and I'd recommend we use that approach.

[rsignell-usgs]

I guess since OGC is using HTTP URIs, we should also.
But when you see something like:
This resolves: http://www.opengis.net/cat/csw/2.0.2
This doesn't: http://www.opengis.net/cat/csw/2.0.1
does that mean that we should pester someone to get it to resolve, or do we say "well, it's really just a urn encoded as http, so it doesn't matter."

[rsignell-usgs]

@smrazgs, can you provide a CSV of what you would propose instead of:
https://github.com/OSGeo/Cat-Interop/blob/master/link_types.csv
I'd love to keep this moving and try implementing it in several geoportal servers we are working with.

-Rich

[tomkralidis]

Agreed, some examples would be valuable. Or a pull request which changes the csv.

[tomkralidis]

@smrazgs: questions:

1./ So what would the following e.g's look like as HTTP URI? :

• urn:ogc:serviceType:SensorObservationService:2.0.0
• urn:x-esri:serviceType:ArcIMS

2./ so would all these fall under http://www.opengis.net/def ? What about those from w3c, unidata, etc.? Should they be under their own domain (which may dereference/resolve at some point in the future?

[smrgeoinfo]

can't figure out how to generate pull request from my checkout, and can't synchronize from my checkout. I created a new page in the wiki with unformatted dump from an edited link_types.csv

[smrgeoinfo]

http://www.opengis.net/serviceType/sos/2.0.0

for the ESRI one, I'd try to figure out who invented it and probably stick with the URN. Its ESRI's mess.

[rsignell-usgs]

@smrazgs Is this the CSV you are suggesting?
https://github.com/OSGeo/Cat-Interop/wiki/link-types-csv-suggestion.
It doesn't use the http: URL syntax. I'm confused.

P.S. To submit a pull request, you can fork the repo on github, then mod your version and submit the PR easily.

[tomkralidis]

FYI I'd added a proposal example per http://lists.osgeo.org/pipermail/cat-interop/2014-March/000027.html at https://github.com/OSGeo/Cat-Interop/blob/master/link_types_vocab.csv for review/comment.

[rsignell-usgs]

Tom,
Thanks for putting up the URL-style CSV file!

A few questions:

1. The link_type URLs in column 1 do not yet resolve to the redirects in column 3 yet, right?

I tried:
http://osgeo.org/vocab/service/ogc/csw/2.0.2
http://www.osgeo.org/vocab/service/opendap/opendap/2.0.0

and got "page not found".

1. Why http://osgeo.org/vocab/service/ogc/csw/2.0.2 for CSW instead
   http://www.opengis.net/cat/csw/2.0.2 found in OGC table 69:
   https://github.com/OSGeo/Cat-Interop/blob/master/csw_2.0.2_table_69.md and which already resolves?

[tomkralidis]

@rsignell-usgs FYI the links are just OSGeo scoped links and are not meant to necessarily resolve (although they could). All they are are opaque identifiers that happen to look like URLs.

Once we put a vocabulary resolver (as I proposed on the mailing list), then these can resolve accordingly.

[smrgeoinfo]

a resolver is good! Since they are URIs and the application will use string matching to determine identity, they only really need to resolve for people, not the machine use case

[mhogeweg]

if we're creating a single list, I would not start with synonyms that resolve to another URL.

a big 👍 to dereferencable URI that resolve to a description of (in this context) the type of resource. imho these should be maintained by the organization that defined the type of resource. since we defined some of the ones we use, we chose the urn we used.

we need to distinguish the type of resource and the format of the response (media types). an OGC WMS typically returns a png or other image format. a WFS returns an XML but could also return a geopackage or csv, etc.

[dpsnowden]

To piggyback on @mhogeweg 's comment, I'm running in to difficulty distinguishing the type of resource we are referring to. We're trying to index SOS services in Geoportal (we create an ISO record and load in Geoportal as an intermediate step). We're using a version of the 52N service which actually implements several different interfaces to one SOS v1.0 service. For example, the following URLs all could be considered interfaces to the v1.0 SOS service. (This references another issue ioos/catalog#41)

[{'scheme': 'urn:x-esri:specification:ServiceType:distribution:url',
   'url': 'http://sos.glos.us/52n/sos/json'},
  {'scheme': 'urn:x-esri:specification:ServiceType:distribution:url',
   'url': 'http://sos.glos.us/52n/sos/pox'},
  {'scheme': 'urn:x-esri:specification:ServiceType:distribution:url',
   'url': 'http://sos.glos.us/52n/sos/soap'},
  {'scheme': 'urn:x-esri:specification:ServiceType:distribution:url',
   'url': 'http://sos.glos.us/52n/sos/kvp?'},
  {'scheme': 'urn:x-esri:specification:ServiceType:download:url',
   'url': 'http://sos.glos.us/52n/sos/json'},
  {'scheme': 'urn:x-esri:specification:ServiceType:download:url',
   'url': 'http://sos.glos.us/52n/sos/pox'},
  {'scheme': 'urn:x-esri:specification:ServiceType:download:url',
   'url': 'http://sos.glos.us/52n/sos/soap'},
  {'scheme': 'urn:x-esri:specification:ServiceType:download:url',
   'url': 'http://sos.glos.us/52n/sos/kvp?'}],

This feels like one of those cases where the url is referencing both interfaces and responses. But, in all four cases the syntax of the client server interaction is different as well as the response format. The pox and kvp should have the same output format and the soap should be almost identical but for the addition of the SOAP wrapper. The json output is, well, json.

Are we asking too much of these URI's?