Do you ever wonder what data is actually stored in your Verity k2 collections? Oh, sure, you probably have a list of the documents which you submitted for indexing; and if you're like a few of the customers we work with, you even analyze your index logs to determine which documents did not successfully index. And you may even know why they didn't index. But seriously: do you know exactly what content you have in all of the fields of your collections?
Using a custom thesaurus in Verity K2 is a powerful way to provide relevant results for your users, especially when you have a specialized vocabulary in your organization that your end users may not know well. The problem is that you either need to count on your users knowing enough to use the operator on their queries; or you need to do your own query tweaking to expand your user queries. The former is not likely, and the latter adds to your query processing.
It's good to use the browser based Dashboard when you can, but if you are a hard core command line person, help is on the way.
This month's question comes form a customer who switched from a Unix platform to Windows 2000 for a K2 5.5 Verity installation and ran into an unexpected problem: the scripts that had worked fine with Vspider on Unix no longer worked on Windows!
An old support adage is When you're sure everything is right, and it still doesn't work, something you are sure of is wrong.
Sometimes you'll find that a new program you are writing using the VSearch object in K2 is just not working the way you expect. Either it's not finding your Java classes, or the server isn't responding, and you'd really like to know what parameters K2 is using when it initiates the VSearch object.
The Verity K2 Dashboard is a great way to manage your K2 installation, but sometimes you just need to know one small detail and you don't need to go to the length of starting the dashboard, giving the password, and poking through menus to find the nugget you needed to know.
The Verity K2 engine supports a user-defined thesaurus capability that allows users to define synonyms for specific terms. Once enabled, a search that uses the operator will expand to include documents that include the defined synonyms defined in the custom thesaurus.
The rcvdk and rck2 utilities are great tools.
rcvdk is the older tool, and is used to directly open collections. It lets you search collections and browse results to confirm that collections are being built the way you think they are. If you are writing code to programmatically access Verity collections, rcvdk lets you cross-check the results you see with your code so you can insure your code is working right. You run rcvdk from the Verity ~bin directory on the machine where the collections reside.
If you’ve been monitoring the search activity on your web site, you’ve probably noticed that there are two kinds of searcher: those that use one or two words to locate a particular document; and those that use very long queries to try to home in on exactly the document they want. Unfortunately, neither type of query is very useful in really locating answers.
Luckily, most enterprise search technology allows you to pre-process user queries before they get to your search engine, and by intelligently processing user queries, you can greatly enhance the changes that the right document will show up near the top of the result list.
NIE Enterprise Search: Issue 3 - July, 2003 If your company owns Verity K2 enterprise search, one of the features for high availability and load-balancing situations is called collection mirroring, which enables identical collections to be accessed on two Verity K2 servers simultaneously. To mirror collections you need a minimum of two K2 servers in your search engine architecture. The collections must also be named identically on both servers in order to enable mirroring.