Cat-Interop
Cat-Interop copied to clipboard
OSGeo
Gather community feedback on ServiceType list
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?
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.
@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.
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.
@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.
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
There is http://urn.opengis.net/ (which points to CSIRO), but honestly this seems a bit magical :)
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).
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.
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: https://github.com/project-open-data/project-open-data.github.io/issues/272
@ddnebert, are you okay with this approach?
-Rich
@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.
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 [email protected]:
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#272https://github.com/project-open-data/project-open-data.github.io/issues/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/OSGeo/Cat-Interop/issues/1#issuecomment-36244992 .
@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)
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.
@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
statuscolumn, 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
submittercolumn, 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.
@tomkralidis , what about version numbers and the "also known as" list? Have these concepts been dropped or just not added yet?
@rsignell-usgs for version numbers, in the name of simplicity, wouldn't version negotiation conversation cover this? Having said this, it looks like @smrazgs has posted https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv with explanation / documentation at https://github.com/OSGeo/Cat-Interop/wiki/Fields-for-Metadata-property-lookup-table, which builds on what I did yesterday, so let's carry on against that.
@smrazgs comments on https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv
- why don't we make the
Aliasfield theStringValuefield, and that's our lookup/key? This also gives us some compatibility with existing values out there currently. - Do we need
github:namespace inRegistrant? Can we just have the handle?
I would leave version numbering questions like @rsignell-usgs raised, up to the owner of the URI. These URI for item types do not have to point/resolve to anything specific and may point to an XSD, and HTML page, an RDF, etc. "the mechanism [of dereferencing URI] makes it possible for a user (or software agent) to "follow your nose" to find out more information related to the identified resource".
I would not use Alias here. The URI may redirect to some other place (as is the case with the OGC ones), but stick to the URI provided by the source as the URI.
Also not sure about TargetField as this list would just describe the well-known types of things (regardless of what metadata, app, other use). If ISO were to adopt this list of types into their spec, they could use a list like this (probably XML instead of CSV) as a common list in whatever XML field or database field or JSON field they choose.
+1 / agreed with @mhogeweg. The CSV in this context is for ease of development here on GitHub. We could use tagging for versioning the CSV, where build steps would produce XML (or JSON, whatever) that is then published to gh-pages, for example.
+1 on using the URIs as the valueString, and the Aliases as ‘alternate usages’
The idea of including the TargetField property is to promote more consistency in usage—the explanation of some of the ISO properties are ambiguous enough that people use them differently (protocol, ServiceType, DCP, format, applicationScheme, metadataStandardName…)
Stephen M Richard Arizona Geological Survey 416 W. Congress #100 Tucson, AZ AZGS: 520-770-3500 Office: 520-209-4127 FAX: 520-770-3505
From: Marten [mailto:[email protected]] Sent: Wednesday, April 02, 2014 10:13 AM To: OSGeo/Cat-Interop Cc: Steve Richard Subject: Re: [Cat-Interop] Gather community feedback on ServiceType list (#1)
I would leave version numbering questions like @rsignell-usgshttps://github.com/rsignell-usgs raised, up to the owner of the URI. These URI for item types do not have to point/resolve to anything specific and may point to an XSD, and HTML page, an RDF, etc. "the mechanism [of dereferencing URIhttp://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier] makes it possible for a user (or software agent) to "follow your nose" to find out more information related to the identified resource".
I would not use Alias here. The URI may redirect to some other place (as is the case with the OGC ones), but stick to the URI provided by the source as the URI.
Also not sure about TargetField as this list would just describe the well-known types of things (regardless of what metadata, app, other use). If ISO were to adopt this list of types into their spec, they could use a list like this (probably XML instead of CSV) as a common list in whatever XML field or database field or JSON field they choose.
— Reply to this email directly or view it on GitHubhttps://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-39357136.
Then I think we should use the RegisteredURI field as the StringValue field, as the canonical key. And remove the "Alias", 'alternate usage' (to me) invites mixing and matching of values, and suddenly software has to detect either of them. One list, one set of keys.
How about removing the Alias field and rename RegisteredURI to "identifier" and put in the first column?
Tom—I’m good with promoting the URI as the value to use. What to call that field is an interesting problem. I liked the idea of calling it ‘stringValue’ or something like that to emphasize that this is what you look for in the data you’re parsing, but ‘identifier’ is good as well.
I’m also with you on doing what we can to dissuade usage of the ‘aliases’. I think it’s good to include them there to help people figure out existing data. Maybe something ‘nonpreferred’, ‘aka’ (also known as), ‘notRecommended’? Or we could put the aliases in the comments?
steve
Stephen M Richard Arizona Geological Survey 416 W. Congress #100 Tucson, AZ AZGS: 520-770-3500 Office: 520-209-4127 FAX: 520-770-3505
From: Tom Kralidis [mailto:[email protected]] Sent: Friday, April 04, 2014 6:57 AM To: OSGeo/Cat-Interop Cc: Steve Richard Subject: Re: [Cat-Interop] Gather community feedback on ServiceType list (#1)
Then I think we should use the RegisteredURI field as the StringValue field, as the canonical key. And remove the "Alias", 'alternate usage' (to me) invites mixing and matching of values, and suddenly software has to detect either of them. One list, one set of keys.
How about removing the Alias field and rename RegisteredURI to "identifier" and put in the first column?
— Reply to this email directly or view it on GitHubhttps://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-39567320.
@smrazgs thanks. The only concern I have is that people actually start using the aliases when they see them there, i.e. "oh, http://www.opengis.net/def/serviceType/ogc/wms also says OGC:WMS, I'll just use OGC:WMS". Then again, in the context of software implemenations this should be less of an issue.
@mhogeweg q: many download links are zipped shapefiles (containing .shp/.shx/.prj/.dbf). What's the best identifier to use for this?
@smrazgs @mhogeweg @rsignell-usgs @ddnebert FYI updated for review/comment:
https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv
Looking at it now, it's obvious that the UNIDATA identifiers (from an infrastructure perspective) are brittle and error prone. Can anyone at unidata suggest simpler, more persistent identifiers?
As well, does http://urn.opengis.net/ have GML somewhere as a def?
Tom, Didn't OGC say they would be willing to resolve non OGC services at opengis.net?
It would be nice to have have the uniform style of:
http://www.opengis.net/def/serviceType/unidata/ncss http://www.opengis.net/def/serviceType/opendap/opendap http://www.opengis.net/def/serviceType/esri/rest
If they were willing.
-Rich
On Fri, Apr 4, 2014 at 1:18 PM, Tom Kralidis [email protected]:
@smrazgs https://github.com/smrazgs @mhogeweghttps://github.com/mhogeweg @rsignell-usgs https://github.com/rsignell-usgs @ddneberthttps://github.com/ddnebertFYI updated for review/comment:
https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv
Looking at it now, it's obvious that the UNIDATA identifiers (from an infrastructure perspective) are brittle and error prone. Can anyone at unidata suggest simpler, more persistent identifiers?
As well, does http://urn.opengis.net/ have GML somewhere as a def?
Reply to this email directly or view it on GitHubhttps://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-39589099 .
Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598
OSGeo would be willing to hold the root names, too, but shouldn't it be up to the owners of the definitions to resolve them from their own namespaces? I suggest we need to have a shorthand 'tag' to share in metadata, a non-resolving URN to distinguish it or specialize it (say by version number), and an information link to learn more about it. It could be that the URN is resolvable, and these latter two items are the same for some items.
Douglas D. Nebert Senior Advisor for Geospatial Technology FGDC Secretariat - Newport, Oregon Tel:+1 703 648-4151 Cell:+1 541 961-3149
On Fri, Apr 4, 2014 at 1:35 PM, Rich Signell [email protected]:
Tom, Didn't OGC say they would be willing to resolve non OGC services at opengis.net?
It would be nice to have have the uniform style of:
http://www.opengis.net/def/serviceType/unidata/ncss http://www.opengis.net/def/serviceType/opendap/opendap http://www.opengis.net/def/serviceType/esri/rest
If they were willing.
-Rich
On Fri, Apr 4, 2014 at 1:18 PM, Tom Kralidis <[email protected]
wrote:
@smrazgs https://github.com/smrazgs @mhogeweg< https://github.com/mhogeweg> @rsignell-usgs https://github.com/rsignell-usgs @ddnebert< https://github.com/ddnebert>FYI updated for review/comment:
https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv
Looking at it now, it's obvious that the UNIDATA identifiers (from an infrastructure perspective) are brittle and error prone. Can anyone at unidata suggest simpler, more persistent identifiers?
As well, does http://urn.opengis.net/ have GML somewhere as a def?
Reply to this email directly or view it on GitHub< https://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-39589099> .
Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598
Reply to this email directly or view it on GitHubhttps://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-39590863 .
I would prefer that vendors host their own URN (if they decide to make them dereferencable). they are the authority of the types of things they make available.
I agree.
Douglas D. Nebert Senior Advisor for Geospatial Technology FGDC Secretariat - Newport, Oregon Tel:+1 703 648-4151 Cell:+1 541 961-3149
On Fri, Apr 4, 2014 at 1:49 PM, Marten [email protected] wrote:
I would prefer that vendors host their own URN (if they decide to make them dereferencable). they are the authority of the types of things they make available.
Reply to this email directly or view it on GitHubhttps://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-39592276 .