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

[Joshua Lieberman]

Stefan,

Both the discussion here and your query regarding "machine- 
readability" are indicative of the difference between OpenSearch and  
CSW, pejoratives aside. OAI-PMH is an easy interface for wholesale  
harvesting. OpenSearch is an easy way of coding definitions for  
making a text search and returning text plus some metadata about the  
result artifact itself. Limited to those capabilities, CSW is  
actually dirt simple, and it's both a legitimate and a received  
criticism that there should be simpler OGC descriptions for simple  
spec profiles. Once you add different types of structured, e.g.  
machine-readable, information types and structured queries against  
them, and structured relationships between them, all very important  
in some use cases, then greater complexity is inevitable. The key (as  
always) is "as simple as possible but no simpler". [A.E.]

Josh

On Oct 8, 2007, at 9:32 PM, Stefan Keller wrote:

> 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
>
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20071008/d9bcb8a7/attachment-0001.html