Analysis of multiple classification
Tony Clark  (10/11/00)

MML Design Document: 1
Author: Tony Clark
Date: 10/11/00
Title: Analysis of multiple classification.


All MML objects have a single 'of' link. All classifiers have
corresponding semantic classes. This leads to a conflict: an
object which represents the meaning of some classifier should have
an 'of' link that leads to the classifier, currently the 'of' link
leads to the appropriate sub-class of Instance.


Package is a classifier, PackageInstance is a semantic domain class.
Given a package p and a package instance pi where should the 'of'
link go to? pi.of = p or pi.of = PackageInstance?

Exp is a classifier, Calc is a semantic domain class. Given an expression
e and a calc c then c.of = e or c.of = Calc?


It has been suggested that we need to have multiple 'of' links
from objects. This would allow a semantic object to be linked to its
data type AND the appropriate instance of Classifier. This has significant
implications for the rest of MML and MMT.

The following examples show how this scheme might work. Suppose that
the only thing we can create are objects with slots. The current MMT
syntax for this is:

  @C s = v; ... end

where C evaluates to produce a classifier, s is a slot name and v
evaluates to produce the corresponding slot value. There can be any
number of slots.

The proposal is to generalise this to:

  @{C1,C2,...} s = v; ... end

so that an object has any number of classifiers so long as it has at
least one. Therefore, if:

  o = @{A,B,C} x = 10 end

then o.of = {A,B,C} and o.isKindOf(A) = true, o.isKindOf(B) = true,
o.isKindOf(C) = true and o.x = 10.

Suppose that this is applied to the package and package instance problem.
Define package p:

  p = @{Package,Object}
        name = "P";
        parents = {};
        contents = Set{
            name = "Dog";
            parents = {};
            attributes = Set{
                name = "owner";
                type = String

NB Dog.parents = {}, this is a change to the current situation where
Dog would have to inherit from Object. Of course we could get it to
inherit from the appropriate model class if necessary (e.g. ModelElement).

Create a package instance:

  pi = @{p,PackageInstance}
         contents = Set{
             owner = "Mr. Brown"

So now, pi.isKindOf(p) = true and pi.isKindOf(PackageInstance) = true.
Note that in both cases the invariants for p and PackageInstance will

Dealing with expressions as classifiers is a bit more fiddly since
there is more going on. Here is a sketch:

  e = @{Multiply,Object}
        left = @{Literal,Object} value = 10 end;
        right = @{Variable,Object} name = "x" end

  c = @{e,BinCalc}
        bindings = env;
        left = @{e.left,LiteralCalc}
                 bindings = env;
                 result = 10
        right = @{e.right,VariableCalc}
                 bindings = env;
                 result = 20

  env = @{Binding} name = "x"; value = 20 end

I would suggest that the following defaults are adopted:

  @X ... end is shorthand for @{X,Object} ... end

  @ ... end is shorthand for @{Object} ... end


(1) Model elements no longer have to inherit from instance classes.

(2) Multiple classes are mixed together at the point of use.

(3) Very expressive when dealing with semantic mappings.

(4) The multiple inheritance specificity problem appears simplified.


It has also been proposed that the processing of ... in an expression
@C ... end is handed over to the class C, i.e. the meta-level defines how to
create objects of specific types. This is consistent with other approaches.
Therefore, the low-level syntax used in this proposal would probably only
be used by MML systems engineers.


Having multiple 'of' links is very non-standard, I cannot think of any
other system that has it. It has significant benefits, but may cause
problems that have not yet surfaced. It the very least the guts of MMT
will have to be modified and the whole of the definition of MML will
have to be checked very carefully.

The same effect can be achieved using multiple inheritance. However, such
a solution winds up with ugly kludges where packages (e.g. p) inherit
from both packages and classes.

previous message
next message

back to MMF page