|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:||Edward C. Zimmermann (ed...@nonmonotonic.net)|
|Date:||Oct 21, 2010 5:40:20 am|
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.
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/