[om-list] RMeta Model Example

Tom and other Packers TomP at Burgoyne.Com
Mon Nov 20 21:31:15 EST 2000


Mark

    What do serious number-crunching programs do to represent vectors?  Do
they use C++ classes?

    Inasmuch as I followed and understood your letter about modelling
thoughts, I agree completely.

tomp

----- Original Message -----
From: "Mark Butler" <butlerm at middle.net>
To: <om-list at onemodel.org>
Sent: Saturday, November 18, 2000 6:29 PM
Subject: [om-list] RMeta Model Example


luke call wrote:

> Can you help me by describing what such a meta-model or meta-meta-model >
would look like? Envisioning it as a set of logical statements still isn't >
easy for me.

Well, basically you want an object model of your object model.  For example,
in your scheme you might have classes for the following:

CLASS
OBJECT
ATTRIBUTE
RELATIONSHIP

One way to write it would be C++ style class declaration, leaving the idea
of
a "pointer" fully abstract. e.g. one example might be:

class Object
{
 /* An object is an arbitrary thing or abstraction */

 enum { OBJECT_CONCRETE, OBJECT_ABSTRACT, ... } abstract_type;
 enum { OBJECT_DISCRETE, OBJECT_CLASS, ... } discrete_type;
};

class Class : public Object
{
/* A Class is a set of objects of arbitrary membership */
};

class Attribute
{
 /* An Attribute is a property of an object */
 /* Strictly speaking, all attributes can be rewritten */
 /* as relationships to a reference object (the domain basis), */
 /* but this is inconvenient for large classes of attributes */

 Object * object;
 string  name;
 string  value;
 Domain * domain;
};

class Relationship
{
 /* A Relationship is the one true assocation */
 /* between a pair of objects. */
 /* Logically a vector of relationship attributes */

 Object * source_object;
 Object * dest_object;
};

class Relationship_Attribute
{
 Relationship * relationship;
 Domain * domain;
 string  value; /* may be scalar or uniform vector */
};

 enum { DOMAIN_SPATIAL,
        DOMAIN_TEMPORAL,
        DOMAIN_MASS,
        DOMAIN_CAUSE,
        DOMAIN_PARENT,
        DOMAIN_FORWARD_NAME,
        DOMAIN_REVERSE_NAME,
        DOMAIN_SCALE
      } Domain_Type;


class Domain : public Object
{
 Domain_Type domain_type;
 Unit * unit;   /* unit for domain values */
 Basis * basis; /* vector basis for domain values */
};


class Basis : public Object
{
 /* defines origin and orientation for a domain */
 /* example 1: a datum for geographical coordinates */
 /* example 2: a reference event for dates and times */
 /* origin is generally irrelevant for a relationship attributes */

 Domain_Type basis_type;

 int basis_size;   /* 1 for scalars, 3 for spatial vectors, etc. */
};


class Unit : public Object
{
 /* defines fundamental unit of measurement */

 Domain_Type unit_type;
 string unit_code;  /* e.g. KG */
 string unit_name;  /* e.g. kilogram */
};


Note: Keep in mind that the the further you define classes, you nearly
automatically lapse from meta-model to model, i.e. you start defining
classes
that could be directly implemented in terms of your original meta-entities.

- Mark

_______________________________________________
om-list mailing list
om-list at onemodel.org
http://www.pairlist.net/mailman/listinfo/om-list







More information about the om-list mailing list