[OSGeodata] geodata schema

[Kralidis,Tom [Burlington]]

Comments prefixed by TK2: 


________________________________

	From: Stefan F. Keller [mailto:sfkeller at gmail.com] 
	Sent: 03 August, 2006 3:56 PM
	To: geodata at geodata.osgeo.org
	Subject: RE: [OSGeodata] geodata schema
	
	

	Tom Kralidis [Burlington] wrote Wed, 02 Aug 2006 16:34:
	> 
	> Comments prefixed by TK:
	> ________________________________
	> 
	> > Stefan F. Keller wrote, Wed, 02 August, 2006 8:52 PM:
	> > 
	> > Tom, you wrote Wed, 2 Aug 2006 11:31:43 -0400:
	> > > I see two levels of decision here:
	> > >
	> > > 1./ RESTful interface
	> > > 2./ underlying information model 
	> > > 2./ output content model
	> > 

TK2: Whoops!  Typo above -- I missed that.  I originally meant 3 levels
of decision (and number 1,2,3) :)

	> >     With 'underlying information model' do you mean that
	> > information that can be taken for requests?
	> 
	> TK: correct.

	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
http://www.oaforum.org/tutorial/english/page3.htm
<http://www.oaforum.org/tutorial/english/page3.htm> ).


TK2: I'm not sure what you mean here.

	[...]
	> >   What I have in mind is that even pure data file provides
(like
	> > KML, Shape, DXF, GeoTIFF, etc.) can participate - without a
database and
	> > without SQL engine.
	> 
	> TK: this should work too, i.e. MapServer can bind to files as
well as
	> databases.  However, the reason I first mentioned databases
was because
	> of the way (in owscat's) the underlying information model is
setup,
	> which is driven by my requirement to discover both service
instances and 
	> layers/feature types, hence the split of the OWS Capabilities
docs, and
	> foreign key refs.  So, some use cases or requirements should
really
	> drive what we want to build here.

	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. 


TK2: we should start looking at the implementation barriers given the
tools we already have for OGC:WFS and OAI.

	[...]
	> TK: I haven't looked into OAI-PMH very much yet (just heard of
it).
	> Perhaps a comparison of OAI-PMH and OGC:WFS would be useful.

	Good idea! Is there a preferred Wiki around? If not I offer in
the meantime http://www.geometa.info/rappiinfo/wiki/index.php/OSGeodata 


TK2: thanks much for this -- very helpful!

	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. 

TK2: by "catalog", I'm referring to a XML-based API (in this case
OGC:WFS) which allows for discovery of (in our case) geospatial content,
via static resource or interactive service.

TK2: Can we step back a minute and clarify what exactly we are looking
to do here?  Is the goal for OSGEO to stand up a catalog API into data
and services?

	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.

	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.

TK2: this would be preferred, the main reason for the xml splitting is
due to using SDI-in-a-box based parts.  If PostGIS/PostgreSQL supported
XPath/Xquery based query and retrieval, and if this functionality was
visible via MapServer, that would have been a lot easier!

	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. 

TK2: are there any examples, or implementations of what you have in mind
(due to the fact that I am ignorant to OAI)?  At any rate, good
discussion -- this is what the catalogue dilemma needs!