Don’t need wildcards? Really?
Wild cards behave differently in 8.5 WorkSite compared to 8.2, now that the IDOL indexer is available. A particular difference is the default use of wildcards in text fields, and in how wildcards affect search results.
With the introduction of Autonomy’s IDOL to the WorkSite suite, a subtle but important change was made to the search functionality for the “text” fields of a WorkSite item. These fields, a.k.a. the magic seven, are now full-text indexed rather than matched letter by letter. There are 4 registry settings to make the client ‘tuned for IDOL’.
If you do not update this setting from its 8.2 default on the desktops, users will be missing out on the automatic stemming and full-text search in the name field. And, the overall performance of searches may suffer!
Read on for performance tips and explanations of the specific settings.
Explanation of: Use (Automatic) Wildcard settings – the first two
The two Use Wildcard client settings are configured to take advantage of IDOL’s full-text behaviour on the description field of document search and workspace searches. Under the hood this means that the automatic insertion of wildcards on those two fields is no longer happening. IDOL can find the word (or words) that you type in that description field anywhere in the description, and will do stemming.
Previously – with the Verity 8.2 indexer – these automatic wildcards were crucial and provided by default, because Verity did not do a full-text search on these description fields. If you wanted to find a word embedded within the description (such as ‘agreement’) using Verity, the wildcards were needed – otherwise Verity assumed you wanted an exact match for only the word ‘agreement’ alone.
To roll out this change, set the following values on desktops:
[HKEY_CURRENT_USERSoftwareInterwovenWorkSite8.0CommonAdvanced Options] "Do not use wildcards"="Y" [HKEY_CURRENT_USERSoftwareInterwovenWorkSite8.0CommonAdvanced Options] "Do not use wildcards WS"="Y"
For Trainers and the Help Desk
If a user needs to, it is possible to change the behaviour for the document searches in the user-interface. Navigate to the WorkSite Options Dialog, Advanced Tab, Options button, and check ON the ‘Add wildcards in description when searching’.
Adding wildcards automatically is not recommended for widespread use with IDOL, because it imposes substantial extra processing load on IDOL to handle a wildcard search. IDOL’s text search of those fields accomplishes the same functional goal that wildcards accomplished with 8.2. We don’t want users to insert wildcards automatically long-term.
Explanation of the ‘Restrict Leading’ settings
These next two settings actually remove the leading wildcard from a description search, even if the user typed the wildcard in deliberately. iManage’s rationale in recommending this setting is to help improve performance.
[HKEY_LOCAL_MACHINESOFTWAREInterwovenWorkSite8.0CommonOptions] "RestrictLeadingWildcardDescriptionSearch"="N" [HKEY_LOCAL_MACHINESOFTWAREInterwovenWorkSite8.0CommonOptions] "RestrictLeadingWildcardDescriptionSearchWS"="N"
Why you might consider going against iManage recommendation:
Stemming is not 100% identical to wildcards. Most of the time, you would consider stemming more accurate. However, leading wildcards might be the only way to locate variations on word spelling, or related words that differ with their prefix. So, use this setting judiciously if it is truly required.
3 thoughts on “Upgrading to iManage IDOL search – taming wildcards”
Hi Sandy, that’s an interesting post – having deployed iManage a very long time ago I have just a couple of questions that I’m hoping you might be able to answer.
Q1: You state that excluding wildcards when using idol has the same functional result as using wildcards with verity – does that hold true for both prefix and suffix plus is it true with regards to words extended with special characters?
Q2: Secondly – the use of preventing wildcards at the beginning of the document description – if you turn that off doesn’t it result in you HAVING to get the first word in the description right? Eg: you may have a description ‘My once in a lifetime opportunity’ but search for ‘once in a lifetime’ – with that setting am I correct in my assumption that I WON’T find my document?
Thanks Sandy.
Kind regards
Scott.
Hi Scott
Cool questions – I’ve added numbers to make this readable. Here goes
Q1: I didn’t mean to imply IDOL-without-wildcards is the identical functional result as Verity-with-wildcards. More, that it will generally do a better job at accomplishing the intended goal. Without wildcards, IDOL will do word-stemming on the words within the description field, and not impose the specific order of terms. In most ways, matching stemmed variations is far more user-friendly than adding wild-cards, because it doesn’t require the searcher to use just the stem in the original search. You could type ‘clarify’ and get matches for ‘clarification’ and ‘clarifies’. Say you are looking for an email and think that the subject was something like Smith clarified his statement. If you provide Smith clarified to IDOL, IDOL will also match Clarification from Josh Smith. No such chance with Verity.
Q2: Nope, IDOL searches the magic 7 text fields without that locked-in dependency on first-word-being-first. With IDOL and no wildcards, it’s a full-on text search of the description field. Continuing with my example, if you just search for clarifies in the description field with IDOL and all the auto-wildcards turned off, it will return matches for all stems of clarifies anywhere in the description. Contrast to Verity and zero wildcards: clarifies matches only those one-word descriptions that are exactly clarifies. With Verity and trailing wildcard, clarifies* matches only those descriptions that begin with exactly “clarifies” followed by anything else.
thx