<p>Norman,</p>
<div>You wrote on Tue, 1 Aug 2006 16:03:31 +0100: <br>> I would be interested in taking the schema and the mind map that you <br>> have on the wiki and at <br>> <a href="https://geodata.osgeo.org/source/browse/geodata/trunk/metadata/">
https://geodata.osgeo.org/source/browse/geodata/trunk/metadata/</a> and <br>> developing it further.<br>> (the svn checkout for 'guest' seems to be broken - is there no guest<br>> access?)</div>
<div><br>Didn't realize this. This seems to borrow the information model from FGDC. How much was this model discussed? For future compatibility, I would either take an 'enhanced' set of attributes from pure core ISO 19115/19 - or an extended and specialized set of Dublin Core elements in RDF, which would give geodata an even broader outreach through Google with the help of OAI-PMH (
c.f. below). Regarding FGDC and ISO 19115: I found that the so called core lacks mandatory Dublin Core elements which is a pity. </div>
<p>> Although I know python quite well, I would prefer to develop in Java <br>> if possible.<br>> <br>> My motivation is to avoid the CSW-ebRim profile, and to encourage the <br>> uptake of RESTful catalogs, and further explore this rapid catalog
<br>> development and see if enough metadata can be captured. My motivations <br>> are also from a business perspective - more catalogs mean more chance <br>> to utilise meaningful data and a better use of clients.
</p>
<p>That was exactly my intention too when I startet the thread "Ready for a lean and mean Catalogue Service Protocol Spec.?" about ten days ago, though perhaps more from a GDI and practical research perspective.
</p>
<p>> I would like to suggest the following work items in Java<br>> <br>> (1) Take existing metadata postgis database<br>> (2) Use Java annotations (EJB3) to do a data-object persistence bind<br>> (3) Write a Java Bot to scour the web for getcapabilities and attempt
<br>> to parse the capabilities and fill up the database using (2) (want to <br>> abstract the database to set of POJOs)<br>> (4) implement georss feed (still thinking about this at the moment) <br>> for new data items
<br>> <br>> Whilst I think 1 - 3 are quite easy, have there been any plans for <br>> develop the API for the catalog front end?<br>[...]</p>
<p>I like you plans (we are using Java too) and I support your approach, "first implement then think" (I'm citing Jo here). Nevertheless just a few thoughts here: What is needed is a protocol and an model/scheme for the metadata. Regarding the metadata scheme I can live with both approaches mentioned above given an incremental, implementation driven process.
</p>
<p>Regarding the protocol I see three choices: 1. CSW 2, 2. WFS and 3. OAI-PMH. Though some say that CSW 2 (1.) can be profiled to a RESTful protocol I simply don't see a reason why to deviate from WFS. This will duplicate specification and implementation efforts. And both, 1. and 2., are somehow isolated in GIS world. Whereas 3. OAI-PMH is RESTful, supported by Google and has many implementations which can be adapted.
</p>
<p>OAICat is one of the most active open source implementations I found: <a href="http://www.oclc.org/research/software/oai/cat.htm">http://www.oclc.org/research/software/oai/cat.htm</a>. So, to repeat my last question from 29 Jul 2006, was: Why no go with OAI-PMH (protocol)?
</p>
<p>Just my few cents here.</p>