[georss] [Mass-Market-GEO] OpenSearch Geo - Feedback

[Ron Lake]

See comments in-line.

R

 

From: georss-bounces at lists.eogeo.org
[mailto:georss-bounces at lists.eogeo.org] On Behalf Of Stefan Keller
Sent: October 9, 2007 3:32 AM
To: Cameron Shorter
Cc: georss at lists.eogeo.org; Jim Groffen; Jeroen Ticheler;
mass-market-geo at opengeospatial.org; Mark Leslie
Subject: Re: [georss] [Mass-Market-GEO] OpenSearch Geo - Feedback

 

I'd like to add that CSW i) was mainly designed for being used in
online-queries while OAI-PMH and OpenSearch employs harvesting; 

Harvesting is also a main objective of CSW-ebRIM - not just online
querying - it is a transactional web service that is to support
web-based update,  automated harvesting, and of course web-based
requests (queries).

 

i)                    contains CQL as a query language which is nice but
is a bit to implement; and that in a thread over at OGC's
http://lists.eogeo.org/mailman/listinfo/dclite4g Raj, made a modest
proposal to profile CSW because of this.

The idea of profiling in CSW-ebRIM is a bit of misunderstanding - more a
question of creating extension packages - which are defined WITHIN ebRIM
for supporting specific application domains.  Not a question of
profiling because of complexity.
 

Now what about my initial feedback from 07.10.2007? :->

 

-- Stefan
 

2007/10/9, Cameron Shorter <cameron.shorter at gmail.com>: 

Andrew,
Your comments regarding complexity  ring true for more than just the
Search related specs. And I think the OGC have acknowledged this in 
their moves to engage the mass market.

I don't pretend to know the Opensearch and Catalog specs well enough to
argue for one over the other, but as a developer, I'd love to lever the
research of someone who has. As you note, us developers only want to 
spend half an hour researching specs before we start writing.
I nice little decision chart would be good. "If you want to do A, then
use Spec1 else if ..."
And ideally, this would lead to the refinement of specs to address a 
greater audience.

Re: Complex specs:
I don't think readability has been a focus of OGC spec writers to date.
They have been targeted more toward being unambiguous (like legal
documents). There are a number of things which could be done to the 
documents to make them easier to implement.
Eg:
* Use example XML instead of XML schema to describe formats.
* Move standard disclaimers etc to annexes at the back so core
information is easier to fine.
* ... I'm sure others could add plenty more.

Andrew Turner wrote:
> On 10/8/07, Cameron Shorter <cameron.shorter at gmail.com> wrote:
>
>> Andrew, 
>> I suspect I've missed half this email thread so please excuse me if
I'm
>> covering old ground.
>>
>
> All feedback is welcome.
>
>
>> The OGC has a Catalog specification which addresses search. It can be

>> very verbose and I understand why a simpler standard would be
desired.
>> However, in your draft specification at
>>
http://www.opensearch.org/Specifications/OpenSearch/Extensions/Geo/1.0/D
raft_1
>> I suggest you:
>>
>> 1. Acknowledge the Catalog spec, (and any other related specs).
>> http://www.opengeospatial.org/standards/cat
>>
>
> I will add links to other search and aggregation specs such as CSW and
> OAI-PMH. However I wouldn't expect many people to read in-depth about 
> them.
>
>
>> 2. Explain why the Catalog spec doesn't suite your requirements. (Too
>> verbose?)
>>
>
> OpenSearch has a longer history than my Geo additions. OpenSearch is 
> currently what "powers" Firefox's & Internet Explorer's Search bars. I
> merely added "Geo" and "Time" as extensions to the existing, stable,
> and very widely used spec. This will allow current users of OpenSearch

> to easily add Geo search to their services and aggregation.
>
> To this end, I used as much from other light-weight geo protocols and
> implementations as made sense. This is why it nominally uses the 
> GeoRSS vocabulary, but WSEN bounding box definition based on KML's
> assumed order in NetworkLinks and numerous other services.
>
>
>> 3. Ideally, note how terms in your specification align with Catalog 
>> terms. This will ease implementation for search clients which aim to
>> address both protocols.
>>
>
> What about the reverse? I imagine it would be more likely that someone
> who uses & understands CSW may want to add OpenSearch than the 
> reverse.
>
> The entire point of these specs is to make them lightweight, and
> primarily, attractive & readable. It is tough enough getting a
> developer to read a ~1 page HTML document, let alone downloading a 
> Click-Through-to-access, 204-page PDF with 5 annexes, 13 page
> front-piece, and 37 pages until an actual example is given. I think
> this addresses the "Too Verbose?" question above.
> 
> This isn't a fault of CSW in particular so much as an symptom of a
> much (much) larger misunderstanding between Spec bodies and
> propagators and down in the dirt developers who don't have 2 weeks to 
> read & be experts on specs just to implement a demo.
>
> Rule of thumb when designing a spec that seeks broad adoption,
> especially one that is meant to augment existing data/services - if I 
> can't open the spec and create a demo implementation within, say 30-45
> minutes, then it's too verbose for the 80% use-case.
>
> seems like there would be a market for OGC Spec Cliff Notes :) 
>
> Andrew
>
>
>
>
>


--
Cameron Shorter
Systems Architect, http://lisasoft.com.au
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254 



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20071009/1b718be8/attachment.html