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,
- 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.
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. Alas, most E/R modelers don't pay attention to the semantics
of relationship naming either.
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.
- 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.
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 2) The hype that suggested that
there exists such a thing as "object oriented analysis", and
UML was an _expression_ of that.
(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.)
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.
- 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.
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.
????
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.)
But all of this is describing the technology for creating a solution, not
analyzing the problem space.
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.
Boy don't I agree! But it was an interesting
adventure...
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.
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. 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.
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.
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.
(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.
I agree. Both are flawed. I have set out to create an
approach to semantic modeling that minimizes the weakness and builds on
the strengths of both.
Even here, of course, Goedel is lurking in the shadows.
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
_________________________________________________________________
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)
|