This is the fifth in a series of blogs describing how one would go about modeling an enterprise ontology.
Informal taxonomies are those hierarchical content structures where there is no consistent class hierarchy enforced. A good example of an informal taxonomy would be: Laptop/CPU/I7 where it should be clear that while I7 is a type of CPU, CPU is clearly not a type of Laptop. Another feature of informal taxonomies is there is no formal requirement that any node be restricted only one parent category (e.g. Desktops also have CPUs). In fact, a defining behavior of informal taxonomies – as opposed to formal taxonomies – is to allow nodes to belong to multiple parent categories as needed.
Given that informal taxonomies are ubiquitous in any enterprise, it behooves us to have a corresponding micro-pattern in our bag of tricks to use. That's what this blog is about. Let's dig in.
As we are using gist to bootstrap our micro-pattern project, a quick inspection of the gist upper-level ontology in Protege reveals there is already a Taxonomy class under Collection. But this class appears to be intended for defining formal taxonomies which we will address in another blog. As such, we will be "rolling our own" here to define a typical informal taxonomy micro-pattern, while still leveraging the gist upper-level ontology components.
Additionally, since the gist Product Category (see previous blog) is a type of Category, and that traditionally Product Categories more-often-than-not present themselves as informal taxonomies, I propose that our Informal Taxonomy concept belongs under the Category class structure rather than the more formal Collection class structure (at least as currently defined by gist).
To hold the name of our Informal Taxonomy (as well as any other attributes that might be needed to describe it), I will be adding an :InformalTaxonomy class of which :MyTree will be an rdf:type. Given that we are leveraging the gist ontology "as is", a definition of any gist:Category entity is supposed to have a gist:allocatedBy property for each taxonomic category. As such, the diagram is a bit "busy" with some relationships that are technically external to the core of the concept of the taxonomy itself. However, that being said, it is clearly a good idea to identify ownership/provenance of any CBox entity such as the buckets in this Informal Taxonomy. This is one of the hallmarks of gist – it defines useful "good enough" practices across the board.
Here's what the Informal Taxonomy micro-pattern looks like. Note that one item node (:Item4) is shown having two parent categories. Additionally one parent category (:Level_1-1-2) is likewise shown as having multiple category parents. Class instances are noted by dashed lines, indicating rdf:type.
THE ABOVE IN TURTLE FORMAT:
@prefix ex1: <https://data.example.com/> . @prefix cat: <https://taxa.example.com/> . @prefix gist: <https://semantic-arts.com/gist/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . cat:InformalTaxonomy a owl:Class . cat:MyTree a cat:InformalTaxonomy . ex1:Item1 gist:categorizedBy cat:Level_1-1-1 . ex1:Item2 gist:categorizedBy cat:Level_1-1-2 . ex1:Item3 gist:categorizedBy cat:Level_1-2-1 . ex1:Item4 gist:categorizedBy cat:Level_1-2-2 . ex1:Item4 gist:categorizedBy cat:Level_1-1-0 . ex1:Item5 gist:categorizedBy cat:Level_1-2-2 . cat:Level_1-1-0 gist:allocatedBy ex:Some_IP_org_or_person . cat:Level_1-1-1 gist:allocatedBy ex:Some_IP_org_or_person . cat:Level_1-1-2 gist:allocatedBy ex:Some_IP_org_or_person . cat:Level_1-2-0 gist:allocatedBy ex:Some_IP_org_or_person . cat:Level_1-2-1 gist:allocatedBy ex:Some_IP_org_or_person . cat:Level_1-2-2 gist:allocatedBy ex:Some_IP_org_or_person . cat:Level_1-1-0 gist:hasSubCategory cat:Level_1-1-1 . cat:Level_1-1-0 gist:hasSubCategory cat:Level_1-1-2 . cat:Level_1-2-0 gist:hasSubCategory cat:Level_1-1-2 . cat:Level_1-2-0 gist:hasSubCategory cat:Level_1-2-1 . cat:Level_1-2-0 gist:hasSubCategory cat:Level_1-2-2 . cat:MyTree gist:hasMember cat:Level_1-1-0 . cat:MyTree gist:hasMember cat:Level_1-2-0 . cat:Level_1-1-0 a gist:Category . cat:Level_1-2-0 a gist:Category . cat:Level_1-1-1 a gist:Category . cat:Level_1-1-2 a gist:Category . cat:Level_1-2-1 a gist:Category . cat:Level_1-2-2 a gist:Category . # INFERRED: # cat:Level_1-1-1 gist:hasSuperCategory cat:Level_1-1-0 . # cat:Level_1-1-2 gist:hasSuperCategory cat:Level_1-1-0 . # cat:Level_1-1-2 gist:hasSuperCategory cat:Level_1-2-0 . # cat:Level_1-2-1 gist:hasSuperCategory cat:Level_1-2-0 . # cat:Level_1-2-2 gist:hasSuperCategory cat:Level_1-2-0 . # cat:Level_1-1-0 gist:memberOf cat:MyTree . # cat:Level_1-2-0 gist:memberOf cat:MyTree .
I know that is a lot of moving parts, but being able to model (and implement) an informal taxonomy in a semantic way is critical to success in implementing enterprise ontologies. The good news is that we now have most of the micro-patterns needed to address the bulk of types of content structures we will encounter when modeling our enterprise ontology.
NEXT BLOG: Adding Facets to your Informal Taxonomy.