If you do a search on the Author-it Yahoo Group about indexing, you will find a wide array of knowledge about some of the best ways to set up indexes especially when you have multiple deliverables.
If you do a Google search for Author-it and indexing, you find out about the Author-it Xtend™ Indexing Service, but that’s not what this post is about. This post is about indexes on sub-books, the kind that give you page numbers, or links to HTML help files in an Index tab.
Indexing is as much art as craft as this Future of Indexing article states so well, and has a wonderful storied history in taxonomy, metadata (or metacrap as Cory Doctorow so eloquently pens), and the Dublin Core metadata model. Not exactly a simple endeavor, to provide keywords and synonyms and figure out which terms to use as sub-entries and duplicate as primary entries.
On the Yahoo Group, Sue Heim has suggestions about using index objects within index objects, nesting the indexes within one main index. Author-it is smart enough to merge multiple index entries no matter what the output. Here’s the general setup for an example set of two books, one for Windows, one for UNIX:
Main index object built with the two index objects listed below plus any index entries that are common to each book, and then also:
- index object for Windows-based book containing entries just for that sub-book
- index object for UNIX-based book containing entries just for that sub-book
Each book uses the main index object. This strategy sounds flat-out brilliant to me, and would certainly make for more manageable indexes (indices? But that sounds oh-so-formal and this is a blog for goodness sake.)
Author-it index object maintenance
One maintenance problem that I’ve run into and found a solution for is that sometimes index entries seem “hidden.” I’ll try to delete an index entry and Author-it tells me it’s in use somewhere, typically in this gigantic comprehensive index we’re using (because we haven’t yet implemented the cool sub-index idea). I’ll open the comprehensive index but can’t see the particular entry I want to delete because it’s a sub-entry to another entry, and it may not be named as logically as I’d like.
So, I export the comprehensive index to XML, and open the XML file in a text editor and search for the index entry object’s ID.
The Object ID is typically the second hit when you search for an Object ID because the beginning of the index has a listing of just Object IDs. You’ll be able to figure out what the primary entry is then, as this screenshot below shows.
Once you determine what the primary entry is, you can delete it in the comprehensive Index object, which then unhooks the dependency and you can delete the original Index entry object that you intended to delete. Whew! What are some of your tips and tricks for index maintenance in Author-it?