Gather community feedback on ServiceType list

[rsignell-usgs]

Steve Richard (@smrazgs), you mentioned on the 2014-02-21 ESIP documentation call that perhaps we should not use the "urn:..." style for ServiceType shown on this strawman ServiceType.

Can you elaborate?

[smrgeoinfo]

I definitely plan on pitching in here. I was looking at the CSW 2.0.2 spec yesterday and notices Table 69--URIs for well known metadata standards, which includes http URIs for all the ogc service capability documents... I'll add it on the a page here.

[tomkralidis]

@rsignell-usgs thanks. FYI we need to update the initial URN list.

If we do go the URN route, then we should probably cite something x-osgeo (or osgeo if IANA registered) for defs that we create ourselves.

[dpsnowden]

Whether this is a URN or URI scheme aside, who will manage the controlled vocabulary being developed? Does this live on as a text file in a github repo or is there a better place like a GML dictionary on an OGC server or a SPARQL enabled vocabulary service endpoint? We register most (all? hopefully) controlled vocabularies at the Marine Metadata Interoperability Ontology Registry and Repository.

@graybeal may have some thoughts on whether MMI is a reasonable place or if it's inappropriate.

[tomkralidis]

@dpsnowden good points. I guess that depends on how far this gets formalized. At the least, I'm thinking a JSON file on GitHub will provide a helper for implementations.

[smrgeoinfo]

I'm thinking that the steward of the service protocol and profiles ought to assign URIs to use as part of defining the protocol/profile. OGC has sort of started down this road, but still don't have a registry AFAIK that can be accessed via vocabulary service

[tomkralidis]

There is http://urn.opengis.net/ (which points to CSIRO), but honestly this seems a bit magical :)

[smrgeoinfo]

Aha-- thats the CSIRO SISSVoc (spatial information services stack) vocabulary server, I should have guessed Simon Cox had deployed the OGC URIs there. The idea is that its a URI dereferencing service-- basically an endpoint to which you sent a URI as a parameter, and it provides you some representation (with some possible content negotiation) of what that string is supposed to identify (as far as that server knows).

[rsignell-usgs]

I pulled out the table 69 that Steve mentions from the CSW spec
https://github.com/OSGeo/Cat-Interop/blob/master/csw_2.0.2_table_69.md
Is it useful?
I see that it lists http: style addresses.

[rsignell-usgs]

Gang,
Trying to come up to speed here.

So if I take one of the CSW Table 69 URIs like http://www.opengis.net/wms and drop it into my browser, it resolves to: http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd

But if I try http://www.opengis.net/wms/1.1.0 it does not resolve to http://schemas.opengis.net/wms/1.0.0/capabilities_1_0_0.xml

I find this confusing. I kind of prefer the urn: approach because then we know it's just a namespace that doesn't resolve. But I guess in the cases that the url: approach resolves, that's useful?

What do others think?

I like Tom's pragmatic suggestion of getting going by using a common JSON or XML file here on Github. And then down the road we can use a more sophisticated approach. This would allow us to keep moving on our IOOS system-test without CSW-endpoint-specific code.

How about just using the geoportal "property-meanings.xml" file?

As a basis, we could start with the property-meanings.xml file from NGDC's geoportal (that I plucked from the geoportal-customizations.zip file found on NOAA's geoportal server page ) and just start adding and revising. Clearly, services like WCS need to be changed away from urns like "urn:x-esri:specification:ServiceType:wcs:url"

@amilan17, is this what NGDC is currently using or has it evolved?

@mhogeweg, how do you see the media-types list fitting in? I also wasn't clear on the overlap between this issue and the issue here: project-open-data/project-open-data.github.io#272

@ddnebert, are you okay with this approach?

-Rich

[tomkralidis]

@rsignell-usgs comments:

• I believe CSW Table 69 is in the context of CSW harvest ResourceType identification. Which we could leave for now to CSW

I've added an initial table at https://github.com/OSGeo/Cat-Interop/blob/master/link_types.csv with a companion Python script at https://github.com/OSGeo/Cat-Interop/blob/master/link_types_dumps.py that can dump the csv to JSON (this could also be extended to output XML, etc.).

The idea here is that the CSV would be the easy-to-manage resource and serialized for machine processing via build steps downstream. The link_type column would be what dct:references/@scheme or dc:URI/@protocol (or, say, their ISO equivalents) would be populated with.

The list is populated based on my experience of common link types (i.e. does anyone have a real live CORBA endpoint?) which we can build upon.

I think media types may be orthogonal, i.e. a WMS provides GetMap in, say, image/png, etc., so I would see media types as part of HTTP workflow. Whereas link types would be more along defining a vocabulary for use within a given metadata format.

[rsignell-usgs]

@jeffdlb and @malaustin, your input welcome here too.

[ddnebert]

I am okay with this approach, and just need to get the wording to put in
our metadata recommendations and eventually in the metadata tools that are
classifying services before they get harvested.

Doug.

Douglas D. Nebert
Senior Advisor for Geospatial Technology
FGDC Secretariat - Newport, Oregon Tel:+1 703 648-4151 Cell:+1 541 961-3149

On Thu, Feb 27, 2014 at 9:11 AM, Rich Signell notifications@github.comwrote:

Gang,
Trying to come up to speed here.

So if I take one of the CSW Table 69 URIshttps://github.com/OSGeo/Cat-Interop/blob/master/csw_2.0.2_table_69.mdlike
http://www.opengis.net/wms and drop it into my browser, it resolves to:
http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd

But if I try `http://www.opengis.net/wms/1.1.0' it does not resolve to
http://schemas.opengis.net/wms/1.0.0/capabilities_1_0_0.xml

I find this confusing. I kind of prefer the urn: approach because then we
know it's just a namespace that doesn't resolve. But I guess in the cases
that the url: approach resolves, that's useful?

What do others think?

I like Tom's pragmatic suggestion of getting going by using a common JSON
or XML file here on Github. And then down the road we can use a more
sophisticated approach. This would allow us to keep moving on our IOOS
system-test without CSW-endpoint-specific code.

How about just using the geoportal "property-meanings.xml" file?

As a basis, we could start with the property-meanings.xml file from NGDC's
geoportal (that I plucked from the geoportal-customizations.zip file found
on NOAA's geoportal server pagehttps://geo-ide.noaa.gov/wiki/index.php?title=ESRI_Geoportal) and just start adding and revising. Clearly, services like WCS need to be
changed away from urns like "urn:x-esri:specification:ServiceType:wcs:url"

@amilan17 https://github.com/amilan17, is this what NGDC is currently
using or has it evolved?

@mhogeweg https://github.com/mhogeweg, how do you see the media-types
list http://www.iana.org/assignments/media-types/media-types.xhtmlfitting in? I also wasn't clear on the overlap between this issue and the
issue here: project-open-data/project-open-data.github.io#272project-open-data/project-open-data.github.io#272

@ddnebert https://github.com/ddnebert, are you okay with this approach?

-Rich

Reply to this email directly or view it on GitHubhttps://github.com//issues/1#issuecomment-36244992
.

[rsignell-usgs]

@tomkralidis , I think the CSV list approach is awesome! (and I didn't know that GitHub renders CSV -- that is so cool).

@ethanrd, please check the Unidata ones I put in (without asking you) for DAP, CDM, NCSS serviceTypes. Of course we are open to better suggestions. (and I wasn't sure about versions)

[emiliom]

Nothing of value to add here at this time, except to say that I'm happy to join this party, in a roundabout way via a pull request to the MetaSearch CSW client QGIS plugin. @tomkralidis, thanks for connecting me to these discussions. @dpsnowden, @rsignell-usgs and @smrazgs, good to run into you here. The discussions here look great, and so do the resources you've already compiled, including the link-types csv list.

[tomkralidis]

@rsignell-usgs, @smrazgs @ddnebert another attempt at flushing this out, for review/comment:

https://github.com/OSGeo/Cat-Interop/blob/master/link_types_ref.csv

Notes for review:

• the idea is simple keys like OGC:WMS, and that's it. Provenance/authority lie elsewhere
• the simple key acts as a helper to the MIME type returned in the response of a given link
• this starts to look a bit like https://github.com/geonetwork/core-geonetwork/blob/develop/web/src/main/webapp/WEB-INF/data/config/schema_plugins/iso19139/loc/eng/labels.xml#L1894.
• removed the status column, this is implicit that once committed to master, it's approved (idea being submissions are done via pull requests for review/acceptance/merge)
• removed the submitter column, this is implicit in the pull request / commit info
• removed comment, do we need this?

Again, this is just for the review, in the spirit of a simple lookup as discussed last week.