OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fw: Requesting SWG e-votes on CSW 3.0


I am forwarding this thread with permission from Doug Nebert. Please do not 
share outside of the TC.  This is what started the discussion yesterday.
--Ray

----- Original Message ----- 
From: "Doug Nebert" <ddnebert@usgs.gov>
To: "Pedro Goncalves" <pedro.goncalves@terradue.com>
Cc: "Carl Reed" <creed@opengeospatial.org>; "Farrukh Najmi" 
<farrukh@wellfleetsoftware.com>; "Panagiotis (Peter) A. Vretanos" 
<pvretano@cubewerx.com>; "Andrew Turner" <andrew@fortiusone.com>; "Jo(anna) 
Walsh" <jo@frot.org>; "Ray Denenberg, Library of Congress" <rden@loc.gov>
Sent: Thursday, October 15, 2009 1:46 PM
Subject: Re: Requesting SWG e-votes on CSW 3.0


> Pedro Goncalves wrote:
>> hi carl,
>>
>> yes, you're right, that's probably the best solution
>> do you/anyone has his contact?
>>
>> So, to really be able to make a decision on tomorrow's vote (questions 2) 
>> we should really clarify this first and probably put this discussion on 
>> the list ... no ?
>>
>
> The institutional questions need to be resolved:
>
> 1. opensearch.org is a de facto standard with no maintenance authority and 
> no official standing in the standards community. It includes all protocol 
> and schema information to allow implementation and also specifies search 
> by geospatial terms.
>
> 2. OASIS Search Web Service (SWS) does not seem to have much activity 
> (wiki started in mid year, no activity; dead links to search-ws documents) 
> but claims to be fully compatible with OpenSearch version 1.1, Draft 3. It 
> appears to be a binding specification, but the document is unavailable. 
> SWS is also a draft but does not yet have a Committee Draft available. 
> Interesting blog discussion on OpenSearch and SRU: 
> http://www.crossref.org/CrossTech/2009/06/aligning_opensearch_and_sru.html 
> We need to review the OASIS CD on the opensearch binding and determine 
> whether it is a standard that effectively translates the opensearch.org 
> site into standard form, or only complements it.
>
> 3. How does the OGC leverage non-SDO-developed standards as dependencies?
>
> 4. Can the OGC adopt draft versions of SDO or non-SDO standards as a 
> dependency?
>
> 5. If the SWS CD on opensearch does not completely incorporate the 
> opensearch spec, then can the OGC reformat and promulgate it as a first 
> order standard?
>
> If referencing OpenSearch.org as a defacto standard is good enough for OGC 
> standards, and since OpenSearch.org already details how to use -geo 
> extensions completely, then OGC only needs 09-084 as a Best Practice 
> document to explain how OGC services could exploit such capabilities. Note 
> that the extension proposal proposes use of KML whereas opensearch.org 
> specifies Atom, GeoRSS, and HTML as response formats. I would add KML to 
> the list, but not be exclusive.
>
> If possible, the 09-084 extensions proposal should refer completely to 
> opensearch.org and describe as a "Best Practice" how OGC services could 
> take advantage of that definition through examples. Similarly, CSW could
> reference the pseudo-spec, but we need to work out the governance issues 
> first.
>
> Doug.
>
>>
>> ciao
>>
>> Pedro
>>
>>
>>
>> On Oct 15, 2009, at 6:49 PM, Carl Reed wrote:
>>
>>> This is my understanding also.
>>>
>>> At this point, OpenSearch appears to be defacto standard with 
>>> significant implementation.
>>>
>>> We could ask Ray Denenberg (Chair ws-search) what is understanding is of 
>>> this issue.
>>>
>>> All this said, there is no reason that the OpenSearch Geo extension 
>>> cannot be vetted by the OGC and moved forward.
>>>
>>> Regards
>>>
>>> Carl
>>>
>>> ----- Original Message ----- From: "Farrukh Najmi" 
>>> <farrukh@wellfleetsoftware.com>
>>> To: "Pedro Goncalves" <pedro.goncalves@terradue.com>
>>> Cc: <ddnebert@usgs.gov>; "Panagiotis (Peter) A. Vretanos" 
>>> <pvretano@cubewerx.com>; "Andrew Turner" <andrew@fortiusone.com>; "Carl 
>>> Reed" <creed@opengeospatial.org>; "Jo(anna) Walsh" <jo@frot.org>
>>> Sent: Thursday, October 15, 2009 10:39 AM
>>> Subject: Re: Requesting SWG e-votes on CSW 3.0
>>>
>>>
>>>>
>>>> Dear colleagues,
>>>>
>>>> Although I proposed adding an OpenSearch binding to Search-WS and 
>>>> contributed the early drafts of the OpenSearch binding I have not been 
>>>> involved for some time with that work.
>>>>
>>>> The Search-WS TC faced the same dilemma that OpenSearch was not a 
>>>> standard so how could they reference it normatively. One approach was 
>>>> to clone OpenSearch spec as part of their spec (which creates a fork 
>>>> from the master version). Another approach was to approach the 
>>>> OpenSearch community to standardize OpenSearch at OASIS. During the 
>>>> discussions with Dewitt Clinton (author) I recall there not being much 
>>>> interest in standardizing at OASIS. Instead I got the impression Dewitt 
>>>> wanted to take it to IETF. AFAIK that has not happened yet and the spec 
>>>> continue to thrive defacto. Looking at the latest Search-WS OpenSearch 
>>>> binding dated Feb 21:
>>>>
>>>> <http://www.oasis-open.org/apps/org/workgroup/search-ws/download.php/27293/opensearch%20binding.doc>
>>>>
>>>> I cannot determine that they have subsumed and forked the spec and 
>>>> whether the above spec is normative or not. If the answer is YESY and 
>>>> YES, then our proposed OpenSearch binding could normatively reference 
>>>> the above spec. Otherwise we are in the same dilemma as SearchWS TC at 
>>>> OASIS.
>>>>
>>>> One possibility is to define an OpenSearch binding and declare it as 
>>>> non-normative and state the reason is the lack of standard status for 
>>>> OpenSearch.
>>>>
>>>> Thoughts?
>>>>
>>>> Pedro Goncalves wrote:
>>>>> Hi Doug, all
>>>>>
>>>>> I originally thought that OASIS would take care of the opensearch spec 
>>>>> (and not parts)
>>>>> from the OASIS page I understood that in fact they were 
>>>>> redoing/copying the opensearch ...
>>>>> and as such we could just reference it (and not the opensearch.org 
>>>>> link) and concentrate on the extensions that we need (this was mine 
>>>>> and jo's rationale on the all thing)
>>>>>
>>>>> for example they say
>>>>> "
>>>>> This binding is the specification of OpenSearch.
>>>>> This binding is intended to be fully compatible with 
>>>>> http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_3
>>>>> "
>>>>> and then they actually do a "copy paste" of the contents of the 
>>>>> opensearch.org web page
>>>>> Probably I'm missing the point here but is there a real error/problem 
>>>>> to take that as a starting point, reference it and just produce a spec 
>>>>> with the geo contents in it ?
>>>>>
>>>>> I added Farrukh (as one of the authors of the OASIS opensearch 
>>>>> binding) just to ask him if I'm misunderstanding the OASIS's role in 
>>>>> all this?
>>>>>
>>>>> In the end, if our initial logic was wrong, and we can't just 
>>>>> reference it, then I suppose that the alternative is to pick it up in 
>>>>> its entirety
>>>>> but wouldn't this make a new and separate opensearch branch ?
>>>>>
>>>>> ciao
>>>>>
>>>>> pedro
>>>>>
>>>>> On Oct 15, 2009, at 5:01 PM, Doug Nebert wrote:
>>>>>
>>>>>> Panagiotis (Peter) A. Vretanos wrote:
>>>>>>> Got it ... I vote that we should just pick it up outright if we can.
>>>>>>
>>>>>> So, an alternative is that we, on behalf of OGC, pick up the entirety 
>>>>>> of opensearch(-geo) and convert it fully (not just geo extensions) 
>>>>>> into an OGC spec format and move it through the OGC process, just as 
>>>>>> we did with KML. Then it would be a supported standard with a 
>>>>>> maintenance authority, unlike the pieces at OASIS and opensearch.org. 
>>>>>> it would mean that we would require the support of Atom/RSS response 
>>>>>> with optional other formats, like KML, and definitely including 
>>>>>> search by bbox.
>>>>>>
>>>>>> Then, other OGC specs could specialize the interface by providing 
>>>>>> well-known query terms, related items, and examples required by the 
>>>>>> solution, such as CSW.
>>>>>>
>>>>>> The benefit of this approach would be that the standard is 
>>>>>> maintained, clearly bounded, and can be referenced by other 
>>>>>> standards. The downside to the proposal would be waiting for the 
>>>>>> RFC-to-standard process before we could 'correctly' incorporate 
>>>>>> opensearch into CSW and other specs. We could do them in parallel, 
>>>>>> but then it strikes me that 3.0 couldn't be approved until 
>>>>>> opensearch-geo were approved due to spec dependencies.
>>>>>>
>>>>>> Let's wait for the votes to come in and then encourage discussion on 
>>>>>> this item with the wider 3.0 group.
>>>>>>
>>>>>> Doug.
>>>>>>
>>>>>>> Doug Nebert wrote:
>>>>>>>> Panagiotis (Peter) A. Vretanos wrote:
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> Pedro is correct...
>>>>>>>>>
>>>>>>>>> 08-169 is just a change proposal and not a specification and will 
>>>>>>>>> eventually be applied to CSW.
>>>>>>>>>
>>>>>>>>> The thing that confuses me is what we do about 09-084 and any 
>>>>>>>>> other opensearch extensions we propose?
>>>>>>>>>
>>>>>>>>> Do we make them OGC specifications? Now that I think about it ... 
>>>>>>>>> can we make them OGC specifications?
>>>>>>>>>
>>>>>>>>
>>>>>>>> See my last email. I think there needs to be an official full 
>>>>>>>> standard somewhere, but it's in pieces with no maintenance 
>>>>>>>> authority. Somewhat awkward for us to normatively reference a 
>>>>>>>> non-standard and a draft abstract OASIS spec as a baseline for our 
>>>>>>>> extensions. I think we either need to pick it up and own the whole 
>>>>>>>> thing outright (as KML) or identify embedded "best practices" in 
>>>>>>>> our specs, including CSW, how to adopt opensearch-geo-compatible 
>>>>>>>> interfaces in an informative way.
>>>>>>>>
>>>>>>>>> If we can make them OGC specifications, do we have a separate 
>>>>>>>>> "Opensearch for OGC" specification based on 09-084 and 08-169? ... 
>>>>>>>>> or do we put all this into a clause or annex of CSW 3.0?
>>>>>>>>>
>>>>>>>>> If we cannot make them OGC specification, how do we feed our 
>>>>>>>>> proposed changes back to opensearch.org? I don't think they have a 
>>>>>>>>> formal change request process ... do they? I guess we can email 
>>>>>>>>> the authors of the relevant Opensearch extensions.
>>>>>>>>>
>>>>>>>>> Comments?
>>>>>>>>>
>>>>>>>>> Ciao.
>>>>>>>>>
>>>>>>>>> Pedro Goncalves wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Oct 14, 2009, at 3:33 PM, Doug Nebert wrote:
>>>>>>>>>>
>>>>>>>>>>> Lorenzo Bigagli wrote:
>>>>>>>>>>>> Doug,
>>>>>>>>>>>> Could you please provide me with a few clarifications (see the 
>>>>>>>>>>>> questions inline)?
>>>>>>>>>>>
>>>>>>>>>>>> 08-057 propose to support OpenSearch for "baseline" CSW: what 
>>>>>>>>>>>> is intended with "baseline"?
>>>>>>>>>>>> Is it: "Catalog abstract information model"+"General catalog 
>>>>>>>>>>>> interface model" (CS 2.0.2 chapters)?
>>>>>>>>>>>> To my understanding, this "baseline" catalog is unrelated to 
>>>>>>>>>>>> any binding, so "baseline" CSW (the HTTP binding of CS) seems 
>>>>>>>>>>>> confusing.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> "baseline" means the complete CSW 2.0.2 implementation without 
>>>>>>>>>>> any additional profiles or extension packages. This is common 
>>>>>>>>>>> functionality that must be supported by all CSW implementations 
>>>>>>>>>>> regardless of profile (or even without a profile). It defines 
>>>>>>>>>>> core queryables, query message, response message syntax, based 
>>>>>>>>>>> on Dublin Core related fields plus spatial. Having a "baseline" 
>>>>>>>>>>> or core capability allows a client to query any catalog by any 
>>>>>>>>>>> profile without having to know the extended profile-specific 
>>>>>>>>>>> details, improving interoperability.
>>>>>>>>>>>
>>>>>>>>>>>> Besides, what is the mentioned OpenSearch-geo interface 
>>>>>>>>>>>> prototype?
>>>>>>>>>>>> Do you refer to 08-169?
>>>>>>>>>>>> Is 08-169 being considered for the harmonization?
>>>>>>>>>>>
>>>>>>>>>>> 08-169 is Peter Vretanos initial response to the general change 
>>>>>>>>>>> request (08-057) as to how to deploy OpenSearch in CSW. As I 
>>>>>>>>>>> understand it, Peter has since volunteered to update this 
>>>>>>>>>>> documentation to better include the full opensearch-geo 
>>>>>>>>>>> specification into CSW - the subject of Pedro's proposal. My 
>>>>>>>>>>> recommendation is that we not have two separate opensearch-geo 
>>>>>>>>>>> specifications in OGC, the subject of 2.a below.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My understanding on this issue was that the Peter's plan was to 
>>>>>>>>>> work together with us to remove all the OpenSearch parameter 
>>>>>>>>>> descriptions of 08-169 and reference 09-084. Then develop 
>>>>>>>>>> separately any the OpenSearch extensions of 08-169 and deprecate 
>>>>>>>>>> the document in the end.
>>>>>>>>>> The time frame for this was the next TC.
>>>>>>>>>>
>>>>>>>>>> The rationale of all this was to have simpler separated 
>>>>>>>>>> extensions
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> Three related items:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.a Shall the OpenSearch-geo interface for Catalog services 
>>>>>>>>>>>>> (08-057),
>>>>>>>>>>>>> which implements OpenSearch-geo as a Catalog 3.0 "baseline" 
>>>>>>>>>>>>> capability,
>>>>>>>>>>>>> incorporate and replace OGC 09-084?
>>>>>>>>>>>>> [ ]Yes [ ]No [ ]Abstain
>>>>>>>>>>>> It doesn't seem to me that 08-057 implements the OpenSearch-geo 
>>>>>>>>>>>> interface (the Change Request does not seem to mention a 
>>>>>>>>>>>> specific interface).
>>>>>>>>>>>> What is the effect of voting "No" to this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.b Shall CS 3.0 support OpenSearch-geo as a mandatory 
>>>>>>>>>>>>> behavior for
>>>>>>>>>>>>> "baseline" and profile implementations?
>>>>>>>>>>>>> [ ]Yes [ ]No [ ]Abstain
>>>>>>>>>>>> See the question on point 2.
>>>>>>>>>>>> Is OpenSearch considering other protocols than HTTP?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2.c Shall the current "baseline" GetRecord and csw:Record 
>>>>>>>>>>>>> response be
>>>>>>>>>>>>> retained as an optional capability for backwards 
>>>>>>>>>>>>> compatibility?
>>>>>>>>>>>>> [ ]Yes [ ]No [ ]Abstain
>>>>>>>>>>>> What is the effect of voting "No" to this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3. Uwe Voges of con terra has volunteered to co-chair the 
>>>>>>>>>>>>> Catalog 3.0
>>>>>>>>>>>>> SWG. Do you approve Uwe Voges to be co-chair of the Catalog 
>>>>>>>>>>>>> 3.0 SWG?
>>>>>>>>>>>>> [ ]Yes [ ]No [ ]Abstain
>>>>>>>>>>>>>
>>>>>>>>>>>>> Doug.
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> Douglas D. Nebert
>>>>>>>>>>>>> Senior Advisor for Geospatial Technology, System-of-Systems 
>>>>>>>>>>>>> Architect
>>>>>>>>>>>>> FGDC Secretariat T:703 648 4151 F:703 648-5755 C:703 459-5860
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>> Dott. Lorenzo Bigagli
>>>>>>>>>>>> Istituto di Metodologie per l'Analisi Ambientale
>>>>>>>>>>>> del Consiglio Nazionale delle Ricerche (IMAA-CNR)
>>>>>>>>>>>> i: Area della Ricerca di Potenza, Contrada Santa Loja
>>>>>>>>>>>> Zona Industriale, 85050 Tito Scalo (PZ), Italia
>>>>>>>>>>>> t: +39 0971 427221
>>>>>>>>>>>> f: +39 0971 427222
>>>>>>>>>>>> m: bigagli@imaa.cnr.it
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Douglas D. Nebert
>>>>>>>>>>> Senior Advisor for Geospatial Technology, System-of-Systems 
>>>>>>>>>>> Architect
>>>>>>>>>>> FGDC Secretariat T:703 648 4151 F:703 648-5755 C:703 459-5860
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Douglas D. Nebert
>>>>>> Senior Advisor for Geospatial Technology, System-of-Systems Architect
>>>>>> FGDC Secretariat T:703 648 4151 F:703 648-5755 C:703 459-5860
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Regards,
>>>> Farrukh
>>>>
>>>> Web: http://www.wellfleetsoftware.com
>>>>
>>>
>>>
>>
>>
>
>
> -- 
> Douglas D. Nebert
> Senior Advisor for Geospatial Technology, System-of-Systems Architect
> FGDC Secretariat   T:703 648 4151    F:703 648-5755    C:703 459-5860
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]