1. Úvod

Termín ontologie byl donedávna spojován především s filozofickou disciplínou zkoumající obecné principy bytí. V poslední době s nástupem sémantického webu se tento termín v poněkud posunutém významu čím dál častěji objevuje i ve slovníku knihovníků a informačních pracovníků. Za poměrně krátkou dobu zhruba od 90. let 20. století už informační teorie i praxe stačila vyvinout značné množství často velmi rozdílných koncepcí „informatických“ ontologií. Tuto šíři pojetí dokládá například ontologický metamodel konsorcia OMG, který nabízí následující vymezení obsahu a zejména rozsahu pojmu ontologie: „Ontologie definuje obecné termíny a pojmy (významy), používané k popisu a reprezentaci určité oblasti vědění. Ontologie může co do expresivity sahat od taxonomie (znalosti strukturované hierarchicky nebo genericky stylem předek – potomek) k tezaurům (slova a synonyma), konceptuálním modelům (se složitějším zachycením struktury znalostí) až k logické teorii (s velmi bohatými, složitými, konzistentními a smysluplnými znalostmi).” [1]

Knihovníkům a informačním pracovníkům zní takový výčet velmi povědomě – je pro ně důkazem, že ontologie se nevynořují odkudsi z neznáma, ale naopak že navazují na dosavadní snahy odborníků i laiků organizovat informace a znalosti, ať už byly příslušné činnosti nazývány kategorizace, třídění, klasifikace, indexování, věcná katalogizace nebo věcné pořádání, a jejich výsledky označovány jako indexy, katalogy, klasifikace, číselníky, autority, hesláře či selekční jazyky. Co do formy bývají ontologie konstruovány jako pojmové hierarchie nebo sítě – opět známý koncept z historie organizace znalostí.

Ontologii chápeme pro účely tohoto textu jako sdílitelnou a opakovaně použitelnou pojmovou reprezentaci vymezené domény (úseku reality). S trochou zjednodušení lze říci, že zatímco cílem slovníků je nastolit pořádek mezi slovy a klasifikace se o totéž snaží u pojmů, vlastním zájmem ontologie je realita[2], přesněji řečeno znalosti o ní. Na rozdíl od filozofické ontologie však není cílem informatické ontologie vytvořit reprezentaci reality v její úplnosti, zaměřuje se vždy na určitou dílčí oblast, vymezenou tzv. univerzem diskursu (oborem úvah)[3]. Je dokonce možné vytvořit více ontologií pro jeden výsek reality, pokud na něj pohlížíme z různých úhlů pohledu a zaměříme se na rozdílné typy řešených problémů a úloh (např. jinou ontologii rostlin si zřejmě vytvoří zahrádkáři a jinou biogenetici). Za hlavní oblasti využití ontologií se považují organizace a vyhledávání znalostí, komunikace znalostí, opakované využití existujících znalostí a automatické odvozování (inference) nových znalostí. Tohoto širšího záběru oproti tradičním systémům organizace znalostí dosahují ontologie díky bohatší a jemněji propracované sémantice, zejména v oblasti vztahů, axiomů a pravidel.

Dosavadní vývoj naznačuje, že v distribuovaném síťovém prostředí webu se nepředpokládá vytvoření jediné všeobsahující univerzální ontologie[4], naopak jsou podporovány doménově a úlohově individualizované ontologie navrhované na míru potřebám jednotlivých specifických komunit. S jistou nadsázkou by bylo možné parafrázovat druhý Ranganathanův zákon knihovní vědy ve znění „každému uživateli jeho ontologii“. Je tedy pravděpodobné, že mnozí informační profesionálové budou v dohledné době postaveni před úkol navrhnout vlastní ontologii.

Následující přehled metodik ontologického inženýrství si vzhledem k explozi publikací věnovaných ontologiím v posledním desetiletí samozřejmě nemůže dělat nároky na úplnost. V současné době už existuje nejen množství metodik, ale byly již vypracovány i četné studie zaměřené na jejich srovnávání. Jim nechce tento text konkurovat. Snažíme se spíše svým výběrem představit současnou rozmanitost přístupů a případné zájemce o další metodiky odkazujeme na komparativní zdroje uvedené v závěrečném seznamu literatury. Naším cílem není ani vyhodnotit „nejlepší“ metodiku – pro tento účel je možné využít např. vícekriteriální systém hodnocení a výběru metodik METES (Methodology Evaluation System), navržený Alenou Buchalcevovou původně pro oblast softwarového inženýrství[5]. Tak jako existují různé typy ontologií, existuje i velké množství různě zaměřených metodik, výběr té nejvhodnější pak ovlivňují především specifika věcné oblasti a typu navrhované ontologie. V charakteristikách jednotlivých metodik se pokusíme ukázat jejich užitečnost pro specifické účely a pomoci tak zájemcům o tvorbu ontologií vybrat si takový postup, který bude vhodný pro jimi realizovaný projekt.

2. Ontologické inženýrství a metodiky

Informatické ontologie na rozdíl od těch filozofických nejsou výsledkem vědeckého zkoumání, ale jsou to artefakty, které jsou navrhovány a konstruovány. Přístup k návrhu ontologií prodělal analogický vývoj jako v případě počítačových programů a expertních systémů, jen s cca třicetiletým časovým posunem: od původního pojetí návrhu ontologie jako umění či vědy, dostupných jen několika výjimečně disponovaným jedincům, k inženýrství. Analogicky k softwarovému a znalostnímu inženýrství se zformovala nová inženýrská disciplína – ontologické inženýrství, a rovněž analogicky k CASE systémům v softwarovém inženýrství už jsou k dispozici i specializované softwarové nástroje podporující návrh ontologií (např. Protégé, Ontopia). Ontologické inženýrství zahrnuje soubor aktivit, jež se týkají procesu vývoje, životního cyklu a metod tvorby (konstrukce) ontologií, a pomůcek (např. jazyků), jež tyto aktivity podporují. Důkazem současného stupně zralosti disciplíny jsou první publikovaná sumarizační díla – učebnice[6], [7] a příručky[8], [9]. Pro tuzemské zájemce o úvodní seznámení s problematikou návrhu ontologií už jsou k dispozici i dva obsáhlé přehledové texty v češtině[10], [11].

Stejně jako ve vědeckém výzkumu, i v inženýrském návrhu mají klíčovou roli metodiky. Z možností, jak úspěšně realizovat nějakou činnost či vyřešit problém, se jeví jako nejefektivnější právě použití osvědčené metody. Alternativa v podobě vlastního vynalézání optimálního postupu je sice šancí na kreativní, originální a potenciálně inovativní řešení, negativem jsou však vysoké náklady a ještě vyšší riziko neúspěchu. Obvyklý postup při inženýrském návrhu vypadá tedy následovně: volba metodiky – návrh, model(ování) – výroba / realizace / implementace.

Obecně lze za metodu považovat jakoukoli zaznamenanou zkušenost s prováděním nějaké činnosti či s řešením nějakého problému. Tím, že je metoda zaznamenaná, je umožněno opakované a vícenásobné použití osvědčených postupů, nezávislé na původním nositeli. V souvislosti s metodami se v odborných textech používají v poměrně volném výkladu termíny metoda, metodika a technika a jejich významy se často protínají nebo dokonce splývají[12]. Pro účely tohoto textu budeme metodiku považovat za nadřazený pojem, komplex metod a technik. Vztah metodiky a metody či techniky je vztahem více – více: v jedné metodice může být zahrnuto více metod a technik, jedna metoda či technika může být využita ve více metodikách. Technika může být věc (nástroj, pomůcka) i proces (postup), metoda je pouze proces.

Jádrem každé metodiky je tedy postup – proces, tj. zpracování vstupů na výstupy, s definovaným počátkem a koncem. Proces se může dále členit na subprocesy, což na obrázku 1 znázorňuje symbol + . Klíčovými vstupy jsou samozřejmě jednotlivé metody a techniky, které jsou v dané metodice využité. Výstupy metodiky představují především vytvořené artefakty (tj. ontologie, resp. její komponenty) a jejich dokumentace. Podstatný vliv na výslednou podobu metodiky mají potřeby, požadavky a omezení formulované jejími autory, obvykle i s ohledem na budoucí uživatele. Na obrázku 1 zastupuje jednotlivé kategorie autorů a uživatelů ontologie symbol označený jako zainteresovaný subjekt (angl. stakeholder). V souladu se standardem UML znázorňujeme tento vztah závislosti šipkou, mířící od závislého objektu (metodika) na objekt nezávislý (zainteresovaný subjekt). Hierarchie zainteresovaných subjektů je znázorněna symboly generalizace (dědičnosti) – trojúhelník ukazuje od podřazeného objektu na objekt nadřazený.

Obr.1: Procesní model metodiky

V pohledu znázorněném na obrázku 1 se tedy metodika zužuje na přehled konkrétních aktivit a jejich vzájemných vztahů. To je přístup, který uplatníme v našem přehledu metodik ontologického inženýrství, samozřejmě s vědomím toho, že samotné provedení předepsaných činností k úspěchu nestačí, a vždy bude zapotřebí brát v úvahu ještě širší kontext. Tento kontext představují jak obecné teoretické principy, paradigmata a metody, tak konkrétní použitá pravidla, návrhové vzory, techniky, nástroje a jazykové prostředky.

Obr.2: Kontext metodik ontologického inženýrství

Na obrázku 2 jsou jednotlivé vrstvy kontextu metodik ontologického inženýrství řazeny za sebou od nejobecnějších po konkrétní, ve skutečnosti se ovšem prvky v nich obsažené navzájem propojují podle potřeby napříč vrstvami a bez ohledu na dané pořadí: například jazyk OWL (Web ontology language) je založen na teoretických principech deskripční logiky; metodika UP (Unified Process) využívá techniky iterace a inkrementace a návrhy podle této metodiky lze vyjádřit diagramy v jazyce UML (Unified modeling language), který vychází z objektově orientovaného paradigmatu. Příklady uvedené v tabulce jsou uvedeny v zájmu názornosti a rozhodně si nečiní nárok na úplnost. Jejich výběr byl zvolen zejména s ohledem na aplikovatelnost v ontologickém inženýrství, řazeny jsou zcela formálně podle abecedy.

V přístupu k typologii metodik ontologického inženýrství lze uplatnit poměrně značné množství pohledů, o shrnutí těch nejvýznamnějších se snažíme v přehledu v tabulce 1 a v následujícím komentáři.

Tab.1: Typologie metodik ontologického inženýrství

Ontologické metodiky lze rozdělit na intelektuální (manuální) a automatizované, tj. realizované s použitím softwarových aplikací, jež jsou často vybavené nástroji umělé inteligence a umožňují např. zpracování přirozeného jazyka nebo formální konceptuální analýzu. V úvahu připadají ještě metodiky poloautomatizované, kombinující oba postupy.

Dalším přístupem k členění metodik je postup uplatněný při řešení problémů. Postup top-down směřuje od obecného celku ke konkrétním částem, bottom-up naopak od konkrétních částí k obecnému celku, postup middle-out vychází od nejdůležitějších prvků a postupuje oběma směry k nadřazeným a podřazeným úrovním. V případě návrhu ontologií se tímto způsobem specifikuje postup při tvorbě slovníku. Postup top-down je deduktivní – celá doména se rozčlení na několik základních kategorií a ty se postupně naplňují konkrétními pojmy, resp. termíny. Při postupu bottom-up se uplatňuje indukce – nejprve se shromáždí všechny termíny a ty se pak seskupují do kategorií. Postup middle-out vychází z pojmů považovaných za nejvýznamnější, ty se indukcí zobecňují do vrcholových kategorií a dedukcí specializují na konkrétní termíny zachycující detaily dané domény.

Z hlediska životního cyklu uplatněného při návrhu je možné se setkat s různými kategorizacemi, mezi odborníky nepanuje úplná shoda ani ve významu jednotlivých termínů. Pro účely tohoto textu vycházíme z přístupu Martina Fowlera[13], který rozlišuje dva základní typy: metodiky uplatňující vodopádový model (případně jeho varianty – fontánový model nebo V-model), a metodiky iterativní (a jejich varianty označované jako spirálový model, přírůstkový neboli inkrementální model, evoluční model, prototypový model). Vodopádový model člení projekt podle činností (typicky na specifikaci požadavků, analýzu, návrh, testování a implementaci), jež za sebou následují v pevně stanoveném pořadí. Návraty k předchozím fázím se připouštějí, je však snaha je minimalizovat. Iterativní model je založen na plánovaném opakování procesů. Vychází se z hypotézy, že opakovaným řešením (verzováním, prototypováním) lze dospět ke kvalitnějšímu výsledku. Zpravidla se před zahájením iterací navrhne základní architektura systému, a poté se přírůstkově řeší jednotlivé části (komponenty, funkcionality). Výstupem každé iterace má být nový přírůstek rozsahu a kvality projektu v podobě použitelné části navrhovaného systému. V průběhu dalších iterací se nejen řeší další přírůstek, ale znovu se revidují už dokončené části.

Nejobvyklejším způsobem inženýrského návrhu je postup směrem top-down od modelu k implementaci – tzv. dopředné inženýrství (forward engineering). Pokud se z hotové funkční aplikace ve směru bottom-up dodatečně odvozuje abstraktní konceptuální model, hovoří se o tzv. zpětném inženýrství (reverse engineering). Oba směry vývoje mohou být v současné době podporovány softwarovými prostředky a do jisté míry automatizovány.

Podle zaměření na konkrétní aktivity v průběhu projektu se metodiky člení na plánovací (výsledkem jsou opakovatelné procesy a postupy) a konstrukční (výsledkem jsou znovupoužitelné modely, resp. pravidla pro jejich konstruování).

V souvislosti s množstvím a závazností pravidel obsažených v metodice se mluví o metodikách rigorózních (striktních), kladoucích důraz na dobře definované procesy vývoje, a o agilních (agile, light, lightweight) metodikách, jež za nejdůležitější faktor úspěchu projektu považují kvalitu zúčastněných osob a jejich efektivní spolupráci, a regulaci procesů se snaží minimalizovat ve prospěch kreativních ad hoc řešení a pružných reakcí na změny v průběhu projektu.

Kromě obsahu je možné uvažovat i formáty, v nichž jsou metodiky zaznamenány. Ty mohou mít rozpětí od vědeckého zákona přes odborné texty až po pravidla a standardy na různé úrovni závaznosti. V úvahu připadají jak dobrovolné technické normy – např. ISO nebo ČSN, tak legislativní normy – např. zákony jednotlivých zemí či direktivy EU. Podle rozsahu působnosti je možné se setkat s pravidly a standardy na mezinárodní, národní, odvětvové úrovni (např. vydávané organizacemi IFLA, CIDOC, IEEE), s podnikovými předpisy a s tzv. best practices.

Metodiky ontologického inženýrství už se stačily typologicky rozvrstvit podle toho, jaké specifické úlohy při vývoji ontologie plní. Kromě kompletního vývoje celé ontologie „od nuly“, „na zelené louce“ (from scratch) jsou k dispozici i metodiky specializované na úlohy reengineeringu (zásadní přepracování existující ontologie), metodiky slučování ontologií a metodiky vývoje či učení existujících ontologií (ontology evolution, ontology learning), jež se věnují postupnému doplňování ontologie o další pojmy a vztahy, často realizovanému s podporou specializovaného softwaru. Specifickou kategorii představují také metodiky pro hodnocení ontologií.

Jak již bylo konstatováno, ontologie navazují na předchozí aktivity v oblasti organizace a zpracování znalostí. Rovněž metodiky ontologického inženýrství využívají osvědčené metody příbuzných oborů, nejčastěji umělé inteligence a znalostního inženýrství, softwarového inženýrství a knihovní a informační vědy.

Umělá inteligence a znalostní inženýrství jsou obory zaměřené na návrh znalostních a expertních systémů, případně znalostních bází. Jejich klíčovými metodikami jsou logická pravidla (rules) – procedurální reprezentace znalostí produkčními pravidly typu předpoklad – závěr (if – then), a rámce (frames)[14]– systém reprezentace objektů v bázi znalostí prostřednictvím položek (slots), sloužících k popisu jejich vlastností. Další metodou ověřenou v této oblasti a uplatnitelnou při návrhu ontologií je formální konceptuální analýza (formal concept analysis) – metodika automatické derivace ontologií z datových objektů a jejich vlastností. Značný význam pro ontologické inženýrství mají vyspělé metody získávání znalostí (knowledge acquisition)[15], jež pomáhají v etapě, která je obecně považována při návrhu ontologie za kritickou. Patří mezi ně techniky získávání (elicitace) znalostí od expertů (interview, brainstorming, třídění kartiček, repertoárové tabulky) a automatizované nebo poloautomatizované získávání znalostí z dat (např. data mining).

Softwarové inženýrství je disciplína zaměřená na návrh softwaru, případně informačního systému (systémové inženýrství, systémová integrace). Typickým produktem je softwarová aplikace nebo databáze. Soustředí se zpravidla na unikátní aplikace, navrhované na míru specifickým konkrétním podmínkám a uživatelským potřebám (tzv. usability – individuální použitelnost). Softwarové inženýrství má k dispozici propracované metodiky datové analýzy (např. ERA modelování, diagramy tříd) a metodiky životního cyklu softwarového projektu – např. MMDIS, RUP – Rational Unified Process, Unified Process, Scrum, Crystal, Extrémní programování.

Knihovní věda a informační věda uplatňují své poznatky v aplikační oblasti návrhu a implementace knihovních a informačních systémů. Produkty významné z hlediska ontologického inženýrství jsou tradičně označovány jako selekční jazyky, v současné době se pro ně zřejmě nejčastěji používá termín systém organizace znalostí (KOS – knowledge organization system). Knihovnické ontologie (MDT, tezaury, CIDOC CRM) zůstávají zatím s výjimkou medicíny poněkud stranou pozornosti odborníků na ontologie. Jejich předností nebývá propracovaný systém vztahů, ale bohatost lexikálního obsahu, který zase mnohdy chybí „pravým“ ontologiím vzniklým v laboratorních podmínkách. Soustředí se zpravidla na dosažení širokého konsensu, jejich ambicí je tedy na rozdíl od softwarového inženýrství opakovatelná použitelnost (reusability). K tomuto účelu mají často vypracovaný velmi důkladný a obsáhlý soubor pravidel, uplatňovaných např. při tvorbě slovníku. Metodiky využitelné při tvorbě ontologií jsou jak kvantitativní (bibliometrie, citační analýza), tak kvalitativní, založené na analýze obsahu. Významným přínosem informační vědy je fasetová analyticko-syntetická metoda[16], v praxi osvědčené metody automatické obsahové analýzy a indexování[17]a četné metodiky tvorby tezauru (viz část 3.6). V neposlední řadě přispěla knihovní věda k propracování principu označovaného jako tzv. warrant – přednost pragmatického aspektu před teoretickými principy; je-li to pro praktické účely potřeba, princip warrant umožňuje „ospravedlnit“ i vytvoření ontologie toho, co „není“ – např. pohádkových bytostí, o nichž se píše v literatuře.

3. Přehled metodik návrhu ontologií

Všechny metodiky uvedené v našem přehledu spadají do kategorie metodik určených pro návrh doménových ontologií, uplatňují dopředné inženýrství a jsou určeny pro návrh nových ontologií typu „na zelené louce“. V zásadě lze každou z nich označit za rigorózní, míra rigoróznosti se však v jednotlivých metodikách liší. Krajní pól představuje metodika Uschold – King / Enterprise, jež nabízí pouze základní kostru určenou k naplnění individuálně zvolenými postupy. Na opačné straně spektra stojí např. metodika Methontology a svým způsobem i metodiky tvorby tezauru s detailně vypracovanými pravidly pro řešení jednotlivých jazykových problémů. Podle své příbuznosti s vědními disciplínami jsou metodiky v přehledu rozděleny do tří skupin. V první skupině jsou uvedeny metodiky, jež mají svůj aparát založen na metodách umělé inteligence a znalostního inženýrství: Dnes již klasické a vzájemně se doplňující metodiky Grüninger – Fox / TOVE a Uschold – King / Enterprise, obě vycházející z prostředí podnikové ekonomiky. Doplňuje je obecně zaměřená metodika Noy – McGuiness, která na rozdíl od předchozích dvou metodik, založených na logických pravidlech, vychází z konceptu založeného na rámcích. Jako příklady metodik založených na principech softwarového inženýrství jsou představeny metodiky Methontology a UPON. Přehled uzavírají dvě metodiky pocházející z prostředí knihovních a informačních systémů: metodiky tvorby tezaurů, jež mají dlouhou tradici (datují se už od 70. let 20. století) a jako jediné mají statut mezinárodně přijatých ISO norem, a metodika Denton – Spiteri, postavená na principech fasetové analýzy, jejíž kořeny v podání S. R. Ranganathana sahají až do 20. let 20. století.

Náš přehled je zaměřen informativně, jeho cílem není srovnávat ani hodnotit jednotlivé metodiky. Snažili jsme se však uplatnit jednotnou strukturu popisu metodik, která by měla umožnit případnému zájemci jejich srovnání. U každé metodiky je uveden její producent nebo autor (autoři) a odkazy na zdrojové dokumenty, rok vzniku či publikování a stručná charakteristika určení a specifik metodiky. Jádro popisu představuje procesní model metodiky, který tvoří slovní popis a procesní graf (příp. grafy) klíčových fází. V závěrečném tabulkovém přehledu (tabulka 3) je uvedeno zatřídění popisovaných metodik podle typologie uvedené v části 2.

Na obrázku 3 jsou uvedeny grafické konvence, použité v procesních grafech:

Obr.3: Použité grafické symboly

Názvy procesů se v jednotlivých metodikách liší – nejčastěji se používají označení etapa, fáze, krok, činnost, aktivita, pracovní postup (workflow), úloha, stupeň (stage) ad. V našem přehledu používáme bez ohledu na původní terminologii autorů metodik jednotně termín „fáze“. Obdobný terminologický problém nastává u pojmenování základního konstrukčního prvku ontologie v jednotlivých metodikách – na konceptuální úrovni se používají označení znalost / poznatek, pojem, třída, instance, na úrovni formální (znakové) se lze setkat s označením lexikální jednotka / lexém, slovo, termín, deskriptor. I v tomto ohledu se snažíme o sjednocení používané terminologie ve prospěch označení „pojem“ a „termín“, ostatní termíny zachováváme v popisech metodik jen tehdy, pokud je to nezbytně nutné pro pochopení smyslu.

Poznámka k názvům metodik: U metodik ontologického inženýrství je poměrně běžné, že jim jejich autoři nedávají individuální názvy. Z našeho souboru jsou známy pod oficiálními názvy pouze metodiky Methontology a UPON. Pro ostatní metodiky používáme názvy odvozené ze jmen jejich autorů, u označení metodiky tvorby tezauru jsme zůstali u popisného názvu.

3.1 Grüninger – Fox / TOVE

Autoři: Michael Grüninger a Mark S. Fox (Enterprise Integration Laboratory, University of Toronto).
Rok vzniku / publikování: 1995.

Určení, specifika: Metodika vychází ze zkušeností autorů s projekty zaměřenými na znalostní informační systém o podniku, založené na principech procesního managementu (Common Sense Enterprise Model, Enterprise Engineering, TOVE – Toronto Virtual Enterprise). Navrhuje přístup ke konstrukci ontologie založený na pravidlech predikátové logiky prvního řádu. V životním cyklu se uplatňuje vodopádový model s prvky iterace, autoři doporučují prototypový postup ve směru middle-out.

Klíčové fáze:

• Motivační scénáře: Obvykle narativní formou příběhu (story) zachycené problémy, jimž se má ontologie věnovat, včetně intuitivních návrhů na jejich řešení.
• Neformální kompetenční otázky: Pro každý objekt v ontologii má existovat otázka, na niž má odpovídat. Autoři doporučují kompetenční otázky stratifikovat, tak aby otázky na vyšší úrovni bylo možné zodpovědět s použitím výsledků jednodušších otázek na nižší úrovni.
• Formalizace terminologie: Termíny navržené k zařazení do ontologie mají být specifikovány s použitím predikátové logiky prvního řádu, případně v jazyce KIF (Knowledge interchange format). V rámci vymezeného univerza diskursu se definují objekty, které jsou reprezentovány prostřednictvím konstant a proměnných. Pro objekty se definují atributy jakožto unární predikáty a vztahy mezi nimi se definují pomocí n-árních (např. binárních) predikátů.
• Formální kompetenční otázky: S pomocí formalizované terminologie se neformální kompetenční otázky převedou na formální.
• Formální axiomy: Definují se formální axiomy, jež s použitím predikátové logiky prvního řádu specifikují definice termínů v ontologii a omezení týkající se jejich interpretace. Axiomy se ověřují prostřednictvím formálních kompetenčních otázek, tato fáze je tedy iterativní.
• Teorémy úplnosti: S využitím formálních axiomů se definují podmínky, za nichž je možné prohlásit řešení kompetenčních otázek za kompletní a tím prověřit úplnost ontologie.

Procesní graf (obrázek 4):

Obr.4: Grüninger – Fox

3.2 Uschold – King / Enterprise

Autoři: Michael Uschold a Martin King (Artificial Intelligence Applications Institute, University of Edinburgh).
Rok vzniku / publikování: 1995.

Určení, specifika: Metodika je založená na zkušenostech autorů z realizace ontologie Enterprise pro oblast podnikové ekonomiky a doplněná o náměty a poznatky získané studiem dosavadní odborné literatury (do r. 1995). Autoři nabízejí základní skelet metodiky v podobě několika fází, určený k dalšímu konkretizování a k dopracování podle potřeb konkrétních aplikačních oblastí. Ilustrují využití navržené skeletové metodiky případovou studií popisující detailně aktivity realizované v průběhu návrhu ontologie. V životním cyklu se přiklánějí k postupu middle-out.

Klíčové fáze:

• Identifikace účelu: Definování zamýšleného použití ontologie a jejích uživatelů, včetně způsobu využití ontologie uživatelem (např. typ softwaru, který bude umožňovat přístup k ontologii). K vymezení věcného zaměření autoři doporučují zformulovat kompetenční otázky.
• Zachycení ontologie: Identifikace klíčových pojmů a vztahů v zájmové oblasti. Tvorba přesných a jednoznačných textových definic těchto pojmů. Nalezení a odsouhlasení termínů označujících definované pojmy a vztahy. Relevantní oblastí, z níž je doporučeno v této etapě čerpat, jsou metody získávání znalostí, známé z umělé inteligence.
• Kódování ontologie: Vyjádření zachycené konceptualizace v nějakém formálním jazyce.
• Integrace existujících ontologií: V průběhu zachycování i kódování ontologie se zvažuje, zda je vhodné a možné použít již existující ontologie.
• Vyhodnocení: Posouzení, zda navržená ontologie odpovídá specifikovaným požadavkům, kompetenčním otázkám a/nebo realitě.
• Dokumentace: Autoři konstatují význam dokumentace pro použitelnost ontologie a navrhují rozpracovat pravidla pro její tvorbu, přizpůsobená různým typům ontologií.

Procesní graf (obrázek 5):

Obr.5: Uschold – King

3.3 Noy – McGuiness

Autorky: Natalya F. Noy a Deborah L. McGuiness (Stanford Center for Biomedical Informatics Research, Stanford University School of Medicine, Stanford).
Rok vzniku / publikování: 2001.

Určení, specifika: Metodika vypracovaná s využitím zkušeností autorek s navrhováním ontologií v prostředí softwarových platforem Protégé, Ontolingua a Chimaera. Uplatňují přístup ke konstrukci ontologie založený na rámcích, interpretovaný tak, aby byl vhodný i pro začátečníky. Nabízí vodopádový postup s prvky iterace.

Klíčové fáze:

• Určení domény a rozsahu ontologie: Definování domény, oblastí použití a uživatelů ontologie. Zformulování kompetenčních otázek.
• Posouzení znovupoužití existujících ontologií: Autorky konstatují, že pro většinu domén už existují ontologie uložené ve veřejně dostupných knihovnách ontologií, jež lze importovat, rozšířit či modifikovat, a doporučují to provést.
• Vyjmenování důležitých termínů: Cílem je vytvořit co nejobsáhlejší seznam termínů, které budou obsaženy ve výrocích nebo ve vysvětleních poskytovaných ontologií uživateli, zatím bez řešení jejich sémantických charakteristik a vztahů.
• Definování tříd a jejich hierarchie: Podle zaměření návrháře, eventuálně podle specifik dané domény se použije buď postup top-down, bottom-up nebo middle-out. Ze seznamu termínů se vyberou termíny označující objekty se samostatnou existencí a označí se jako třídy. Mezi třídami se definují generické hierarchické vztahy s uplatněním dědičnosti. Obvykle se tato fáze těsně propojuje s fází následující a realizuje se iterativně. Typický průběh vypadá tak, že se vybere několik kandidátních tříd a pro ně se určí jak hierarchické vztahy, tak jejich vlastnosti. Poté se pokračuje další skupinou tříd.
• Definování vlastností tříd: Z termínů, které nebyly označeny jako třídy, se vyberou ty, jež představují vlastnosti některé z definovaných tříd. Rozlišují se typy vlastností: přirozené / vnitřní (např. barva), vnější (např. název), části strukturovaných objektů a vztahy k jiným objektům.
• Definování faset: Fasetami se rozumí v této metodice „vlastnosti vlastností“, popisující datový typ, povolené hodnoty, počet hodnot (kardinalitu) a případné další parametry. U vlastností, které vyjadřují vztahy, se určí definiční obor (domain) a obor hodnot (range).
• Tvorba instancí: Vytvoření individuálních instancí tříd a naplnění jejich vlastností hodnotami.

Procesní graf (obrázek 6):

Obr.6: Noy – McGuiness

3.4 Methontology

Producent: Ontology Engineering Group (Universidad Politécnica de Madrid)
Rok vzniku / publikování: 1997 (popis metodiky je zpracován podle verze publikované v roce 2004).

Určení, specifika: Východiskem metodiky je standard IEEE 1074 pro návrh životního cyklu softwarových procesů v dnes již neplatné verzi z roku 1996[18]. V souladu s tímto standardem jsou aktivity životního cyklu návrhu ontologie rozčleněny na tři paralelně probíhající skupiny procesů: správa, vývoj, podpora. Pro fáze vývoje je navrženo pořadí provádění, u fází věnovaných správě a podpoře ontologie se předpokládá, že jsou realizovány průběžně během celého životního cyklu projektu. Životní cyklus je založen na prototypování, počítá se s iterativním postupem ve směru middle-out. Na podporu metodiky byly vyvinuty softwarové editory ODE a WebODE, je použitelná i s jinými nástroji (např. Protégé). Je doporučena organizací FIPA (Foundation for Intelligent Physical Agents).

Klíčové fáze:

Aktivity řízení a správy ontologie – plánovací fáze se uskutečňuje na počátku každého vývojového cyklu, kontrola a zajištění kvality probíhají průběžně.

• Plánování: Identifikace úloh, jež mají být vykonány, jejich pořadí a potřebného času a zdrojů.
• Kontrola: Ověření, zda byly naplánované úlohy provedeny.
• Zajištění kvality: Kontrola kvality výstupů (ontologie, software, dokumentace).

Aktivity orientované na vývoj ontologie – člení se na předvývojovou fázi, vlastní vývoj a post-vývojovou fázi.

• Předvývojová fáze: V jejím průběhu se vypracují studie prostředí a studie proveditelnosti.
• Studie prostředí: Určení platformy, na níž bude ontologie provozována, a aplikací, s nimiž má být integrována.
• Studie proveditelnosti: Posouzení vhodnosti a uskutečnitelnosti záměru vytvořit ontologii.
• Vývoj: Fáze vývoje se dále člení na iterativně prováděné fáze specifikace požadavků, konceptualizace, formalizace a implementace.
• Specifikace: Určení účelu, uživatelů a zamýšleného použití ontologie.
• Konceptualizace: Vytvoření konceptuálního modelu z materiálu získaného v průběhu fáze získávání znalostí. Nejvýznamnější fáze tvorby ontologie – autoři doporučují v jejím průběhu vypracovat následující komponenty:
• Výkladový slovník termínů: Zpracování definic a seznamu synonym a zkratek pro všechny termíny, jež budou obsaženy v ontologii.
• Pojmové taxonomie: Výstupem je jedna nebo více taxonomií zachycující hierarchické vztahy mezi pojmy.
• Diagramy ad hoc binárních vztahů: Vytvoří se diagramy zachycující ad hoc binární vztahy mezi pojmy v ontologii navzájem a mezi pojmy v ontologii a pojmy z jiných ontologií.
• Výkladový slovník pojmů: Slovník pojmů zahrnuje jejich instance (nepovinné), atributy tříd a instancí a ad hoc vztahy.
• Popis ad hoc binárních vztahů: Detailní popis každého vztahu, vyskytujícího se v diagramu.
• Popis atributů instancí: Sestavení tabulky s podrobným popisem všech atributů každé instance.
• Popis atributů tříd: Sestavení tabulky s podrobným popisem všech atributů každé třídy.
• Popis konstant: Podrobný popis všech konstant, jež specifikují informace týkající se znalostní domény, a jež mohou být používány ve vzorcích.
• Formální axiomy: Identifikace a přesný popis formálních axiomů vyskytujících se v ontologii. Autoři doporučují zpracovat jejich formulaci prostřednictvím predikátové logiky prvního řádu.
• Pravidla: Identifikace a přesný popis pravidel vyskytujících se v ontologii. Autoři doporučují pro zápis pravidel konstrukci if – then.
• Instance: Po dokončení konceptuálního modelu se mohou definovat relevantní instance. Nepovinná fáze.
• Formalizace: Vyjádření konceptuálního modelu v některém formálním jazyce. Pokud je při konceptualizaci používán softwarový nástroj typu WebODE, lze tuto fázi provést automatizovaně. Nepovinná fáze.
• Implementace: Vytvoření počítačem zpracovatelného modelu ve zvoleném ontologickém jazyce.
• Postvývojová fáze: Zahrnuje údržbu a případné (znovu)použití.
• Údržba: Aktualizace a opravy ontologie podle potřeby.
• (Znovu)použití: Využití existující ontologie jinými ontologiemi nebo aplikacemi.

Aktivity podpory ontologie – veškeré aktivity se uskutečňují podle potřeby souběžně s vývojovými fázemi ontologie.

• Získávání znalostí: Získání znalostí od doménových expertů nebo nějakým automatizovaným procesem (učení ontologií).
• Hodnocení: Technické posouzení ontologie, jejího softwarového prostředí a dokumentace.
• Integrace: Realizuje se v případě, že se vytváří nová ontologie s využitím již existujících ontologií.
• Slučování: Realizuje se v případě, že se vytváří nová ontologie sloučením již existujících ontologií nebo jejich částí, přičemž dochází k sémantickému sjednocení.
• Mapování: Realizuje se v případě, že jsou zdrojové ontologie ponechány beze změny a mezi odpovídajícími částmi jsou definovány vazby.
• Dokumentace: Úplný popis každé dokončené fáze a vytvořeného produktu.
• Správa konfigurací: Záznam všech vytvořených verzí dokumentace i ontologie samotné.

Procesní grafy (obrázky 7 – 10):

Obr.7: Obecný rámec metodiky Methontology

Obr.8: Methontology – detailní členění fází Správa a Podpora

Obr.9: Methontology – detailní členění fáze Vývoj

Obr.10: Methontology – detailní členění fáze Konceptualizace

3.5 UPON: Unified Process for ONtology

Autoři: Antonio De Nicola a Michele Missikoff (Istituto di Analisi dei Sistemi ed Informatica, Consiglio Nazionale delle Ricerche, Roma), Roberto Navigli (Dipartimento di Informatica, Università di Roma „LaSapienza“, Roma).
Rok vzniku / publikování: 2005 (popisována je verze publikovaná v roce 2009).

Určení, specifika: Metodika UPON byla vyvinutá v rámci projektů Interop NoE a Athena IP, jež jsou součástí 6. rámcového programu EU. Jejím zdrojem je metodika Unified Process (UP)[19], která je v současnosti považována za standard ve vývoji rozsáhlých softwarových aplikací. Charakteristickými rysy metodiky UP jsou: orientace na uživatele (vývoj systému řízený případy užití), iterativní a inkrementální vývoj, prototypování, znovupoužití (reuse) existujících návrhů, vzorů i komponent. Nabízí relativně komplikovaný životní cyklus, který ovšem právě díky své komplexnosti lépe odpovídá reálnému průběhu softwarových projektů, než je tomu například u jednoduchého vodopádového postupu. Strukturu softwarového projektu tvoří cykly, členěné na čtyři fáze (inception – zahájení, elaboration – rozpracování, construction – konstrukce, transition – zavedení), a každá fáze se vnitřně člení na stejných pět pracovních postupů (requirements – požadavky, analysis – analýza, design – návrh, implementation – implementace, testing – testování). Jak cykly, tak fáze mohou být prováděny opakovaně (iterativně). Iterace na úrovni celého cyklu vede k vývoji nové verze. Grafickým vyjádřením této struktury je schéma na obrázku 11. V souladu se standardem UML znázorňujeme vztah celek – část šipkou ve tvaru kosočtverce, mířící od části k celku. Konkrétní fáze a pracovní postupy jsou připojeny vztahem závislosti znázorněným šipkou vedoucí od instance k její třídě.

Obr.11: Struktura metodiky Unified Process

Metodika UPON přebírá beze změny strukturu procesu UP včetně názvů fází a pracovních postupů, které však naplňuje konkrétním obsahem přizpůsobeným pro účely návrhu ontologie (viz obr. 12). Je určena pro návrh rozsáhlých i menších doménových ontologií, určených pro oblast přesně vymezenou konkrétními případy užití. Při návrhu ontologie se počítá s dvěma klíčovými typy odborníků – znalostními (ontologickými) inženýry a doménovými specialisty, jimž jsou v procesu vývoje určeny aktivity, za něž zodpovídají. Přírůstkový charakter metodiky se projevuje v postupném vytváření a doplňování výstupů jednotlivých fází: 1) fáze zahájení: slovník (lexicon = seznam termínů, 2) fáze rozpracování: výkladový slovník (glossary = termíny + definice), 3) fáze konstrukce: sémantická síť (semantic network = slovník + vztahy), 4) fáze zavedení: doménová ontologie. Tyto opakující se revize a zdokonalování jednotlivých výstupů jsou vyznačeny v iteracích na obrázcích 12 a 13.

Obr.12: Obecný rámec metodiky UPON[20]

Klíčové fáze:

Fáze Požadavky – cílem je specifikace sémantických potřeb uživatelů a uživatelského pohledu na znalosti, jež mají být zachyceny v ontologii. Vstupem jsou rozhovory s doménovými experty a dokumenty týkající se aplikační oblasti ontologie. Výstupem jsou kompetenční otázky, případy užití a aplikační slovník.

• Určení zájmové domény a rozsahu ontologie: Vymezení té části reality, na niž se ontologie zaměří. Pokud je doména rozsáhlá, určí se subdomény. Nástrojem jsou pojmy a ontologické závazky[21].
• Definování účelu nebo motivačního scénáře s uživateli a jejich záměry: Vymezení uživatelů ontologie, jejich typologie a úloh, jež bude ontologie pro uživatele řešit.
• Vypracování kresleného scénáře: Načrtnutí pořadí aktivit, jež se odehrávají v rámci konkrétního scénáře.
• Vytvoření aplikačního slovníku: Shromáždění terminologie od doménových expertů a z dokumentů používaných v aplikační doméně. Možnost využití kreslených scénářů a nástrojů pro extrakci znalostí z textových dokumentů (např. OntoLearn).
• Identifikace kompetenčních otázek: Formulace otázek na pojmové úrovni, jež má být ontologie schopna zodpovídat. Hlavními typy jsou otázky směřující k vyhledávání (informačních) zdrojů a otázky, jejichž cílem je dosažení sémantické dohody o významu zdrojů.
• Modelování případů užití: Určení funkcionalit, jež má ontologie poskytovat, aby umožnila zodpovězení kompetenčních otázek. Autoři doporučují použít modely případů užití, definované ve standardním modelovacím jazyce UML.

Fáze Analýza – cílem je detailní rozpracování a strukturování požadavků. Vstupem je aplikační slovník a existující externí zdroje (dokumenty, standardy, ontologie). Výstupem jsou diagramy tříd, diagramy aktivit a referenční výkladový slovník.

• Získání doménových zdrojů a tvorba doménového slovníku: Doménový slovník tvoří terminologie používaná v zájmové doméně, převážně získaná analýzou existujících externích dokumentových zdrojů, jako jsou zprávy, manuály, standardy, slovníky, tezaury a dostupné ontologie. Tvorba doménového i aplikačního slovníku může být podpořena automatizovanými nástroji pro text mining.
• Vytvoření referenčního slovníku: Sloučení vybraných termínů z aplikačního a doménového slovníku.
• Modelování aplikačních scénářů: Doplnění zpracovaných diagramů případů užití o UML diagramy aktivit a diagramy tříd.
• Vytvoření referenčního výkladového slovníku: Zpracování neformálních definic v přirozeném jazyce pro termíny zahrnuté v referenčním slovníku.

Fáze Návrh – cílem je vypracování ontologické struktury pro položky referenčního výkladového slovníku. Vstupem je referenční výkladový slovník a diagramy tříd a aktivit. Výstupem je sémantická síť a její převod do formátu ontologie.

• Modelování pojmů: Pro kategorizaci pojmů autoři nabízejí vlastní metodiku OPAL[22]. V průběhu konceptualizace se pojmy rozčlení do kategorií (aktéři, objekty, procesy, zprávy a atributy).
• Modelování hierarchických a doménově specifických vztahů: Při definování hierarchických vztahů je doporučen postup middle-out od nejfrekventovanějších pojmů k obecným a k specifickým. Základní generická taxonomie se doplní o další typy vztahů – agregace a asociace. Výsledná sémantická síť je graficky znázorněna UML diagramem tříd.

Fáze Implementace – cílem je zakódování ontologie do rigorózního formálního jazyka. Výstupem je ontologie v jazyce OWL.

• Výběr formálního jazyka: Zvažuje se vyjadřovací síla, výpočetní složitost usuzovací metody a akceptování jazyka v rámci dané komunity. Autoři doporučují jazyk OWL.
• Formalizace ontologie: Do formálního jazyka se převede množina definovaných pojmů, vztahy mezi pojmy a množina sémantických axiomů.

Fáze Testování – cílem je kontrola splnění požadavků na ontologii a posouzení sémantické a pragmatické kvality (užitečnosti pro uživatele) ontologie.

• Kontrola konzistence: Využití automatických kontrol provedených specializovaným softwarem (tzv. reasoner, např. Racer, Pellet), kontrolujícím správnost definovaných logických axiomů a pravidel (např. disjunktnost hierarchie).
• Verifikace pokrytí: Testuje se, zda je možné sémanticky anotovat zdroj spadající do aplikační domény s použitím pojmů obsažených v ontologii.
• Odpovědi na kompetenční otázky: Testuje se, zda je možné kompetenční otázky, zformulované ve fázi Požadavky, zodpovědět prostřednictvím obsahu ontologie.

Obr.13: UPON – členění na základní fáze

Obr.14: UPON – detailní členění fáze Požadavky

Obr.15: UPON – detailní členění fáze Analýza

Obr.16: UPON – detailní členění fáze Návrh

Obr.17: UPON – detailní členění fáze Implementace

Obr.18: UPON – detailní členění fáze Testování

3.6 Metodika tvorby tezauru

Určení, specifika: Na tvorbě metodik pro vytvoření tezaurů se od 70. let 20. století podílelo mnoho zástupců odborné veřejnosti a četné významné instituce: UNESCO, IFLA, ISO (technická komise ISO/TC 46 Information and documentation), národní standardizační instituce BSI a ANSI / NISO, na národní úrovni se věnovali už v rané fázi vývoje problematice tvorby tezaurů i odborníci z tehdejšího Československa[23], [24], [25], [26]. Autoritativním manuálem se stala příručka Thesaurus construction and use, kterou autoři Jean Aitchison, Alan Gilchrist a David Bawden v roce 2000 vydali již ve 4. vydání. Výstupy těchto aktivit v podobě publikovaných dokumentů mapuje v historickém přehledu tabulka 2. Jak naznačují postupné změny názvů, od původního striktního zaměření na návrh tezaurů se záběr rozšiřuje směrem k obecnějšímu pojetí, použitelnému pro širší spektrum typů řízených slovníků a jiných selekčních jazyků. Od roku 2008 připravuje subkomise SC 9 ISO/TC 46 Identification and description na základě BS 8723 novou verzi standardů ISO 2788:1986 a ISO 5964:1985 jako dvoudílnou normu číslo 25964[27], [28]. Očekává se, že tato norma přinese sjednocující pohled na pravidla a metody návrhu tezaurů a bude reflektovat změny, k nimž došlo zavedením informačních technologií do této oblasti (softwarové aplikace pro tvorbu a využívání tezaurů, technologie fulltextového vyhledávání ad.)

Tab.2: Historický přehled vývoje metodik pro tvorbu tezaurů

Klíčové fáze:

• Vymezení věcné oblasti: Vymezení obsahového zaměření tezauru. Určení jádra, které bude zpracováno nově a do hloubky, a okrajových oblastí, pro jejichž pokrytí mohou být využity existující tezaury nebo jejich části.
• Ověření duplicity: Průzkum existujících tezaurů zpravidla potvrdí, že pro zvolenou specifickou oblast zatím samostatný tezaurus neexistuje, ale v příbuzných oborech se najdou obsahové části, využitelné při tvorbě nového tezauru. Po přijetí rozhodnutí o vytvoření nového tezauru se doporučuje tento záměr zveřejnit.
• Určení struktury a formátu: Definování konstrukční architektury tezauru, založené na stanoveném způsobu jeho používání. Určení úrovně specifičnosti a lexikálního formátu termínů.
• Volba metody shromáždění termínů: Volí se mezi těmito přístupy: top-down / bottom-up, dedukce / indukce a jejich případná kombinace, a automatizovaná metoda (tj. identifikace kandidátních termínů v textech, sledování frekvence používání termínů při indexování dokumentů nebo v dotazech uživatelů).
• Zajištění interoperability: Výběr metody pro zajištění interoperability navrhovaného tezauru s již existujícími slovníky. Na výběr jsou metody derivace (odvozování z modelového zdroje), překlad / adaptace, satelitní slovníky (obdobné metodě derivace), přímé propojování prostřednictvím jednotlivých termínů, mapování, spojení prostřednictvím propojovacího slovníku.
• Výběr termínů: Zdrojem pro sběr termínů se mohou stát standardizované terminologické zdroje, analýza dotazů, excerpce textů, znalosti uživatelů a expertů a znalosti sestavovatelů tezauru.
• Strukturování: Návrh základních kategorií pro uspořádání vybraných termínů a jejich vzájemných vztahů. Volba pořádacího principu: a) podle oborů nebo tematických oblastí, b) podle faset, c) kombinovaný přístup – např. na nejvyšší úrovni podle tematických oblastí a v jejich rámci podle faset.
• Zaznamenání termínů: Pro každý termín se pořídí samostatný záznam, v němž se popíšou jeho vlastnosti a vztahy k ostatním termínům (ekvivalence, hierarchie, asociace). Tato fáze tedy zahrnuje i strukturování tezauru – analýzu a seskupování termínů v rámci stanovených kategorií.
• Verifikace termínů: Ověření správnosti termínu vzhledem k stanoveným pravidlům výběru, rozsahu a formy termínů a v autoritativních zdrojích (odborné slovníky, encyklopedie, existující tezaury a klasifikační schémata).
• Testování a hodnocení: Doporučuje se realizovat tuto fázi před zveřejněním tezauru a v pravidelných intervalech v průběhu jeho používání.
• Správa: Aktualizace a doplňování slovníku – přidávání nových termínů, modifikace existujících termínů, odstraňování nadužívaných nebo nepoužívaných termínů. Doporučuje se formalizovat návrhy na aktualizaci pomocí formulářů a veškeré provedené změny zaznamenávat v historických poznámkách, případně v odkazech.

Procesní graf (obrázek 19):

Obr.19: Metodika tvorby tezauru

3.7 Denton – Spiteri

Producent / autor: William Denton (York University of Toronto), Louise F. Spiteri (Dalhousie University, Halifax)
Rok vzniku / publikování: 1998 (Spiteri) / 2003 (Denton)

Určení, specifika: Metodika tvorby fasetové klasifikace pro publikování webového obsahu, určená pro malé a středně velké kolekce dokumentů. Východiskem jsou čtyři fáze tvorby fasetové klasifikace, jež v roce 1960 definoval Brian Campbell Vickery[51]. V metodice navržené Williamem Dentonem jsou uplatněny v pozměněném pořadí a doplněny o další tři fáze. Ústřední fáze – vytvoření a uspořádání faset, jsou založeny na zjednodušeném modelu fasetové analýzy, který vypracovala Louise Spiteri kompilací vybraných kánonů, postulátů a principů S. R. Ranganathana a principů fasetové analýzy zpracovaných Skupinou pro výzkum klasifikace (Classification Research Group – CRG). Ve vodopádovém životním cyklu se uplatňují četné prvky iterace.

Klíčové fáze:

• Shromáždění entit: Shromáždění reprezentativního vzorku entit pro danou doménu; u malých kolekcí je doporučeno zahrnout entity z celé domény.
• Popis entit: Vytvoření popisu jednotlivých entit. Sémantický rozklad popisů – rozdělení vět na části, přeuspořádání slov, rozpoznání základních pojmů v jednotlivých částech vět a jejich izolování.
• Vytvoření faset: Prozkoumání výsledných termínů a nalezení obecných kategorií na nejvyšší úrovni, vyskytujících se ve všech entitách. Omezení nalezených kategorií na množinu vzájemně se vylučujících a ve svém celku vyčerpávajících faset, použitelných pro všechny termíny vytvořené v předchozí fázi. Principy pro výběr faset:
• diferenciace – použité kritérium členění má vést k jasnému rozlišení jednotlivých částí
• relevance – zvolené fasety mají odpovídat účelu, předmětu a rozsahu klasifikace
• průkaznost (ascertainability) a permanence – fasety mají reprezentovat trvalé a měřitelné charakteristiky klasifikovaných objektů
• homogenita a disjunktnost – každá faseta smí reprezentovat pouze jednu charakteristiku členění
• základní kategorie mají být přizpůsobeny specifickým vlastnostem a kontextu klasifikovaných objektů
• Uspořádání faset: Naplnění faset termíny vytvořenými ve fázi Popis entit, tak aby bylo možné zatřídit všechny shromážděné entity. Uspořádání termínů uvnitř fasety podle zvoleného principu (abecední, hierarchický, chronologický ad.). Volba preferovaných termínů, tvorba řízeného slovníku.
• Určení pořadí faset: Rozhodnutí o standardním (defaultním) uvádění pořadí faset (např. na domovské stránce).
• Klasifikace: Zatřídění celého obsahu domény. Analýza všech entit za použití faset a použití správných termínů pro popis každé entity.
• Revize, testování, správa: Při jakýchkoli problémech zjištěných v etapě Klasifikace následuje iterace – návrat k předchozí fázi, jež je relevantní k vyřešení problému. Následuje uživatelské testování a pravidelná správa klasifikace (změna terminologie, nové entity, změny v doméně).

Procesní graf (obrázek 20):

Obr.20: Denton – Spiteri

Tab.3: Typologie metodik