RE: [discussion@2uworks.org] RE: [wg@2uworks.org] 3C + 2U = xP?

From: Joaquin Miller (miller@joaquin.net)
Date: Sat 07 Sep 2002 - 14:57:45 BST

```Thanks.

The statement from the draft is:

> > >A consequence of the semantic domain design principles is that the
> > >semantic domain should not contain equivalences; i.e. all semantic
> > >elements denote distinct concepts.

concepts.  That was not my problem, but i appreciate the discussion.

I had not even come to the equivalences yet.  What has had me confused for
a couple of years is just what 2U intends to mean by 'semantic
domain.'  Recently I thought i had a pretty good handle on it.  Then i read
the excerpt above.

In my uneducated understanding, the standard (a standard) approach is to
have a theory (model to us UML users), and then an interpretation function
that takes items in the theory into items in a model of the theory (perhaps
called 'semantic domain' by 2U).  And perhaps more sets of interpretation
functions and model, giving other interpretations of the theory.  Tarski
gets credit for making this standard (insofar as it is).  This is my
understanding of one meaning of 'formal semantics.'  For mathematicians,
that is the end of the story.

We are trying to build systems, so we have something different to deal with.

We start with the model (theory) and the world (our system in the
world).  That's all there is on the shop floor.  Testing is looking at the
system and seeing if it matches the model.

Along come the formalists, and want to help us with what they call
'semantics.'   This is great, because we need all the help we can get.  The
formalists take our model (theory) and construct a mapping (interpretation
function), producing a <something> (model).

[The <something> (model) will often be some built using a particular flavor
of set theory or some kind of possible worlds thinggumbob.   2U (i thought)
uses objects and slots, instead of sets.  That seemed fine. ]

This contribution from the formalists helps us in more ways than one.  It
can uncover problems with our model or our modeling language.  It can also
help us clarify what our model means.

Now we have three things:  our model, our system, and the structure (my
"<something>" , Tarski's model) in the range (2U: semantic domain) of the
interpretation function (2U: semantic mapping).

The elements of the model (theory) represent stuff in the system.  The
semantics (interpretation function together with its range and its image of
the model in that range) provide an interpretation of the model in terms of
some formal system.  And by looking at the semantics and the system, we can
check on and better understand the representation relationship between the
model and the system.

Some particular particular individual model element represents some
particular individual thing in the system, or some particular individual
happening in the system.  Some particular type in the model is a way to
classify or check individuals in the system.  Classes in the model have an
interesting status, as they serve both as object types and as models of
classes in the system.

This makes good sense to me.  Adding the semantics to the mix seems likely
to help our sad present situation.

But i am not at all sure that is what 2U has in mind.  Particularly, i'm no
longer sure after a long and very helpful conversation with James at the
recent OMG meeting.

Now, on top of my uncertainty about whether this is what 2U has in mind, i
am faced with this:

> > >A consequence of the semantic domain design principles is that the
> > >semantic domain should not contain equivalences; i.e. all semantic
> > >elements denote distinct concepts.

semantic elements are the items in the semantic domain
the items in the semantic domain denote concepts

so my questions:

>  Which are the concepts that the items in the semantic domain (the
> "semantic elements") denote?
>  Where are those concepts found?
>  What do those concepts denote?
>  Where do we find the meaning of those concepts?

If i don't misread the text, we now have
-- the elements in the model,
-- the elements in the semantic domain,
-- the concepts these elements in the semantic domain denote,
-- possibly items these concepts denote (maybe, maybe not), and
-- items in the world, those in the system we are trying to specify.

plus, (certainly, i hope) meanings for these concepts.

That is more kinds of things than the three that make sense to me.

I don't get it.

Cordially,

Joaquin

At 05:16 AM 9/7/2002, Tony Simons wrote:
>Hi Joaquin,
>
>I think this may relate to what theoreticians in algebra and category
>theory refer to as the "initial algebra" semantics (as opposed to
>"final algebra" semantics).
>
>If I've remembered these the right way, then all semantic elements in
>an initial algebra are assumed to be distinct unless you can prove,
>using axioms, that they are equal.  In a final algebra, it's the other
>way around - you assume that elements are potentially equivalent,
>unless you can prove that they are distinct.
>
>(There are many-to-one mappings from elements in initial algebras
>onto elements in final algebras, which is why I think that things
>which are distinct in an initial algebra are equivalent in a final
>algebra.  If I have this the wrong way round, someone let me know).
>
>It sounds as if this statement is being made about the semantic
>domain, not the UML model elements.  The semantic domain is the
>underlying mathematical (eg set-theoretic) model on which the concrete
>syntax of the UML model is based and interpreted.  The idea is that
>the meaning of the UML model is made plain in terms of well-understood
>math constructs in the semantic model.
>
>For example, it is possible to say that the meaning of a standard type
>declaration  x : T  is that there exists a T-set of which x is a member.
>Semanticists write something like:
>
>[[ x : T ]] == x' in T'
>
>where x, T are syntactic elements from the concrete model and
>x' is an element and T' is a set in the semantic domain.  The double
>brackets [[ ]] denote "the meaning of" the enclosed expression.
>This gives a simple set-theoretic semantics for the notion of type.
>
>Technically a semantic domain is more than just a set.  Domains are
>constructed to have certain properties, for example, Scott domains
>are sets whose elements are partially ordered and in which you can
>construct a complete lattice of elements according to the < less
>than relation.  This kind of domain is useful for interpreting
>the meaning of things like functional programs, since you can show
>that recursion will eventually terminate, if the meanings of the
>original argument and the argument of the recursive call can be
>shown to be ordered in the lattice (the latter must be "less than"
>the former).  In ordered domains, there is always a "bottom"
>element that is less than any other element, where algorithms
>halt.
>
>If what you report 2U as saying follows this kind of reasoning, then
>the consequences for UML models are that you must provide explicit
>equivalences (in OCL) to assert that model elements are the same,
>otherwise you must always assume they are distinct.
>
>--Tony
>
>==========================================================================
>
> > From: Joaquin Miller <miller@joaquin.net>
> >
> >  From a 2U draft:
> >
> > >A consequence of the semantic domain design principles is that the
> > >semantic domain should not contain equivalences; i.e. all semantic
> > >elements denote distinct concepts.
> >
> > I'm sorry, but i need to ask what that means.
> >
> > Are the semantic elements those in the UML model or those in the semantic
> > domain, or ...?
> >
> > Which are the concepts that the semantic elements denote?
> > Where are those concepts found?
> > What do those concepts denote?
> > Where do we find the meaning of those concepts?
> >
> >
> >
> > PGP Fingerprint:
> > CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3
>
>==========================================================================
>
>Dr Anthony J H Simons                   a.simons@dcs.shef.ac.uk
>Senior Lecturer in Computer Science     http://www.dcs.shef.ac.uk/~ajhs
>Director of Teaching
>
>Department of Computer Science          tel:  (+44) 114 22 21838
>University of Sheffield                 dept: (+44) 114 22 21800
>Regent Court, 211 Portobello Street     fax:  (+44) 114 22 21810
>SHEFFIELD, S1 4DP                       univ: (+44) 114 22 22000
>United Kingdom
>
>==========================================================================

PGP Fingerprint:
CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3
```