Friday, March 29, 2019

Knowledge Modeling

I recently presented a webinar on “knowledge modeling.” I usually have spoken or written only of creating controlled vocabularies, or more specifically taxonomies, rather than creating knowledge models. Now, I am beginning to think of knowledge models and knowledge modeling.

A knowledge model is not just a fancy buzzword for a controlled vocabulary. It’s more complex than that. A knowledge model is more similar to a knowledge organization system, which I defined in an earlier blog post. As a system or a model, it comprises not only the concepts, their labels and attributes, and their relationships, but also rules or policies for their use. Furthermore, a knowledge model is either a complex type of knowledge organization system, such as a thesaurus or an ontology, or a set of multiple controlled vocabularies to be used in combination for the same content set  that form a set of taxonomies, such as facets, but it is not a simple single controlled vocabulary. The designation of “model” is also what is used for RDF, SKOS, and OWL-based systems. These are often called semantic models.

The activity of “knowledge modeling” is also slightly different and more complex than mere “taxonomy creation.”   Taxonomy creation involves identifying concepts through obtaining input from stakeholders/users and from surveying the content, possibly with some additional external resources, but the extent of obtaining user input may vary. It is possible to build a taxonomy, especially one for external users, with no user input and just input from some other stakeholders. Knowledge modeling also involves inputs of people and content, but more emphasis is on stakeholder/user input. Content contains information, but people contain knowledge, so knowledge modeling requires the input of various people, with the input gathered in a comprehensive and systematic way, such as through interactive brainstorming workshops and interviews. Furthermore, knowledge modeling does not look at merely content, but starts out considering the body “knowledge” that can be derived from the content.

Knowledge modeling may also involve a slightly different thinking of the taxonomist or knowledge modeler. Instead of thinking of what terms are needed for indexing and retrieval of a set of content, the knowledge modeler thinks of what are the possible classes, facets, or concept schemes to describe a domain of knowledge, and what are the various user activities and use cases that could be supported. From there, specific concepts are then created. Taxonomy creation involves a combination of top-down and bottom approaches to the hierarchy of concepts, but knowledge modeling puts more emphasis on the top-down approach.

Knowledge modeling is a very apt description for what is involved in designing and creating ontologies, which are knowledge organization systems that describe a domain of knowledge, through concepts, classes of concepts, and customized semantic relationships between concepts of different classes. (Ontologies, by definition, should also follow the OWL standards of the World Wide Web Consortium for data representation.) There are knowledge organization systems which are not ontologies yet make use of some semantic relationships, and designing these also involves the activity knowledge modeling. Determining what additional semantic relationships are desired, how specific they should be, and what they should be named in both directions is very much a knowledge modeling task.

Knowledge modeling also suggests that it is an activity of knowledge management and not merely information management. Knowledge management is defined as “the process of capturing, distributing, and effectively using knowledge,”(Tom Davenport, 1994), which goes beyond the mere support of search, discovery, and retrieval. Knowledge management is especially for internal enterprise-level knowledge.

I think knowledge modeling is more challenging than mere taxonomy creation, but I am up for the challenge.                                                                                                                                                                             

Thursday, February 28, 2019

Taxonomy Building Steps


What are the steps to take when building a taxonomy? This question was posted not long ago to a discussion group of which I am member. I referred the person asking to slides of one of my past presentations, "Everything You Need to Know to Start a Taxonomy from Scratch." That  presentation, however, is more about what to consider in a project of creating a new taxonomy, rather than actual steps to take. So, I’ll summarize the steps here.

The main steps in developing a taxonomy are information gathering, draft taxonomy design and building, taxonomy review/testing/validation and revision, and taxonomy governance/maintenance plan drafting. The steps may overlap slightly.

Information gathering for a taxonomy


Information gathering involves the two sides of the taxonomy: the content to which it will be tagged and the users who will utilize the taxonomy in browsing, searching, filtering, etc.
Information gathering about the content involves looking at a large representative sample of content (documents, intranet or web pages, database records, digital assets, etc.) and determining how they would be classified  and what they are about. Determining how they would be classified is on the higher level of content types or document types. Determining what they are about is on the more specific level of indexing terms. As a former indexer, I approach the task as if I were going to index the documents with index terms of my choosing. These terms are then gathered and organized into the taxonomy. Any existing term lists or sets of metadata should also be gathered and analyzed.

Information gathering about the needs of the users involves conducting interviews or using questionnaires to learn about the information-seeking needs and behaviors of the primary users of the future taxonomy. Some of the users of the taxonomy won’t be those looking for content but rather those who will be publishing or uploading content and they will use the taxonomy to select terms for tagging. Those users should also be interviewed or asked questions on questionnaires, but they are asked different questions than of those who perform information-seeking.

Draft taxonomy designing and building


Creating the taxonomy may begin with an initial high-level taxonomy design and metadata specification, based on the information gathered from users and some of the content. It is at this stage that the taxonomy type (hierarchical, faceted, a combination), any larger metadata schema, and the top terms are determined. Depending on the situation, the taxonomy project owner or other key stakeholders should provide their feedback on the high-level design before detailed taxonomy building begins.

Building out the taxonomy involves approaching the structure from both directions: top down and bottom up. The top-down design and some building comes primarily from the information gathered in speaking with the users and other stakeholders. The bottom-up building comes from the index terms discerned when analyzing sample content. The taxonomy needs to be well designed from both ends and integrate well in the middle. Terms at both ends may be revised in the process.
A well-designed taxonomy not only suits the needs of the users and represents the range of content, but it also needs to follow best practices for taxonomies so that the format of terms and the relationships between terms conform to standards, and thus the taxonomy is logical and intuitive to use. 

Taxonomy review/testing/validation and revision


At one or more points in the process, the taxonomy should be reviewed and tested. Testing should ideally involve both uses of the taxonomy: finding terms to tag content and finding desired content by means of taxonomy terms. This testing can be done with an offline sample of content and taxonomy terms, if the taxonomy has not yet been implemented. Testing may be based on use cases that came out of the initial user interviews.  In this process, concepts missing from the taxonomy whose meaning is unclear can be identified and added or clarified. Testing that is done when the taxonomy is nearly finished and expected to be in good shape might be called “validation.”

Taxonomy governance/maintenance plan drafting


Documenting the policy for the taxonomy and its usage does not come merely at the end of the project but gets started as the taxonomy is built and tested. As issues come up and get resolved, they get documented. Taxonomy governance includes the taxonomy editorial policy/guidelines, the taxonomy use/tagging policy, and policies and procedures for updating and maintain the taxonomy. A taxonomy is expected to change and require updating.

Conclusions


Those with skills in creating index terms need to broaden their skills to include requirements gathering, stakeholder interviewing, and governance planning, if they want to design and build a taxonomy. Those with skills in information project management may need to deepen their skills in best practices for creating taxonomy terms and relationships.  If you would like to develop those skills, I am offering full-day workshops in taxonomy design and creation in Rome, Italy, on March 25, 2019, and in Cleveland, Ohio, on June 15, 2019. I also offer a self-paced online taxonomy course that can be started any time.

Thursday, January 31, 2019

Indexes and Faceted Taxonomies


I recently completed a project of creating an index for a book. I had done quite a bit of freelance back-of-the-book indexing 2005 – 2013 but had not indexed a book in over four years. Since I also do taxonomy work, whenever I do indexing, I draw comparison between index creation and taxonomy creation. This time I drew some new comparisons.

It is back-of-the-book indexing, rather than the kind of indexing of content items that is done with a taxonomy, that has some similarities with taxonomy creation. That is because they both involve creating taxonomy terms, naming them, coming up with variant names, and relating them to each other.  I have written a detailed article “Creating Indexes and Thesauri: Similarities and Differences”  published in the journal The Indexer.

During my most recent index project, I thought of comparisons not with thesauri, but with faceted taxonomies. Faceted taxonomies are increasingly common form of taxonomies or controlled vocabularies. Different aspects/dimension/refinements/filter types of a content item and of a query to find it are considered in creating a set of facets from which terms are used in combination. Facets can be for each of such things as named persons, places, person types, events, activities, things, etc. The set of facets, ideally around 4-7, is customized to the set of content. Each facet may contain just a few or hundreds of terms.

An index, of course, is quite unlike a faceted taxonomy, because a single index includes all kinds of terms: named persons, places, person types, events, activities, things, etc. Some books, however, have separate Name and Subject indexes, so that could be like having two facets. Whether it’s a single index or a set of two, however, the user is only looking up one term at a time, unlike a faceted taxonomy, which allows the user to select multiple terms from multiple facets and combine them to limit the search results.

What is significant is that a good index should include all the aspects/dimensions/types of terms. Thus, the intellectual activity of creating a good back-of-the-book index is similar to creating a good faceted taxonomy, because a full set of aspects needs to be considered and created.

The book I recently indexed was a biography of a jazz saxophonist. As I indexed, focusing on the content at the level of a paragraph or a couple of consecutive paragraphs, I found myself making sure I created index terms that covered the different aspects or term types. In this case they tended to be: named persons, named places, person types (different kinds of musicians, music producers, etc.), place types, activities, music groups, music genres, record label companies, names of songs or albums, and music-related topics.

Of course, it is rare that a single paragraph would have more than a couple of distinct index term concepts (not counting synonyms, what in indexes is called “double posts”); a full set of facets is not expected. Rather, though, as I was indexing, after I selected an initial, obvious index term for the paragraph(s), I would then pause to think if there was a different aspect that could also apply as an index term from among potential facet-like categories, as listed above. I felt that being “facet aware” I was able to create a very comprehensive index.

The resulting index is simply an alphabetical arrangement of terms, with  the larger concepts further broken down with subentries. It does not appear faceted. However, all the potential facets are included.  The variants or synonyms, as “double posts” in the index, help guide different users who think of different words for the same thing to find the text passage of the desired topic. Additionally, the terms of the different aspects, like facets, help guide different users in another way, by serving those who are thinking about different aspects of the book’s content and narrative.