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



Date view Thread view Subject view Author view Attachment view

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.

Your message is a valuable discussion of the business about distinct 
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.

One possible reading:
   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

Date view Thread view Subject view Author view Attachment view