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

Fri Jul 21 18:26:20 EDT 2006

Jody Garnett wrote:
> He he - my turn.
> 
> CSW-2 is fine (aka very similar to WFS but allows separation of data 
> returned from data queried in case we care):
> - query - filter 1.1 is good, think they even made a BNF text format for 
> it right?

Yes.  Called CQL.  Actually Filter was based on the same BNF as CQL ... 
although Filter includes extensions.

> - query model? query against something really simple. uDig uses 
> something like minimal Dublin core with no multiplicity

Jody, I think you know this already but for the benefit of the others, 
the CSW2 specification already includes a "simplified" information model 
based on Dublin Core.  It is called csw:Record.  The relevant schema 
files can be found at:

http://schemas.opengis.net/csw/2.0.1

See record.xsd, rec-dcems.xsd and rec-dcterms.xsd.

According to the CSW2 specification all catalogs must be able to expose 
their actual information model using csw:Record for query.  However 
there is nothing preventing a catalog from actually being built using 
only csw:Record.

I think two addition entities would need to be add to the record.xsd 
schema in order to make csw:Record useful:

1) As association entity so that catalog records can be associated with 
each other.  This is how we can find out that SERVICE A offers FEATURE 
TYPE B.  This would be a simple entity: SOURCE_ID ASSOCATION_NAME TARGET_ID.

2) A classification entity to that catalog records can be classified 
according to some classification scheme.  This is how we can find all 
WFS services or all ROAD feature types.  Again this could have a fairly 
simple structure: RECORD_ID CLASSIFICATION_NODE

> - data returned? something really simple ... OWSContext contains some 
> basic direct elements which are good.

I would recommend csw:Record.  CSW defines brief, summary and full 
schemas of csw:Record to support various levels of detail.

Ciao.

> 
> Cheers,
> Jody
>>
>> 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 
>> <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 
>> <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 
>> <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 
>> <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 
>> <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 
>> <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.
>>
> 
> 

-- 
Panagiotis (Peter) A. Vretanos          CubeWerx Inc.
Big Kahuna (Senior Database Developer)  http://www.cubewerx.com
Tel. 416-701-1985 Fax. 416-701-9870     pvretano at cubewerx.com

"Black holes are where God divides by zero!" Steven Wright