Good Practices for building ontologies

General best practices refer to how the ontology is scoped, designed, and constructed.

FUNDAMENTAL RULES

There is no one correct way to model a domain — there are always viable alternatives. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate.

Ontology development is necessarily an iterative process.

Concepts in ontology should be close to objects (physical or logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.

PILLARS OF ONTOLOGY

Clarity of Purpose: Why this ontology is being built and what are its intended uses and end-users. : specify or write the answers in an ontology requirements specification document. Define the ontology’s goals and objectives with precision. This includes identifying its primary application areas, target user groups, and expected outcomes. Clearly state the ontology’s domain coverage and the specific knowledge it intends to capture.

Knowledge representation: List the sources of knowledge and give a rough description of how you carried out the processes, and the techniques used (interview | survey | documents. Leverage on non-ontological content such as existing relational database schema, taxonomies, controlled vocabularies, MDM directories, industry specifications, and spreadsheets and informal lists.

Reuse: Conduct a thorough survey of existing ontologies and vocabularies relevant to your domain to identify potential sources for reuse. Use ontology alignment and mapping techniques to connect your ontology’s concepts with those in external ontologies, ensuring seamless interoperability. Implement mechanisms for version tracking and updates of reused ontologies to stay aligned with the latest developments.

Modular Design: Consider using ontology design patterns from established pattern libraries to structure your ontology consistently. Modularize based on domain aspects, knowledge granularity, or different viewpoints within the domain.

Consistency: Enforce naming conventions consistently, considering factors like camel case, underscores, or other conventions that align with your community or standard practices. Ensure that class and property names are meaningful and self-explanatory, avoiding ambiguity. Implement quality control checks for logical consistency and axiom coherence using ontology validation tools and reasoners.

Formality: Utilize ontology editors and ontology development environments that support formal ontology languages (e.g., Protege for OWL). Explicitly specify the ontology’s axioms, logical constraints, and relationships using ontology languages. Employ reasoning tools and ontology validation frameworks to identify and resolve inconsistencies or contradictions.

Versioning and Documentation: Implement a version control system (e.g., Git) to manage different versions of the ontology. Maintain detailed documentation, including ontology specifications, user manuals, ontology evolution history, and release notes.

Alignment with Standards: Ensure that the ontology aligns with domain-specific standards, RDF schemas, and OWL profiles relevant to your domain. Follow best practices and design patterns endorsed by recognized ontology organizations or communities.Regularly review and update the ontology to stay in sync with evolving standards.

Evaluation and Testing: Implement automated testing procedures to assess the ontology’s completeness, consistency, and logical correctness. (SHACL).Engage domain experts for domain-specific validation and quality assurance.

Evolution: Develop a clear governance structure that defines roles and responsibilities for maintaining and updating the ontology. Establish a transparent process for handling change requests, bug fixes, and new feature proposals, involving the ontology’s user and developer community.

Some good practices on Consistency:

A subclass relationship is transitive:If B is a subclass of A and C is a subclass of B, then C is a subclass of A

Classes represent concepts in the domain and not the words that denote these concepts.

Synonyms for the same concept do not represent different classes.

Avoid class cycles.

All the siblings in the hierarchy (except for the ones at the root) must be at the same level of generality.

When to/ not to introduce a new class:

If a class has only one direct subclass there may be a modeling problem, or the ontology is not complete. If there are more than a dozen subclasses for a given class, then additional intermediate categories may be necessary ( inspired by typesetting rules).

Introduce new class when : There are several rules of thumb that help decide when to introduce new classes in a hierarchy. Subclasses of a class usually (1) have additional properties that the superclass does not have, or (2) restrictions different from those of the superclass, or (3) participate in different relationships than the super classes.

If concepts form a natural hierarchy, then we should represent them as classes.

Good Practices on naming conventions:

Capitalize class names and use lower case for data property. (assuming the system is case-sensitive)

When a concept name contains more than one word (such as Meal course) we need t o delimit the words. Here are some possible choices. Use Space: Meal course (many systems, including Protégé, allow spaces in concept names). Run the words together and capitalize each new word: MealCourse Use an underscore or dash or other delimiter in the name: Meal_Course, Meal_course, Meal-Course, Meal-course. (If you use delimiters, you will also need to decide whether each new word is capitalized.

Consistent singular names for Class.

Do not add strings such as “class”, “property”, “slot”, and so on to concept names.

REFERENCES

A Reference Guide to Ontology Best PracticesAI3:Adaptive InformationAI3:::Adaptive Information (mkbergman.com)

Ontology101 — Protege Wiki (stanford.edu)