Building RACK on MODEL

This document explains an update to the RACK ontology. Previously we were accounting for performer/tool specific properties of RACK instance data through subclassing RACK classes in performer-specific ontology overlays. This new approach will focus on the core RACK classes being much more structural and moving the different interpretations of these classes to model-classes that can be attached to them.

We achieve this with a new core class: MODEL

MODEL
    is a type of ENTITY
    described by models with a single value of type THING.

This allows us to populate the skeleton of the project as early as possible with a minimal interpretation of the project artifacts. We can then build on this skeleton with more interesting semantic models.

As a general design objective, facts about data can be contained in properties and relations on the core classes. Different interpretations of that data can be then be tracked through associated models.

Focus

A single model always models exactly one element in the project. This is captured with with a single value in the models relation.

We specify this to ensure that having models doesn't create a whole new

Independence

Each model should stand on its own. The set of models attached to any particular data is open. The interpretation of one model should not depend on another. All of the models attached to the same data should describe compatible semantics.

Let's consider an example. If we had a requirement that had three facets to it, it would not be correct to generate three distinct models of each facet to be associated with the requirement. We'd want to generate a single model that characterized all three of the facets of the requirement. If we actually needed to decompose the requirement three ways we'd first want to generate three sub-requirements and then model each of those separately.

Requirement model example

GrammaTech has a model of requirements that breaks then down into different text components along with confidence that each component was correctly distinguished.

AcertRequirementModel
  is a type of MODEL
  described by textConfidence with values of type double,
  described by ifText with values of type string,
  described by ifTextConfidence with values of type double,
  described by thenText with values of type string,
  described by thenTextConfidence with values of type double,
  described by givenText with values of type string,
  described by givenTextConfidence with values of type double.

This allows us to ingest the requirement immediately with a consistent identity and then allows the GrammaTech ACERT tool to add a more useful interpretation of the requirement.

Previous we had modeled this as a subclass of REQUIREMENT. The result of using a subclass is that we can't add the data until the interpretation is known, and additional interpretations would be incompatible as each would require a different subclass.

Queries

This design helps with discoverability. Here are some examples of queries we can write with this design:

• List all models and their types associated with a particular piece of data
• List all of a specific models of subtype for a particular piece of data
• List all models of a certain type
• List all the subtypes of models

Note that the models relation is not directional. Even though its definition is on the MODEL type, it can be used as attached to any other THING.