10 messages in org.oasis-open.lists.search-ws-commentRE: [search-ws-comment]DisplayTerm //...| From | Sent On | Attachments |
|---|---|---|
| LeVan,Ralph | Oct 20, 2010 8:04 am | |
| Edo Plantinga | Oct 20, 2010 8:29 am | |
| LeVan,Ralph | Oct 20, 2010 8:54 am | |
| Edward C. Zimmermann | Oct 21, 2010 5:40 am | |
| Edo Plantinga | Oct 21, 2010 6:39 am | |
| LeVan,Ralph | Oct 21, 2010 8:21 am | |
| LeVan,Ralph | Oct 21, 2010 8:25 am | |
| Edward C. Zimmermann | Oct 21, 2010 9:11 am | |
| LeVan,Ralph | Oct 21, 2010 10:33 am | |
| Edward C. Zimmermann | Oct 21, 2010 12:10 pm |
| Subject: | RE: [search-ws-comment]DisplayTerm // Forms versus Scan and Facet // was: .... | |
|---|---|---|
| From: | Edo Plantinga (Edo....@ictu.nl) | |
| Date: | Oct 21, 2010 6:39:49 am | |
| List: | org.oasis-open.lists.search-ws-comment | |
To quote Edward: ">>Some my say: "Performance".. Its faster to search for
"n201012345" in my LCCN index than to find "Ralph Levan". "
My take on this (in addition to what Edward says): 1. Performance is not an issue here, as <query> can still include "n201012345" if the server so chooses to handle it for performance reasons. 2. And on top of that: let's not require the client to solve the server's performance problems. As an analogy: I'm sure that for my email server it would be easier if I logged in with a number and not my email adres, but why should I care? Somebody else's problem....
Ok, let's try to wrap this up. I believe we all had plenty of opportunities to voice our opinions. Since Edward and me seem to agree about this and both of us already have a working implementation, I think a fair way to do conclude this discussion is to require Ralph to show a pseudo code example to prove his point. Please not that I'm proposing this with the best intentions; I feel this discussion is starting to take too long.
Regards,
Edo
-----Oorspronkelijk bericht----- Van: Edward C. Zimmermann [mailto:ed...@nonmonotonic.net] Verzonden: donderdag 21 oktober 2010 14:43 Aan: Edo Plantinga; LeVan,Ralph CC: Ray Denenberg, Library of Congress; sear...@lists.oasis-open.org Onderwerp: RE: [search-ws-comment]DisplayTerm // Forms versus Scan and Facet // was: ....
In Ralph's example:
On Wed, 20 Oct 2010 11:54:44 -0400, LeVan,Ralph wrote
<terms> <term> <actualTerm>n201012345</actualTerm> <displayTerm>Ralph LeVan</actualTerm> </terms> </facet>
In this example, there is no index that supports looking up names. There is only an LCCN index. LCCN is worthless for display to the user.
Ralph
I agree that the cryptic n201012345 is "worthless" for anyone not intentionally searching a LCCN index (knowing the numbers) but might also suggest that a display of "Ralph LeVan"
OK.. Pretend that there are more than one "Ralph LeVan" then a search won't return just the LCCN = n201012345 Ralph but the others.. On the other hand a scan would also return a collection of what on the display level is a list of multiple "Ralph LeVan"s but with different LCCNs.
Pretend that our target has ONLY a single index: an LCCN index. Somehow we are associating Ralph LeVan with n201012345 and thus it does not matter if there is some table/relation/index in the system that associates n201012345 with Ralph LeVan or there would not have been the possibility to return Ralph LeVan in the <DisplayTerm> associated with the value n201012345 as its stored in the index. For the implementor in this case its pretty easy: If the term does not meet the syntax of an LCCN then its a name.
The scan of the index as names would produce a list of names.. as LCCNs its a list of ... LCCNs..
Again.. anything goes.. And if having a list of user names is not what the server wants to deliver (or accept) then it does not need to supply them or handle them..
Some my say: "Performance".. Its faster to search for "n201012345" in my LCCN index than to find "Ralph Levan". Maybe.. but surely the resources demanded--- CPU, I/O, bandwidth etc.--- I would suggest are higher in the DisplayTerm model than in what I've proposed, Throw in the architecture of our computers which tend to have for our application I/O bottlenecks and the DisplayTerm looks even more costly...
--
Edward C. Zimmermann, NONMONOTONIC LAB Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts Office Leo (R&D): Leopoldstrasse 53-55, D-80802 Munich, Federal Republic of Germany Telephone: Voice:= +49 (89) 385-47074 Corp.Fax:= +49 (89) 692-8150 Umsatz-St-ID: DE130492967
-- 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: sear...@lists.oasis-open.org Unsubscribe: sear...@lists.oasis-open.org List help: sear...@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/