Active Knowledge Modeling

Based on 10-15 years of experience in research and development of model-driven applications, I here propose some design principles for active modeling platforms. The objective is to provide end users with a modeling framework that is simple enough for their use, yet powerful enough to define complete executable applications. While most of these principles are known to modeling experts, few are fully supported by the modeling tools currently on the market. The principles deal with modeling language, openness and evolution, reuse and inheritance, multiple views, modeling tools and methodologies.

1. Models should be visual and graphical.
   … if end users are to model themselves, and to understand other people’s models. Visual languages act as a neutral ground between terminologies specific to different cultures, companies, or disciplines.
2. A modeling language is not a programming language.
   It should be domain-specific and always open to extension and adaptation. All elements are equal. Relationships, roles, properties, and even values can be modelled separately, assigned features, be related, and structured in part and specialization hierarchies, just like objects.
3. Metamodeling is modeling.
   Instances and classes should be modelled the same way. The metadata of an element will evolve throughout its lifecycle.
4. Reuse is best supported by templates and patterns.
   Common classes should be complemented by role specific categories, and cross-cutting aspects organised into multiple dimensions.
5. The essence of a model element is its context.
   Elements cannot be defined by themselves. The meaning of an element may depend on the meaning of any other element (semantic holism). Inheritance can occur along any relationship, so relationships can be seen as annotations, adding meaning to the elements they connect.
6. A model is a federation of multiple views.
   Views are autonomous, and may use different types for the same element. Every architecture, or model, is open and incomplete. Every view is a partial representation, and views are mutually reflective, contributing to each others’ meaning.
7. A model is always in flux.
   Models evolve through different degrees of ambiguity and precision.
8. Models should be interpreted pragmatically and executed interactively.
   There should be no separation between design time and runtime, and no compilation. Behaviour should be modelled separately from structure, to enable flexible binding.

Common modeling techniques violate most of these principles, and are not ideal for model-driven applications. UML is a visual programming language with poor support for instance modeling, property modeling and domain specific languages. Different views cannot have different metadata, inheritance is constrained and rigid, and encapsulation violates semantic holism and the separation of behaviour from structure. Artificial intelligence, ontologies, and semantic web claim to be knowledge based and provide an executable foundation. The formal logic that these systems are based on is actually even further from the users’ knowledge than programming languages. A formal representation has a precise meaning (violating principle 7) that does not in any way depend on interpretation or context (violating principles 5 and 8).

Still, some modeling technologies show promise. Microsoft’s software factories approach, and more recently their Oslo project, have picked up on domain specific languages, templates and patterns, and on seeing the model as the application. Reflective programming frameworks like CLOS (Common Lisp Object system) follow many of the principles, but their syntax is far from user-friendly (violating principle 1). RDF (The Resource Desciption Framework) is a simple language for partial specification, which allows properties to be treated like objects reflectively. The RDF Schema class system does however share most of the weaknesses of UML. OWL (Web Ontology Language) support property modeling indenpendent of object classes, which is important for industrial data management. OWL Full supports reflection, allowing users to treat all kinds of elements the same and to extend the core metamodels. This variant is however seldom applied, because it cannot guarantee sound formal reasoning for automatic execution. According to our principles, this is not a limitation of the framework. It is a correct reflection of the facts of life, the complexity of real business contexts.

When we get around to it, we plan to describe each of these principles in greater detail, with motivating examples. We  will include brief descriptions of innovative new technologies for model-driven applications, and the tools and languages section will discuss how mainstream technologies can be applied.