An observation



Date view Thread view Subject view Author view Attachment view

From: Bauer, Robert (rbauer@rational.com)
Date: Tue 10 Sep 2002 - 00:10:39 BST


Mitch,

Like you, I am unfamilar with the 2U document and like you, I am often
confused because the notions of semantic domain, etc., in this thread
are quite different from the standard usage in the formal methods and
formal semantics community.

The call for a formal semantics is a good one and the deep embedding of OCL
in HOL is a good start; however, since OCL cannot fully express the
metamodel,
using ocl to define the semantics is somewhat questionable.  Note, that
semantics
is used in the sense that a compiler has a semantic analysis phase rather
than
in the denotational, axiomatic, or operational sense.

Just about 2 years ago, I worked on a language called P that defined object
models using a language that looked sort of like "C" and SQL combined with
lambda abstractions and lazy evaluation.  That language was used internally
by us to describe model transformations as a result of applying patterns.

This is a real issue:  since the "meaning" of an OCL expression is based on
the underlying model, you cannot reason about OCL without an underlying
model.
Now, since the underlying model of a model transformation does not exist
until
the model is transformed, you cannot reason about the OCL representing the
post condition of a model transformation until the model is transformed.

So, I choose representing the model, transformations, etc., in a
programming-like
language and worked on some basic floyd-hoare semantics for the language, so
that
I do simple proofs about model correctness etc. without having to realize
models,
etc. - that is, the model is represented in P as a data, the transformations
on
the model as a program in P, and the assertions, etc., are represented as
functions
written in P denote boolean or error values.

The upshot of all this is that the semantics of a model are defined in terms
of the
code generated by the model and we are left with discussions about the
syntax of that
semantics and the precise mechanism by which we discover (or prevent from
being formed)
models for which we are not able to generate code.

Ok, well just my two cents worth - still think the discussion is worthwhile
and am interested
in reading comments etc., but note:  if you want to reason, you need a
formal system so that
you can be sure that your reasoning is rigorous within that system.

robert







-----Original Message-----
From: Mitch Kokar [mailto:kokar@coe.neu.edu]
Sent: Monday, September 09, 2002 3:26 PM
To: puml-list@cs.york.ac.uk; wg@2uworks.org; discussion@2uworks.org
Subject: RE: >>>>> CORRECTION >> READ ME FIRST <<



Joaquin,

>
> > >> 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 am not familiar with the 2U document, but it seems to me that in the above
sentence the concept of "semantic domain" does not look like the "semantic
domain" that I know of. In my understanding "semantic domain" is a
mathematical domain - like sets, elements, functions. What is the meaning of
"two elements in a set are equivalent"? In my understanding, equivalence is
a logical concept. So my reading is that what they call "semantic domain" is
actually a syntactic domain. But then again, I did not read the document.

Moreover, I saw Stuart's message. So it looks like this discussion is not
that relevant to 2U. But it is an interesting topic on its own. So thanks
for bringing this up.


==Mitch


>
> if the verb, 'denotes' connects a UML model element to an element in the
> semantic domain (which seems to be how you and i read it, Mitch), then i
> want to think that the same verb will connect an element in the semantic
> domain to something else further along, not back to something in
> the UML model.
>
> i understand denotation to be an asymmetric relation.
> [ asymmetric: x denotes y implies not (y denotes x) ]
>
> which is why i asked where we could find the concepts that the semantic
> elements denote.
>
>
>
>
> =======  previous, wrong, message ===================
>
> Thanks for weighing in on this Mitch.  And welcome to the club.
>
> I'm not in a position to have an opinion on what is correct
> usage.  Instead
> i'm in the position of a dictionary maker, trying to find what
> the usage is
> (the usage of specialists, in this case.)
>
> >I think I can join the club - now I am confused. I am not sure whether my
> >interpretation of what you said is correct, but here is what I
> think about
> >denotations.
> >
> >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.
>
> This fits with what i thought the usage was.  That's reassuring.
>
> So, (i put this out for correction by the 2U authors) in 2U terms,
> an element of UML (say class or attribute) denotes an element of the
> semantic domain (say object or slot).
> and
> an element of the semantic domain (say object or slot) is the
> denotation of
> an element of UML (say class or attribute),
>
> In model theory terms, the word, if i have this right, would be
> 'interpreation:'
> an element of the model (semantic domain) is the interpretation of an
> element of the theory (UML).
>
> >If this is what you meant, then we agree and there is no confusion. But
> >I'm not sure.
>
> If this is what everyone means by 'to denote,' then there is no confusion
> about the meaning of that term.
>
> But then i'm still confused about what the draft 2U text means:
>
> > >> 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.
>
> if the verb, 'denotes' connects a UML model element to an element in the
> semantic domain (which seems to be how you and i read it, Mitch), then i
> want to think that the same verb will connect an element in the semantic
> domain to something else further along, not back to something in
> the UML model.
>
> i understand denotation to be an asymmetric relation.
> [ asymmetric: x denotes y implies not (y denotes x) ]
>
> which is why i asked where we could find the concepts that the semantic
> elements denote.
>
> ======= end of reply =====================
>
> [  Side comment: In a second meaning of 'to denote,' an element of UML
> denotes the meaning of that element.  This is the ordinary English and
> Cambridge Dictionary of Philosophy meaning of denotation.  And
> so, in this
> second meaning of 'denotation,' the denotation of an element of
> UML is the
> meaning of that element.  These meanings of 'to denote,' which i
> claim are
> two, may amount to the same thing in some cases, but in others
> there can be
> an important distinction between, on the one hand, image under the
> interpretation function in formal semantics and, on the other
> hand, meaning.
> (The formal semantics can certainly serve as a ladder to meaning,
> but if we
> want to focus on meaning, the ladder is probably best thrown away
> after it
> has been climbed.)
> (On the other hand, if we want to focus on trying to clean up the UML
> specification, (and cleaning it up will certainly help make it easier to
> figure out its meaning), then i expect we will find formal semantics
> extremely useful to keep around.  As long as it is cleanly distinguished
> from meaning.)
> Of course, specialists tend to use 'meaning' as a synonym for
> 'denotation'
> (their specialist meaning of denotation), even when the denotation they
> have in mind is in some formal "universe."  That's fine (in specialist
> discussion), since these specialists know that they mean the specialist
> meaning of 'meaning.'  But perhaps misleading when addressing the
> laity (me).
> But here i insist on beating my horse, and perhaps had better shut up on
> that, because of the danger of this side issue derailing the main
> discussion: where can we find the concepts that semantic elements
> denote. ]
>
>  > -----Original Message-----
> > >
> > > That does help, Tony, very much so.  Thanks.
> > >
> > > I had not realized that 'to denote' was also used to mean 'to be the
> > > interpretation of.'  I suppose that's because of my distinction
> > > between
> > > the range of the interpretation function of formal semantics
> > > and
> > > the system that the model represents;
> > > and because i took 'to denote' in its ordinary dictionary meaning
> > > (e.g. Cambridge Dictionary of Philosophy).  As a result
> > > of that distinction and that meaning, i would expect 'to denote'
> > > to be used
> > > with respect to the relation of a model element to what that element
> > > represents, not the relation of that element to something in an
> > > interpretation (model) of that model (theory).  So i had it
> all backwards.
> > >
> > > Probably best to avoid the jargon of the formal semantics
> trade in the 2U
> > > documents.  That's not your problem, or puml's.  I'll suggest
> it to 2U.
> > >
> > > It is reassuring to see we share the idea that there are three things,
> > > model (theory), system, and interpretation (model).  And at least two
> > > essential relations, representation and interpretation (or, as
> > > used in the
> > > text, denotation).
> > >
> > > Here is where we part company:
> > >
> > > >-- well, the meaning of the concepts-as-UML-elements is given in the
> > > >semantic domain;  the meaning of the real world/system is
> more tricky!
> > >
> > > i would say the meaning of the model elements is found in the system.
> > > and that the system has no meaning.
> > > (Sure, some things do have meaning.  If statues of the leader
> are erected
> > > in the squares, the statues have a meaning.)
> > >
> > > that's because i feel the distinction between meaning and formal
> > > semantics
> > > is central to keeping everything straight.  (and, since experts
> > > tend to use
> > > 'semantics' to mean formal semantics: i feel the distinction between
> > > meaning and semantics is central to keeping everything straight.)
> > >
> > > the (set-theoretic) semantics of a model element might be some
> > > set, but the
> > > model element does not mean some set, it means a certain item in
> > > the system.
> > >
> > > or, if we don't want to use 'to mean' in that way, then the
> appearance of
> > > an element in a model does not mean there is a certain set, it
> > > means there
> > > is to be a certain item in the system.
> > >
> > > but that is just to explain my frequent confusion.  i don't mean
> > > to suggest
> > > changes to the technical language used by experts.  i know
> that 'x means'
> > > is often used by experts to mean the image of x under the
> > > interpretation is.
> > >
> > > Again, thanks for the careful elucidation.
> > >
> > >
> > > At 10:17 AM 9/7/2002, Tony Simons wrote:
> > > >Hi again,
> > > >
> > > >Joaquin Miller wrote:
> > > >
> > > >=====
> > > > > > >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
> > > >=====
> > > >
> > > >Well I can't really comment on the wording of the 2U document, but I
> > > >I read this as meaning that each element in the semantic domain is
> > > >unique (not equivalent to any other in the domain) and therefore a
> > > >denotation of a distinct element from the UML model.  I don't think
> > > >that there's meant to be another level of concepts below the semantic
> > > >domain, which somehow explains that domain.  Granted, the
> wording does
> > > >seem a bit fluffy.
> > > >
> > > >It would have been easier to say:  "Because of the way the semantic
> > > >domain is constructed, elements in the domain are unique.  No element
> > > >is equivalent to any other."
> > > >
> > > >This would have avoided introducing "concepts" which seems to be the
> > > >source of the confusion.  I haven't seen the full context of
> the above
> > > >statement, but the "concepts" may refer to UML model
> elements, in which
> > > >case I would read this as meaning: "if two model elements are denoted
> > > >by different semantic elements, then they are distinct".
> > > >
> > > >My preferred answers to your questions are therefore:
> > > >
> > > > >  Which are the concepts that the items in the semantic domain (the
> > > > > "semantic elements") denote?
> > > >
> > > >-- elements from the semantic domain are the denotations
> (interpretation)
> > > >    of UML model elements;  it is reasonable to say that
> they "denote the
> > > >    concepts" (from the model layer above)
> > > >
> > > > >  Where are those concepts found?
> > > >
> > > >-- these "concepts" are just ordinary elements of UML models, whose
> > > >    meaning is given by the mapping to elements in the
> semantic domain
> > > >
> > > > >  What do those concepts denote?
> > > >
> > > >-- probably not a well-formed question; they model some aspect of the
> > > >    software system under consideration, but "denoting" may be the
> > > >    wrong term, since the relationship is one of abstraction rather
> > > >    than precise characterisation.
> > > >
> > > > >  Where do we find the meaning of those concepts?
> > > >
> > > >-- well, the meaning of the concepts-as-UML-elements is given in the
> > > >    semantic domain;  the meaning of the real world/system is more
> > > >    tricky!
> > > >
> > > >I hope this helps,
> > > >
> > > >--Tony
> > > >
> > > >=================================================================
> > > =========
> > > >
> > > >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
> >
> >
> >
> >
> > To remove yourself from this list please mail
> > puml-list-request@cs.york.ac.uk
> > with a message containing the word "unsubscribe".


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




To remove yourself from this list please mail
puml-list-request@cs.york.ac.uk
with a message containing the word "unsubscribe".




To remove yourself from this list please mail
puml-list-request@cs.york.ac.uk
with a message containing the word "unsubscribe".

Date view Thread view Subject view Author view Attachment view