This is the fourth in a series of blogs describing how one would go about modeling an enterprise ontology.
Gist is a minimalist upper-level ontology that can help you bootstrap the implementation of your Knowledge Graph ontologies/taxonomies. In the previous blog, I introduced the concept of group buckets using gist. In this blog we continue on our journey by exploring another concept that is built into gist: that of "Product Category". If we load the gist core ontology (see: https://github.com/semanticarts/gist) into an ontology editor such as Protege (see: https://protege.stanford.edu/), we see this explanation of what a Product Category means:
"Product Category: Any of many ways of categorizing products, including models, NATO product codes, and the like."
You will also notice that Group is a type of Category. As such it inherits the properties of Category as well. (see Protege screen shot below).
The above is a pretty bare-bones definition — not much to it. Which might have you scratching your head: why is this any different than tag? or group? or any other gist category? The answer shouldn't surprise you: gist is an upper-level ontology that expects you to enrich/extend it to match your specific domain's use-cases. As such, it should be thought of as a framework upon which you (and others) will built cross-domain compatible mid-level ontologies and taxonomies. It should be clear that the concept of "product category" is fairly universal and deserving of its own place in an upper-level ontology definition.
Note: the following micro-pattern demonstrates just a simple product categorization, not a taxonomy. Taxonomies will be covered in a later blog post.
If you've been reading this blog series from the beginning, the Product Category micro-pattern should look familiar to you: it is quite similar to the group micro-pattern and not all that different that the tag micro-pattern either. Here the Product Categories are the buckets to which individual products indicate that they are gist:categorizedBy. While gist does not define an inverse property, you can still do reverse queries quite easily in SPARQL. Additionally, it would be trivial to add an inverse property if you so desire.
THE ABOVE IN TURTLE FORMAT:
@prefix ex1: <https://data.example.com/> . @prefix ex: <https://taxa.example.com/> . @prefix gist: <https://semantic-arts.com/gist/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . gist:ProductCategory rdfs:subClassOf gist:Category . ex:ProdCat1 a gist:ProductCategory . ex:ProdCat2 a gist:ProductCategory . ex:ProdCat1 gist:allocatedBy ex:Some_IP_org_or_person . ex:ProdCat2 gist:allocatedBy ex:Some_IP_org_or_person . ex1:Prod1 a ex:Product . ex1:Prod2 a ex:Product . ex1:Prod3 a ex:Product . ex1:Prod4 a ex:Product . ex1:Prod1 gist:categorizedBy ex:ProdCat2 . ex1:Prod2 gist:categorizedBy ex:ProdCat2 . ex1:Prod2 gist:categorizedBy ex:ProdCat1 . ex1:Prod3 gist:categorizedBy ex:ProdCat1 . ex1:Prod4 gist:categorizedBy ex:ProdCat1 .
That's about it. Simple, basic, and very reusable. By now you should be thinking about how you might enrich/extend the above generic micro-pattern to align with your domain-specific project — which is precisely what we will do in the next blog.
NEXT UP: we explore how to implement an Informal Taxonomy micro-pattern.