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

[Sean Gillies]

Cameron,

The Atom/AtomPub community (Atom is not an acronym) views OpenSearch as 
the way to go, so I don't see much future for CS/W + Atom.

Sean

Cameron Shorter wrote:
> Andrew,
> This email from Peter might answer some of your questions.
> My concern with CS/W complexity has been focused on the EBRIM format 
> returned. Peter tells me that development for an ATOM response (which I 
> assume is simpler) is in the pipeline.
> 
> Panagiotis (Peter) A. Vretanos wrote:
>> Cameron,
>>
>> Though you might find these observations useful.  Feel free to forward 
>> to all the mailing lists in the original message.  I don't want to do 
>> it myself because I am too busy to get into an email debate!
>>
>>
>> Looking at the table of contents of the CSW specification, the part 
>> that overlaps the OpenSearch spec is only about 22 pages (clauses 10.8 
>> and 10.9) which is not too bad.
>>
>> Also, the KVP query invocations for OpenSearch and CSW are different 
>> but not that different:
>>
>> OpenSearch:
>> (I hope I go this right, the templates and the samples seem slightly 
>> different)
>>
>> http://example.com/?
>>        q=New+York+History&
>>        pw=3&
>>        format=atom&
>>        bbox=-74.0667,40.69418,-73.9116,40.7722
>>
>> CSW:
>> http://example.com?
>>        constraint="anyText=New and anyText=York and anyText=History"
>>        startPosition=10&
>>        outputFormat=application/xml+atom
>>        bbox=-74.0667,40.69418,-73.9116,40.7722&
>> ---------------------------------------------------------------------
>>        service=CSW&
>>        version=2.0.2&
>>        request=GetRecords&
>>        constraintLanguage=CQL&
>>        typeName=csw:Record
>>
>> They certainly seem to share a lot of the same ideas.
>>
>> Finally, there is a proposal to add stored queries to CSW so that a 
>> stored query can be defined in CSW that looks pretty darn close to 
>> OpenSearch.
>>
>> Hope this is useful.
>>
>> Ciao.
>>
>> P.S. There is movement a foot in OGC to use a core+extensions pattern 
>> when defining implementation specification.  The idea is to have a 
>> small, easily implementable core and then a set of other documents 
>> that define extensions.
>>
> 
> 
> Andrew Turner wrote:
>> Bringing Mass Market Geo back into the thread and suggesting we drop
>> GeoRSS (since not explicitly pertinent to that list)
>>
>> Can someone who does know the OGC Catalog spec well - and hopefully
>> have actually implemented it once - write up a 1 HTML page description
>> of it with examples - in a similar vein to the OpenSearch-Geo
>> description? It may help shed light on differences/discrepancies etc.
>>
>> I would love to read it.
>>
>> Thanks,
>> Andrew
>>
>> On 10/8/07, Raj Singh <raj at rajsingh.org> wrote:
>>  
>>> OGC Catalog was designed to meet the needs of a vast array of
>>> organizations. Part of the "problem" is in catering to the librarian
>>> community and all their legacy protocol requirements. I'm not part of
>>> the library community, so a lot of the catalog spec seems pointless
>>> to me too, but I hear there's a lot of people who swear by the Z.39
>>> interface.
>>>
>>> But we may have a "jack of all trades, master of none" problem here.
>>> An API that really works well for the Web may need to break away and
>>> have a spec of its own. I'm not sure any interoperability gains from
>>> having one spec can outweigh the advantages of having cleaner,
>>> simpler interfaces for each community.
>>> ---
>>> Raj
>>>
>>>
>>> On Oct 8, 2007, at 4:32 PM, Sean Gillies wrote:
>>>
>>>    
>>>> 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.
>>>>