Semantic checks

Here you find several checks on the terms and relations. These checks are mainly focussed on Semantic Modeling, but can be used of other types of graphs as well.

You can select this tool via Tools > Semantic Checks

When you selected a check, you get a new screen with title and 2 icons.

• Refresh icon: This will recalulate the terms with matches the check. You should refresh when you changed some terms or relations in the graph, while having this sidebar open

• Select terms: Selects all matches (the list of matched terms you see below) in the graph.

Plurals in name

Lists all term names which are in plural form.

While there might be rare exceptions or specific modeling methodologies that allow for plural terms in certain contexts, the general consensus in semantic modeling favors singular term names for the reasons mentioned below. It promotes a cleaner, more consistent, and less ambiguous representation of your domain knowledge:

• Focus on the Concept: Singular terms tend to represent a distinct concept or entity. When you use "Customer" instead of "Customers," you're directly referring to the idea of a customer, with its inherent properties and relationships. This makes the model more abstract and focused on the fundamental building blocks of your domain.

• Avoid Ambiguity: Plural forms can sometimes be ambiguous. Does "Products" refer to the general concept of a product or a specific collection of multiple product instances? Using the singular "Product" clearly denotes the concept itself. When you need to represent multiple instances, you typically do so through relationships (e.g., a "Customer" has many "Order" instances).

• Consistency and Predictability: Employing singular forms creates a more consistent and predictable modeling style. Once this convention is established, it becomes easier for everyone working with the model to understand the meaning of terms and to create new ones following the same pattern.

• Alignment with Instance Representation: In many data storage and programming contexts, you'll often deal with individual instances of entities. Using singular terms in your model aligns better with how you'll likely represent these individual records or objects (e.g., a single customer record, a single product object).

• Easier Relationship Naming: Singular terms often lead to more natural and readable relationship names. For example, "Customer places Order" is clearer than "Customers place Orders."

• Reduced Redundancy: When defining properties or attributes of a term, you're describing characteristics of a single instance. It feels more natural to say a "Product has a Name" rather than "Products have a Name."

Think of your semantic model as a vocabulary for describing your domain. Just as you define the meaning of a single word, you define the meaning of a single concept. You then use relationships to express how multiple instances of these concepts interact.

Duplicate names:

Lists all terms which have duplicate names.

Unique term names are fundamental for creating a clear, consistent, and unambiguous representation of your domain. They ensure that everyone using the model is speaking the same language and that the model can be used effectively for reasoning, integration, and communication. It's a basic principle that underpins the usefulness and reliability of any semantic model. Here's why duplicate term names are problematic:

• Confusion and Ambiguity: If you have two different terms with the same name, it becomes impossible to know which concept is being referenced in any given context. This leads to misinterpretations, errors in reasoning, and difficulties in communication among those using the model. Imagine trying to discuss "Account" when it could refer to a user account or a financial account – the conversation would quickly become muddled!

• Hindrance to Logical Reasoning: Semantic models are often used for logical inference and querying. If term names are not unique, it becomes incredibly difficult to formulate precise queries or to draw accurate conclusions from the relationships defined within the model. The system wouldn't be able to distinguish between the two identically named concepts.

• Data Integration Challenges: When you try to map your semantic model to underlying data sources, duplicate term names create significant challenges. How do you know which database table or data field corresponds to which concept in your model if they share the same name? This complicates data integration and interoperability.

Tooling and Technology Limitations: Many semantic modeling tools and technologies rely on unique identifiers for terms. Duplicate names can cause errors, warnings, or unexpected behavior within these systems.

No description:

Lists all terms which do not have a description.

The descriptions/definitions provide the crucial context and detail that term names alone often lack. Here's why they are so important:

• Clarity and Precision: While term names aim for conciseness, descriptions provide the space to elaborate on the exact meaning of a term. They can clarify nuances, specify boundaries, and distinguish a term from other similar concepts. For example, you might have a term named "Customer Status" but the can be many interpretations for it.

• Shared Understanding: Descriptions act as a central point of reference, ensuring that everyone working with the model has the same understanding of what each term represents. It reduces the risk of misinterpretations and promotes consistent usage of terminology.

• Contextualization: A term's meaning can be heavily influenced by the context of the domain being modeled. Descriptions allow you to capture this context, explaining how a term is used and understood within that specific domain. For instance, the term "Lead" might have different meanings in a sales context versus a manufacturing context. The description can clarify the intended meaning within your specific model.

• Resolving Ambiguity: Even with singular and unique term names, there can still be potential for ambiguity. A well-written description can explicitly address and resolve these ambiguities, leaving no room for doubt about the intended meaning of a term.

• Facilitating Model Evolution: As the domain evolves, the meaning of certain terms might also need to be updated or refined. The description provides a place to document these changes and ensure that the model accurately reflects the current understanding of the domain.

No relations:

Lists all terms that do not have any relations (either incoming or outgoing).

Relations are the foundational links that define how terms connect and interact within a semantic model. They are critical for building a meaningful and useful representation of a domain. Here is why having them is so important:

• Consistency with Definitions: A term's relations should always align with its definition. If a term is defined as an "Event," it should have relations that connect it to other events, participants, or locations. Missing relations could indicate that the term's connections have not been fully modeled, leading to a gap between what the term is described as and how it is actually used within the graph. This consistency is vital for maintaining a logical and coherent model.

• Structural Integrity: A term without relations is an isolated concept. Relations weave a network of meaning, showing how each term contributes to a larger, interconnected system. They provide the necessary structure to turn a simple list of terms into a functional and navigable model.

• Context and Dependency: Relations provide crucial context by defining a term's role and its dependencies on other concepts. For example, a term like "Product" is only meaningful in a semantic model when it's related to a "Price," a "Customer," or a "Supplier." These connections clarify its function and place within the domain.

• Navigational Pathways: In a graph-based system, relations act as pathways for exploration and analysis. By following relations, users can discover related terms, understand causal links, or trace dependencies. A term with no relations is a dead end, hindering the ability to navigate and explore the knowledge graph.

• Completeness and Accuracy: A term that lacks relations may indicate an incomplete or inaccurate model. It suggests that a concept has been identified but its connections to the rest of the domain have not been fully captured. Including relations ensures that your model accurately reflects the real-world relationships between concepts.

Potential Attributes:

Identifies term names that are likely to represent attributes rather than entities or relationships based on their last word.

Semantic modeling practices often encourage distinguishing between entities (things you want to model) and attributes (descriptive properties of those things). This rule highlights names whose suffixes suggest they are attributes, helping you maintain a clearer and more consistent separation of concepts.

Why this matters

• Clearer Conceptual Boundaries: Attributes (e.g., Name, Date, Balance) describe properties of entities but should not themselves be modeled as standalone concepts. A term like CustomerName is best understood as an attribute of Customer, not as an independent entity.

• Avoiding Over-Modeling: When attribute-like terms are modeled as entities, the model can become unnecessarily complex. For example, Status is usually just a property of another entity (like Order Status) rather than a separate concept in its own right.

• Consistency Across the Model: By consistently recognizing attributes based on naming conventions, you avoid inconsistencies such as sometimes treating PostalCode as an entity and other times as an attribute.

• Alignment with Common Modeling Practices: Many semantic and data modeling methodologies recommend separating what something is (entities) from how something is described (attributes). This aligns better with both conceptual modeling and practical implementation in databases or APIs.

• Predictable Structure: Identifying attributes based on suffixes or naming patterns makes the model more predictable for others to understand and extend. For example, encountering AccountBalance immediately signals that Balance is a property of Account.

How it works

This check splits a term name into words (handling spaces, underscores, and camelCase) and examines the last word. If the last word matches a known attribute indicator (e.g., id, code, balance, date,

TIP

You can select all matched terms by pressing the 'select terms' icon at the top. Then in the right sidebar select "property" as the term type, see here. Now you can hide the properties in the document settings to get a clearer picture of you entities (classes) only.

No parent in description:

Lists all terms which have a Generalisation relation with a parent term, but that parent term is not mentioned in the definition.

Mentioning the parent term in the definition is a powerful technique for building well-structured, understandable, and logically sound semantic models. It leverages the power of hierarchical relationships to organize knowledge effectively:

• Establishing a Clear Hierarchy and Context: By stating the parent term, you immediately position the current term within a broader classification. This establishes a clear "is-a" relationship and provides essential context for understanding the term's fundamental nature. For example, defining "Sedan" as "a type of Car" immediately tells us that a sedan inherits all the general characteristics of a car.

• Improving Understandability and Navigation: Explicitly stating the parent term makes the model easier to understand and navigate. Users can quickly grasp the relationship between different concepts and traverse the hierarchy to find related terms. It creates a more intuitive and organized structure.

• Supporting Logical Reasoning and Inference: When parent-child relationships are clearly defined through definitions, it enables logical reasoning and inference within the model. For example, if we know "Sedan is a type of Car" and "Car has four wheels," we can infer that "Sedan has four wheels."

• Ensuring Consistency and Avoiding Redundancy: By anchoring a term to its parent in the definition, you reinforce the established hierarchy and reduce the risk of defining contradictory or redundant properties and relationships for the child term.

Duplicating parent relations:

This lists all terms which have the same relation(s) as one of the parents.

Avoiding the explicit duplication of parent relations in child terms is a key principle for creating efficient, maintainable, and semantically clean models. While a child term inherits the parent's relations in a hierarchical structure, explicitly stating the same relations on the child term leads to several drawbacks:

• Redundancy and Increased Complexity: Explicitly listing the same relations on both the parent and the child term introduces unnecessary redundancy. This makes the model larger and more complex to read and understand. It clutters the definition of the child term with information that is already implicitly understood through the parent-child relationship.

• Maintenance Overhead: If a relation of the parent term needs to be updated (e.g., its cardinality changes, or it's renamed), you would also need to remember to update it on every child term where it was explicitly duplicated. This significantly increases the maintenance burden and the risk of inconsistencies if you forget to update all the instances.

• Reduced Clarity of Specialization: The primary purpose of creating child terms is to represent more specific concepts that specialize the parent concept. If a child term simply repeats all the parent's relations, it doesn't clearly highlight the unique relationships that define its specialization. The focus should be on the relations that are specific to the child term or where the child term participates in a relation with different constraints or characteristics.

Instead of duplication, the focus should be on:

• Inheritance: Leveraging the inherent hierarchical relationship so that child terms automatically inherit the relations of their parents. (more info soon...)
• Specialization: Defining only the relations that are unique to the child term or where the child term has a different behavior or constraints compared to the parent.
• Overriding (with caution): In some advanced modeling scenarios, a child term might override a parent's relation with a more specific definition or constraint. This should be done judiciously and with clear justification. This is feature is not supported by Termboard

Multi parent

This lists terms which have multiple parents, including the parents.

Multiple inheritance offers the potential for more expressive and concise models in certain situations, particularly when dealing with entities that naturally belong to multiple distinct categories. However, the risk of ambiguity (the diamond problem), increased complexity, and potential for inconsistencies means it should be used judiciously and with careful design considerations. Often, alternative modeling techniques like using intermediate classes, interfaces (in programming analogies), or carefully defined relationships can achieve similar expressiveness with fewer drawbacks.

Advantages:

• Increased Expressiveness and Granularity: Multiple inheritance allows a term to inherit characteristics (properties and relations) from multiple distinct parent concepts. This can lead to a more nuanced and accurate representation of real-world entities that naturally belong to more than one category. For example, a "Hybrid Car" inherits features from both "Electric Car" and "Gasoline Car."

• Reduced Redundancy (in some cases): If a concept shares characteristics with multiple independent parent concepts, multiple inheritance can avoid the need to explicitly define those shared characteristics within the child term. Instead, it inherits them from the respective parents.

• Facilitating Reusability: By inheriting from multiple parents, a child term can reuse existing definitions and relationships, promoting modularity and reducing the overall size and complexity of the model (compared to explicitly defining all characteristics).

Disadvantages:

• The "Diamond Problem" (or Inheritance Ambiguity): This is the most significant challenge. It arises when a child term inherits from two parents that, in turn, share a common ancestor. If this common ancestor defines a property or relation, it becomes ambiguous which version the child should inherit. This requires explicit resolution mechanisms, which can complicate the model. For example:

  LivingBeing
    /   \
    Animal Plant
    \   /
      Creature  (inherits from both Animal and Plant)
  

  If LivingBeing has a property "hasCellStructure," does Creature inherit the animal cell structure or the plant cell structure, or both?

• Increased Complexity and Reduced Understandability: Models with multiple inheritance can become significantly more complex to understand and reason about. Tracing the inheritance paths and resolving potential conflicts can be difficult for both humans and automated systems.

• Potential for Logical Inconsistencies: If the inherited characteristics from multiple parents are contradictory, it can lead to logical inconsistencies within the model. Careful design is needed to avoid such situations.

Circular hierarchies

Lists the terms which are in a circular hierarchy (the Generalisation relation type)

Avoiding circular hierarchies in semantic modeling is crucial for maintaining logical consistency, enabling effective reasoning, and ensuring the overall integrity and understandability of the model.