Re: Denotation, Meaning (and Humble Pie) (was Re: [])

Date view Thread view Subject view Author view Attachment view

From: Ulf Schuenemann (
Date: Mon 16 Sep 2002 - 20:04:24 BST

Hello everybody,

I enjoyed following this discussion about the meaning of meaning,
denotation, representation, model, etc. which are very versatile
words. Let me throw in my $.02 worth before the discussion is over.

An object-oriented model is not a physical thing. It is the model of
an existing/being-developed/hypothesized real system - the two
share some relevant quantitative/qualitative properties, but not all
properties. An certain elements of the model will model, or represent
(as Joaquin said), certain elements of the system (and their environs).

        Model(-el.) -------------> System(-el.)

This relation is the one which analysts / modelers are most interested
in, so that to them, models _mean_ systems.
[There are other cominations too: a styrofoam-and-paper object
 (physical) may model a building (physical), and Claudia Schiffer (just
 bec. Jean brought her up) may be the model of some (girl's) beauty
 ideal, ie. of an abstraction.]

Now, being a non-physical/abstract/conceptual thing, the model has
to be represented somehow in order to be able to deal with it.
This is done by expressing it in some modeling notation, usually
                 expresses                  models
                 represents                 represents
                 means                      means
 Diagram(-el.) -------------> Model(-el.) -------------> System(-el.)
 [syntactic                   [abstract                  [physical
  domain]                      domain]                    domain]

Cf. the expression[syntax] : sense[abstract] : denotation[physical] triade.

Designers of a modeling language and those trying to clarify its
meaning have to be concerned, among others, about this relation.
To them, a diagram elements _means_ a model element. (The UM*L* spec
avoids 'means' and similar words by talking of diagram elements
'mapping' to model elements.) For the user of a modeling language -
the analyst/modeler - it is ok not to care about the notational layer
and freely point to a class symbol and say "this _is_ a class" (not:
this expresses a class) "and it models/represents/means this-and-that
in the system."

However, mapping diagram elements to model elements is not the
ultimate end, since the prospective language user also wants to know
what to model by these model elements. (The modeler who introduced a
model element to model something may know what that element models,
but how can others know?) Problem is, designers of a modeling language
can only talk very generally about systems and thus give only a rather
vague meaning to the elements of the abstract domain of models (and
thus, ultimately, a vague meaning to the notation).

Here, standard approaches developed for calculi, programming
languages, etc. can help by providing mathematical models of
data and computation. These model structure and behavior of systems,
just what object-oriented models do. Since mathematical objects never
refer to unique physical objects (cf. Frege/Russell's? denotation
of "2" as the collection of all sets of two physical things),
mathematicians might prefer to say that their mathematical objects are
abstractions, not models, of systems.

 OO-Model ---------------------------------------------> System
 (-el.)   ----------------> Math-Model ----------------> (-el.)
   ^       formal meaning   (-el.)      model-of
   |       denotes?            ^        abstraction-of
   |       interpreted-as      |
   |                           |
 Diagram(-el.) ----------------' denotes

One can now define a mapping f (the "interpretation function" -
Joaquin) from oo-models to mathematical objects (of a certain domain).
For the modeling language designer f is the way how he gets the
meaning of his oo-models defined. So one might call f the 'formal
meaning', while f . model-of  specifies the meaning which the
modeler needs to use oo-models for modeling. For the modeler,
f is not _the_ meaning but a clarification, which elucidates
to him what oo-models actual mean, ie., how they model systems.

IMHO it would be wrong to talk of "de-notation" in either case because
what it gives meaning to is not a notation (syntactic domain). It is
the explanation of one abstract domain in terms of another. Hence it
is rather a kind of translation (at the semantic, not syntactic
level). The translation also enables a new account of the meaning of
the _diagrams_. "Denotation" is a better fit for this mapping from
diagrams to math. objects (expresses . f).

I hope this makes any sense. Meaning-of-meaning discussions always get
confusing so easily...


PS. Ad Tony's 'denotes':
Traditionally it is the symbols which denote, or refer to, some thing
which is therefore called the symbol's meaning. Now in Tony's example

  "let [[p]] denote the meaning of program p"

'denote' seems to go in the reverse direction. But everything is fine
if one reads this as a declaration about the "[[.]]" notation:

  Let us use the notation (symbol) "[[p]]" to refer to (to denote)
  the p's meaning/denotation = what p denotes/means ...
  and let us reserve the notation "p" to refer to p as a syntactic
  entity, a symbol.

Date view Thread view Subject view Author view Attachment view