Разработка онтологий 101: посібник з створенню Вашої першої онтології

Разработка онтологий 101: посібник з створенню Вашої першої онтологии[1].

Наталья Ф. Ной (Natalya F. Noy) і Дэбора Л. МакГіннесс (Deborah L. McGuinness).

Стэнфордский Університет, Стенфорд, Калифорния Онтологии стали центральними компонентами багатьох великих додатків, хоча навчальний матеріал відповідає дедалі глибшому інтересу. У роботі обговорюється питання, навіщо будувати онтологію, і пропонується методологія створення онтологий, заснована на системах уявлення декларативних знань. Вона використовує досвід двох авторів у будівництві й підтримки онтологий у низці онтологічних середовищ, включаючи Protege-2000, Ontolingua і Chimaera. У ньому представлена методологія з прикладу навчальної бази знань по винам. Попри те що, стаття адресована користувачам фреймовых систем, може бути корисна для побудови онтологий у будь-якій объектно-ориентированной системе.

1. Навіщо створювати онтологию?.

В останні роки розробка онтологий — формальних явних описів термінів предметної області й відносин з-поміж них — переходить зі світу лабораторій зі штучного інтелекту на робочі столи експертів по предметним областям. У світовому павутинні онтології стали звичним явищем. Онтології у мережі варіюються від великих таксономий, категоризирующих веб-сайти (як у сайті Yahoo!), до категоризаций які й товарів хороших і їх характеристик (як у сайті Amazon.com). Консорціум WWW (W3C) розробляє RDF (Resource Description Framework), мову кодування знань на веб-сторінках, у тому, щоб зробити їх зрозумілими для електронних агентів, які проводять пошук інформації. Управління перспективних досліджень, і розробок Міністерства оборони США (The Defense Advanced Research Projects Agency, DARPA) в співробітництво з W3C розробляє Мова Розмітки для Агентів DARPA (DARPA Agent Markup Language, DAML), розширюючи RDF більш виразними конструкціями, призначеними полегшення взаємодії агентів у мережі. Багато дисциплінах зараз розробляються стандартні онтології, які можуть використовуватися експертами по предметним областям для спільного використання коштів і аннотирования інформацією своїй сфері. Наприклад, у сфері медицини створено великі стандартні, структуровані словники, такі як snomed і семантична мережу Системи Уніфікованого Медичного Язика (the Unified Medical Language System). Також з’являються великі общецелевые онтології. Наприклад, Програма ООН в розвитку (the United Nations Development Program) і компанія Dun & Bradstreet об'єднало зусилля і розробити онтології UNSPSC, що надає термінологію товарів та послуг (internet.

Онтология визначає загальний словник науковцям, яким треба разом використовувати інформацію в предметної області. Вона містить машинно-интерпретируемые формулювання основних понять предметної області й відносини з-поміж них.

Почему виникає потреба у розробці онтології? Ось лише деякі причины:

Для спільного використання особами чи програмними агентами спільного розуміння структури информации.

Для можливості повторного використання знань у предметної області .

Для здобуття права зробити припущення в предметної області явными.

Для відділення знань у предметної області від оперативних знаний.

Для аналізу знань у предметної области.

Совместное використання особами чи програмними агентами спільного розуміння структури інформації є одним із найзагальніших цілей розробки онтологий. Приміром, нехай, кілька різних веб-сайтів містять інформацію з медицині чи надають інформацію про платних медичних послугах, оплачуваних через Інтернет. Якщо такі веб-сайти спільно використовують і публікують те ж базову онтологію термінів, якими вони всі користуються, то комп’ютерні агенти можуть видобувати інформацію з цих різних сайтів й накопичувати її. Агенти може використати накопичену інформацію для відповіді запити користувачів чи як вхідні дані для інших приложений.

Обеспечение можливості використання знань предметної області поменшало одній з рушійних сил недавнього сплеску до вивчення онтологий. Наприклад, для моделей багатьох різних предметних областей необхідно сформулювати поняття часу. Цю виставу включає поняття тимчасових інтервалів, моментів часу, відносних заходів часу й т.д. Якщо одна група учених детально розробить таку онтологію, то інші можуть просто повторно використовувати їх у своїх предметних областях. З іншого боку, якщо треба створити велику онтологію, ми можемо інтегрувати кілька існуючих онтологий, що описують частини великий предметної області. Ми також можемо повторно використовувати основну онтологію, таку, як UNSPSC, й розширити її для описи цікавій для нас предметної области.

Создание явних допущень в предметної області, лежачих основу реалізації, дає можливість легко змінити ці припущення при зміні наших знання предметної області. Жорстке кодування припущень про мир мовою програмування призводить до того, що це припущення не лише важко знайти і зрозуміти, а також складно змінити, особливо непрограммисту. З іншого боку, явні специфікації знань у предметної області корисні нових користувачів, які мають дізнатися значення термінів предметної области.

Отделение знань предметної області від оперативних знань — це іще одна варіант загального застосування онтологий. Ми можемо описати завдання конфигурирования продукту з його компонентів відповідно до необхідної спецификацией і впровадити програму, що робить цю конфігурацію незалежної від продукту та тіла компонентів. Після цього ми можемо розробити онтологію компонентів і характеристик ЕОМ і застосувати цей алгоритм для конфигурирования нестандартних ЕОМ. Ми також можемо використати хоча б алгоритм для конфигурирования ліфтів, коли ми надамо йому онтологію компонентів лифта.

Анализ знань у предметної області може бути, коли є декларативна специфікація термінів. Формальний аналіз термінів надзвичайно цінний як із спробі використання існуючих онтологий, і за її расширении.

Часто онтологія предметної області як така не мета. Розробка онтології на кшталт визначенню набору даних, і їх структури від використання іншими програмами. Методи вирішення завдань, доменно-независимые докладання й програмні агенти використовують як даних онтології та фінансової бази знань, побудовані з урахуванням цих онтологий. До прикладу, у цій статті ми розробляємо онтологію вин і їжі, і навіть підходящі комбінації вин і страв. Потім цю онтологію можна використовувати є основою для додатків у наборі інструментів керувати рестораном: Одне додаток міг би складати список вин для меню сучасний день чи відповідати на запити офіціантів і відвідувачів. Інше додаток міг би аналізувати інвентарний перелік винного льохи і пропонувати категорії вин поповнення і виробити конкретні вина для закупівлі до наступним меню або заради поварених книг.

Об цьому руководстве

Мы опираємося на нашому досвіді використання Protege-2000, Ontolingua, Chimaera як середовищ для редагування онтологий. У цьому вся керівництві нашим прикладів ми використовуємо Protege-2000.

Пример провина, і їжі, який ми використовуємо протягом всієї статті, зроблено за основі з приблизною бази знань, представленої в статті, яка описує CLASSIC — систему уявлення знань, засновану на описательно-логическом підході. У навчальному посібнику по CLASSIC цей приклад отримав розвиток. Protege-2000 і інші фреймові системи описують онтології декларативним чином, визначаючи явно, як і класова ієрархія і яких класам належать индивидные концепти.

Некоторые ідеї розробці онтологий у тому керівництві беруть своє керівництво у літературі по объектно-ориентированному проектування. Проте розробка онтологий відрізняється від проектування класів та взаємин у объектно-ориентированном програмуванні. Объектно-ориентированное програмування зосереджується головним чином методах класів — програміст приймає проектні рішення, засновані на операторных властивості класу, тоді як розробник онтології приймає ці рішення, виходячи з структурних властивості класу. Через війну структура класу тут і відносини між класами в онтології від структури як і предметної області у объектно-ориентированной программе.

Невозможно охопити всі труднощі, які, можливо, доведеться подолати розробникові онтології, й у керівництві ми намагаємося торкнутися їх усіх. Ми ж намагаємося дати відправну точку, вихідне керівництво, яка могла б допомогти недосвідченому проектувальнику онтологий у тому розробці. Наприкінці ми пропонуємо джерела, у яких можна подивитися пояснення до складнішим структурам і механізмам розробки, якщо вони знадобляться для предметної области.

В кінцевому підсумку, єдиною правильної методології розробки онтологий немає, і ми намагалися визначити таку. Подані тут ідеї ми ми вважаємо корисними, з нашого досвіду розробки онтологий. Наприкінці нинішнього керівництва ми пропонуємо список посилань на альтернативні методологии.

2. З чого полягає онтология?.

В літератури з штучного інтелекту міститься багато визначень поняття онтології, чимало з яких суперечать одна одній. У статті онтологія — формальне явне опис понять в аналізованої предметної області (класів (іноді їх називають поняттями)), властивостей кожного поняття, що описують різні своства і атрибути поняття (слотів (іноді їх називають ролями чи властивостями)), та, накладених на слоты (фацетов (іноді їх називають обмеженнями ролей)). Онтологія разом із набором індивідуальних примірників класів утворює базу знань. Насправді, важко визначити, де закінчується онтологія і починається база знань.

В центрі більшості онтологий перебувають класи. Класи описують поняття предметної області. Наприклад, клас вин представляє все вина. Конкретні вина — екземпляри цього. Вино Bordeaux в келиху перед вами, як ви читаєте цей документ ще, — це примірник класу вин Bordeaux. Клас може мати підкласи, які мають конкретніші поняття, ніж надкласс. Наприклад, ми можемо розділити клас всіх вин на червоні, білі і рожеві вина. Як альтернативу ми можемо розділити клас всіх вин на ігристі і не ігристі вина.

Слоты описують властивості класів та примірників: вино Chвteau Lafite Rothschild Pauillac — міцне, вона виробляється на винному заводі Chвteau Lafite Rothschild. Ми маємо два слота, які описують вино — в цьому прикладі: слот фортеця багатозначно «міцне» і слот виробник багатозначно «винний завод Chвteau Lafite Rothschild». Ми можемо сказати, що лише на рівні класу в примірників класу Вино є слоты, які описують смак, фортеця, рівень цукру, виробника провина, і т.д. 1].

Все екземпляри класу Вино та її підклас Pauillac мають слот виробник, значення є примірником класу Винний завод (Рис. 1). Усі екземпляри класу Винний завод мають слот виробляє, що входить всім винам (екземплярам класу Вино та її підкласів), які виробляються у цьому заводе.

На практиці розробка онтології включает:

определение класів в онтологии;

расположение класів в таксономическую ієрархію (підклас — надкласс);

определение слотів і опис що допускаються значень цих слотов;

заполнение значень слотів экземпляров.

После цього ми можемо створити базу знань, визначивши окремі екземпляри цих класів, запровадивши у визначений слот значення і додаткових обмежень для слота.

.

Рис. 1. Деякі класи у сфері вин, екземпляри і відносини з-поміж них. Чорним ми позначили класи, а червоним — екземпляри. Прямі зв’язку позначають слоты та внутрішні зв’язку, такі як «примірник [класу]» і «підклас [класу]».

3. Проста методологія інженерії знаний.

Как ми сказали вище, немає єдиного «правильного» способу чи методології розробки онтологий. Тут ми обговорюємо загальні моменти, які слід урахувати, і пропонуємо одне із можливих способів розробки онтології. Ми наводимо ітеративний підхід до розробки онтології: ми починаємо з першого чорнового перегляду онтології. Потім ми перевіряємо і уточнюємо отримувану онтологію і додаємо деталі. Попутно ми обговорюємо рішення, що стосуються моделювання, які має вжити розробник, і навіть «за» і «проти» і вивести результати прийняття різних решений.

Во-первых, ми б виділити деякі фундаментальні правила розробки онтології, яких ми будемо неодноразово звертатися. Ці правила можуть досить категоричними. Проте, у часто можуть допомогти прийняти проектні решения.

1) Немає єдиного правильного способу моделювання предметної області - завжди існують життєздатні альтернативи. Краще рішення майже залежить від можливого докладання і очікуваних расширений.

2) Розробка онтології - це обов’язково ітеративний процесс.

3) Поняття в онтології мали бути зацікавленими близькі до об'єктів (фізичним чи логічним) і відносинам в цікавій для вас предметної області. Найімовірніше, це іменники (об'єкти) чи дієслова (відносини) в пропозиціях, які описують вашу предметну область.

То є, знання того, навіщо ви маєте намір використовувати онтологію і, як детальної чи загальної вона, стимулюватиме багато рішень, що стосуються моделювання. Серед кількох життєздатних альтернатив ми мусимо визначити, яка допоможе краще вирішити поставлену завдання й буде більше унаочнюється, більш розширюваної і простіший в обслуговуванні. Нам також слід пам’ятати, що онтологія — це модель реального світу й поняття в онтології мають відображати цю реальність. Потому, як ми визначимо початкову версію онтології, ми можемо оцінити й налагодити її, використовуючи їх у додатках чи методах вирішення завдань і/або обговоривши її з експертами предметної області. Відтак напевно ми мусимо буде переглянути початкову онтологію. Цей процес відбувається итеративного проектування, мабуть, буде тривати протягом усього життєвого циклу онтологии.

Шаг 1. Визначення області й масштабу онтологии.

Мы пропонуємо розпочати розробку онтології з визначення її ділянці і масштабу. Тобто, відповімо сталася на кілька основних вопросов:

Какую область охоплюватиме онтология?

Для чого ж ми використовуватимемо онтологию?

На які типи питань має давати відповіді інформація в онтологии?

Кто активно використовуватиме підтримувати онтологию?

Ответы ці запитання можуть змінитися під час процесу проектування онтології, але у будь-який поставлене час вони допомагають обмежити масштаб модели.

Рассмотрим онтологію провина, і їжі, що її представили раніше. Область нашої онтології - уявлення їжі вин. Ми використовуватимемо цю онтологію для додатків, які пропонувати хороші поєднання вин і еды.

Конечно, наша онтологію будуть включені поняття, описують різні типи вин, основні види їжі, поняття доброго та поганого поєднання провина, і їжі. У той самий час, малоймовірно, що онтологія включатиме поняття керувати інвентарем на винному заводі які у ресторані, навіть хоча ці поняття почасти пов’язані з поняттями провина, і еды.

Если онтологія, що її проектуємо, буде використовуватися на допомогу при обробці природної мови статей у товстих часописах про винах, то, можливо, знадобиться включити в онтологію синонімів понять і інформації про частини мови. Якщо онтологія використовуватиметься здобуття права допомогти відвідувачам ресторану вирішити, яке вино замовити, ми мусимо буде включити інформацію про роздрібні ціни. Якщо вона використовуватися на допомогу покупцям винні у створенні запасів у винному льосі, можуть знадобитися відомостей про оптових цінах про наявність вин. Якщо людей, які підтримувати онтологію, опишуть предметну область мовою, відрізняється від мови користувачів онтології, вона може знадобитися надати таблицю відповідностей між языками.

Вопросы для перевірки компетентности

Один із засобів визначити масштаб онтології - це накидати список питань, куди має відповісти база знань, заснована на онтології, тобто. питання перевірки компетентності. Це питання служитимуть лакмусовим папірцем: Містить чи онтологія досить інформації для відповіді ці типи питань? Потрібна з відповідей особливий рівень деталізації чи уявлення певної області? Це питання для перевірки компетентності є лише формальними і би мало бути исчерпывающими.

В області провина, і їжі можливі такі питання перевірки компетентности:

1. Які характеристики вина мені треба враховувати при виборі вина?

2. Вино Bordeaux червоне чи белое?

3. Чи добре поєднується Cabernet Sauvignon з морськими продуктами?

4. Яке вино найкраще підійде до смаженій мясу?

5. Які характеристики вина впливають з його сполучуваність з блюдом?

6. Чи з рік виробництва вина на його букет чи крепость?

7. Які врожаї Napa Zinfandel були хорошими?

Судя у цій списку питань, онтологія буде включати інформацію про різноманітні характеристиках провина, і типах вин, роках виробництва вин (гарних манер і поганих), класифікаціях їжі, потрібно врахувати під час виборів підходящого вина, які рекомендуються поєднаннях провина, і еды.

Шаг 2. Розгляд варіантів використання існуючих онтологий.

Почти слід врахувати, що зробив хтось ще, і перевірити, можемо ми поліпшити й розширити існуючі джерела нашій конкретної предметної області й завдання. Повторне використання існуючих онтологий то, можливо необхідним, якщо системі потрібно взаємодіяти з іншими додатками, у яких увійшли до окремі онтології чи контрольовані словники. Багато онтології вже доступні в електронному вигляді й може бути імпортовані в що використовується Вами середу проектування онтології. Формалізм онтології часто вже не має значення, т.к. багато системи уявлення знань можуть й експортувати онтології. Навіть якщо його система уявлення знань неспроможна працювати прямо пов’язана з окремим формалізмом, завдання перекладу онтології вже з формалізму на другий звичайно є сложной.

В літератури і світовому павутинні існують бібліотеки повторно використовуваних онтологий. Наприклад, ми можемо використати бібліотеку онтологий Ontolingua (internet чи бібліотеку онтологий DAML (internet Існує й ряд загальнодоступних комерційних онтологий (наприклад, UNSPSC (internet RosettaNet (internet DMOZ (internet.

К прикладу, база знань по французьким винам вже існувати. Якщо ми можемо імпортувати цю базу знань і онтологію, на якої основана, те в нас як класифікація французьких вин, а й перший крок класифікації характеристик вин, використовуються для розділення бізнесу і описи вин. Списки властивостей вина вже може бути доступні на комерційних веб-сайтах, як-от internet які клієнти використовують для придбання вин.

Тем щонайменше, у тому керівництві вважатимемо, що відповідних онтологий що немає, й почнемо розробляти онтологію з нуля.

Шаг 3. Перерахування важливих термінів в онтологии.

Полезно скласти список всіх термінів, ми хотіли б сказати щось чи котрі хотів би пояснити користувачеві. Які терміни ми б розглянути? Які властивості мають ці терміни? Що ми б хотіли сказати про ці термінах? Наприклад, до важливих термінів, що з винами, входять вино, виноград, винний завод, місце розташування, колір вина, його фортеця, смак і змістом цукру; різні види їжі, такі як риба і чорне м’ясо; типи вина, такі як біле вино тощо. На початку важливо здобути цілковитий список термінів, не турбуючись перетині понять, які представляють, про відносини між термінами, про можливі властивості понять чи те, ніж є поняття — класами чи слотами.

Следующие два кроку — розробка ієрархії класів та визначення властивостей понять (слотів) — тісно переплетені. Складно виконати спочатку них, і потім — інший. Зазвичай, у ієрархії ми даємо кілька формулювань понять і далі описуємо властивості цих понять тощо. Також ці два кроку — найважливіші кроки у процесі проектування онтології. Тут ми опишемо їх коротенько, потім у наступних двох розділах розглянемо складніші проблеми, які треба прийняти до уваги, часто які труднощі, рішення, яких треба вжити, і т.д.

Шаг 4. Визначення класів та ієрархії классов.

Существует кілька можливих підходів і розробити ієрархії классов:

Процесс низхідній розробки починається з визначення найзагальніших понять предметної області із наступною конкретизацією понять. Наприклад, ми можемо розпочати зі створення класів для загальних понять Вино і Єда. Потім ми конкретизуємо клас Вино, створюючи його підкласи: Біле вино, Червоне вино, Рожева вино. Ми можемо ще категоризировать клас Червоне Вино, наприклад, в Syrah, Red Burgundy, Cabernet Sauvignon і т.д.

Процесс висхідній розробки починається з визначення самих конкретних класів, листя ієрархії, із наступною угрупованням цих класів на більш загальні поняття. Наприклад, спочатку ми визначаємо класи для вин Pauillac і Margaux. Потім ми створюємо загальний надкласс обох цих класів — Medoc, який, своєю чергою є подклассом Bordeaux.

Процесс комбінованої розробки — це поєднання спадного і вранішнього підходів: Спочатку ми визначаємо більш помітні поняття, та був відповідним чином узагальнюємо і обмежуємо їх. Ми мали б розпочати з понять вищого рівня, як-от Вино, і знання кількох конкретних понять, як-от Margaux. Потім ми можемо співвіднести його з поняттям середнього рівня, таких як Medoc. Після цього нам може знадобитися сформувати все класи вин в галузі Франції, формуючи в такий спосіб ряд понять середнього уровня.

На рис. 2 показано можливе розподіл різні рівні узагальнення.

.

Рис. 2. Різні рівні таксономії Вино: Вино, Червоне вино, Біле вино, Рожева вино — загальніші поняття, верхній рівень. Pauillac і Margaux — самі конкретні класи в ієрархії, нижній уровень.

Ни із цих трьох методів не краще за інших зі своєї суті. Вибір підходу значною мірою залежить від власного погляду предметну область. Якщо розробник схильний до розгляду предметної області згори вниз, йому, можливо, личитиме краще спадний метод. Часто багатьом розробників онтологий найпростішим є комбінований метод, т.к. поняття, які перебувають «посередині», мають тенденцію бути дуже наочними поняттями в предметної области.

Если ви схильні робити спочатку саму загальну класифікацію вин, то, вам личитиме краще спадний метод. Якщо ви хоч б розпочали приводити конкретні приклади, то кращим є висхідний метод.

Какой метод ми ні обрали, зазвичай ми починаємо з визначення класів. Із списку, складеного в Кроці 3, ми вибираємо терміни, які описують об'єкти, існуючі незалежно, а чи не терміни, які описують ці об'єкти. У онтології ці терміни будуть класами заходяться точками прив’язки в ієрархії классов[2]. Ми організуємо класи в ієрархічну таксономию, формулюючи так запитання: якщо об'єкт є примірником одного класу, чи він буде обов’язково (тобто. по визначенню) примірником деякого іншого класса?

Если клас, А — надкласс класу У, то кожен примірник У є також примірником А.

Другими словами, клас У є поняття, що є «різновидом» А.

Например, кожне вино Pinot Noir — обов’язково червоне вино. Тому клас Pinot Noir — підклас класу Червоне вино.

На рис. 2 показано частина ієрархії класів онтології по винам. У 4-й главі детально розглянуто, що слід шукати щодо ієрархії классов.

.

Рис. 3. Слоты класу Вино і фацеты цих слотів. Значок «I» поруч із слотом виробник вказує, що з слота є слот (Глава 5.1.).

Шаг 5. Визначення властивостей класів — слотов

Классы власними силами не надають досить інформації для відповіді питання перевірки компетентності з Кроку 1. Після визначення певної кількості класів ми повинні описати внутрішню структуру понятий.

Мы вже вибрали класи зі списку термінів, який ми створили на Кроці 3. Більшість решти термінів, мабуть, будуть властивостями цих класів. Ці терміни включають, приміром, колір вина, його фортеця, смак і вміст цукру, і навіть місце розташування винного заводу.

Для кожного властивості зі списку ми повинні визначити, який клас воно описує. Ці властивості стануть слотами, прив’язаними до класам. Отже, у класу Вино будуть такі слоты: колір, фортеця, смак і цукор. У класу Винний завод буде слот местоположение.

Вообще, в онтології слотами можуть бути кілька типів властивостей объектов:

«внутренние» властивості, такі як смак вина;

«внешние» властивості, такі як назва провина, і область, у якій вона було произведено;

части, якщо об'єкт має структуру; є підстави як фізичними, і абстрактними «частинами» (наприклад, страви, що входять до обед);

отношения коїться з іншими индивидными концептами; це відносини між окремими членами класу тут і іншими елементами (наприклад, виробник вина, що становить ставлення між вином і винним заводом, і виноград, з яких вироблено вино).

Таким чином, на додаток до раніше певним властивостями, до класу Вино ми мусимо додати такі слоты: назва, область, виробник, виноград. На рис. 3 показані слоты класу Вино.

Все підкласи класу успадковують слот цього. Наприклад, все слоты класу Вино будуть успадковані усіма подклассами цього класу, включаючи Червоне Вино і Біле Вино. До класу Червоне Вино ми додамо додатковий слот рівень таніну (низький, середній чи високий). Слот рівень таніну буде успадкований усіма класами, котрі представляють червоні вина (такі як Bordeaux і Beaujolais).

Слот може бути прив’язаний до самого загальному класу, яка має то, можливо дане властивість. Наприклад, міцність і колір вина потрібно буде прив’язати до класу Вино, т.к. це найбільш загальний клас, чиї екземпляри матимуть міцність і цвет.

Шаг 6. Визначення фацетов слотов

Слоты може мати різні фацеты, які описують тип значення, дозволені значення, число значень (потужність) та інші властивості значень, що може приймати слот. Наприклад, значення слота назва (як в «назва вина») — один рядок. Тобто, назва — це слот з типом значення Рядок. Слот виробляє (як і вираженні «винний завод виробляє ці вина») може мати множинні значення, що є екземплярами класу Вино. Тобто, виробляє - це слот з типом значення Примірник, і дозволеним класом є Вино.

Сейчас ми опишемо кілька загальних фацетов.

Мощность слота

Мощность слота визначає, скільки значень може мати слот. У деяких системах різняться лише одинична потужність (можна тільки одне значення) і множинна потужність (можливо будь-яке число значень). Фортеця провина не буде слотом одиничної потужності (вино може мати тільки один фортеця). Провина, вироблені конкретному заводі, заповнюють слот множинної потужності виробляє класу Винний завод.

Некоторые системи дозволяють визначити мінімальну і максимальну потужність у тому, щоб точніше описати кількість значень слота. Мінімальна потужність N означає, що слот повинен мати щонайменше N значень. Наприклад, слот виноград класу Вино має мінімальну потужність 1: кожне вино робиться, принаймні, вже з сорти винограду. Максимальна потужність М означає, що слот може мати максимум М значень. Максимальна потужність слота виноград для вин вже з сорти винограду дорівнює 1. Іноді корисно встановити максимальну потужність в 0. Ця установка означатиме, що з певного підкласу слот неспроможна мати значений.

Тип значення слота

Фацет типу значення описує, які типи значень можна вводити на слот. Ось список найзагальніших типів значений:

Строка — найпростіший тип значення, який використовують у таких слотах, як назва: значенням є проста строка.

Число (іноді використовуються конкретніші типи значень: Float (Кількість з плаваючою коми) і Integer (Ціле число)) описує слоты числовими значеннями. Наприклад, вартість вина може мати тип Float.

Булевы слоты — це прості прапори «так — немає». Наприклад, коли ми нічого очікувати представляти ігристі вина як клас, то належність до ігристим винам то, можливо показано значенням булевого слота: якщо значення «істина» («так»), то вино гристе, і якщо значення «брехня» («немає»), то вино не игристое.

Нумерованные слоты визначають список конкретних дозволених значень слота. Наприклад, ми можемо встановити, що слот смак може прийняти 1 із 3 можливих значень: сильний, помірний лагідний. У Protege-2000 нумеровані слоты мають тип Символ.

Слоты-экземпляры дозволяють визначити відносини між индивидными концептами. Слоты з типом значення Примірник також має визначати список дозволених класів, екземпляри яких можна використовувати. Наприклад, слот виробляє класу Винний на заводі ролі значень може мати екземпляри класу Вино[3].

На рис. 4 показано визначення слота виробляє класу Винний завод.

.

Рис. 4. Визначення слота виробляє, який описує вина, вироблені винному заводі. Слот має множинну міць і значення типу Примірник.

Разрешенным класом для значень цього слота є клас Вино.

Домен слота і діапазон значень слота

Разрешенные класи для слотів типу Примірник часто називають діапазоном значень слота. У прикладі на рис. 4 клас Вино є діапазоном значень слота виробляє. Деякі системи дозволяють обмежити діапазон значень слота, якщо слот прив’язаний до якогось классу.

Классы, яких слот прив’язаний, чи класи, властивість яких слот описує, називаються доменом слота. Клас Винний завод — домен слота виробляє. У системах, куди ми прив’язуємо слоты до класам, домен слота зазвичай становлять класи, яких прив’язаний слот. Не треба окремо визначати домен.

Основные правила визначення домену слота і діапазону значень слота схожі друг з другом:

При визначенні домену чи діапазону значень слота знайдіть найбільш загальні класи чи клас, які можна відповідно доменом чи діапазоном значень слотов.

С з іншого боку, не визначайте занадто загальний домен і діапазон значень: все класи в домені слота мають бути описані слотом, а екземпляри всіх класів буде в діапазоні значень слота мають бути потенційними заповнювачами слота. Не вибирайте занадто загальний клас для діапазону значень (тобто, ви захочете робити THING діапазоном значень, а захочете вибрати клас, який все заполнители.).

Вместо здобуття права перелічити всі можливі підкласи класу Вино для діапазону значень слота виробляє, просто внесіть до списку клас Вино. У той самий час, ми мусимо визначати діапазон значень слота як THING (найзагальніший клас, у онтологии).

Конкретнее:

Если список класів, визначальних діапазон значень слота чи домен слота, включає клас" і його підклас, приберіть подкласс.

Если діапазон значень слота містить і клас Вино, і клас Червоне Вино, ми можемо видалити Червоне Вино з діапазону значень, т.к. не додає нову інформацію: Червоне Вино — це підклас класу Вино, і тому діапазон значень слота вже неявно включає його, як і й інші підкласи класу Вино.

Если список класів, визначальних діапазон значень слота чи домен слота, охоплює всі підкласи класу А, але з включає сам клас Бо ж у діапазон значень має входити лише клас А, а чи не його подклассы.

Вместо вказівки те, що діапазон значень слота включає Червоне Вино, Біле Вино і Рожева Вино (перерахування всіх прямих підкласів класу Вино), ми можемо обмежити діапазон значень самим класом Вино.

Если список класів, визначальних діапазон значень слота чи домен слота, включає майже всі підкласи класу А, подумайте, може, визначення діапазону значень краще підійде клас А.

В системах, де прив’язка слота до класу рівнозначна додаванню класу до домену слота, до прив’язки слота застосовуються самі правила: З одного боку, ми мусимо постаратися зробити його максимально загальним. З з іншого боку, ми повинні гарантувати, кожен клас, куди ми прив’язуємо слот, насправді уміє, яка представляє слот. Ми можемо прив’язати слот рівень таніну до кожного класу, який представляє червоні вина (наприклад, Bordeaux, Merlot, Beaujolais і т.д.). Проте, т.к. все червоні вина часто мають здатність «рівень таніну», то натомість ми мусимо прикріпити цей слот до більш загальному класу Червоні Провина. Буде неправильно далі узагальнювати домен слота рівень таніну (прив'язка його до класу Вино), т.к. ми використовуємо рівень таніну для описи, приміром, білих вин.

Шаг 7. Створення экземпляров

Последний крок — це створення окремих примірників класів в ієрархії. Для визначення окремого примірника класу потрібно (1) вибрати клас, (2) створити окремий примірник цього і (3) запровадити значення слотів. Наприклад, ми можемо створити окремий примірник Chateau-Morgon-Beaujolais до подання певного типу вина Beaujolais. Chateau-Morgon-Beaujolais — це примірник класу Beaujolais, що представляє всі вина Beaujolais. Це примірника визначено такі значення слотів (рис. 5):

Крепость: Легкое Цвет: Красный Вкус: Мягкий Уровень таніну: Низкий Виноград: Gamay (примірник класу Виноград виготовлення вин) Производитель: Chateau-Morgon (примірник класу Винний завод) Область: Beaujolais (примірник класу Винна область) Сахар: Сухое.

.

Рис. 5. Визначення примірника класу Beaujolais. Примірником є вино Chateua Morgon Beaujolais в галузі Beaujolais, виробленої з винограду Gamay заводу Chateau Morgon. Воно легке, з м’яким смаком, червоне, з низьким рівень таніну. Це сухе вино.

4. Визначення класів та ієрархії классов

У цьому главі говориться у тому, заради чого слід уважно стежити, про помилки, які легко зробити за визначенні класів та ієрархії класів (Крок 4 з Глави 3). Як ми вже говорили раніше, для будь-який предметної області немає єдиною правильної ієрархії класів. Ієрархія залежить від його можливих способів застосування онтології, рівня деталізації, який буде необхідний докладання, особистих уподобань і іноді від вимог щодо сумісності коїться з іншими моделями. Проте, ми розглядаємо кілька керівних принципів, які слід урахувати при розробці ієрархії класів. Після визначення значної кількості нових класів корисно зупинитися і перевірити, чи що виникає ієрархія цим керівним принципам.

4.1. Забезпечення правильності ієрархії классов

Отношение «is-a"[2].

Иерархия класів представляє ставлення «is-a»: клас, А — це підклас У, якщо кожне примірник У є також примірником А. Наприклад, Chardonnay — підклас класу Біле Вино. Інший спосіб підходи до таксономическому відношенню — цей показник «kind-of"[3]: Chardonnay -вид Білого вина. Реактивний лайнер -вид літака. М’ясо -вид еды.

Подкласс класу представляє поняття, що є «різновидом» поняття, подається надклассом.

Отдельно взяте вино перестав бути подклассом всіх вин Распространенная помилка під час моделювання — це включення до ієрархію варіанта однієї й тієї самого поняття як і єдиному, так й у множині, зробивши перше подклассом другого. Наприклад, буде неправильно визначити клас Провина і клас Вино як підклас класу Провина. Як лише починаєте вважати, що ієрархія є ставлення «kind-of», то помилка під час моделювання очевидна: окреме Вино перестав бути виглядом Вин. Найкращий засіб уникнути таких помилок — завжди використовувати імена класів чи єдиному, чи у множині (присвоювання імен поняттям докладно розглянуто в Главі 6).

Транзитивность ієрархічних відносин

Отношение підкласу транзитивно:

Если У — це підклас А, а З — підклас У, то З — підклас А.

Например, ми можемо визначити клас Вино, і потім визначити клас Біле вино як підклас класу Вино. Потім ми визначаємо клас Chardonnay як підклас класу Біле Вино. Транзитивность відносини підкласу означає, що клас Chardonnay є також подклассом класу Вино. Іноді ми розрізняємо прямі й опосередковані підкласи. Прямий підклас — найближчий підклас класу: в ієрархії між класом, і його прямим подклассом немає інших класів. Тобто, між класом, і його прямим надклассом в ієрархії немає інших класів. У прикладі Chardonnay — це прямий підклас класу Біле вино і прямий підклас класу Вино.

Развитие ієрархії класів.

Поддержание послідовної ієрархії класів може викликати складності тоді, як розвиваються предметні області. Наприклад, багато років значиться все вина Zinfandel були червоними. Тому ми визначаємо клас вин Zinfandel як підклас класу Червоне вино. Проте, виробники вин іноді почали вичавлювати виноград й одразу видаляти цветообразующие речовини з винограду, змінюючи в такий спосіб колір одержуваного вина. Тож ми отримуємо «біле Zinfandel» рожевого кольору. Тепер ми мусимо розбити клас Zinfandel на 2 класу zinfandel — Біле zinfandel і Червоне zinfandel — і класифікувати їх як підкласи класів Рожева вино і Червоне вино соответственно.

Классы та його імена.

Важно розрізняти клас" і його имя:

Классы представляють поняття предметної області, а чи не слова, що означують ці поняття.

Имя класу може змінитися, коли ми виберемо іншу термінологію, але термін представляє об'єктивну реальність світу. Наприклад, ми можемо створити клас Shrimps, а потім перейменувати їх у Prawns — клас представляє усе ж поняття. Провина, які перебували до харчем з shrimp, повинні підходитимемо харчем з prawn[4] .

В дійсності треба постійно дотримуватися правил:

Синонимы однієї й тієї самого поняття уявити не можуть різні класи.

Синонимы — лише різні імена поняття чи терміна. Отже, не має бути десь із класу ім'ям Shrimp і водночас із цим десь із класу ім'ям Prawn, і навіть десь із класу ім'ям Crevette[5]. Краще буде мати один клас безпосередньо з ім'ям Shrimp чи Prawn. Багато системи дозволяють асоціювати з класом список синонімів, перекладів чи імен уявлення. Якщо цю систему Демшевського не дозволяє здійснювати такі асоціації, то синоніми можна перерахувати в документації до классу.

Избежание циклів класів.

Нам слід уникати циклів у ієрархії класів. Ми говоримо, що у ієрархії є цикл, коли в деякого класу, А підклас У й те водночас У — це надкласс А. Створення такого циклу в ієрархії рівнозначний оголошенню те, що класи Проте й У еквівалентні: всі екземпляри, А — це екземпляри У, проте екземпляри У також є екземплярами А. Справді, оскільки У — підклас Бо всі екземпляри У би мало бути екземплярами класу А. Оскільки, А — підклас У, то ми все екземпляри До того ж мали бути зацікавленими екземплярами класу В.

4.2. Аналіз узлов-братьев в ієрархії классов

Узлы-братья в ієрархії класів.

Узлы-братья в ієрархії - це класи, що є прямими подклассами однієї й тієї ж самого класу (див. Розділ 4.1).

Все узлы-братья в ієрархії (крім, які перебувають в корені) повинні розташовуватися одному рівні узагальнення.

Например, Біле вино і Chardonnay нічого не винні бути подклассами однієї й тієї ж класу (скажімо, класу Вино). Біле вино — більш загально поняття, ніж Chardonnay. Узлы-братья повинні представляти поняття, що є «в одній лінії», як і розділи рівня у книзі має перебувати одному рівні узагальнення. У цьому вся сенсі вимоги до ієрархії класів нагадують вимоги до структури книжки.

Однако поняття, що у корені ієрархії (і який завжди представлені як прямі підкласи деякого самого загального класу, такого як Thing), представляють основні розподілу в предметної області й нічого не винні бути схожими понятиями.

Что називати «занадто багато», що — «замало»?

Не існує жорстких правил про те, скільки прямих підкласів повинен мати клас. Проте, у багатьох онтологиях з чіткою структурою є від двох до дюжини прямих підкласів. Звідси два керівних принципу:

Если клас має сенс тільки один прямий підклас, то, можливо, під час моделювання допущено помилку чи онтологія неповна.

Если цього класу є більш дюжини підкласів, то, можливо, необхідні додаткові проміжні категорії.

Первое правило схоже правило набору тексту, де говориться, що з маркованого тексту будь-коли має бути лише одна маркіроване точка. Наприклад, більшість червоних бургундських вин — це Cфtes d’Or. Припустимо, що ми хотіли подати лише цей основний тип бургундських вин. Ми мали створити клас Red Burgundy і потім єдиний підклас Cotes d’Or (рис. 6-а). Проте він менш, тоді як нашому історичному уявленні червоні бургундські провина, і вина Cфtes d’Or, сутнісно, еквівалентні (все червоні бургундські вина є винами Cфtes d’Or і всі вина Cфtes d’Or — це червоні бургундські вина), то не потрібно створювати клас Cotes d’Or, і не додасть в уявлення нову інформацію. Якби ми мусили включити вина Cфtes Chalonnaise (дешевші бургундські вина в галузі південніше Cфtes d’Or), ми б створили два підкласу класу Burgundy: Cotes d’Or і Cotes Chalonnaise (рис. 6б).

.

Рис. 6. Підкласи класу Red Burgundy.

Наличие у класу лише одну підкласу свідчить про помилку при моделировании.

Теперь припустимо, що окреслили все вина як прямі підкласи класу Вино. Тоді це перелік включати такі загальніші сорти, як Beaujolais і Bordeaux, так само як і більше конкретні вина, як Paulliac і Margaux (рис. 7а). У класу Вино занадто багато прямих підкласів і вони справді, у тому щоб онтологія відбивала різні сорти вин чіткіше, Medoc має бути подклассом Bordeaux, а Cotes d’Or має бути подклассом Burgundy. З іншого боку, наявність таких проміжних категорій як Червоне вино і Біле Вино також відбивати ту понятійну модель предметної області вин, яку має багатьох людей (рис. 7б).

Тем не менш, а то й існує природних класів для угруповання понять в довгий список узлов-братьев, то ми не потрібно створювати штучні класи — залишіть усе є. Зрештою, онтологія — це відбиток реального світу, і тоді як дійсності категоризації немає, то онтологія має це отражать.

.

Рис. 7. Категоризація вин. Просте перерахування всіх вин проти кількох рівнів категоризации.

4.3. Множинне успадкування.

Большинство систем уявлення знань дозволяють здійснювати множинне успадкування в ієрархії класів: клас то, можливо подклассом кількох класів. Припустимо, що хочемо створити окремий клас десертних вин — клас Десертне вино. Вино Port є і червоним, і десертним вином [4]. Отже, ми визначаємо, що з класу Port є 2 надкласса: Червоне вино і Десертне вино. Усі екземпляри класу Port будуть екземплярами як класу Червоне вино, і класу Десертне вино. Клас Port успадкує слоты і фацеты від обох батьків. Таким чином, він успадкує значення СЛАДКОЕ з слота Цукор класу Десертне вино, і навіть слот рівень таніну і значення слота кольору класу Червоне вино.

4.4. Коли вводити (або вводити) новий колектив

Одно з найскладніших рішень, яку треба прийняти під час моделювання, — це визначити, коли запровадити нову клас, або коли сформулювати відмінність з допомогою різних значень властивостей. Складно орієнтуватися як і ієрархії, з дуже великі ступенем вкладеності і безліччю сторонніх класів, і у дуже пласкою ієрархії, з дуже мало класів, але у їх слотах закодовано занадто багато інформації. Знайти підходящий баланс нелегко.

Существует кілька практичних способів визначення того, як у ієрархію слід також запровадити нові классы:

Обычно підкласи класу (1) мають додаткові властивості, яких в надкласса, чи (2) обмеження, які від тих, що є в надкласса, чи (3) перебувають у інші стосунки, ніж надклассы.

У червоних вин рівні таніну, тоді як і властивість немає для описи вин загалом. Слот цукор класу Десертне вино має значення СЛАДКОЕ, тоді як надкласса класу Десертне вино це негаразд. Провина Pinot Noir можуть добре поєднуватися з морськими продуктами, тоді як інші червоні вина — немає. Інакше кажучи, ми звичайно вводимо в ієрархію новий колектив тільки тоді ми, коли ми можемо сказати про цей клас щось таке, чого ж ми поспіль не можемо сказати про надклассе.

На практиці кожному підкласу потрібно нові слоты чи визначити в нього нових значень слотів і перевизначити деякі фацеты успадкованих слотів.

Однако іноді може бути корисним започаткувати нові класи, навіть якщо де вони вводять ніяких нових властивостей.

Классы в ієрархіях термінів не зобов’язані нових властивостей.

Например, деякі онтології включають великі ієрархії посилань звичайних термінів, які у предметної області. Приміром, онтологія, що лежить основу електронної системи записи медичної інформації, може охоплювати класифікацію різних хвороб. Ця класифікація може бути як раз такий — ієрархією термінів, без властивостей (чи з однією і тих ж набором властивостей). І тут як і корисно організувати терміни в ієрархію, а чи не в лінійний список, вона (1) полегшить вивчення і навігацію і (2) дозволить лікаря легко вибрати підходящий рівень спільності терміна.

Другая причина запровадження нових класів без нових властивостей — це моделювання понять, серед яких експерти в предметної області зазвичай проводять розмежування, попри те що те, що ми мали змогу прийняти зважене рішення не моделювати саме розмежування. Оскільки ми використовуємо онтології для сприяння комунікації між експертами в предметної області, а також між експертами і системами, заснованими на знаннях, то онтології ми хотілося б відбити думку експерта на предметну область.

В результаті розширення зрештою, нам годі було створювати підкласи класу кожному за додаткового обмеження. Приміром, ми запровадили класи Червоне вино, Біле вино і Рожева вино, оскільки цей поділ є природним у світі вин. Не запровадили класи для вишуканого вина, для вин з помірним смаком тощо. Коли ми визначаємо ієрархію класів, наша мета — домогтися рівноваги між створенням класів, які корисні організації класів, і створення надто великої числа классов.

4.5. Новий клас, або значення властивості?

При моделюванні предметної області нам часто потрібно вирішувати, моделювати певна розмежування (таке як біле, червоне чи рожеве вино) як значення властивості чи як набір класів, що ж залежить від масштабу предметної області й від розв’язуваної завдання.

Создать нам клас Біле вино чи навіть створити клас Вино і введення різні значення слота колір? Відповідь залежить від цього масштабу, який ми визначили для онтології. Наскільки важливо поняття Біле вино — в нашої предметної області? Якщо важливість вин в предметної області незначна і те, біле це вино чи ні, особливо впливає його з іншими об'єктами, то ми не потрібно було затверджувати окремий клас білих вин. Для моделі предметної області, використовуваної для підприємства, де проводять винні етикетки, правила для етикеток вин різних кольорів одні й ті самі й поділ немає значення. І навпаки, до подання вина, їжі їх підхожих поєднань, червоне вино відрізняється від білого: воно узгоджується з інший їжею, в нього інші властивості тощо. Також, колір вина важливий для бази знань по винам, що ми можемо використовуватиме визначення послідовності дегустації вин. Тому ми створюємо окремий клас Біле вино.

Если поняття з різними значеннями слота стають обмеженнями щодо різноманітних слотів за іншими класах, то тут для поділу нам треба створити новий колектив. Інакше поділ представляється у значенні слота.

Подобным чином, з нашого онтології вин є такі класи як Червоне Merlot і Біле Merlot, а чи не єдиний клас всім вин Merlot: червоні Merlot і білі Merlot — ця справді різні вина (виготовлені з одного винограду), і коли ми розробляємо докладну онтологію, це поділ представляє важливість.

Если в предметної області розмежування представляє важливість та об'єкти коїться з іншими значеннями розмежування ми вважаємо іншими типами об'єктів, то тут для здійснення розмежування ми мусимо створити новий колектив.

При ухваленні рішення у тому, вводити новий колектив чи немає, також може бути корисно розглянути потенційні окремі екземпляри класу.

Класс, до якого належить окремий примірник, не повинен часто змінюватися.

Обычно, коли визначення різниці між класами ми використовуємо зовнішні, а чи не внутрішні властивості понять, екземпляри цих класів повинні часто переміщуватимуть вже з класу на другий. Наприклад, Охолоджене вино на повинен бути класом в онтології, яка описує пляшки вин у ресторані. Властивість охолоджене має бути просто атрибутом винні у пляшці, оскільки примірник класу Охолоджене вино може легко перестати бути примірником цього, та був знову стати його примірником.

Обычно числа, кольору, місцеположення є значеннями слотів і призводять до створення нових класів. Проте, вино — особливе виняток, оскільки колір вина має першорядної важливості його описи.

В ролі іншого прикладу розглянемо онтологію людської анатомії. Коли уявляємо ребра, створюємо ми клас для «1-го лівого ребра», потім клас для «2-го лівого ребра» тощо. Або в маємо клас Ребро зі слотами для послідовності і боку (ліве — правое)?[5] Якщо інформацію про кожному з ребер, які ми уявляємо в онтології, істотно відрізняється, те справді, треба створити клас кожному за ребра. Тобто, якщо ми хочемо докладно уявити інформацію про суміжності й у становищі (які різні всім ребер), і навіть особливі функції, що виконує кожне ребро, і які органи воно захищає, то нам треба створити класи. Якщо ми моделюємо анатомію на трохи більше низький рівень узагальнення і нашим потенційних додатків все ребра дуже схожі на (ми говоримо лише у тому, яке ребро зламано, судячи з рентгенівському знімку, безвідносно решти частинам тіла), знадобиться спростити ієрархію і залишити тільки клас Ребро з цими двома слотами: сторона і порядковий номер.

4. 6. Примірник чи клас?

Определение того, чим є певне поняття — класом в онтології чи примірником — залежить від потенційних додатків онтології. Визначення того, де закінчуються класи вулицю й розпочинаються окремі екземпляри, починається з визначення потрібної глибини деталізації в поданні. Глибина деталізації, своєю чергою, визначається потенційним додатком онтології. Інакше кажучи, які самі конкретні елементи будуть представлені у базі знань? Якщо повернутися до питань для перевірки компетентності, які ми викинули у Кроці 1 Глави 3, самі конкретні поняття, які відповідями ці запитання, найкраще підійдуть в ролі индивидных концептів у базі знаний.

Отдельные екземпляри — самі конкретні поняття, представлені у базі знань.

Например, коли ми збираємося говорити про доборі поєднань провина, і їжі, то нас потребу не цікавитимуть конкретні матеріальні пляшки вина. Тому такі терміни як Sterling Vineyards Merlot, мабуть, будуть найбільш конкретними використовуваними нами термінами. Отже, Sterling Vineyards Merlot буде примірником в базі знань.

С з іншого боку, якщо б ми хотіли підтримувати у ресторані асортимент вин в доповнення до бази знань хороших поєднань «вино-еда», то окремими екземплярами з нашого базі знань міг би стати окремі пляшки кожного вина.

Аналогично, якщо б ми хотіли записати різні якості кожному за конкретного врожаю Sterling Vineyards Merlot, то примірником у базі знань був би конкретний врожай вина, а Sterling Vineyards Merlot був би класом, що містить екземпляри усіх її урожаїв.

Другое правило може «перемістити» деякі окремі екземпляри до розряду классов:

Если поняття формують природну ієрархію, потрібно подати, як класи.

Рассмотрим винні області. На початку ми можемо визначити основні винні регіони, такі як Франція, США, Німеччина, та т.д. як класи, а конкретні винні області всередині цих регіонів як екземпляри. Наприклад, область Bourgogne — це примірник класу регіон Франція. Проте ми також хотіли відзначити, що область Cotes d’Or — це область Bourgogne. Тому область Bourgogne мусить бути класом (щоб мати підкласи чи екземпляри). Проте уявлення області Bourgogne як класу, а області Cotes d’Or як примірника області Bourgogne здається довільним: дуже складно чітко розмежувати, які галузі є класами, а які - екземплярами. Тому ми визначаємо все винні області як класи. Protege-2000 дає можливість користувачеві визначити деякі класи як Абстрактні, показуючи, що з класу може бути прямих примірників. У нашому випадку, все класи областей є абстрактними (рис. 8).

.

Рис. 8. Ієрархія винних областей. Іконка «А» поруч із іменами класів зазначає, що це абстрактні класи і неспроможна бути прямих экземпляров.

Так ж ієрархія класів було б неправильної, якби ми пропустили в імені класу слово «область». Не можемо сказати, що клас Alsace — це підклас класу Франція: Alsace — це не різновид Франції. Проте, область Alsace — різновид регіону Франція.

В вигляді ієрархії можна лише класи — в системах уявлення знань немає категорії «подэкземпляр». Тому, якщо серед термінів існує природна ієрархія, така як і ієрархіях термінів в Розділі 4.2, потрібно охарактеризувати ці терміни як класи, навіть якщо вони можуть і не мати своїх экземпляров.

4.7. Обмеження масштабу

В ролі останнього зауваження до складання ієрархії класів, наступний набір правил завжди допоможе у відповідях питанням, закінчено чи визначення онтологии:

Онтология має утримувати всю можливу інформацію про предметної області: ви повинні конкретизувати чи узагальнювати більше, ніж ви повинні до вашої докладання (трохи більше 1 додаткового рівня кожну бік).

Для нашого приклади з вином і їжею нам непотрібен знати, з якої папери робляться етикетки, чи як готуються страви з креветок.

Также онтологія має утримувати всіх можливих властивості класів та різницю між класами в ієрархії.

В нашу онтологію ми, природно, не включаємо все властивості, які б мати вино чи їжа. У нашій онтології ми представили найважливіші властивості класів елементів. Навіть попри те що книжках з винам можна почути розмір виноградин, ми включили цю інформацію. Також, наша систему ми увімкнули всі можливі відносини між всіма термінами. До прикладу, ми включаємо в онтологію такі взаємини, як улюблене вино чи улюблена їжа, просто у тому, щоб зробити повніше уявлення про взаємозв'язках між певними нами термінами повнішим.

Последние правила також застосовні задля встановлення відносин між поняттями, які ми готуємося вже включили в онтологію. Розглянемо онтологію, описує біологічні експерименти. Ця онтологія, мабуть, міститиме поняття Біологічні організми. Вона також утримувати поняття Експериментатор (у тому числі ім'я, місце праці та т.д.), що проводить експеримент. Правильно те, що експериментатор як людина є також біологічним організмом. Проте, ми, напевно, нічого не винні відбивати цю особливість в онтології: з метою цього подання експериментатор не є біологічним організмом, і ми, напевно, будь-коли проводитимемо експерименти самих экспериментаторах. Якби онтології робили уявлення усе те, що ми можемо сказати про класах, то Експериментатор б став подклассом класу Біологічний організм. Однак необхідності включати те знання для можливих додатків. Фактично, включення додаткової класифікації існуючих класів справді заважає: тепер у примірника Експериментатора будуть слоты мати більшу вагу, віку, виду та інших даних, які належать до біологічному організму, але зовсім недоречні в контексті описи експерименту. Проте, для користувачів, які поводитися з цієї онтологією і який знати про задуманому нами додатку, ми мусимо відбити це проектне рішення, у документации.

4.8. Диз’юнктивні подклассы

Многие системи дозволяють нам явно поставити, що кілька класів є дизъюнктивными. Класи диз’юнктивні, якщо в них то, можливо загальних примірників. Наприклад, з нашого онтології класи Десертне вино і Біле вино є дизъюнктивными: є безліч вин, являющих екземплярами обох класів. Однією з таких прикладів є Rothermel Trochenbierenauslese Riesling, примірник класу Солодке Riesling. У той водночас, класи Червоне вино і Біле вино дизъюнктивны: жодна вино може бути одночасно та білим, і червоним. Визначення класів як дизъюнктивных дозволяє системі краще перевіряти правильність онтології. Якщо ми оголосимо класи Червоне вино і Біле вино дизъюнктивными і далі створимо клас, який подклассом і Riesling (підклас Білого вина) і Port (підклас Червоного вина), то система може показати, що є помилка в моделировании.

5. Визначення властивостей — іще докладно

В цієї главі ми торкнемося ще кілька деталей, потрібно мати щодо слотів в онтології (Кроки 5 і шість в Главі 3). Здебільшого, ми обговорюємо зворотні слоты і значення слота по умолчанию.

5.1. Зворотні слоты

Значение слота може залежати від значення іншого слота. Наприклад, якщо вино було виконано на винному заводі, винний завод виробляє це вино. Ці дві відносини, виробник і робить, називаються зворотними відносинами. Зайве зберігати інформації і у тому, і про інше. Коли ми знаємо, що вино виготовляють винному заводі, то додаток, яке використовує базу знань, може вивести значення протилежного відносини: винний завод виробляє вино. Проте, з погляду придбання знань зручно мати всі два блоки інформації доступними вочевидь. Такий підхід дозволяє користувачам вказати вино — в тому випадку і винний на заводі іншому. Після це система придбання знань може автоматично заповнити значення протилежного відносини, забезпечуючи узгодженість бази знань.

В прикладі є пара зворотних слотів: слот виробник класу Вино і слот виробляє класу Винний завод. Коли користувач створює примірник класу Вино і продовжує заповнювати значення слота виробник, система автоматично додає знову створений примірник до слоту виробляє відповідного примірника класу Винний завод. Наприклад, коли ми говоримо, що Sterling Merlot виготовляють заводі Sterling Vineyard, система автоматично додає Sterling Merlot до списку вин, що їх виготовляє завод Sterling Vineyard (рис. 9).

.

Рис. 9. Примірники з зворотними слотами. Слот виробляє класу Винний завод є зворотним для слота виробник класу Вино. Заповнення однієї з слотів призводить до автоматичному оновленню другого.

5.2. Значення за умовчанням

Многие фреймові системи дозволяють визначити для слотів значення за умовчанням. Якщо значення певного слота однаково для більшості примірників класу, ми можемо визначити це значення значення слота за умовчанням. Потім, коли створюється кожен примірник класу, має цей слот, система автоматично заповнює значення за умовчанням. Після цього ми можемо змінити це значення будь-яку інше, яке дозволять фацеты. Тобто, значення за умовчанням створено зручності: у разі де вони накладають будь-які обмеження на модель чи її змінюють.

Например, коли більшість вин, ми збираємося говорити, є міцними, ті значення фортеці вина ми можемо зробити «міцне» за умовчанням. Тоді всі вина, які ми визначаємо, будуть міцними, коли ми не зазначимо інше.

Обратите увагу, що це від значень слота. Значення слота неможливо знайти змінені. Наприклад, ми можемо сказати, що слот цукор класу Десертне вино має значення «СЛАДКОЕ». Тоді в всіх підкласів і примірників класу Десертне вино значення слота цукор буде «СЛАДКОЕ». Всім підкласів чи примірників цього це значення змінити нельзя.

6. Про именах

Определение єдиних правил присвоювання імен поняттям в онтології, та був суворе дотримання цих правил як робить онтологію простіший розуміння, але й допомагає уникнути деяких загальних помилок під час моделювання. Є багато варіантів присвоювання імен поняттям. Зазвичай немає причини для вибору тієї чи іншої варіанта. Проте, нам нужно Определить єдині правила присвоювання імен класам і слотам і дотримуватися их.

На вибір правил присвоювання імен впливають такі особливості системи уявлення знаний:

Имеет чи система один і той ж простір імен класів, слотів і примірників? Тобто, дозволяє чи система мати клас" і слот з ім'ям (як, наприклад, клас винний коли завод і слот винний завод)?

Различает чи система регістр літер? Тобто, вважає система різними імена, які відрізняються лише регістром (як Винний коли завод і винний завод)?

Какие роздільники в іменах дозволяє вживати дана система? Тобто, чи можуть імена утримувати прогалини, коми, зірочки і т.д.

К прикладу, Protеgе-2000 має єдиний простір імен всім своїх фреймів. Вона розрізняє регістр літер. Отже, не то, можливо класу винний підприємство і слота винний завод. Проте ми й то, можливо клас Винний завод (не великі літери) і слот винний завод. З іншого боку, CLASSIC не розрізняє регістр літер і має різні простору імен для класів, слотів і индивидных концептів. Отже, з погляду системи, ми можемо легко привласнити ім'я Винний підприємство і класу, і слоту.

6.1. Заголовні букви і разделители

Во-первых, ми в змозі істотно поліпшити читаність онтології, якщо всі час писатимемо назви понять з великої літери. Наприклад, загальноприйнято починати імена класів з великої літери, а імена слотів — з маленької (припускаючи, що систему розрізняє регістр літер).

Когда ім'я поняття містить довше слова (як і Винний завод), ми мусимо розділити слова. Ось можливі варианты:

Использовать прогалину: Винний завод (багато системи, включаючи Protеgе, дозволяють використовувати прогалини у іменах понятий).

Соединить слова разом і кожен слово написати з великої букви: ВинныйЗавод .

Использовать в імені підкреслення чи тирі, або інший роздільник: Винный_Завод, Винный_завод, Винный-Завод, Винный-завод (коли ви використовуєте роздільник, вам також потрібно вирішити, писати кожне слово з великої букви чи нет).

Если система уявлення знань дозволяє використовувати прогалини у іменах, то тут для багатьох розробників онтологий прогалини може бути найприроднішим рішенням. Проте важливо враховувати інші системи, із якими може взаємодіяти ваша система. Якщо з цих системах не використовуються прогалини чи ваше засіб уявлення трохи зле обробляє прогалини, вона може бути кращою використовувати інший метод.

6.2. Єдине чи множинне число

Имя класу представляє набір об'єктів. Наприклад, клас Вино насправді представляє все вина. Тож багатьох розробників було б природніше дати класу ім'я Провина, а чи не Вино. Жоден з варіантів не краще організувати і буде не гірший іншого (хоча практиці для імен класів частіше використовується однину). Проте, яким би не був вибір, його слід дотримуватися протягом усього онтології. Деякі системи навіть вимагає від своїх користувачів заздалегідь оголосити, яка кількість (єдине чи множинне) вони залучити до іменах класів, не дають їм відхилятися від своєї выбора.

Использование постійно одному й тому ж форми також запобігає такі помилки розробника під час моделювання, створення класу Провина, та був створення класу Вино як він підкласу (див. Розділ 4.1).

6.3. Домовленість щодо використання префіксів і суффиксов

Некоторые методології за базами знань радять дотримуватися на домовленості у відношенні використання префіксів і суфіксів в іменах у тому, щоб розрізняти класи і слоты. Існує дві поширених традиції: додавати до імен слотів has-[6] чи прийменник -of[7]. Отже, наші слоты змінюються на его-производитель і его-винный_завод, коли ми виберемо використання-. Слоты змінюються на maker-of і winery-of[8], коли ми виберемо використання of-. Такий підхід дозволяє кожному, хто подивиться на термін, відразу ж потрапляє визначити, що це: клас, або слот. Проте імена термінів стають трохи длиннее.

6.4. Інші міркування щодо присвоюванню імен

Еще кілька моментів, потрібно пам’ятати при визначенні правил присвоювання имен:

Не додавайте до імен понять такі рядки як «клас», «властивість», «слот» тощо.

Из контексту відомо, що це, приміром, клас чи слот. На додачу до того що, що з класів та слотів ви використовуєте різні правила присвоювання імен (скажімо, пишете його з великий і з малої літери відповідно), саме ім'я показуватиме, чим є це понятие.

Обычно кращим скорочувати імена понять (тобто, використовуйте Cabernet Sauvignon, а чи не Cab).

Имя надкласса повинно входити чи в усі імена прямих підкласів, або ні до одного з них. Наприклад, коли ми створюємо два підкласу класу Вино до подання червоних, і білих вин, то підкласи повинні називатися чи Червоне Вино і Біле Вино, чи Червоне і Біле, але з Червоне Вино і Белое.

7. Інші ресурси

В наших прикладах як середовище розробки онтологий ми використовували Protege-2000. Duineveld із колегами описує і порівнює низку інших середовищ і розробити онтологий.

Мы постаралися розповісти про основному про розробці онтологий і торкнулися багатьох поглиблених що тим чи альтернативних методологій розробки онтологий. Gуmez-Pйrez і Uschold представляють альтернативні методології розробки онтологий. Керівництво по Ontolingua говориться про деяких формальних аспектах моделювання знань.

В час дослідники надають особливе значення як розробці онтологий, але й аналізу онтологий. Чим більше онтологий створюватиметься і повторно використовуватися, тим більший буде інструментальних коштів на аналізу онтологий. Приміром, Chimaera надає діагностичні інструментальні кошти на аналізу онтологий. Аналіз, що здійснює Chimaera, включає як перевірку логічного вірності онтології, і діагностику типових помилок під час проектування онтологий. Розробник онтологий може провести діагностику розроблюваної онтології з допомогою Chimaera, щоб визначити відповідність загальним способам моделювання онтологий.

8. Укладання

В цьому керівництві ми описали методологію розробки онтології для декларативних фреймовых систем. Ми перерахували кроки при розробці онтології і торкнулися складні питання визначення ієрархій класів та властивостей класів та примірників. Проте, окрім правив і рад, слід одне з найважливіших речей: для будь-який предметної області не існує єдино правильної онтології. Проектування онтології - це творчий процес і ще дві онтології, розроблені різними людьми, будь-коли будуть однаковими. Потенційні докладання онтології, і навіть розуміння розробником предметної області та його думка її у будуть, безсумнівно, проводити прийняття рішень під час проектування онтології. «Курчат восени вважають» — ми можемо оцінити якість нашої онтології, лише використовуючи їх у додатках, котрим її разработали.

Список литературы

Booch, G., Rumbaugh, J. and Jacobson, I. (1997).The Unified Modeling Language userguide: Addison-Wesley.

Brachman, R.J., McGuinness, D.L., Patel-Schneider, P.F., Resnick, L.A. and Borgida, A. (1991). Living with CLASSIC: When and how to useKL-ONE-like language. Principles ofSemantic Networks. J. F. Sowa, editor, Morgan Kaufmann:401−456.

Brickley, D. and Guha, R.V. (1999). Resource DescriptionFramework (RDF) Schema Specification. Proposed Recommendation, World Wide WebConsortium: internet.

Chimaera (2000). Chimaera Ontology Environment.internet.

Duineveld, A.J., Stoter, R., Weiden, M.R., Kenepa, B. andBenjamins, V.R. (2000). WonderTools? A comparative study of ontologicalengineering tools. International Journalof Human-Computer Studies52(6):1111−1133.

Farquhar, A. (1997). Ontolingua tutorial.internet.

Gуmez-Pйrez, A. (1998). Knowledge sharing and reuse. Handbook of Applied Expert Systems. Liebowitz, editor, CRC Press.

Gruber, T.R. (1993). A Translation Approach to PortableOntology Specification. KnowledgeAcquisition5: 199−220.

Gruninger, M. and Fox, M.S. (1995). Methodology for theDesign and Evaluation of Ontologies. In: Proceedings of the Workshop on BasicOntological Issues in Knowledge Sharing, IJCAI-95, Montreal.

Hendler, J. and McGuinness, D.L. (2000). The DARPA AgentMarkup Language. IEEE IntelligentSystems16(6): 67−73.

Humphreys, B.L. and Lindberg, D.A.B. (1993). The UMLSproject: making the conceptual connection between users and the information theyneed. Bulletin of the Medical LibraryAssociation81(2): 170.

McGuinness, D.L., Abrahams, M.K., Resnick, L.A., Patel-Schneider, P.F., Thomason, R.H., Cavalli-Sforza, V. and Conati, З. (1994).Classic Knowledge Representation System Tutorial.internet.

McGuinness, D.L., Fikes, R., Rice, J. and Wilder, P. S. (2000).An Environment for Merging and Testing Large Ontologies. Principles of Knowledge Representation andReasoning: Proceedings of the Seventh International Conference (KR2000). A.G. Cohn, F. Giunchiglia and B. Selman, editors. San Francisco, CA, MorganKaufmann Publishers.

McGuinness, D.L. and Wright, J. (1998). Conceptual Modelingfor Configuration: A Description Logic-based Approach. Artificial Intelligence for EngineeringDesign, Analysis, and Manufacturing — special issue on Configuration.

Musen, M.A. (1992). Dimensions of knowledge sharing andreuse. Computers and BiomedicalResearch25: 435−467.

Ontolingua (1997). Ontolingua System Reference Manual.internet.

Price, З. and Spackman, K. (2000). SNOMED clinical terms. BJHC&IM-British Journal of HealthcareComputing&Information Management17(3): 27−31.

Protege (2000). The Protege Project.internet.

Rosch, E. (1978). Principles of Categorization. Cognition and Categorization. R. E. andB. B. Lloyd, editors. Hillside, NJ, Lawrence Erlbaum Publishers:27−48.

Rothenfluh, T.R., Gennari, J.H., Eriksson, H., Puerta, A.R., Tu, S.W. and Musen, M.A. (1996). Reusable ontologies, knowledge-acquisitiontools, and performance systems: PROTEGE-II solutions to Sisyphus-2.International Journal of Human-ComputerStudies44: 303−332.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. andLorensen, W. (1991).Object-orientedmodeling and design. Englewood Cliffs, New Jersey: Prentice Hall.

Uschold, M. and Gruninger, M. (1996). Ontologies: Principles, Methods and Applications. KnowledgeEngineering Review11(2).

[1] Імена класів ми починаємо з великої літери, а імена слотів — з маленької. Також всім термінів з економічного онтології, наведеної у як приклад, ми використовуємо шрифт друкованої машинки.

[2] Ми також можемо розглядати класи як унарные предикати — питання з однією аргументом. Наприклад, «Цей предмет є вином?» Унарные предикати (чи класи) протилежні бінарним предикатам (чи слотам) — питанням з цими двома аргументами. Наприклад, «Цей предмет має сильний смак?» «Який смак від цього предмета?».

[3] Деякі системи лише визначають тип значення з допомогою класу тут і не вимагають спеціальної формулювання для слотов-экземпляров.

[4] У нашій онтології вирішили подати лише червоні вина Port: білі вина Port існують, але дуже рідко встречаются.

[5] Тут нам здається, кожен анатомічний орган є класом, оскільки ми також хотів би казати про «1-му лівому ребрі Джона». У нашій онтології окремі органи реально існуючих людей буде представлено як индивидные концепты.

[1] У більшості американських коледжів вступний курс будь-якого предмета має номер «101»: «Хімія 101», «Біологія 101» тощо. Наступні два більш поглиблених курсу по хімії називалися б «Хімія 102» і «Хімія 103» відповідно. У номер «101» означає «Запровадження». Тобто., назва статті треба розуміти як «Введення у розробку онтологий: Посібник із створенню Вашої першої онтології». (Тут і далі з тексту примітки перекладача. Авторські примітки винесені на кінець статті самими авторами.).

[2] Буквально «является».

[3] Буквально «вид, різновид [чего-то]».

[4] «Shrimp» і «prawn» — це синоніми, які переводяться однаково — «креветка».

[5] Також перекладається «креветка».

[6] «has» у разі можна перекласти, як «его».

[7] У англійській прийменник «of» використовується для відносин, які у російській мові передаються родовим падежом без приводу. Тому використання цього суфікса для російськомовних користувачів утрачає будь-який сенс.

[8] maker-of — виробник [чогось], а winery-of — винний завод [із виробництва чего-то].