[OSGeodata] RE: Ready for a lean and mean Catalogue Service Protocol Spec.?

[sfkeller at hsr.ch]

On Jul 20, 2006, at 11:34, Paul Ramsey voted for a user a centred vision
and assembled some important questions towards a (revised) vision and
requirements:
> "What is the user looking for? (web services, in particular the  
> components of services, layers and feature types and coverages).   
> "How are they looking for them? (by keyword, usually, perhaps with a 
> bounding box, occasionally with a service type)" [...]

I agree with most of these. Still, my idea is to define an information
model holding 'data about data' as well as 'data about web services that
deliver data'. 

I like these ideas here
http://www.oaforum.org/tutorial/english/page3.htm especially because of
the 'read only' protocol to harvest metadata which adds lower/additional
requests than a (possibly cascaded) online query.

On 20. Juli 2006 23:40 Anagiotis (Peter) A. Vretanos wrote:
> Stefan,
> The HTTP protocol binding from CSW2 is already heavily based on WFS
and
> includes KVP encodings for most of the requests. [...]
> [...]
> Your specific proposal (i.e. ISO19115/19 and WFS) would be very
> close to the existing ISO profile of the CSW2 specification. [...]

That's right, but there is some evidence that WCS as well as 'ISO
profile of CSW2' seem to be overloaded: The latter has some superfluous
and underspecified bindings. So I still tend to extend Dublin Core
instead of narrowing a bunch of pages and a basket of optional
attributes (ISO 19115/19 with hundreds of referenced pages and specs.).
And WCS' GetRecords (still 205 pages) references the complete Filter
spec. Think about data providers (GML, KML, shape) that shouldn't be
urged to implement/setup a WFS and a (SQL like) filter.

> Personally, I think what makes the current CSW specification "heavy
> weight" is the KVP encoding for the query operation (GetRecords) and
the
> fact that the client needs to know the catalog's information model
> fairly well to even formulate a query.  Not to mention, be familiar
with
> the Filter syntax.
>
> What I think needs to happen is the addition of a new "simplified"
query
> request to the CSW specification leaving GetRecords as the "advanced"
> query operation.

This is the direction I'd like to follow. 

And still, what about this: Why not extending the simple OAI-PMH with
the simple information model (with data and service descriptions) above
as well as a fixed (extended) filter syntax which includes BBOX (no need
for requests to know more about the information model, i.e. no
possibility to filter queries more than with freetext, datetime, bbox,
and 'file and/or service type')? It's notably Google who supports
OAI-PMH too. In this case, care should be taken that automated protocol
binding is still possible (thus the possible restriction to 'service
type')

-- Stefan