Ideally, metadata statements should be fine-grained and diverse to accommodate all kinds of questions. In practice, monetary constraints limit the level of detail that can be reached. The aim is to balance the effort that is made by the site owner and the benefits for site visitors. A layered model is an instrument to determine what priorities need to be set and what investments yield the largest effect.

The first level consists of basic full-text search provided by a search engine. At this level, most search engines allow for grammatical tricks like stemming. After relatively easy setup and installation steps, the search engine functions more or less automatically and only needs systems management attention.

The second level deals with enriching the querystring entered by a user. Candidates are synonyms and possibly hierarchical relations. Synonyms play a key role in bridging the gap between site vocabulary and the documents that they are looking for. An example is the difference between the popular Dutch term "leaseauto" (company car) and the legal term "auto van de zaak". Synonyms are harvested by specialists and loaded into the search engine. Once loaded, the process is done fully automatic.

The third level is about enriching (groups of) documents with metadata statements. This is the most labor-intensive strategy. To ensure consistency, authors should pick values from a controlled list. Whenever possible, metadata statements should be assigned to groups of documents, as this can be done with little effort. Tagging individual documents is a strategy of the last resort.

There is an art to describing documents with metadata in such a way that visitors are able to find what they want. Librarians have been performing this trick for ages, and it is therefore only fitting that website architects turn to approaches from the library sciences. Facetted classification is an example of a library science technique that was rediscovered in the context of web sites. Peter Morville [Morville, P. 2001] uses the example of an e-commerce wine seller that describes each bottle by several "facets" (year, price, region, color). Each facet contains values from an enumerated list (color: red, white, rose) or a hierarchy (region: Europe, France, Bordeaux).

The main advantage of facetted classification is the avoidance of deep hierarchies that sometimes characterize classical thesauri. This reduction of complexity does not lead to fewer possibilities for the end-user. By combining facets, powerful queries can be constructed: "give me all red wine from France that costs less than 5 Euro". This example highlights the way hierarchical information is used. The value "France" is not assigned to any bottle, but resolved by a query engine because of the hierarchical relationship to all French regions that are connected to bottles.

Morville's wine example works well for explaining what facetted classification looks like, but turns out to be a bit deceptive. Key to its simplicity is the fact that the units (the bottles) are homogeneous, all facets are relevant to all units, and the facets are clearly separated. In our case, the documents that are part of the website are less homogeneous, which implies that not all facets will be applicable to all documents. Also, a clear separation of facets was hard to find, which ultimately meant we had to trade in analytical clarity for practical applicability.

As it is expensive to change facets after the documents are processed, it is necessary to thoroughly analyze the information domain and the expected behavior of the site visitors to determine what facets are required. By turning this process into a collaborative effort in which all stakeholders participate, conflicts down the road can be avoided.

In our case the following facets were determined:

The law facet contains a hierarchy of law-related terms. The other facets are enumerated lists. Year, event and type were the easiest to discover. Process and law took longer, because we wrestled with occasional cross-pollution between the two (laws do sometimes describe processes). In the end, we felt that minimizing the process facet to a small number of well-known steps would benefit the search user, and we included process.

The aim is to use these metadata statements in conjunction with the basic search engine facilities. Each XHTML document is assigned zero or more metadata statements that look like <meta keyword="facet" value="value" />. The search engine is instructed to look for these types of description and apply weighing rules. Some rules are applied to groups of documents (for instance type facet). Other rules match values. For instance, if user search term is found within law facet values, then documents with descriptions which contain facet law and value equals search term will gain weight in the relevancy ranking.

Allocating facet metadata statements is aimed at enhancing search. Without an interface that is intuitive and easy-to-use, these "behind the screen" investments would go to waste. It falls outside the scope of this paper to investigate all design decision, but some steps that refer to the use of facets are relevant here.

The initial presentation of search results is flat. Each hit contains at least a title and an URL. When the (complete) set of results contain hits that refer to documents with facet descriptions, opportunities for enhancement arise. The obvious one is to combine the title and URL with the facet descriptions. The addition gives users a better insight into the context of the document that is referred to, and possible avoidance of unnecessary detours to documents that do not matter.

The more advanced features that can be built upon facet information are advanced search and refinement. Advanced search refers to the process of specifying a query - before the actual resultset is created. By specifying facet - value criteria, the size of the resultset might be reduced. Refinement takes place after the resultset is constructed. It allows the user to drill down within a resultset.

Ultimately, one can only make educated guesses about the kind of queries that the site visitors will make. Therefore, it is crucial to try to learn as much about site visitors needs as possible. One way is to invite the site visitor to answer a questionnaire. Another way is to monitor actual behavior.

In the context of a search service, one way to monitor behavior is to log the keywords as they are entered in the search box. By replaying popular terms, keywords that do not lead to acceptable results can be found, and steps can be taken to improve the results.

Obviously, this manual process of testing keywords is expensive and only useful for the most popular keywords. Therefore, one should start with the small set - say a top-50 - and a weekly or monthly period. After a few iterations, the amount of work decreases and experiments with a larger set or a shorter period might be possible.

Closing the loop is important because it enhances the - necessarily indirect - communication between site producer and consumer. A continuous process needs to be designed: determine whether a popular keyword yields acceptable results, add new keywords to a centrally managed collection as synonym or facet values, republish the modified synonym list to the search engine and the author controlled vocabulary to the author tools, and test whether the situation improves. As this process is labor-intensive (specialist time), manual steps like calculating a top-50, checking what keywords are new, exporting the new synonym list and vocabulary should be automated as much as possible.

An evolutionary approach places a premium on extensible systems. The topic map paradigm is well suited to driving extensible systems. By implementing the topic map standard, systems offer a number of mechanisms that help handling diversity and growth in an evolutionary way:

The fact that our site contains older information presented a challenge for migration. Retrofitting all content with new metadata statements would take quite a while. In the meantime, advanced search would not work as expected. Unless the majority of the documents on the site are retrofitted, site visitors are fooled into thinking that constructing an advanced query would matter. They would be mistaken and probably disappointed.

One way out of this dilemma is to offer options only when they have effect. In other words, offer opportunities for filtering the resulting set based on the characteristics of the resulting set itself. When no opportunities are present in the resulting set, no filtering opportunities are offered. This refinement strategy obviously takes place in the second phase. When a sufficient number of documents is processed, advanced search can be offered.

Realizing refinement is not easy, as it complicates life for the search engine quite a bit. Instead of just serving 10 or 20 hits, unique facet values for the whole resultset need to be determined to populate the filtering options. Once a user refines the resultset, the next and previous buttons need to take the chosen option into account and skip entries in the resultset.

The alternative is to distribute processing a bit and use JavaScript on the client. In this case the search engine delivers in a single XHTML page with all hits included. Attached JavaScript code sets CSS (display) properties, determines filtering options and controls previous / next buttons. The initial loading of the page is longer (19Kb with 100 hits), but once loaded filtering is in-memory. The disadvantage of using JavaScript on the client can be mitigated with a trick that was popularized by Jon Udell. Each hit contains semantic descriptions:

<li class="hit"><div class="title">This is the title</div>
<div class="url"><a href="document.html">Go to document</a></div><span class="year">2003</span></li>

A small amount of JavaScript is required to process this information. Browsers with JavaScript turned off will show all hits without pagination and filtering options. Apart from the longer loading times and scrolling, the page degrades relatively graceful.

This kind of solution obviously does not work for a global search engine - too many hits would create huge pages - but can be made to work in a medium-sized website where the number of hits does not generally exceed 200.

As our website contains a number of relatively distinct sections, writing content is often done in projects. A project follows a more or less distinct process that results in a set of XHTML documents (a subsite). With regards to metadata assignment, there is project-level metadata that is applicable to all resulting XHTML documents, group-level metadata that is applicable to a smaller set of XHTML documents, and document-level metadata that only applies to a single XHTML document within a project.

To minimize manual metadata assignment, a kind of 'trickling-down' mechanism would allow authors to assign metadata statements at the project or group level. These statements should apply to all documents within the project or group. Authors should also be able to prevent trickling-down for those statements that only apply to the containing level. For new projects, one would imagine that this kind of group level metadata assignment is built in the web content management systems. Unfortunately, this proved to be not the case. Because we also wanted to use this technique to enhance existing documents, we had to write a custom solution to append these descriptions to groups of documents. This application uses a site-wide XML document that relates groups of documents to metadata values that are applicable to all documents within the group. With little effort, a large number of documents can be prepared automatically.

The following types were defined:

For simplicity, we refrained from subclassing association types [Rath, H. and S. Pepper 2000] or subclassing occurrence types (for instance scope note as a kind of description). The use of the scope construct for a short name is ugly. The XTM 1.1 option of assigning a class to a baseName looks promising, but was not supported by our system at the time.

Synonymy is an example of a thesaurus construct that can be realized in two ways. As two synonyms represents the same concept, one could argue that a topic should represent the concept, and that its baseNames should be used to cover the synonyms. To distinguish between preferred and alternate terms, baseName scoping is available. The other option is to create topics for each term and work with associations to document the synonymy relationship between term topics. The second approach probably scales better, but the first cannot be disabled. From a topic map perspective, both approaches can coexist. In our system, synonyms need to be extracted for use in Verity. Thus, the programmer of the transformation script needs to be aware of both ways or information is lost.

Metadata statements on the topic map constructs is another example of a problem that can be solved in multiple ways. Specialized thesaurus tools offer extensive metadata facilities, for instance to document why a term description is modified, or when the modification was done and by whom. In a topic map, the use of reification is probably the most elegant solution. Topics are created that describe the "history" of the primary topics and associations in a topic map. The actual metadata is written into typed occurrences. Although elegant, this solution runs the risk of massive growth of the topic map. Also, it is not easy to implement. One could also forget reification and add the occurrences directly to the topics themselves. This raises the question of how to document metadata on associations. The third way is to forget the topic map altogether and rely on a separate logfile. Obviously, this is the least attractive solution as information that should be part of the topic map is separated.

Our site contains information about offices of the Dutch Tax and Customs Administration (phone, visit, etc.) in relation to Dutch municipalities. Every once in a while mutations are delivered by another organization. The mutations are processed, some post-processing (exceptions) takes place, and the result is published to an application on the website. Currently, the information is loaded into an Access database. By converting the delivered information into a topic map, and managing the exceptions in a second topic map, Access is no longer required. In fact, the same tools that are used for managing keywords are reused.