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

[Sean Gillies]

Cameron Shorter wrote:
> Andrew,
> I suspect I've missed half this email thread so please excuse me if I'm 
> covering old ground.
> 
> 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
> 
> 2. Explain why the Catalog spec doesn't suite your requirements. (Too 
> verbose?)
> 

OpenSearch embraces the web while the OGC Catalog tries (pointlessly) to 
abstract away the web. OpenSearch fits naturally with Atom/Atompub and 
OGC Catalog does not. OpenSearch is for the Web. CSW is not. That's it 
in a nutsell.

(And then there's the silliness about having to click through a license 
agreement to read the Catalog spec.)

Sean


> 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.
> 
> Stefan Keller wrote:
>> Andrew, was nice to meet you in Victoria! I've just posted a list of 
>> possible protocols at 
>> http://lists.eogeo.org/mailman/listinfo/dclite4g including OpenSearch 
>> but put a remark "fit-for-use" after it. Let me explain this.
>>
>> I like OpenSearch being simple and well integrated in RSS/JSON and I 
>> think it's fit-for-use to programmatically describe search engines' i) 
>> query syntax, ii) response encoding and iii) make then discoverable.
>>  
>> My main concern is about how OpenSearch was meant to exchange machine 
>> readable geo metadata? OpenSearch as I understand it is about search 
>> engine result pages (SERPs in SEO lingo). But these results are mainly 
>> links to human readable resources ( i.e. web applications) and neither 
>> machine readable URLs like datasets (e.g. geodata) nor services (e.g. 
>> WMS), right?
>>  
>> Assuming it's also meant for this, let me sketch out what would be needed:
>>  
>> There is no part which which defines the semantics of such URLs and no 
>> machine readable encoding which indicates if a found item is a i) 
>> webapplication, ii) a dataset (like KML, Shapefiles) or a iii) service 
>> like WMS (or Web Processing Services or a SOAP service...).
>>  
>> In addition, to me something like a subset of Dublin Core (dc:) is 
>> also needed. So, looking at the item element of a OpenSearch query 
>> response record we find title (= dc:title or dct:abstract), link 
>> (dc:identifier), description (dc:description) and even a bounding box 
>> if we take a GeoRSS ecoding. What's perhaps missing are (RSS) 
>> equivalents to dc:type (dataset or service), dc:format (KML, RSS, 
>> shapefile) and perhaps dc:rights ( e.g. Creative Commons By 
>> Attribution - No Derivatives).
>>  
>> -- Stefan
>>  
>> 2007/6/15, Andrew Turner <ajturner at highearthorbit.com 
>> <mailto:ajturner at highearthorbit.com>>:
>>
>>     Greetings - as some of you may know - from WhereCamp - we rapidly put
>>     together a draft specification of OpenSearch-Geo. We did it with
>>     DeWitt Clinton - the original mastermind behind OpenSearch, and had
>>     general consensus in the group.
>>
>>     I've posted the draft here - with some modifications:
>>     http://www.opensearch.org/Specifications/OpenSearch/Extensions/Geo/1.0/Draft_1
>>
>>     I would definitely like any more feedback or thoughts people could
>>     offer on the spec. The guiding principle behind the spec was to make
>>     it work with existing services where possible (hence the bbox w,s,e,n
>>     order) and also make it parallel to GeoRSS and GeoJSON.
>>
>>     This makes it easier for all the specs to try and move forward
>>     together in the future (we can argue concepts/terminology once and
>>     have it apply to all) as well as educating other developers and users
>>     by being able to instruct once and have common concepts carry over to
>>     the different "formats".
>>
>>     I figured Friday afternoon - you're all looking for some interesting
>>     reading and the weekend to play with it. :)
>>
>>     Thanks
>>     Andrew
>>
>>     --
>>     Andrew Turner
>>     ajturner at highearthorbit.com
>>     <mailto:ajturner at highearthorbit.com>      42.2774N x 83.7611W
>>     http://highearthorbit.com
>>     <http://highearthorbit.com/>              Ann Arbor, Michigan, USA
>>     _______________________________________________
>>     georss mailing list
>>     georss at lists.eogeo.org <mailto:georss at lists.eogeo.org>
>>     http://lists.eogeo.org/mailman/listinfo/georss
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mass-Market-GEO mailing list
>> Mass-Market-GEO at opengeospatial.org
>> https://mail.opengeospatial.org/mailman/listinfo/mass-market-geo
>>   
> 
>