Ready for a lean and mean Catalogue Service Protocol Spec.?

[Stefan F. Keller]

Many thanks for your many reactions. It seems that I hit a need and that
there is some sort of (implicit) agreement that we need a lean and mean
Catalogue Service Protocol Spec but - sigh: where to begin and how to reach
consensus here?



To clarify this at this place: Presumably no one wants to reimplement the
wheel and OGC needs to be kept in the loop. My short term goal is to define
a thesis project to contribute an implementation of such a service.



I'm still thinking forth and back what's better: Either to profile WFS (as
well as profiling the ISO 19115/19119 information model), or to extend
general search protocols like OpenSearch - thus becoming interoperable with
library and search community (did anyone really try to understand OAI-PMH?)
- or ...?



Next I will try to summarize the discussion with requirements, current
implementations and proposals.



-- Stefan



> -----Original Message-----

> From: Panagiotis (Peter) A. Vretanos [mailto:pvretano at cubewerx.com]

> Sent: Donnerstag, 20. Juli 2006 23:40

> Subject: Re: Ready for a lean and mean Catalogue Service Protocol Spec.?

>

> Stefan,

>

> The HTTP protocol binding from CSW2 is already heavily based on WFS and

> includes KVP encodings for most of the requests.  Here are some examples:

>

>

> a) Get a capabilities document:

>

> http://www.pvretano.com/cwwrs/cwwrs.cgi?request=GetCapabilities

>

> b) Describe the information model(s) that the catalog uses:

>

> http://www.pvretano.com/cwwrs/cwwrs.cgi?request=DescribeRecord

>

> c) Execute a query that does searches the record descriptions:

>

>
http://www.pvretano.com/cwwrs/cwwrs.cgi?request=GetRecords&typeNames=Extrinsic

>
Object&ConstraintLanguage=Filter&Constraint=%3Cogc:Filter%20xmlns:ebxml=%22urn

> :oasis:names:tc:ebxml-

> regrep:rim:xsd:
2.5%22%20xmlns:gml=%22http://www.opengis.net/gml%22%20xmlns:ogc

>
=%22http://www.opengis.net/ogc%22%3E%3Cogc:PropertyIsLike%20escape=%22\%22%20s

>
ingleChar=%22_%22%20wildCard=%22%25%22%20matchCase=%22false%22%3E%3Cogc:Proper

> tyName%3E/ExtrinsicObject/Description/LocalizedString/@value
%3C/ogc:PropertyNa

>
me%3E%3Cogc:Literal%3E%25bird%25%3C/ogc:Literal%3E%3C/ogc:PropertyIsLike%3E%3C

> /ogc:Filter%3E

>

> d) Get the repository item associated with the record found in (c)

> (analogous to fetching the book from the library shelf):

>

>
http://www.pvretano.com/cwwrs/cwwrs.cgi?request=GetRepositoryItem&id=urn:uuid
:

> 9f818e6a-08b0-11db-8378-0010dcf5553d

>

> e) Get a specific record from the catalog:

>

>
http://www.pvretano.com/cwwrs/cwwrs.cgi?request=GetRecordById&id=urn:uuid:3748

> cfea-17f9-11db-b340-0010dcf5553d

>

> f) Get the repository item associated with the record from (d):

>

>
http://www.pvretano.com/cwwrs/cwwrs.cgi?request=GetRepositoryItem&id=urn:uuid
:

> 3748cfea-17f9-11db-b340-0010dcf5553d

>

>

> Your specific proposal (i.e. ISO19115/ISO19119 and WFS) would be very

> close to the existing ISO profile of the CSW2 specification.   The ISO

> profile uses the HTTP protocol binding from CSW2 as the API and

> ISO19115/ISO19119 as the information models.

>

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

>

> I have been experimenting with a simpler query request whose KVP

> encoding looks something like this (equivalent to (c)):

>

>
http://www.pvretano.com/cwwrs/cwwrs.cgi?request=GetRecordsBasic&fulltext=birds

>

> NOTE:  My experimental name for the request is GetRecordsBasic and at

> the moment the request returns an XML fragment which may not validate in

> your browser.  So, you may have to view the source to see what was

> generated by the catalogue.

>

> Other parameters on the GetRecordsBasic request include:

>

> BBOX, CLASSIFICATIONNODE, OBJECTTYPE, KEYWORDS, OUTPUTSCHEMA, Temporal

> Operators

>

> The advantage of this request is that the client does not need to be too

> familiar with the catalog's information model in order to formulate a
query.

>

> Comments welcome.

>

> Ciao.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20060721/ae4d5758/attachment.html