Módszertanok ismeretelemzésre
Molnár Bálint
PhD, egyetemi docens, BKÁE
MTA Információtechnológiai Alapítvány
2003
Módszertanok ismeretelemzésre, ismeretbázisú és szakértő rendszerek tervezésére 1
Az ismeretbázisú rendszerek első nagyobb sikerei és a prototípus szerű megközelítések vegyes sikereket produkáló eredményei után megjelent az igény, hogy ha ezt a számítástechnika, informatika egyik elfogadott mérnöki ágának (“tudományának”) tekintik, akkor ezt az általános mérnöki tervezési elveknek megfelelően szilárd és szabatos elvi alapokra kellene helyezni. Az elmúlt évek, évtizedek alatt kikristályosodott, hogy “intelligens” számítógép programok építéséhez négy jól elkülöníthető alkotórész megkülönböztetésére van szükség. – A szakterület ontológiája, amely azokat a fogalmakat, kifejezéseket, a köztük fennálló kapcsolatokat írja le, amelyek az alkalmazási területet jellemzik, és ezáltal megteremtik azt a kommunikációs szövegkörnyezetet2 (diskurzust), amelyben az alkalmazási terület lényeges fogalmai vitathatók, elemezhetők; – Az ismeretbázisból, amely a logikai ismereteket tárolja kijelentések formájában az adott alkalmazási területről, mégpedig úgy, hogy mindegyik kijelentés a szakterület ontológiájában előforduló fogalmakra vonatkozik, csak azokat használja; – A problémamegoldó módszerekből, amelyek azt a vezérlési szerkezetet adják meg, amelyekkel a tipikus, szakterület független problémamegoldási stratégiákat lehet kivitelezni, ilyenek például: klasszifikáció (osztályba sorolás), hiba diagnosztika, tervezés; – A leképezésből, amely a szakterület ontológiájában szereplő fogalmakat továbbá, a kijelentésekből álló ismeretbázist, amelynek a struktúráját a szakterület ontológiája megszabja összerendeli a problémamegoldó módszerek be- és kimeneti igényeivel. Ez a felsorolás azt sugallja, hogy “intelligens rendszerek” építése egy olyan módszertant kíván, amelyben először a fejlesztők létrehozzák a terület ontológiáját, amely az alkalmazási terület lényeges fogalmait ragadja meg; majd ezt kibővítik azokkal a kijelentésekkel, amelyek a szakterület logikai ismereteit tükrözik vissza (’kijelentéskalkulus’), és végül a szakterület ilyen formában megfogalmazott ismereteit leképezik, összerendelik azzal az egy vagy esetleg több probléma megoldó módszerrel, amelyek az alkalmazási területtől függetlenül adják meg a vezérlési struktúrát.
Protégé A Stanford egyetemen készítettek egy eszközt és egy módszert, amely az ismeretelemzés egyik elfogadott elméleti irányának (paradigmájának) megfelelően építettek fel. Az egyik kutatási irány a szakterület független problémamegoldó módszerek modelljeinek felhasználásából indul ki, és ezek alapján hoznak létre ismeretelemzési, tudásszerző eszközöket3 (McDermott, 1988). Ezek a modellek a szóban forgó feladat megoldásában segítik az ismeretbázisú rendszer tervezőjét, ilyen problémamegoldó módszerek például, a heurisztikusklasszifikáció (Clancey, 1985), vázlatos terv tovább finomítása (Friedland, Iwasaki, 1985)4. 1
Knowledge acquisition, knowledge-based system, expert system A filozófia egyes ágaiban is diskurzusnak nevezik ezt a kommunikációs szövegkörnyezetet, amelyben az adott filozófiai iskola fogalmai nézetei, tézisei vitathatók, más iskolák fogalmai esetleg egyáltalán nem értelmezhetők, hiszen nem azonos fogalmi alapon és ezért nem azonos vita alapon állnak. (’Domain of discourse’) 3 Knowledge acqusition tool 4 heuristic-classification, skeletal-plan refinement. 2
Ezért feladat és szakterület specifikus eszköz nyerhető a feladat és szakterület független modellekből. Mivel pedig a problémamegoldó modellek függetlenek az ismeretreprezentáció választott formalizmusától, ezért a feladatok modellezése az ismeretek szintjén jelenik meg, (Newell, 1982), ahol az ismeret elemek szerepét határozzák csak meg, szemben a szimbolikus szinttel, ahol is minden ismeret elem típust részletesen le kell írni. Problémamegoldó modellek alapján épített eszközökre több példa is létezik, a ROGET rendszer (Bennett, 1985) a heurisztikus-klasszifikáció egyik speciális formáját használta diagnosztika feladatokhoz szükséges ismeretek összegyűjtésére és elemzésére. A SALT (Marcus, McDermott, 1989) konfigurációs feladatra használta a “javasoljmajdfinomítsd” (propose-and-revise) módszert. Egy másik eszköz és módszertani csoport meta szinten működik. Ezek az eszközök a feladat egy modelljéből automatikusan egy ismeretelemző, tudásszerző eszközt hoznak létre. Erre példa a PROTÉGÉ (Musen 1989), amely (problémamegoldó) módszer központú, míg a DOTS (Eriksson, 1990), pedig nem követ egyetlen konkrét problémamegoldó módszert sem. A PROTÉGÉ az eszköz automatikus létrehozását egy olyan felületen keresztül valósítja meg, amelyet az alkalmazás készítő mérnök használ egy ismeret-szerkesztő formájában. Grafikus felületen keresztül gyűjti be a procedurális ismereteket (pl. folyamat ábrák). Az embergép kommunikációs felület a szóban forgó terület feladat modelljén alapul, ezért a PROTÉGÉ által automatikusan létrehozott eszköz az ismeretelemzés és tudásszerzés teljes folyamatán keresztül segíti a felhasználót, irányítja a tevékenységét, és ezáltal garantálja, hogy az összegyűjtött ismeretek teljesnek és ellentmondásmentesnek tekinthetők a terület modelljére vonatkoztatva. PROTÉGÉ hátránya az, hogy hasonlóan a többi problémamegoldó módszeren alapuló eszközhöz, nem vagy csak nehezen tudja a szakterület függő vezérlési ismeretek helyét megtalálni. A szokásos eljárás ilyenkor az, hogy az ismeret szintről az ismeretbázis tervezőjének át kell mennie a szimbólum szintre, és ott kell a szükséges módosításokat közvetlenül a szabályhalmazban végrehajtania. ’Feladat’ fogalma a PROTÉGÉ-ben A feladat egy olyan tevékenység vagy tevékenység absztrakciója, amelyik a valós világban létezik. A feladat (be)fogad bizonyos bemeneti adatokat és valamilyen kimenetet készít. A terület, amelyre a feladatot alkalmazzák meghatározza, hogy milyen bemeneti adatok fogadhatók el és milyen típusú kimeneteket fog létre hozni a feladat. A feladat a nem összetett a PROTÉGÉ-ben, azaz nem létezik a részfeladat fogalma, a részfeladatok hierarchiája sem. A feladat lebontása részfeladatokra csak a problémamegoldó módszer kontextusában értelmezhető és hajtható végre. Továbbá a feladat nem támaszt semmilyen követelményt a feladat végrehajtásához alkalmazandó ismeretek típusa iránt. Ez eltér más kutatók megközelítésétől. ’Mechanizmus’ fogalma a PROTÉGÉ-ben A PROTÉGÉ könyvtárában a mechanizmus egy olyan eljárás, amely végrehajt, vagyis megold egy feladatot. Ez annak a leírását jelenti, hogy egy feladatot, hogyan lehet kivitelezni. A feladatok és a mechanizmusok között sok-sok kapcsolat van. Azon feladatok véges halmazát, amelyeket egy bizonyos mechanizmussal sikeresen meg lehet oldani a mechanizmus céltartományának (’target’); a mechanizmusok véges halmazát pedig, amelyek sikerrel tudnak egy bizonyos feladatot megoldani a feladat forrástartományának (’source’) nevezik. A mechanizmus előírja, hogy a céltartományába tartozó feladatoknak milyen követelményeknek kell megfelelniük, milyen típusú ismertekre és adatokra van szükség, ahhoz, hogy ezzel a mechanizmussal sikerrel megoldják a feladatot. Ezek az alkotórészek a következők:
– Bemenet / kimenet megadása (B/K): A bement megadása megszabja, hogy milyen bemenetekre van szüksége a mechanizmusnak. A kimenet megadása a mechanizmus céltartományába tartózó feladatokat határozza meg. – Globális adatmodell: Ez a komponens határozza meg a bemeneti adatok típusát, amelyet a mechanizmus elfogad, és a kimeneti adatok típusát, amelyet a mechanizmus létrehoz, továbbá ezeken az adatokon elvégezhető műveletek osztályait. – Szemantikus feltételek halmazát: Ez a halmaz a bemenetek és kimenetek közötti viszonyt szabályozza, vagyis ezekről a feltétekről a feladatban is tudni kell, ebben a formában mint elérhető ismereteknek rendelkezésre kell állniuk a feladat végrehajtása során. – A vezérlési és adatfolyamok: A mechanizmus megköveteli azt, hogy milyen típusú ismeretekre van közvetlenül szüksége ahhoz, hogy az előírt adat és vezérlési információk áramolhassanak. A vezérlés vagy az adatfolyamok megváltoztatására vonatkozó döntés a feladatra vonatkozó ismeretek függvényében lehet meghozni. Módszer Az összes mechanizmus céltartományához tartozó feladatok egyesítése a PROTÉGÉ könyvtárában természetesen nem fedi le az összes lehetséges feladatok halmazát, de ez nem is volt cél. Feladat
Mechanizmus
Eredmény
(a)
Módszer
Részfeladat
Mechanizmus
Eredmény
Részfeladat
Mechanizmus
Eredmény
Összetett részfeladat
Összetett feladat
Módszer
Részfeladat
Részfeladat
Mechanizmus
Mechanizmus
Eredmény
Részfeladat
Mechanizmus
Eredmény
Részfeladat
Mechanizmus
Eredmény
Eredmény
(b)
1. ábra: Módszer, mechanizmus és a feladatok viszonya. (a)-ban s feladatot egyszerűnek tekintik ha egy mechanizmus meg tudja oldani. (b)-ben egy feladat összetett (árnyékolás érzékelteti, ha le kell bontani, lehet az is hogy rekurzív módon egyszerű feladatokra, annak megfelelően, ahogy azt a módszer igényli, az eredmény elérését megelőzően. A részfeladat egy olyan feladat, amely egy feladat lebontásának része Természetesen lesznek olyan feladatok, amelyek kívül esnek a létező mechanizmusok céltartományain. Azonban az is lehetséges, hogy két vagy több mechanizmust egy módszerbe összeszerkesszenek. Mechanizmusok és a módszerek között a feladatokhoz hasonlóan sok-
sok kapcsolat van. A módszerek céltartományába tartozó feladatok természete azonban különbözik a mechanizmusokéba tartozóktól. Ezt érzékelteti az 1. ábra. Ezért érdemes megkülönböztetni a feladatok két típusát akkor, amikor vagy mechanizmusokhoz, vagy módszerekhez kapcsolódnak. Azok a feladatok, amelyek egy feladat céltartományához tartoznak egyszerű feladatnak tekintendők, míg, amelyek pedig egy módszer céltartományába tartoznak, azok az összetett feladatok. A módszer a PROTÉGÉ könyvtárában tehát egy olyan eljárás, amely az összetett feladatokat a részfeladataira bontja. Ez a lebontás addig halad, amíg az összes összetett és részfeladat egyszerű feladatokra nem bomlik. Ha erre a pontra eljutottak, akkor a mechanizmus alkalmazható az egyszerű feladatok megoldására, és ezen keresztül az eredeti összetett feladatot is meg tudja oldani, illetve végrehajtani. Módszerek konfigurálása és összeszerkesztése Módszer konfigurálásnak hívják azt az eljárást, amikor eldöntik azt, hogy melyik mechanizmus vagy módszer fogja megoldani egy feladat lebontás egyes részfeladatait. Amikor, pedig egy vagy több mechanizmust egy módszerbe kapcsolnak össze azért, hogy új céltartományt határozzanak meg akkor ezt módszer szerkesztésnek nevezik. Több mechanizmus összeillesztése meghatároz egy feladat lebontást, amely viszont megszabja az összetett feladat céltartományát, amely természetesen ehhez a lebontáshoz illeszkedik. A PROTÉGÉ eredményeinek értékelése A kutatás számára ellentmondásos igényként jelentkezik egyrészt az a követelmény, hogy építsenek egy olyan ismeretelemző, tudásszerző eszközt, amely szakterület független modelleken alapul, de másrészt ugyanakkor olyan rendszerfelületet mutasson a szóban forgó rendszer, amely feladat-, szakterület-, és felhasználó-függő. A PROTÉGÉ ezt a kihívást két irányból támadva próbálta megoldani. Egyrészt a mechanizmus fogalmának bevezetésével, amelyet alapvető építő egységnek tekintettek, és amelyeknek a segítségével problémamegoldó módszerek voltak szerkeszthetők. Ennek a révén meg kívánták szüntetni az egyetlen módszer kiválasztásából származó korlátokat és egyidejűleg szakterület-független és szakterület-függő ismeret szerepek megadására is mód nyílt. Másrészt létrehoztak egy olyan felhasználói felület kézben tartására szolgáló alrendszert, amely lehetővé teszi, hogy a rendszerfelületet alkalmanként hozzáillesszék, adaptálják a megkonstruált problémamegoldó módszerekhez, továbbá az egyes feladatokhoz, az egyedi szakterületekhez, és felhasználókhoz. A PROTÉGÉ a nagy elődök (Newell, Chandrasekaran, Wielinga) elméleti munkásságára támaszkodik, lsd. az ismeret- és szimbólum szint elve, valamint a feladatok és az ismeretek összeláncoltságára illetve szétválaszthatóságára vonatkozó tézisek. A kutatás számára továbbra is megmaradt az a kihívás, hogy olyan eszközöket hozzanak létre, amelyek az “ismeretszint elvének” megfelelő ismeret-architektúrán alapul, ennek alapján ismeretelemző, tudásszerző eszközt tud automatikusan előállítani, és nem tekinti feleslegesnek, vagy nem kezeli felületesen a legfontosabb ismeretforrást az alkalmazási terület szakértőjét.
VITAL VITAL egy olyan kutatás fejlesztési projekt volt, amelyik módszertani és szoftver eszköz segítséget kívánt nyújtani nagy, beágyazott ismeretbázisú alkalmazások kifejlesztéséhez. VITAL újdonsága az volt, hogy egy olyan módszertanon alapuló szoftvereszköz készletet,
szoftver munkapadot5 akart létrehozni, amely az ismeretbázisú rendszerek teljes életciklusát lefedi, a követelmény specifikációtól a megvalósításig, továbbá a mesterséges intelligencia területén kifejlesztett számos technikát egységes keretben és összehangoltan sorakoztasson fel, bocsásson rendelkezésre, valamint a szoftver mérnöki és az ember-gép kapcsolattal kapcsolatos kutatási területek termékeny kölcsönhatását teremtse meg.
A VITAL ismeretelemzési módszertan A VITAL ismeretelemzési módszertan termék-központú, nevezetesen a fejlesztési folyamatban előállított termékekre összpontosít, amelyek “az ismeretbázisú rendszer fejlesztése során leszállítandó, lényeges és végleges termékeknek tekintendők”. Az alapötlet az, hogy az ismeretbázisú rendszerek fejlesztésénél a strukturált módszertani megközelítés jelentős segítséget tud nyújtani: – Az alkalmazás kifejlesztését a fejlesztési folyamat jól meghatározott és szabatosan előírt termékeinek létrehozása vezérli; – A folyamatban előállított összes termék szerepe valamint a közöttük fennálló kapcsolatok világosan szabályozottak és előírtak; – A folyamat összes termékének létrehozásához módszereknek, technikáknak és eljárásoknak összehangolt, ellentmondásmentes és rendszerezett készletéről gondoskodik a módszertan. Egy ismeretbázisú rendszer elkészítésekor, amelyet a VITAL módszertan szerint fejlesztettek ki, a következő termékeket kell előállítani: – Követelmény specifikáció (Requirements specification, RS): – Ez a dokumentáció az alkalmazási rendszertől azokat az elvárt funkciókat, a tényleges és véglegesnek tekintett peremfeltételeket, korlátozásokat tartalmazza, amelyeknek a rendszernek meg kell felelnie, ki kell azokat elégítenie. – Fogalmi modell (Conceptual Model, CM): – Ez a termék a szakértelme modelljét tartalmazza, amely a szakterület legfontosabb fogalmait, entitásait, a feladatok felépítését, szerkezetét, és a szakértő problémamegoldó viselkedését írja le6. – Rendszerterv (Design Models, DM): – Ez a következőket tartalmazza a “Funkcionális tervet” (Functional Design Model, FDM), és a “Műszaki tervet” (Technical Design Model, TDM). A szóban forgó ismeretbázis egy a tényleges megvalósítástól független működési leírását adja meg a funkcionális terv. A műszaki terv pedig a megvalósítástól függő leírás nyújt, ez a függés a szakterület illetve az ismeretbázis és annak számítástechnikai környezetére is vonatkozhat. A műszaki terv szolgáltatja a leképezést a funkcionális terv és végrehajtandó program kód között. – A végrehajtandó program kód (Executable Code, EC): – Ide tartozik az összes “karbantartandó szoftver alkotórész”, amelyet az alkalmazásba beágyaztak, és amelyeket akár a szóban forgó ismeretbázisú rendszer fejlesztési projekt keretében vagy azonkívül fejlesztettek ki. A szoftver munkapadhoz kidolgozott rendszerfelület, ember-gép párbeszéd szolgáltatás az úgy nevezett “VITAL torony metaforán” alapszik, amely “szobák hasonlat” mérsékelt kiterjesztése. A metafora a következő komponensekből áll: – A torony a szoftver munkapadhoz kapcsolodó rendszerfelület; – A szint (emelet) egy asszisztenshez vagy több más eszközhöz, esetleg a VITALon kívül eső eszközökhöz, kapcsoló felület; 5 6
workbench lsd. (Wielinga92)
– A szoba egy asszisztensen belüli eszköz készlet, amelyet egy fejlesztési termék előállításához együttesen használnak fel. Mindegyik szobát egy bizonyos feladatnak szentelnek. Ugyanazon a szinten elhelyezkedő szobákat az köti össze, hogy ugyanazon fejlesztési termék előállítása végett működnek együtt. Ez a metafora a következő munka módszert sugallja: a felhasználó ugyanazon a szinten mozog a szobák között akkor, amikor egy fejlesztési terméket különböző szempontokból kíván megvizsgálni; a felhasználó másik szintre megy át akkor, amikor az egyik fejlesztési termék eredményeit egy másik fejlesztési termékké akarja átalakítani.
Ontológia tervező módszertanok Egyre növekvő számban készülnek olyan módszertanok, amelyek kifejezetten az ontológia tervezést célozzák meg (Jones98). Az ontológiák vagy a szakterület modelljének elkészítését egyre tágabb körben tekintik az ismeretbázisú rendszerek készítése kulcs kérdésének. Az ilyen szakterület modellek előnyeit sokan és széles körben ecsetelték: az ismeretek, a tudás megosztásának, közkinccsé tételének, az ismeretek újrahasznosíthatóságának lehetősége, továbbá az ismeretbázisú rendszerek tervezésének magasabb minőségi szintjét jelentheti a tudásszerzés, ismeretelemzés és az ismeretek helyességének ellenőrzése (verifikáció és validáció) valamint a rendszer karbantarthatósága tekintetében. A létrehozott ontológiák megvizsgálásakor azonban kiderül, hogy jelentős különbségek vannak közöttük, még akkor is, ha hasonló célokra készítették őket. Ezért folyik jó ontológia tervező módszertan vagy módszertanok keresésese. Ezekről a kisérletekről (Jones98) cikke alapján adunk egy rövid összefoglalót. TOVE (Toronto Virtual Enterprise) A Toronto Virtual Enterprise projekt, kísérlet tapasztalataiból a következő ontológia tervező módszertant alakították ki ((Ninger94a), (Ninger94b), (Ninger95)): – (1) motiváló forgatókönyvek: a kiindulási pont a szóban forgó cég, szervezet problémáinak feltárása, amely gyakran probléma történetek vagy példák formájában jelenik meg; – (2) ontológia hatáskör (kompetencia) informális megfogalmazása: az ontológiával szemben szabott követelmények, amelyek a motiváló forgatókönyveken alapszanak, és az ontológiának ki kell elégitenie; ez a fejlesztési szakasz az ontológia elkészítésére a megelőző szakaszban hozott döntés kiértékelése. – (3) terminológia specifikáció : az ontológia objektumai, attribútumai és a közöttük fennálló kapcsolatok formális leírása (általában elsőrendű logikai kalkulusban). – (4) ontológia hatáskör (kompetencia) formális megfogalmazása: a formálisan leírt terminológia segítségével az ontológiával szemben támasztott követelmények formalizálása. – (5) axiómák megfogalmazása: az alapkifejezéseket határozzák meg az axiómák és értelmezésükön keresztül pedig a peremfeltételeket, korlátokat, amelyeket első rendű logikai kalkulusban írják le. Az axiómák megformálását a formális ontológia hatáskör leírások irányítják, mivel az axióma rendszernek szükségesnek és elégségesnek kell lennie az ontológia hatáskörébe eső illetékességi kérdések kifejezésére és megoldására. – (6) teljességi tézis: kiértékelési szakasz, amely felméri, hogy az ontológia hatáskörébe eső kérdéseket milyen feltételek fennállása esetén tudják megoldani úgy, hogy a megoldások teljesnek tekinthetők. Azon feladatok (tasks) kezdeti megfogalmazását, amelyeket az ontológia a motiváló forgatókönyvek értelmében támogat, a TOVE projektben nyert tapasztalatok általánosításából
nyerték. A motiváló forgatókönyvek csak az egyik lehetőséget adják, amelyekkel a feladatokat le lehet írni, ezért további leíró módszerekre van szükség ahhoz, hogy egy általánosabb és átfogóbb módszertant kaphassanak. A TOVE módszertan megközelítésének nagyon érdekes mozzanata az ontológia kiértékelése, különösen az axióma rendszer teljességének vizsgálata.
Szervezeti modellezésből adódó megközelítés Szervezeti ontológia kifejlesztése során nyert tapasztalatok alapján egy módszertani vázlatot írt le Uschold lsd.(Uschold95), (Uschold96), (Uschold96a). A következőkben lehet röviden összefoglalni: – (1) a cél azonosítás: az ontológia formalizálási fokának meghatározása. – (2) az ontológia kiterjedésének meghatározása: egy olyan “specifikáció” készül, amely felsorolja azokat az információkat, amelyeket az ontológiának le kell írnia. Ezt a motiváló forgatókönyvek vagy az informális ontológia hatásköri kérdések megfogalmazása révén lehet elérni hasonlóan a TOVE-ban alkalmazott eljáráshoz , illetve “ötletbörze és szűrés” segítségével, vagyis a potenciálisan fontosnak tartott fogalmak felsorolásával egy listában, amelyből a lényegteleneket és szinonimákat eltávolítják. – (3) formalizálás: a specifikációnak megfelelő axiómák és formális meghatározások létrehozása. – (4) formális kiértékelése: általános és ontológia specifikus kritériumok alapján az ontológia kitűzött céljaival való összhang és a teljesség leellenőrzése. Ez a megközelítés megkülönbözteti az ontológia építés formális és informális fázisait. Az informális szakaszba tartozik a kulcsfogalmak felismerése, majd szöveges leírás formájában a fogalmak és kapcsolataik meghatározását. Erre a fázisra az általános ismeretelemző és tudásszerző technikák alkalmazását javasolja, de nem ad semmiféle ajánlást az ontológiai fogalmak megragadásának módjára. Ez a megjegyzés gyakorlatilag az összes szóba jövő módszertanra érvényes. Methontology Methontology a következő tevékenység azonosításával indít (lsd. (Fernandez97), (Gomez-Perez96) ): – (1) specifikáció: az ontológia céljának megfogalmazása, a leendő felhasználói kör felmérése, a formalizáltság mértéke tartozik ide, valamint az ontológia kiterjedésének körbejárása, vagyis az ábrázolandó kifejezések, ezek jellemzői és leírásuk részletezettségének (granularitás) meghatározása. Ennek a fejlesztési szakasznak a kimenete egy természetes nyelven megírt specifikációs dokumentum. – (2) ismeretelemzés, tudásszerzés: ez a szakasz az előző szakasszal párhuzmosan folyhat. Nincs semmilyen különösebb előírás, mivel bármelyik és bármilyen ismeretforrást és feldolgozási, begyűjtési módszert lehet használni; a módszertan azonban külön kitér a szakértőkkel folytatott interjúk és a szövegek elemzésének fontosságára. – (3) fogalmi modell alkotás: a szakterület kifejezéseit fogalmak, egyedi példányok, igei kapcsolatok vagy sajátosságok formájában írja le, és mindegyiket egy informális ábrázolási móddal adja meg. – (4) összehangolás: a különböző ontológiák közötti egységesség érdekében más ontológiákból származó definiciókat célszerű beemelni, pl. az Ontolingua szabványosnak tekinthető elemeit. – (5) megvalósítás: az ontológiát formálisan leírják egy adott nyelvben, ilyen lehet például az Ontolingua.
– (6) kiértékelés: erre a fejlesztési szakaszra nagy hangsúly kerül a Methontologyában. Az itt alkalmazott technikák lényegében azokra alapulnak, amelyeketaz ismeretbázisú rendszerek helyességének ellenőrzésére alkalmaznak (verifikáció, validáció). Irányelveket ad a módszertan teljesség, az önellentmondás-mentesség és a redundanciák feltárására. – (7) dokumentáció: a különböző tevékenységekből származó dokumentumok összeállítása. Egy olyan ontológia életciklusa, amelyben ezek a fentebb felsorolt tevékenységek vannak elrendezve, prototípus tovább finomításán alapszik. Egy ontológia a következő állapotokon megy át (amely megfelel néhány előbb leírt tevékenységnek): specifikáció, fogalmi modell alkotás, formalizálás, összehangolás, megvalósítás. Végül az ontológia a karbantartási szakaszba kerül. Az ismeretelemzés, tudásszerzés, kiértékelés és dokumentálás a teljes életciklus alatt folyamatosan folyik. A TOVE módszertanhoz hasonlóan a Methontology megkülönböztető jellemzője a karbantartás szem előtt tartása. A kettő között a fő különbség abban áll, hogy a Methontology egy ontológia életciklusának karbantartási szakaszának teljességét átfogó kérdésekre összpontosít, míg a TOVE sokkal formalizáltabb technikák kiaknázására helyezi a hangsúlyt és sokkal korlátozottabb számú karbantartási kérdéssel foglalkozik.
Ontolingua Létezik a világhálón egy kiszolgáló állomás, ahol az Ontolingua környezet elérhető és ahol jó tanácsok találhatók a kiszolgálón tárolt ontológiák szemlézésére, fejlesztésére, karbantartására és megosztására. ((Farquhar95), (Farquhar96), (Farquhar97)). A nagy előnye az Ontolingua kiszolgáló használatának az, hogy lehetővé teszi korábban kifejlesztett ontológiák elérését. Ez a könyvtár folyamatosan fejlődik annak megfelelően, ahogy a fejlesztők újabb elemeket illesztenek be. Ebben az értelemben az ontológia építés az Ontolingua-ban a moduláris fejlesztés elvén alapul. A könyvtár ontológiái négy különböző módon hasznosíthatók újra: – (a) tartalmazás: az A ontológiát egy az egyben beillesztik a B ontológiába. Az A ontológia szótárát lefordítják a B ontológia szótárára. Majd ezt a fordítást megismétlik az A ontológia axióma rendszerére, és ezzel az axióma rendszerrel kibővítik B axióma rendszerét. Több ontológia egyszerre történő beillesztését is segíti – az Ontolingua. – (b) polimorfikus finomítás: az egyik ontológiában elkészített definíciót a másik ontológia átveszi majd tovább finomítja. Például az összeadás műveletét, amelyet több ontológia is definiál, az A ontológia tartalmazza, majd az értelmezését kiterjesztik karakter sorozatokra (string adattípus) és beillesztik a B ontológiába, majd itt kiterjesztik a vektorok összeadására. – (c) megszorítás: az egyik ontológia megszorítását egy másik ontológiában használják fel, a számok ontológiáját az egész számok ontológiájában használják fel azzal a megszorítással, hogy az összes szám csak egész szám lehet. – (d) ciklikus tartalmazás: mivel az ontológia tartalmazás tranzitív reláció (azaz az (a) pont) a következő helyzet előfordulása megengedett: az A ontológiát tartalmazza a B ontológia, a B ontológiát tartalmazza a C ontológia, a C ontológiát pedig tartalmazza az A ontológia. Ezek a megkülönböztetések nagyon hasznosak az ontológiák újrahasznosíthatósága végett, noha az nem világos, hogy az ontológiák közötti kapcsolatokat teljes mértékben lefedike, például úgy tűnik, hogy azok a leképezések amelyek az egyik ontológiát a másikba átalakítják nincsenek teljesen feltárva. Ontolingua egy de facto szabvány az ontológiák megvalósítására szolgáló eszközök között, azonban a szerver szolgáltatásai mellett szükség van egy sokkal átfogóbb, szélesebb körű módszertan alkalmazására.
KACTUS A CommonKADS módszertant széles körben használják ismeretbázisú rendszerek kifejlesztésére, amelyek készítésében az ontológiák fontos szerepet játszanak. A KACTUS project egy olyan folytatása volt a CommonKADS módszertan kifejlesztésének, amelyik az ontológia fejlesztési kérdéseire összpontosított. Egy mérnöki szabatosságú tervezési megközelítést fogadtak el, amely hangsúlyozta a modularitás, áttervezhetőség és újrahasznosíthatóság elvét ((Schreiber95), (Wielinga94)). Egy ontológiát könyvárban rendelkezésre álló viszonylag kisebb terjedelmű ontológiákból lehet felépíteni, ez viszont megköveteli a különböző, az új ontológia kifejlesztésében szóba kerülő ontológiák közötti leképezéseket. Két leképezés típust definiáltak az ontológiák szótárainak lefordítására: – (i) a leképezett ontológia kifejezéseinek szemantikájában nincs változás. – (ii) a leképezett ontológia szemantikájában változás csak akkor következik be, amikor annak értelmezésére sor kerül, interpretálása a másik ontológia értelmében szükségessé válik. A lényeges, a területre vonatkozó ontológiák kiválasztását a könyvtárból egy indexelési eljárás, mutató rendszer segíti. Ez az ontológia felhasználásának lehetséges értelemzési környezetét három dimenzióban fogja meg: a feladat típusok, a problémamegoldó módszerek és a szakterület típusa alapján. A modularitás elve általánosan elfogadottaz ontológia tervezéssel foglalkozók körében, hiszen ez az újrahasznosíthatóság elvéből következik.
PLINIUS A Plinius (Mars94) projekt arra tett kísérletet, hogy természetes nyelven megírt szövegekből, félig automatikusan gyűjtse ki az ismereteket, mégpedig az „Engineered Material Abstract” periodika on-line változatából a cím és a kivonatok szövegének elemzéséből. A Plinius ontológiát a természetes nyelvű mondatok egy ismeret reprezentáció nyelv kifejezéseire való fordítás céljára fejlesztették ki. Azokat a tervezési döntéseket, amelyeket a fejlesztés során hoztak és szakterület függetlennek tűntek úgy terjesztették elő mintha általános ontológia a fejlesztési elvek volnának. Ezek a következők: – (1) ugyanarról az entitásról szóló ellentmondó állítások annál könnyebben tárhatók fel minél teljesebben írják le az adott fogalmat. – (2) a létező formális elméleteket úgy, ahogy vannak elfogadják; a szakterület ontológiája nem ad specifikációt a logikai konstansokra. – (3) az ontológiának függetlennek kell lennie az ismeret reprezentációs nyelvtől. – (4) a fogalmi modell készítésének elvei azt állítják, hogy egy ontológia fogalmi primitívekből és szerkesztési szabályokból áll, amelyek lehetővé teszik ezen primitívek segítségével további fogalmak létrehozását. – (5) egy alul nézetből induló megközelítést fogadtak el azért, hogy a megoldandó feladatot elégséges mértékben tudják teljesen megoldani. Azaz a fogalmi modell készítésekor alsó szintű fogalmakból indulnak ki és a szerkesztési szabályok segítségével hoznak létre magasabb szintű fogalmakat. – (6) egy ontológia kifejlesztése mérnöki tervezési döntéseken alapul, például egy bizonyos fogalmom beillesztésekor költség-haszon elemzést kell végezni. – (7) az ontológiát ki kell értékelni a feladat teljes megoldhatósága szempontjából. Ez a teljességi kritérium két részre bontható: egyik a lefedettség, azaz minden az érdeklődésre számot tartó fogalmat lefedtek-e, a másik a részletezettség (minden lényeges megkülönböztetés, fogalmi különbség tétel megtörtént-e?
Irodalom VITAL homepage: http://www.cs.Helsinki.FI:80/~linden/extra_files/vital_homepage.html Sisyphus 1 Visualizations: http://kmi.open.ac.uk/~john/vital/sisyphus1visualizations.html (Jones98) Dean Jones, Trevor Bench-Capon, and Pepijn Visser. Methodologies for Ontology Development, ed: José Cuena, IT & KNOWS, Information Technologies and Knowledge Systems, Proceedings of the 15th IFIP World Computer Congress, 31 Aufgust-4 September 1998, Vienna/ Austriaand Budapest / Hungary, 62-75 pp, 1998. (Puerta92) A. Puerta, J. Egar, S. Tu, & M. Musen. A Multiple-Method KnowledgeAcquisition Shell for the Automatic Generation of Knowledge-Acquisition Tools. Knowledge Acquisition, 4:171-196, 1992. (Domingue93) Domingue, J., Motta, E. and Watt, S. (1993) The Emerging Vital Workbench. In Ed. Aussenac, N., Boy, G., Gaines, B., Linster, M., Ganascia, J.-G. and Kodratoff, Y. Knowledge Acquisition for Knowledge-Based Systems 7th European Workshop, EKAW'93 Toulouse and Caylus, France, September, pp. 320-339, Springer-Verlag. (Uschold96) USCHOLD, M. (1996) "Building Ontologies: Towards A Unified Methodology", Proc. Expert Systems 96, Cambridge, December 16-18th. (Uschold95) USCHOLD, M. and KING, M. (1995) "Towards A Methodology for Building Ontologies", IJCAI-95 Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, Canada. (Uschold96a) USCHOLD, M. and GRUNINGER, M. (1996) "Ontologies: Principles, Methods and Applications", Knowledge Engineering Review, 11(2), 93-137. (Gruninger94a) GRUNINGER, M. and FOX, M.S. (1994a) "The Design and Evaluation of Ontologies for Enterprise Engineering", Workshop on Implemented Ontologies, European Conference on Artificial Intelligence 1994,, Amsterdam, NL. (Gruninger94b) GRUNINGER, M. and FOX, M.S. (1994b) "The Role of Competency Questions in Enterprise Engineering", IFIP WG5.7 Workshop on Benchmarking - Theory and Practice, Trondheim, Norway. (Gruninger 95) GRUNINGER, M. and FOX, M.S. (1995) "Methodology for the Design and Evaluation of Ontologies", IJCAI-95 Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, August 19-20th. (Fernandez97) FERNANDEZ, M., GOMEZ-PEREZ, A. and JURISTO, N. (1997) "METHONTOLOGY: From Ontological Art Towards Ontological Engineering", AAAI-97 Spring Symposium on Ontological Engineering, Stanford University, March 24-26th. (Gomez-Perez96) GOMEZ-PEREZ, A., FERNANDEZ, M. and DE VICENTE, A.J. (1996) "Towards a Method to Conceptualize Domain Ontologies", ECAI-96 Workshop on Ontological Engineering, Budapest. (Farquhar95) FARQUHAR, A., FIKES, R., PRATT, W. and RICE, J. (1995) "Collaborative Ontology Construction for Information Integration", Technical Report KSL 95-63, Knowledge Systems Laboratory, Stanford University. (Farquhar96) FARQUHAR, A., FIKES, R. and RICE, J. (1996) "The Ontolingua Server: A Tool for Collaborative Ontology Construction", Technical Report KSL-96-26, Knowledge Systems Laboratory, Stanford University.
(Farquhar97) FARQUHAR, A., FIKES, R. and RICE, J. (1997) "Tools for Assembling Modular Ontologies in Ontolingua", Technical Report KSL-97-03, Knowledge Systems Laboratory, Stanford University. (Schreiber95) SCHREIBER, A.TH., WIELINGA, B.J. and JANSWEIJER, W.H. (1995) "The KACTUS View on the ‘O’ Word", IJCAI Workshop on Basic Ontological Issues in Knowledge Sharing, Montreal, August 19-20th. (Wielinga94) WIELINGA, B.J., SCHREIBER, A.TH., JANSWEIJER, W.H., ANJEWIERDEN, A. and VAN HARMELEN, F. (1994) "Framework and Formalism for Expressing Ontologies", KACTUS Project Deliverable DO1b.1, University of Amsterdam. (Mars94) MARS, N.J.I., TER STAL, W.G., DE JONG, H., VAN DER VET, P.E. and SPEEL, P.-H. (1994) "Semi-automatic Knowledge Acquisition in Plinius: An Engineering Approach", in Proc. 8th Banff Knowledge Acquisition for Knowledge-based Systems Workshop, Banff, January 30th-Febraury 4th, 4.1-4.15.
