[OSGeodata] geodata schema

[Kralidis,Tom [Burlington]]

> -----Original Message-----
> From: Jo Walsh [mailto:jo at frot.org] 
> Sent: 02 August, 2006 11:08 AM
> To: geodata at geodata.osgeo.org
> Subject: Re: [OSGeodata] geodata schema
> 
> dear Stefan, all; sorry for my response lag on this - i'm 
> still playing email catchup from my week offline last week. :/
> 
> On Tue, Aug 01, 2006 at 08:02:14PM +0200, sfkeller at hsr.ch wrote:
> > 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
> This is an implementation of
> http://wiki.osgeo.org/index.php/Geodata_Metadata_Requirements
> which in turn is an attempt to extract the 'simplest useful thing'
> from FGDC metadata, and bolt on some Dublin Core properties 
> and also expressions about OGC web services interfaces. This 
> was put together over a couple of longish discussions at IRC 
> meetings in April/May. It doesn't represent a "public 
> recommendation" but a representation of what OSGeo and 
> telascience members need as a baseline for our own data 
> repository, which we hope will be useful to others. 
> 
> > 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.
> 
> Why not OAI-PMH, i would say 1/ because none of us really knew it. 
> http://www.oaforum.org/tutorial/english/page3.htm outlines a 
> nice simple worldview - 6 http based requests - But we'll 
> *definitely* need to extend beyond this
> - I want to be able to send spatial and temporal bounding 
> boxes to a RESTful interfaces and get back data sets 
> constrained by this. 
> I guess being able to say 'OAI-PMH compatible' is a win?
> 
> I've always thought of this as a data-driven not "metadata-driven"
> activity - thus 'ListMetadataFormats' doesn't make that much 
> sense to me. Model first, format is syntactic sugar almost? 
> ;) I guess I'd envisioned results coming out mainly in RSS1.0 
> (RDF) with GeoRSS expressions - cf http://georss.org/  - and 
> also optionally in that lovely tab-delimited FGDC format :) - 
> and FGDC xml if people really want that too.
> 
> I hadn't thought about this in syndication/crawler terms, 
> until i actually looked at it, and thought, well it would 
> work both ways, and i'm already using GDAL/OGR and starting 
> to use OWSLib to automate spatial indexing of shapefiles, 
> etc, and OGC web services, respectively.
> 
> > > My motivation is to avoid the CSW-ebRim profile
> 
> Definitely, it sounds painful.
> > 
> > Regarding the protocol I see three choices: 1. CSW 2, 2. WFS and 3.
> > OAI-PMH.
> 
> +1 on using the very basic OAI-PMH 6 functions, seeing if they're all
> useful to us, and extending them, and then arguing about it 
> via the medium of bots. 

I see two levels of decision here:

1./ RESTful interface
2./ underlying information model
2./ output content model

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).

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.

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)

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

..Tom