|
Thanks Leo, John,
This is an important consideration.
When we get our first version of the Emergency Data Exchange
Language (EDXL) Reference Information Model (EDXL-RIM) ready for its
initial 60-Day Public Review it will have only been started after we
first developed three other specifications in the family:
- EDXL-DE (Distribution Element for efficient and sound,
security-capable routing);
- EDXL-HAVE (Hospital AVailability Exchange for reporting
'snapshots' of a hospital's or hospital system's capabilities); and,
- EDXL-RM (Resource Messaging for requesting resources, responding
to requests and reporting various factors related to the logistical
management of emergency-related resources).
I cite this as an example of one kind of process that has led us
up to the decision to develop an RDF Schema and OWL-DL Ontology as
well as the more familiar and comfortable XML Schema for
EDXL-RIM.
Before now, even though I suggested it several times, the idea
was deemed too new, too uncertain and too little understood in terms
of the value it could provide to gain agreement. Now the value is
clear because people and companies involved in the OASIS Emergency
Management Technical Committee (EM TC) can see how it would
codify what we have learned for easy reference in future versions and
in new specifications within the family.
Additionally, by slogging away at the process, we have also
convinced people and companies that were previously unwilling, to make
DOMs that have previously been informative only, normative. This will
also save developers a lot of time in developing applications that use
EDXL standards.
Likewise, by developing specifications that include ontologies,
we begin the process of moving the adoption of this relatively new
capability to more specifications outside this family and help build
momentum toward more widespread use of sound ontology
development.
What would be especially helpful would be if we could perhaps
find qualified employees of enterprises such as MITRE who could join
the EM TC and help guide our efforts. The EDXL-RIM effort is currently
scheduled to get underway immediately after we push EDXL-RM out the
door for its second 60-Day Public Review in January (hopefully).
Cheers,
Rex
At 6:52 PM -0500 11/17/07, Obrst, Leo J. wrote:
John,
No one I know who is seriously addressing ontology enterprise
issues
thinks that everyone is going to magically convert overnight. In
fact,
we take great pains to let stakeholders and existing customers,
potential customers, and leadership know the issues. There is no
free
lunch. So this is a false strawman or spear-jab. It may be useful
for
discussion purposes, which I assume is your purpose. So that's fine.
In
fact, I invite such a discussion.
For example, if not done right, creating bottom-up Community of
Interest vocabularies and models (ontologies) of those can result
in
conceptual stovepipes. What's to prevent an ad hoc, laissez faire
approach from generating lots of redundancy, even if everyone is
developing ontologies and firmly believes in the paradigm: nothing.
You
need strong processes and procedures, and organizational
understanding,
dedicated responsible organizational units -- at the base level
(individual COIs), at the next level (hierarchic or spanning COIs),
at
the middle level (comparable to the middle ontology level; we call
this
the Common Core, and there are multiple such), and at the highest
level
(comparable to the upper ontology level; we call this Universal
Core).
Another example, if an enterprise is embarking on the
Service-Oriented
Architecture paradigm, they must be clearly told that this new
fangled
ontology/Semantic Web/semantic technology paradigm does not
supersede
SOA but in fact extends and enriches it. There are real fears that
each
new paradigm in information technology is a fad which overthrows
the
previous paradigm. That's not true in this case.
Some of us advocate:
1) Unbundling/decomposing your existing
systems over time into
services. This is hard work and will be going on for a LONG time.
2) When new systems/applications are considered, design them as
services, i.e., reusable discrete (as much as possible) components
which can be composed to create new systems/applications.
3) Build services which are described semantically. This
description
can be initially a purely natural language description (implicit
model), or an ontology (explicit model). In either case, you will
need
grounding in natural language descriptions: that need does not go
away
with the development of a logical model (you still need to describe
in
natural language what you mean by the logical _expression_, so humans
can
inspect both and gauge conformance of the logical description with
the
natural language description).
4) For existing (legacy) systems, you need to plan their evolution
toward your semantic/SOA paradigm. All systems have a maintenance
cycle. Transforming legacy systems to a new paradigm incurs such
huge
costs that you cannot typically do that. Instead, you must rely on
the
next bullet:
5) Abstracting functional/procedural calls into the legacy system
(assuming you can do so, i.e., if the API is rich enough to
support
this; if it isn't and you just call the monolithic system and get
its
final results, this effort will not
work). Create wrappers for these
calls into the legacy systems. They become rudimentary services.
But
most legacy systems are not amenable to this, so you must focus on
the
next bullet:
6) For standalone, monolithic legacy systems (which you cannot
create
functionally distinct calls into), then you must wrap the whole
system,
i.e., treat the whole system as a single service and try to create
a
semantic model (ontology) for what that system is doing. The system
may
or may not use a distinct database.
A) If it uses a distinct database, you can try to extrapolate a
semantic model (conceptual model, local ontology) from the
physical
schema and data dictionary (if there is one). This local
conceptual
model/ontology will more easily map into the ontologies you are
developing for the enterprise. Then you must also analyze what
semantics the procedural code of the system provides, a difficult
task,
and seek to incorporate that into the emerging semantic model
(ontology).
B) If the system has no database but simply uses internal data
structures, then you must analyze those data structures and the
procedures which use those to determine the actual semantics of
the
system which could potentially be at least partially captured in a
declarative semantic model (ontology). This is hard.
So, 1) there are ways to move legacy systems along towards a new
paradigm such as involving the use of explicit semantic models
(ontologies) in an enterprise; 2) but one needs to be very aware of
the
potential for creating new legacy systems and guard against such
by
creating processes and procedures that govern the constructs of
those
new paradigms. This means new governance and policy, sociological
issues. However, these are more important finally then the
technical
constructs, because systems and paradigms fail primarily due to
people
issues, i.e., on flawed sociology.
Thanks,
Leo
_____________________________________________
Dr. Leo Obrst The MITRE
Corporation, Information Semantics
lobrst@xxxxxxxxx Information Discovery &
Understanding, Command and
Control Center
Voice: 703-983-6770 7515 Colshire Drive, M/S H305
Fax: 703-983-1379 McLean, VA 22102-7508, USA
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John
F.
Sowa
Sent: Saturday, November 17, 2007 3:48 PM
To: [ontolog-forum]
Subject: [ontolog-forum] Legacy systems
Many of the ontology proposals are based on the assumption
that everybody is going to magically convert overnight to
whatever new standard is proposed.
However, there are still legacy software systems running
today that were written over 40 years ago. The only reason
why there aren't many that are older is that computers
only
became widely available in the 1960s.
There's an article about the final days of Edison's original
direct-current service in New York City:
http://cityroom.blogs.nytimes.com/2007/11/14/off-goes-the-power-current
-started-by-thomas-edison/
Off Goes the Power Current Started by Thomas Edison
But the shut-down of DC service does not mean that the old
equipment will be shut down. Instead, they're using
converters
from AC to DC:
> The last snip of Con Ed's direct current system will take
place
> at 10 East 40th Street, near the Mid-Manhattan Library.
That
> building, like the thousands of other direct current
users
> that have been transitioned over the last several years,
now
> has a converter installed on the premises that can take
> alternating electricity from the Con Ed power grid and
adapt
> it on premises.
In 1928, they predicted that it would take 45 years to convert
all the DC equipment. But the equipment is still running
today,
even though the service has been terminated.
This provides some perspective on interoperability: any new
proposal must be able to accommodate legacy systems, and it
must be designed with the knowledge that the new system will
also become a legacy.
John Sowa
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config:
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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config:
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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|