engineering design knowledge representation based on logic and objects

7/28/2019 Engineering Design Knowledge Representation Based on Logic and Objects

1/19

Coffee

Cooking TipsRecipes & Food and Drink

Wine & Spirits

Elder Care

Babies & Toddler

Pregnancy

Acne

Aerobics & Cardio

Alternative Medicine

Beauty TipsDepression

Diabetes

Exercise & Fitness

Hair Loss

Medicine

Meditation

Muscle Building & Bodybuilding

Nutrition

Nutritional SupplementsWeight LossYoga

Martial Arts

Finding HappinessInspirational

Breast Cancer

Mesothelioma & Cancer

Fitness Equipment

Nutritional SupplementsWeight Loss

Affiliate Revenue

Blogging, RSS & FeedsDomain Name

E-Book

E-commerce

Email Marketing

Ezine Marketing

Ezine Publishing

Forums & Boards

Internet Marketing

Online Auction

Search Engine OptimizationSpam Blocking

Streaming Audio & Online

Music

Traffic Building

Video Streaming

Web Design

Web Development

Web Hosting

Web Site Promotion

Broadband Internet

VOIP

Computer Hardware

Data Recovery & Backup

Internet Security

Software

Advertising

Branding

Business Management

Business Ethics

Careers, Jobs & Employment

Customer Service

Marketing

Networking

Network Marketing

Pay-Per-Click Advertising

Presentation

Public Relations

Sales

Sales Management

Sales Telemarketing

Sales Training

Small Business

Strategic Planning

Entrepreneur

Negotiation Tips

Team Building

Top Quick Tips

Book Marketing

Leadership

Positive Attitude Tips

Goal Setting

Innovation

Success

Time Management

Public Speaking

Get Organized - Organization

Credit

Currency Trading

Debt Consolidation

Debt Relief

Loan

Insurance

InvestingMortgage Refinance

Personal Finance

Real Estate

TaxesStocks & Mutual Fund

Structured Settlements

Leases & Leasing

Wealth Building

Home Security

Mobile & Cell Phone

Video Conferencing

Satellite TV

Dating

Relationships

Game

Casino & Gambling

Humor & EntertainmentMusic & MP3

Photography

Golf

Attraction

Motorcycle

Fashion & Style

Crafts & Hobbies

Home Improvement

Interior Design & Decorating

Landscaping & Gardening

Pets

Marriage & WeddingHoliday

Fishing

Aviation & Flying

Cruising & Sailing

Outdoors

Vacation Rental

Book Reviews

College & University

Psychology

Science Articles

ReligionPersonal Technology

Humanities

Language

Philosophy

Poetry

Book Reviews

Medicine

Coaching

Creativity

Dealing with Grief & LossMotivation

Spirituality

Stress ManagementArticle Writing

Writing

PoliticalCopywriting

Parenting

Divorce
http://www.findbeststuff.com/showarticles.php?cat=121http://www.findbeststuff.com/showarticles.php?cat=123http://www.findbeststuff.com/showarticles.php?cat=209http://www.findbeststuff.com/showarticles.php?cat=246http://www.findbeststuff.com/showarticles.php?cat=141http://www.findbeststuff.com/showarticles.php?cat=109http://www.findbeststuff.com/showarticles.php?cat=204http://www.findbeststuff.com/showarticles.php?cat=100http://www.findbeststuff.com/showarticles.php?cat=102http://www.findbeststuff.com/showarticles.php?cat=104http://www.findbeststuff.com/showarticles.php?cat=111http://www.findbeststuff.com/showarticles.php?cat=135http://www.findbeststuff.com/showarticles.php?cat=136http://www.findbeststuff.com/showarticles.php?cat=145http://www.findbeststuff.com/showarticles.php?cat=156http://www.findbeststuff.com/showarticles.php?cat=180http://www.findbeststuff.com/showarticles.php?cat=181http://www.findbeststuff.com/showarticles.php?cat=117http://www.findbeststuff.com/showarticles.php?cat=190http://www.findbeststuff.com/showarticles.php?cat=231http://www.findbeststuff.com/showarticles.php?cat=245http://www.findbeststuff.com/showarticles.php?cat=249http://www.findbeststuff.com/showarticles.php?cat=179http://www.findbeststuff.com/showarticles.php?cat=157http://www.findbeststuff.com/showarticles.php?cat=165http://www.findbeststuff.com/showarticles.php?cat=115http://www.findbeststuff.com/showarticles.php?cat=175http://www.findbeststuff.com/showarticles.php?cat=150http://www.findbeststuff.com/showarticles.php?cat=231http://www.findbeststuff.com/showarticles.php?cat=245http://www.findbeststuff.com/showarticles.php?cat=103http://www.findbeststuff.com/showarticles.php?cat=112http://www.findbeststuff.com/showarticles.php?cat=138http://www.findbeststuff.com/showarticles.php?cat=139http://www.findbeststuff.com/showarticles.php?cat=140http://www.findbeststuff.com/showarticles.php?cat=142http://www.findbeststuff.com/showarticles.php?cat=146http://www.findbeststuff.com/showarticles.php?cat=147http://www.findbeststuff.com/showarticles.php?cat=151http://www.findbeststuff.com/showarticles.php?cat=168http://www.findbeststuff.com/showarticles.php?cat=106http://www.findbeststuff.com/showarticles.php?cat=219http://www.findbeststuff.com/showarticles.php?cat=224http://www.findbeststuff.com/showarticles.php?cat=107http://www.findbeststuff.com/showarticles.php?cat=107http://www.findbeststuff.com/showarticles.php?cat=236http://www.findbeststuff.com/showarticles.php?cat=239http://www.findbeststuff.com/showarticles.php?cat=242http://www.findbeststuff.com/showarticles.php?cat=243http://www.findbeststuff.com/showarticles.php?cat=244http://www.findbeststuff.com/showarticles.php?cat=221http://www.findbeststuff.com/showarticles.php?cat=116http://www.findbeststuff.com/showarticles.php?cat=240http://www.findbeststuff.com/showarticles.php?cat=158http://www.findbeststuff.com/showarticles.php?cat=131http://www.findbeststuff.com/showarticles.php?cat=218http://www.findbeststuff.com/showarticles.php?cat=223http://www.findbeststuff.com/showarticles.php?cat=101http://www.findbeststuff.com/showarticles.php?cat=114http://www.findbeststuff.com/showarticles.php?cat=176http://www.findbeststuff.com/showarticles.php?cat=144http://www.findbeststuff.com/showarticles.php?cat=118http://www.findbeststuff.com/showarticles.php?cat=130http://www.findbeststuff.com/showarticles.php?cat=177http://www.findbeststuff.com/showarticles.php?cat=189http://www.findbeststuff.com/showarticles.php?cat=188http://www.findbeststuff.com/showarticles.php?cat=202http://www.findbeststuff.com/showarticles.php?cat=205http://www.findbeststuff.com/showarticles.php?cat=203http://www.findbeststuff.com/showarticles.php?cat=212http://www.findbeststuff.com/showarticles.php?cat=213http://www.findbeststuff.com/showarticles.php?cat=214http://www.findbeststuff.com/showarticles.php?cat=215http://www.findbeststuff.com/showarticles.php?cat=222http://www.findbeststuff.com/showarticles.php?cat=227http://www.findbeststuff.com/showarticles.php?cat=143http://www.findbeststuff.com/showarticles.php?cat=187http://www.findbeststuff.com/showarticles.php?cat=233http://www.findbeststuff.com/showarticles.php?cat=235http://www.findbeststuff.com/showarticles.php?cat=113http://www.findbeststuff.com/showarticles.php?cat=172http://www.findbeststuff.com/showarticles.php?cat=201http://www.findbeststuff.com/showarticles.php?cat=153http://www.findbeststuff.com/showarticles.php?cat=164http://www.findbeststuff.com/showarticles.php?cat=230http://www.findbeststuff.com/showarticles.php?cat=234http://www.findbeststuff.com/showarticles.php?cat=207http://www.findbeststuff.com/showarticles.php?cat=191http://www.findbeststuff.com/showarticles.php?cat=127http://www.findbeststuff.com/showarticles.php?cat=129http://www.findbeststuff.com/showarticles.php?cat=133http://www.findbeststuff.com/showarticles.php?cat=134http://www.findbeststuff.com/showarticles.php?cat=174http://www.findbeststuff.com/showarticles.php?cat=166http://www.findbeststuff.com/showarticles.php?cat=169http://www.findbeststuff.com/showarticles.php?cat=183http://www.findbeststuff.com/showarticles.php?cat=194http://www.findbeststuff.com/showarticles.php?cat=208http://www.findbeststuff.com/showarticles.php?cat=232http://www.findbeststuff.com/showarticles.php?cat=226http://www.findbeststuff.com/showarticles.php?cat=229http://www.findbeststuff.com/showarticles.php?cat=173http://www.findbeststuff.com/showarticles.php?cat=241http://www.findbeststuff.com/showarticles.php?cat=161http://www.findbeststuff.com/showarticles.php?cat=182http://www.findbeststuff.com/showarticles.php?cat=238http://www.findbeststuff.com/showarticles.php?cat=216http://www.findbeststuff.com/showarticles.php?cat=132http://www.findbeststuff.com/showarticles.php?cat=210http://www.findbeststuff.com/showarticles.php?cat=152http://www.findbeststuff.com/showarticles.php?cat=119http://www.findbeststuff.com/showarticles.php?cat=163http://www.findbeststuff.com/showarticles.php?cat=186http://www.findbeststuff.com/showarticles.php?cat=198http://www.findbeststuff.com/showarticles.php?cat=212http://www.findbeststuff.com/showarticles.php?cat=105http://www.findbeststuff.com/showarticles.php?cat=185http://www.findbeststuff.com/showarticles.php?cat=148http://www.findbeststuff.com/showarticles.php?cat=125http://www.findbeststuff.com/showarticles.php?cat=160http://www.findbeststuff.com/showarticles.php?cat=167http://www.findbeststuff.com/showarticles.php?cat=170http://www.findbeststuff.com/showarticles.php?cat=196http://www.findbeststuff.com/showarticles.php?cat=178http://www.findbeststuff.com/showarticles.php?cat=159http://www.findbeststuff.com/showarticles.php?cat=149http://www.findbeststuff.com/showarticles.php?cat=108http://www.findbeststuff.com/showarticles.php?cat=128http://www.findbeststuff.com/showarticles.php?cat=192http://www.findbeststuff.com/showarticles.php?cat=237http://www.findbeststuff.com/showarticles.php?cat=110http://www.findbeststuff.com/showarticles.php?cat=122http://www.findbeststuff.com/showarticles.php?cat=206http://www.findbeststuff.com/showarticles.php?cat=217http://www.findbeststuff.com/showarticles.php?cat=211http://www.findbeststuff.com/showarticles.php?cat=195http://www.findbeststuff.com/showarticles.php?cat=162http://www.findbeststuff.com/showarticles.php?cat=171http://www.findbeststuff.com/showarticles.php?cat=197http://www.findbeststuff.com/showarticles.php?cat=199http://www.findbeststuff.com/showarticles.php?cat=110http://www.findbeststuff.com/showarticles.php?cat=180http://www.findbeststuff.com/showarticles.php?cat=120http://www.findbeststuff.com/showarticles.php?cat=126http://www.findbeststuff.com/showarticles.php?cat=155http://www.findbeststuff.com/showarticles.php?cat=184http://www.findbeststuff.com/showarticles.php?cat=225http://www.findbeststuff.com/showarticles.php?cat=228http://www.findbeststuff.com/showarticles.php?cat=248http://www.findbeststuff.com/showarticles.php?cat=247http://www.findbeststuff.com/showarticles.php?cat=200http://www.findbeststuff.com/showarticles.php?cat=124http://www.findbeststuff.com/showarticles.php?cat=193http://www.findbeststuff.com/showarticles.php?cat=137http://www.findbeststuff.com/showarticles.php?cat=137http://www.findbeststuff.com/showarticles.php?cat=193http://www.findbeststuff.com/showarticles.php?cat=124http://www.findbeststuff.com/showarticles.php?cat=200http://www.findbeststuff.com/showarticles.php?cat=247http://www.findbeststuff.com/showarticles.php?cat=248http://www.findbeststuff.com/showarticles.php?cat=228http://www.findbeststuff.com/showarticles.php?cat=225http://www.findbeststuff.com/showarticles.php?cat=184http://www.findbeststuff.com/showarticles.php?cat=155http://www.findbeststuff.com/showarticles.php?cat=126http://www.findbeststuff.com/showarticles.php?cat=120http://www.findbeststuff.com/showarticles.php?cat=180http://www.findbeststuff.com/showarticles.php?cat=110http://www.findbeststuff.com/showarticles.php?cat=199http://www.findbeststuff.com/showarticles.php?cat=197http://www.findbeststuff.com/showarticles.php?cat=171http://www.findbeststuff.com/showarticles.php?cat=162http://www.findbeststuff.com/showarticles.php?cat=195http://www.findbeststuff.com/showarticles.php?cat=211http://www.findbeststuff.com/showarticles.php?cat=217http://www.findbeststuff.com/showarticles.php?cat=206http://www.findbeststuff.com/showarticles.php?cat=122http://www.findbeststuff.com/showarticles.php?cat=110http://agoga.com/search.php?xargs=&terms=Educationhttp://www.findbeststuff.com/showarticles.php?cat=237http://www.findbeststuff.com/showarticles.php?cat=192http://www.findbeststuff.com/showarticles.php?cat=128http://www.findbeststuff.com/showarticles.php?cat=108http://www.findbeststuff.com/showarticles.php?cat=149http://www.findbeststuff.com/showarticles.php?cat=159http://www.findbeststuff.com/showarticles.php?cat=178http://www.findbeststuff.com/showarticles.php?cat=196http://www.findbeststuff.com/showarticles.php?cat=170http://www.findbeststuff.com/showarticles.php?cat=167http://www.findbeststuff.com/showarticles.php?cat=160http://www.findbeststuff.com/showarticles.php?cat=125http://www.findbeststuff.com/showarticles.php?cat=148http://www.findbeststuff.com/showarticles.php?cat=185http://www.findbeststuff.com/showarticles.php?cat=105http://www.findbeststuff.com/showarticles.php?cat=212http://www.findbeststuff.com/showarticles.php?cat=198http://www.findbeststuff.com/showarticles.php?cat=186http://www.findbeststuff.com/showarticles.php?cat=163http://www.findbeststuff.com/showarticles.php?cat=119http://www.findbeststuff.com/showarticles.php?cat=152http://www.findbeststuff.com/showarticles.php?cat=210http://www.findbeststuff.com/showarticles.php?cat=132http://www.findbeststuff.com/showarticles.php?cat=216http://www.findbeststuff.com/showarticles.php?cat=238http://www.findbeststuff.com/showarticles.php?cat=182http://agoga.com/search.php?xargs=&terms=Entertainmenthttp://www.findbeststuff.com/showarticles.php?cat=161http://www.findbeststuff.com/showarticles.php?cat=241http://www.findbeststuff.com/showarticles.php?cat=173http://www.findbeststuff.com/showarticles.php?cat=229http://www.findbeststuff.com/showarticles.php?cat=226http://www.findbeststuff.com/showarticles.php?cat=232http://www.findbeststuff.com/showarticles.php?cat=208http://www.findbeststuff.com/showarticles.php?cat=194http://www.findbeststuff.com/showarticles.php?cat=183http://www.findbeststuff.com/showarticles.php?cat=169http://www.findbeststuff.com/showarticles.php?cat=166http://www.findbeststuff.com/showarticles.php?cat=174http://www.findbeststuff.com/showarticles.php?cat=134http://www.findbeststuff.com/showarticles.php?cat=133http://www.findbeststuff.com/showarticles.php?cat=129http://www.findbeststuff.com/showarticles.php?cat=127http://agoga.com/search.php?xargs=&terms=Financeshttp://www.findbeststuff.com/showarticles.php?cat=191http://www.findbeststuff.com/showarticles.php?cat=207http://www.findbeststuff.com/showarticles.php?cat=234http://www.findbeststuff.com/showarticles.php?cat=230http://www.findbeststuff.com/showarticles.php?cat=164http://www.findbeststuff.com/showarticles.php?cat=153http://www.findbeststuff.com/showarticles.php?cat=201http://www.findbeststuff.com/showarticles.php?cat=172http://www.findbeststuff.com/showarticles.php?cat=113http://www.findbeststuff.com/showarticles.php?cat=235http://www.findbeststuff.com/showarticles.php?cat=233http://www.findbeststuff.com/showarticles.php?cat=187http://www.findbeststuff.com/showarticles.php?cat=143http://www.findbeststuff.com/showarticles.php?cat=227http://www.findbeststuff.com/showarticles.php?cat=222http://www.findbeststuff.com/showarticles.php?cat=215http://www.findbeststuff.com/showarticles.php?cat=214http://www.findbeststuff.com/showarticles.php?cat=213http://www.findbeststuff.com/showarticles.php?cat=212http://www.findbeststuff.com/showarticles.php?cat=203http://www.findbeststuff.com/showarticles.php?cat=205http://www.findbeststuff.com/showarticles.php?cat=202http://www.findbeststuff.com/showarticles.php?cat=188http://www.findbeststuff.com/showarticles.php?cat=189http://www.findbeststuff.com/showarticles.php?cat=177http://www.findbeststuff.com/showarticles.php?cat=130http://www.findbeststuff.com/showarticles.php?cat=118http://www.findbeststuff.com/showarticles.php?cat=144http://www.findbeststuff.com/showarticles.php?cat=176http://www.findbeststuff.com/showarticles.php?cat=114http://www.findbeststuff.com/showarticles.php?cat=101http://agoga.com/search.php?xargs=&terms=Businesshttp://www.findbeststuff.com/showarticles.php?cat=223http://www.findbeststuff.com/showarticles.php?cat=218http://www.findbeststuff.com/showarticles.php?cat=131http://www.findbeststuff.com/showarticles.php?cat=158http://www.findbeststuff.com/showarticles.php?cat=240http://www.findbeststuff.com/showarticles.php?cat=116http://www.findbeststuff.com/showarticles.php?cat=221http://www.findbeststuff.com/showarticles.php?cat=244http://www.findbeststuff.com/showarticles.php?cat=243http://www.findbeststuff.com/showarticles.php?cat=242http://www.findbeststuff.com/showarticles.php?cat=239http://www.findbeststuff.com/showarticles.php?cat=236http://www.findbeststuff.com/showarticles.php?cat=107http://www.findbeststuff.com/showarticles.php?cat=107http://www.findbeststuff.com/showarticles.php?cat=224http://www.findbeststuff.com/showarticles.php?cat=219http://www.findbeststuff.com/showarticles.php?cat=106http://www.findbeststuff.com/showarticles.php?cat=168http://www.findbeststuff.com/showarticles.php?cat=151http://www.findbeststuff.com/showarticles.php?cat=147http://www.findbeststuff.com/showarticles.php?cat=146http://www.findbeststuff.com/showarticles.php?cat=142http://www.findbeststuff.com/showarticles.php?cat=140http://www.findbeststuff.com/showarticles.php?cat=139http://www.findbeststuff.com/showarticles.php?cat=138http://www.findbeststuff.com/showarticles.php?cat=112http://www.findbeststuff.com/showarticles.php?cat=103http://agoga.com/search.php?xargs=&terms=Internethttp://www.findbeststuff.com/showarticles.php?cat=245http://www.findbeststuff.com/showarticles.php?cat=231http://www.findbeststuff.com/showarticles.php?cat=150http://www.findbeststuff.com/showarticles.php?cat=175http://www.findbeststuff.com/showarticles.php?cat=115http://www.findbeststuff.com/showarticles.php?cat=165http://www.findbeststuff.com/showarticles.php?cat=157http://www.findbeststuff.com/showarticles.php?cat=179http://www.findbeststuff.com/showarticles.php?cat=249http://www.findbeststuff.com/showarticles.php?cat=245http://www.findbeststuff.com/showarticles.php?cat=231http://www.findbeststuff.com/showarticles.php?cat=190http://www.findbeststuff.com/showarticles.php?cat=117http://www.findbeststuff.com/showarticles.php?cat=181http://www.findbeststuff.com/showarticles.php?cat=180http://www.findbeststuff.com/showarticles.php?cat=156http://www.findbeststuff.com/showarticles.php?cat=145http://www.findbeststuff.com/showarticles.php?cat=136http://www.findbeststuff.com/showarticles.php?cat=135http://www.findbeststuff.com/showarticles.php?cat=111http://www.findbeststuff.com/showarticles.php?cat=104http://www.findbeststuff.com/showarticles.php?cat=102http://www.findbeststuff.com/showarticles.php?cat=100http://www.findbeststuff.com/showarticles.php?cat=204http://www.findbeststuff.com/showarticles.php?cat=109http://www.findbeststuff.com/showarticles.php?cat=141http://www.findbeststuff.com/showarticles.php?cat=246http://www.findbeststuff.com/showarticles.php?cat=209http://www.findbeststuff.com/showarticles.php?cat=123http://www.findbeststuff.com/showarticles.php?cat=121http://agoga.com/search.php?xargs=&terms=Health


2/19

Compurers & StrucruresVol. 63, No. 5, pp. 1015-1032, 19970 1997ElscxierSciena Ltd. All tights reservedPrinted n Great BritainPII: sow-7949(%)00247-7 0045-7949197 l7.Otl-k 0.00

COMPENDIUMENGINEERING DESIGN KNOWLEDGE REPRESENTATION

BASED ON LOGIC AND OBJECTSJ. Bento,t$ B. Feij&@ and D. L. Smitht

t Department of Civil Engineering, Instituto Superior TQnico, Technical University of Lisbon, Av.Rovisco Pais, 1096 Lisboa Codex, Portugal$ Expert Systems Laboratory, Imperial College of Science, Technology and Medicine, University ofLondon, Imperial College Road, London SW3 2BU, U.K.5 ICAD-Intelligent CAD Laboratory, Department of Computer Science, Pontificia UniversidadeCatblica do Rio de Janeiro, Rua Marques de S%o Vicente, 225, CEP 22453, Rio de Janeiro, RJ, Brazil(Recei ved 4 M arch 1994)

Abstract-This paper presents a hybrid framework to integrate first-order logic into the object-orientedparadigm for representing engineering design knowledge. The object-oriented nature of engineering designactivities are analysed and details of the programming environment are provided. 0 1997 Elsevier ScienceLtd.

1. INTRODUCIIONThe hierarchical o:rganization of structural engin-eering objects is inherent to the structural engineeringdesign activity. The following object-oriented con-cepts can be found in this kind of activity: (a) theaggregation of structural engineering objects fromother structural engineering objects, i.e. some objectshave parts which are themselves other objects-aframed-building has a roof, a system of foundations,walls, etc.; (b) the zsharing of properties amongst anumber of similar objects defining classes ofobjects-all framed-buildings have a number ofcommon properties; and (c) the inheritance ofproperties from more abstract objects to moreconcrete ones (e.g. a framed building is a building,that is it inherits all typical building properties).In the context of proposing a framework forbuilding ICAD (intelligent CAD) systems in struc-tural steel design, the present paper proposes aknowledge representation scheme and a program-ming environment capable of addressing the object-oriented aspects above mentioned. The programmingenvironment incorporates first-order logic into theobject-oriented paradigm.The main motivation of the present work is relatedto the fact that a previous and strict commitment tologic as a programming paradigm, and especially asa knowledge repressentation formalism in a designenvironment [11, has revealed some deficiencies,namely when the explicit representation of designobjects is under consideration. Furthermore, it beingthoroughly accepted1 that first-order logic providesthe most robust and efficient model of deductivethought, it is then indisputable that logical deduction

merely covers one aspect (possibly not evenpredominant) of human thought. Reference [2], whilediscoursing about the appropriateness of first-orderlogic for representing design models, stresses thatembracing different aspects of cognitive emulation isa vital nexus to reality and suggests the use of framesin addition to logic. In fact, it is widely accepted, evenby strong defendants of logic programming [3], thatsome features present in object-oriented program-ming systems, which are of interest to designknowledge representation, are lacking in logicprogramming languages.Most man-made artifacts are fully or partially of ahierarchical nature (frequently induced by a bottom-up construction process), and many types of designautomation applications require a data structurewhich is naturally related with real world objects.This argument is especially important in the presenceof CAD systems for architectural, civil or mechanicalengineering design, in which geometric modelling iseither a main concern or an essential requirement.Furthermore, as previously identified [4], features ofobject-oriented languages seem to be of value forrepresenting design characteristics in a formal modelof the design process.

Still in a (structural) design context, other writersseem to have identified a need for object-orientedfeatures to be present in design automation systems.Notably Refs [3] or [5] refer to its use as a vehicle forthe inclusion of geometric reasoning features inICAD systems by incorporating and integratingexisting software; a more in-depth treatment is givenby Refs [6] and [7] in the solutions they explore forassimiliating geometric reasoning capabilities into

1015
http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/http://www.findbeststuff.com/


3/19

1016 CompendiumCAD systems. Garrett [8] also explores the use ofobject-oriented programming in production systemas a means to achieve better rule-based inferencemechanisms, and the same paradigm is used indeveloping a data structure which is able to be usedby different participants in the design of buildings(e.g. agents related with architectural design,structural design, HVAC design, etc.) [9]. Finally,references are due to the PBASE proposal [lo] andthe IDDL concept by the group Bart Veth [l 11,whichseek to promote the integration of object-orientedcharacteristics with predicate logic; they have thespecific aim of creating a better representationallanguage for knowledge about entities, attributes ofentities and relationships between entities, all presentin design processes.

2. KNOWLEDGE ABOUT DESIGN OBJECTSIn the design process, one often needs to refer toentities characterized by having both physical and

functional attributes, as well as to relationshipsamong those entities, e.g. structural elements, in astructural design process. The basic notationaldilemma in describing those entities and relationsconsists in whether to use an extensional or anintensional description [121. If extensionally describ-ing the properties of a beam, say B 1, one could usethe following representation, borrowing a notationalconvention from predicate calculus:beam (Bl)span (BL L)height (Bl H)width (Bl W)material (Bl steel)left-node (Bl N)right-node (Bl M)node (N)node (M) (1)If a column entity, say Cl, were to be similarlydefined, one could express extensionally an adjacencyrelationship as follows:next-to (Bl Cl) (2)If, conversely, an intensional description were to beadopted, beams could be represented by means of asingle assertion,beam (name span heightwidth materialleft-node right-node).which, for the case of Bl, would lead to

(3)

beam (Bl L H W steel N M). (4)

The relation (2) would then become, if describedintensionally,relation (Bl next-to Cl). (5)Extensional descriptions involve a larger number ofsimpler assertions. In the given example (I), a totalof nine assertions making use of as many as eightrelations were used to describe the properties of beamBl; a single relation (4) would be enough to describethe very same piece of knowledge if use were to bemade of an intensional description method. Never-theless, the extra amount of wording of extensionaldescriptions facilitates an extremely easy procedurefor modifying the properties of entities described inthat way: adding or deleting properties is just amatter of asserting or retracting facts.

Another positive facet of extensional descriptions,in the context of design knowledge bases, is thatdifferent views of the same design entity may be easilydefined by picking only those facts which are ofrelevance for the view in question (e.g. a beam maybe viewed from a structural analysis perspective orfrom that of quantity surveying, situations in whichdifferent properties are used to describe the sameentity). Contrarily, in the case where an intensionaldescription has been used, adding the cross_sectionproperty requires the complete redefinition of thebeam predicate already defined by eqn (4). Further-more, providing support for multiple views on thebasis of intensional descriptions of knowledgerequires the development of a totally different andalternative scheme. Nevertheless, is important tostress that the higher flexibility of extensionalrepresentations also bears a performance drawback:a larger number of assertions have to be processed.The same set of reasons explains why the lowerflexibility of intensional representations may becompensated by a much better retrieval and greatercomputational efficiency.

The authors share the opinion expressed by thegroup Bart Veth [l l] that logic programming, aformalism extremely well adapted to representingknowledge extensionally, is a preferable tool fordescribing and manipulating that kind of designknowledge which is expected to be subjected tofrequent changes throughout the design process. Forthe same reasons, objects may be used to describethose other pieces of knowledge whose structure isless likely to change in the course of the designprocess, but which may be subjected to changes at anattribute value level, e.g. in a structural designcontext, structural elements, whose components andproperties in general are fixed, but have variablevalues.The flexibility-performance issues raised about thetwo above-mentioned representation schemes may beseen as a notation problem with consequences at aknowledge representation level. It has also been aconcern of other authors; for example, Charniack


4/19

Compendium 1017and McDermott [131 adopt a similar approach whendescribing what they call a slot-assertion notation(extensional) vs an alternative frame or slot-and-fillerone (intensional). Again, they claim that framenotations are better (while more efficient) if newpieces of information are not intended to be added orremoved very often. In the specific context of logicprogramming, McCabe [3] also identifies two comp-lementary ways of representing data: by usingassertions (the assertional or database view) and byusing terms (an alternative for dealing with morestructured and homogeneous types of information).

One may be tempted to agree with those who arguethat the use of lasgic is best suited to organizingknowledge which varies with the evolution of thedesign process, whereas objects are best for those lessflexible entities present in modelling design processesand design objects Ill]. However, it must follow thathybrid solutions are also possible, and probablybetter, in situations where the above separation is notsufficiently clear. In agreement with that, the authorspropose a scheme where flexibility and performanceare combined to form what is judged to be a betterbalanced situation, by employing, in a hybridenvironment, pred:icate logic and objects with avariable structure, i e. whose modification-addition,deletion or alteration of properties--does not implya full redefinition.

Making use of the proposed framework, differententities may be represented by using objects, logic orboth, whichever shows most appropriateness.

3. OBJECT-ORIENTED REPRESENTATIONS3.1. Basic characteristics

A simple definition of objects may involve anabstract data structure in which data and proceduresabout the entities being modelled are kept together.

There are three ksey characteristics inherent in anyobject-oriented programming environment:

l he ability to (define prototypes or classes ofobjects which have to include their own data(values of attributes) and methods;

l he ability to create different objects via acomparative method-instances of predefinedclasses created by specialization of thoseclasses-and of accessing data and methods fromthem;

l he ability for sub-classes to inherit data andmethods from ancestor classes, extending orrestricting them locally.

Figure 1 shows an object that represents theconcept of a cross section. In this example, the areais not explicitly stored as a static attribute value andmay be computed from other attribute values. Objectproperties which involve computations are generallyreferred to as methods. In this context, the property

/L objects name% parent objects name

I indicate objects properties

Fig. 1. Representation of a cross secrion object.

area may be defined as a function having the widthand the depth as arguments: area(width,depth)=width x depth. A typical feature of most object-ori-ented programming environments is data abstraction.Data abstraction, or information hiding, is achievedby forbidding external entities to access directly (oreven know) the internal structure of an object, i.e. theaccess to the internal data of an object presumes theinvocation of its methods. Moreover, the invocationof a method should not presuppose any furtherknowledge about the details of its internal implemen-tation. In this context, the set of properties that doesnot belong to the internal structure of an object iscalled the public part.

Another key characteristic present in object-ori-ented programming environments relies on thepossibility of creating different objects as instances ofpredefined classes and of accessing those classes dataand methods. Furthermore, those instances tiay bespecialized by addition of new properties or byoverriding existing ones (modifying or removingthem). Hence, developing object-oriented appli-cations should start by the definition of generalclasses-containing attributes, attribute values andmethods common to a number of objects-fromwhich such objects may be instantiated andspecialized. Figure 2 illustrates an Z_larninated_sec-tion prototype/class, as well as an object derived fromit: 1PE_550.

Subclasses are defined when derived objectsthemselves contain properties (static attributes andmethods) which are common to a number of otherobjects. Such an approach allows for the establish-ment of a hierarchy of classes and subclasses, i.e. a

(a) (b)Fig. 2. (a) Class-as-prototype; (b) derived object.


5/19

1018IWliW

parents nameJ,

Valueattributes

methodsLFig. 3. Property inheritance between two objects.

child is derived from its ancestor classes. TheI_luminated_section object of Fig. 2a, from whichIPE_550 is derived, constitutes an example of asubclass of the cross_secti on class depicted earlier inFig. 1.

One of the most relevant consequences ofstructuring knowledge using objects is that it leads toa great economy of expression, avoiding redundancyof explicit information, by the use of inheritance asa mechanism for information elision. Accordingly,child classes, as well as derived (child) objects, inheritproperties from their ancestors, in terms of attributes,attribute values or methods, with some possible localupdating (through addition or modification). Differ-ent kinds of inheritance may be propagatedindependently, such as attribute values, propertiesand methods (Fig. 3).Another interesting feature about inheritance isthat it stands as a vehicle for finding information,even when it is not in the place where information isfirst looked for [14]. Also, inheritance forms animportant vehicle for providing, if not a defaultreasoning mechanism then at least for the use ofdefault values.3.2. M ult i p le inh er i tance

A situation of multiple inheritance is found whenan object is derived from more than one directancestor. The economy of expression arising fromelision through inheritance and consequently sharing

(a)

of descriptions between classes, is clearly increased byproviding multiple inheritance.While inheritance of properties from a single directancestor (parent) defines a class hierarchy representedby a tree, multiple inheritance, as exemplified above,establishes a class hierarchy representable by a moregeneral graph structure, usually a directed acyclicgraph (Fig. 4 may be used for comparing both). Thiskind of class hierarchy may exhibit an importantexpressive power, namely in situations where thedescribing of objects with a component-subcompo-nent structure is at issue (such as in geometricmodelling or structural design knowledge represen-tation, for example).However, multiple inheritance poses some prob-lems, especially at the implementation level. The mostrelevant problem concerns decision criteria fordealing with an objects attribute when that attributehas not been locally defined (explicitly within theobject), but more than one attribute with the samename may have been inherited from different parents.

Different implementations have followed fromdifferent methodologies for facing multiple inheri-tance. In some systems, the multiple occurrence ofhomonymous attributes in different ancestors of anobject prevents the possibility of (multiple) inheri-tance at all [14]; some systems assume that no singlecriterion for multiple inheritance may reasonably beapplied in every situation, imposing therefore that,whenever a multiple inheritance conflict emerges, the

(b)Fig. 4. (a) Directed acyclic graph of structural components; (b) equivalent tree representation


6/19

Compendium 1019user must explicitly identify which attribute to use orwhich method to apply [15, 161; some systems havepredefined ancestry graph search criteria which, inthe case of the competitive occurrence of inheritableattributes or methods, leads to the choice of the firstfound by the search procedure [17, 181. Usually thesearch is then related to the order of declaration ofthe ancestors.

Approaches to multiple inheritance which are notassociated with the establishment of an inheritanceprecedence relation, such as in the case of logicprogramming languages, are said to lead to lesssevere situations when this problem arises; this is dueto the fact that, in logic programming, backtrackingtakes care of searching for all possible methods andselecting the appropriate ones [3]. In fact, the authorssustain that also in a logic programming language,the order of declaration of the ancestors, or at leastthe order in which the ancestors and their attributesand methods are ar,serted, is relevant for this matter:they are caught by the backtracking process in thatvery same order. Zaniolo [19] seems to corroboratethis opinion in his introductory work.

The developer of object-oriented knowledge-basedsystems, which rely on multiple inheritance capabili-ties, has to carefully address this problem, asunpleasant results may occur due to unexpectedconsequences resulting from unpredictable inheri-tance. Some authors even argue that it is oftenpreferable to restrict inheritance to a singlesource [3, 141.

Nevertheless, most situations in which multipleinheritance seems an essential feature are indeedavoidable. In general, directed acyclic graph (DAG)structures may be alternatively associated withsimpler ones such as trees. Foley et al. [20] addressthis problem with describing a part-of hierarchy ofrobot components in which a DAG is replaced by atree by actually multiplying the objects with multipleoccurrences. This solution, being safer, may also besaid to be less elegant; moreover it leads to aduplication of information. In the example of Fig. 4,not only does an extra class need to be defined for thelatter case, but also it will contain unnecessarilyduplicated explicit information, such as the u l t i -mate_plastic_momerrt, axial-capacity and Eu-lers_crit ical_Ioad attributes or methods, which maybe already present in either beam or column classes.3.3. inherit ance ow rri ding (except i ons)

Inheritance overriding is an essential ability ofobject-oriented envi:ronments which aim to representexceptions (as well as defaults) in a natural manner.A trival though paradigmatic example of this kindof situation is the ostrich (penguin, chicken, etc.tbirdproblem. It is an acceptable common-sense notionthat birds fly besides having feathers, beak, and so on;hence it would seem advisable to include the attributeof flight property in ,a class definition for representingbirds. However, ostriches are also birds, despite their

Fig. 5. Birds and ostriches: inheritance overriding.

not being able to fly. An exception handlingmechanism then becomes a required feature so thatin looking up the properties of ostriches, a wrongconclusion may not be reached about their flyingproperties, as a consequence of the local absence ofa flying attribute, followed by inheritance from thebird class (Fig. 5). Some approaches to object-ori-ented logic programming have not been able to copeelegantly with the inheritance overriding problem;OBLOG is such an example [21]. However, repeatingwhat has been argued for the case of multipleinheritance, languages which are not prepared tohandle inheritance overriding may simply avoid it;that can be achieved by designing alternativetaxonomies of classes and objects for the domain ofknowledge in question. Typical of such situations isthe ostrich-bird example: birds may be divided intotwo sub-classes-flying-birds and non-flying ones,inheriting properties other than flying from acommon superclass.

Zaniolo has also chosen a birds example in hisintroductory work to object-oriented programmingin Prolog. Curiously, despite the capability fordealing with inheritance overriding shown by hisproposal, he advocates that emphasis in tackling thiskind of situation should be placed around thedatabase organization, an opinion which the authorsentirely endorse.3.4. M essage passing

For an external entity, such as an object or aninteractive user, to communicate with another objectit is necessary to send it a message. Messages must beunderstandable to the recipient object, which selectsan appropriate method, if any, to answer it. Objectsmay communicate among each other only by thesending of messages.

A simple example of a message is a retrievalcommand which returns the value of an objects staticattribute.

(depth of section_Sl (x) ) ? (6)which assumes the existence of a depth property inthe object sectionS1; such a property being a staticvalue, the interpretation of the message correspondsto returning the value of the sections depth throughthe variable x.

In the more general case that the objects propertyreferred to by the message is a method, the recipient


7/19

1020 Compendiumobject responds by performing the procedure itdefines; such a response may result in the sending ofmessages to other subjects.Computation achieved by means of such aninter-object message-passing mechanism, is usuallyclassified as event-driven. Thus object-orientedprogramming emerges as an ideal programmingparadigm to cope with discrete event simulation. Asnoticed by Garrett [8] such an event-driven nature isdifficult to achieve in a monotonic pure rule-basedenvironment. Furthermore, it is interesting to observethat enriching a traditional procedural language withobject-oriented characteristics introduces some newinference capabilities through inheritance and value-class cardinality checking. In that sense, the presentwork is concerned with increasing the expressive andinferential power of logic through those capabilities.

4. A HYBRID APPROACH TO LOGIC AND OBJECTS

The present work follows an approach aiming atincorporating object-oriented capabilities into anenvironment based on logic and suitable forrepresenting engineering design knowledge. Althoughradically different, this approach is in its principlesaligned with the kernel idea of Gordons OBLOGproposal: to combine the frame [22] and logicparadigms in order to achieve an even higher orderof abstraction in knowledge representation. Contrar-ily, there is no special commitment to preserving fullythe semantics of logic. This attitude is based on thepragmatic assumption that the extra care required informalizing and using knowledge by means ofextra-logical methods may be compensated by theimproved efficiency of real object-oriented capabili-ties, e.g. inheritance built into the objects structurevs inheritance obtained through logical deduction.

With respect to general guidelines, the presentwork also draws on the less formal proposal ofParsaye and Chignell[14]: to develop a systemcapable of taking advantage of the robustness andnatural deductive properties of logic, extending itwith the packaging and built-in inheritance capabili-ties of objects.

The proposed approach was built upon XLOG, anenvironment for programming in logic and forbuilding expert systems [1,2,23]. The resultingextended environment, enriched with object-orientedcapabilities, will be referred to hereinafter atXLOG + .Objects and first-order logic clauses (non-Hornclauses) coexist in XLOG + . In other words, logicalsentences in XLOG programs may include referencesto XLOG + objects and vice versa. Figure 6 attemptsto depict the somewhat independent and yetcooperative presence of first-order logic clauses andobjects in the XLOG + hybrid environment: anobjects database may be defined in an imaginaryorthogonal plane to that of the clauses database; linksoccurring at the level of issued messages are then

established between the two components, wheneverrequired.

5. THE STRUCTURE OF AN XLOG + OBJECTAn XLOG + object may be recursively defined asbeing an entity identified by a name, having or not anumber of parent objects and containing or not a

coherent set of properties defined as attributes(explicit ones if locally described, or implicit ones ifinherited); attributes may possibly have a value andtwo special kinds of annotations called attachedpredicates, eqn (7). The syntax is the following:{name (parenti, arentj,_){attributet(value), (if-needed),(if-changed)]

I, i-1I (7)For instance, a roof_beam_Abject may be describedby the following expression:1 roof-beam-A {beam, columns{material[(steel,)l},flength(9.Um)l),c-1,iweightfl 1

I (8)Attributes may be described as having a meaningsimilar to that of slots in the frame theory. As

repeatedly mentioned above, they denote objectproperties. Properties may be formally defined as anassociation of an attribute with an attribute value,and attributes are, in turn, any characteristic(frequently of a physical nature) to which a value maybe assigned, thus defining its state.

In conformance with the aforementioned, at-tributes, as defined in XLOG + objects, shouldalways have a name and a value, their main purposebeing to store data. In XLOG + , in addition toworking as containers of data, attributes may alsohave attached to them a specific type of annotationwhich appears in the form of predicate namesreferring to so called attached procedures. The mainpurposes of those procedures are: (1) to behave asfunctions (methods, in object-oriented terminology);and (2) to define constraints affecting assignment orretrieval of attribute values.In XLOG + , attribute values may be assigned tocharacter strings, as well as to integer or realnumbers. For simple examples of attribute values, seeFig. 3. A kind of attribute value which has a deepersignificance in XLOG + is a string denoting thename of another object. Attribute values carrying thisspecial meaning are called, in XLOG + , objectreferences. They are used in order to indicate that a


8/19

1021


9/19

1022 Compendiumparticular attribute of an object is itself anotherobject; in other words, it stands as a means toestablish part-of relationships and to build compositeobjects (Section 10).Within XLOG + , because objects are consideredas embedded in a general logic programmingenvironment, attached procedures are invoked bymeans of attached logic predicates. For that reason,they can be understood as a logic interpretation of themeaning of an attribute [21]. Moreover, due to theextra-logical nature of XLOG, in which a hybridlogic/procedural programming environment is avail-able through the use of built-in predicates, compu-tation with attached procedures may also be achievedby means of procedures in imperative programminglanguages such as C [24].

methods, or through specialization from ancestorobjects (prototypes/classes). In the latter situation,explicit declaration of attributes, attribute values orattached predicates is only required for objectproperties which extend or override properties oftheir ancestors.

Property annotation by means of attachedpredicates is used for the purpose of triggeringprocedures on variable access, drawing on the style ofactive values and access-oriented programmingtechniques [l&25].

As for the common set of properties between aderived object (or class) and its ancestors, they areautomatically associated with the object at creation.However, such automatic inheritance behaviour doesnot imply that objects created through specializationof ancestor classes do actually possess the same localattributes, with values and attached predicates,redundantly multiplying the amount of explicitinformation and storage space required. In fact, theinternal structure of XLOG + objects avoids theexplicit storage of inherited properties. This charac-teristic is not common to other systems for which, asin XLOG + , real classes are not defined [27].

6. INHERITANCE IN XLOG +Two special types of predicates may be attached toattributes of an XLOG + object: if-needed andif-changed. The obvious meaning of each declarationis linked with the firing timing for its evaluation-ex-ecution. In a manner similar to that of frame basedprogramming environments, if-needed predicates aredeclared to be evaluated before an attribute values istentatively retrieved. Oppositely, if-changed predi-cates are defined as goals to be proved in the case ofan attribute value being tentatively changed-oncemore, before assertion of the attribute value takesplace. The latter play a role identical to OBLOG andIDDL constrains [21,26]; they behave like watch-dogs of the attributes to which they are attached.

In the case of XLOG + , inheritance has to coverattributes names, values and attached predicates(and, through them, methods).In the conceived environment, inheritance ofproperties is automatically achieved by means of theobjects internal structure and, therefore, is notrequired to be explicitly declared (i.e. programmed).As a consequence, the declaration of an object as aderivation of its ancestor(s)-implicitly defining anis-a relationship--automatically ensures inheritanceof their properties.

The use of attached predicates is also of utmostrelevance for the implementation of methods inXLOG + , as fully described in Section 8.

In XLOG + , there is no clear distinction betweenclasses and objects; it is then unnecessary to define thelatter as instances of the former. The term classshould be rather understood in the context ofXLOG + as prototype, i.e. every object in XLOG +may be interpreted as a typical member of theabstract class it represents.

The algorithm implementing the built-in inheri-tance of XLOG + objects may be generallydescribed by means of a simple example. When aretrieval operation is attempted from an objectsattribute (i.e. if a retrieving message is issued, thusfiring a retrieval method) the following proceduredevelops:

The closest an XLOG + prototype object cancome to providing a typical class definition is whenit serves to define an aggregation of properties-at-tributes and methods-for which no values have beenassociated with. The I_laminated_section of Fig. 2illustrates an example of such a prototype/classsituation. It should be remarked that, as aconsequence of the uniform approach undertaken,the creation of such a class or such an object isaccomplished in XLOG + by virtue of the sameprocedure (see Section 11). Prototyping may then besaid to drive object creation in XLOG + .

(i) tnhetexistence of the attribute itself is checked(ii) if an appropriate attribute is locally availableand has a value, that value is then retrieved(subject, of course, to the successful logical

evaluation of any if-needed predicate attachedto the attribute);(iii) in the case of no local availability of such anattribute (or if it has no value), its ancestorsare searched (at run time), until either a value

is found for the same attribute in one of itsancestors, or the ancestry lattice is unsuccess-fully exhausted (Section 5.1 contains moredetailed information on the retrieval ofattribute values).As in most other object-oriented environments, In the example of Fig. 3, the IPE_550 objectXLOG + objects are created either from scratch, i.e. inherits the material attribute and value from itswith the explicit creation of its attributes and parent-I_laminated_section-but the depth at-


10/19

Compendium 1023tribute, which is also inherited, has its value defmedlocally. It would then suffice to define a local valuefor depth, width, e:tc., with no mention to material:{IPE_550 ( I _ l am nat ed_s ec t i on)f d ep t h [ ( 5 00mm) ] ) ,( wi d t h [ ( 2 l Omm) ] } ,f _ ) ,1 ( 9)

As previously discussed (Section 3.1), a situation ofconflict may arise in the presence of multipleinheritance when more than one attribute (ormethod) is eligible for inheritance by a child object.Moreover, because inheritance of attributes andmethods is achieved in XLOG + at runtime and theinheritance process stops as soon as a satisfactorycandidate (attribute or method) is found, a searchcriterion needs to he enforced in order to establishhow to traverse the ancestry lattice, i.e. how toproduce ancestors in a topological order.

The criterion ad.opted in the current implemen-tation of XLOG + may be defined as a depth-first/left-right one: the leftmost parent in the objects listof parents is checked first (step 1 in Fig. 7a), its firstparent afterwards (step 2 in Fig. 7a), and so on, untileither the attribute/method in question is found or aroot object (an object with no parents) is reached(step 3, Fig. 7a); in that case, search resumes at thenext leftmost parent of the child of that root object(step 4, Fig. 7a), continues through its first parent andso on and so forth (Fig. 7a).

Some alternative search criteria have been con-sidered, either by actual experimentation or byinvestigating how similar situations have been dealtwith in other systems also supporting multipleinheritance. Stefik and Bobrow [27] claimed thatexperimentation with precedence relationships in aninheritance context was an open issue at the time oftheir paper, in the sense that no solution would begood enough for all situations. The authors believethat this remains true, but that preferable solutionsmay, indeed must, be found for specific purposes. Amost obvious one would have been first to exhaustthe target objects li:st of parents, and only then, if stillrequired, proceed upwards in a breadth-first/left-right manner (Fig. 7b).

(a)94

The approach undertaken of favouring the firstlydeclared parents along the search process was basedon the assumption that, in most cases of designknowledge representation, objects do not need to relyupon multiple inheritance; networks of objects willmostly consist, then, of trees of objects with a singleimmediate parent (Fig. 7~). Most of the exploratorywork preceding the current implementation hasconfirmed the validity of this hypothesis. Therefore,for the case of knowledge bases containing thoseexpected types of objects, one covers the search spacebetter by using a depth-first search criterion(degenerating to a depth-only one for a situationallowing only a single parent to be declared).An additional advantage of the adopted approach,although marginal at this stage, is that it facilitates aneventual implementation of a precedence list cri-terion, i.e. one by which objects would be allowed todeclare weighted parents, with the heavier onestaking precedence along the inheritance searchprocess. Enablement would consist in no more thanperforming a reordering of the target objects list ofparents, by switching the heavier ones to the left-handside of the list, keeping the adopted search criterionunaltered.

Tomiyama [28], while exploring the approriatenessof object-oriented languages for the development ofICAD systems, has claimed that, among some otherproblems, the automatic inheritance of methods andvariables does not fit the principle of informationhiding, which is of particular importance in the caseof superclasses being mostly alien to subclasses.Nonetheless, in agreement with the indispensabilityof having means for representing is-a hierarchies hesubscribes to the use of a selective inheritancemechanism such as delegation, a proposal previouslyformulated in Ref. [7] in the context of designmodelling. Delegation consists basically of an objectdelegating only within the class it belongs to, i.e.automatic inheritance that ceases at the first levelabove the object in its ancestry tree-lattice; in the caseof an object being also a member of another class,such an explicit declaration is required.

However, there is no evidence of the vitalimportance of data hiding through strict encapsula-tion in the context of design knowledge represen-tation. Moreover, as remarked by Stefik and

:...:: ::.,..:.!!

q:.,..i: 7:zt.,~ - . .I II._ *2.(4 objectrootobjectFig. 7. Criteria for search related to multiple inheritance.


11/19

1024 CompendiumBobrow [27], encapsulation, when found to be afundamental issue, may be made by convention, i.e.the program or knowledge-base developer mayrestrain objects from directly accessing attributevalues of other objects. The authors also endorsetheir claim that allowing direct access to objectvariables is a major necessity for knowledgerepresentation purposes, e.g. for comparing twoobjects or attributes from two different objects.Despite advocating that the corruption of theprinciple of information hiding is not a major issuein design knowledge bases, the authors have adoptedan approach which allows an object not to inherit anyparticular method or attribute from any of itsancestors. Moreover, the ability to override inheri-tance is also required for dealing with exceptions.

Inheritance is overridden in XLOG + by theexplicit local inclusion of a specific method orattribute, with a null or non-null value. Search for avalue or method in the ancestry tree is then preventedby the simple local occurrence of the attribute(s)/method(s) in question.

7. QUERYING AS MESSAGE PASSING

Messages are passed to objects in XLOG + bymeans of direct queries, i.e. messages which areinteractively issued to the object as logical queries, orby the inclusion of object or attribute references inclauses of the knowledge base. Messages may then besaid to establish links between actions and objects,having also the role of providing the requiredarguments.The mechanism supporting the issuing of messagesin direct assertions, direct queries or during logicaldeduction, consists of the use of built-in predicatesrequiring logical evaluation and defining proceduresthat, as a side effect, operate directly upon theobjects structure.

Example 1 illustrates two different types of messagepassing: (1) a query which directly retrieves a valuefrom an object attribute; and (2) a generic clausecontaining built-in predicates-value, add-value-which operate directly upon objects. In this example,value retrieves the value of the attribute salary of theobject Lecturer and associates this value with thevariable ?sal. ask is the general XLOG predicate thatposes a query to the system or, strictly speaking,poses a theorem to be proved. In Example 1,add-value asserts a value ?sal o the attribute salary ofthe object ?obj.Example 1. Passing messages to objects.(1)(2)

ask(value(salary of Lecturer(?sal)))check salary (?obj ?sal) ifvaluetsalary of ?obj (?old_sal)) andgreater (?sal ?old_sal) andadd-value (salary of ?obj (?sal) )

Fig. 8. XLOG + objects store no more of their attachedpredicates than the names.

Querying the knowledge base by means of the set ofbuilt-in predicates which operate upon objects leadsto logical deduction with predictable side effectoperations upon the objects defined. This draws onthe message passing interpretation of logic referred toby McCabe [3] in his class template notationproposal.A sub-set of XLOG + built-in predicates providedto deal specifically with objects is given in Section 11.

8. METHODS AS PROCEDURAL AITACHMENTMethods in XLOG + are either default ones, and

are valid for any object-like methods for assignmentor retrieval of attribute values, or may be associatedwith specific objects, if declared through the use ofattached predicates.

A procedure enabling the association of anon-default method with an object is required to bedefined elsewhere. This procedure is the following:

(1) an attribute, preferably with the same name ofthe method in question, must be created;(2) the procedure associated with the method mustbe attached to the attribute in the form of abuilt-in or logic predicate (if-needed orif-changed);

(3) the procedure itself must then be defined inpredicate form (regardless of whether it isassociated with a built-in predicate or with anormal one);

(4) the issuing of messages to invoke methods thencorresponds to retrieving from, or assigning to,those attributes for which if-needed or if-changed predicates were defined according to(1) and (2).

In XLOG + the body of an attached proceduredefined as above does not become part of the objectitself. The name of the attached predicate is the onlyportion of the method definition which is actuallystored locally in the object. Attached predicatesnames behave therefore as pointers to the proceduresthey define, the latter being added to the knowledge


12/19

Compendium 1025base by means omf he available tools for adding may lead to serious difficulties in program debugging,clauses. i.e. unpredictable results may follow from changes toIn Example 2(a), a predicate called x_momqroc is the inheritance structure (to which conventionalattached to an attribute called x_moment_of_inertia methods are immune).of an object named rectangular_shaped_section. Thepredicate add-if-rtd denotes add as a if-needed 9. MUTABLE OBJ ECTSprocedure. The clause or the set of clauses containingthe body of the attached procedure associated with Objects are considered mutable if their propertiesx_mom_proc has to be asserted independently to the may change with the passing of time; otherwise theyknowledge base, as suggested in Example 2(b). are considered static ones. In an object-orientedConsequently, the object will contain no more of the environment, the equivalent concept to a variablesattached procedure than its name (Fig. 8). value in procedural programming is an objects state.

The state of an object is given by the individual valuesExample 2(a). Attaching a predicate name to an of its properties. Therefore, in order to be able toobject. have a defined state and, notably, in order to be ableto effect a required change of state, an object must

~add-if-nd(x_Inoment_of_inertiaallow and support the modification of any of itsproperties (attributes) at any time.of The special reference to objects in this perspectiverectang_shaped_sect (x_momgroc) ) is justified by the importance given to such ability in

>_ many object-oriented applications, not only becauseof mutable objects being able to store data in soExample 2(b). Denning a procedure associated with called local variables (attributes in the case ofan attached predicate. XLOG + ), but also because the ability to support> -)add (x_momsroc(?obj) if value flange-width of ?obj ( ?w) ) andvalue (depth of ?obj (?h) and

value(flange-thickn of ?obj (?ft)) andvalue(web-thickness of ?obj (?wt) ) andcub (?h ?hcu:b) andeval((?Io=?w * ?hcub/l2)) and_)

As far as specialization is concerned, XLOG +implements method specialization [27] and improvesthe level of granularity.A final note about methods in XLOG + concernsthe possibility of relaxing the concept of method, inthe sense that methods may also be defined externallyto the objects they are supposed to belong to. In fact,axioms may be asserted as normal logical sentences,not associated with any particular class or object, butbeing only applicable within the scope of objectssatisfying the preconditions of the procedure/methodthey declare. The procedural interpretation of thoseclauses may be faced as the performance of methodsdefined under the scope of the objects involved.Hence, such methods are bound to objects indepen-dently of explicit reference in the object definition,allowing a means of dynamic inheritance of methods.This extended and relaxed concept of methodsdraws on the ideas of ARTs multi-method [18] orLoops DoMethod [17]. Although it may be seen asa practical and powerful means for combiningobjects methods or simply attribute values, it alsobears the dangers of escaping from the messagepassing convention of object-oriented programming.In particular, the ,widespread use of this mechanism

mutable objects implies the propagation, or at leastthe communication, of changes occurring in themutant object to those other objects which includereferences to it.Different implementations have dealt with thisquestion in diverse ways. While some have to makeuse of more or less cumbersome techniques [3], othersoffer support for an objects state as an inherentproperty of objects [151.This characteristic of objects, extremely importantin knowledge representation tasks, is fully achieved inXLOG + by means of attribute values andprocedural attachment. In fact, the use of attributesas data storing slots, in conjunction with if-changedpredicates used in order to attach broadcastprocedures directed at objects related to them,provides a simple enough effective way of implement-ing to a reasonable extent mutable objects and theirfunctionality.

10. COMPOSITE OBJECBAs previously mentioned, the hierarchical nature ofmost man-made physical entities-and notablycivil/mechanical engineering structures-must be


13/19

1026 Compendium

Fig. 9. Example of composite object.

taken into account when developing knowledgerepresenation tools for design.

One way of endowing knowledge representationformalisms with these capabilities consists in develop-ing tools that allow the build-up of descriptions ofobjects as an aggregation of parts which arethemselves other objects. By doing so, part-ofrelations among different objects may be defined.Objects formed in this manner are called, in the scopeof this work, composite objects. Conceptually, arecursive definition for composite objects is possiblesince they may be used as parts for other compositeobjects and, therefore, part-of hierarchies may bedefined. Composite objects form, together withmultiple inheritance, the set of instruments providedin XLOG + for combining objects in is-a/part-ofhierarchies.

Two basic approaches could have been followed tointegrate the concept of composite objects into theknowledge representation capabilities of XLOG + .The first would provide a form of describing an objectas having parts formed from other objects by usinga template containing their description; the com-posite object would then be instantiated as having allthe attributes of these contributory parts directlyassociated with it, in a way rather resembling(multiple) inheritance. The second would consist inkeeping a reference within the composite object of allits parts that are, in fact, other objects.

One can consider, for the purpose of illustrating

tyresattributes

Fig. IO. Example of composite objecr built through aninheritance approach.

the implementation and usage of composite objects,the network of objects of Figure 9, used in the partialdescription of a Car. This example suggests that acomposite object like Car may be organized in termsof information located at the following differentsources:

l ocal attributes (non-inherited properties);l nherited attributes (possibly from a number of

different ancestors);l properties that are themselves other subjects.If the first of the basic approaches above

mentioned (rather resembling a special kind ofmultiple inheritance) had been pursued, all the directattributes of Car, as well as those of their constituentpart-sub-objects would have been aggregated underthe same single object. Hence, the Car object in theexample above would result in being described asshown in Fig. 10. The most obvious disadvantage ofthis solution is associated with loss of flexibility andmodularity. If, for example, any change were to occurat the level of the Car component tyres (such as theaddition of a new attribute), its propagation towardsthe composite object Car would become extremelydifficult to handle.

An additional drawback of the inheritanceapproach to composite objects has implications forthe resulting clarity of expression. As an example, onemay use a query concerning the material property ofthe tyres attribute of the Car object: it would lead, ifuse were made of the above Car description, to aconfusing if not misleading query that wouldassociate material with Car,ask(value(materialof Car (?mat))) (10)rather than with tyres,ask(value(materialoftyresofCar(?mat)))

(11)The alternative approach to the implementation of

composite objects consists in keeping local pointerswithin the composite object to the objects defined asparts. An effectively modular approach may then beattainable, in the sense that any kind of alteration,occurring at any time, at the level of the constituentobjects, becomes automatically reflected (i.e. propa-gated) in the composite object. This alternativeapproach is adopted in XLOG + by simply definingobject names as the values of composite objectsattributes. Figure 11 illustrates the support forcomposite objects in XLOG + .

From the strict point of view of knowledge basedorganization, the level of nesting that a part-ofhierarchy may support should have no clearlimitations. There is, however, an impairment arisingfrom cognitive limitations of human behaviour when


14/19

Compendium 1027

Fig. 11.Object-oriented representations in structural design.

dealing with such knowledge bases. Indeed, theabsence of a limit for nesting part-ofs would turn theuse of composite (objects into a source of complexityrather than modularity and clarity. On the otherhand, one has also to consider the limitations ofhumans as users of knowledge so nested: the authorsknow of no quamified evidence concerning the levelof nesting considered tractable. Nonetheless, similarconcerns have been raised in the exploration of bettercriteria for developing geometric solid modellers [29].

11. IMPLEMENTATION OF XLOG +The notation used in the present paper denotes

compulsory strings and characters in boldface type;references to compulsory user-dependent com-ponents are included between ( ) and optionalarguments between right brackets [ I.

The set of built-ln predicates provided in XLOG +to work specifically with objects may be divided asfollows:

0 Creation;l Destruction;l Information/Modification;l Assignment/Retrieval;l Genera1 purpose.These built-in predicates have to be provided with

the ability to return true or false values, reflectingsuccess or failure in their evaluations, i.e. in theperformance of the procedures they define. It remainsa task of the theorem prover to propagate to the userthe consequences of the returned true/false values.

The most important XLOG + predicates are listedin Table 1 using th.e following notation: characters inboldface denote compulsory strings; references tocompulsory user-dependent components are included

between ( ) and optional arguments should bebetween right brackets [ ]. More details about thesyntax of XLOG and XLOG + can be foundelsewhere [I, 231. A short illustration is presented inExample 3, where ) denotes the XLOG + promptand subt(x y z) means x = y - z.XLOG was originally written as a C function; it stillis, although the code for supporting object orien-tation was written in C + + [16].

Because of the layer architecture of XLOG,addition of built-in procedures may occur in a broadsense by adding to a table the names of the predicatesand functions with which they are associated and bylinking the compiled code of those functions to theXLOG object libraries.

The first implementation of the object-orientedfeatures now described must be understood as anexperimental one aiming, above all, at developing arapid prototype to be used as an exploratory tool.l$evertheless, his apparently low key approach seemsto be an emerging trend in software engineering, asnoticed by others [11, 301.

For the user who is interested in developingXLOG + facilities on the top of the objectorientation approach, access to a few header files issufficient. These files contain C+ + class definitionsof the fundamental data structures supportingXLOG + objects: generic_list.h, other_listsh, at-tributes.h, 0bjects.h. Also, knowledge about foursource files containing the code for their associatedmember functions may be required. These files are:listsc, attrs.c, 0bjects.c and objtab1e.c.

An XLOG + object is internally represented asgroup of attributes, of the form shown in Fig. 12.

Attributes are themselves stored in a symbol tableconsisting of a vector of linked lists grouped bymeans of a simple hashing process, ensuring thatattributes with the same hash code are linkedtogether. Class tbl_attrs in Fig. 13 defines such a data


15/19

1028 CompendiumTable 1. Some XLOG + built-in medicates

Creation:add-obj (object) ( [(parent-i)] [, (parent-i + l>l [_I ) 1add-attr((attribute) of (object) [((value)))add-if-ndi(attribute)of(object)((predicate_name))add-if-ch((attribute)of(object)((predicate_name)))add((Clause))Destruction:dal-obj ((object))del-attr((attribute) of (object))Information/Modification:list-obj ((n) o (m) [attrl)list-obj(al1 [attrl)list(obj [attrl vail attl [pranl)liet((obj) [attrl i-11 [attl [pranl)list-attrs((obj) [vail att-oredl)list ((object) [attrl [vail attl )is-a((object)(ancestor))is a( (variable) (variable))has-a((object) (variable))has-a((variable) (variable))has-val((attribute) of (object>)has-parant((object) (parent))Assignment/Retrieval:add-value((attr) of (obj) ((val)))put-value((attr) of (obj) ((val))ask (value((attr)of(obj-ref)((val)))General purpose:readf( file-name))eave( (file-name))display((string))

Example 3.)add-obj (employee))add-attr(age of employee))add-if-nd(age of emPloyee(calc_age)))add( calc_age(?obj) if

current_year(?current) andvalue(year-of-birthof ?obj (?year)) andsubt(?AGE ?current ?year) andadd-value(age of obj (?AGE)))

)add(current_year(1991)))add-obj(Fernando-Pessoa (employee)))add-attr(year-of-birth of Fernando-Pessoa(l955)))ask(value (age of Fernando-Pessoa( ?age)) and

dieglay(The age of the employee is ?age))

structure and declares the methods provided forhandling it.Finally, the internal structure of XLOG + objectshas been defined as a derivation of the above defined

struct attribute1 char *name;char *value;char *if-changed;char *if-neededattribute *nextva ue

@if-&anif-needed

Fig. 12. Code and illustration of the structure ofattribute. an

data structures: a table of attributes to which a name,a list of parents, a list of children and a set ofassociated methods to operate upon it have beenadded.

class tbl_attrs // Hashed table of attrib.sattribute l is;int size;public:

// xlog+ attributes// Table sizetbl_attrs(int sz = 20); // COnStrUCtor-tbl_attrsO; // Destructorattribute l ook(char *); // lookupattribute*insert(char'.char'.char*,char',chdr*):void listattrs(int, int): // listing

Fig. 13. Definition of a list of attributes.


16/19

Compendium 1029class object : public tbl_attrs1 friend class obj_tbl:char "name;lst_objs "Parents;lst_objs "Children;

object *next;public:object(char*. lst_objs* = 0):-objectO,void updateChildren(object *newChild)( Children->append(newChild); 1

char* ask_value(char');int add_value(char*. char*);int put_value(char*, char');int add_if_changed(char*. char*):int al~d_if_needed(char', char*);object* i';_a(char*, int=l);attribute* has_a(char', int=l):void list_my_attrs(int. int);object* find_child(char*. int=l);char* gat_if_needed(char*, int=l);char* get_if_changed(char*, int=l):1;

Fig. 14. Header file and graphic depiction of anXLOG + object.

It is worth observing the close relationship betweenmethods available for the object class and the built-inpredicates provided in XLOG + for dealing withobjects, strongly emphasizing the clarity achievedthrough programming with an object-oriented philos-ophy (using C-k +, in this case). Using anobject-oriented terminology, XLOG + objects maybe said to be groups of attributes for which some newproperties-name, parents and children-and severalmethods have been defined (see Fig. 14).

The data structure supporting the implementationof XLOG + objects becomes completely defined bydescribing the table in which they are stored-avector of linked lists of objects in which objects withthe same names hash code are linked together. Thecode listed in Fig. 15 is clear enough to avoid the needfor further comments.

1:Z. RELATED WORK

Some of the commercial knowledge engineeringframeworks which provide support for objects--suchas CommonLoops [31], ART [18], NExpertOb-ject [32], KEE [33, 341, STRATA [35] and manyothers-are not intended to be primarily used as logicprogramming too:ls. In fact, in most cases it is notclear to the authors how they embrace logic, if at all,

class obj_tbl // Hashed table of objects(

object l ol;int ol_size:public:obj_tbl(int sz = MAX_NO_OBJI:object l ind(char*j; // Lookup onlyobject l ppend(char*n, lst_str*p=O);void remove(char *I; // Delete objectvoid listmetvoidj; // Listing method1;

Fig. 15. Table of objects.

either as a knowledge representation formalism or asa programming paradigm; they seem to be primarilyintended for combining objects with production rules,leading to what one may call object-orientedproduction systems.

It must be stressed, however, that the proposedenvironment may also be used in a perspective similarto that of those systems. In particular, if comparedwith ART, for example, XLOG + may easily andclearly organize data as objects (schemata) withattributes (slots), allowing attribute inheritance andpattern matching from rules (reasoning) [181.A lesser-known commercial system which seems tobe closer to the present work is the IntelligenceCom-piler package[l4]. It is a frame-based system,implemented in C, and may be used when embeddedwithin a logic programming environment. Theauthors, however, have no further knowledge aboutthe underlying theoretical foundations of this systemnor details of the current stage of implementation.The approaches followed by Kornfeld [36],Shapiro and Takeuchi [37], Zaniolo [19] and Mc-Cabe [3] have the common objective of developingnew logic programming languages based on Prlong orextensions of it, with support for objects or, at least,some of their functionality.Both Zaniolo and McCabe propose translationsbetween objects and Prolog, while Shapiro effects theimplementation of an object-oriented language as ameans for attaining concurrent logic programming.A reference is merited by the work of Bowen andKowalski [38] who have tackled the use of metalanguage to construct programs. This may beinterpreted as an early attempt to relate theobject-oriented paradigm to conventional logicprogramming.Kornfeld proposes a generalization of Prologsunification process in order to include the explicitdeclaration of equality relations among predicates.Despite the merit of such an early effort towardsobject-oriented functionality, it has been revealed asrather restricted in practical application. In fact, asnoticed in Ref. [19], the symmetric nature of theequality relation renders it virtually useless forrepresenting real inheritance situations, even if trivial.Moreover, no message-passing mechanism is pro-vided in the proposal. Finally, a contradiction whichmay be found in Kornfelds work (as well as inothers) is that, while it may be understood as a meansto endow Prolog with a relevant new capacity-andthus presumes a clear propensity for the use ofProlog-it requires a high degree of surgery onexisting interpreters and/or compilers, namely at thelevel of the implementation of the unificationalgorithm. This is an option rarely acceptable formost users.Zaniolo proposes the implementation of object-ori-ented features in Prolog and on top of existing Prologinterpreters and/or compilers. This is achieved by theintroduction of a number of new infix operators-


17/19

1030 Compendiumwith, is-a and :-which may be used to declare objectsand their associated methods (with, :), as well as tobuild inheritance structures (is-a). Despite its totalcommitment to Prolog-which has already beendismissed as unnecessary (and even undesirable) forthe objectives of the current work-Zaniolos earlyproposal addresses very elegantly some of theproblems with object-oriented programminglanguages that some subsequent proposals have failedto consider. Such is the case, for example, in thetreatment he gives to multiple inheritance and to itsoverriding. Concerning the latter aspect, however, thesolution achieved has some inconsistencies which area result of the message interpretation algorithmimplemented. In particular, a method may beoverriden by several local ones, an arguablyinteresting capability. As a consequence, more thanone method may become available for executionduring message answering, those methods, beinglocal ones, may not be inherited. It seems thatrestricting the availability of methods to a single one,or extending it to the full inheritance lattice with theadditional use of a selection criterion, would result ina more coherent solution.

A very broad statement of McCabes proposal isthat labels (with or without variables) are used inorder to structure (large) logic programs byassociating related groups of clauses under thoselabels. Such related sets of axioms therefore formobjects or classes of objects. An important drawbackof the approach followed by McCabe, which alsoaffects Zaniolos work, is that, due to their strongcommitment to logic programming, they do notreally implement objects with state, i.e. whoseattribute values may change throughout someassociated process. Another problem with McCabesclass template notation is that one is not allowed toadd, modify or remove properties of an object,without having to redefine the whole object. As apositive contribution of his work, McCabe claimsthat the broadcast message mechanism is a uniqueand original feature which assumes particularimportance when physical systems are modelled as acomposition of several objects (composite objects).

Watson and Chan [lo] put forward a prototypicobject-oriented knowledge representation system,based on Prolog, with support for schema evolution,composite objects, declarative methods and versioncontrol. Although their declared main purpose is theimplementation of an object-oriented databasesystem for engineering applications, They eventuallyconvey that persistency of asserted objects issimplistically ensured by writing Prolog clauses toASCII text files.

The OBLOG proposal by Gordon [21] wasdeveloped with the primary aim of representing legalknowledge in a logic system. Gordon starts from theobservation that objects are mostly a syntacticvariant of logic sentences; and he follows with theproposal of an object-oriented approach to logic

programming, without straying from the semanticsof predicate logic. This contribution reveals aninteresting and early attempt at enhancing logicprogramming with object orientation by reinterpret-ing the frame paradigm. However, OBLOG fails toattend to some important features of object-orientedsystems, such as inheritance overriding. Gordon alsoclaims that he would rather have included realfunctions for representing functional properties ofobjects, instead of relations acting as functions.

As for Shapiros work (and that of his followers),it consists mostly of implementing object-orientedlanguages in parallel logic programming (ConcurrentProlog in his case). Although his work presents veryinteresting and often unique features, such as effectivenon-sequential execution through the use of streams,it clearly aims at objectives radically different fromthe ones pursued in the conception of XLOG + .Such a diversion from the scope of the present workmay be illustrated by the lack of support for aninheritance structure in Concurrent Prolog. More-over, the contradiction arising from a commitment toProlog together with major surgery requirements onexisting interpreters/compilers is also present; thechanges demanded reach the point of eliminating theassert and retract Prolog built-in predicates.The POOL language (Parallel Object-orientedLogic) [6] stands as another proposal along the sameline as Shapiros contributions, where parallelism isreached through message-passing between concurrentexecuting objects synchronized by means of monitor-like constructs. Similarly to most other systems,methods are limited to the sequential execution offirst-order Horn clauses.

The present paper is not at all concerned with theconsideration of parallelism in logic programming.Nonetheless, a final reference is merited by yetanother parallel object-oriented logic programmingsystem--OAR (objects and reasoning) (71. In OAR,parallelism is achieved by

engineering design knowledge representation based on logic and objects

Documents