Aspen Publishers is a New York-based legal publisher and part of the WoltersKluwer Legal-Tax-Business cluster in North America. As it happens, legal texts are prime candidates for XML publishing for several reasons. In the first place, lawyers have fully embraced electronic publications—along with everyone else the internet is the first place lawyers go for research, but they have also eagerly embraced CD-ROM publications unlike other areas of publishing. Many legal texts are consequently good candidates for release in three different formats, On the measure of multipurposing, Aspen handily meets Jon Bosak’s threshold for applying structured markup of 1.6 uses.

And of course legal texts are relatively stable. Many issues of law are pretty much settled, so when new laws are passed, new court cases decided, new regulations promulgated, you’re not usually throwing away the previous text, but instead adding to it or editing it somewhat. This type of authoring also lends itself to inhouse or staff authoring, which facilitates using XML, but for historical reasons and unlike its sister companies Aspen works almost entirely with outside authors and is unable to dictate their working environment.

The first series of books that Aspen put into structured markup shared not only the same design but the same structure as well—a question-and-answer or frequently asked question (FAQ) format. (See Figure 1.) As the 41 titles in this series of AnswerBooks, spanning the full breadth of the law, were migrated into XML, the question arose as to how else take advantage of this fact. Aspen includes a legal-education division, which publishes books for law school classes, and the natural educators’ desire for material customized to specific classes introduced the notion of creating a custom-publishing application. Mixing-and-matching chapters, sections, subsections or even questions into a new book seemed a natural way to take advantage of the different books’ identical formatting and structure. And of course this application was envisioned to generate a single, unified index for any custom publication. ^[1]

At the time this project was first discussed, each book’s Table of Contents and List of Questions ^[2] were being generated programmatically from the XML. Each book’s index, however, consisted of an XML file that was manually edited as entries and references were added or deleted. (See Figures 2 and 3.) Similarly, the “end-tables” (such as the Table of Cases) existed as XML files instead of being generated programmatically. In the body of the book, each question-and-answer pair is contained within a <qagroup> element. The index and end-tables point to the questions by number and not to the page where the question begins, while the Table of Contents (TOC) and List of Questions (LOQ) point to the page containing the question and beginning of the answer.

In a traditional custom-publishing scenario, Aspen could list the books’ contents divided into chapters or segments smaller than chapters, such as sections, subsections and subsubsections, and provide a mechanism for checking off which segments a professor or professional user wanted in the custom publication. This list would then be fed to the pagination application which would assemble the one-off title and an index and format it. Of course, this scenario would depend on Aspen’s converting the index’s XML file into inline references. ^[3] Some publishers actually construct such titles by combining already existing PDFs, automagically generating a unified index. They believe that the TOC hierarchy provides sufficient indication of a segment’s content, at least so far as a professor is concerned.

This crude level of chapter-chunking does not serve the professional user well. Just as a story about a sports star signing a new contract appears in a newspaper’s sports section but is also business topic, many AnswerBook questions have relevance to more than a single topic. In fact, of course, the mere concept of an index acknowledges that the primary hierarchy is not suitable for all types of access into a book’s contents. As Aspen studied the effort to transform the index’s XML file into inline indexing,^[3] these advantages for custom publishing were identified:

At this juncture, Nikita Ogievetsky of Cogitech provided the necessary guidance to steer Aspen towards using topic maps for its custom-publishing application. Topic maps, as he pointed out, derive from indexes, and indexed material translates easily into topic maps. As to their suitability for this project, you can be the judge here.

Cogitech’s Adaptive Classificator framework, [xml2000]developed earlier, formed the basis for the proposed approach. The first step was to separate the question-and-answer content from the back of the book indexes and the so-called end-tables ^[4]. Question-and-answer pairs from all books were collected into a uniform corpus of question-and-answer pairs and kept in an XML repository. All indexes, including the Table of Content (TOC), Back of the Book (BOB) index, glossary, references into IRS publications, etc. would be extracted in the form of topic map associations that point into information resources (e.g., question-and-answer pairs) stored in the content repository. Some additional associations can be inferred based on the topics’ similarity and semantic proximity. Topic maps extracted from all books are to be merged into a single topic map and maintained in a topic map repository. The XML repository can be used for this purpose with some proper normalizations.

Individual books can be reconstructed following TOC indexes. This is possible because associations of each TOC index are scoped with the theme of the original book. As the TOC and qagroups are reconstructed, BOB and other indexes follow. This allows content repurposing and facilitates maintenance of BOB and other indexes.

The merits of this approach become even clearer as one considers its use for custom publishing.. Indexed content of the original books can be used as the basis for the new publication. A book in our framework is a mere collection of TOC associations. So construction of a customized book becomes almost as easy a process as reconstruction of any of the original ones. Steps that are needed are as follows:

Once the conceptual framework was settled, a few requirements were delineated. Namely, any application built would have to accommodate the following editorial needs:

It was recognized that relying on inline indexing would allow qa-numbering to move forward in the book production timeline, closer to print time. This was not a requirement but any easing in the schedule makes life simpler for the editors.

As we built the prototype of Aspen’s BookBuilder custom-publishing application, it was clear that several different users’ needs would need to be considered:

This last item was not part of the custom-publishing notion, but along the way the content navigation model was admired by some of the people responsible for website design.

Specifically, the custom-publishing application included these requirements:

This last requirement is truly what brought Aspen to topic maps.

In the first place, topic maps require close and accurate subject identification for all the occurrences that the topics are going to point to. This is no small requirement, especially as the material you are dealing with moves into the tens of thousands of pages. But, odd as may seem to anyone who has worked in the low-margin world of publishing, book publishers—unlike most businesses—have already invested vast amounts of money to perform this identification. ^[5] That is, they have hired subject-matter experts (subject-matter expert (SME)s) to index their titles, not for building topic maps but for navigating a book by topic. Because this expense has already been incurred, it provides not a barrier to but an incentive for using topic maps, to capitalize on existing investment. In the case of Aspen’s AnswerBook indexes, serendipitously the start- and stop-points of any index entry were already identified, because the index pointed not at a page number but at a qagroup. That meant the inclusiveness of any material could be identified with one hundred percent certainty.

Indexes also contain several useful relationships easily modeled in topic maps—the see and see also relations most prominently. Other relationships will be discussed momentarily.

With this in mind, let us take a look at the prototype for Aspen’s custom book constructor, the Aspen BookBuilder. It utilizes the Cogitative Topic Maps Websites (CTW) framework, an XSLT library for Topic Maps as described in [CTW], [XTM4W], and [XSLTCB]. The prototype was designed for proof of concept and speed of development, and consequently does not represent the final application in many respects. For this prototype, Aspen selected just 5 of its 41 AnswerBook titles and then supplied approximately 20 percent of the questions from these titles. In some cases, questions or index entries were selected because it was clear they had relations that would span across the titles—in other words, the sample material was probably richer than the material as a whole. The five titles—Pension Answer Book, 401(k) AnswerBook, 403(b) AnswerBook, ERISA Fiduciary AnswerBook and Nonqualified Deferred Compensation AnswerBook—were assumed to have related material on benefits and pensions and are in fact marketed as the Panel Pension Library, Panel being an Aspen imprint.

The prototype being demonstrated in Philadelphia is shown in Figures 4, 5 and 6. These are web-based screenshots, reflecting not only the simpler path of developing a web application, but also a reliance on standard technologies such as HTML, CSS and XSLT, as well as XTM. (We hope to demonstrate access to the same underlying topic maps using hyperbolic or star-tree representations but this work was not completed at this paper’s submission time.)

The BookBuilder prototype easily related index entries from five different titles, using XML topic maps to identify the index entries and the basic relationships used to connect associated concepts. Merging of the different topic maps was based on names, but in the actual production arena it was envisoned that published subject indicator (PSI)s would be used for merging. After the application was constructed and the notion extended to other series, the natural fit of this material to this technology became more apparent. First, the atomized nature of the FAQ approach makes it simple to identify the starting and ending point of any topic for inclusion in the custom publication. For many books, a second pass through the index by an SME would need to take place, to map the exact start- and stop-points. Second, the detailed index of the material that is necessary for this approach to work poses no obstacle to technical publishers, who have made huge investments in indexing already. As was noted before, choosing open standards facilitated the development of this project—although to the authors’ knowledge, no index-based custom-publishing application had ever been built before, the Aspen BookBuilder took less than two weeks to construct from requirements list to working prototype. Most of the subsequent work was simply in cleaning up the user interface.

Content repurposing is not just a buzzword in publishing, but in fact one of the essential means for justifying the expenditures for better, richer content. XML, of course, presupposes repurposing as the natural course of events. Whether the topic map methodology described here is used for custom-publishing or small-run narrow-interest republishing or web navigation, it clearly makes separate books into a web of interconnectedness that puts exploration of the material onto a higher level.