RE: [search-ws] Fw: Requesting SWG e-votes on CSW 3.0

["LeVan,Ralph" <levan@oclc.org>]

My strong recommendation would be to take the OpenSearch folks' document
as a de facto standard.

Ralph

> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Friday, October 16, 2009 10:00 AM
> To: OASIS SWS TC
> Subject: [search-ws] 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.ht
ml
> > 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
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>