[GeoNetwork-devel] OpenSearch GEO, OAI-MPH, CSW, GeoRSS. All miss a defined way to transfer service information

GeoNetwork GeoNetwork Developer
1

Hi all,
I see a huge number of extremely interesting discussions around catalogues happening all at the same time. This is excellent and I have good hopes we get to a point where we can bring lots of different approaches together! I'm starting a new one here :slight_smile:

One observation I have, that I have not seen resolved anywhere (where I have looked!?) is how to get information about services across in the simple, harmonized Dublin Core format that seems to be the common fall back format in all (or most if you wish) the above mentioned protocols.

We had an IRC discussion on this today in the OSGeo geodata channel (or #telascience on freenode). The issue for me is the following:

ISO19115 can be used to describe a number of online resources (I purposely ignore ISO19119 here :-). These resources can be all kind of things. W*S, zip files, HTML links, KML, you name it. If I have an ISO19115 record, I would like to be able to use these (multiple) online resources and show them in my DC formatted output. Without any documented agreement, this can not be done AFAIK. we came up with the idea to use the (logical) URI field for the links, but add required information to that field so that a proper (best guess) assessment can be made by the client on what this URI as all about.

Using mimetypes seems like a nice way of doing this. So you would end up with a list of URI elements in your DC metadata that could look like this:

<URI>mimetype, URI, name, description</URI> (with the 'name' and 'description' as optional content) (we use name for a wms layername in the case of a WMS service for instance)

So:
<URI>application/vnd.ogc.wms, http://geonetwork3.fao.org/ows/1, national_boundaries_africa, National administrative boundaries of Africa</URI>
<URI>application/vnd.google-earth.kml+xml, FAO Map Catalog, National administrative boundaries of africa, National administrative boundaries of africa</URI>

etc...
This kind of formatting allows most clients to properly asses what they can do with the URI provided and is easy to maintain as mimetypes are pretty well defined.

OK, maybe nothing new to many of you, but it was an insight we had today that I quite liked and that has some potential to work on DC as it is now used in most server protocols already without the need to modify schemas or so.

We can at that point also start using mimetypes as the content of the "protocol" field in the online resources in ISO19115 metadata. This is a relief for us compared to our current hacked approach :slight_smile:

Looking forward to suggestions on this. Keep up the good discussions!
Ciao,
Jeroen

2

* On 9-Oct-2007 at 1:33PM PDT, Jeroen Ticheler said:

So:
<URI>application/vnd.ogc.wms, http://geonetwork3.fao.org/ows/1,
national_boundaries_africa, National administrative boundaries of
Africa</URI>
<URI>application/vnd.google-earth.kml+xml, http://www.fao.org/
geonetwork/srv/en/google.kml?id=2&layers=sub-
national_boundaries_africa, National administrative boundaries of
africa, National administrative boundaries of africa</URI>

etc...
This kind of formatting allows most clients to properly asses what
they can do with the URI provided and is easy to maintain as
mimetypes are pretty well defined.

I think you're on the right track with the MIME typing, but I'm
concerned about your syntax and semantics there. First off, your
example doesn't look like a URI :slight_smile: and second, what if the title, URL,
or description contains a comma? I think you have the right idea but
I'd encourage you to look at structuring the representation
differently...

SDE

3

Great! What about:

dc:formatosgeo:http://geonetwork3.fao.org/ows/1[application/vnd.ogc.wms]</dc:format>

‘osgeo’ is a hierarchical scheme name as required by the URI RFC 2396. Let’s call it an osgeoURL. It consists of an underlying URL-reference followed by the mime type in brackets. An osgeoURL can be defined with the following ABNF:

osgeoURL = “osgeo:” URI-reference “[” mime-type “]”

Any occurence of the characters “[”, “]” (and probably “=”, and “,” as well) in the URL-reference MUST be encoded. (This proposal was inspired by http://trevp.net/cryptoURL/draft-ietf-cryptoURL-01.html).

To Andrew: Some time ago I tried to summarize what OAI-PMH is here:
http://gis.hsr.ch/wiki/OAI-PMH#OAI-PMH . But you probably better look at the source code and the live ‘demo’ called ‘OAI Repository Explorer’: http://www.openarchives.org/pmh/tools/

To Raj: I’m wondering that librarians stick with Z39.50 because that’s a dinosaur! AFAIK there is SRU (http://www.loc.gov/standards/sru/) as the ‘modern’ successor (which is actually also using CQL like CSW). Here again I’d like to be aware that Z39.50/SRU imply an online-query approach as opposite to harvesting.

2007/10/9, Schuyler Erle <schuyler@anonymised.com>:

  • On 9-Oct-2007 at 1:33PM PDT, Jeroen Ticheler said:

So:
application/vnd.ogc.wms, http://geonetwork3.fao.org/ows/1,
national_boundaries_africa, National administrative boundaries of
Africa
application/vnd.google- earth.kml+xml, http://www.fao.org/
geonetwork/srv/en/google.kml?id=2&layers=sub-
national_boundaries_africa, National administrative boundaries of
africa, National administrative boundaries of africa

etc…
This kind of formatting allows most clients to properly asses what
they can do with the URI provided and is easy to maintain as
mimetypes are pretty well defined.

I think you’re on the right track with the MIME typing, but I’m
concerned about your syntax and semantics there. First off, your
example doesn’t look like a URI :slight_smile: and second, what if the title, URL,
or description contains a comma? I think you have the right idea but
I’d encourage you to look at structuring the representation
differently…

SDE