<p>Tom Kralidis [Burlington] wrote Wed, 02 Aug 2006 16:34:<br>> <br>> Comments prefixed by TK:<br>> ________________________________<br>> <br>> > Stefan F. Keller wrote, Wed, 02 August, 2006 8:52 PM:<br>> >
<br>> > Tom, you wrote Wed, 2 Aug 2006 11:31:43 -0400:<br>> > > I see two levels of decision here:<br>> > ><br>> > > 1./ RESTful interface<br>> > > 2./ underlying information model
<br>> > > 2./ output content model<br>> > <br>> > With 'underlying information model' do you mean that<br>> > information that can be taken for requests?<br>> <br>> TK: correct.</p>
<p>Do you mean users requests to your search service or programmatic requests from a 'service provider' to a (meta) 'data provider'? (OAI-PMH terminology; see <a href="http://www.oaforum.org/tutorial/english/page3.htm">http://www.oaforum.org/tutorial/english/page3.htm
</a>).</p>
<p>[...]<br>> > What I have in mind is that even pure data file provides (like<br>> > KML, Shape, DXF, GeoTIFF, etc.) can participate - without a database and<br>> > without SQL engine.<br>> <br>> TK: this should work too,
i.e. MapServer can bind to files as well as<br>> databases. However, the reason I first mentioned databases was because<br>> of the way (in owscat's) the underlying information model is setup,<br>> which is driven by my requirement to discover both service instances and
<br>> layers/feature types, hence the split of the OWS Capabilities docs, and<br>> foreign key refs. So, some use cases or requirements should really<br>> drive what we want to build here.</p>
<p>My idea is to induce the smallest amount of software through the spec. I like MapServer and Java (regarding GeoServer etc.). But I was thinking to lower the implementation barrier for those who GIS programs which don't have already a WFS component and as well as to progammers which use scripting languages or in C including. For those who even won't have access to GIS software they can even contribute their spatial data description to so called 'OAI Static Repository Gateway' by registering their metadata files there.
</p>
<div>[...]<br>> TK: I haven't looked into OAI-PMH very much yet (just heard of it).<br>> Perhaps a comparison of OAI-PMH and OGC:WFS would be useful.</div>
<p>Good idea! Is there a preferred Wiki around? If not I offer in the meantime <a href="http://www.geometa.info/rappiinfo/wiki/index.php/OSGeodata">http://www.geometa.info/rappiinfo/wiki/index.php/OSGeodata</a> </p>
<p>In CSW and your former discussions you mention 'catalogue' as service providers which implies a probably sophisticated database. I'm rather thinking also about free text search engines (perhaps with some clever 'one boxes'). This would be a cool Google like search engine. So, I'd like to define the minimal data structures which are required for a spatially aware metadata interface protocol.
</p>
<p>To my understanding, harvesing - as assumed in OAI-PMH - does not require sophisticated query funtionality compared to a generic query, which is the assumption behind WFS Filter. Harvesting means also, that no distributed (cascaded) services need to be contacted in real-time like in WFS (probably) or in
Z39.50.</p>
<p>I see that you've made already advances by converting those XML from GetCapabilities to a 'underlying information model'. BTW: My approach was to use an XML database and then to try to apply XPath/XQuery.</p>
<p>I would be happy with a the minimal common information model (it's basically the KVPs attributes) wheras the response (e.g. the 'output content model') is simply something like an extended Dublin Core. If it's a 'service protocol' I'm still able to get more through GetCapabilities.
</p>
<p>-- Stefan</p>