<p>Tom Kralidis wrote Friday, August 04, 2006:<br>> TK2: we should start looking at the implementation barriers given the<br>> tools we already have for OGC:WFS and OAI.<br>[...]</p>
<p>I agree and I don't want to underestimate the fact that WFS is already implemented in tools like GeoTools and others. But I assume that there is some coding needed anyway and I wanted to give a try to get a really lean and mean metadata protocol spec. So, if I would'nt have found something like OAI-PMH I would vote directly for WFS profiled to RESTful harvesting needs. Now it seems, that we got such a lightweight spec. from a much broader community as well as tools (
c.f. below).</p>
<p>> TK2: by "catalog", I'm referring to a XML-based API (in this case<br>> OGC:WFS) which allows for discovery of (in our case) geospatial content,<br>> via static resource or interactive service.</p>
<p>Yes, both static resources and online services should be included. </p>
<p>My simplified definition from information retrieval is, that there are search services (called 'service providers' in OAI-PMH) which can be subdivided in catalogues (= database, boolean search, SQL, no ranking) and search engines (free text, fuzzy search, ranking).
<a href="http://Mapdex.org">Mapdex.org</a> and most GDI portals are examples for a catalogue and <a href="http://geometa.info">geometa.info</a> is an (initial) example for a search engine. </p>
<p>Both, catalogues and search engines, can make use of the protocol I have in mind. I observed also some additional demands, like direct search and bind out of a GIS box (uDig and ArcGIS/geographynetwork). I hope that we can achieve that directly through this OAI-PMH definition I sketched here:
<a href="http://www.geometa.info/rappiinfo/wiki/index.php/OSGeodata">http://www.geometa.info/rappiinfo/wiki/index.php/OSGeodata</a>. If not I would enhance the spec. after some implementation experiences.</p>
<p>> TK2: Can we step back a minute and clarify what exactly we are looking<br>> to do here? Is the goal for OSGEO to stand up a catalog API into data<br>> and services?</p>
<p>Yes, that's what I suggested too in a former thread. See my answers above and in the following message ("RE: [OSGeodata] discovery requirements"). </p>
<p>> TK2: are there any examples, or implementations of what you have in mind<br>> (due to the fact that I am ignorant to OAI)? At any rate, good<br>> discussion -- this is what the catalogue dilemma needs!</p>
<p><a href="http://www.openarchives.org/">http://www.openarchives.org/</a> is the entry point of everything about OAI including an OAI Repository Explorer as well as tools: <a href="http://www.openarchives.org/tools/tools.html">
http://www.openarchives.org/tools/tools.html</a> (sourceforge lists 27). I'm not (yet) an OAI connoisseur but what I've seen so far looked like useable open source tools. For example as data providers I found OAICat <a href="http://www.oclc.org/research/software/oai/cat.htm">
http://www.oclc.org/research/software/oai/cat.htm</a> for Java and <a href="http://srepod.sourceforge.net/">http://srepod.sourceforge.net/</a> for C and some PHP implementations. On the other hand there I found search service providers from the same source as OAICat, and additionalle FathomFive, a Java crawler based on Lucene which spiders HTTP and OAI, up to DSpace, a digital library system. For Google, Yahoo etc. coverage read this:
<a href="http://en.wikipedia.org/wiki/Deep_web#Crawling_the_deep_web">http://en.wikipedia.org/wiki/Deep_web#Crawling_the_deep_web</a>.</p>
<div>I'd definitively suggest looking at OAICat.</div>
<div>-- Stefan<br> </div>