How to Know When and Why You Should Use Schema Extensions

Published by on July 22, 2015 at 2:37 pm.

How to Use Innoslate for Intermediate Users

As customers become more familiar with Innoslate, they often ask me, “How do I capture these additional pieces of data in the model?” In this post, I will be answering that question by having a discussion on what a schema is, when not to create a schema extension, and when to create a schema extension.

What is a Schema?

A schema is the term used to represent the taxonomy (the bins that data falls into) and ontology (the relations between those bins). One of the reasons for a schema is to create an underlying common language that captures and communicates the necessary information.

Innoslate uses the Lifecycle Modeling Language (LML) as its base schema. LML specifies two major areas: (1) the classes (the taxonomy) and (2) relations (the ontology). Classes are differentiated between each other by having unique properties on them. For example, on the Action class (used to capture things like Activities and Functions) there is a Duration property, Start Time property, and a Percent Complete property. Relations are differentiated based on what two classes a single relation connects. The relation generates connects Action to Input/Output.

A major sticking point in the Systems Engineering community is that many people do not like to talk about schemas, as they feel that they are too complex and designed so that only experts can understand them. While this may be the case for some schemas, LML was designed for simplicity and is often recognized as one of the easier ones to learn.

On the opposite end of the spectrum is not having a schema at all. I have found that while someone may claim that they do not have a schema, in fact they do. Their schema may not be formally documented and might not the have the breadth of a formal one; however, the basic concept is there. Any time there is a need to differentiate between two pieces of data a schema, even at the most basic of levels, is needed.

One of the unique attributes of LML is that it was never designed to be a 100% model capture schema. The reason for this is that when schemas claim to be a 100% capture they often ignore a property a systems engineer would want to model or require an awkward obtuse way of capturing it. LML recognized this and instead focuses on creating a robust 80% solution that can be used as the basis for additional classes/properties to be added as needed.

When NOT to Create a Schema Extension

It is a bit quizzical to say that LML is a great starting point for a schema extension then to go straight into “When Not to.” However, there is a reason for this: overextending.

What I mean by overextending is the idea that just because you can, means you should. I have seen too many cases where someone has created a schema extension to handle a single additional attribute on a single entity. This creates unneeded fluff and confusion over why it is there. For situations like this, where a small group of entities needs a bit more info, I recommend creating “Characteristic” entities. A Characteristic entity is already related to most other classes via the “specified by” relation. Also, that single characteristic entity can be re-used and related to multiple other entities reducing model duplication.

The second common way of overextending is to extend an existing LML class without adding any attributes. Most of the time this is done as an alias mechanism. To create aliases we recommend that you use a label instead. For more information about using Labels as an alias /typing, see “Typing” under the Labels & Search blog.

When to Create a Schema Extension

If you decided that a schema extension is the correct choice, then there are a couple of things that you need to consider.

First, are you adding value? One thing we tend to do is assume that we need to capture everything. Does a property add value if it is never used? I recommend that in a separate project build a test schema and then bring in the data (or a testing subsection). Does the schema cover what you are looking to capture or was there something you forgot? Remember you can keep creating new project and testing out schemas that work for you.

Second, if you are adding a property does it need to go on the root class or should you create a new class? If you are adding a property to the root class, all entities of that class will have that property. If this is not ideal it might be necessary to create a new class and set the parent of that new class to an LML class. This way you can add a property to the child class, and still inherit all the properties and relations from the parent.

Third and finally, if you are adding a new class that is not under another class, what relations do you need? I have often seen people create a new class and then not have any relations to any other classes. Most of the time this is done unintentionally and once the error is pointed out either add relations or remove the class (See the first question). Having a relation between classes adds the additional traceability and linkage that is not there if the data is just hang out in the model.

 

Below are examples of some of the most common schema extensions:

Adding a Property

  • Status on Requirement: Depending on the requirements generation process, it may be necessary to identify requirements that are still in draft stages. A Status attribute would show where that requirement is in that processes. Status is often represented as a text or enumeration type.
  • Priority on Requirement: If a stakeholder has indicated that some requirements are more important than others, a priority attribute would be used. This priority would allow each requirement to have a value that could then be sorted/filtered on. Priority is often represented as a number type.
  • Weight on Resource: Use if the resources you are modeling have a physical weight to them. Weight is often represented as number type.

Adding a Class

    • Stakeholder Need (child of Statement): Capture stakeholders’ needs before they are turned into Requirements. This new class would be a child of “Statement”, inheriting all of the properties and relations. Some example additional properties could be: Captured By, System Role, and/or Representing. An example additional relation could be “leads to/lead from” to Requirement.
    • Component (child of Asset): As an Asset Management System, it might make sense to add an additional child class to Asset. The example here, Component, might include properties such as: Unique Number, Reference Drawing Location, and/or POC.

If as you read this you are still confused as to how to create a schema extension, or would like to discuss if your extension is a good solution for your problem, feel free to contact our support team at: https://www.innoslate.com/contact-us/


Topics: