Вищезазначені типи плюс rdfs: Literal формують вбудовані типи даних OWL. Все OWL-рассуждателі зобов'язані підтримувати типи xsd: integer і xsd: string.
Інші вбудовані типи XML Schema можуть використовуватися в OWL Full, але з застереженнями, описаними в документі Семантика і абстрактний синтаксис OWL.
Властивість рік пов'язує ГодВінтажа зі значеннями позитивного цілого числа. Нижче ми вводимо властивість імеетГодВінтажа. яке пов'язує Вінтаж з ГодВінтажа.
У Довідці по OWL ([Reference], 6.2) описується використання owl: oneOf. rdf: List і rdf: rest для того, щоб визначити перерахований тип даних. Приклад показує, як створити owl: DatatypePropertyсчетІгриВТенніс з діапазоном, що включає елементи списку цілочисельних значень.
Спочатку ми опишемо індивідів класів Регіон і Винарня. а потім ми визначимо наше перше вино, Каберне-Совіньйон.
Це визначення все ще неповно. Є інші аспекти винного букета, які визначені в повній онтології. Але частини зростаються воєдино. Ми вже могли б почати міркувати про те, до яких пунктах меню в нашій онтології їжі підійшло б це вино. З останнього визначення ми знаємо, що його виготовляють на винограднику Гора Санта-Круз. Оскільки це Каберне-Совіньйон (див. Wine.rdf), ми знаємо, що це - сухе червоне вино.
Подібним чином до індивідам можуть бути додані властивості-значення. Нижче ми описуємо представника класу ГодВінтажа і пов'язуємо його з певним значенням типу &xsd;positiveInteger.
Наступні кілька розділів описують механізми, використовувані для більш точного визначення властивостей. Існує можливість визначити показники якості, що забезпечує потужний механізм для вдосконаленого міркування про властивості.
3.3.1. TransitiveProperty
Якщо властивість P, визначено як транзитивне, тоді для будь-якого x, y, і z:
Властивість расположенВ є транзитивним.
Через те, що РегіонГориСантаКрузрасположенВРегіонКаліфорнія. він також повинен бути расположенВРегіонСША. оскільки властивість расположенВ - транзитивне.
3.3.2. SymmetricProperty
Якщо властивість P позначено як симетрична, тоді для будь-якого x і y:
Властивість прілегаетКРегіону - симетричне, тоді як расположенВ - немає. Якщо бути більш точним, расположенВ не призначене, щоб бути симетричним. Але в даний час ніщо в онтології вина не перешкоджає йому бути симетричним.
РегіонMendocino прилягає до РегіонSonoma і навпаки. РегіонMendocino розташований в РегіонКаліфорнія. але не навпаки.
3.3.3. FunctionalProperty
Якщо властивість P позначено як функціональне, тоді для будь-якого x, y і z:
У нашій онтології вина властивість імеетГодВінтажа функціонально. Будь-яке вино має унікальний рік винтажа. Таким чином, даний індивідуальний Вінтаж може бути пов'язаний тільки з єдиним роком, використовуючи властивість імеетГодВінтажа. При цьому owl: FunctionalProperty не вимагає, щоб всі елементи домену мали значення. Дивіться обговорення кардинальності Вінтаж.
3.3.4. inverseOf
Якщо властивість P1, позначено як owl: inverseOf P2, то для всіх x і y:
Зауважте, що синтаксис для owl: inverseOf бере в якості аргументу назву властивості. A якщо B означає (A передбачає B) і (B передбачає A).
У Вин є виробники, які за визначенням класу Вино обмежені виноробні. Тоді кожна Винарня проводить набір вин, які ідентифікують її як виробника.
3.3.5. InverseFunctionalProperty
Якщо властивість P позначено як назад функціональне, то для всіх x, y і z:
Зверніть увагу, що проізводітВіно в попередньому розділі назад функціональне. Причина цього в тому, що властивість, протилежне функціональному властивості, має бути назад функціональним. Ми могли б визначити імеетПроізводітеля і проізводітВіно наступним чином, і отримали б той же ефект, як і в попередньому прикладі.
Розглядайте елементи діапазону назад функціонального властивості як визначення ключового поля при побудові баз даних. owl: InverseFunctional передбачає, що елементи діапазону забезпечують унікальний ідентифікатор для кожного елемент домену.
В OWL Full ми можемо помітити DatatypeProperty як назад функціональне. Це дозволяє нам ідентифікувати рядок як унікальний ключ. В OWL DL літерали (строкові значення) відокремлені від owl: Thing, і тому OWL DL не дозволяє застосовувати InverseFunctional до DatatypeProperty.
3.4. обмеження властивостей
На додаток до позначення характеристик властивостей, можна різними способами ще більше обмежити діапазон властивості в певних контекстах. Ми робимо це за допомогою обмежень властивостей. Різні способи, описані нижче, можуть використовуватися тільки в контексті owl: Restriction. Елемент owl: onProperty вказує на обмежується властивість.
3.4.1. allValuesFrom, someValuesFrom
Ми вже розглянули один спосіб обмежувати типи елементів, які утворюють властивість. До сих пір ці механізми були глобальними в тому сенсі, що вони ставилися до всіх представників даного властивості. Наступні два, allValuesFrom і someValuesFrom - локальні по відношенню до містить їх класу.
Обмеження owl: allValuesFrom вимагає, щоб для кожного представника даного класу, який має ця властивість, все значення цієї властивості були представниками класу, заданого в пункті owl: allValuesFrom.
Виробником Вина повинна бути Винарня. Обмеження allValuesFrom на властивість імеетПроізводітеля накладається тільки для цього класу Вино. Виробників Сиру це локальне обмеження не стосується.
owl: someValuesFrom діє схожим чином. Якби ми в останньому прикладі замінили owl: allValuesFrom на owl: someValuesFrom. то це означало б, що принаймні одна з властивостей імеетПроізводітеля для кожного Вино має вказувати на індивіда класу Винарня.
Різниця між цими двома формулюваннями - це відмінність між універсальним і екзистенційним визначенням кількості.
Всі вина мають хоча б одного виробника, який є виноробнею.
Перше ставлення не вимагає, щоб вино мало виробника. Якщо у нього є один або більше виробників, то всі вони повинні бути виноробними. Друге ставлення вимагає, щоб був принаймні один виробник-виноробня, але також можуть бути виробники, що не виноробні.
Ми вже бачили приклади вказівки кардинальності. До теперішнього моменту це були вказівки мінімальної кардинальності. Більш точно це був параметр owl: cardinality. який дозволяє вказати точну кількість елементів в зв'язку. Наприклад, ми вказали, що у класу Вінтаж є строго один ГодВінтажа.
Ми задали властивість імеетГодВінтажа як функціональне, що те ж саме, як якщо сказати, що кожен Вінтаж має не більше одного ГодВінтажа. Застосування цієї властивості до Вінтаж з використанням обмеження кардинальності задає більш суворе ставлення, що каждийВінтаж має строго один ГодВінтажа.
Вирази кардинальності зі значеннями, обмеженими 0 або 1 є частиною OWL Lite. Це дозволяє користувачеві уточнити відносини 'щонайменше один', 'не більше одного' і 'точно один'. Позитивні цілочисельні значення крім 0 і 1 дозволені в OWL DL. owl: maxCardinality може використовуватися для вказівки верхньої межі. owl: minCardinality може використовуватися для вказівки нижньої межі. У комбінації один з одним вони можуть використовуватися для обмеження кардинальності властивості в межах числового інтервалу.
hasValue дозволяє нам визначати класи, засновані на існуванні специфічних значень властивості. Отже, індивід буде членом такого класу щоразу, коли принаймні одне з його значень властивості дорівнюватиме ресурсу, зазначеному за допомогою hasValue.
Тут ми оголошуємо, що всі Бургундські вина - сухі. Тобто, їх властивість імеетСладость повинно мати принаймні одне значення, рівне Сухе.
Як і для allValuesFrom і someValuesFrom. це локальне обмеження. Воно відноситься до властивості імеетСладость тільки щодо Бургундського.
Для того, щоб онтології мали максимальний ефект, вони повинні бути широко поширені. А щоб мінімізувати інтелектуальні зусилля, витрачені на розробку онтологій, вони повинні бути придатними для багаторазового використання. В кращому з усіх можливих варіанті вони повинні бути складені з компонентів. Наприклад, Ви могли б скористатися онтологією дати з одного джерела і онтологією фізичного місця розташування з іншого, і потім розширити поняття місця розташування, включивши в нього період часу, протягом якого дане розташування зберігається.
Важливо зрозуміти, що велика частина зусиль по розробці онтології присвячена зв'язуванню разом класів і властивостей так, щоб максимально точно передати закладений у поняття сенс. Ми хочемо, щоб прості твердження про членство в класі мали широкі і корисні наслідки. Це - найскладніша частина розробки онтології. Якщо Ви можете знайти існуючу онтологію, яка вже широко використовується і добре опрацьована, то має сенс пристосувати її для своїх потреб.
Також заманливо буде злити воєдино цілу колекцію онтологій. У цьому випадку допомога спеціального інструментарію буде майже напевно необхідна для підтримки узгодженості.
4.1. Еквівалентність між класами і властивостями
equivalentClass. equivalentProperty
Щоб зв'язати разом ряд онтологій, що входять в якості компонентів в якусь третю онтологію, часто корисно мати можливість вказати, що дані клас або властивість в одній онтології еквівалентні класу або властивість у другій онтології. Ця здатність повинна використовуватися з обережністю. Якщо об'єднані онтології є такими, що суперечать (всі А - це Б, в іншій всі А - це не Б), то не буде ніякого розширення (ні індивідів, ні відносин), який задовольняли б підсумкову комбінацію.
В онтології їжі ми хочемо зв'язати особливості вина в описах обідніх страв назад з онтологією вина. Один із способів зробити це - визначити клас в онтології їжі (&food;Wine), а потім оголосити його еквівалентним існуючого класу вина у винній онтології.
Властивість owl: equivalentClass використовується, щоб показати, що два класи мають абсолютно однакових представників. Зауважте, що в OWL DL класи просто позначають набори індивідів, але не самих індивідів. Однак, в OWL Full ми можемо використовувати owl: sameAs між двома класами, щоб показати, що вони ідентичні у всіх відносинах.
Звичайно, приклад вище кілька заплутаний, так як ми завжди можемо використовувати &vin;Вино всюди, де ми використовували б # Вино. і отримували б при цьому той же самий ефект без перевизначення. Більш виправдане використання було б в разі, якщо б ми залежали від двох незалежно створених онтологій, і помітили, що вони використовують URI O1: foo і O2: bar для посилання на один і той же клас. Щоб звести їх разом, міг би використовуватися owl: equivalentClass. тобто щоб постулати від цих двох онтологій були об'єднані.
ТехасскіеВещі - це саме ті речі, що розташовані в Техаському Регіоні. Різниця між таким використанням owl: equivalentClass і використанням rdfs: subClassOf - це відмінність між умовами "необхідного" і "необхідного і достатнього". У разі використання subClassOf речі, розташовані в Техасі не обов'язково повинні відноситься до класу ТехасскіеВещі. Але при використанні owl: equivalentClass все, що розташоване в Техасі, має бути в класі ТехасскіеВещі.
Ця програма надає посилання на введення в стандарти, від яких залежить OWL.
Щоб повністю розуміти синтаксис OWL і семантику, Ви повинні бути знайомі з основами близьких W3C і IETF стандартів, що вказані нижче. Мінімальна знайомство з XML і RDF забезпечують перші два посилання із запропонованих нижче.
Першим мовою, визначеною W3C для того, щоб представляти семантичну інформацію про довільних ресурсах був Resource Description Framework (RDF). RDF Schema (RDFS) - це кандидат в рекомендації W3C для розширення RDF, щоб описувати RDF-словники. RDFS може використовуватися, щоб створювати онтології, але він гранично легкий, з меншою виразною потужністю, ніж OWL.
Як і OWL, RDFS включає класи і властивості, а також обмеження діапазону і домену для властивостей. Він забезпечує ієрархії успадкування як для класів, так і для властивостей. Після його випуску користувачі почали просити додаткові особливості, включаючи типи даних, перерахування та можливість більш строго визначати властивості.
Інші спроби досліджень в даній області вже розробляли саме ці види особливостей. Для тих, хто бажає глибше розібратися в цих питаннях, пропонуємо частковий список проектів і мов:
Щоб не продовжувати працювати з окремими мовами онтологій для Семантичної Мережі, група дослідників, серед яких багато з головних учасників проектів OIL і DAML-ONT, об'єдналася в Joint US / EU ad hoc Agent Markup Language Committee. щоб створити нову мову веб-онтологій. Ця мова DAML + OIL. побудований на базі OIL і DAML-ONT, був запропонований в W3C як передбачувана основа для OWL, і був згодом обраний як відправна точка для OWL.
На додаток до мов онтологій, різні таксономії і існуючі онтології вже знаходяться в комерційному використанні. В сайтах електронної комерції вони полегшують комунікацію за допомогою комп'ютера між покупцем і продавцем, уможливлюють вертикальну інтеграцію ринків і дозволяють описами багаторазово використовуватися на різних ринках. Приклади сайтів, які фактично створюють онтології для комерційного використання, включають:
- VerticalNet Вертикальна Мережа в даний час містить 59 галузевих e-ринків, які охоплюють різноманітні галузі промисловості, такі як виробництво, зв'язок, енергія і охорону здоров'я.
Розроблено різні медичні або фармацевтичні онтології, щоб допомогти керувати величезною масою даних сучасних медичних і біохімічних досліджень, які буває важко пов'язати разом в єдине ціле. Один з головних ресурсів Консорціум генних Онтологій. який визначає онтології для
- молекулярних функцій,
- біологічних процесів,
- клітинних компонентів.
Цей сайт також має покажчики на онтології для
- послідовних атрибутів,
- атрибутів продуктів генів,
- хімічних речовин,
- шляхів,
- анатомія,
- патологій,
- фізичних характеристик,
- атрибутів експериментів,
- класифікацій.
Сьогодні знаходяться у використанні великі таксономії, яка були б готові для впровадження в OWL-простір. Наприклад, Північноамериканська Система Класифікації Промисловості (NAICS) визначає ієрархію з більш ніж 1900 елементів, які ідентифікують типи промисловості. NAICS також пов'язана з Міжнародною Системою Класифікації Індустріальних Стандартів (ISIC, Ревізія 3), розробленої і підтримуваної Організацією Об'єднаних Націй.
Це перша версія документа, яка була переведена на російську мову. Зміни в вихідної англійської версії см. В оригінальному документі