Meta Modeling with ConceptBase

ConceptBase supports any OMG abstraction level (M0=data level, M1=model or schema level, M2=notation level, M3=notation definition level, and so forth) and uses a single data structure called P-facts to represent all factual information regardless of the abstraction level. You design modeling languages (M2-level) based on your own M3-level, use the modeling languages to create example models (M1-level), and even represent example data/traces at the M0-level. In the example on the right, a screendump is shown with the definition of an extended entity-relationship diagramming language. The top is the M3-level:

Concept with
 attribute
    singleDef: Concept;
    necessaryDef: Concept
end

The object Concept is defining two attribute categories singleDef and necessaryDef that are used to capture the cardinality of some modeling constructs at the M2-level. The M2-level defines the symbols of the entity-relationship diagramming language:

Concept EntityType with
  attribute
    attr: Domain;
    key: Domain;
    superType: EntityType
end

Concept RelationshipType with
  attribute
    role: EntityType;
    max_1: EntityType;
    max_2: EntityType;
    max_n: EntityType;
    min_1: EntityType;
    min_2: EntityType
end

The Datalog-based constraint language of ConceptBase allows to capture the semantics of (some of) the notational symbols of the M2-level. In this case, the cardinality symbol max_1 is defined to allow at most one filler for a relationship role link A.

Class RelationshipType with
  constraint
    ic_max1: $ forall A/RelationshipType!max_1 a1,a2,r/Proposition
                   (a1 in A) and From(a1,r) and
                   (a2 in A) and From(a2,r)
                ==> (a1 = a2) $
end

The M1-level (see below) is used to represent some example entity-relationship diagram. The definitions below use the same frame-like textual representation. This is the format accepted by the ConceptBase server at its programming interface. Dedicated client programs can generate the frames from user input to a graphical interface optimized for the respective notation.

EntityType Staff with
  attr
    name: String;
    hired: Date;
    salary: Integer
  attr,key
   staffno: Integer
end

RelationshipType employs with
  role, max_n
    employee: Staff
  role, max_1
    employer: University
end
...

Finally, the M0-level is used to validate the example diagram with some data. Note that some definitions at the M2-level can only be checked at the data level. For example, vardinalities of relationship types refer to properties of actual data, not to properties of a diagram!

employs emp1 with
  employee
    who: willi
  employer
    where: RWTH
end

While other system can also represent all OMG abstraction level for meta modeling, ConceptBase allows you to specify rules, constraints, and queries at any abstraction level. Actually, the query language of ConceptBase makes no difference at all about the abstraction level of the objects it refers to. The assignment of objects to abstraction levels is indeed relative: an object can be defined as an instance of another object called its class (see green links in the screendump), that class can be instance of a third object called the meta class of the original object. Hence, willi has the meta class EntityType. At the same time, Faculty has the meta class Concept. The data model of ConceptBase would also allow to link objects from different abstraction level:

Concept with
  attribute
     created: "1-Jan-2004: 12:03"   {* link from M3 to M0 *}
end

Models like ERD models can be excerpted from ConceptBase in various output formats. You can for example translate ERD models to graph representations for the Graphviz package and have it layed out automatically.

http://conceptbase.cc -- Contact: M. Jeusfeld, Tilburg University, Postbus 90153, 5000 LE Tilburg, The Netherlands -- 9-Feb-2005