allScience Magazine

1 Защо да разработи онтология?
През последните години развитието на онтологии изрично официално спецификациите на условията в домейна и отношенията между тях (Грубер 1993) се движи от сферата на лабораториите за изкуствен интелект на компютрите на експерти в областта. Онтологиите са станали често на World Wide Web. Онтологии на уеб гама от големи сайтове за категоризиране на таксономии Web (като Yahoo!) за категоризация на продуктите за продажба и техните характеристики (като например в Amazon.com).

WWW Консорциума (W3C) се развива Resource Description Framework (Brickley и Guha 1999 г.), език за кодиране на знания на уеб страници, за да направят разбираеми за електронни агенти, търсене на информация. На отбраната Разширено изследователски проекти агенция (DARPA), във връзка с W3C разработва DARPA Агент Markup Language (DAML) чрез разширяване на RDF с по-изразителен конструкции, насочени към улесняване на взаимодействието агент на Web (Хендлър и Макгинес 2000). Много дисциплини сега се развиват стандартизирани онтологии, че експерти на домейн може да използвате, за да споделят и анотирате информация в своите области. Медицина, например, произвежда големи, стандартизирани, структурирани речници като SNOMED (Цена и Spackman 2000 г.) и семантична мрежа на Единната медицинска система Language (Хъмфрис и Линдберг 1993 г.). Широкото с общо предназначение, онтологии се появяват, както добре. Например, на Програмата за развитие на на Организацията на обединените нации и Dun & Bradstreet обединиха усилията си за разработване на UNSPSC онтология, която осигурява терминология за продукти и услуги (www.unspsc.org).
Онтология дефинира общ речник за изследователи, които се нуждаят от да споделят информация в домейн. Тя включва машина интерпретира определения на основни понятия в областта и отношенията между тях.
Защо някой ще иска да се разработи онтология? Някои от причините са:
· За да се споделят общото разбиране на структурата на информация между хора или софтуерни агенти
· Да се ​​даде възможност за повторно използване на домейн знания
· За да направите домейн предположения изрично
· Да отделен домейн на знания от оперативните знания
· Да се ​​анализират знания на домейн
Споделянето на общо разбиране за структурата на информация сред хората или софтуерни агенти е един от по-общи цели в развиващите се онтологии (Musen 1992 г.; Грубер 1993). Например, да предположим, че няколко различни уеб сайтове съдържа медицинска информация или предоставяне на медицински услуги за електронна търговия. Ако тези уеб сайтове, споделят и публикуват същото онтология на гледна точка, всички те използват, а след това компютър агенти може да се извлече и на обобщена информация от тези различни сайтове. Агентите могат да използват тази обобщена информация, за да отговори на запитвания на потребителите или като входни данни за други приложения.
Активиране на повторно използване на домейн знания е една от движещите сили зад неотдавнашния скок на онтология изследвания. За пример, модели за много различни области трябва да представлява понятието за време. Това представяне включва понятията на времевите интервали, точки във времето, относителната мерки на време, и така нататък. Ако една група от изследователи се развива такава онтология в детайли, други може просто да го използвате отново за техните домейни. Освен това, ако ние трябва да се изгради голям онтология, ние може да се интегрира на няколко съществуващите онтологии, описващи части на голям домейн. Можем също така да използвате повторно общо онтология, като UNSPSC онтология и да го удължи, за да се опише домейна ни на интерес.
Осъществяване изрично предположения на домейн, в основата на изпълнение дава възможност да се променят тези предположения лесно, ако нашите знания за домейн промени. Hard-кодиране на допусканията за света, в програмен код език прави тези предположения не само трудно да се намери и разбиране, но също така трудно да се промени, по-специално за някого, без програмиране експертиза. В допълнение, изрично спецификации на домейн знания са полезни за нови потребители, които трябва да се научат какво означават термините в домейна.
Отделянето на домейн знания от оперативните знания е друга често срещана употреба на онтологии. Ние можем да опишем задача на конфигуриране на продукта от неговите компоненти, в съответствие с техническите изисквания и прилагане на програма, която върши тази конфигурация, независимо от продукти и компоненти себе си (Макгинес и Райт 1998 г.). След това можем да се разработи онтология на PC компоненти и характеристики и прилага алгоритъм, за да конфигурирате компютри, изработени по поръчка. Можем също да използваме същия алгоритъм, за да конфигурирате асансьори, ако ние «фураж» онтология компонент асансьора към нея (Rothenfluh и др. 1996).
Анализиране на домейн знания е възможно веднъж декларативен спецификация на условията е на разположение. Официално анализ от гледна точка е изключително ценна, когато и двете се опитват да използват повторно съществуващите онтологии и разширяване тях (Макгинес и др 2000).
Често онтология на домейна не е цел сама по себе си. Разработване на онтология е близък до определянето на набор от данни и структурата им за други програми да ползват. Проблем за решаване на методи, домейн независими приложения и софтуерни агенти използват онтологии и бази от знания, построен от онтологии като данни. Например, в тази статия ние разработваме онтология на вино и храна, както и подходящи комбинации на вино с храна. Това онтология може да се използва като основа за някои приложения в пакет от инструменти за управлението на ресторант-: едно заявление може да създаде вино предложения за меню за деня, или да отговарят на запитвания на сервитьори и клиенти. Друго приложение, може да анализира опис на винарска изба и да предложи вино категории, за да се разшири и кои конкретни вина за закупуване за предстоящи менюта или готварски книги.
За това ръководство
Ние изграждаме на нашия опит с използването протеже-2000 (протеже 2000), Ontolingua (Ontolingua 1997), Chimaera (Chimaera 2000) като среда за редактиране на онтология. В това ръководство, ние използваме протеже-2000 за нашите примери.
Например вино и храна, която ние използваме цялото ръководство, е базиран на база например знания, представени в хартията, описващ CLASSIC — система за представяне на знания, въз основа на описание на логиката подход (Brachman и др 1991 г.). CLASSIC начинаещи (Макгинес и др 1994) е разработила този пример. Протеже-2000 и други рамка системи, базирани на онтологии описват декларативно, като се посочва изрично, какво класа йерархия и към която принадлежат класове лица.
Някои идеи за дизайн на онтология в това ръководство, с произход от литература по обектно-ориентиран дизайн (Rumbaugh и др 1991 г.;. Booch и др 1997 г.). Въпреки това, развитието на онтология е различно от проектирането на класове и отношения в обектно-ориентираното програмиране. Обектно-ориентирано програмиране центрове предимно около методи на класове програмист прави дизайнерски решения, въз основа на оперативни свойства на даден клас, като има предвид, че онтология дизайнер прави тези решения, въз основа на структурните свойства на даден клас. В резултат, класовата структура и отношения между класове в онтологията са различни от структурата за подобен домейн в обектно-ориентирана програма.
Това е невъзможно да обхваща всички въпроси, които един разработчик онтология може да се наложи да се борят с, и ние не се опитваме да се справи с всички тях в това ръководство. Вместо това, ние се опитваме да предостави отправна точка, първоначално ръководство, което ще помогне нов дизайнер онтология, за да развият онтологии. В крайна сметка, ние предлагаме места, да се търсят обяснения на по-сложни структури и механизми за дизайн, ако домейна ги изисква.
Накрая, не е единствен правилен методология за дизайн на онтология и ние не се опитват да определят. Идеите, че ние представяме тук, са тези, които ние открихме, полезни в нашата собствена онтология развитие опит. В края на това ръководство, ние предлагаме списък на справки за алтернативни методики.

2 Какво е по онтология?

Изкуствен интелект литература съдържа много дефиниции на онтологията, много от тези противоречат един на друг. За целите на това ръководство онтология е официално изрично описание на понятия в областта на дискурса (класове (понякога се нарича идеи)), свойства на всяка концепция, описващи различни характеристики и атрибути на понятието (слотове (понякога се нарича роли или свойства) ), и ограничения върху слотове (фасети (понякога наричат ​​роля ограничения)). Онтология, заедно с набор от индивидуални случаи на класове, представлява база от знания. В действителност, има Тънка е границата, където онтология свършва и започва на базата от знания.
Класовете са във фокуса на повечето онтологии. Класовете описват понятия в домейна. Например, един клас вина представлява всички вина. Специални вина са копия от този клас. Бордо вино в чаша пред вас, докато четете този документ е инстанция на класа на вина от Бордо. Даден клас може да има подкласове, които представляват концепции, които са по-специфични от суперкласа. Например, можем да разделим класа на всички вина в червено, бяло и розе вина. Като алтернатива, можем да разделим класа на всички вина в пенливи и пенливи вина.
Slots описват свойства на класове и случаи: Шато Лафит Ротшилд Pauillac вино има цялото тяло, той се произвежда от винарна Шато Лафит Ротшилд. Ние имаме два слота описание на вино в този пример: слот тяло с стойност и производител на слот със стойността Шато Лафит Ротшилд винарна. В класа ниво, можем да кажем, че случаите на класа вино ще имат слотове описва техният вкус, тялото, нивото на захар, производител на вино и др. [1]
Всички случаи на класа вино, и неговите подклас Pauillac, слот машина, стойността на който е инстанция на класа, винарна (Фигура 1). Всички случаи на класа Винарна имат слот произвежда че се отнася за всички вина (инстанции на класа вино и подкласовете), че винарната произвежда.
От практическа гледна точка, развитието на онтологията включва:
· Дефиниране на класове в онтологията,
· Организиране на класове в йерархия таксономична (подклас суперкласа),
· Определяне на слотове, както и описание на допустимите стойности за тези слотове,
· Попълване на стойностите за слота за отделните случаи.
Ние можем след това да създадете база от знания, чрез определяне на отделни случаи на тези класове, попълване на специфична информация слот стойност и допълнителни ограничения слот.

Фигура 1. Някои класове, случаи, и отношенията между тях в областта на виното. Ние използвахме черен за класове и червен за случаи. Директни връзки представляват слотове и вътрешни връзки, като например на и подклас на.

3 A Simple-инженеринг на знания Методология

Както казахме по-рано, има нито един «правилен» начин или методология за разработване на онтологии. Тук ние обсъждане на общи въпроси да се разглеждат и предлагат един възможен процес за разработване на онтология. Ние описват един повтарящ се подход към развитието на онтология: да започнем с грапава първо преминаване на онтологията. Ние след това да се преразгледа и прецизира развиващата онтология и попълнете в детайлите. По пътя, ние обсъждаме решенията за моделиране, че един дизайнер трябва да се направи, както и плюсовете, минусите, както и последиците от различни решения.
Първо, бих искал да подчертая някои основни правила в дизайна на онтология, към които ще се отнесе много пъти. Тези правила може да изглеждат по-скоро догматично. Те могат да помогнат, обаче, да направи дизайн решения в много случаи.
1) не е един правилен начин за модел на домейн винаги съществуват надеждни алтернативи. Най-доброто решение почти винаги зависи от приложението, което имате в предвид и разширения, които ви очакват.
2) Онтология развитие е задължително един повтарящ се процес.
3) понятия в онтологията трябва да бъде в близост до обекти (физически или логически) и взаимоотношенията в домейна на вашите интереси. Това са най-вероятно да бъдат съществителни (обекти) или глаголи (връзки) в изречения, които описват вашия домейн.
Това е, да реши какво ние ще използваме онтология за и колко подробни или общи онтология ще бъде ще ръководи много от решенията за моделиране надолу по пътя. Сред няколко надеждни алтернативи, ние ще трябва да се определи кой ще работи по-добре за прогнозите задача, да бъдат по-интуитивни, по-разтегателен, и по-възможна за поддържане. Ние също трябва да се помни, че една онтология е модел на реалността на света и концепции в онтологията трябва да отразяват тази реалност. След като определи първоначална версия на онтологията, ние може да прецени и да го дебъгване, като го използва в приложения или методи за решаване на проблеми или като го обсъдите с експерти в областта, или и двете. В резултат на това почти със сигурност ще трябва да преразгледа първоначалното онтология. Този процес на повтарящ се дизайн вероятно ще продължи през целия жизнен цикъл на онтологията.

Стъпка 1. Определяне на домейн и обхвата на онтологията

Ние предлагаме да започнете развитието на онтология, чрез определяне на домейн и обхвата. Това е отговор на няколко основни въпроса:
· Какво е домейн, че онтологията ще покрие?
· За какво ще използвате онтология?
· За какви видове въпроси на информация в онтологията следва да даде отговори?
· Кой ще използва и поддържа онтология?
Отговорите на тези въпроси могат да се променят по време на процеса на дизайн на онтологията, но във всеки даден момент те помагат да ограничи обхвата на модела.
Помислете за онтология на вино и храна, които ние въведохме по-рано. Представителство на хранителни продукти и вина, е областта на онтологията. Ние планираме да използвате тази онтология за приложения, които показват добри комбинации на вина и хранителни.
Естествено, на понятията, описващи различни видове вина, основни видове храни, на понятието добра комбинация от вино и храна и лоша комбинация, ще фигурират в нашата онтология. В същото време, тя е малко вероятно, че онтологията ще включва концепциите за управление на инвентаризация в винарна или служители в ресторант, въпреки че тези понятия са донякъде свързани с понятията на вино и храна.
Ако онтология, ние сме проектиране ще бъдат използвани за подпомагане в естествен език обработка на статии в списания за вино, тя може да бъде важно да се включват синоними и част от реч информация за концепции в онтологията. Ако онтологията ще се използват за подпомагане ресторант клиенти решават кой вино ред, ние трябва да включват дребно ценова информация. Ако то се използва за купувачи на вино в отглеждане на винарска изба, търговия на едро цената и наличността може да се наложи. Ако хората, които ще поддържат онтологията се описват домейна в един език, който е различен от езика на онтологията потребители, може да се наложи да се предоставят на картографиране между езиците.
Компетентност въпроси.
Един от начините да се определи обхватът на онтологията се скица списък на въпроси, които на база от знания, на базата на онтологията трябва да бъде в състояние да отговори, компетентност въпроси (Gruninger и Fox 1995 г.). Тези въпроси ще послужат като лакмусов тест по-късно: Дали онтологията съдържа достатъчно информация, за да отговорим на тези видове въпроси? Дали отговорите изискват определено ниво на детайлност или представителство на конкретна област? Тези компетентност въпросите са само една скица и не трябва да бъде изчерпателен.
В домейн на вино и храна, са следните възможни въпроси на компетентност:
· Кои характеристики на вино трябва да се вземат предвид при избора на вино?
· Бордо червено или бяло вино?
· Ли Каберне Совиньон вървят добре с морски дарове?
· Какво е най-добрият избор на вино за скара?
· Кои характеристики на виното влияят на нейната целесъобразност за едно ястие?
· Ли букет или орган на конкретната промяна на вино с реколтната година?
· Какви са били добри реколти за Напа зинфандел?
Съдейки от този списък от въпроси, онтология ще включва информация за различни характеристики на виното и видове вина, реколта години-добри и лоши-класификации на храни, които имат значение за избора на подходящо вино, препоръчва комбинации на вино и храна.

Стъпка 2. Помислете за повторно използване на съществуващите онтологии

Той е почти винаги, заслужава да бъде разгледан това, което някой друг е направил и проверка, ако можем да се прецизира и разшири съществуващите източници за специално нашия домейн и задача. Повторно използване на съществуващите онтологии може да бъде изискване, ако нашата система трябва да си взаимодействат с други приложения, които вече са ангажирани специално онтологии или контролирани речници. Много онтологии вече са достъпни в електронен вид и могат да бъдат внасяни в онтология развитие на околната среда, че използвате. Формализъм, в който се изразява онтология често няма значение, тъй като много системи за представяне на знания, да импортирате и експортирате онтологии. Дори ако системата за представяне на знания не могат да работят директно с формализъм, задачата на превода на онтология от един формализъм към друг, обикновено не е трудно.
Има библиотеки на многократно онтологии в интернет и в литературата. За пример, можем да използваме онтология Ontolingua библиотека (http://www.ksl.stanford.edu/software/ontolingua/) или DAML библиотека онтология (http://www.daml.org/ontologies/). Има и редица публично достъпни търговски онтологии (например, UNSPSC (www.unspsc.org), RosettaNet (www.rosettanet.org), DMOZ (www.dmoz.org)).
Например, на база от знания на френски вина, може вече да съществува. Ако можем да внасят тази база от знания и онтология, на които то се основава, ние ще имаме не само класификация на френските вина, но и първо преминаване на класификацията на вино характеристики, използвани за да се разграничи и да се опише вината. Списъци на вино свойства може вече да бъде на разположение от търговските уеб сайтове като www.wines.com, че клиентите смятат, че използвате, за да купуват вина.
За това ръководство, но ние ще приемем, че вече няма съответни онтологии да съществува и да започне разработването на онтологията от нулата.

Стъпка 3. Изброят важните термини в онтологията

Полезно е да се напише списък на всички условия, ние бихме искали да правят изявления или да обясни на потребителя. Какви са условията, ние бихме искали да говорим за? Какво свойства тези термини? Какво бихме искали да кажем за тези срокове? Например, важно лозаро-свързани ще включва вино, гроздова, винарна, място, на виното цвят, тялото, аромат и съдържание на захар; различни видове храни, като риба и червено месо; подтипове на вино като бяло вино, и така нататък. Първоначално е важно да получите изчерпателен списък на условията, без да се притеснявате за припокриване между понятия, те представляват, отношенията между термините, или имоти, които могат да имат понятията, или дали понятията са класове или слотове ..
Следващите две стъпки развитието на класа йерархия и определяне на свойства на понятията (слотове) са тясно преплетени. Трудно е да направите едно от тях на първо място и след това направете друга. Обикновено ние създаваме няколко дефиниции на понятията в йерархията и след това продължете, като описва свойствата на тези понятия и така нататък. Тези две стъпки са най-важните стъпки в процеса на дизайн на онтологията. Ние ще ги опишем тук за кратко и след това прекара следващите две секции обсъждане на по-сложни въпроси, които трябва да бъдат взети под внимание, общите клопки, решенията да се направи, и така нататък.

Стъпка 4. Дефиниране на класове и клас йерархия

Има няколко възможни подходи в развитието на класа йерархия (Uschold и Gruninger 1996):
· Отгоре-надолу процес на разработка започва с определянето на най-общите понятия в областта и последваща специализация на понятията. Например, можем да започнем със създаването на класовете за общите понятия, на виното и храните. Тогава ние се специализират Wine клас от създаването на някои от неговите подкласове: Бяло вино, червено вино, вино розе. Ние можем още повече да категоризира Червено вино клас, например, в Сира, Red Бургундия, Каберне Совиньон, и така нататък.
· Процеса на развитие «отдолу-нагоре» започва с определянето на най-специфичните класове, листата на йерархията, с последващо групиране на тези класове в по-общите понятия. Например, да започнем от определяне на класове за Pauillac и Margaux вина. Ние след това да се създаде обща суперкласа за тези два класа-Medoc, което от своя страна е подклас на Бордо.
· Процес на разработка на комбинация е комбинация от подходи отгоре надолу и отдолу-нагоре: Ние дефинираме по-характерните концепции за първи път и след това се обобщи и да ги специализират по подходящ начин. Ние може да започне с няколко от най-високо ниво концепции като вино, и няколко конкретни концепции, като Margaux. След това можем да им се отнасят до средно ниво концепция, като Medoc. Тогава можем да искат да генерират всички регионални класове на вино от Франция, като по този начин се генерира номер на средно ниво концепции.
Фигура 2 показва вероятното разпределение между различните нива на всеобщност.

Фигура 2. Различните нива на таксономия на Wine: вино, червено вино, бяло вино, вино розе са по-общи концепции, най-високо ниво. Pauillac и Марго са най-специфичните класове в йерархията, най-ниското ниво.

Нито една от тези три метода е присъщо по-добре, отколкото някой от другите. Подход да предприеме силно зависи от личната гледна точка на домейна. Ако разработчикът има систематичен отгоре-надолу оглед на домейна, тогава тя може да бъде по-лесно да се използва подход «отгоре-надолу. Комбинацията подход често е най-лесният за много разработчици онтология, тъй като понятия «по средата» са склонни да бъдат по-описателни понятия в домейн (Рош 1978).
Ако сте склонни да мислим за вина, като разграничаване на най-общата класификация на първо място, а след това «отгоре-надолу подход може да работи по-добре за вас. Ако искате по-скоро да се започне от получаване на обоснован с конкретни примери, подход отдолу-нагоре може да бъде по-подходящо.
Който и подход ние избираме, ние обикновено се започне от определяне на класове. От списък, създаден в Стъпка 3, изберете термини, които описват обекти, които имат самостоятелно съществуване, а от термини, които описват тези обекти. Тези условия ще бъдат класове в онтологията и ще станат водещи в класа йерархия. [2] Ние организираме класове в йерархична таксономия, като пита дали от инстанция на един клас, обект ще е задължително (т.е., по дефиниция). инстанция на някои друг клас.
Ако даден клас А е суперкласа от клас Б, след това на всеки случай на B е също инстанция на
С други думи, клас Б представлява концепция, която е «вид на» А.
Например, всеки Pinot Noir вино е задължително червено вино. Затова Пино Ноар клас е подклас на Red Wine клас.
Фигура 2 показва част от класа йерархия за Wine онтология. Раздел 4 съдържа подробно обсъждане на неща, които трябва да се търсят при определяне на клас йерархия.

Фигура 3. Слота за класа вино и аспекти за тези слотове. Икона «I» до производител слот, показва, че слота има обратнопропорционална (раздел 5.1)

Стъпка 5. Определяне на свойствата на класовете слота

Класовете сами по себе си няма да предостави достатъчно информация, за да отговори на въпроси от компетентността Стъпка 1. След като сме определили някои упражнения, ние трябва да описват вътрешната структура на понятията.
Ние вече са избрани класове от списъка на термините, които ние създадохме в стъпка 3. Повечето от останалите условия е вероятно да бъдат свойства на тези класове. Тези условия включват, например, цвят на кожата, тялото, аромат и съдържание на захар, вино и местоположението на винарната.
За всеки имот в списъка, ние трябва да определи кой клас го описва. Тези свойства стават слотове приложен към класове. Така, клас в лозаро-винарския сектор ще има следните слотове: цвят на кожата, тялото, вкус, и захар. А клас на Винарната ще има слот за местоположение.
По принцип, има няколко типа на обекта имоти, които могат да станат слотове в онтологията:
· «Присъщите свойства, като например вкуса на виното;
· «Неприсъщи» свойства, като например името на виното, и област идва от;
· Части, ако обектът е структуриран, те могат да бъдат както физически, така и абстрактни «части» (например, курсовете на храненето)
· Взаимоотношения с други лица, това са отношенията между отделните членове на клас и други елементи (например, производител на вино, което представлява връзката между вино и винарна, и грозде, виното е направено от.)
Така, в допълнение към свойствата, които са идентифицирани по-рано, ние трябва да добавите следните слотове за виното клас: име, район, производител на грозде. Фигура 3 показва слотове за клас вино.
Всички подкласове на класа наследяват слота на този клас. За пример, всички слотове на класа Вино ще бъде наследен на всички подкласове на вино, включително и червено вино и бяло вино. Ние ще добавим допълнителен слот, танин ниво (ниска, средна или висока), Red Wine клас. Слот за танин ниво ще бъдат наследени от всички класове, представляващи червени вина (като Бордо и Божоле).
Слот трябва да се прикрепи в най-общ клас, които могат да имат тази собственост. Така например, тялото и цвета на виното трябва да бъде приложен в клас вино, тъй като тя е най-общ клас, чиито случаи ще има тяло и цвят.

Стъпка 6. Определете аспекти на слотовете

Slots може да има различни аспекти, описващи стойност тип, позволените стойности, броят на стойностите (cardinality), както и други характеристики на стойностите, слот може да. Например, стойността на име каре (както и в «името на вино») е един низ. Това означава, че името е слот със стойност тип String. Слот произвежда (както в «Винарната произвежда тези вина») може да има няколко стойности и стойностите са инстанции на клас вино. Това е, произвежда, е слот с вида съд с вино, както е позволено клас.
Сега ще опишем няколко общи аспекти.
Слот cardinality
Слот cardinality определя колко стойности може да има слот. Някои системи се различават само между една cardinality (което позволява най-много една стойност) и множествена cardinality (позволяваща произволен брой стойности). А тялото на виното ще бъде един слот cardinality (вино, може да има само един орган). Вина, произведени от дадена винарна попълните няколко cardinality слот произвежда винарна клас.
Някои системи позволяват определяне на минималния и максималния cardinality, за да опише по-точно броя на слот стойности. Минимална cardinality на N означава, че слот трябва да има най-малко N ценности. Например, гроздовата слот на вино е минимум cardinality на 1: всяко вино е направено най-малко един сорт грозде. Максимална cardinality на M означава, че слот може да има най-много ценности M. Максималната cardinality за гроздовата слот за един сортови вина е 1: тези вина са направени от само един сорт грозде. Понякога може да е полезно да зададете максималната cardinality 0. Тази настройка се посочва, че слота не може да има никакви стойности за даден подклас.
Slot-тип «стойност»
Стойност тип аспект се описва какви типове стойности може да запълни в слота. Ето списък на най-често срещаните видове стойност:
· String е най-простият от вида, който се използва за получаване на слотове, като име: стойността е обикновен низ
· Брой (понякога се използват по-специфични видове стойност на поплавъка и цяло число) описва слота с числени стойности. За пример, цената на виното може да има Float тип на стойност
· Булеви слотове са просто да не знамена. Например, ако решим да не представлява пенливи вина като отделен клас, дали е пенливо вино или не може да бъде представена като стойността на булеви слот: ако стойността е «истинска» («да») е пенливо вино и, ако стойността е «фалшиво» («не») вино не е пенливо.
· Изброени слотове да определи списък на допустимите стойности за слота. Например, ние можем да се уточни, че слота вкус може да поеме един от трите възможни стойности: силна, средна и деликатен. В протеже-2000 изброените слотове са от тип Symbol.
· Съд от типа слотове позволяват дефиниране на отношенията между индивидите. Slots с вида съд също трябва да се определи списък на разрешените класове, от които случаи може да дойде. Например, слот произвежда за Винарна клас може да има случаи на класа вино като неговите ценности. [3].
Фигура 4 показва определението на слота произвежда в клас Winery.

Фигура 4. Определението на слот произвежда, която описва вина, произведени от избата. Слот е кратно на cardinality съд стойност тип, и за виното клас като допустимите клас за техните стойности.

Домейн и обхват на слота
Разрешени класове за получаване на слотове на тип съд са често се нарича набор от слот. В примера на фигура 4 клас Виното е кръг от произвежда слот. Някои системи позволяват ограничаване на обхвата на слот, когато е приложен слота за определен клас.
Класове, към които е приложен слот или клас, който имот слот описва, се нарича областта на слота. Класът на Винарска изба е домейн на произвежда слот. В системите, където ние отдаваме слота за класове, класовете, към който е прикрепен слота обикновено съставляват домейн на този слот. Няма нужда да укажете домейн отделно.
Основните правила за определяне на домейн, както и набор от слот са сходни:
При определяне на домейн или диапазон за слот, намерете най-общи класове или клас, които могат да бъдат съответно домейн или набор за слотовете.
От друга страна, не се определят на домейн и обхват, че е прекалено общо всички класове в областта на слот трябва да бъдат описани от слота и копията на всички класове в обхвата на слот трябва да бъдат потенциални пълнители за слот. прекалено общ клас за диапазон (т.е., човек не би искал да направи нещо от време), но човек би искал да избере класа, която ще обхваща всички пълнители
Вместо да се изброяват всички възможни подкласовете на Wine клас за обхвата на произвежда слот, просто Винена листа. В същото време, ние не искаме да се определи обхвата на слота като нещо най-общ клас в онтологията.
В по-специфични условия:
Ако списъкът на класовете, които се определят диапазон или домейн на слот включва клас и подклас, извадете подклас.
Ако обхвата на слота съдържа както Wine класа и Red Wine клас, ние можем да премахнете червеното вино от диапазона, защото не добавите всяка нова информация: Червено вино е подклас на виното и затова слота гама вече имплицитно включва както и всички останали подкласове на класа за виното.
Ако списъкът от класове, които се определят диапазон или домейн на слот съдържа всички подкласовете от клас А, но не и клас А самия диапазон трябва да съдържа само клас А и не подкласове.
Вместо определяне на обхвата на слота, за да се включат червено вино, бяло вино и вино розе се изброяват всички преки подкласовете на виното, ние може да ограничи обхвата на самия клас Wine.
Ако списъкът от класове, които се определят диапазон или домейн на слот съдържа, почти всички подкласове на клас А, помислете ако клас А ще направи по-подходящо определение, обхват.
В системите, където закрепване слот клас е същата като добави класа към домейна на слота, същите правила се прилагат за слот прикачения файл: От една страна, трябва да се опитаме да го направим възможно най-общо, както. От друга страна, ние трябва да се гарантира, че всеки клас, към който ние отдаваме слота действително може да има собственост, която представлява слота. Ние можем да прикачите ниво танин слота за всеки от класовете, представляващи червени вина (например, Бордо, Мерло, Божоле и др.). Въпреки това, тъй като всички червени вина са собственост на танин ниво, ние трябва, вместо да прикачите слота за този по-общ клас на червени вина. Обобщаване на домейна на слота танин ниво (като го закрепи за виното клас, вместо) не би било правилно, тъй като ние не използваме ниво на танин, за обозначаването на бели вина, например.

Стъпка 7. Създаване на случаи

Последната стъпка е създаване на индивидуални случаи на класове в йерархията. Определяне на индивидуален инстанция на даден клас изисква (1) избор на клас, (2) създаване на индивидуален инстанция на този клас, и (3) попълване на слота стойности. Например, ние можем да създадем индивидуален Chateau-Morgon-Божоле например да представлява определен тип вино Божоле. Chateau-Morgon-Божоле е инстанция на класа Божоле, представляващи всички Божоле вина. Този случай има следните стойности слот, определена (Фигура 5):

· Body: Light
· Color: Red
· Flavor: Delicate
· Tannin level: Low
· Grape: Gamay (instance of the Wine grape class)
· Maker: Chateau-Morgon (instance of the Winery class)
· Region: Beaujolais (instance of the Wine-Region class)
· Sugar: Dry

Фигура 5. Определението на инстанция на клас Божоле. Инстанция Chateua Morgon Божоле от региона Божоле, произведени от Gamay грозде от винарска изба Chateau Morgon. Тя е лека тяло, деликатен аромат, червен цвят, и ниско ниво на танин. Това е сухо вино.

4 Дефиниране на класове и клас йерархия

В този раздел се обсъждат неща, които трябва да се грижа за и грешки, които са лесно да се направи при определяне на класове и клас йерархия (Стъпка 4 от раздел 3). Както споменахме преди, не е единствен правилен йерархия клас за даден домейн. Йерархията зависи от възможните употреби на онтологията, нивото на подробност, че е необходимо за прилагане, личните предпочитания, а понякога и изискванията за съвместимост с други модели. Въпреки това, ние обсъждаме няколко насоки, които да имате предвид, когато развитието на класа йерархия. След определяне на значителен брой нови класове, това е полезно да се изправи отново и да проверите, ако развиващите се йерархия в съответствие с тези насоки.

4.1 Осигуряване клас йерархия е вярна

За «е-» връзка
Клас йерархия представлява «е» връзка: клас А е подклас на B, ако всеки случай на B е например на А. За пример, Шардоне е подклас на Бяло вино. Друг начин да се мисли на таксономичния връзка е като «вид» връзка: Шардоне е един вид бяло вино. А jetliner е един вид на въздухоплавателното средство. Месото е един вид храна.
Подклас на класа представлява концепция, която е «вид» Концепцията, че суперкласа представлява.
Едно вино не е подклас на всички вина
Често срещана грешка моделиране е да се включат единствено и множествено число версия на едно и също понятие в йерархията на бившия подклас на последния. За пример, че е грешно да се дефинира клас вина и клас Wine, като подклас на Вина. След като смятате, че на йерархията, като представляващ «вид на» отношения, става ясно, моделиране грешка: една вината не е един вид вина. Най-добрият начин да се избегне такава грешка е винаги да се използват единствено или множествено число в именуване класове (виж раздел 6 за дискусия за именуване на концепции).
Transitivity на йерархичните отношения
Подклас правоотношение е преходен:
Ако Б е подклас на А и С е подклас на B, C е подклас на А
Например, ние можем да определите клас вино, и след това дефинира клас Бяло вино като подклас на виното. Тогава ние определяме клас Шардоне като подклас на Бяло вино. Transitivity на подклас отношения означава, че класът Шардоне е подклас на Wine. Понякога се прави разграничение между преки подкласове и косвени подкласове. Директен подклас е «най-близките» подклас на класа: не съществуват класове между клас и подклас преките си в йерархията. Това е, няма други класове в йерархията между класа и нейните преки суперкласа. В нашия пример, Шардоне е директен подклас на Бяло вино и не е пряко подклас на виното.
Еволюция на йерархия клас
Поддържането последователна йерархия клас може да се превърне в предизвикателство, тъй като домейните се развива. Например, в продължение на много години, всички зинфандел вина бяха червени. Ето защо, ние дефинираме клас на вина зинфандел, тъй като подклас на Червено вино клас. Понякога, обаче, винари започнаха да натиснете грозде и да отнеме цвят за производство аспекти на гроздето, непосредствено, като по този начин променя цвета на получения вино. По този начин, ние се «бял Зинфандел», чийто цвят е роза. Сега ние трябва да се прекъсне зинфандел клас в два класа на Зинфандел-White Зинфандел и Червения Зинфандел и да ги класифицира като подкласове на вино розе и червено вино.
Класове и имената им
Важно е да се прави разлика между класа и името си:
Класовете представляват концепции в областта, а не думи, които означават тези понятия.
Името на даден клас може да се промени, ако ние изберете различна терминология но самият термин представлява обективна реалност в света. Например, ние може да се създаде клас Скариди, и след това го преименувайте на скариди-клас все още представлява една и съща концепция. Подходящи комбинации от вино, което е посочен скариди ястия трябва да се отнасят до скариди ястия. В по-практическа гледна точка, следното правило трябва да се спазват:
Синоними за една и съща концепция не представляват различни класове
Синоними са просто различни имена за понятие или термин. Ето защо, ние не трябва да има клас, наречен скариди и клас, наречен Скариди, и евентуално клас, наречен Crevette. Напротив, има един клас, име или скариди или скариди. Много системи позволяват да се асоциира списък на синоними, преводи, или имена на представяне с класа. Ако системата не позволява това асоциации, синоними винаги може да бъдат изброени в класа документация.
Избягване клас цикли
Ние трябва да избягват цикли в класа йерархия. Ние казваме, че има цикъл в йерархията, когато някои от клас А, подклас «Б» и в същото време B е суперкласа А. Създаването на такъв цикъл в йерархията възлиза на деклариране, че класовете А и Б са еквивалентни: всички случаи на А са случаи на Б, и всички случаи на B са също копия на А. В действителност, тъй като B е подклас на А, случаи, всички Б трябва да бъдат случаи на клас А. Тъй като А е подклас на B, всички А случаи също трябва да бъдат случаи на клас B.

4.2 Анализиране братя и сестри в йерархията клас

Братя и сестри в клас йерархия
Братя и сестри в йерархията са класове, които са преки подкласовете от същия клас (виж раздел 4.1).
Всички братя и сестри в йерархията, с изключение на тези, които в основата трябва да бъде на същото ниво на всеобщност.
Например, бяло вино и Шардоне, не трябва да се подкласовете от същия клас (да речем, вино). Бяло вино е по-общото понятие от Шардоне. Братята и сестрите трябва да представят концепции, които попадат в обхвата на «по същата линия» по същия начин, че същото ниво раздели в книгата са на същото ниво на всеобщност. В този смисъл, изискванията за клас йерархия са подобни на изискванията за книгата очертае.
Концепциите в основата на йерархията обаче (които често са представени като преки подкласовете на някои много общ клас, като Thing), представляват основни поделения на домейн и не трябва да бъдат подобни концепции.
Колко е твърде много и колко малко е твърде малко?
Няма твърди правила за броя на директните подкласове, че един клас трябва да имат. Въпреки това, много добре структурирана онтологии са между две и една дузина директен подкласове. Ето защо, следните две насоки:
Ако даден клас има само един директен подклас може да има проблем за моделиране или онтология не е пълна.
Ако има повече от дузина подкласовете за даден клас и след това допълнителни междинни категории могат да бъдат необходими.
Първата от двете правила е подобен на набор правило, че списъците никога не трябва да има само една подточка. Например, повечето на червените Бургундия вина са Côtes d’Or вина. Да предположим, че ние искахме да представлява само това мнозинство, тип на Бургундия вина. Бихме могли да се създаде клас Червен Бургундия и тогава един подклас Cotes d’Or (Фигура 6а). Въпреки това, ако в нашето представителство червен Бургундия и Côtes d’Or вина са равностойни по същество (всички червени Burgundy вина са Côtes d’Or вина и всички Côtes d’Or вина са червени Burgundy вина), създаване на Cotes d’Or клас не е е необходимо и не добавя никаква нова информация за представителство. Ако бяхме да се включат Côtes Chalonnaise вина, които са по-евтини Burgundy вина от региона на юг от Côtes d’Or, тогава ние ще създадем две подкласовете на Бургундия клас: Cotes d’Or и Cotes Chalonnaise (фигура 6б).

Фигура 6. Подкласове на Червената Бургундия класа. Като един подклас на класа обикновено се насочва към проблем в моделирането.

Да предположим сега, че ние се изброят всички видове вина като преки подкласовете на Wine клас. Този списък ще включва и такива по-общи вида вино Божоле и Бордо, както и по-специфични видове като Paulliac и Margaux (фиг. 7а). Клас Wine е твърде много преки подкласове и наистина, за онтологията да се отрази на различните видове вино в по-организиран начин, Medoc трябва да се подклас на Бордо и Cotes d’или трябва да бъде подклас на Бургундия. Също така има такива междинни категории като червено вино и бяло вино ще се отрази на концептуалния модел на домейна на вина, че много хора имат (фиг. 7б).
Въпреки това, ако няма естествен класове съществуват група концепции в дългия списък на братя и сестри, няма нужда да се създават изкуствени класове просто оставете класове начина, по който те са. В крайна сметка онтологията е отражение на реалния свят, и, ако не категоризация съществува в реалния свят, тогава онтология трябва да отразяват това.

Фигура 7. Разделяйки вина. Като всички вина и видове вино в сравнение с няколко нива на категоризация.

4.3 множествено наследяване

Повечето системи за представяне на знания позволяват множествено наследяване в йерархията класа: клас може да бъде подклас на няколко класа. Да предположим, че бихме искали да се създаде отделен клас на десертни вина, десертно вино клас. Пристанище вино е червено вино и десертно вино [4] Ето защо, ние определяме Port клас да имат две superclasses: Червено вино и десертно вино. Всички случаи на пристанище клас ще бъдат копия на Червено вино клас и клас десертно вино. Класът пристанище ще наследи слотове и техните аспекти както от неговите родители. По този начин, тя ще наследи на стойност SWEET за слот захар от класа на десертно вино и слота за нивото на танин и стойност за цвета му слот от Червено вино клас.

4.4 Кога да се въведе нов клас (или не)

Една от най-трудните решения, които да направят по време на моделиране е кога да се въведе нов клас или когато представлява разграничение чрез различни стойности на собственост. Трудно е да се движите изключително вложени йерархия с много външни класове и много плоска йерархия, която има твърде малко паралелки с твърде много информация, кодирана в слота. Намирането на подходящ баланс, въпреки че не е лесно.
Има няколко правила на палеца, които помагат да реши кога да се въведе нови класове в йерархията.
Подкласове на класа обикновено (1) имат допълнителни свойства, че суперкласа не, или (2) ограничения, различни от тези на суперкласа, или (3) участват в различни взаимоотношения, отколкото superclasses
Червени вина могат да имат различни нива на танин, като има предвид, че този имот не се използва за описание на вина като цяло. Стойността за захар слот на десертно вино е сладко, като има предвид, че не е вярно на суперкласа от клас десертно вино. Пино Ноар вина могат да вървят добре с морски дарове, докато други червени вина не. С други думи, ще се въведе нов клас в йерархията, обикновено само когато има нещо, което можем да кажем за този клас, че не можем да кажем за на суперкласа.
От практическа гледна точка, всеки подклас трябва да има нови слотове, добавени към него, или са определени нови стойности слот, или да заобиколят някои аспекти за наследените слотове.
Въпреки това, понякога може да е полезно за създаване на нови класове, дори ако те не се въвеждат никакви нови свойства.
Класове в терминологични йерархии не трябва да се въведат нови свойства
Например, някои онтологии включват големи йерархии позоваване на общи термини, използвани в домейна. Например, онтология, която е в основата на електронен медицински запис система може да включва класификация на различни заболявания. Тази класификация може да бъде само, че йерархията на термини, без свойства (или с един и същ набор от свойства). В този случай, тя все още е полезно да се организира в йерархията, а не плоска списък, тъй като (1) ще позволи по-лесно проучване и навигация и (2) да даде възможност на лекаря да избере лесно ниво на всеобщност на термин, който се подходящ за ситуацията.
Друга причина за въвеждане на нови класове без никакви нови имоти е модел понятия, сред които експерти в областта често се направи разграничение, въпреки че ние може да са решили да не модел на самата разлика. Тъй като ние използваме онтологии, за да улесни комуникацията между експерти в областта и между експерти в областта и системи, базирани на знанието, ние бихме искали да отразяват мнението на експерта на домейн в онтологията.
И накрая, ние не трябва да създават подкласове на класа за всеки допълнително ограничение. Например, ние въведохме класовете червено вино, бяло вино, и вино розе, защото това разграничение е естествено едно в света на виното. Ние не въвеждат класове за деликатен вино, умерено вино, и така нататък. При определяне на клас йерархия, нашата цел е да се намери баланс между създаването на нови класове, които са полезни за клас организация и създаването на прекалено много класове.

4.5 нов клас или имущество на стойност?

При моделиране на домейн, ние често трябва да реши дали да се модел конкретна разлика (като бяло, червено или розе вино), като стойността на имота или като набор от класове отново зависи от обхвата на домейн и задачата в ръка .
Ли, ние създаваме клас Бяло вино или не, ние просто се създаде клас вино и попълнете различни стойности за цвят слота? Отговорът обикновено е в обхвата, така че ние определено за онтологията. Колко важна е концепцията на Бяло вино е в нашия домейн? Ако вина имат само маргинално значение в областта, както и дали виното е бяло, няма никакво специално значение за отношенията си към други обекти, тогава ние не следва да въведат отделен клас за белите вина. За домейн модел, използван в завод за производство на вино етикети, правила за етикетите на вино на всеки цвят са едни и същи и разликата не е много важно. Като алтернатива, за представяне на вино, храна и подходящи комбинации от червено вино е много по-различен от бяло вино: тя се свърже с различни храни, има различни свойства, и така нататък. По същия начин, цвета на виното е важно за вината на база от знания, които ние може да използваме, за да се определи-за дегустация на вино. По този начин, ние създаваме отделен клас за бяло вино.
Ако понятия, с различни стойности слот стават ограничения за различни слотове в други класове, тогава ние трябва да създаде нов клас за разграничение. В противен случай, ние представляваме разликата в стойността слот.
По същия начин, нашето вино онтология има такива класове, като Red Мерло и бяло «Мерло», а от един клас за всички вина Мерло: Merlots на червено и бяло Merlots, са наистина различни вина, направени от една и съща гроздов и ако ние се развиват подробно онтология на вино, това разграничение е важно.
Ако разграничение е важно в домейна и мислим за обектите с различни стойности за разграничение, тъй като различните видове обекти, а след това ние трябва да създаде нов клас за разграничение.
Като се имат предвид потенциалните индивидуални случаи на клас също могат да бъдат от полза при вземането на решение дали или не да се въведе нов клас.
Клас, към който принадлежи индивидуален случай не трябва да се променят често.
Обикновено, когато ние използваме неприсъщи, отколкото характерните свойства на понятията, за да се прави разлика между класове, случаи от тези класове ще трябва да мигрират често от един клас в друг. Например, охладени вино не трябва да бъде един клас в онтология, описваща бутилки вино в ресторант. Охладени собственост трябва да бъде само един атрибут на вино в бутилка, тъй като инстанция на Охладени вино лесно може да престане да е инстанция на този клас и след това отново да се превърне в копие на този клас.
Обикновено числа, цветове, места слот ценности и не водят до създаването на нови класове. Вино, обаче, е едно забележително изключение, тъй като цвят на виното е така от първостепенно значение за описанието на вино.
За друг пример, помислете за човешката анатомия онтология. Когато ние представляваме ребра, ние създаваме клас за всеки един от «ляво ребро 1-во», «2-ри лявото ребро», и така нататък? Или имаме класа Rib с прорези за реда и странично положение (ляво-дясно)? [5] Ако информацията за всеки един от ребра, които ние представляваме в онтологията се различава значително, тогава ние действително трябва да се създаде клас за всяка от ребрата. Това е, ако искаме да представляват близост детайли и информация за местоположението (което е различно за всяко ребро), както и специфични функции, които всеки Playa ребро и органи го предпазва, ние искаме класове. Ако ние сме моделиране анатомия в малко по-малка степен на всеобщност, и всички ребра са много сходни, доколкото се отнася до нашите потенциални приложения (говорим само за това, който ребро е разбит на X-Ray без последици за други части на тялото) , ние може да искате да се опрости нашата йерархия и имат само класа ребро, с два слота: странично положение, за.

4.6 Пример или клас?

Вземането на решение дали дадена концепция е един клас в онтология или индивидуален случай зависи от това какво са потенциалните приложения на онтологията. Вземането на решения, където класове края и индивидуални случаи започват да започне да реши какво е най-ниското ниво на обяснения в представителството. Нивото на детайлността, на свой ред се определя от потенциалното приложение на онтологията. С други думи, какви са най-специфичните елементи, които ще бъдат представени в базата от знания? Връщайки се към компетентността въпроси, идентифицирани в Стъпка 1 в раздел 3, най-конкретни понятия, които ще представляват отговорите на тези въпроси са много добри кандидати за физически лица в база от знания.
Отделните случаи са най-специфичните понятия, представени на база от знания.
Например, ако ние само ще да се говори за сдвояване на вино с храна, ние няма да се интересуват в специфични физически бутилки от вино. Ето защо, такива термини като Sterling Лозя Мерло вероятно ще бъде най-специфични термини, които използваме. Ето защо, Стърлинг Лозя Мерло ще бъде инстанция в база от знания.
От друга страна, ако ние бихме искали да се поддържа опис на вина в ресторанта, в допълнение към базата от знания на доброто вино, храна сдвоявания, отделни бутилки от всяко вино може да стане на отделни случаи в нашата база от знания.
По същия начин, ако бихме искали да се записват различни свойства за всеки конкретен реколта Мерло Sterling Лозя, след това специфичните реколта на виното е например в база от знания и Sterling Лозя Мерло е клас, съдържащ случаи за всичките си реколти.
Друго правило може да се «движи» някои отделни случаи, в набор от класове:
Ако концепции образуват естествена йерархия, тогава ние трябва да ги представляват и класове
Помислете за лозаро-винарските области. Първоначално, ние може да се определят основните региони на виното, като Франция, САЩ, Германия, и така нататък, като класове и специфични региони на виното в рамките на тези големи региони като случаи. Например, Bourgogne региона е инстанция на френския региона клас. Въпреки това, ние би искал също така да се каже, че Cotes d’Or областта Бургундия региона. Ето защо, Bourgogne региона трябва да бъде клас (за да има подкласове или случаи). Въпреки това, Bourgogne региона класа и Cotes d’Or регион инстанция на Бургундия район изглежда произволно: тя е много трудно да се разграничи кои региони са класове и случаи. Ето защо, ние определяме всички лозаро-винарски райони като класове. Протеже-2000 позволява на потребителите да определят някои класове като абстрактни, което означава, че в клас не може да има преки копия. В нашия случай, всички класове на региона са абстрактни (Фигура 8).

Фигура 8. Йерархия на лозаро-винарските области. «А» икони до имена показват, че класовете са абстрактни и не може да има преки копия.

Същата йерархия клас би било некоректно, ако бяхме пропуснали думата «район» от имената класа. Не можем да кажем, че класът Елзас е подклас на класа Франция: Елзас не е вид на Франция. Въпреки това, Елзас е един вид френски регион.
Само класове могат да бъдат подредени в йерархия представяне на знания системи не е понятие на под-инстанция. Ето защо, ако има естествена йерархия между условията, като в терминологични йерархии от раздел 4.2, трябва да се определят тези условия, за класове, въпреки че те не могат да имат всички случаи на техните собствени.

4.7 Ограничаване на обхвата

Като последна бележка по определяне на клас йерархия, след набор от правила, винаги е полезно при вземането на решение, когато дефиницията онтология е пълна:
Онтология не трябва да съдържа всички възможни информация за домейна: не е нужно да се специализират (или обобщим) повече, отколкото трябва за вашето приложение (най-много едно допълнително ниво във всяка посока).
За нашето вино и храна например, ние не трябва да знаят какво се използва хартия за етикети или как да се готви скариди ястия.
Аналогично, онтологията не трябва да съдържа всички възможни свойства на и разграничения между класове в йерархията.
В нашата онтология, ние със сигурност не включва всички имоти, че може да има вино или храна. Ние представени най-характерните свойства на класовете на елементите в нашата онтология. Въпреки че вино книги ще ни каже размер на грозде, ние не са включени тези познания. По същия начин, ние не сте добавили всички отношения, които човек може да си представите сред всички условия в нашата система. Например, ние не се включват отношения като любимото си вино и любима храна в онтологията, само за да се позволи по-пълно представителство на всички връзки между условията, които са определили.
Последният правила също се отнася до установяване на отношения между понятия, които вече са включени в онтологията. Помислете онтология, описваща биология експерименти. Онтология-вероятно ще съдържа концепцията на биологичните организми. Тя също така ще съдържа концепцията на експериментатор, който извършва експеримент (с неговото име, принадлежност и др.). Вярно е, че експериментатор, като човек, също се случва да бъде един биологичен организъм. Въпреки това, ние вероятно не трябва да се включи тази разлика в онтологията: за целите на тази декларация експериментатор не е биологичен организъм и ние най-вероятно никога няма да провежда експерименти върху самите експериментатори. Ако бяхме представлява всичко, което можем да кажем за класовете в онтологията, експериментатор ще се превърне в подклас на биологичен организъм. Въпреки това, ние не трябва да включва това знание в обозримо приложения. В действителност, включително и този вид на допълнителна класификация за съществуващите класове всъщност боли: инстанция на експериментатор ще имат слотове за тегло, възраст, вид, и други данни, отнасящи се до биологичен организъм, но е абсолютно без значение в контекста на описва експеримент . Въпреки това, ние трябва да се отбелязва дизайн решение в документацията в полза на потребителите, които ще се търси в тази онтология и които не могат да бъдат наясно с прилагането, имахме предвид.

4.8 непресичащи подкласове

Много системи ни позволяват да се определя изрично, че няколко класа се обърквам. Учебните занятия се обърквам, ако те не може да има общи случаи, в. Например, десерт, вино и Бялата класове на виното в нашата онтология не са непресичащи: има много вина, които са случаи и на двете. Rothermel Trochenbierenauslese Ризлинг например на Sweet клас Ризлинг е един такъв пример. В същото време, червено вино и Бяло вино класове са непресичащи: вино не може да бъде едновременно червено и бяло. Посочване, че класовете са непресичащи се дава възможност на система за валидиране на онтологията по-добре. Ако ние заявяваме Червено вино и Белия класове вино, за да се обърквам и по-късно се създаде клас, който е подклас на двете Ризлинг (подклас на Бяло вино) и Port (подклас на Червено вино), една система може да посочи, че има моделиране грешка.

5 Определяне на свойства-повече детайли

В този раздел ще обсъдят още няколко подробности, за да имате предвид, когато определянето на слотове в онтологията (Стъпка 5 и Стъпка 6 в раздел 3). Преди всичко, ние обсъждаме обратния слотове и стойности по подразбиране за слот.

5.1 Inverse слотове

А стойността на слота може да зависи от стойността на друг слот. Например, ако е произведено виното от избата, винарната произвежда че виното. Тези две отношения, производител и произвежда, се нарича обратна отношения. Съхраняването на информация «и в двете посоки» е излишно. Когато знаем, че виното е произведено от винарна, приложение, с помощта на база от знания, винаги може да се направи извод стойността за обратна връзка, че винарната произвежда вино. Въпреки това, от гледна точка на придобиването на знания, то е удобно за двете парчета на информация изрично. Този подход позволява на потребителите да попълват във виното, в единия случай и винарната в друга .. Система за придобиване на знания биха могли след това автоматично попълване на стойността за обратната връзка застраховане последователност на база от знания.
Нашият пример има двойка на обърнати слотове: производител на слот на класа за виното и произвежда слот на винарната клас. Когато един потребител се създава инстанция на класа за виното и попълва стойност за производителя слот, системата автоматично добавя новосъздадената например произвежда слот на съответната винарна например. Например, когато казваме, че Sterling Мерло се произвежда от Sterling винарна Vineyard, системата автоматично ще се добавят Sterling Мерло към списъка на вина, че Sterling Vineyard винарната произвежда. (Фиг. 9).

Фигура 9. Случаите с обратна слотове. Слотът произвежда за клас Winery е обратнопропорционална на слот машина за клас вино. Попълване в един от слотовете задейства автоматична актуализация на другите.

5.2 Стойности по подразбиране

Много кадър-базирани системи позволяват спецификация на стойности по подразбиране за получаване на слотове. Ако дадена стойност на слотовете е един и същ за повечето случаи на клас, можем да определим тази стойност да бъде на стойност по подразбиране за слота. Тогава, когато всеки се създава нова инстанция на класа, съдържащи този слот, системата попълва стойността по подразбиране автоматично. След това можем да се промени стойността на всяка друга стойност, че фасети ще позволи. Това означава, че стойностите по подразбиране са там за удобство: те не налагат никакви нови ограничения на модела или промяна на модела по никакъв начин.
Например, ако по-голямата част от вината, ние ще обсъдим, са плътен вина, ние може да има «пълно», като стойност по подразбиране за тялото на виното. Тогава, освен ако кажем, в противен случай, всички вина, ние определяме ще да бъде пълноценен.
Имайте предвид, че това е различно от слот стойности. Slot стойности не могат да бъдат променяни. Например, можем да кажем, че слота захар стойност SWEET за клас десертно вино. Тогава всички подкласове и случаи на клас десертно вино ще имат SWEET стойност за слота захар. Тази стойност не може да бъде променена във всеки от подкласовете или екземпляри на класа.

6 Какво е едно име?

Определяне на именуване конвенции за концепции в онтологията и след това стриктно се придържа към тези конвенции не само прави онтологията по-лесно за разбиране, но също така помага да се избегнат някои общи грешки моделиране. Има много алтернативи в именуването на концепции. Често не се дава конкретна причина, за да изберат една или друга алтернатива. Въпреки това, ние трябва да
Определяне на именуване конвенция за класове и слотове, както и да се придържат към него.
Следните характеристики на системата за представяне на знания, оказват влияние върху избора на именуване конвенции:
· Ли системата да имат същото име пространство за класове, слотове, и случаи,? Това е, системата позволява, като клас и слот със същото име (като клас винарна и слот винарна)?
· Дали системата главни и малки букви? Това е система за лечение на имената, които се различават само в случай, тъй като различни имена (като Винарска изба и винарна)?
· Какво разделители системата позволява в имената? Това е, може да чиито имена съдържат интервали, запетайки, звездички, и така нататък?
Протеже-2000, например, поддържа пространство с едно наименование за всички неговите рамки. Тя е с малки букви. По този начин, ние не може да има клас на винарска изба и винарна слот. Ние можем, обаче, има клас Винарна (не горния случай) и слот за винарна. CLASSIC, от друга страна, не се малки и главни букви и поддържа различни пространства име за класове, слотове, и физически лица. Така, от гледна точка на цялостната система, няма проблем в именуването на класа и винарна слот.

6.1 Капитализация и разделители

Първо, ние можем значително да подобри четивността на онтологията, ако ние използваме в съответствие капитализация с концепцията имена. Например, тя е често да се възползва клас имена и да използват по-ниски делото за слот имена (ако приемем, че системата е разлика между главни и малки букви).
Когато името концепция съдържа повече от една дума (като например хранене разбира се), ние трябва да се дефинира думите. Ето някои възможни решения.
· Използвайте Space: брашно, разбира се (много системи, включително и протеже, позволяват пространства в концепцията имена).
· Изпълнение на думите заедно и да се възползва всяка нова дума: MealCourse
• Използвайте подчертавка или тире или други разделител в името: Meal_Course, Meal_course, грис курса, грис разбира се. (Ако използвате разделители, също ще трябва да реши дали или не се капитализират всяка нова дума)
Ако системата за представяне на знания позволява пространства в имената, чрез тях може да бъде най-интуитивно решение за много разработчици онтология. Необходимо е обаче важно да се обмислят други системи, с които вашата система може да взаимодейства. Ако тези системи не се използват интервали или ако Вашата средносрочна представяне не се справят добре пространства, тя може да бъде полезно да се използва друг метод.

6,2 единствено или множествено число

А името на класа представлява колекция от предмети. Например, клас Вино всъщност представлява всички вина. Следователно, тя може да бъде по-естествено за някои дизайнери да се обадя клас Вина, а от виното. Няма алтернатива е по-добре или по-лошо от другите (въпреки че единствено за клас имена се използва по-често в практиката). Въпреки това, независимо от избора, тя трябва да бъде последователен в цялата онтология. Някои системи, дори да налага на потребителите си да декларират предварително, дали те ще се използват единствено или множествено число за концепция за имена и не им позволяват да се отклоняват от този избор.
Използването на една и съща форма през цялото време също така предотвратява дизайнер да прави такива грешки моделиране, като създаване на клас вина и след това създаване на класа на виното като подклас (виж раздел 4.1).

6.3 префикс и суфикс конвенции

Някои методики на базата на знания предполагат използване на префикс и суфикс конвенции в имената, за да се направи разграничение между класовете и слотовете. Две общи практики, за да добавите, или наставка на слот имена. Така, нашите слотове стават е-мейкър и винарна, ако ние избрахме на Конвенцията. Слотове стане производител и винарна на, ако ние избрахме на Конвенцията. Този подход позволява на всеки, който търси в срок, за да се определи веднага, ако срокът е един клас или слот. Въпреки това, терминът имена стават малко по-дълъг.

6.4 Други съображения за именуване

Ето още няколко неща, които трябва да се вземат предвид при определяне на именуване конвенции:
· Не добавяйте низове като «класа», «имущество», «гнездо», и така на концепцията имена.
Той винаги е ясно от контекста, дали концепцията е един клас или един слот, например. В допълнение е да използвате различни именуване конвенции за класове и слотове (да речем, капитализация и не се капитализират), самото наименование ще бъде показателен за това каква е концепцията.
· Това е обикновено е добра идея да се избегнат съкращения в концепцията имена (е, използвайте Каберне Совиньон, а от Cab)
· Имената на преки подкласове на класа или всички трябва да включва или не включва името на суперкласа. Например, ако ние създаваме две подкласове на класа за виното, за да представляват червени и бели вина, две подклас имена трябва да бъдат или червено вино и бяло вино или червено и бяло, но не червено вино и Бяла.

7 Други ресурси

Използвали сме протеже-2000 като онтология развиваща се среда за нашите примери. Duineveld и колеги (Duineveld и др. 2000) описват и сравни броя на други онтология среди за разработка.
Ние се опитахме да се справи с много основите на развитие на онтология и не са обсъдени много теми за напреднали, или алтернативни методологии за развитие на онтология. Gómez-Перес (Gómez-Перес 1998 г.) и Uschold (Uschold и Gruninger 1996) представи алтернативни методологии за развитие на онтология. Ontolingua начинаещи (Фаркуар 1997) обсъжда някои формални аспекти на знания моделиране.
В момента изследователите се подчертае, не само развитието на онтологията, но също анализ на онтологията. Тъй като все повече онтологии са създадени и използвани повторно, повече инструменти ще бъде на разположение, за да анализира онтологии. За пример, Chimaera (Макгинес и др. 2000) предлага диагностични инструменти за анализ на онтологии. В анализа, който извършва Chimaera включва чек за логично коректността на онтология и диагностика на обща онтология дизайн грешки. Един дизайнер онтология може да искате да стартирате Chimaera диагностика върху развитието на онтологията, за да се определи съответствие с общите практики за моделиране на онтология.

8 Заключения

В това ръководство, сме описали онтология методология за развитие на декларативно кадър-базирани системи. Ние изброени стъпки в процеса на развитие на онтологията и се обърна към сложните въпроси, на определяне на клас йерархии и свойства на класове и случаи. Въпреки това, след изпълнение на всички правила и предложения, едно от най-важните неща, които трябва да запомните е следното: не е единствен правилен онтология за всеки домейн. Онтология дизайн е творчески процес и няма две онтологии, проектирани от различни хора, ще бъде същата. Потенциалните приложения на онтологията и разбиране на дизайнера, както и оглед на домейна несъмнено ще повлияе на избора на дизайн онтология. «Доказателството е в пудинг» — можем да се оцени качеството на нашата онтология само като го използва в приложения, за който го е проектирал.

Благодарности

Протеже-2000 (http://protege.stanford.edu) е разработена от групата на Марк Musen в Станфордския медицинска информатика. Ние генерирани на цифрите, с плъгин OntoViz за протеже-2000. Ние внесени първоначалната версия на вино онтология от онтология библиотека Ontolingua (http://www.ksl.stanford.edu/software/ontolingua/), което от своя страна използва версия, публикувана от Brachman и колеги (Brachman и др. 1991) и разпространяват с CLASSIC система за представянето на знания. Ние тогава се изменят, онтологията да представи концептуална принципите на моделиране за декларативен рамка онтологии. Рей Фергерснъ и обширни коментари Mor Фалек на по-ранни проекти значително подобрена тази статия.

Originally at http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html. Translated by All Science