Ed Barkmeyer wrote:
Yes! We have to show them what we
can do with ontologies, per se, because people have also been doing knowledge
engineering in the development of software (/hardware) systems for 50 years. One
version of the sales pitch is that ontologies are the next generation data/information
models -- they focus on the domain concepts and their relationships and not the
software renditions of them. But that alone generates shelfware. We must show
what we can do with these models that cannot be done with data/information
models (and the database schemas and OOPL classes generated from them). Otherwise
we have achieved formally grounded information models, full stop -- an academic
nirvana with no demonstrated value to the people who pay for model and software
I agree with Ed that the ontology community should be
invited to show what cannot be done with a Conceptual Schema and an associated
fact base that can be done with an OWL expressed ontology.
A few facts and questions are probably worth
Technical Report TR9007 (1987) “Concepts and Terminology for the
Conceptual Schema and the Information Base” defined what a Conceptual
Schema is and that the 100% principle applies to validation rules (integrity
rules, constraints). Most published ontologies hardly cover ½ of the needed
validation rules as defined in the ISO TR9007 report.
law gigo not applicable to questions asked from the A-box?
it help to remark that an OWL ontology is a good step backward viewed from the
100% principle of ISO TR9007?
Halpin’s Ph. D. of 1989 formalized conceptual information modelling in
seems that the conceptual modelling progress made in the seventies and eighties
in the semantic database research and application community is not easily available
to the ontology community.
limitations and inconveniencies of binary models have been extensively discussed
at many conferences in the seventies and eighties.
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ed Barkmeyer
Sent: dinsdag 4 januari 2011 17:09
Subject: Re: [ontolog-forum] Quote
for the day
Two somewhat related observations from this thread:
John F. Sowa wrote:
> Before we try to sell [business persons] on the idea of using
> we have to show them some advantage. They know their business far
> than we do, they've been running it successfully for a long time,
> need to show some clear value in this newfangled O-stuff.
Yes! We have to show them what we can do with ontologies, per se,
because people have also been doing knowledge engineering in the
development of software (/hardware) systems for 50 years. One version
the sales pitch is that ontologies are the next generation
data/information models -- they focus on the domain concepts and their
relationships and not the software renditions of them. But that alone
generates shelfware. We must show what we can do with these models that
cannot be done with data/information models (and the database schemas
and OOPL classes generated from them). Otherwise we have achieved
formally grounded information models, full stop -- an academic nirvana
with no demonstrated value to the people who pay for model and software
In the QUOMOS effort, we used a different pitch for the BIPM
(International Bureau of Weights and Measures) folk. We told them there
should be a standard measurements ontology that they controlled, so
two dozen uneducated software engineering standards teams would have no
excuse for building their own conflicting models and thus making a mess
of 21st century international trade. But in a certain sense, we were
just pitching the ontology to a different set of academics. Their
primary concern is about what is to be measured, what the quality of
measurement is, and how the measurement and its quality are expressed.
Those specifications are used in government specifications and contract
rules. Industry folk rely on the references to the common standards,
their specialists use the details of the standards in designing their
quality controls. The idea of the standard ontology is just to ensure
that the BIPM knowledge is what is engineered into the standard form
the reasoning technologies that will supposedly be used in industry. It
doesn't convey advantage in its own right.
This leads to observation 2:
Anders Tell wrote:
> An old and tired example, the Invoice or RequestForPayment
> Not really a good example since most Invoice ontologies are old
> fashioned, since they are based on modeling paper/document
> Invoices instead of corresponding to requests for reciprocal
> for delivery.
John is correct that business people have been keeping records and
executing business transactions for 4000 years. One of the problems we
have is that they developed standard paper forms for these records and
transactions over 100 years ago, and their first efforts to automate
records and transactions 50 years ago were to create software models of
the paper forms, from which the paper forms could in fact be printed. I
am sad to say that 50 years later, and 30 years after the widespread
of databases, the UN/CEFACT gang still thinks in modeling paper forms
(electronic documents) for electronic transactions and record keeping.
It is the culture of business administration people to think in terms
the paper form, rather than its information content. If you customarily
put three different information groups in the same box on the form, but
for somewhat different transactions, they are three different concepts
that have no business content in common. But the administrator will
insist that there is a common supertype, or a common object that
subsumes them all by having a set of undefined text components.
So in order to provide value for business ontologies, we have to
overcome this mentality and demonstrate substantial improvement in some
business processes. Anders suggests that we drop the form concept and
concentrate on the information required for each process-at-hand, with
some general categories of message that are standardized, and some
partner-specific refinements. In a certain sense, this is the
ontological version of the CEFACT approach -- defining standard
with mostly optional components, each of which has many optional
information elements (with extensive definitions that use many vague
> Anyway, maybe an request for payment could be modeled something
> these lines:
> A Message MOT ala UN/CITRAL: "Communication” means any
> declaration, demand, notice or request, including an offer and the
> acceptance of an offer, that the parties are required to make or
> choose to make in connection with the formation or performance of
> - with Communication adaptation(extension) point.
> RequestForPayment Communication: with reciprocal Delivery and
> - Reference to a Product MOT with core semantics including the
> recognition that different people view Products differently
> of work perspectives, processes, life cycle, etc.
> - with a Product adaptation(extension) point.
> An industry adapts their own Product' MOT for their constituents.
> Two trading partners adapt and agrees on their own adaptations,
> on their industry's Product' MOT
This is the approach of the ISO/OASIS Product LifeCycle Services (PLCS)
standards gang. They allow for successive levels of standardization,
each of which defines common practices for a smaller industry group and
allows for trading partner specializations and adaptations. Their
models, however, are currently written in a combination of EXPRESS
an OWL derivative) and XML Schema, so that they actually get
in commercial software. One of the key ideas in PLCS, and Anders'
proposal, is that the reference models are the definitions of the
transactions, and the XML schemas define the organizations of the
corresponding data for exchange purposes.
> The above is an example of an eco-system view of ontologies.
After the abuse of this term in OMG and elsewhere, I don't know what an
'ontology eco-system' might be. So if Anders says this is one, who am I
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx