Re: [ontolog-forum] UML and Semantics

[William Frank <williamf.frank@xxxxxxxxx>]

On Tue, Dec 4, 2012 at 11:47 AM, David C. Hay <dch@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

William, thanks for this:

At  12/3/2012 03:54 PM, you wrote:

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,

One point I neglected to make previously.  When I write of E/R, actually I am referring to something different from either information engineering (IE) or IDEF1X.  The latter in particular is only good for designing relational databases.  Any attempt to discuss an IDEF1X model with the business community is doomed to failure.  IE is better for discussing  things with the outside world, but ERwin's approach to identifying relationships is borrowed from IDEF1X and shares its impenetrability. 

 

What I have set out to do is to follow the premises of Richard Barker and Harry Ellis, who came up with a trim notation, with relatively few symbols, plus a set of rules for naming entity types, attributes, and relationships.  This is what allows one to address semantics in a model. 

Yes, this was important work, to quote John Sowa describing B & E,

Relationship names assert facts about things that are purported to exist.

But, again, I have to say, "welcome to the party'.    This is the case with mathematical logic, that has been saying this same thing for about a century.   And, note that this principle above is truly OBJECT oriented, not CLASS oriented.

 Alas, most E/R modelers don't pay attention to the semantics of relationship naming either. 

Right, and that is the point, same with UML modellers, so why take the stance that one is more suitable than the other?   What difference could it possibly practically make, to determine which not entirely suitable technique was *more* unsuitable?  What good has this bought you or the world?

My view of a semantic entity relationship model is that it must

- make effective use of Language (English is my home, but that doesn't rule out others) to describe the world.

But, as Ed B and others have pointed out, English can be and is especially misleading, as the distinction between grammar and meaning is not clean.  A fully analytic language such as written Chinese shows best where the junctures are.  Also, fully synthetic languages such as Latin. On pain of infinite regression, "has as a property" is not a relatoinship.
  

- not be connected with technology.
- be formatted so that it can be presented to a non-technical audience of people who understand the domain involved.

Both IE and UML suffer from being too connected to technology.  For want of any aesthetic standards, as practiced the diagrams produced in both approaches are unintelligible to the outside world. 

Yes, they do, so one needs to overcome this. 

For example, when you say "as practiced" you don't mean as practiced by me.   In fact, I go much further than you to make sure that no business person has to be "Taught" to read a diagram.  A diagram that is not self-explanatory is worth than useless to communicating outside a narrow community.

For example, you like 'chicken feet' to show multiplicities of relationships.  More graphical than the UML standard, I agree.  But, I stopped using chicken feet too 20 years ago when a business person said "what are those chicken feet."   So now, I WRITE "at least one" more than one, etc.   Right on the UML diagram, when multiplicity is an issue.  But I usually don't write anything, because the multiplicity of a relationship should be determined later. It is a common mistake to think that this is an essential part of a relationship  consider marriage. Consider the issue of 'tenancy' in a SaS system.    How man customers may a customer representtive have?  In a family office, exactly one?   If you do your model with very few multiplicity assertions, and let those be made at a later time, following the Kanban and general good architecture principle of deffering commitments to details until just in time, you can make much faster progress.

So, don't compare your good practice in one language with other people's poor practice in another.  And don't compare your work as an individual to the work of a standards body. Apples and apples, please.

I agree with Edward that NIEM/ORM is much better than either of them in expressing the semantics of the world, but he is right that they aren't well enough supported.

Yes, I have been UML's greatest critic over the years, for two reasons.  1) I would rather that cardinality be portrayed graphically, rather than by characters

I disagree, because while a picture is worth a thousand words, an equation is worth a thousand pictures. 

So, when the TIME COMES (just in time for a particular reuse of a specification of "marriage", I want to say that 'a man can be married to between zero and 12 women."  Or, in another culture: a woman  who is married is always married to only and all the men who consitute a set of brothers."  

Haven't you found the chiken feet to be a little restrictive?  and hey, how about that little 'o' that means zero as an option on the feet?  I thought it meant some chickens have  a id band on their leg, and others don't? 

 

2) The hype that suggested that there exists such a thing as "object oriented analysis", and UML was an _expression_ of that.

Let me point to  Rebecca Wirfs-Brock and Eric Evans. They do relate thier modelling work to software.  But this makes their work more easily accessible.   You and I think the two should be separated, and we are right. But again, we can do that ourselves. We don't have to toss out the baby.
 

(No.  there is analysis of a domain.  Once you've done  that, you can apply technology to create a solution using object-oriented technology or relational technology or whatever the current fad might require.  It is not the same thing.)

Of course. There is analysis of a domain, but you can use whatever conceptual model you choose to DO the analysis. It can be done very partially with E/R, more concisely with OWL, or more fully and richly with a tool like Enterprise architect, which lets you ship little parts to E/R and OWL.   I think everybody who thinks about this long ago realized that the "hype" you are talking about was just that. The OMG's model driven architecture recognized this, applying some but not enough of RM-ODP and IEEE a decade ago now, so the ":hype" windmill you are jousitng at is about 20 years old.

But the exercise of having to construct what I want an e/r model to be and borrowing the UML notation to do it was most salutary.

Absolutely.  And, as a reader of your pre-published draft, I said so.
 

 

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.

 

But, unless the domain is technological, you don't want technology to appear in your model of the world.  Pick your domain.  But once you've done so, the language used should only pertain to that domain.

Exactly, and so said Schaier and Mellor, two decades ago.  In books about "object oriented analysis".

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

But all of this is describing the technology for creating a solution, not analyzing the problem space.

No, not a bit. I am explaining the choices a modeller has, of what kinds of thingies he can put in his model, as did RM-ODP two decades ago.  How are you going to pick out points in a speicfication of "problem space."   you have to chose a method  Longitude and lattitude?, polar coordinates, cartesian?  The rest of what I say above is EXACTLY about being clear about the thingies in the laguage you are using to describe your problem space. Are you describing the intentions of sets - i.e., the equivelence class of all the extensions in any interpretation of the model that must logically be coextensive, or are you describing a particular specificatino of a set, or are you identifying the extension of a set in a given universe?

This is the usual argument.  My first response is that to describe the "behavior" of a Person or a Project would require a lot more than what you could squeeze into a third of a box. 

Ah, well, you are surely in agreement with the fathers or UML. That is why it integrates sequence diagrams, activity diagrams, communications diagrams, component diagrams, RIGHT IN THE SAME LANGUAGE.  When serious people are talking about behaviors, Dave, that is what they are talking about! In fact, people using UML for declarative programming NEVER put any "methods' on a so-called 'class'. Becuase the classes represent concepts, as they do in the OMG computational independent model.

It is not for nothing that process modeling, data flow diagramming, functional modeling, and entity life history modeling are comprehensive techniques in their own right.
It is not a little box in the bottom of the marriage entity.


The E/R model is about the structure of things.  To model the behavior of things is a different exercise.  Related to be sure, and the models should be linked meaningfully, but to try to do it all at once (in my opinion) introduces way too much complexity.

You are preaching to the choir, EXCEPT that the things you call comprehensive techniques in their own right are actually different views of the same problem space.  The most important is nested state transition modelling. The act of marriage is a different VIEW of being married. you would represent it with some oft thes other modelling techniques.   I think John is calling these petri nets, but only a tiny subset of petri nets can be expressed this way.  State transitions are the future of non-procedural (declarative) specifictions, desing, and implemention, and you can buy them right here the UML store, pre-connected to your entities  that go throurh the states.  I the past, it is because hese outmoted techniques like data flows were NOT connected that they had to be built separately.


Then I looked more closely and discovered that in most UML models, it wasn't actually the behavior being described.  It was the names of programs that would carry out the behavior.

It seems to me you did not look closely enough at state transition modelling.   Where's the methods?  They are gonzo.

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

Sure. And it was very good work. Without the polemics about the sad history of UML 20 years ago, it would get more of the audience that it deserves.
 
Wm

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

 

_________________________________________________________________
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
 

_________________________________________________________________
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

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