“Our little lives get complicated / It’s a simple thing / Simple as a flower / And that’s a complicated thing.” – Love and Rockets, No New Tale to Tell

The W3C SKOS standard is defined as the

“Simple Knowledge Organization System (SKOS), a common data model for sharing and linking knowledge organization systems via the Web.

Many knowledge organization systems, such as thesauri, taxonomies, classification schemes and subject heading systems, share a similar structure, and are used in similar applications. SKOS captures much of this similarity and makes it explicit, to enable data and technology sharing across diverse applications.

The SKOS data model provides a standard, low-cost migration path for porting existing knowledge organization systems to the Semantic Web. SKOS also provides a lightweight, intuitive language for developing and sharing new knowledge organization systems. It may be used on its own, or in combination with formal knowledge representation languages such as the Web Ontology language (OWL).” (SKOS)

The SKOS data model defines common taxonomy components like concepts, schemes, labels, notations, properties, and relations. It also defines the class of skos:Collection, a simple and useful tool in managing and delivering taxonomies. From what little research I’ve done, there doesn’t seem to be a lot of discussion or commentary on the use of skos:Collection in practice, but I think it is a simple way to enable taxonomy delivery in the organization.

What Is skos:Collection?

According to the W3C standard, “SKOS concept collections are labeled and/or ordered groups of SKOS concepts” (SKOS). They are defined by the classes skos:Collection and skos:OrderedCollection which are both instances of owl:Class. Using these classes, it is possible to group concepts across one or more schemes and at different levels in a hierarchical taxonomy. Concepts grouped as skos:Collection are delivered as a flat list in default alphabetical order while concepts using the subclass skos:OrderedCollection can be grouped and delivered in a selected order.

To define what concepts are included in a collection class, SKOS uses skos:member and skos:memberList as instances of owl:ObjectProperty. Any concept can be a member of a collecxtion.

Interestingly, skos:Collection is disjoint with skos:Concept and skos:ConceptScheme. A disjoint class is a grouping sharing no common members or instances with another class. “Collection and Concept are regarded as disjoint, so that the relation definitions disallow a collection from being a mid-level node in a hierarchy of concepts” (ISKO). This means collections are not typically defined as concepts with URIs themselves, but as blank nodes. In addition, the concepts gathered within a collection are not placed within a hierarchy as part of the named collection. 

Concepts in a collection are delivered in a flat list because their class is “disjoint from concepts. It is therefore impossible to use SKOS semantic relations to have a collection directly fit into a SKOS semantic network. In other words, grouping concepts into collections does not replace assertions about the concepts’ place in a concept scheme” (SKOS). Not only are semantic relations not included within the class, but there is the practical limitation of retaining broader and narrower relationships when concepts can potentially be added to a collection from any scheme at any level in the hierarchy. It is extremely difficult to reconstruct a hierarchy with any sense or accuracy if concept levels are absent or skipped.

Why Use Collections?

When I worked at Synaptica (now part of Squirro), the taxonomy and ontology management system, Graphite, included easily accessible ways to create named collections on the fly and manage the member concepts. In the implementation of collections in this tool, it was possible to name the collection and add and delete concepts as needed. Different collections could include concepts from any taxonomy schema managed within a project and from any hierarchical level. Different collections could include the same terms if desired. So, it was possible to designate a collection at a hierarchical level and include all the children under it or select concepts from any level in any taxonomy. The main use case for implementing collections in this was to create a grouping for delivery through the API to a field in a consuming system.

To illustrate, a Geography taxonomy could have long lists of countries and cities. However, a consuming system may have a field requiring only a list of countries in which the organization operated. Of course it would be possible to create a new grouping concept in the taxonomy called “Organization countries” or something similar. Then countries could be added to this new grouping header as well as retained in their original structure nested under continents or regions (assuming that were part of the Geography taxonomy). However, using a collection is a fast and easy way to keep the original taxonomies clean without redundant polyhierarchical structures and additional grouping headers. In this example, we are using collections to grab a subset of a mutually exclusive set of concepts.

Collections can also be a way to group concepts conceptually that may or may not live in a single hierarchical taxonomy branch or even within a single taxonomy scheme. For example, there are many points within a content management lifecycle ecosystem to manage the way information is presented to customers. Typically, gathering products on a landing page organized around a common principle is the work of the web content management system. Ideally, these products are already tagged with a variety of metadata including concepts managed in a taxonomy. Grouping products by a metadata value should be relatively easy within a WCM system but conceivably could be gathered in conceptual groupings using collections. For example, a grouping concept like “Back to school” is a temporal but repeatable way to group products across many types of taxonomic categories. Again, this is typically done in a WCM system but can also be done in the taxonomy source system if the grouping is stable and repeatable.

Additionally, end users often ask for processes to be modeled in taxonomies. While this is possible, it’s equally feasible to list the process steps in a more taxonomic hierarchy and then deliver them as an ordered collection in the proper step stages. This could be particularly useful when selecting a flat list of terms in a downstream system to indicate at which stage a process is in.

While collections may have a limited set of use cases, I have found the use of skos:Collection a relatively simple way to group concepts for delivery, especially when these groupings are external to the domain modeled by the taxonomies. Notions like print vs digital, internal vs external, and other conceptual models which are not inherent to the concepts themselves are additional groupings not readily modeled within taxonomies. I have not conducted a full audit of commercial off-the-shelf taxonomy tools and their expression of collections, but it is potentially a simple and useful tool for taxonomists working directly within a taxonomy UI to group concepts for delivery.