There’s a lot of advice out there on semantic modeling – and not all of it is easy to follow. Informed by our extensive industry experience, metaphacts summarises some of the best practices to follow when semantic modeling to unlock the full potential of your data. 

 

Best practices when semantic modeling

When semantic knowledge modeling, you might come across conflicting information, complicating the process and causing unnecessary headaches. There’s no one way to go about semantic modeling, and over time, you will learn which semantic modeling practices fit your enterprise best. But when starting out, we suggest taking the most straightforward approach possible. In the following article, we recommend some semantic modeling best practices, taken from our Semantic Modeling Guidelines, which you can use and implement when you begin modeling. 

 

Table of Contents

 

1. Best practices when starting to model your ontology

2. Best practices when working with ontology elements

3. Best practices when evaluating and publishing your ontology

4. Best practices: learning by doing

 

1. Best practices when starting to model your ontology

Whether you’re getting started with your first semantic knowledge model or want some pointers on how to improve your ontology, in this article, we outline some of the best practices you should adhere to when semantic modeling. 

 

Don’t worry if the following advice is a lot to remember, metis – our AI-assisted semantic modeling agent – is here to help. metis simplifies and accelerates model creation by automatically incorporating many of these practices, offering suggestions and recommendations as you build with metaphactory. This support allows you to focus on mastering the best practices—ensuring you remain in the driver’s seat and have the strategic insight to properly steer the direction of your model and address your model needs. 

 

For more experienced users looking to fine-tune the visuals of their semantic knowledge model, metaphactory’s visual modeling editor also prompts you to follow these best practices.

 

Best practices for defining the scope of your ontology

Competency questions

The first piece of advice we have to modelers is to create “competency questions”, which address what your ontology is about and the kind of answers you want to extract from it, like a query. Once created, these questions will help you to define the scope, purpose, and goal of the ontology. Example competency questions might include “how many customers have multiple contracts with our organization” or “how many customers are billed monthly vs annually”. Always keep in mind the kind of real-life queries an end-user might ask, to avoid coming up with questions that are too broad or abstract. 

 

Documentation

One of the most important and sometimes overlooked parts of the process is documentation. We recommend documenting the ontology purpose and use in the form of a description attached to the ontology. A benefit of semantic modeling with metaphactory is that you can directly model and document your ontology within the platform. This centralizes all the documents you need in one place, in an interoperable, semantically-rich, and human and machine-understandable format. 

 

Purpose statement

One good practice in ontology governance is to write a purpose statement. Doing this at the very beginning will help you stay aligned with your original goals later on. Try to write the purpose statement as simply as possible so it can be understood by both technical and non-technical readers. 

 

Roles & collaboration

If multiple people are involved in building the ontology, asking competency questions and creating clear documentation early on can make sure you stay on the same page. It’s also important at this stage to decide who will be involved, what each person’s roles are and how you plan to collaborate.

 

We recommend involving domain experts early on, as you are likely to rely on domain expertise later on in the process. This is because subject matter experts provide critical insights that can be missed by others (even experienced knowledge engineers), who are not as deeply schooled on specific subjects. 

 

How you work with domain experts differs on a case-by-case basis. For example, if you are building an ontology in Pharmaceuticals, this might be gaining valuable insights from principal scientists. If you are working in Automotive manufacturing and want to map the material flow and inventory management of the company, this might involve working with logistics and supply chain managers. Working with domain experts like this helps ensure that the semantics are accurate and the ontology will have real-world applicability. 

 

Best practices when researching existing ontologies and non-ontological knowledge resources

Now you know what you want your ontology to achieve and who you want to involve in its creation, it’s time to enter the implementation phase. At this point, we advise researching existing ontologies and other non-ontological knowledge sources. 

 

Using resources like these can help save you time, effort and enrich your model. They can even help create large-scale knowledge graphs with millions of entities! But be careful, reusing materials can also make modeling more complicated and come with design trade-offs. Make sure to do proper research and keep in mind the original scope and intent of the ontology you are considering to reuse, to make sure it does fit your needs and does not overcomplicate things unnecessarily. Sometimes, designing a custom ontology from scratch can be the best approach. 

 

Here are seven considerations you should have when considering internal and external ontologies to reuse:

 

1. Does the ontology align with your domain?

2. Is it semantically compatible? Do the definitions and relationships match well with your intended semantics?

3. Will using this ontology increase interoperability? Will it help the ontology integrate with external data sources and industry standards? 

4. Is the ontology well-maintained and managed by a stable community?

5. Is the complexity of introducing the ontology worth its benefits?

6. Is the ontology attached to an academic publication or other trustworthy source? 

7. Is the granularity appropriate for my modelling activities, and not overly general or specific?

 

There are a few things to consider depending on whether the ontology you intend to reuse is internal or external. When evaluating internal ontologies (ontologies developed within your organization), the most important consideration is making sure your group remains in sync with other colleagues modeling other sub-domains independently. We recommend implementing shared governance workflows (e.g., peer reviews, notification systems) and regular sync meetings. 

 

When using external ontologies (like publicly available ontologies), check that they are peer-reviewed, properly maintained and well-documented. Some publicly available ontologies define meta-modeling standards instead of domain-specific semantics. When semantic modeling with metaphactory, there is no need to manually import these foundational standards and mix them with domain-specific ontologies – the software already supports these ontologies as long as they are expressed in RDF/OWL standards. 

 

We recommend you consult a domain expert before making the final decision on reusing an internal or external ontology. Once you have the green light, it’s wise to start with a small-scale test integration before full adoption. 

 

When reusing non-ontological knowledge resources (like databases or UML diagrams), the most important thing to consider is whether reengineering them into an ontology is worth the time and effort. If it is, next, you need to spend time transforming the relevant concepts into ontology elements, basically converting the resource into a structured ontological model.

 

Best practices to approach ontology development

When ontologies grow, they can become more difficult to navigate and can expand beyond the initial scope. Our advice is to take a modular approach to ontology development.

 

One way to do this is a top-down approach. This means you start big, by designing high-level domain concepts, then working your way down to specialized sub-ontologies for specific subdomains. Working this way also makes it easier to compartmentalize the modeling work across your team. 

 

How exactly you work depends on the situation. For example, in a decentralized modeling environment, you might have multiple teams working independently on domain-specific ontologies, and later on, a designated steward might assess these smaller ontologies, find common patterns and create a higher-level ontology. 

 

Sometimes a bottom-up approach might be necessary. To understand the difference between the two approaches, imagine you own many books and want to create a library. Taking a bottom-up approach would mean figuring out what books you already have, grouping them into categories like romance or mystery novels, and then buying a bookshelf to house them based on these categories. Whereas taking a top-down approach would mean creating the bookshelves, labeling the shelves and only then introducing the books you own. 

 

Another alternative option is to take a hybrid approach. There are two steps you can take to do this: one is to predefine a few high-level, shared concepts, and the other is to start modeling around a concrete use case to ensure the ontology develops around a focused and practical need. Think carefully about which approach you want to take (top-down, bottom-up or hybrid) on a case-by-case basis by considering your original competency questions. 

 

Regardless of whether you take a top-down or bottom-up approach, always bear in mind the list of competency questions you are trying to answer as you build your ontology. This can also help prompt you towards the best approach to take. 

 

Recap of best practices when starting to model your ontology

 To recap what we’ve learnt so far, you can consult the checklist below of the best practices we’ve covered in this first section of our guide.

 

Best practices for defining the scope of your ontology

 

• Create competency questions.

• Decide who will be involved, what each person’s roles are and how you plan to collaborate.

• Document the ontology purpose and use and write a purpose statement.

 

Best practices when researching existing ontologies and non-ontological knowledge resources 

 

• Research existing ontologies and other non-ontological knowledge sources. 

• Ensure your group remains in sync with other colleagues modeling other sub-domains independently.

• Check that the ontologies you reuse are peer-reviewed, properly maintained and well-documented. 

• Consult a domain expert before making the final decision to reuse an ontology.

• Start with a small-scale test integration before full adoption of another ontology.

• Best practices to approach ontology development 

• Take a modular approach to ontology development.

• Use your competency questions to assess the right modular approach you will take to building your ontology. 

 

 

2. Best practices when working with ontology elements

Classes, attributes and relations. It’s important to know the importance of each of these elements, and also to use and name them correctly. In this section, you will learn some of the best practices when naming and working with ontology elements.

 

Best practices when naming your ontology 

Are all the files on your computer neatly named? Or are you guilty of randomly naming documents in a hurry? When naming your ontology, it’s important to title it clearly and select a good namespace. We recommend choosing short, to-the-point titles which include the word ‘Ontology’. E.g., “Food Ontology” or “Sports Ontology”. 

 

IRI stands for Internationalized Resource Identifiers, and these are automatically generated for all elements when semantic modeling with metaphactory once a namespace for an ontology is defined. When defining your ontology IRI, think early on about whether you need to include a sub-path to group ontologies.

 

We recommend using consistent, speaking IRIs, IRIs which are readable to humans and clearly reflect the meaning of the element (e.g., /vocab/Person/reportsTo vs. /a84b-01c3). Not everyone recommends doing this; in fact, some argue that this can limit future changes. Using speaking IRIs strengthens the link between an ontology’s identity and its meaning, and also makes the ontology more user-friendly. If you do need to make changes, you can update the IRI rather than obscure it with an arbitrary identifier like a UUID. 

 

Best practices when creating classes

A class represents a category of things (abstract or concrete) which share common characteristics, and they are the first elements you will create when semantic knowledge modeling. When naming a class, don’t be tempted to use random characters or fillers; instead, make sure you stick to the following rules:

 

• Class names should be singular (e.g., Person not People).

• Class names should be capitalized (e.g., Organization).

• Class names should use nouns or noun phrases (e.g., Organization or Software Business)

• Classes named with noun phrases should use title case (e.g. Software Business)

 

Best practices when creating attributes

Attributes, also known as datatype properties, are a quality or feature which can be used to describe something in a class. For example, a person will have a birth date, or a country will have a population. You should use attributes to represent information like string, integer and date. 

 

Again, attributes have their own naming conventions. These are:

 

• Attributes should be named after the internal properties of a class (length, birth date, color, etc.)

• Attributes should be lowercase.

• Attributes should be nouns (e.g., length) or, less commonly, verbs/verb phrases (e.g., has length of).

• Attributes in verb form should use the present tense (e.g., has not had).

• Multi-word attributes should use spaces (e.g., birth date) or camel-case (e.g., birthDate) consistently.

 

Best practices when creating relations  

Relations, also known as object properties, tell us how two classes interact with one another. Critically, relations don’t just have a connection but also a direction. For example, an organization is involved in a project but not the other way around. You can even relate classes to themselves, for example, a Person knows another Person. 

 

There are three things to consider when deciding which direction your relation will take. The first is to think about which of them you want to make the main subject (this will be the class where your relation starts). The second is to consider the perspective of your queries and what questions your ontology is trying to answer. One formulation might help more than the other to satisfy these questions. For example, an Organization is involved in a Project but not the other way around.

 

The third is to think about which direction sounds most readable and natural. A good way to check this is to assess whether the relation uses an active or passive voice. We prefer the active voice (where the subject performs the action).

 

Sometimes, the right answer might satisfy some but not all of these recommendations. When decisions don’t feel straightforward, a best practice is to model the relation on the class (domain) where it is mandatory (an existential property). For example, a Publication cannot exist without a Person, but a Person might exist who does not have a Publication. In this case, we would recommend modeling: Publication authored by (at least one or many) Person.

 

Sometimes it’s necessary to set restrictions on relations. Specifying limits on relations can be useful (for example, “a Triangle has at least 3 Sides” and “A Triangle has at most 3 Sides”). However, adding too many limits can prevent your ontology from adapting well to new data and situations.  

 

Modelers can refer to their competency questions to avoid adding unnecessary limits. If the current relations already satisfy the relevant competency question or questions, then there is no need to add additional limits. 

 

When formatting your relations, you can use the same conventions as attributes, with one exception: use verbs (“manages”) and verb phrases (“is located in”) and not nouns. 

 

Best practices when creating the subClassOf relation

Use this special type of relation whenever you want to indicate when something is also something else. For example, “a Banana is a Fruit”. These relations go one specific way, so double-check your connection is in the right direction (if something is a Fruit, it is not always a Banana!). 

 

Always remember, something can be closely related but not actually the same. Because the class will inherit all the relations and attributes from the other class, you don’t want to make the mistake of misusing a subClassOf relation.

 

Best practices when creating vocabularies 

A vocabulary helps enhance an ontology with information – which is often, but does not have to be, hierarchical. As a rule of thumb, a vocabulary is helpful when you have a class with many types of subclasses, all known in advance, that have some kind of hierarchical structure but do not need further modeling. 

 

One way to visualize this is to consider the tree of life. Tree diagrams have been used for centuries to visualize knowledge, and in biology, the tree of life is commonly used to visualize evolution or the relationships between different organisms. Think of a controlled vocabulary (sometimes called a taxonomy) like a tree, and think of the ontology like a forest of trees. 

 

For example, you could use a vocabulary to describe all the possible roles in an organization. A vocabulary can then be used to define a hierarchy of controlled terms for Roles that are all fixed in advance, and that could apply to the Role class in an ontology.

 

Concepts in the vocabulary connected to a class share the same attributes and relations as the class, and you can add new terms without having to update the entire ontology. Terms can be as specific or general as you want. Vocabularies should be named ‘Vocabulary’ and share the same naming conventions as ontologies. Terms should be capitalized and as concise as possible, whilst still retaining the meaning. For example, if your vocabulary covered the types of roles people have in a company, you could call it “Role Vocabulary”.

 

Recap of best practices when working with ontology elements

 To recap, here is a checklist of the best practices we’ve covered when naming your ontology and working with ontology elements.

 

Best practices when naming your ontology 

 

• Choose short, to-the-point titles which include the word ‘Ontology’

• When defining your ontology IRI, think early on about whether you need to include a sub-path to group ontologies.

• Use consistent, speaking IRIs.

 

Best practices when creating classes

 

• Class names should be singular (e.g., Person not People).

• Class names should be capitalized (e.g., Organization).

• Class names should use nouns or noun phrases (e.g., Organization or Software Business).

• Classes named with noun phrases should use title case (e.g. Software Business).

 

Best practices when creating attributes

 

• Attributes should be named after the internal properties of a class (length, birth date, color, etc.).

• Attributes should be lowercase.

• Attributes should be nouns (e.g. length) or, less commonly, verbs/verb phrases (e.g. has length of).

• Attributes in verb form should use the present tense (e.g. has not had).

• Multi-word attributes should use spaces (e.g., birth date) or camel-case (e.g., birthDate) consistently.

 

Best practices when creating relations  

 

• Think about which class you want to make the main subject.
• Consider the perspective of your queries and what questions your ontology is trying to answer.
• Think about which direction sounds most readable and natural. 
• Using limits sparingly with relations.
• When formatting your relations, you can use the same conventions as attributes, with one exception: use verbs and verb phrases and not nouns. 
• Use this subClassOf relation whenever you want to indicate when something is also something else, and remember something can be closely related but not actually the same.

Best practices when creating vocabularies

 

• A vocabulary is helpful when you have a class with many types of subclasses, all known in advance, that have some kind of structure but do not need further modeling. 
• Vocabularies should be named ‘Vocabulary’ and share the same naming conventions as ontologies.
• Terms should be capitalized and as concise as possible, whilst still retaining the meaning.

 

3. Best practices when evaluating and publishing your ontology

Once you’ve built your ontology, it’s time to evaluate it. Then, when you’re happy with the final outcome, you can share the ontology internally or possibly make it publicly available. The next part of this guide explores the semantic modeling best practices in the final stage of your ontology journey. 

 

Best practices when evaluating and refining your ontology  

If you haven’t done so already, check your ontology against your competency questions (which, hopefully, you’ve been referring to throughout the process). Improve or edit where your ontology provides no clear answers to these questions.

 

This is a great time to revise your questions and add any you would like to answer in the future. Don’t skip over any questions that seem “obvious”; you might be surprised by something you’ve missed. It is reasonable to mutually align the ontology as well as the questions at the same time to account for minor changes, however you should not have to rewrite either of them from scratch if you consult both throughout your modeling.

 

Best practices for publishing and maintaining your ontology 

You might be excited to share your ontology with the world, but before doing so, it’s crucial that you check your documentation and refine it if necessary. Clear documentation is important to maintain traceability, collaboration and reuse. This is especially vital when working in teams or in shared modeling environments. Having the proper documentation in place also makes it easier to maintain, integrate and evaluate your ontology for potential reuse internally or externally. 

 

At a minimum, we recommend you include this key metadata in your ontology:

 

• A concise description of the ontology’s purpose and scope

• The creation date and author(s)

• A version identifier (often managed automatically by the tool)

 

 

Recap of best practices when evaluating and publishing your ontology

 To summarise this section, here is a checklist of the best practices we’ve discussed when evaluating and publishing your ontology.

 

Best practices when evaluating and refining your ontology

 

• Check your ontology against your competency questions.

• Revise and add to your competency questions.

 

Best practices for publishing and maintaining your ontology 

 

• Prepare clear documentation, including at a minimum…

  • A concise description of the ontology’s purpose and scope.

  • The creation date and author(s).

  • A version identifier (often managed automatically by the tool).

• Plan how to manage new ontology versions and track changes

 

4. Best practices: learning by doing

 

The best way to learn is by doing. Now that you’ve read this summary of semantic modeling best practices, it’s time to apply your knowledge. 

 

metis is your knowledge-driven AI platform, combines large language models and knowledge graphs to deliver AI agents that provide generative power, semantic precision and contextual, explainable insights. Our Semantic Modeling Agent is designed to help you apply these modeling best practices in real-time for a finished, context-aware model faster. By engaging with this article and the Semantic Modeling Guidelines, you ensure you are working with the agent smarter—equipped with the proper insight to assess exactly what you need and why.

 

The AI agent provides support throughout the modeling lifecycle, from idea to implementation. Not only does it move your project forward faster, but it also offers quality checks, suggestions for improvements and other recommendations along the way.

 

Speak with one of experts today to learn more about metis!

 

For more context, we also suggest you read the Semantic Modeling Guidelines, from which these best practices are summarised. 

 

We also offer a free self-guided semantic modeling tutorial, where users can learn in less than three hours how to build a semantic knowledge model via video tutorials and exercises. This also includes a 4-week free trial with metaphactory for hands-on learning alongside the material.