[OSGeodata] geodata schema

Stefan F. Keller sfkeller at gmail.com
Wed Aug 2 20:17:19 EDT 2006


Jo wrote:

> 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
[...]


To my knowledge FGDC strongly influenced - if not formed the base of -
ISO19115. So on one hand, this means that chances are high that there are
similarities to ISO19115, but I think, that on the other hand FGDC (as a
namespace) would be not so accepted in Europe.



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



OAI-PMH with the basic 6 functions needs at least being extended by the
'output content model' (i.e. the metadata schema).



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



Temporal constraints are included in OAI-PMH. Spatial constraints have also
been suggested by Tom in the following answer and I accept that. But keep in
mind: To me the difference between an online-query and a harvesting protocol
is, that the latter only needs to gather a complete and perhaps a
differential set of records (that's what OAI-PMH obviously offers). This
does not exclude that the OAI-PMH (search) service providers can offer
spatial constraints.



> I guess being able to say 'OAI-PMH compatible' is a win?



Yes, definitively: Google accepts it and work seems to be done in spec. and
implementations since years in this information retrieval area.



> 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? ;)



Yeah! I have waited for years to hear such words in ISO/OGC
standardization... (keep in mind that every second content model of ISO/OGC
is still crafted by hand in XML schema instead of being model-driven).



I agree that it should be data-driven, but look closer:
'ListMetadataFormats' is used with similar semantics like GetCapabilities in
the sense that the OAI-PMH data provider is requested to respond the
metadata schemas it knows. I'd expect that in our context it responds that
it knows Dublin Core ('oai_dc' as mandatory default) as well some geospatial
metadata schemas, where one is the one we have to sketch here (I'd say
Dublin Core plus...).



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



GeoRSS would be nice for syndicating new entries (as Tom suggested) but not
for exchanging 'output content model'. BTW: There exists another spec.
proposal for exchanging search engine results, which is RSS like, called
OpenSearch.



For votes against FGDC (as a namespace or encoding) see above.



[...]

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



OAI-PMH using the basic 6 functions is exactly what I meant.



-- Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20060803/1c51c742/attachment.html


More information about the Geodata mailing list