Re: Denotation, Meaning (and Humble Pie)

Date view Thread view Subject view Author view Attachment view

From: Joaquin Miller (
Date: Tue 10 Sep 2002 - 16:19:53 BST

This is lucid.  Thanks.

I only want to add that at the end of the road we need to explain to the 
UML users what a model element means, and this is (may be, hopefully can 
be) best done in terms of the representation relation from model to system 
and a discussion of conformance testing.

A trip through any layers (i expect four?? (!)) is extremely valuable for 
the reasons discussed, but we don't want to explain UML by taking the user 
through those layers.

The two items of direct interest to the user are
   m) the classes and the objects in the model and
   s)   the objects and the classes
                (or whatever we call them things
                    (e.g. that the class loader loads))
          in the system.

>   Denotation, Meaning (and Humble Pie)
>   ====================================
>Quite a lot of folk have now contributed to the recent discussion
>regarding the meaning of the word "denote" and "denotation".  I'm
>now convinced that I should have agreed with Mitch in both parts
>of his assertion (gulp! sound of humble pie being eaten):
> > An element of a semantic domain is a *denotation* of an element
> > of the non-logical vocabulary.
> > Conversely, an element of the non-logical vocabulary
> > *denotes* an element of the semantic domain.
>and I think that my confusion in understanding the direction of the
>"denote" arrow arises from confusion in determining which is the sign
>and which is the referent.  So, may I attempt to lay the issue to rest
>with the following?
>The basic meaning of "to denote" means "to stand for" something else.
>It is always the case, both in normal English usage and in formal
>languages, that the abstract sign denotes the more definite referent.
>This is true in Stuart's discussion of Montague semantics:
>In Montague semantics, the terms in the semantic domain (words that
>are the names of certain concepts) can be defined to "denote"
>physical objects in the real world, as one way of giving the concept-
>terms meaning.  (This is usually called extensional definition - you
>define some term by saying "these things are instances of the concept;
>whereas these things are not".  Extensional definition contrasts
>with intensional definition, where you say "these predicates are
>true of all instances of this concept".  In OO, you can define a
>class extensionally, as the set of all its instances, or intensionally
>by the attributes/methods that any instance must have in order to
>So, in Montague's approach, the semantic terms "denote" concrete
>referents in the world; this is because Montague is defining his
>semantic terms (abstract signs) in terms of concrete examples.
>Joaquin is right to say that "x denotes y" is different from "x
>means y".  However, in denotational semantics, the philosophical
>stance taken is that the meaning IS the denotation.  (There are
>many approaches to providing a semantics, of which the denotational
>approach is just one).
>I've checked the following with a formalist in our department,
>just to make sure that I've got my arguments lined up straight.
>In the denotational semantics approach to interpreting computer
>programs, it is assumed that terms in the programming language are
>abstract signs whose meaning has to be given in some other model.
>Typically, a set-theoretic or domain-theoretic model is used.
>This is understood to be somehow more definite (because the
>mathematical objects and their relationships are well-understood,
>in comparison to the as-yet undefined terms in the programming
>language).  So, a term in the programming language "denotes" an
>element in the semantic model, which somehow explains the
>meaning of the program term.  (This is precisely the opposite of
>what I erroneously suggested in reply to Mitch, for which I
>Note how the meaning of "denote" does not depend so much on the
>level of description (real world, syntactic model, semantic
>model) but on which things are the signs and which things are
>the referents.  So, in the Montague discussion, the arrow
>went from semantic level to concrete level, and in the
>denotational semantics discussion, the arrow went from the
>syntactic level to the semantic one.
>My earlier error was to assume that the arrow always went from the
>"abstract" semantic to the "more concrete" syntactic level;  in
>fact, in denotational semantics, the semantic domains are the *more
>definite* things denoted by the more abstract language terms.
>With regards to Joaquin's discussion over which things denote what
>in UML, I now think it is reasonable to say that:
>2U UML models denote elements in the 2U semantic domain (in a proper
>*denotational* semantics approach);  the semantic elements are the
>denotations of UML model elements;
>UML models may also denote elements of real-world systems (in some
>*operational* semantics approach).
>I now understand from other contributors that the 2U semantic model
>is itself described in terms of objects and slots, rather than on set
>theory.  If this model is totally describable in its own terms, then
>I guess there only need be three layers:  the real world, the UML
>models and the semantic domains.
>However, in order to bootstrap the novel objects-and-slots semantic
>domain, it may also be appropriate to explain this in some even
>more primitive, but better-understood concrete set-theoretic model.
>In which case Joaquin would be right in expecting the 2U semantic
>model to be further explained by a fourth level.

Date view Thread view Subject view Author view Attachment view