Re: [ontolog-forum] UML and Semantics

[William Frank <williamf.frank@xxxxxxxxx>]

Hi Dave,

Ah, though we very often agree, here is an opportunity for me to disagree most vociferously.

On Mon, Dec 3, 2012 at 3:40 PM, David C. Hay <dch@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

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.

First of all, object-oriented program design was developed specifically to support creating programs that ***were*** models of the world, just as E/R models were intended to do.
And, just as o-o was subverted into models of software for software's sake by most but not all, so too, whatever the originators said, E/R was USED by developers for was a way to diagram relational databases, not to model the world, except by a few wieros, (yours truly included.)  And, those same wierdos used UML in the same way, the first day it was delivered.
 

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. 

This is almost true.  It is a DIAGRAM.  A picture language.    The rules for its use are local dialects, with family resemblances between meanings, not precise meanings, just like English.   I bet there are only 0.1% of UML users who ever bothered with the formal semantics.  (thank goodness, since they are a nightmare.)  
 

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.) 

Good, from this it follows that one is free to put whatever constraints one wants on what is going to constitute a class.  That's the way I like it.  Let our languages be under-specified, so we can use them as need be.  Also, I find plenty of screens in my real world, I am looking at one right now. 
 

In semantic modeling, we are concerned only with classes of things of significance to an organization.

????

If you said a community, I would agree.  Since only communities can share meanings, and meanings have to be shared by some community to be useful.   So, this is a matter of SCOPE.  Is the community the community that is building a new user interface to a cash management application?  Is it the cash management business in an international bank?  Is it the cash management economic ecosystem that spans the globe, is it the conglomerate that constitutes the bank as a whole? 
 

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.

Yes, in a UML model of a program written is what is usually called an 'object oriented language" (which I think is a misnomer, UML being so class oriented), a class is a template that can be used to create executable peices of software, by instantiating aa so-called object from the class.   And a templatge is surely not the same thing even as a specification, for you can *specify* something without being able to create one. (for example, a biologist can specify what a platypus is, but he can't make one from the specification.)  Nor is a class the same thing as an extensionally-defined set (the set of pennies within a given square on the surface of a table at a given time.  Or the same thing as the intentiion of a set (the set of pennies that could and might be found in the square, which itself might have been specified with either polar or Cartesian coordinates, yet be the same square.)

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 think you would have been better off not to ask either.

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. 

Yes, I read this excellent book, but when you say  "it turns out", I can only say "Welcome to the Party".

There are many other reasons to prefer UML. E/R, like Class models, are STATIC.    But UML provides correspondences bettween these static structures and dynamic models of the same things. I think this is a critical part of semantics:  Sam and Sally ARE married because the GOT married, and their marriage has not been voided.   Sam and Sally can't get divorced unless they ARE married.  In fact, I think that the event based views are alot more compelling than the static views.  Marriage might be better understood as happenings, not facts.

(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.

I think that the whole so-called O-O paradigm  and E/R modelling are almost equally flawed because both are class oriented, and the real world is made up of objects.  And, except in biology, those objects are not related by inheritance, or even conform to any precise patterns. At least E/R does not give different NAMES to things and their types.  (e.g. singnals, messages).  I think that UML is more fatally flawed if we let it be, given its very silly semantics.  Or, we could stop pointing out that it is silly and USE it in ways that are useful, because their are so many tools that let us do all sorts of great things with it. 



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
 

-- 
William Frank

413/376-8167


This email is confidential and proprietary, intended for its addressees only.
It may not be distributed to non-addressees, nor its contents divulged,
without the permission of the sender.
_________________________________________________________________
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    (01)