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

[Stefan Keller]

I'd like to add that CSW i) was mainly designed for being used in
online-queries while OAI-PMH and OpenSearch employs harvesting; ii) 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.

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/Draft_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/f0b3f619/attachment.html