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.

[rsignell-usgs]

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

[tomkralidis]

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

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

• why don't we make the Alias field the StringValue field, and that's our lookup/key? This also gives us some compatibility with existing values out there currently.
• Do we need github: namespace in Registrant? Can we just have the handle?

[mhogeweg]

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]

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

+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//issues/1#issuecomment-39357136.

[tomkralidis]

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]

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//issues/1#issuecomment-39567320.

[tomkralidis]

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

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

[tomkralidis]

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

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//issues/1#issuecomment-39589099
.

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

[ddnebert]

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//issues/1#issuecomment-39590863
.

[mhogeweg]

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]

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//issues/1#issuecomment-39592276
.

[rsignell-usgs]

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//issues/1#issuecomment-39592434
.

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

[tomkralidis]

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]

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

[rsignell-usgs]

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//issues/1#issuecomment-39593627
.

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

[pvgenuchten]

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]

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

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]

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

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

[pvgenuchten]

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

@pvgenuchten thanks. Comments:

• at this point, I'm suggesting we keep versions downstream to version negotiation between client/server (as per https://github.com/OSGeo/Cat-Interop/blob/master/LinkPropertyLookupTable2.csv)
• given the json-ld example, what is the actual value that ends up in the metadata to describe the link type? I thought it would be (in the case of WMS), OGC:WMS as per the identifier field in the CSV. This is enough to tip someone off to do a WMS workflow with the URL

[tomkralidis]

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]

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]

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]

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]

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]

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

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:
#1 (comment)

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

[pvgenuchten]

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.