Active Knowledge Modeling

I’ve made a small effort to investigate the detailed properties of Microsoft Oslo, and how it could fit into a larger modeling environment that also includes Visio for business diagramming. As an example, I used the Enterprise Knowledge Architecture core, a simple language that we have defined for reflective and extensible architectures. First, the language was defined as types, extents and templates in Intellipad. Then these structures were deployed to the Oslo repository, and finally we used the data link feature in Visio to show the elements in a business diagram.

Definition in M

First I tried to express the ideas as simply and fluently as possible in the M syntax. In this phase I neither cared about the detailed semantics of M, nor about MSchema design patterns. The aim was simply to communicate concepts. This is the resulting sketch:

Initial definition of our language in M

Repository

The specification above lacks details needed for deployment to the repository. In the SQL preview windows, Intellipad provides error messages:

/*
Project compile errors:
file:///C:/hdj/Oslo/EKA/Information-direct.m(15,20): error M2026: SQL generation does not support the type ‘Any?’.
file:///C:/hdj/Oslo/EKA/Information-direct.m(16,17): error M2026: SQL generation does not support the type ‘Any?’.
file:///C:/hdj/Oslo/EKA/Information-direct.m(26,9): error M2034: The entity field ‘Origin’ requires a membership constraint (‘in’ or ‘<=’).
file:///C:/hdj/Oslo/EKA/Information-direct.m(27,9): error M2034: The entity field ‘Target’ requires a membership constraint (‘in’ or ‘<=’).
file:///C:/hdj/Oslo/EKA/Information-direct.m(8,6): error M2034: The entity field ‘Attributes’ requires a membership constraint (‘in’ or ‘<=’).
file:///C:/hdj/Oslo/EKA/Information-direct.m(20,41): error M0099: Expression ‘TypeRef: Entity: Element: { Id;Name;Description;Attributes;FieldNames }’ is not currently supported by the SQL expression generator
*/

First we have to be more specific about the types of the generic elements. We declare Property.ValueType as Text instead of any, and Property.Value as General. This creates a new problem with the constraint for Role: Property where Value in Element, because the Value field can no longer take element values. Redefining Role.Value as Element is not allowed, because it is inconsistent with the supertype definition of that field. We therefore have to define a new field for holding the element that fills the role, called FilledBy. Finally, we must add explicit membership constraints between the extents wherever a field refers to another entity. The corrected model is shown below:

Revised definition of our language for MSchema

When the model is run through the Oslo tool chain, these tables are created in the repository:

Initial database views created by MSchema

In this structure, all the different types of elements have been assigned their own _Attributes tables which refer to the overall Properties table. Other than that, Roles and Relationships refer to the Elements they connect. The specialization relationships defined in the model are however not reflected in the database structure. This repository will not know that Roles, Relationships, Objects, and Properties are different types of Elements, and the data structure cannot directly be used to represent relationships between objects, or for that matter between properties or relationships.

To achieve a better connected repository database structure, we should add

where Id in Elements.Id

to all the subtype definitions. This leads to the addition of four foreign key constraints in the database:

Revised database structure with foreign keys for specialization.

Though the critical dependencies have been represented, the database structure above is not at all normalized. An object could have a one name and description in the Objects table, and another in the Elements table, for instance. To create a suitable repository structure for our model, it seems we must use the patterns that Microsoft apply for the BPMN sample that comes with the Oslo SDK, by extending the Item, RootItem, and DerivedItem types of the System module. This model is shown below.

Revised definition of our language using the System Item-RootItem-DerivedItem pattern.

The database structure is simplified and correctly normalized:

Final database structure for our language

Finally then, we have been able to define the correct repository database structure for our modeling language. With this structure in place, we should be able to populate the database with the model content as objects, relationships, roles and properties. Note that most of the columns in the database have been inherited from the generic Oslo System types. ObjectsTable is actually just a list of the Ids of the Elements that are Objects.

Though when we start adding some instances to the model some limitations surface. First let us add some Elements by initializing that extent:

Elements {
   Elem {Name = “Element”, DescriptiveInformation = “Template”, ExtentName = “Elements”},
   Obj {Name = “Object”, DescriptiveInformation = “Template”, ExtentName = “Objects”},
   Prop {Name = “Property”, DescriptiveInformation = “Template”, ExtentName = “Properties”}, 
   Rol {Name =”Role”, DescriptiveInformation = “Template”, ExtentName = “Roles”},
   Relship {Name = “Relationship”, DescriptiveInformation = “Template”, ExtentName = “Relationships”},   
   RelshipIs {Name = “Is”, DescriptiveInformation = “Template”, ExtentName = “Relationships”},   
   RelshipIsa {Name = “Is a”, DescriptiveInformation = “Template”, ExtentName = “Relationships”},   
   RelshipEquals {Name = “Equals”, DescriptiveInformation = “Template”, ExtentName = “Relationships”},   
   RelshipMember {Name = “Member”, DescriptiveInformation = “Template”, ExtentName = “Relationships”},
   RelshipPart {Name = “Part”, DescriptiveInformation = “Template”, ExtentName = “Relationships”}
};

These test elements are representations on the instance level of the core types that we have defined. We have applied this design pattern, called templates as type representatives, in the past to model generic features on the instance level, e.g. default parts and properties. When the above statements are put into the repository, we end up with 10 rows in the Elements table. We would however like to have the same elements represented in the correct derived-item tables as well, as Objects, Relationships, Roles, and Properties. This is achieved by the statements below.

    Objects { {Id = Elements.Obj.Id} };
    Properties { {Id = Elements.Prop.Id} };
    Roles { {Id = Elements.Rol.Id} };
    Relationships {
        {Id = Elements.Relship.Id},
        {Id = Elements.RelshipIs.Id},
        {Id = Elements.RelshipIsa.Id},
        {Id = Elements.RelshipEquals.Id},
        {Id = Elements.RelshipMember.Id},
        {Id = Elements.RelshipPart.Id}
    };

Note that the names of the entities defined inside the Elements extent initialization must be qualified with the extent name, unlike for modules, where such qualification is not optional. (This is not clearly documented in the M language specification). This example illustrates some problems in the alignment between Intellipad and MSchema. Using the RootItem/DerivedItem pattern, we end up with subtyping reflected in the database, but not in Intellipad.  The object, relationships etc. defined above will be separate entities from the elements with the same Ids in Intellipad, and they will not be recognized as elements. Oppositely, in our original model M subtyping is applied. This results in the correct structure in Intellipad, but a denormalized and disconnected database structure. Intellipad does however prohibit this structure, because it would place the same entity in two tables. This model is thus not allowed:

    Objects { obj { Name = “Object”, Description = “Template” } };
    Elements { Objects.obj };

But this one, creating two duplicate entities, is allowed:

    Objects { obj { Name = “Object”, Description = “Template” } };
    Elements { { Name = Objects.obj.Name, Description = Objects.obj.Description } };

It seems that working with instances in Intellipad is not to be recommended if you apply subtyping. We may hope that the Quadrant modeling editor has better support building models that the textual editor. The BPMN language that Microsoft ships with the Oslo SDK also applies the RootItem/DerivedItem pattern, so I would guess Microsoft has come up against these issues in their visual modeling development.

Visualization in Visio

While we are waiting for Quadrant, Visio is a reasonable choice for visualizing the Oslo model content. Below we see the result of applying Visio’s data link functionality to import and visualize the 10 element templates defined above. This step was by far the easiest part of the investigation, illustrating that the Oslo tools are still in early pre-release versions. While the data content can be used in visualization rules (data graphics), and be refreshed from the database, functionality for updating the database from a Visio diagram must be implemented by programming. The code will be specialized for the database structures, so it will need to be updated when the metadata is changed in Oslo. Likewise, programming is needed to automatically connect shapes based on relationships defined in the database. The relationships shown below were added manually. This makes a generic language like our EKA a good starting point for an integrated modeling environment, because the repository database is rather generic, and does not hardwire application logic.

Visio diagram showing our instance data, with links to the repository database.