[OSGeodata] discovery requirements

[Stefan F. Keller]

Tom suggested stepping back: One of our requirements was that we not only
want to register a static resource but also web services (e.g. WxS). My
dilemma is that services are not really the resource users are looking for!
What's really the goal of dissemination is the geographic data, e.g. raster
maps or the geographic feature object sets or the coverage data.

Either a harvester must identify this geographic service and try to request
it for more information based on the indicated 'proprietary' protocol (WxS
GetCapabilities, SOAP, etc.) or every single geographic data resource needs
to be registered once for every service, be it a 'WMS layer' or a 'WFS
feature set' etc. But isn't this 'duplication' the same with file formats,
like data delivered as GML, SHP, DXF (similar to DOC, PDF, HTML). So: Isn't
this a possible solution?

-- Stefan

P.S. I tried to model this as value 'WxS service...' (tbd.) in Dublin Core
(DC) and found attribute/DC element Type appropriate (see
http://www.geometa.info/rappiinfo/wiki/index.php/OSGeodataMetadataModel). In
terms of metadata records the two variants mean, that in case we register
'service resources', we have one record entry per WxS containing many
hidden(?) geographic data resources. I prefer to register one 'data
resource' record (per data provider) where Type values are repeated (in DC
every attribute can be repeated AFAIK), one entry for every available file
format and one for every service (WxS). If this seems impracticable, there
exist also hierarchical sets in DC.

This dilemma becomes even more evident when different SLD's offer different
'views' on the same data or when future conversion services exist! But
still: To IMHO there are too many open questions regarding service
description (quality rating as Paul mentioned?) and service chaining. This
does not mean that registering these types of services is prevented in the
solution I suggest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20060805/afe39e96/attachment.html