Rex & Brand: (01)
Rex: Could you please provide a reference to the RDF and OWL-DL work
you're doing for EMTC, preferably including CAP and EDXL ? (02)
I'm with the General Services Administration and we're currently
developing a revision to our FEA reference models in OWL-DL. As well as
the initial production of the Federal Transition Framework (FTF) in
OWL-DL. We have an Office of Emergency Response & R? (OERR) with whom
we'll soon be "examining data standards." (03)
In light of ISWC '09 being in DC there should be a good connection we
can make between the FEA and EMTC. (04)
Brand: I'm guessing you're starting the long road to ISWC '09 planning.
Seems a good topic to put into the queue. (05)
Rick (06)
Rex Brooks wrote:
> 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
> (07)
_________________________________________________________________
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 (08)
|