On Feb 15, 2013, at 4:56 PM, Paul Tyson wrote: (01)
> On Fri, 2013-02-15 at 13:44 -0500, John F Sowa wrote:
>> In a conference call for the forthcoming Ontology Summit, Barry Smith,
>> Chris Partridge, Anatoly Levenchuk, and Mike Bennett presented four
>> thoughtful and well organized talks. Following is the summary with
>> pointers to the slides and the audio recordings:
>>
>> http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2013_02_07
>>
>> On the whole, the presentations were good. But none of them mentioned
>> four *extremely* important points:
>>
>> 1. Trillions of dollars have been invested in legacy software that
>> runs the world economy.
>>
>> 2. That software will not be replaced for a long, long time. In past
>> experience, the lifetime of a large, mission-critical system can be
>> 40 years or more. Its replacements must interoperate with it in
>> as smooth a transition as possible.
>>
>> 3. Every attempt to replace a critical, working system with a new
>> one that could not interoperate during the transition has failed.
>> The greater the discontinuity, the greater the ensuing disaster.
>>
>> 4. Every successful introduction of new technology interoperates with
>> the interfaces, infrastructure, and conventions of the old system
>> during an extended, incremental, and evolutionary transition.
>> The duration of that transition is usually *decades*, not years.
>>
>
> That's part of the story. I would add 2 points:
>
> 5. The mother of all system disasters happened nearly 50 years ago when
> the IBM suits and their ilk commandeered the vision of early personal
> computing pioneers who wanted to augment communication and cognitive
> activities, and gave us instead a poor imitation of paper and pencil on
> a cathode ray tube. I heard Doug Engelbart speak at the Computer History
> Museum about an early demo he gave of advanced hypertext creation and
> navigation, but the IBM execs were only interested in improving the
> productivity of their customers' typing pools. Their idea of
> interoperability was "make it the best electric typewriter ever". I
> don't know the history of computer graphics applications, but something
> similar must have happened--the early developers looked at draftsmen
> putting lines and curves on mylar and decided to write a program to put
> lines and curves on a CRT. It's taken several generations of graphics
> software (each having to "interoperate" with the previous generation) to
> really begin to augment the engineer's primary goal of communicating
> design intent--and some people still don't believe that's possible
> without honoring the conventions of antique draftsmanship. (02)
+1 (03)
The mother of all such failures of imagination is one we are still living with,
the "desktop" metaphor, and the entire apparatus of "files" and "folders". Why
should a PC imitate an office cubicle from the 1940s? Here's a different one:
the PC as a workshop, where things are made out of raw materials and pre-made
components, using tools which modify them, cut them, assemble and glue them
together and change their properties. They key difference here is that the
basic component is an operation on something(s), not opening a file with an
application. Here's another: the PC as a kitchen, where foods are prepared,
cooked and served. The 'file system' is your refrigerator and pantry, with
shelves. Better still, none of these metaphors, and the PC operating system is
(what is now called) a browser, and most users don't even know what is in their
local machine and what is in the cloud. Your computer is the entire world, or
at least something like a city, and most of what you do on it involves
communication, cooperating with or negotiating with other people. (04)
I look forward to a future in which the very idea of expecting users to
distinguish between (for example) JPEG, RAW and TIFF is as meaningless as
expecting them to know how to put a binary string into a location whose address
is another binary string (which was a console operation, done with a bank of
little switches, on the first machine I learned to program seriously.) I want
to manipulate *images*, not "files" with a "type". I don't care about file
types, not should I have to. (05)
Pat (06)
> So, be
> careful how you interpret the mandate to "interoperate": sure, horseless
> carriages had to use the same roads and fit through the same passages as
> horsed ones did; but at the same time they shed many of the constraints
> of horsepower transportation, and brought on new problems requiring new
> solutions.
>
> 6. The software vendor-consultant complex plays a large role in inducing
> suboptimal system design and deployment. More people (outside the
> enterprise) profit from a botched implementation than from an efficient
> one. And regardless of system benefits or performance, software vendors
> are eager to extend vendor lock-in through proprietary formats and
> closed systems.
>
> In general I am sympathetic with John's principles regarding ontology
> development, and agree with his recommendations. I might have a slightly
> different view of how we got in this mess and specific directions to
> take out of it.
>
> Regards,
> --Paul
>
>> There was some discussion of these issues in the email list for the
>> ontology summit. I'll relate some of it to the slides of the talks.
>>
>> I'll start with Slide 19 in Barry Smith's talk:
>>> Candidate Upper Level Ontologies
>>> – Domain Ontology for Linguistic and Cognitive
>>> Engineering (DOLCE)
>>> – Suggested Upper Merged Ontology (SUMO)
>>> – Upper Cyc Ontology
>>> – Basic Formal Ontology
>>> – all reflections of recognized need for semantic
>>> standardization via upper level ontology
>>
>> That may be true of what the DOLCE, SUMO, and BFO developers say.
>> But it is definitely *not* true of Cyc. Doug Lenat has explicitly
>> said that the upper level is the *least* important. He said that
>> *all* the detailed reasoning is based on axioms and definitions
>> at the mid level and lower levels.
>>
>> The most important role of the upper level is to establish a common
>> set shared terms for types and relations. The top level must be
>> very underspecified -- usually with little more than type-subtype
>> and disjoint-from links. The lower level "microtheories" contain
>> the axioms and definitions needed for detailed reasoning.
>>
>> Cyc has been developing their ontology for over 28 years (since 1984).
>> They discovered very early (by 1989) that a single, consistent,
>> monolithic ontology was unworkable. Instead, they reorganized the
>> ontology by removing most of the detail from the upper level, and
>> pushing it down to the possibly *inconsistent* microtheories.
>>
>> Furthermore, I claim that the same principles are true of BFO, as it is
>> actually used. Following is an example.
>>
>> From http://jowl.ontologyonline.org/bfo.html
>>> Definition: An entity [bfo:Entity] that exists in full at any time in which
>>> it exists at all, persists through time while maintaining its identity and
>>> has no temporal parts.
>>>
>>> Examples: a heart, a person, the color of a tomato, the mass of a cloud,
>>> a symphony orchestra, the disposition of blood to coagulate, the lawn and
>>> atmosphere in front of our building
>>>
>>> Synonyms: endurant
>>> Disjoint With:
>>> occurrent
>>
>> For the formal ontology (in OWL), that English definition is a comment
>> that has no effect on any computation. The relation "Disjoint With"
>> is the only information that distinguishes the very underspecified
>> term 'continuant' from the equally underspecified term 'occcurrent'.
>>
>> But that assumption is inconsistent with the BFO practice. The only
>> formal constraint is that the subtree under 'continuant is disjoint
>> from the one under 'occurrent'. The metaphysics stated in English has
>> no influence on any of the reasoning with or about the BFO ontology.
>>
>> There are also many questionable points in the examples above. The word
>> 'disposition' raises a huge number of thorny, subtle, and controversial
>> issues on which professional philosophers have not reached a consensus.
>>
>> In the slides by Chris Partridge, I very strongly agree with the first
>> half dozen slides about the need for an architecture based on a "shared
>> understanding" among the key developers. I disagree with later points:
>>
>> From Slide 9 by Chris P:
>>> "Find a scientific man who proposes to get along without any metaphysics...
>>> and you have found one whose doctrines are thoroughly vitiated by the crude
>>> and uncriticizedmetaphysics with which they are packed"
>>> (Charles Peirce, Collected Papers 1.129).
>>
>> I also quote that point, but I disagree with Chris's assumptions about
>> the implications:
>>> In other words, there is going to be a top ontology anyway, Do you want
>>> to manage it directly (or manage the results of a heterogeneous framework
>>> on a piecemeal basis)?
>>
>> I agree that every ontology will inevitably have some kind of top level.
>> I also agree that it should be managed on a systematic basis. But I
>> strongly disagree with the following points:
>>
>> 1. The top level should be based on subtle distinctions that even
>> professional philosophers find controversial.
>>
>> 2. The existing diversity of heterogeneous legacy systems can be
>> (let alone, *must* be) replaced by rigid philosophical distinctions
>> that will be imposed upon every conforming application.
>>
>> Comment by JFS from the thread on the Ontology Summit list,
>>> The distinctions an ontology requires are determined by its purpose.
>>> Making distinctions that are irrelevant to the purpose can decrease
>>> its generality and interoperability. Therefore, the quality of
>>> an ontology should be measured by its *relevant* distinctions.
>>
>> Response by Alan Rector,
>>> Amen...
>>
>> Following is a revised version of the recommendations that I proposed
>> in earlier notes to the Ontology Summit list:
>>
>> 1. Avoid subtle and controversial philosophical distinctions in the
>> top levels of an ontology.
>>
>> 2. Avoid making detailed commitments in the top levels. Push any
>> complex details or distinctions into the middle and lower levels.
>>
>> 3. Design the ontology in a way that is easy to modify or adapt
>> as needed -- preferably by automated or semi-automated methods.
>>
>> Refrigerator principle: When in doubt, throw it out. Any distinction
>> that is hard to explain to a high-school graduate should be deleted
>> or pushed down to a specialized microtheory that is designed for
>> and used by the people who understand that distinction.
>>
>> John
>>
>> _________________________________________________________________
>> 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 (07)
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes (08)
_________________________________________________________________
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 (09)
|