NOTE: although the focus here is on ontologies, some of these points can apply to other systems such as controleld vocabularies, taxonomies, thesauri, etc.
Some of the following may be obvious to some readers, but explicitly stating them is necessary to (i) express it for posterity, for the student, and for the non-specialist so that they (ii) are informed and so that (iii) misinformation is mitigated.
SUPPORT: If you find value in my work, please support/donate here.
1. You can create your own ontology, at any degree of abstraction, specificity, generality, or application
- You can create your own topic-specific ontology (also called: domain ontology, domain-specific ontology, application ontology, lower-level ontology, etc.)
- You can create your own highly abstract ontology (also called: general/generic ontology, foundational ontology, upper-level ontology, top-level ontology, core ontology, etc.)
- Some developers may resist this fact because some existing ontologies are the result of years of work, collaboratively or otherwise. Having multiple contributors may aid in some aspect of development and in quality control, but it is no guarantee of these things and it is not guarantee of the utility of the ontology.
- You can create one for your more-specific domain ontology. You do not need to use an existing top-level ontology, in part because it may not be the correct abstract model for your domain ontology, e.g., it may make commitments or ideological assumptions you disagree with.
- Anyone that says you must (or is pushy about it), is very likely trying to get you to use or purchase theirs.
- Do not tolerate, and do not encourage unfair tactics, political abuse, or attempts to monopolize.
An ontology may commit to other ontologies by importing them. An ontology may commit to a specific theory, ideology, philosophical worldview, or to a specific model of the world, or model of a specific concept or a target domain. So...
- Be aware of all commitments an ontology makes, at all degrees of abstraction. Be aware of semantic commitments, ontological commitments, ideological commitments, etc.
- Be aware of the assumptions, and assumed worldviews and ideologies it makes.
- Be aware of any imported ontologies or taxonomies the candidate ontology commits to or uses. Be aware of other ontologies or semantic resources you may be committing to by using the candidate ontology. How? Read documentation, look at the ontology at all levels of abstraction, at its axioms, imports, etc. It may be time-consuming, but blindly accepting a product (e.g., ontology) will benefit them (not necessarily you) while also potentially mis-defining your vocabulary, terms, concepts, etc.
4. You have a right to understand what an ontology says about your subject, discipline, terminology, data, expertise, or about the world if anything.
- Does an ontology allow the concepts/categories/terms you want to include or model? Will an ontology exclude your domain concepts?
- Can you accurate model/represent or semantically annotate your data and your domain concepts/terms with the candidate ontology?
- Will a more abstract, generic or upper-level ontology mischaracterize or miscategorize your domain concepts?
- Do not believe the "black box" saying that an ontology should be hidden from users or end-users. Anyone that tries to convince you of this is probably trying to push their ontology on you.
- Being informed, even of the seemingly mundande or ineffectual detials, is always better than not.
- There are other technologies and methods to achieve the same results. But you can also create your own more generic (or broader) ontology or taxonomy.
- Some developers may resist this fact, but it is important to put ones bias for their vested interst (or lifes work) aside, and be objective, fair and truthful. Stating it explicitly, even if obvious, is essential for the sake of communicating those facts; it will help to prevent (intentional or unintentional) misinformation. It will help inform posterity.
- There are other technologies and methods to achieve the same purported results.
- You might consider a less complex type of knowledge organization system, such as taxonomy, thesauri, etc.
- Ontology development and engineering (and related semantic web modeling approaches, and knowledge-based approaches) is a relatively immature topic, with limited quantitative evidence for its utility, and even less tools to harness the most robust (or heavyweight) forms of ontologies and the most expressive ontology (or knowledge representation) formal languages.
- This may be a contentious point for some, but bottom line is...do not blindly believe the hype. Just like with any other activity, tehnology, or product, we must admit such facts, and not exaggerate the benefits or state of ontology despite being interested or otherwise vested in the topic.
9. Popularity and standardization does not necessarily mean quality, or utility, & does not guarantee the system will be desired for your project.
- The amount of users an ontology (or ontology project) has does not mean an ontology is good, or useful.
- Presence in an (inter)national standards organization, e.g., having a standard document of an ontology, does not mean the ontology is good quality, useful, correct, etc. Some have entered into standards through political abuse and other unethical actions (evidence and cases available).
- Like in other disciplines, popularity, and presence in a standards organization, are invalid arguments that are used to convince people to accept the product or technology (e.g., an ontology).
© 2016-2021, Robert John Rovetto. All right reserved. Not authorized for commercial use unless explicitly negotiated with the author. Citation/attribution required.