RE: [search-ws] Fw: [search-ws-comment] Suggestions

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

"Useful" is a fuzzy concept.  More and more I've come to regret the
baggage we've loaded our work with.  We keep saying that we can hide
that complexity by deferring it to other documents and then resist
having multiple documents.  We make our product so complex that no one
wants to use it.  Compare that to OpenSearch which is so stupid that it
is busted and yet is widely adopted and leaves pretty much everything to
extensions.

I think there is a lesson to be learned there.  Unless we think everyone
is going to want to use this feature, then let's leave it out.

Given that attitude, my first candidate for removal would be result
sets.  Not used by anyone.  (Yes, my server creates and manages result
sets.  Not a single one of the clients that I've written use them.)  But
so many implementors, on reading our documentation, think they have to
implement result sets.

Ralph

> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Monday, December 07, 2009 4:33 PM
> To: OASIS SWS TC
> Subject: Re: [search-ws] Fw: [search-ws-comment] Suggestions
> 
> Anyone else (besides Ralph and me) have an opinion on this?
> 
> My view, which I have stated whenever something of this sort comes up,
is
> that you don't relegate a suggested feature to an extension if (a) the
> standard is still in development, and (b) it is felt to be a useful
feature.
> 
> With regard to the first point, sure, if you have an approved,
official
> standard and someone says "how do you do this" you might say "there is
an
> extension capability" rather than say, "well we'll just amend the
standard".
> But in our case we are still developing the standard so we don't incur
the
> cost of amendment.
> 
> So that takes us to point (b).  If we answer "you can do this as an
> extension" then (if you accept my premise) that says we don't think it
is a
> useful feature.
> 
> I believe that the ability for the server to suggest alternatives when
a
> query results in zero hits is a valuable feature.We talked about this
in
> Z39.50 often, though we never came up with a solution.   I'll back
down on
> my suggestion that this be a first class parameter, and suggest that
we find
> a way to build this into our diagnostic facility.
> 
> I'd like members' views on this.
> 
> --Ray
> 
> ----- Original Message -----
> From: "LeVan,Ralph" <levan@oclc.org>
> To: "Ray Denenberg, Library of Congress" <rden@loc.gov>; "OASIS SWS
TC"
> <search-ws@lists.oasis-open.org>
> Sent: Tuesday, December 01, 2009 10:06 AM
> Subject: RE: [search-ws] Fw: [search-ws-comment] Suggestions
> 
> 
> I'm in favor of leaving this as an extension.
> 
> Ralph
> 
> > -----Original Message-----
> > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> > Sent: Tuesday, December 01, 2009 9:57 AM
> > To: OASIS SWS TC
> > Subject: [search-ws] Fw: [search-ws-comment] Suggestions
> >
> > Nobody has responded to this yet.  Perhaps we could briefly kick
this
> idea
> > around a bit among us?  The suggestion is that the protocol supply a
> way for
> > the server to suggest alternatives when the query results in no
hits.
> (He
> > says "query fails" but I think he means the query failed to locate
any
> > recorrds.)  Would it be a good idea to incorporate a first class
> parameter
> > like the one he suggests? (Rahter than relegate this to an
extension.)
> >
> > --Ray
> >
> > ----- Original Message -----
> > From: "Willem Jan Faber" <WillemJan.Faber@KB.nl>
> > To: <search-ws-comment@lists.oasis-open.org>
> > Sent: Tuesday, November 24, 2009 11:21 AM
> > Subject: [search-ws-comment] Suggestions
> >
> >
> > Hi all,
> >
> >
> > I'm currently prototyping a new SRU server for the KB, and looking
at
> > the new specifications for SRU,
> > I could not find anything which gives a suggestion to the user after
> the
> > query has failed.
> >
> > What I did was add an extraResponseData field which give's out a
clue
> to
> > the user : 'did u mean ?'
> >
> >
> > <srw:extraResponseData>
> > <suggestions>
> > <suggestionfor>deeelderr</suggestionfor>
> > <suggestion>deelder</suggestion>
> > <suggestion>feelders</suggestion>
> > <suggestion>dukeelder</suggestion>
> > <suggestion>deelde</suggestion>
> > </suggestions>
> > </srw:extraResponseData>
> >
> > (Currently I'm using the SpellCheckComponent from SOLR to generate
> these
> > result's)
> >
> > Are there any idea's where this should fit in the new SRU standards
?
> >
> > All the best,
> >
> > Willem Jan Faber.
> >
> > --
> > Research & Development || Koninklijke Bibliotheek, national library
of
> > The Netherlands
> >
> > --
> > This publicly archived list offers a means to provide input to the
> > OASIS Search Web Services TC.
> >
> > In order to verify user consent to the Feedback License terms and
> > to minimize spam in the list archive, subscription is required
> > before posting.
> >
> > Subscribe: search-ws-comment-subscribe@lists.oasis-open.org
> > Unsubscribe: search-ws-comment-unsubscribe@lists.oasis-open.org
> > List help: search-ws-comment-help@lists.oasis-open.org
> > List archive:
http://lists.oasis-open.org/archives/search-ws-comment/
> > Feedback License:
> http://www.oasis-open.org/who/ipr/feedback_license.pdf
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > Committee:
> > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws
> > Join OASIS: http://www.oasis-open.org/join/
> >
> >
> >
---------------------------------------------------------------------
> > 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
> >
> 
> 
> 
> ---------------------------------------------------------------------
> 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
>