[OSGeodata] geodata schema

[Kralidis,Tom [Burlington]]

Comments prefixed by TK: 


________________________________

	From: Stefan F. Keller [mailto:sfkeller at gmail.com] 
	Sent: 02 August, 2006 8:52 PM
	To: geodata at geodata.osgeo.org
	Subject: [OSGeodata] geodata schema
	
	

	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

		 
		With 'underlying information model' do you mean that
information that can be taken for requests? 

TK: correct.

	 
		> I would go with a WFS as the interface standard
(flexible API).   In our

	> experiences with owscat, we found WFS to be flexible, and can
already be 

	> integrated with WFS client tools, as well as the option of
going with 

	> open source WFS servers out-of-the-box (MapServer, GeoServer,
deegree). 

	 

	Don't take me wrong WMS and WFS are good specs. But WFS make
reference to Filter. And for a simple protocol I'd like to have a simple
query language, mainly to boolean and perhaps wildcard matches. So IMHO
WFS query should be really profiled and constrained to REST (no SOAP). 

	 
TK: You can use WFS and Filter RESTfully.

	The fact that open source WFS exist out-of-the-box is a plus.
But what about repositories in other languages like C or C# (as many
commercial desktop GIS)? 

	 

	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.

	 

	OAI-PMH offers a spec. and implementations - as well as services
and gateways - called static repository:
http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm
<http://www.openarchives.org/OAI/2.0/guidelines-static-repository.htm>
.


	Forgive me when I mentioned that spec. again. I think code
first, think later will allow for several approaches here. 

	 

	> For an information model, I would envision a model (or db
tables) like: 

	> 

	> service_endpoints

	> service_resources

	> data_resources

	> 

	> Where service_endpoints and service_resources are basically a
split of 

	> an OGC Capabilities XML document (service vs. layer metadata)
with 

	> foreign key refs associating them.

	 

	Don't understand this yet, have to think about this again. 

	 

		Is'nt something like those 6 queries from OAI-PMH enough
combined with the minimally extended Dublin Core (including coverage as
spatial constraints (bbox)) as output content model enough whereas every
attribute from the extended Dublin Core can be queried? From the
response the harvester/crawler can see that its a file (protocol value =
'file:') or a service and - if service - make a subsequent
GetCapabilities request which contains all further information? 

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.	 

	> For an output content model, as a WFS, we can offer a
multitude of

	> output formats:

	> 

	> Data: OWSCommon (which is based on ISO19115/9), FGDC, DC 

	> Services: OWSCommon (which is based on ISO19115/9) 

	 

	Is there an UML diagram for both OWSCommon for data and
services? 


TK: see Annex B of OWS Common 1.0.0 at:
https://portal.opengeospatial.org/files/?artifact_id=8798

	> We can also provide an operation to a GeoRSS feed for 'most
recent' 

	> entries.

	 

	Yes.