My take: I don't think ontologies are of much use on the maintenance of existing systems, they have too much of their own ad hoc ontologies marbled into their schema and riddled through their code. The same mostly still goes for development of neo-legacy systems.
We have found Systems Integration and particularly trying to do SOA right does benefit from getting agreement on shared terms and aligning the data that has gone before, using ontologies as a basis.
David, you in particular might find this interesting: ZapThink this morning are dismissing Enterprise Architecture Frameworks as being merely ontologies.
http://www.zapthink.com/?newsletter But what I'm most interested in and most optimistic about is I think we're on the verge of a different way of building systems (indeed I'm not convinced that "applications" as
we currently conceive of them will survive) and that this new world order of enterprise system will be based at least in part on semantics.
[DMc] Dave McComb, Semantic Arts
-----Original Message-----
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Eddy
Sent: Sunday, September 12, 2010 2:41 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Language vs Logic
Pat -
On Sep 12, 2010, at 12:19 AM, Patrick Cassidy wrote:
Context for the group... & reminding Pat, since he's probably
forgotten he said this...
I am holding Pat to his statement at a SICoP meeting in approx
2005
where he said (approximately) that unless "this magic" (e.g.
ontologies, etc.) was somehow delivered & made accessible to folks in
the trenches who have zero knowledge, interest or education in
ontologies, ontologies would be nothing more than an interesting
academic exercise.
CONTEXT... I am interested in the potential use of ontology for the
development/maintenance of software applications.
I am increasingly coming to the conclusion that ontologies are simply
NOT relevant to this task.
Please tell me I'm using the wrong lance to tilt at the wrong
windmill. It won't hurt my feelings.
> Figuring out precisely what a term in an ontology is supposed to
> mean has
> three aspects: what the person developing the ontology intends it
> to mean;
> what the person reading the
documentation interprets it to mean,
> and what
> the computer executing a program using the ontology interprets it
> to mean.
> Ideally, the they will be the same, but they may differ.
I would argue that since these are highly likely to be three
different people, with all the differing experiences, perspectives &
languages that humans tote around as life baggage, "they WILL differ"
not may.
Granted my interest in systems development & maintenance may be too
narrow, I would also argue there are far more people wrestling with
systems development/maintenance language challenges than people
building ontologies.
> so good documentation is critical for
> ontologies intended to be used by more than a small tightly
> connected group.
My money is on the ONLY accurate documentation is the source
code
(assuming, of course, you can find the correct version). In
commercial applications, what paper documentation exists may have
been accurate at one point, but if the system has been in use the
code is the only accurate record. [I'd like to think weapons systems
& nuclear power plants hold to a higher standard, but I have no
experience here.]
This is in fact one of the great language challenges... as a system
transitions from paper specifications & documentation through
development into production and on to new teams of project managers &
developers (whose native language is likely NOT English), the intent
of the original language begins to mutate since there is no formal
process to ensure subsequent generations of maintainers (project
managers & coders) continue to use the same language &
meanings.
Whereas the compiler will force you to use correct VERBS, there is no
such constraint on the NOUNS... which is why organizations end up
with literally hundreds of names/nouns for the same thing.
The CD/CDE (as abbreviation for CODE) example is from just such an
experience. The original IMS DBA enforced CD as the single correct
abbreviation for several years in the initial system building phase.
She left & a new DBA took over. A new segment was added & he
evidently liked to abbreviate CODE as CDE. There was no automated
mechanism like a compiler to ensure or "encourage" him to use CD
rather than CDE. The problem comes when one searches for "-CD
" (note the space suffix, since CD was used as a suffix in data
element names) you will NEVER find "-CDE ". The devil is in the
details.
In a system that adheres to "good names" one learns that the name of
something & what it is are in fact the same. In the physical world
there a multiple forces-the dairy, the food inspectors, the grocery
store-to ensure a jug labeled "milk" actually contains milk. We
haven't quite learned this lesson yet in systems.
> For me, good documentation means to state what one intends the
> ontology element to mean,
The way you present this I interpret as saying the ontology needs to
be done BEFORE the system.
This is, of course, not acceptable since the vast majority of systems
are up & running & have been built/maintained without any
consideration at all to an ontology(s).
I don't consider reverse engineering ontologies from existing systems
to be practical. Primary argument...
since the system owner does not
consider it cost effective to maintain accurate, current
documentation, they're certainly not going to spend money/time on
reverse engineering an ontology. I also factor in that the "reality"
I look at is a small organization of 10,000 people, with 900
systems. Last year ComputerWorld said IBM, with 400,000 people had
4,500 "applications" (same as/different from systems? ...who knows).
I am at pains to point out that each one of these
"applications" (whatever an application is) was built by different
people at different times for different objectives. Then maintained
by different people... all these actors bringing different language
to the task.
> To some extent,
> learning to use a logic-based ontology is similar to learning to
> use a new
>
object-oriented programming language, but programming languages
> usually come
> with a library of immediately useful applications as learning
> examples. We
> haven't reached that point yet in the technology of ontology
> creation and
> dissemination.
Long, long ago I was beginning to work on my last programming
assignment. I angered the architect (not a word in use then) by
telling him I did not want to LEARN CICS (at that point a HOT
language), rather I wanted to USE it. Took about 10 years, but he
finally came around to understanding what I was saying. His
templates (what we'd call frameworks today) were absolutely
brilliant. From a standing start (e.g. knowing absolutely nothing
about CICS) I was able to take his templates & get 17 CICS programs
working in 2
weeks.
Twenty years later I was looking at a cross platform development
tool... and was astonished to find a template/framework tool for
$350. The earlier templates probably cost the client $500,000+.
This is the standard I hold an ontology tool to... it better not be
any more complex than a spell checker/dictionary. Clearly there's a
ways to go.
> For the time being, I look first at the logical axioms associated
> with a
> term in an ontology, then at the documentation (usually contained
> in the
> "comments' section of an ontology element)
You keep using words that are difficult to grok...
"documentation"? "comments"? They are outside my experience. :-)
Here's what I consider to be documentation...
a = b * c
Totally accurate & not very
useful. More precisely... USELESS!
Unfortunately there's a lot of this.
The same logical statement:
wkly-pay = hrs-wkd * rate-pay
Is now potentially comprehensible.
If I can determine this is code is in a payroll module then I'm going
to assume that "pay" is likely a dollar & cents amount. If I can
deduce this from just the name without needed to ask someone or fish
around in some questionable documentation, then I'm a happy camper.
But what I would really like is the ability to hot-key/right click on
these variables & see what they mean. I think this look-up facility
is possible in modern editors like Eclipse... but someone has to dig
up what the words mean in the context of their specific use... which
may or may not say anything about their meaning somewhere else in the
system.
___________________
David Eddy
deddy@xxxxxxxxxxxxx781-455-0949
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:
ontolog-forum-leave@xxxxxxxxxxxxxxxxShared Files:
http://ontolog.cim3.net/file/Community Wiki:
http://ontolog.cim3.net/wiki/ To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1JTo Post: mailto:
ontolog-forum@xxxxxxxxxxxxxxxx _________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/ Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/ Unsubscribe: mailto:
ontolog-forum-leave@xxxxxxxxxxxxxxxxShared Files:
http://ontolog.cim3.net/file/Community Wiki:
http://ontolog.cim3.net/wiki/ To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1JTo Post: mailto:
ontolog-forum@xxxxxxxxxxxxxxxx