One
comment:
But I'm pretty sure such practical reverse engineering is
of minimal interest to the Ontology world.
MW:
If that were true, why would we have run a session on Methodologies for
developing integrating ontologies? In fact it is easily the largest practical
use of ontologies in industry.
This
certainly has been the thrust of our work. The financial industry has lots of
standards for messaging, and some at the level of common logical data models,
but the requirements for integration within financial firms has led to an
increasing realisation that what's really needed is common semantics: individual
terms, with agreed definitions and formally framed meanings, independent of all
these physical and logical data models. Those technical models have been very
good for their purposes, but each time a firm buys in a new system, adds a new
data feed, connects to a new broker or other market participant via another
feed, or merges with or acquires another financial institution with a whole lot
of similar applications (most of them having different data models), then there
is a case to be made for common semantics.
Now of course one could
address some of the need for common semantics with a good old low tech
vocabulary, but it makes a lot more sense to use the available expressive power
of formal ontology languages (or least a sub-set of those formalisms that can be
shown back to the business for validation). So that is what we've done with the
Financial Industry Business Ontology (though, for most business participants, we
still end up describing this in terms of a common business vocabulary - at least
until business folks start to understand what formal ontologies can do).
So the industry needed a formal, standardized ontology for financial
industry concepts, and this has been and is being built up along Semantic Web
principles. Would we have started with a blank sheet of paper to do this? No,
there are all those logical and physical data standards which represent
considerable work and considerable business knowledge (and in the more widely
used ones, considerable feedback from the real world so we know they actually
worked).
The message standards and logical data model standards are
therefore a good source of knowledge, the only problem with them being that,
with a few honourable exceptions, the business knowledge that business people
brought to the table was immediately hard coded into XML schemas or UML class
models without first being documented in a technology-neutral and
design-independent way. That is, while business knowledge was brought to the
table there was a double obscuration of this knowledge from the business itself:
through the chosen design of the designed artefact (XML schema, RDB or UML Class
model etc.), and through the technical language in which those designs are
typically expressed (XMLSpy, ERM, UML etc.).
This is symptomatic of a
deeper problem in many message or model standards: someone has designed a design
without ever documenting the business requirements against which that design was
designed, and in defiance of most accepted engineering practice (other than that
which is applicable to games or to one-off prototypes). That is, we have message
models without some corresponding conceptual models.
This leads to not
one but two motivations for reverse engineering from designs to ontologies:
1. It provides the "missing" conceptual model which sets out the
business concepts against which those technical standards models were apparently
designed; and
2. It provides the industry with a conceptual model for
integration, common message hub creation etc.
This is why I tend to talk
in terms of conceptual models or conceptual ontologies rather than "Integrating"
ontologies per se: integration is one of the use cases for a conceptual model
(including a conceptual model for data, i.e. an ontology). Other use cases are
in the ongoing maintenance and business validation of just about anything for
which there is intended to be some future versioning and maintenance. Like
standards. Or anything which can lose you money if it messes up.
So yes,
reverse engineering into ontologies is very much of interest to us business
problem solvers. Whether it's of interest to the "ontology world" or not is not
something I'm in a position to comment on, but it's very much of interest to the
business world :)
Mike
This week I've seen what appeared to be a promising
corporate glossary. On first use with 5 terms which were not found...
oops! That's one prospect who's never going to return. And this
was just a simple glossary.
_________________________________________________________________
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