search

OSGeo / Cat-Interop

Better interoperability between open source metadata servers and clients.
http://wiki.osgeo.org/wiki/Cat-Interop
MIT License
23 stars 21 forks source link

Gather community feedback on ServiceType list #1

Open rsignell-usgs opened 10 years ago

rsignell-usgs commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

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

smrgeoinfo commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

tomkralidis commented 10 years ago

@rsignell-usgs comments:

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 commented 10 years ago

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

ddnebert commented 10 years ago

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#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 .

rsignell-usgs commented 10 years ago

@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 commented 10 years ago

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 commented 10 years ago

@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:

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

rsignell-usgs commented 10 years ago

@tomkralidis , what about version numbers and the "also known as" list? Have these concepts been dropped or just not added yet?

tomkralidis commented 10 years ago

@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.

tomkralidis commented 10 years ago

@smrazgs comments on https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv

mhogeweg commented 10 years ago

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.

tomkralidis commented 10 years ago

+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.

smrgeoinfo commented 10 years ago

+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:notifications@github.com] 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.

tomkralidis commented 10 years ago

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?

smrgeoinfo commented 10 years ago

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:notifications@github.com] 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.

tomkralidis commented 10 years ago

@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.

tomkralidis commented 10 years ago

@mhogeweg q: many download links are zipped shapefiles (containing .shp/.shx/.prj/.dbf). What's the best identifier to use for this?

tomkralidis commented 10 years ago

@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?

rsignell-usgs commented 10 years ago

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 notifications@github.comwrote:

@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

ddnebert commented 10 years ago

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 notifications@github.comwrote:

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 <notifications@github.com

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 .

mhogeweg commented 10 years ago

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.

ddnebert commented 10 years ago

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 notifications@github.com 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 .

rsignell-usgs commented 10 years ago

Folks, Okay, so if vendors want to host a resolver, they should be able to. That makes sense. What about organizations that might not want to maintain a resolver?

If organizations like Unidata and OPeNDAP prefer not to, would it be okay to have them resolved by OGC ( not osgeo) ?

http://www.opengis.net/def/serviceType/unidata/ncss http://www.opengis.net/def/serviceType/opendap/opendap

On Fri, Apr 4, 2014 at 1:50 PM, ddnebert notifications@github.com wrote:

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 notifications@github.com 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 GitHub< https://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-39592276>

.

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

Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598

tomkralidis commented 10 years ago

update based on latest comments: https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable2.csv, for review and comment. This makes the alias the identifier/shorthand tag.

mhogeweg commented 10 years ago

if OGC provides that service, that would be fine and preferred as a vendor-neutral place ;-)

rsignell-usgs commented 10 years ago

Marten,

Good, I thought that's what we were shooting for -- a vendor neutral place to resolve the different services, putting the different services on an equal footing, and also giving the appearance that we are all in this together. ;-)

So, just to make sure: as long as it's vendor neutral place (OGC), it would be okay to resolve ESRI services there?

With github, it would be easy for vendors to update the links they want the OGC keys to resolve to.

-Rich

On Fri, Apr 4, 2014 at 2:02 PM, Marten notifications@github.com wrote:

if OGC provides that service, that would be fine and preferred as a vendor-neutral place ;-)

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

Dr. Richard P. Signell (508) 457-2229 USGS, 384 Woods Hole Rd. Woods Hole, MA 02543-1598

pvgenuchten commented 10 years ago

Hi all, great to see this evolving having uri's as identifier would be the way to go imho. It would be great if all uri's resolve properly, however i support the desire of pointing to a maintainer of the spec, even if it would mean it can break resolving.

I'd suggest to store the list (or a copy) as a json-ld file, so it's easy to read for machine, while being embedded in semweb (facilitate conversion to skos:RDF).

tomkralidis commented 10 years ago

@pvgenuchten thanks. The CSV is meant for a workable artifact here on GitHub. When we version/tag/release this, one of the results will be a json.

Based on https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable2.csv, can you post a snippet of what the header and one of the rows would look like?

mhogeweg commented 10 years ago

if have created a simple start of a type description: http://esriurl.com/mpk.xml. This redirects to a metadata record in our sandbox geoportal server instance is that conveniently allows for an RDF-style description. This link is not an official Esri map package type URI, but it's a start.

tomkralidis commented 10 years ago

@mhogeweg thanks. Exactly. So then the identifier for this in our table is something like ESRI:MPK, the uri is http://esriurl.com/mpk.xml (for now), and the url is http://esriurl.com/mpk.xml, label is "ESRI Map Package".

drh-stanford commented 10 years ago

for WWW:LINK, rather than using xlink, you can use the linked data property from schema.org -- namely, http://schema.org/url.

pvgenuchten commented 10 years ago

@tomkralidis JSON-LD export for the list could look like:

{
  "@context":
    { 
    "@type": "http://www.opengeospatial.org/def/serviceType",
    "url": "http://schema.org/url",
    "version":  {
      "@id": "http://schema.org/version",
      "@type": "@id"
    },
    "label_en": {
      "@lang":"en",
      "@id": "http://schema.org/name",
      "@type": "@id"
    },
    "comment_en": {
      "@lang":"en",
      "@id": "http://schema.org/comment",
      "@type": "@id"
    },
    "target": {
      "@id": "http://www.opengeospatial.org/def/target",
      "@type": "@id"
    },
    "registrant": {
      "@id": "http://schema.org/publisher",
      "@type": "@id"
    },
    "owner": {
      "@id": "http://schema.org/provider",
      "@type": "@id"
    }
  },
  "@graph":
  [
  {
  "@id":"http://www.opengis.net/def/serviceType/ogc/csw/2.0.2",
  "version":"2.0.2",
  "url": "http://www.opengeospatial.org/standards/cat",
  "label_en": "OGC Catalogue Service for the Web",
  "comment_en": "API to query a data catalogue",
  "target": "srv:serviceType;gmd:protocol;usgin:overlayAPI",
  "registrant": "@tkralidis",
  "owner": "OGC"  
  },
  {
  "@id":"http://www.opengis.net/def/serviceType/ogc/wms/1.1.0",
  "version": "1.1.0",
  "url": "http://www.opengeospatial.org/standards/wms",
  "label_en": "OGC Web Mapping Service",
  "comment_en": "API to retrieve spatial information as a bitmap",
  "target": "srv:serviceType;gmd:protocol;usgin:overlayAPI",
  "registrant": "@tkralidis",
  "owner": "OGC"  
  }
  ]
}

@mhogeweg in this case you're referring to a mediatype, I'd suggest to make a separate list for geospatial mediatypes or connect to existing lists of mediatypes like http://www.iana.org/assignments/media-types/media-types.xhtml. In your rdf-document there is not a reference to the type-of-object that you're describing (in your case a mediatype). And here we hit another old discussion (see for example https://joinup.ec.europa.eu/asset/dcat_application_profile/issue/%E2%80%9Cprotocol%E2%80%9D-and-%E2%80%9Cname%E2%80%9D-properties -> conslusion: won't fix), what is the type of thing we're listing here? DCAT is not aware of an api-spec, servicetype or protocol.

tomkralidis commented 10 years ago

@pvgenuchten thanks. Comments:

tomkralidis commented 10 years ago

FYI based on https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable2.csv I've posted a simple Python function at https://github.com/OSGeo/Cat-Interop/blob/master/sniff_link.py, for the workflow of detecting what a link is, when, say for ISO, gmd:protocol is empty/not set. Certainly needs more work on detection, but gives an initial idea.

kalxas commented 10 years ago

Thanks @tomkralidis for this first implementation of the https://github.com/OSGeo/Cat-Interop/blob/master/link_types.py. Given the above discussion, can we safely merge/delete https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csv with https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable2.csv ? How about creating a beta tag for the merged table?

pvgenuchten commented 10 years ago

Hi tsotsos, Maybe I'm repeating an old discussion here, but the list contains a number of file formats (mpk,gml). I think we should create a new list (or merge with existing initiatives) for those.

Also I'm not seeing a number of ogc and w3c standards I'd expect here, like wmts, OpenLS, sparql, odata

pvgenuchten commented 10 years ago

I was just thinking about some other API's we could add

What about Git and/or Subversion endpoints. In the open data community we have seen quite some initiatives to publish datastes as (geo)json in Git. For sure one could add such a dataset as a file-download, but by referencing it as a file in git/svn, a catalogue client might be able to access its historic versions (and facilitate commenting or even suggest modifications). Same for related spatial data versioning API's like GeoGit and Dat (https://github.com/maxogden/dat)

What about the Geo Cloud Publish API as it is used in geoserver and mapserver (neogeo). It's an open specification, used by multiple products (Qgis, geoserver, geocat bridge). On the other hand such an endpoint is probably not an endpoint somebody would want to share in a catalogue

Also good to consider are Transformation services, such as Inspire describes here: http://inspire.ec.europa.eu/index.cfm/newsid/10241, but also easy format transformation services like datapipes (http://datapipes.okfnlabs.org) or http://ogre.adc4gis.com.

Below is an export from a recent catalogue project, where they wanted to adjust a similar list to only contain OGC specs, I noticed some of them are not yet in the online list (This list also has some file formats, which are actually used in that catalogue instance to enable "add to map" for that type of data)

OGC:CSW - OGC-CSW Catalogue Service for the Web OGC:WMS - OGC-WMS Web Map Service OGC:WMTS - OGC-WMTS Web Map Tiled Service OGC:WFS - OGC-WFS Web Feature Service OGC:WCS - OGC-WCS Web Coverage Service OGC:WCTS - OGC-WCTS Web Coordinate Transformation Service OGC:WPS - OGC-WPS Web Processing Service OGC:WMC - OGC-WMC Web Map Context OGC:KML - OGC-KML Keyhole Markup Language OGC:GML - OGC-GML Geography Markup Language OGC:WFS-G - OGC-WFS-G Gazzetteer Service OGC:SOS - OGC-SOS Sensor Observation Service OGC:SPS - OGC-SPS Sensor Planning Service OGC:SAS - OGC-SAS Sensor Alert Service OGC:WNS - OGC-WNS Web Notification Service OGC:ODS - OGC-ODS OpenLS Directory Service OGC:OGS - OGC-ODS OpenLS Gateway Service OGC:OUS - OGC-ODS OpenLS Utility Service OGC:OPS - OGC-ODS OpenLS Presentation Service OGC:ORS - OGC-ODS OpenLS Route Service

ethanrd commented 10 years ago

Unidata could commit to maintaining these service identifiers

http://www.unidata.ucar.edu/serviceType/unidata/ncss http://www.unidata.ucar.edu/serviceType/unidata/cdmr

On the other hand, we would also be OK with OGC based identifiers for the Unidata services. And given there is already some infrastructure to deal with resolving OGC identifier URLs, that might be a good choice. Do they already resolve other non-OGC services?

For the OPeDNAP service, I would suggest OPeNDAP:DAP for the alias and similarly for the identifier: /serviceType/opendap/dap. Has anyone from OPeNDAP chimed in yet? I'll be on a telecon with them tomorrow and could bring this up if that would be helpful.

rsignell-usgs commented 10 years ago

@ethanrd, yes, I think that would be useful to bring up with OPeNDAP guys, if nothing other than to make them aware of the issue.

tomkralidis commented 10 years ago

On Sun, May 11, 2014 at 11:51 AM, paul van genuchten < notifications@github.com> wrote:

I was just thinking about some other API's we could add

What about Git and/or Subversion endpoints. In the open data community we have seen quite some initiatives to publish datastes as (geo)json in Git. For sure one could add such a dataset as a file-download, but by referencing it as a file in git/svn, a catalogue client might be able to access its historic versions (and facilitate commenting or even suggest modifications). Same for related spatial data versioning API's like GeoGit and Dat (https://github.com/maxogden/dat)

Wouldn't these be figured out from the protocol itself (i.e. git:, svn://)?

What about the Geo Cloud Publish API as it is used in geoserver and mapserver (neogeo). It's an open specification, used by multiple products (Qgis, geoserver, geocat bridge). On the other hand such an endpoint is probably not an endpoint somebody would want to share in a catalogue

Below is an export from a recent catalogue project, where they wanted to adjust a similar list to only contain OGC specs, I noticed some of them are not yet in the online list (This list also has some file formats, which are actually used in that catalogue instance to enable "add to map" for that type of data)

Thanks will look. Are all of these current/relevant? For example, are there examples of metadata out there with OpenLS links?

OGC:CSW - OGC-CSW Catalogue Service for the Web OGC:WMS - OGC-WMS Web Map Service OGC:WMTS - OGC-WMTS Web Map Tiled Service OGC:WFS - OGC-WFS Web Feature Service OGC:WCS - OGC-WCS Web Coverage Service OGC:WCTS - OGC-WCTS Web Coordinate Transformation Service OGC:WPS - OGC-WPS Web Processing Service OGC:WMC - OGC-WMC Web Map Context OGC:KML - OGC-KML Keyhole Markup Language OGC:GML - OGC-GML Geography Markup Language OGC:WFS-G - OGC-WFS-G Gazzetteer Service OGC:SOS - OGC-SOS Sensor Observation Service OGC:SPS - OGC-SPS Sensor Planning Service OGC:SAS - OGC-SAS Sensor Alert Service OGC:WNS - OGC-WNS Web Notification Service OGC:ODS - OGC-ODS OpenLS Directory Service OGC:OGS - OGC-ODS OpenLS Gateway Service OGC:OUS - OGC-ODS OpenLS Utility Service OGC:OPS - OGC-ODS OpenLS Presentation Service OGC:ORS - OGC-ODS OpenLS Route Service

Angelos Tzotsos schreef op 11-5-2014 2:17:

Thanks @tomkralidis for this first implementation of the https://github.com/OSGeo/Cat-Interop/blob/master/link_types.py. Given the above discussion, can we safely merge/delete https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable.csvwith https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable2.csv? How about creating a beta tag for the merged table?

Reply to this email directly or view it on GitHub: https://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-42758485

— Reply to this email directly or view it on GitHubhttps://github.com/OSGeo/Cat-Interop/issues/1#issuecomment-42774159 .

pvgenuchten commented 10 years ago

Hi Tom, I can see that usecase where a git-resource is categorised by it's protocol-prefix. However probably people will want to link to an http endpoint of the data (in github "raw"), so clients that are not aware of the git protocol, can still access the data. In that case you would need the protocol to identify it's nature.

In geoss I found some boilerplate records describing OpenLS services, for example http://geossregistries.info/geosspub/resource_details_ns.jsp?compId=urn:geoss:csr:resource:urn:uuid:3787839f-d254-45b1-be46-ecd6a1cde748

I still have my doubts on the file-formats/encodings/applicationprofiles in the list (mpk,gml,quakeml). The list will potentially become very long if we add those types.