From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David C. Hay
Sent: Tuesday, December 04, 2012 12:41 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] UML and Semantics
<snip>
My point is that an E/R model should be concerned with a particular domain, and the entity types/classes included should only be about the domain, not about technology.
[EJB] And the same is true of any model – it should be at a consistent level of abstraction in and for a given domain. The point of E/R is not to specify any implementation concern; the point of UML is to be able to express models at various levels of abstraction for the same domain. ONE of those levels is purely conceptual, a model of the “things of the business”, as Donald Chapin would have it. But another is the conceptual software solution model, which is a related DOMAIN. And one of the things the modeling community has pushed for is the ability to create both models, and relate them.
2. It is absolutely true that UML still has a lot of O-O programming baggage, like visibility, that has not been sorted out into "stereotypes" and "profiles" and other such dialect mechanisms, precisely because of the perceived target market. No rose is without thorns. You don't have to use, or show, visibility, or static or default values, or any other such Java/C++ isms. (You may have to work to convince the UML tool that you don't want to see that junk.)
The first month I spent on this exercise was figuring out how to turn off the things in the MagicDraw tool that I wasn't interested in. . .
[EJB] ditto.
3. A UML association IS a "relationship" in exactly the same sense that an ER "relationship" is. The problem is that, like an ER relationship, it is two or three views of the same conceptual relationship. The UML 'navigation' stuff is conceptually about which of those views is intended. (Of course, 90% of UML modelers think it is about whether there is a pointer-to-X member of the object structure represented by the related classes.
No, I must disagree. You correctly point out that the E/R model has a relational bias. Most of that should be dispensed with i a conceptual model, but E/R modeling does inherit the underlying fact that it is about how things are related to each other. If you have asserted that A is related to B, that is a complete sentence. You cannot separately have A is related to <something> and <something> related to B. The E/R approach is based on relational theory being fundamentally declarative. The UML approach is based on OO programming having to deal with "namespaces".
[EJB] Namespaces are about the association of meaning with symbols. The same symbol in a different namespace may have a different meaning, as in English “the head of the class” and “the head of John the Baptist” are entirely different interpretations of ‘head’ depending on what the ‘head’ is OF. Namespaces, at least in this area, in UML are nothing more than this distinction. A UML relationship between ‘vehicle’ (class) and ‘person’ class that has the ‘association end’ designation ‘owner’ can, in the weakest of cases be read “Each vehicle may have an owner, which is a person. Of course, a UML association can also have a name that is separate from the association ends. So for example the association can be called: “vehicle has owner” or “person owns vehicle”, which seems to be exactly what this supposed E/R difference is about. (In NIAM/ORM, the association can have both ‘readings’.) The problem for UML is that there is no clear guidance on how to use association names and association end names, and thus no guidance for how to read them when the model is not a drawing of a Java program/library, and there are big differences in common practice.
[EJB] I don’t know how the “A is related to <something> and <something> related to B” is related to UML.
The great insight of object-oriented programming was that it is much more powerful for being organized around the objects being manipulated than around the processes. But, (much to my surprise when I discovered this), many object-oriented programmers remain programmers. Even the definition of class is that it is a piece program code.
[EJB] in OOPLs, yes, because it is. But not in UML.
If the relationship is navigable FROM either or both of the classes, there is a "property" of things in that class that refers to the corresponding instances of the other class.
But the problem is that that "property" does not recognize the existence of the other class.
[EJB] ??? I don’t understand. The relationship is explicitly shown to be between the classes, and is so captured in the UML metamodel. The “property” is named by one of three symbols associated with the relationship, a symbol for the relationship from the viewpoint of one of the participants, and a reference to the corresponding other participant(s). What you write in that symbol is up to you.
[EJB] I have argued elsewhere, usually to no avail, that the “property” is a logical function that is derived from the logical relation expressed by the “association”. That is, the two notions are semantically distinct, and have significantly different formal interpretations, although they are closely related. For the less formally inclined, I referred to these as different “views” of the “relationship”.
It is dependent upon the "roleName" to label it. Thus "roleName" is not a predicate. This is different--big time.
[EJB] Only to a speaker of English. We are forced to put in the verb ‘has’. (And omg! “this is different , big time.”) In a Slavic language, the ‘has’ verb is rarely used. One writes: Of vehicle, owner. But in UML, it is perfectly acceptable to use the “roleName” ‘has owner’. It is just not common practice.
In formal logic terms (not far from database science terms), there is a function that maps members of that class to members of the related class. If neither end of the relationship is navigable, it is a conceptual relationship imposed on the two classes from outside, and th
ere is no such property. In formal logic terms, there is only a mapping from pairs to truth values.
UML is in this sense more expressive than E-R languages that only name the relationship (or is that the table?) and provide only one "reading" in Nijssen's terminology.
How is it more expressive? UML does allow naming in both directions, just as my version of E/R does. But the name involved is just a roleName, not a predicate.
[EJB], but the association name itself can be the “predicate”, if you insist on being pedantic about property names.
I don't really want to argue for the value of the soft and hard containment notions that can be added to UML relationships ("aggregation" and "composition"), for several reasons, but some conceptual modelers find them useful, by making clear the intended axiomatic interpretations.
If your syntax allows you to assert that each Order may be composed of one or more Line Items, then you don't need any other symbols for that. But plain vanilla UML does not permit that.
[EJB] Yes, it does. It allows you to name the association “order is composed of line items”, if you want to. If you don’t use association names, that is your choice.
All you can say is that Order has a property that is labeled order line (or some such).
[EJB] This is simply false. You can say that instead, or in addition.
There is another class hidden back there, but it's not part of the property.
[EJB] Huh??? Where did this idea come from? Choosing to model a role as a class is a particular kind of modeling commitment that I don’t often find useful.
Since composition is a common (and pretty important) kind of relationship, the UML folks decided it needed its own symbol. Unfortunately, there is no symbol for member of, player of, or any of the other infinite number of possible relationship predicates.
[EJB] Actually there is – the ‘aggregation’ symbol (the white diamond). UML, however, defines no axiom for the ‘aggregation’ category of associations that would clearly distinguish it from an arbitrary relationship. And technically, the aggregation symbol should classify the owning class as the “aggregate entity”, and that particular association/relationship as the one that the “aggregate” notion is based on. But then there could be more than one, e.g., a ‘team’ could consist of players and coaches.
[EJB] The problem with both ‘composition’ and ‘aggregation’ relationships in UML is that they imply some “mereological” axioms to the modeler, but neither UML nor most modelers actually write those axioms down. UML does say that a thing can be the component of at most one composition relationship instance at any given time.
One interesting thing about the pair of symbols for composition is that they do address 2 / 3 of the relational problem of referential integrity. "Composition" says that you cannot delete the parent in a relationship.
[EJB] Not quite. If the multiplicity of the composite end is 1..1, then deleting a composite instance creates an inconsistent world if it has components. But if the multiplicity is 0..1, the component-composite relationship is merely exclusive. The component is permitted to be orphaned (multiplicity of the actual relationship is 0). Also, if a thing can be a component of any of several possible structures, all the separate relationships are composite with multiplicity 0..1, because none of them is required. If the component thing is required to be a component of some one of them, there is no way to say that in the UML diagram, although it can be stated in OCL.
"Aggregation" says that if you do, the children are left as orphans. There is no symbol for "referential delete"--if you delete the parent, all the children are also deleted.
[EJB] Aggregation says nothing of importance. A person can be a member of a team, or not. But if the team disappears, the person is no longer a member of it – the relationship disappears. But then that is true of any relationship instance – it cannot remain in existence if any of its participants ceases to exist. “Referential delete” aka “existential dependency” is an interpretation of the composite semantics that is enforced by some libraries. The alternative is to allow a “temporarily inconsistent” world to come into existence, hoping that some unspecified element of a larger “transaction” will make the world consistent again.
<snip>
I was startled to learn from one of the reviewers of my Enterprise Model Patterns book that I have created something called a "Domain Specific Language". I did not know that.
[EJB] DSL is a big buzzword in the computer science halls of ivy. There are several tools out there that allow you to create your very own diagramming language and assign to the boxes (and other closed shapes), lines and annotations any semantics you want (assuming you have any idea what ‘assigning semantics’ means). (The late Selden Stewart called these “BLA languages”, for boxes, lines and annotations.) OMG even has a standard for exchanging DSL definitions, regrettably tied to MOF metamodels as a substitute for “semantics”. So now anyone can develop his own modeling language, with ready-made tooling to support it, at least at the level of enabling diagram construction. Having a tool that uses the result and performs a useful function consistently over many diagram authors is, of course, quite another thing entirely. It is the graphical version of XML Schema. K
I didn't define stereotypes for "entity type" and "predicate", because one of the elements I require in creating my kind of E/R model is that the diagram not be cluttered with things that don't contribute to its meaning. But I do assert that if you are looking at a "highly abstract yellow" (I use yellow to highlight the latest additions in a model build-up sequence) or "HAY" model, these are the things you are looking at. But yes, I apply my definitions of terms consistently.
So apparently it is legal UML after all!
[EJB] Who knows? I have enough trouble getting my UML tools to accept valid UML models without pushing the envelope.
Best regards,
-Ed
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Engineering Laboratory -- Systems Integration Division
100 Bureau Drive, Stop 8263 Office: +1 301-975-3528
Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
________________________________________
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David C. Hay [dch@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: Monday, December 03, 2012 3:40 PM
To: [ontolog-forum]
Subject: [ontolog-forum] UML and Semantics
At 12/2/2012 11:57 PM, John Sowa wrote:
KI
> entity relationship model semantics can exist in self-describing structured data.
Yes. E-R diagrams were introduced in 1976. Even earlier, there were
Bachman diagrams, type hierarchies, and Petri nets. Versions of all
those diagrams were combined in UML,
No. UML was developed specifically to support object-oriented program design, and had only minimal relationship to the earlier E/R notations.
and mainstream programmers used
them to specify programs and databases. They developed tools to draw
the diagrams and map them to and from the software.
Just two kinds of UML diagrams provide 99% of the useful subset of OWL:
type hierarchies and E-R diagrams. Controlled English could be added
as a very readable supplement or extension. If the SW had adopted that
as the official strategy, mainstream IT would have a smooth migration
path to ontology-based tools.
I realize that "UML" has captured the imaginations of a lot of data modelers. The problem is that the UML class diagram, as originally designed, doesn't address semantics at all. It is not a "useful subset of OWL type hierarchies and E-R diagrams". It is something quite different.
In the OO world it came from, a "class" simply refers to a piece of program code that describes something to be manipulated by the computer. Only accidentally might a class refer to a collection of things in the world. As a consequence, there are several important implications:
1. There are no constraints as to what constitutes a "class". It might be a class of things in the world ("person", "project", etc.), or a class of things to be manipulated by the computer ("screen", "interface", etc.) In semantic modeling, we are concerned only with classes of things of significance to an organization. John previously wrote a compelling essay on the conflict between calling these "entity classes" or "entity types", but I don't want to go into that here. The point is, they are not OO classes.
2. There are all kinds of bits of notation that apply only to the programming world. ("visibility", etc.)
3. (And this is most important), an "association" is not about structure. In the E/R world, a Relationship is about two (entity) classes. It represents the structure of something in the world, as expressed in a sentence of the form: <subject entity class> <predicate> <object entity class>. Thus, a relationship name represents a predicate in a semantic assertion. In UML, an association is a navigation path for software to transverse. This means that a "role name" is not a predicate at all. It is simply a label for the 2d class. (You see, even though both an attribute and an association are "properties" of the first class, the 2d class at the other end of the association is not permitted to be part of that property. (It's about something called a "namespace". Don't ask.))
I spent some time hanging out with the Object Management Group people and was inundated with the propaganda that "Oh, thanks to "stereotypes", you can get UML to cover anything". It took a long time for me to get my head around point 3, above, but finally decided to address the problem.
So, in my latest patterns book, Enterprise Model Patterns: Describing the World, I decided to use UML instead of my favorite notation. By addressing the premises I just mentioned, it turns out I could use a modified form of the UML class notation to create semantic models.
(Among other things, I had to add the Barker/Ellis standard for naming relationships to incorporate semantics. Thus, UML "roleNames" became E-R predicates.)
It worked! I would submit that that book is a candidate for a "high-level" ontology.
Because I had now convinced my E/R buddies that I had "gone over to the dark side" by using UML--as well as annoying my UML buddies for having completely bastardized their notation--I wrote a companion, UML and Data Modeling: A Reconciliation. This book specifically addresses the issues of trying to describe semantics with a notation that was not originally designed for it.
I welcome any comments and responses.
Dave Hay
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J