koenig@urz.unibas.ch (07/05/90)
Could somebody give me references to articles or books that discuss
the application of OOP concepts to artificial intelligence problems,
esp. rule-/knowledge-based expert systems ?
Please send any information to koenig@urz.unibas.ch
Thanks.
===================================================================
stefan koenig Institut fuer Informatik
Univ. Basel, Switzerlandballou@databs.enet.dec.com (07/06/90)
> > Could somebody give me references to articles or books that discuss > the application of OOP concepts to artificial intelligence problems, > esp. rule-/knowledge-based expert systems ? > > Please send any information to koenig@urz.unibas.ch > Thanks. > =================================================================== > stefan koenig Institut fuer Informatik > Univ. Basel, Switzerland I don't know about books on the topic, but you might want to check out a workshop entitled "Object-Oriented Programming in AI" at AAAI '90. I believe attendance is by invitation only (send mail to Scott Woyak - sww@edsdrd.eds.com). There are several talks that may interest you (I'm sure you can at least get the text for these): "Frames or Objects, or Both?" Ora Lassila, Helsinki University of Technology "Frames and Object-Oriented Programming" Christian Ranthke, University of Stuttgart "Efficient Pattern Matching in Object-Oriented Programming" Mark Auburn, Inference Corp. "Object Oriented Programming for an Expert System Shell" Betrand Neveu, INRIA And many more... In short, the entire workshop looks very interesting. Cheers, Nat Ballou DEC OODB
timm@runxtsa.runx.oz.au (Tim Menzies) (07/09/90)
In article <1990Jul5.175708.809@urz.unibas.ch> koenig@urz.unibas.ch writes: >Could somebody give me references to articles or books that discuss >the application of OOP concepts to artificial intelligence problems, >esp. rule-/knowledge-based expert systems ? > >Please send any information to koenig@urz.unibas.ch >Thanks. >=================================================================== >stefan koenig Institut fuer Informatik > Univ. Basel, Switzerland i have a thesis that objects are not a knowledge representation techhique. yes, minsky's frames can be done as objects, but in a practical sense how useful are they? by that i mean, what portion of all the code of your expert systems can usefully be represented as objects? the other month, i made a strange observation. in three years of working with object tools while writing expert systems (in KEE & Smalltalk), i've never shown a domain expert my hierarchy of objects. this puzzled me greatly since "everyone" knows that objects are a great way to represent knowledge. the more i thought about it, the more i thought that objects are a great way of representing "programmer" knowledge, not expert knowledge. if i implement a user-friendly specification environment that can specify and execute nouns and verbs are taken from the expert's vocabulary (my usual method of operation), then when i review my code i find that i am using a whole host of constructs **NOT** in the vocabulary of the domain experts. i can cleverly devise a whole host of abstract classes that tease apart some useful functionality of my specification environment and the expert's domain. but i wouldn't dream of confusing a domain expert with constructs that they did not invent themselves. yes. i would use objects to build expert systems. i would rigourously apply meyer's shopping list approach to the development (i.e. view objects as a collection of services that can be delivered to the outside world and delay the writing of the top-level loop till as late as possible). this allows for incremental modification. BUT, i would "black-box" the hierarchy and offer the experts a succcinct, high-level logical specification environment that **HIDES** the implementation complexity of the hierarchy. my objections to objects as a KR method are based on pragmatic considerations. brachman has a set of logical objections. in 1983 he surveyed the field of people using frame/object tools. he listed out all the things that inheritance was being used for. his list included: - superset/ subset - specialisation/ generalisation - set membership - predicates that act on an individual - sharing of common properties - conceptual containment (e.g. a triangle is a polygon with three sides). then, a dramatic chord. nowhere, observes brachman, in that list is "pass this property" or "block this property". inheritance has no semantics per se. it can be used to implement (read, muddle up) a variety of semantic properites. brachman's thesis is that these semantic properties should eb offerred as seperate building blocks in a KR tool and not thrown in together in a mess. as a programmer, i like inheritance hierarchies. i can normalise all my code. i know that i can specify the behaviour of a whole sub-tree of objects by changing code at some high level. but thats all by-the-by for knowledge representation. back to brachman... but what about default knowledge? surely thats a useful KR trick that needs a hierarchy of inheriting objects? not so says brachman. with defaults comes the ability to override defaults. the ability to override defaults effectively negates any knowledge representation power. if john is-a bachelor and john can override any or all of the properties of bachelor, then all you can say about john is that at sometime in the past, john had all the properies of a bachelor. since then, john could have done anything with his bachelor-ness. if defaults can be over-ridden, then you can 'tbe sure about any of john's properties right now. this is all blasphemy of course. objects give you a window into the fundamental truths of the universe. as soon as you buy your copy of your KEE/Eiffel/ C++/ CLOS/ Smalltalk/ ADS 5.1/ KAPPA/ Egeria/ (etc. etc.) system, then all your specification problems will disappear and all will become so clear. any we certainly don't need programmers like YOU mr menzies. i just smile, and wait. sooner or later the project folds or my phone rings. anyway, you may find the following references useful: the classic frame paper: Minsky, M "A Framework for Representing Knowledge", The Psychology of Human Vision, Winston P.H.(ed) McGraw Hill, 1975. a survey of commercial oo/es tools: Tello, E "Object Oriented Programming 4 Artificial Intelligence" Howard W. Sams & Company (i think), 1989, (i think) Brachman's blasphemies: Brachman R.J. "What IS-A Is and Isn't: An Analysis of Taxonomic Links in Semantic Nets" IEEE Computer, October 1983, vol 16, No. 10, pp66-73 Brachman R.J. "I Lied About the Trees", or Defaults and Definitions in Knowledge Representations. The AI Magazine, Fall 1985, pp80-85. my own dissidents view: Menzies T.J. "Why You Shouldn't Respecy Your Parents", Proceedings of AI '90, in preperation. someone using frames for soemthing interesting: Reggia J et al "Diagnostic Expert Systems based on a set covering model", International Journal of Man-Machine Studies, the software engineer's perspective: Meyer B. "Object-oriented Software construction", Prentice-Hall, 1988.
plogan@mentor.com (Patrick Logan) (07/10/90)
In article <1947@runxtsa.runx.oz.au> timm@runxtsa.runx.oz.au (Tim Menzies) writes: > [...] > > [Missing is a list of various ways the typical IS-A inheritance relation has > been used/abused.] > > then, a dramatic chord. nowhere, observes brachman, in that list is > "pass this property" or "block this property". inheritance has no > semantics per se. it can be used to implement (read, muddle up) a > variety of semantic properites. brachman's thesis is that these > semantic properties should eb offerred as seperate building blocks in a > KR tool and not thrown in together in a mess. > > [...] > > this is all blasphemy of course. objects give you a window into the > fundamental truths of the universe. as soon as you buy your copy of your > KEE/Eiffel/ C++/ CLOS/ Smalltalk/ ADS 5.1/ KAPPA/ Egeria/ (etc. etc.) > system, then all your specification problems will disappear and all will > become so clear. The Carnegie Representation Language, part of the Knowledgecraft system from Carnegie Group, has a very flexible facility for defining custom relationships. It is highly declarative, falling back on the underlying CommonLISP if necessary. Relationships and entire classes or individual objects can be refined on the fly. Very powerful for prototyping. I used it for nearly two years and thoroughly enjoyed it. I'd like to use something like it again. It's not a be-all-and-end-all, it just offers a powerful way to implement the domain's concepts. It's still necessary to build supporting objects that are not a part of the actual domain. There's still a long way to go. -- Patrick Logan uunet!mntgfx!plogan | Mentor Graphics Corp. 8500 SW Creekside P | Beaverton, Oregon 97005-7191 |
pepke@gw.scri.fsu.edu (Eric Pepke) (07/12/90)
In article <1947@runxtsa.runx.oz.au> timm@runxtsa.runx.oz.au (Tim Menzies) writes: > but what about default knowledge? surely thats a useful KR trick that needs > a hierarchy of inheriting objects? not so says brachman. with defaults comes > the ability to override defaults. the ability to override defaults effectively > negates any knowledge representation power. if john is-a bachelor and john > can override any or all of the properties of bachelor, then all you can say > about john is that at sometime in the past, john had all the properies of a > bachelor. since then, john could have done anything with his bachelor-ness. > if defaults can be over-ridden, then you can 'tbe sure about any of john's > properties right now. I don't see any real problem with this. I have a bicycle. Bicycles have two wheels. This is one of the most basic properties of bicycles and is the one from which it derives its name. Let's say I forget to lock it up with the chain, only the U-lock, and somebody steals the front wheel. Would smoke come out of my ears if I were to say, "I have a bicycle, but it's front wheel is missing."? Would it be unreasonable to say or think, "I need a new front wheel for my bicycle" rather than "I need a new front wheel for my that-which-is-not-a-bicycle but which, upon addition of a new front wheel, shall become a bicycle."? Would it not make more sense to be able to look at the default that is overridden, see that it is a fundimental property of a bicycle, and be able to conclude thereby that there is something wrong with the bicycle? I don't know whether objects are the best way to represent knowledge, but to conclude that they are useless on the basis of such reductio ad absurdum arguments is silly. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.