[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