Thursday, May 30, 2019

Knowledge Graphs and Ontologies


Schema DBpedia 2010 from Wikimedia Commons attributed to Charles Sturt University (Creative Commons license)
I’ve been hearing a lot about knowledge graphs recently. Corporate and academic implementations have been increasing in recent years, and now the taxonomy community is also taking an interest. Taxonomy software vendors are talking about knowledge graphs in webinars, blogs, and conferences, and knowledge graphs was on the list of suggested presentation proposal topics for this fall’s Taxonomy Boot Camp London conference.

Knowledge graph purposes and definitions


A knowledge graph is the organization and representation of a knowledge base as a graph, with a network of nodes and links, not as tables of rows and columns. As such, it is generally based on data in a graph database, rather than on a relational database, and graph databases are becoming more popular. A knowledge graph usually includes (but is not limited to) visualizations of data, such as of an output of graph analytics, a display of interconnected nodes and links, or a display of linked data in a “fact box.”

Knowledge graphs can serve various roles and provide many benefits. They support search, recommendation engines, e-commerce, and enterprise knowledge management. They can integrate knowledge, serve data governance, provide semantic enrichment to content, bring structured and unstructured data together, provide a unified view of varied unconnected data sources, provide a semantic layer on top of the metadata layer, improve search results beyond mere algorithms, and answer complex user queries instead of merely returning content on a specified topic. An example of a complex query, which can easily be handled by a knowledge graph linked to the right data, but would be very time-consuming if not impossible by traditional search and query methods would be: “Which of the top 10 scholarly journals (by most often cited), published in Europe in the past 3 years discuss knowledge graphs in the context of knowledge organization systems.”

Google Knowledge Graph fact box example
Google Knowledge Graph example
Like “taxonomy” or “ontology,” the definition of “knowledge graph” is not clear or agreed upon. Knowledge graphs have different meanings from different perspectives, such as those with a computer science vs. information management backgrounds. Sometimes a knowledge base, or at least a knowledge base that is represented as a graph, is considered the same as a knowledge graph. There was even a conference presentation, turned into an article, dedicated to this topic of defining knowledge graphs: "Towards a Definition of Knowledge Graphs," by Lisa Eherlinger and Wolfram Wöß, CEURWorkshop Proceedings.

A Google search with Wikipedia results at top returns the article describing Google’s own “Knowledge Graph” (introduced in 2012 and displayed as fact boxes, as in the example screenshot here for Boston) and a see also “Knowledge graph” (lower case), which redirects to the Wikipedia article “Ontology (information science).”

Knowledge graphs and taxonomies, ontologies, and other knowledge organization systems


Knowledge graphs, like taxonomies, comprise things/nodes/concepts and relationships between them. Knowledge graphs may comprise multiple domains and thus contain multiple taxonomies, thesauri, ontologies, or other knowledge organization systems. Knowledge graphs can link together disparate sources of controlled vocabularies and data.

RDF triple example
RDF Triple example
Knowledge graphs resemble ontologies (a kind of knowledge organization system that is based on taxonomies, but is more complex), but, despite what Wikipedia claims, they are not the same. Knowledge graphs and ontologies both are represented by nodes (things, concepts) and have customized semantic relationships between them. As they both can be visually represented in the same way of nodes and relationships, they may look the same in visualizations. They are both based on RDF (Resource Description Framework) triples (comprising subject-predicate-object), and are usually also based on the Semantic Web standard OWL. All nodes must have their own unique URIs. Specialized software tools are available to create knowledge graphs and ontologies.

Knowledge graphs can be considered ontologies and more. According to the authors, Eherlinger and Wöß, “A knowledge graph acquires and integrates information into an ontology and applies a reasoner to derive new knowledge.” A knowledge graph may comprise multiple domain ontologies, or an ontology and another vocabulary/knowledge organization system. A certain kind of very general ontology called an upper ontology or foundation ontology can also serve as the data model for a knowledge graph.

Conferences including knowledge graphs


There are many conferences that now have sessions on knowledge graphs. I cannot explore all of them, but I have attended and will attend several conferences this year that include knowledge graphs in their programs. VOGIN-IP-lezing 2019 "Search and Findability" at which I spoke in Amsterdam in March had a session on a fashion retailer's knowledge graph and a 2-hour workshop “Enterprise Knowledge Graphs." Data Summit, which I attended earlier this month in Boston, had several sessions that mentioned knowledge graphs, one focused on the topic, "From Structured Text to Knowledge Graphs," but not as something new to be defined, but rather as an accepted technology. I'm excited to be co-presenting (presenting the first part on taxonomies and ontologies) in a pre-conference full-day workshop "Fast Track to Knowledge Graphs and Semantic AI," at the SEMANTiCS conference in Karlsruhe, Germany, on September 9. Then I will be presenting  a "A Brief Introduction to Knowledge Graphs," among other presentations, at Taxonomy Boot Camp London in October.

Tuesday, April 30, 2019

Taxonomy Software Trends: Convergence and Visualizations


I recently looked more closely into current offerings of taxonomy software to prepare for an upcoming presentation at the SLA conference in Cleveland in June: “Taxonomy Tools and Tool Evaluation.” I will speak about the tools, and my co-presenter, Marti Heyman, will speak about how to evaluate them. I had last contacted various software vendors in 2015 when I was writing the second edition for my book, The Accidental Taxonomist. I had previously blogged on Taxonomy Software Trends in January 2015 and observed that, since researching software for my first edition in 2009, there is more cloud/web-based software, more SKOS/RDF/Semantic web framework software, and more plugins to SharePoint, content management systems, and search engines. Those trends continue. Now that I look into taxonomy software again, the additional trends I see are taxonomy, thesaurus, and ontology tool convergence and graphical vocabulary visualization.

Taxonomy, thesaurus, and ontology software convergence


Originally there was thesaurus management software (also used for any taxonomies), such as MultiTes, Data Harmony Thesaurus Manager, Synaptica KMS, and other products that no longer exist;  and ontology management software, such as TopBraid Composer, Protégé, ad others. The two kinds of software were very distinct, from different vendors, based on completely different standards and models, with different features, used by different users, for different purposes.

Now, we don’t hear as much about “thesaurus software” as before, but rather vocabulary/taxonomy/knowledge organization system (KOS)/ontology software, where the same software tool supports thesaurus standards (ANSI/NISO Z39.19 or ISO 25964) and ontology standards (OWL and RDF), and especially the SKOS (Simple Knowledge Organization System) model for any kind of controlled vocabulary. This makes sense, because an organization often has needs for more than one kind of controlled vocabulary. Newer software offerings have combined taxonomy, thesaurus, and  ontology software into one. These include Smartlogic Semaphore, PoolParty, TopBraid Enterprise Data Governance’s Vocabulary Manager, Mondeca Intelligent Topic Manager, and VocBench. Synaptica is the exception with two products: Synaptica KMS primarily for thesauri and graph database-based Synaptica Graphite primarily for ontologies.

Visualizations of taxonomies, thesauri, and ontologies


Interactive visualization charts/graphs of taxonomies (what I shall call all controlled vocabularies here) are not something I had paid much attention to, because the feature is not considered so important by a professional taxonomist for creating taxonomies. However, while taxonomists are the primary users of taxonomy management software, other stakeholders in taxonomies are important secondary users. These people include content managers, content strategists, project managers, knowledge managers, information product managers, user interface/experience designers, and subject matter experts. Rather than creating taxonomies, these various stakeholders need to view draft taxonomies and provide feedback on them. Viewing the taxonomy in the user interface used by the taxonomist is often not practical or intuitive. However, viewing the taxonomy as the end-user will see view it may not be possible, because the taxonomy has not yet been implemented into its final system or product. Therefore, a taxonomy visualization feature of taxonomy management software can be quite useful for stakeholder review and input.

Visualizations are especially useful for ontologies with their semantic relationships, but they are also helpful for taxonomies and thesauri. With the convergence of taxonomy, thesaurus, and ontology-creation capabilities in the same software, vocabulary visualization has become a more common feature. However, they are not the same in all vocabulary management software products. Following are some varied examples of visualizations. In many cases, they are interactive, whereby the user can drag and reposition the nodes.

Data Harmony Thesaurus Master offers a “sunburst” visualization for hierarchical taxonomies, as an alternative to the inverted tree display, which is available in the editing interface of the software.

Taxonomy visualization from Data Harmony Thesaurus Master
Visualization from Data Harmony Thesaurus Master

Synaptica KMS has a node and link relationship display for taxonomies and thesauri, where relationships do not need to be defined. Synaptica Graphite will have a new directed-graph visualizer feature added later this year.

Thesaurus visualization from Synaptica KMS
Visualization from Synaptica KMS


Semaphore, Mondeca, and TopBraid EDG Vocabulary Management each have a node and link relationship display for ontologies that additionally describes the types of relationships.



Ontology visualization from Smartlogic Semaphore
Visualization from Semaphore



Ontology visualization from Mondeca ITM
Visualization from Mondeca ITM




Visualization from TopBraid EDG Vocabulary Management
Visualization from TopBraid EDG Vocabulary Management



PoolParty offers a different type of visualization, focusing on the relationships of a selected concept, with each type color-coded. 
Visualization of a taxonomy concept from PoolParty
Visualization from PoolParty



In combination with other graph database tools, both Syaptica Graphite and PoolParty can support interactive nonhierarchical visualizations and graph analytics. This brings us to our next topic, knowledge graphs, which I will dicuss in my next blog post.

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.