SUO: RE: Resolution of Comment #1 "Target Number of terms"
This message from Bill Burkett WBurkett@pdit.com bounced, so here it is
again:
I apologize to James for not letting "sleeping dogs lie", but the following
message came across my desk this morning and presents a more
practical-experience-based alternative to my argument for fewer concepts in
the SUO. I apologize for all the acronyms, but the gist of the message is
that implementing large numbers of classes is very problematic for data
access and interoperability.
"Dear Luis,
Yes the projects that tried to bind CORBA to the SDAI experienced
big problems because an SDAI binding of STEP requires many classes
and most (all?) CORBA implementation do not perform well when
they are required to send messages between hundreds of small
classes.
The granularity problem is easier to deal with in the SDAI P27
using Java serialization because all the classes are loaded into
the local application. However, a new problem arises because
it takes a long time to load the Java classes.
Also for both approaches there is a common problem of programmer
understanding. You have to be a STEP expert to write applications
against 500 classes.
In consequence, the SDAI that is working well today is the SDAI C
binding. This binding is being used by STEP and geometry experts
to write STEP translators. Most of the major CAD systems contain
a STEP translator written using some variety of SDAI C binding.
The search for an "easy" interface for STEP programming continues.
The current focus is on using XML to provide this capability.
The XML bindings for STEP being developed in the Part 28 project
give STEP data a much more descriptive representation than
Part 21 because all the attribute information is repeated for
every entity instance. With the right approach, the XML data can
be organized so that with a little knowledge you can read the
description and understand the meaning. This is a big step
forward (pun intended) because with Part 21 you need to have
both an EXPRESS-G description of the data and the STEP mapping
tables in order to get any understanding of the Part 21
information.
Lastly, by combining STEP XML with the Document Object Model (DOM)
you can build a new CORBA (or OLE/COM) interface to STEP
that contains far fewer classes, resulting in much better
performance and easier programming."
------------------------------------------------------------------
William C. Burkett 562-495-6500x13
Product Data Integration Technologies, Inc. 562-495-6509
100 W. Broadway Suite 540 wburkett@pdit.com
Long Beach, CA, 90802 USA http://www.pdit.com
------------------------------------------------------------------
-----Original Message-----
From: Schoening, James R CECOM DCSC4I
[mailto:James.Schoening@mail1.monmouth.army.mil]
Sent: Monday, August 21, 2000 12:35
To: 'Standard-Upper-Ontology (E-mail) '
Subject: SUO: Resolution of Comment #1 "Target Number of terms"
SUO,
It appears we do not have consensus to change the target size of SUO to
~300, as suggested in Comment #1(below) by Bill Burkett. Bill has stated
that while he is still uneasy about the
target size of 1000-2500, he is "...willing to go along with it given the
subsequent discussions about structuring, specialization, and organization
of concepts."
As such, unless anyone objects, we will stay with the original
target of 1000-2500.
Please also keep in mind that this is cited as an 'estimate.' If we
later find the best size is smaller or larger, we will not be bound by this
range.
Jim Schoening
-----Original Message-----
From: Schoening, James R CECOM DCSC4I
Sent: Monday, August 07, 2000 21:10
To: 'Standard-Upper-Ontology (E-mail) '
Subject: SUO Comment #1 Resolution
SUO,
SUO Comment #1: Bill Burkett writes:
"I believe that the objective of 1000-2500 terms is far too large to
be practical. In my experience, I've found that the practical upper limit on
the number of independent object/entity types in a schema is ~300 types.
Models larger than this simply cannot be comprehensively understood by a
single person. (One may argue that it's possible to understand larger models
with the aid of a meta-level organizing structure - and I agree - but then
*this* structure becomes the upper level ontology.)" ( The full text of
this message is located at
http://ltsc.ieee.org/records/suo-votes-2000-07-26.htm#bill)
One reply already posted was from Adam Pease, who wrote:
"Folks in the HPKB project including Cycorp, Teknowledge and Stanford used
the Cyc upper model of 3000 terms successfully in several tests. I take this
as an existence proof that refutes your assertion, or more gently, maybe it
just refutes the need for an individual to comprehend the entirety of a
model for that model to be useful."
This comment is now open for discussion. Is 1000-2500 too large? If so,
what would be a better range to target?
Jim Schoening