[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]