[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] Fw: [search-ws-comment] Suggestions
I do have to agree with Ralph here: > 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 have a direct analogy for us in the OpenURL work. There there was a de facto (SFX) spec in operation which was taken to NISO for fast track standardization. Some 3 years (and more) later NISO emerged with a much more generalized model for OpenURL which built in various addition such as registries, communities, transports, formats, etc. We even tackled identifiers head on and registered a URI scheme 'info:' against the prevailing determination. And in practice, the simple original OpenURL format is the one still in the widest use. But even closer to home look at SRW and web services. Truth is people shun complexity. I even wonder about some of the already included features such as Search Result Analysis. So I would definitely relegate Suggestions to an application/extension level status. Tony On 7/12/09 21:42, "LeVan,Ralph" <levan@oclc.org> wrote: > "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 >> > > > > --------------------------------------------------------------------- > 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 > ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]