[ontolog-forum] Conceptual Schema, ISO TR9007 (1987) and Ontology

["Sjir Nijssen" <sjir.nijssen@xxxxxxxxxxxx>]

The email below of Ed Barkmeyer has some very interesting points.

I will add a few sentences here and there, in bold and between [[     ]].

 

Ed Barkmeyer wrote:

My take, based primarily on
discussions with manufacturing executives and a handful of consultants,
is that what the senior executives want right now is three things:

 (a) a means of organizing the captured corporate knowledge, so that it
can be searched and retrieved by people who discover they need it.  The
problem with the captured knowledge is that it is mostly in text form,
with some formal models and structures in various languages and tools. 

 

[[Sjir: this is indeed the same I learn from executives;

not only they are faced with the challenge to organize

the captured knowledge, they also struggle with the meaning

of the captured knowledge, in the sense that little or no semantics

is associated with the models specified in various languages and tools.

It is also worth mentioning that this is explicitly recognized in

ECSS-E-TM- 10-23 (European Cooperation for Space Standardization, 2010). 

The need and importance of a meaningful global model

(as the union of various models and views)

of the corporate knowledge is identified in this.]] 

In theory, this is the kind of thing we ought to be able to do better
with ontologies, [[Sjir: I invite Ed to illustrate how an Ontology could

do better than the Conceptual Schema as defined in ISO TR9007.

A Conceptual Schema as defined in TR9007 is a set of fact types (n-ary)

and all the associated validation (integrity) rules;

optionally a number of derivation rules can be added,

for more than one purpose.

In the early nineties the concept of conceptual schema has been extended

to include fact type forms (for communication purposes) and

in the mid nineties concept definitions for purposes of better understanding ]]

and it is a direct application of some of the Semantic
Web ideas.

 (b) a means of capturing corporate knowledge that may otherwise be lost
as senior staffers retire or are attracted to other firms.  One of the
big concerns -- a version of John Sowa's profferred definition of
'expert' -- is capturing the knowledge of what has been tried and
proven/judged *not* to work, and why.  Most of the existing corporate
documentation reflects what was actually built or implemented and the
decisions that were taken.  The ideas that were discarded for various
reasons are typically documented only in the minds of the people who
participated in that experience, and perhaps briefly in a few emails or
the minutes of some management meeting.  Upper management is plagued
with bright new 'ideators' seeking to make their mark.  The senior
officer can filter out those that were tried in 1982, 1987, 1991 and
1995 and can usually tell the new face when it was tried, how, and what
happened, but none of that is documented.  The idea here is to do the
knowledge engineering 'from the horse's mouth'.

 

[[Sjir: Or, in other words: not only the results of projects

are to be administered in a formal and understandable manner,

also the “lessons learned” should be administered, including the faulty lessons.

A structured means of describing and formalizing the decision

process followed is needed. ]]

 (c) a means of reconciling the information they get from various
departments, each holding different views on critical corporate assets,
processes, and plans.  The problem here is not only the 'nyms' that Jack
Ring mentions -- different terms for the same things, different
groupings/aggregations and upper level classifiers -- but also genuinely
conflicting models.  The conflicts tend to arise out of the different
KPIs and other elements of the business assessment, evaluation and
reward system.  One group counts orders placed, another orders filled,
and a third total revenue from orders; and as an order changes state,
its value to the company changes, but its value to various performance
assessments appears and disappears. 

[[Sjir: in a truly engineered Conceptual Schema, this can be

dealt with without any disappearance.]] This is an area in which ontologies
can do better than the Conceptual Schema and the Information Base of
which Sjir speaks. 

[[Sjir: I invite Ed to illustrate this claim,

taking the definition of Conceptual Schema as in ISO TR9007.

 

It may be useful to quote a few concept definitions of ISO TR9007.

 

100 Percent principle

All relevant general static and dynamic aspects, i.e. all rule,

laws, etc., of the universe of discourse should be described in

the conceptual schema. The information system cannot be held

responsible for not meeting those described elsewhere,

including in particular those in application programs.

 

Conceptualization principle

A conceptual schema should only include conceptually relevant aspects,

both static and dynamic of the universe of discourse, thus excluding

all aspects of (external and internal) data representation,

physical data organization and access as well as all aspects of

particular external user representation such as message formats,

data structures, etc.

 

Conceptual schema

A consistent collection of sentences expressing the necessary propositions

that hold for a universe of discourse. ]] 

 

Ontologies can provide formal definitions of classes
and properties (in terms of 'more fundamental' ones), which allows us to
deduce relationships, recognize (or declare) synonyms, and recognize
inconsistencies in the 'schemas' themselves.

[[Sjir: the same can be done with SQL and

a Conceptual Schema a la ISO TR9007.]]

The problem with delivering any of these results is tying the bell on
the cat's neck.  Some team of knowledge engineers has to get down and
dirty with the text resources and the individual company practitioners,

[[Sjir: I would like to add to this list the running systems. There is quite a bit

of knowledge buried in these systems. Bringing that knowledge in a

conceptual schema makes the knowledge more accessable and it can be used

in comparing the knowledge obtained from the subject matter experts.

And it also recommended to describe the knowledge that is encoded

in action sequences of business processes.]] 

 

[[Sjir: I agree completely with Ed, the need here is for a comprehensive protocol

or methodology, to be used by an engineer, not an ontology magician.]]
and tease out and formulate all of the knowledge that is presumably
resident in them.  And then the knowledge engineers have to go back to
many of these resources to resolve some of the confusion and conflict. 
That is an expensive process for the CEO, not because of what the
consulting ontologists cost, but because of the time of his/her
corporate personnel assets that is consumed.  Further, it is a risky
process, precisely because it exposes the knowledge that is the
corporate advantage to external eyes and ears.  Unlike Toby's tag line,
this is an activity that must be done well -- thoroughly and carefully

[[Sjir: therefore there is a need for a comprehensive protocol

how to develop and validate a Conceptual Schema (a la ISO TR9007).]]
-- to be worth doing at all.

-Ed

Sjir Nijssen

 

Sjir.Nijssen@xxxxxxxxxxxx

_________________________________________________________________
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)