"Скажите мне, какое вино мне нужно купить к каждому из блюд в этом меню. И, кстати, я не люблю Сотерн." Сегодня трудно было бы создать веб-агента, который смог бы выполнить поиск вин в Сети, удовлетворяющих этому запросу. Сходным образом, рассмотрите назначение компьютерному агенту задачи согласования нескольких маршрутов путешествия. (Примеры использования смотрите в документе требований к OWL.) Для поддержки такого рода вычислений необходимо пойти дальше ключевых слов и описать содержание ресурсов, доступных в Сети. Этот дополнительный уровень интерпретации имеет дело с семантикой данных.
Язык веб-онтологий OWL - это язык для определения и представления веб-онтологий. Онтология - термин, заимствованный из философии, который обозначает науку, описывающую формы бытия и то, как они относятся между собой. Веб-отнология может включать описания классов, свойств и их примеры. Формальная семантика OWL описывает, как получить логические следствия, имея такую онтологию, т.е. получить факты, которые не представлены в онтологии буквально, но следуют из ее семантики. Эти следствия могут быть основаны на одном документе или множестве распределенных документов, которые комбинируются с использованием определенных механизмов OWL.
Данный документ - это один из компонентов описания OWL, языка веб-онтологий, разрабатываемого рабочей группой W3C Web Ontology (WebOnt). Раздел Карта документа в Кратком обзоре ([Краткий обзор], 1.1) описывает каждый из этих компонентов и то, как они соотносятся друг с другом.
Вопрос, который возникает, когда описываешь еще один XML/Web стандарт, - это "Что это дает мне, что не могут дать XML и XML Schema?" Есть два ответа на этот вопрос.
- Онтология отличается от схемы XML тем, что это представление знания, а не формат сообщений. Большинство веб-стандартов состоят из комбинации форматов сообщений и спецификаций протоколов. Этим форматам дали эксплуатационную семантику, типа, "По получении сообщения ЗаказНаПокупку, перевести Количество рублей со СчетПокупателя на СчетПродавца и отпустить Товар." Но спецификация не создана для поддержки операций вне контекста данной транзакции. Например, у нас нет, как правило, механизма, чтобы заключить, что из-за того, что Товар имеет название Шардоне, он должен также быть белым вином.
- Одним из преимуществ OWL онтологий будет доступность инструментов, которые могут рассуждать о них. Инструменты обеспечат общую поддержку, которая не является специфической для данной предметной области, что было бы тем случаем, когда надо построить систему, чтобы рассуждать в пределах одной стандартной для данной индустрии XML схеме. Построение четкой и работоспособной системы рассуждения - непростое дело. Строительство онтологии намного более доступно. Мы ожиданием, что много групп предпримут строительство онтологий. Они извлекут выгоду из инструментов третьих лиц, основанных на формальных свойствах языка OWL, инструментов, которые предоставят ассортимент возможностей, которые большинству организаций было бы трудно реализовать самим.
1.1. Виды OWL
OWL обеспечивает три различных по выразительности диалекта, спроектированных для использования отдельными сообществами разработчиков и пользователей.
-
OWL Lite поддерживает тех пользователей, которые нуждаются, прежде всего, в классификационной иерархии и простых ограничениях. Например, притом, что он поддерживает ограничения кардинальности (количества элементов), допускаются значения кардинальности только 0 или 1. Для разработчиков должно быть проще в своих продуктах обеспечить поддержку OWL Lite, чем его более выразительных собратьев, в частности, OWL Lite позволяет быструю миграцию тезаурусов и других таксономий.
-
OWL DL поддерживает тех пользователей, которые хотят максимальной выразительности без потери полноты вычислений (все заключения гарантировано будут вычисляемыми), и разрешаемости рассудочных систем (все вычисления завершатся в определенное время). OWL DL включает все языковые конструкции OWL с ограничениями вроде разделения типа (класс не может быть частным свойством, а свойство не может быть индивидом или классом). OWL DL так назван из-за его соответствия дескриптивной логике [Дескриптивная логика], дисциплине, в которой изучен именно разрешаемый фрагмент логики первого порядка. OWL DL была спроектирована, чтобы поддержать существующий сегмент бизнеса, занимающийся дескриптивной логикой, и иметь желательные вычислительные свойства для систем рассуждения.
-
OWL Full предназначается для пользователей, которые хотят максимальную выразительность и синтаксическую свободу RDF без вычислительных гарантий. Например, в OWL Full класс может одновременно рассматриваться и как совокупность индивидов, и с равным правом как индивид. Другое существенное отличие от OWL DL в том, что owl:DatatypeProperty может быть помечено как owl:InverseFunctionalProperty. OWL Full позволяет такие онтологии, которые расширяют состав предопределенного (RDF или OWL) словаря. Маловероятно, что какое-либо рассудочное программное обеспечение будет в состоянии поддержать полную поддержку каждой особенности OWL Full.
Каждый из этих диалектов - расширение его более простого предшественника, и в том, что касается выразительных возможностей, и в том, что касается возможностей производимых заключений. Поддерживаются следующие отношения, но не наоборот.
- Каждая допустимая OWL Lite онтология - допустимая OWL DL онтология.
- Каждая допустимая OWL DL онтология - допустимая OWL Full онтология.
- Каждое правильное OWL Lite заключение - правильное OWL DL заключение.
- Каждое правильное OWL DL заключение - правильное OWL Full заключение.
Разработчики онтологий, использующие OWL, должны решить, какой из диалектов лучше подходит к их задачам. Выбор между OWL Lite и OWL DL зависит от степени того, насколько пользователям требуются более выразительные конструкции, обеспечиваемые OWL DL. Приложения для OWL Lite будут иметь желаемые вычислительные характеристики. Приложения для OWL DL, при том, что имеют дело с разрешаемым диалектом, в самых тяжелых случаях будут связаны с более высокой сложностью. Выбор между OWL DL и OWL Full, главным образом, зависит от степени того, насколько пользователям требуются средства мета-моделирования RDF Схем (например, определяющие классы классов). При использовании OWL Full, по сравнению с OWL DL, рассудочная поддержка менее предсказуема. Для дальнейшей информации см. Семантика OWL.
Пользователи, мигрирующие из RDF в OWL DL или OWL Lite должны позаботиться о том, чтобы оригинальный RDF-документ выполнял ограничения, наложенные OWL DL и OWL Lite. Детали этих ограничений объясняются в Приложении E Справки по OWL.
Когда мы представляем конструкции, которые разрешаются только в OWL DL или OWL Full, они помечаются "[OWL DL]".
1.2. Структура документа
Чтобы обеспечить связный набор примеров по всему руководству, мы создали онтологии вина и пищи. Это OWL DL онтологии. Те из наших рассуждений, которые будут касаться возможностей OWL Full, будут соответственно помечены. Онтология вина и еды - это существенная модификация элемента библиотеки DAML онтологий с долгой историей. Она была первоначально разработана МакГиннесом как КЛАССИЧЕСКИЙ пример дескриптивной логики, расширенный в учебник по дескриптивной логике и в учебник по онтологиям.
В этом документе мы представляем примеры, использованные в RDF/XML синтаксис ([RDF], 5), предполагая, что XML знаком самой обширной аудитории. Нормативный синтаксис обмена OWL - RDF/XML. Заметьте, что OWL был спроектирован с максимальной совместимостью с RDF и RDF Schema. Форматы XML и RDF - часть стандарта OWL.
Все примеры, представленные в этом документе взяты из онтологий, содержащихся в wine.rdf и food.rdf, кроме отмеченных ¬ в правом нижнем углу.
2. Структура онтологий
OWL - это компонент инициативы Semantic Web. Это попытка сделать веб-ресурсы более доступными для автоматизированных процессов путем добавления информации о ресурсах, которая описывают или обеспечивает веб-контент. Поскольку Семантическая Сеть по определению распределена, OWL должен позволять собирать информацию из распределенных источников. Это частично обеспечивается возможностью онтологий быть связанными, включая прямой импорт информации из других онтологий.
В дополнение, OWL предполагает открытость. То есть, описания ресурсов не ограничены единственным файлом или темой. В то время как класс C1 первоначально может быть определен в онтологии O1, он может быть расширен в других онтологиях. Следствия из этих дополнительных суждений о C1 являются монотонными. Новая информация не может опровергать предыдущую информацию. Новая информация может быть противоречащей, но факты и следствия могут только добавляться, и не могут удаляться.
Возможность таких противоречий - это то, что разработчик онтологии должен учитывать. Ожидается, что инструменты, поддерживающие OWL, помогут обнаруживать такие случаи.
Чтобы написать онтологию, которая может однозначно интерпретироваться и использоваться программными агентами, мы требуем синтаксис и формальную семантику OWL. OWL - это расширение словаря [RDF Semantics] RDF. Семантика OWL определена в документе Семантика и абстрактный синтаксис OWL.
2.1. Namespaces
Прежде, чем мы можем использовать набор конструкций, нам надо точно указать, какие словари используются. Стандартный начальный компонент онтологии включает набор объявлений XML namespace, заключенных в открывающий тэг rdf:RDF. Это обеспечивает возможность однозначно интерпретировать идентификаторы и делает остальную часть представления онтологии более читабельной. Типичная OWL онтология начинается с объявления пространства имен (namespace), подобного следующему. Конечно, URI конкретных онтологий обычно не будут ссылками на w3.org. <rdf:RDF xmlns ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" xml:base ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2001/XMLSchema#">
Первые две декларации идентифицируют namespace, связанный с этой онтологией. Первая делает этот namespace значением по умолчанию, заявляя, что имена тэгов без префиксов относятся к текущей онтологии. Вторая идентифицирует namespace текущей онтологии с приставкой vin:. Третья идентифицирует базовый URI документа (см. ниже). Четвертая идентифицирует namespace вспомогательной пищевой онтологии с префиксом food:.
Пятая namespace декларация говорит, что элементы в этом документе, предваряющиеся owl:, должны пониматься как обращение к понятиям, взятым из namespace, называемого http://www.w3.org/2002/07/owl# . Это - обычная декларация OWL, использованная для ссылки на OWL.
OWL зависит от конструкций, определенных RDF, RDFS, и XML Schema datatypes. В этом документе приставка rdf: обращается к понятиям, взятым из namespace http://www.w3.org/1999/02/22-rdf-syntax-ns# . Следующие две декларации namespace делают похожие объявления RDF Schema (rdfs:) и XML Schema datatype (xsd:) namespaces.
Как помощь в написании длинных URL часто может быть полезным обеспечить ряд определений ENTITY в декларации типа документа (DOCTYPE), которая предшествует определениям онтологии. Названия, определенные в соответствии с namespace декларациями имеют значение только как части тэгов XML. Значения атрибутов - нечувствительны к namespace. Но в OWL мы часто ссылаемся на идентификаторы онтологии, используя значения атрибутов. Они могут быть записаны в полной форме, например "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Мерло". Как альтернатива, сокращения могут быть определены, используя определение ENTITY, например: <!DOCTYPE rdf:RDF [ <!ENTITY vin "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" > <!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" > ]>
После этой пары ENTITY деклараций, мы могли бы писать значение "&vin;Мерло" и это расшифровывалось бы в "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Мерло".
Возможно, более важно то, что декларации rdf:RDF namespace могли бы тогда упроститься, так что изменения в ENTITY декларациях распространились бы на всю онтологию. <rdf:RDF xmlns ="&vin;" xmlns:vin ="&vin;" xml:base ="&vin;" xmlns:food="&food;" xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2001/XMLSchema#">
2.2. Заголовки онтологии
После того, как установлены namespaces, мы обычно включаем коллекцию утверждений о нашей онтологии, сгруппированных под тэгом owl:Ontology. Эти тэги поддерживают такие критические вспомогательные задачи как комментарии, управление версиями и включение других онтологий. <owl:Ontology rdf:about=""> <rdfs:comment>An example OWL ontology</rdfs:comment> <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/PR-owl-guide-20031215/wine"/> <owl:imports rdf:resource="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food"/> <rdfs:label>Wine Ontology</rdfs:label> ...
Заметьте, что мы используем '...', чтобы указать, что есть дополнительный текст, который отброшен в данном примере.
Элемент owl:Ontology - это место, где собрана большая часть метаданных OWL-документа. Это не гарантирует, что документ описывает онтологию в традиционном смысле. В некоторых сообществах создаются онтологии не об индивидах, а только о классах и свойствах, которые определяют предметную область. Используя OWL, чтобы описать коллекцию частных данных тэг owl:Ontology может быть необходим, чтобы записать информацию о версии и импортировать определения, от которых зависит данный документ. Таким образом, в OWL термин онтология был расширен, чтобы включить частные данные (см. выше).
Атрибут rdf:about обеспечивает название или ссылку на онтологию. Если значение атрибута "", то названием онтологии служит базовый URI элемента owl:Ontology. Как правило, это URI документа, содержащего онтологию. Исключение из этого - тот случай, если используется xml:base, который может установить базовый URI элемента на что-нибудь другое, чем URI текущего документа.
rdfs:comment обеспечивает очевидно необходимую возможность аннотировать онтологию.
owl:priorVersion - является стандартным тэгом, предназначенным для поддержки систем управления версиями, работающих с онтологиями. Работа с версиями онтологий обсуждается далее.
owl:imports обеспечивает механизм включения. owl:imports принимает единственный аргумент, обозначенный атрибутом rdf:resource.
Импорт другой онтологии переносит весь набор утверждений, обеспеченных в той онтологии, в текущую онтологию. Чтобы наилучшим образом использовать импортированную онтологию, принято координировать ее с декларацией namespace. Заметьте различие между этими двумя механизмами. namespace декларации обеспечивают удобное средство, чтобы ссылаться на имена, определенные в других OWL онтологиях. Концептуально, owl:imports предназначен для того, чтобы показать Ваше намерение включить все утверждения другой онтологии. Импорт другой онтологии, O2, также импортирует все онтологии, что импортированы в O2.
Заметьте, что owl:imports не всегда может сработать. Как Вы могли бы ожидать, имея дело с Семантической Сетью, доступ к ресурсам, распределенным по Сети, не всегда может быть возможен. Инструментальные средства должны отвечать на эту ситуацию в соответствии с их манерой исполнения.
Заметьте, что для того, чтобы использовать словарь OWL Вам не обязательно нужно импортировать онтологию owl.rdf. В самом деле, такой импорт не рекомендуется.
Один общий набор дополнительных тэгов, которые могли бы быть разумно включены здесь - это некоторые из стандартных тэгов метаданных Dublin Core. Их значениями служат простые типы или строки. Примеры включают Title, Creator, Description, Publisher и Date (см. RDF declarations).
Свойства, которые используются как аннотации, должны быть объявлены, используя owl:AnnotationProperty. Например, <owl:AnnotationProperty rdf:about="&dc;creator" />
OWL обеспечивает несколько других механизмов, чтобы связать текущую онтологию с импортированными вместе (см. картирование онтологий).
Также мы включили rdfs:label, чтобы указать для нашей онтологии метку на натуральном языке.
Определение заголовка онтологии заканчивается следующим тэгом. </owl:Ontology>
За заголовком следуют фактические определения, которые составляют онтологию, и в конечном счете завершаются </rdf:RDF>
2.3. Агрегация данных и секретность
Способность OWL выражать онтологическую информацию об индивидах, содержащихся во множестве документов, принципиальным образом поддерживает связывание данных из разных источников. Лежащая в основе семантика обеспечивает возможность делать выводы из этих данных, что может привести к неожиданным результатам. В частности способность выражать эквивалентность с помощью owl:sameAs может быть использована, чтобы заявить, что как будто бы различные индивиды на самом деле одно и то же. Owl:InverseFunctionalProperty также может быть использовано, чтобы связать индивидов вместе. Например, если такое свойство как "ИНН" является owl:InverseFunctionalProperty, то два отдельных человека могли бы быть расценены как один и тот же на основе того, что они имеют одно и то же значение этого свойства. Когда идентичность индивидов определяется такими средствами, информация о них из разных источников может быть слита. Эта агрегация может использоваться, чтобы определить факты, которые не представлены прямо ни в одном из источников.
Способность Семантической Сети связывать информацию из многих источников - желательное и мощное свойство, которое может использоваться во многих приложениях. Однако, способность объединять данные из многих источников в сочетании с мощью логического вывода OWL, действительно имеет потенциал для злоупотребления. Пользователи OWL должны быть заботиться о потенциальной угрозе секретности. Детальные решения по защите информации были расценены как выходящие за область рассмотрения данной рабочей группой. Множество организаций, занимающихся этими вопросами, предлагает широкий спектр решений по безопасности и секретности. Например, см. SAML и P3P.
3. Основные элементы
Большинство элементов онтологии OWL относятся к классам, свойствам, представителям классов и отношениям между этими представителями. Этот раздел представляет компоненты языка, необходимые для представления этих элементов.
3.1. Простые классы и индивиды
Применение онтологии будут зависеть от предоставляемой ею возможности рассудить об индивидах. Чтобы сделать это удобным, мы должны иметь механизм, чтобы описать классы этих индивидов и свойства, которые они наследуют на основании членства в классе. Мы всегда можем обозначить определенные свойства индивидов, но основная сила онтологий лежит в рассуждениях на основе классов.
Иногда мы хотим подчеркнуть различие между классом как объектом и классом как набором, содержащим элементы. Мы называем набор индивидов, которые являются членами какого-то класса расширением этого класса.
3.1.1. Простые именованные классы Class, rdfs:subClassOf
Наиболее фундаментальные понятия в какой-то области должны соответствовать классам, которые находятся в корне различных таксономических деревьев. Каждый индивид в мире OWL является членом класса owl:Thing. Таким образом каждый определенный пользователем класс автоматически является подклассом owl:Thing. Специфичные для данной области корневые классы определяются простым объявлением именованного класса. OWL также определяет пустой класс, owl:Nothing.
Для области виноделия, которую мы используем в качестве примера, мы создаем три корневых класса: Винодельня, Регион и ПродуктПитания. <owl:Class rdf:ID="Винодельня"/> <owl:Class rdf:ID="Регион"/> <owl:Class rdf:ID="ПродуктПитания"/>
Заметьте, что этим мы только сказали, что существуют классы, которым дали эти имена, обозначенные с помощью 'rdf:ID ='. Формально, мы не знаем почти ничего об этих классах, кроме того, что они существуют, несмотря на использование в качестве меток знакомых русскоязычных терминов. Хотя классы существуют, к ним нельзя отнести никаких индивидов. По тому, что мы знаем в данный момент об этих классах, их можно также назвать Вещь1, Вещь2 и Вещь3.
Важно помнить, что определения могут быть расширяющимися и распределенными. В частности, позже мы должны будем больше конкретизировать понятие Винодельня.
Синтаксис rdf:ID="Регион" используется, чтобы ввести название, как часть его определения. Атрибут rdf:ID ([RDF], 7.2.22) похож на атрибут ID из XML. Теперь внутри этого документа на класс Регион можно ссылаться с помощью #Регион, например, rdf:resource="#Регион". Другие онтологии могут ссылаться на это название, используя его полную форму "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Регион".
Другая форма ссылок использует синтаксис rdf:about="#Регион", чтобы расширить определение ресурса. Использование синтаксиса rdf:about="&ont;#x" - ключевой элемент в создании распределенной онтологии. Это позволяет расширить импортированное определение x, не изменяя оригинал документа и конструировать большие онтологии из блоков.
Теперь можно обратиться к классам, которые мы определили в других OWL конструкциях, используя их же идентификаторы. Для первого класса, заданного в этом документе, мы можем использовать относительный идентификатор, #Винодельня. Возможно, другим документам также потребуется ссылка на этот класс. Самый разумный способ сделать это - обеспечить namespace и определения ENTITY, которые включают определяемый документ в качестве источника: ... <!ENTITY vin "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" > <!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" > ... <rdf:RDF xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" ... > ...
Сделав эти определения мы можем обращаться к классу винодельня или используя XML-тег vin:Винодельня или значение атрибута &vin;Винодельня. Кроме этого, всегда можно сослаться на ресурс, используя его полный URI, в нашем случае http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Винодельня .
Фундаментальным таксономическим конструктором для классов является rdfs:subClassOf. Он связывает более частный класс с более общим классом. Если X - подкласс Y, то каждый представитель X - также представитель Y. Отношение rdfs:subClassOf является транзитивным. Если X - подкласс Y, и Y - подкласс Z, то X - подкласс Z. <owl:Class rdf:ID="Напиток"> <rdfs:subClassOf rdf:resource="#ПродуктПитания" /> ... </owl:Class>
Мы определяем Напиток (жидкость, пригодная для питья) как подкласс ПродуктПитания.
В мире веб-онтологий, оба этих класса могут быть определены в отдельной онтологии, которая обеспечила бы основные строительные блоки для широкого круга пищевых и питьевых онтологий, что мы и сделали - мы определили их в онтологии пища, которая импортирована в онтологию вина. Онтология пищи включает множество классов, например, Пища, СъедобнаяВещь, Блюдо и Моллюски, которые не относятся к знаниям о вине, но должны быть связаны со словарем винных терминов, если мы собираемся совершать полезные рассуждения. Пища и вино взаимозависимы, и нам это пригодится, чтобы идентифицировать подходящие комбинации вина/пищи.
Определение класса состоит из двух частей: указание названия или ссылка и список ограничений. Каждое из непосредственно содержащихся в определении класса выражений ограничивает (уточняет) свойства представителей определенного класса. Представители класса принадлежат к пересечению указанных ограничений. (Хотя см. описание owl:equivalentClass.) Пока мы видели только примеры, которые включают единственное ограничение, обязывающее новый класс быть подклассом некоторого другого именованного класса.
Здесь мы создаем простое (и неполное) определение для класса Вино. Вино - это Напиток. Также мы определяем Паста как СъедобнаяВещь. <owl:Class rdf:ID="Вино"> <rdfs:subClassOf rdf:resource="&food;Напиток"/> <rdfs:label xml:lang="en">wine</rdfs:label> <rdfs:label xml:lang="ru">вино</rdfs:label> <rdfs:label xml:lang="fr">vin</rdfs:label> ... </owl:Class> <owl:Class rdf:ID="Паста"> <rdfs:subClassOf rdf:resource="#СъедобнаяВещь" /> ... </owl:Class>
Конструкция rdfs:label обеспечивает необязательное удобочитаемое название этого класса. Инструментальные средства представления информации пользователю могут его использовать. Атрибут "lang" обеспечивает поддержку разных языков. Конструкция rdfs:label (метка) подобна комментарию и ничего не вносит в логическую интерпретацию онтологии.
Наше определение вина все еще очень неполно. Мы не знаем ничего о винах за исключением того, что они - вещи и напитки, но мы имеем достаточно информации, чтобы создавать индивидов этого класса и производить суждения о них.
3.1.2. Индивиды
В дополнение к классам мы хотим иметь возможность описать их членов. Обычно мы думаем о них как об отдельных индивидах в нашем пространстве вещей. Для определения индивида достаточно объявить его членом какого-то класса. <Регион rdf:ID="РегионЦентральногоПобережья" />
Заметьте, что следующее идентично по значению примеру выше. <owl:Thing rdf:ID="РегионЦентральногоПобережья" /> <owl:Thing rdf:about="#РегионЦентральногоПобережья"> <rdf:type rdf:resource="#Регион"/> </owl:Thing>
rdf:type - это свойство RDF, которое связывает индивида с классом, членом которого он является.
Есть пара моментов, на которых здесь следует остановиться. Во-первых, мы решили, что РегионЦентральногоПобережья (определенная область) является членом Регион, класса, содержащего все географические регионы. Во-вторых, нет никаких требований в примере из двух частей, что эти два элемента должны следовать друг за другом, или даже находиться в одном и том же файле (хотя, в противном случае их названия должны были бы быть расширены с помощью URI). При проектировании веб-онтологий нужно помнить, что они предназначены для распределенной среды. Они могут быть импортированы и расширены, создавая новые производные онтологии.
Чтобы иметь в своем распоряжении еще несколько классов для представления свойств в следующих разделах, мы определяем ветвь таксономии Виноград с индивидом, обозначающим сорт винограда Каберне-Совиньон. Виноград определен в онтологии пищи: <owl:Class rdf:ID="Виноград"> ... </owl:Class>
И теперь в онтологии вина мы имеем: <owl:Class rdf:ID="ВинныйВиноград"> <rdfs:subClassOf rdf:resource="&food;Виноград" /> </owl:Class> <ВинныйВиноград rdf:ID="ВиноградКабернеСовиньон" />
Как обсуждается в следующем разделе, ВиноградКабернеСовиньон - индивид, потому что обозначает один конкретный сорт винограда.
3.1.3. Дизайн для использования
Существуют большие проблемы относительно различия между классом и индивидом в OWL. Класс - это просто название и совокупность свойств, которые описывают набор индивидов. Индивиды - это члены этих наборов. Таким образом, классы должны соответствовать естественно образованным наборам вещей в рассматриваемой области, а индивиды должны соответствовать реальным объектам, которые могут быть сгруппированы в эти классы.
При создании онтологий, это различие часто размывается в двух направлениях:
- Уровни представления: В определенных контекстах что-то, что очевидно является классом, может самостоятельно считаться представителем чего-то еще. Например, в онтологии вина мы имеем понятие Виноград, которое призвано обозначать набор всех разновидностей винограда. ВиноградКабернеСовиньон - пример представителя этого класса, поскольку он обозначает фактический сорт винограда, называемого Каберне-Совиньон. Однако, ВиноградКабернеСовиньон мог бы сам считаться классом, обозначающим набор всех реальных кустов винограда Каберне-Совиньон.
- Подкласс или частный случай: Бывает очень просто спутать отношения по типу представитель-класс с отношением по типу подкласс-надкласс. Например, выбор сделать ВиноградКабернеСовиньон индивидом, являющимся представителем класса Виноград, а не подклассом класса Виноград может показаться чисто произвольным. Но это не произвольное решение. Класс Виноград обозначает набор всех сортов винограда, и поэтому любой подкласс Винограда должен обозначать подмножество этих сортов. Таким образом, ВиноградКабернеСовиньон должен считаться представителем Винограда, и не подклассом. Ведь он не описывает подмножество сортов винограда, он сам является сортом.
Заметьте, что то же самое различие возникает в отношение класса Вино. Класс Вино фактически обозначает набор всех разновидностей вина, но не набор реальных бутылок, которые можно купить. В таком бы случае, каждый представитель класса Вино в нашей онтологии определял бы класс, состоящий из всех бутылок вина данного типа. Достаточно легко вообразить такую информационную систему, типа системы учета для винного торговца, которая должна рассматривать индивидуальные бутылки вина. Чтобы поддержать такую интерпретацию, наша онтология вина, в том виде как она сейчас, потребовала бы возможности рассматривать классы как индивиды. Отметьте, что OWL Full разрешает такую экспрессивность, позволяя нам рассматривать конкретного представителя сорта винограда одновременно как класс, представители которого - бутылки вина.
По той же логике, вина, произведенные винодельнями в определенные годы считаются винтажем. Чтобы представлять понятие винтажа, мы должны определить его место в нашей онтологии. Представитель класса Вино, как обсуждалось выше, представляет конкретный сорт вина, производимого конкретной винодельней, например, FormanШардоне.
Уточнение, что вино, произведенное в 2000 году, считается винтажем, бросает нам вызов, потому что мы не имеем возможности представить подмножество данного индивида вина. Этот винтаж - не новый сорт вина, это - особое подмножество вина - того, что было произведено в 2000 году. Одним из вариантов было бы использовать OWL Full и рассматривать представителей вина как классы с подклассами (подмножествами), обозначающими винтажи. Другой вариант обойти эту проблему - это рассматривать Винтаж как отдельный класс, чьи представители имеют отношение к тому Вину, винтажем которого они являются. Например, FormanШардоне2000 - это индивид класса Винтаж с со свойством являетсяВинтажем, значение которого - индивид класса Вино, FormanШардоне. Мы определим класс Винтаж ниже .
Цель этого обсуждения - показать, что развитие онтологии должно строго подчиняться ее предполагаемому применению. Также эти вопросы подчеркивают одно из главных различий между OWL Full и OWL DL. OWL Full позволяет использовать классы как индивидов, а OWL DL - нет. Онтология вина проектируется, чтобы работать в OWL DL, и поэтому такие индивиды как FormanШардоне не рассматриваются одновременно как классы.
3.2. Простые свойства
Мир классов и индивидов был бы совершенно неинтересным, если бы мы могли только определять таксономии. Свойства позволяют нам утверждать общие факты о членах классов и особые факты об индивидах.
3.2.1. Определение свойств ObjectProperty, DatatypeProperty, rdfs:subPropertyOf, rdfs:domain, rdfs:range
Свойство - это бинарное отношение. Различают два типа свойств:
- свойства-значения, отношения между представителями классов и RDF-литералами или типами данных, определяемых XML Schema
- свойства-объекты, отношения между представителями двух классов. Заметьте, что слово объект в названии не связано с RDF-термином rdf:object ([RDF], 5.3.4).
При определении свойства существует множество способов ограничить это отношение. Можно определить домен и диапазон. Свойство может быть определено как специализация (подсвойство) существующего свойства. Возможны и более сложные ограничения, которые описаны позже. <owl:ObjectProperty rdf:ID="сделаноИзВинограда"> <rdfs:domain rdf:resource="#Вино"/> <rdfs:range rdf:resource="#Виноград"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="блюдо"> <rdfs:domain rdf:resource="#ПриемПищи" /> <rdfs:range rdf:resource="#ВидБлюда" /> </owl:ObjectProperty>
В OWL последовательность элементов без явного указания оператора представляет собой неявное соединение. Свойство сделаноИзВинограда имеет домен Вино и диапазон Виноград. Таким образом, это связывает представителей класса Вино с представителями класса Виноград. Множественные домены означают, что доменом свойства служит пересечение указанных классов (и подобным образом для диапазона).
Точно так же свойство блюдо связывает данный ПриемПищи с каким-то ВидомБлюда.
Заметьте, что использование информации о диапазоне и домене в OWL отличается от информации о типе данных в языках программирования. В частности, в языках программирования типы данных используются, чтобы отслеживать взаимоувязанность кода. В OWL диапазон значений может использоваться, чтобы наследовать тип. Например, из следующего определения: <owl:Thing rdf:ID="LindemansBin65Шардоне"> <сделаноИзВинограда rdf:resource="#ВиноградШардоне" /> </owl:Thing> ¬
мы можем заключить, что LindemansBin65Шардоне - это вино, потому что доменом свойства сделаноИзВинограда является Вино.
Свойства, так же как классы, могут быть организованы в иерархию. <owl:Class rdf:ID="ХарактеристикаВина" /> <owl:Class rdf:ID="ЦветВина"> <rdfs:subClassOf rdf:resource="#ХарактеристикаВина" /> ... </owl:Class> <owl:ObjectProperty rdf:ID="обладаетХарактеристикойВина"> <rdfs:domain rdf:resource="#Вино" /> <rdfs:range rdf:resource="#ХарактеристикаВина" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="имеетЦвет"> <rdfs:subPropertyOf rdf:resource="#обладаетХарактеристикойВина" /> <rdfs:range rdf:resource="#ЦветВина" /> ... </owl:ObjectProperty>
Свойство ХарактеристикаВина связывает вина с их цветом и компонентами вкуса, включая сладость, крепость и букет. имеетЦвет - подсвойство свойства обладаетХарактеристикойВина с более ограниченным диапазоном: ЦветВина. Отношение rdfs:subPropertyOf в этом случае означает, что что-либо со значением X свойства имеетЦвет также имеет свойство обладаетХарактеристикойВина со значением X.
Ниже мы вводим свойство расположенВ, которое связывает вещи с регионами, в которых они расположены. <owl:ObjectProperty rdf:ID="расположенВ"> ... <rdfs:domain rdf:resource="http://www.w3.org/2002/07/owl#Thing" /> <rdfs:range rdf:resource="#Регион" /> </owl:ObjectProperty>
Заметьте, как определены домен и диапазон расположенВ. Домен разрешает быть расположенным в регионе чему угодно, включая сами регионы. И транзитивное использование этого отношения по существу создает сеть географически определенных субрегионов и вещей. Те вещи, в которых ничего не расположено, могут относиться к любому классу, в то время как те, в которых расположены другие вещи, должны являться регионами.
Теперь можно расширить определение Вина, чтобы включить понятие о том, что вино сделано по крайней мере из одного Винограда. Как и с определениями свойств, определения класса имеют многократные подразделы, которые неявно соединены. <owl:Class rdf:ID="Вино"> <rdfs:subClassOf rdf:resource="&food;Напиток"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#сделаноИзВинограда"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> ... </owl:Class>
Выделенное выше ограничение подкласса <owl:Restriction> <owl:onProperty rdf:resource="#сделаноИзВинограда"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction>
определяет неименованный класс, который представляет набор вещей с по крайней мере одним свойством сделаноИзВинограда. Мы называем такие классы анонимными. Включение этого ограничения в определение класса Вино означает, что вещи, являющиеся винами, также являются членами этого анонимного класса. Таким образом, каждое индивидуальное вино должно быть задействованным по крайней мере в одном отношении сделаноИзВинограда.
Теперь мы можем описать класс Винтаж, обсуждаемый ранее. <owl:Class rdf:ID="Винтаж"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#являетсяВинтажем"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> ¬
Свойство являетсяВинтажем связывает Винтаж с Вином. <owl:ObjectProperty rdf:ID="являетсяВинтажем"> <rdfs:domain rdf:resource="#Винтаж" /> <rdfs:range rdf:resource="#Вино" /> </owl:ObjectProperty> ¬
В следующем разделе мы свяжем Винтажи с их годами.
3.2.2. Свойства и типы данных
Мы отличаем свойства по тому, связывают ли они индивидов с индивидами (свойства-объекты) или индивидов с типами данных (свойства-значения). Свойства-значения могут иметь диапазон литералов RDF или простых типов, определенных в XML Schema datatypes.
OWL использует большинство встроенных типов XML Schema. Ссылки на эти типы осуществляются посредством URI для типов http://www.w3.org/2001/XMLSchema. Следующие типы данных рекомендуются для использования с OWL:
xsd:string |
xsd:normalizedString |
xsd:boolean |
xsd:decimal |
xsd:float |
xsd:double |
xsd:integer |
xsd:nonNegativeInteger |
xsd:positiveInteger |
xsd:nonPositiveInteger |
xsd:negativeInteger |
xsd:long |
xsd:int |
xsd:short |
xsd:byte |
xsd:unsignedLong |
xsd:unsignedInt |
xsd:unsignedShort |
xsd:unsignedByte |
xsd:hexBinary |
xsd:base64Binary |
xsd:dateTime |
xsd:time |
xsd:date |
xsd:gYearMonth |
xsd:gYear |
xsd:gMonthDay |
xsd:gDay |
xsd:gMonth |
xsd:anyURI |
xsd:token |
xsd:language |
xsd:NMTOKEN |
xsd:Name |
xsd:NCName |
Вышеупомянутые типы плюс rdfs:Literal формируют встроенные типы данных OWL. Все OWL-рассуждатели обязаны поддерживать типы xsd:integer и xsd:string.
Другие встроенные типы XML Schema могут использоваться в OWL Full, но с предостережениями, описанными в документе Семантика и абстрактный синтаксис OWL. <owl:Class rdf:ID="ГодВинтажа" /> <owl:DatatypeProperty rdf:ID="год"> <rdfs:domain rdf:resource="#ГодВинтажа" /> <rdfs:range rdf:resource="&xsd;positiveInteger"/> </owl:DatatypeProperty>
Свойство год связывает ГодВинтажа со значениями положительного целого числа. Ниже мы вводим свойство имеетГодВинтажа, которое связывает Винтаж с ГодВинтажа.
В Справке по OWL ([Reference], 6.2) описывается использование owl:oneOf, rdf:List и rdf:rest для того, чтобы определить перечисленный тип данных. Пример показывает, как создать owl:DatatypeProperty счетИгрыВТеннис с диапазоном, включающим элементы списка целочисленных значений {0, 15, 30, 40}.
3.2.3. Свойства индивидов
Сначала мы опишем индивидов классов Регион и Винодельня, а затем мы определим наше первое вино, Каберне-Совиньон. <Регион rdf:ID="РегионГорыСантаКруз"> <locatedIn rdf:resource="#РегионКалифорния" /> </Регион> <Винодельня rdf:ID="ВиноградникГораСантаКруз" /> <КабернеСовиньон rdf:ID="КабернеСовиньонВинодельняГораСантаКруз" > <расположенВ rdf:resource="#РегионГорыСантаКруз"/> <имеетПроизводителя rdf:resource="#ВиноградникГораСантаКруз" /> </КабернеСовиньон>
Это определение все еще неполно. Есть другие аспекты винного букета, которые определены в полной онтологии. Но части срастаются воедино. Мы уже могли бы начать рассуждать о том, к каким пунктам меню в нашей онтологии пищи подошло бы это вино. Из последнего определения мы знаем, что его изготавливают на винограднике Гора Санта-Круз. Поскольку это Каберне-Совиньон (см. wine.rdf), мы знаем, что это - сухое красное вино.
Подобным образом к индивидам могут быть добавлены свойства-значения. Ниже мы описываем представителя класса ГодВинтажа и связываем его с определенным значением типа &xsd;positiveInteger. <ГодВинтажа rdf:ID="Год1998"> <год rdf:datatype="&xsd;positiveInteger">1998</год> </ГодВинтажа>
3.3. Характеристики свойств
Следующие несколько разделов описывают механизмы, используемые для более точного определения свойств. Существует возможность определить характеристики свойства, что обеспечивает мощный механизм для усовершенствованного рассуждения о свойстве.
3.3.1. TransitiveProperty
Если свойство P, определено как транзитивное, тогда для любого x, y, и z: P(x,y) и P(y,z) предполагают P(x,z)
Свойство расположенВ является транзитивным. <owl:ObjectProperty rdf:ID="расположенВ"> <rdf:type rdf:resource="&owl;TransitiveProperty" /> <rdfs:domain rdf:resource="&owl;Thing" /> <rdfs:range rdf:resource="#Регион" /> </owl:ObjectProperty> <Регион rdf:ID="РегионГорыСантаКруз"> <расположенВ rdf:resource="#РегионКалифорния" /> </Регион> <Регион rdf:ID="РегионКалифорния"> <расположенВ rdf:resource="#РегионСША" /> </Регион>
Из-за того, что РегионГорыСантаКруз расположенВ РегионКалифорния, он также должен быть расположенВ РегионСША, поскольку свойство расположенВ - транзитивное.
3.3.2. SymmetricProperty
Если свойство P помечено как симметрическое, тогда для любого x и y: P(x,y) если P(y,x)
Свойство прилегаетКРегиону - симметричное, тогда как расположенВ - нет. Если быть более точным, расположенВ не предназначено, чтобы быть симметричным. Но в настоящее время ничто в онтологии вина не препятствует ему быть симметричным. <owl:ObjectProperty rdf:ID="прилегаетКРегиону"> <rdf:type rdf:resource="&owl;SymmetricProperty" /> <rdfs:domain rdf:resource="#Регион" /> <rdfs:range rdf:resource="#Регион" /> </owl:ObjectProperty> <Регион rdf:ID="РегионMendocino"> <расположенВ rdf:resource="#РегионКалифорния" /> <прилегаетКРегиону rdf:resource="#РегионSonoma" /> </Регион>
РегионMendocino прилегает к РегионSonoma и наоборот. РегионMendocino расположен в РегионКалифорния, но не наоборот.
3.3.3. FunctionalProperty
Если свойство P помечено как функциональное, тогда для любого x, y и z: P(x,y) и P(x,z) предполагают y = z
В нашей онтологии вина свойство имеетГодВинтажа функционально. Всякое вино имеет уникальный год винтажа. Таким образом, данный индивидуальный Винтаж может быть связан только с единственным годом, используя свойство имеетГодВинтажа. При этом owl:FunctionalProperty не требует, чтобы все элементы домена имели значения. Смотрите обсуждение кардинальности Винтажа. <owl:Class rdf:ID="ГодВинтажа" /> <owl:ObjectProperty rdf:ID="имеетГодВинтажа"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> <rdfs:domain rdf:resource="#Винтаж" /> <rdfs:range rdf:resource="#ГодВинтажа" /> </owl:ObjectProperty>
3.3.4. inverseOf
Если свойство P1, помечено как owl:inverseOf P2, то для всех x и y: P1(x,y) если P2(y,x)
Заметьте, что синтаксис для owl:inverseOf берет в качестве аргумента название свойства. A если B означает (A предполагает B) и (B предполагает A). <owl:ObjectProperty rdf:ID="имеетПроизводителя"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="производитВино"> <owl:inverseOf rdf:resource="#имеетПроизводителя" /> </owl:ObjectProperty>
У Вин есть производители, которые по определению класса Вино ограничены Винодельнями. Тогда каждая Винодельня производит набор вин, которые идентифицируют ее как производителя.
3.3.5. InverseFunctionalProperty
Если свойство P помечено как обратно функциональное, то для всех x, y и z: P(y,x) и P(z,x) предполагает y = z
Обратите внимание, что производитВино в предыдущем разделе обратно функциональное. Причина этого в том, что свойство, обратное функциональному свойству, должно быть обратно функциональным. Мы могли бы определить имеетПроизводителя и производитВино следующим образом, и получили бы тот же эффект, как и в предыдущем примере. <owl:ObjectProperty rdf:ID="имеетПроизводителя" /> <owl:ObjectProperty rdf:ID="производитВино"> <rdf:type rdf:resource="&owl;InverseFunctionalProperty" /> <owl:inverseOf rdf:resource="#имеетПроизводителя" /> </owl:ObjectProperty> ¬
Рассматривайте элементы диапазона обратно функционального свойства как определение ключевого поля при построении баз данных. 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. <owl:Class rdf:ID="Вино"> <rdfs:subClassOf rdf:resource="&food;Напиток" /> ... <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#имеетПроизводителя" /> <owl:allValuesFrom rdf:resource="#Винодельня" /> </owl:Restriction> </rdfs:subClassOf> ... </owl:Class>
Производителем Вина должна быть Винодельня. Ограничение allValuesFrom на свойство имеетПроизводителя накладывается только для этого класса Вино. Производителей Сыра это локальное ограничение не касается.
owl:someValuesFrom действует похожим образом. Если бы мы в последнем примере заменили owl:allValuesFrom на owl:someValuesFrom, то это означало бы, что по крайней мере одно из свойств имеетПроизводителя для каждого Вино должно указывать на индивида класса Винодельня. <owl:Class rdf:ID="Вино"> <rdfs:subClassOf rdf:resource="&food;Напиток" /> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#имеетПроизводителя" /> <owl:someValuesFrom rdf:resource="#Винодельня" /> </owl:Restriction> </rdfs:subClassOf> ... </owl:Class> ¬
Различие между этими двумя формулировками - это различие между универсальным и экзистенциальным определением количества.
Отношение |
Результат |
allValuesFrom |
Для всех вин, если они имеют производителей, все производители - винодельни. |
someValuesFrom |
Все вина имеют хотя бы одного производителя, который является винодельней. |
Первое отношение не требует, чтобы вино имело производителя. Если у него есть один или более производителей, то все они должны быть винодельнями. Второе отношение требует, чтобы был по крайней мере один производитель-винодельня, но также могут быть производители, которые не винодельни.
3.4.2. Кардинальность
Мы уже видели примеры указания кардинальности. До текущего момента это были указания минимальной кардинальности. Более точно это был параметр owl:cardinality, который позволяет указать точное количество элементов в связи. Например, мы указали, что у класса Винтаж есть строго один ГодВинтажа. <owl:Class rdf:ID="Винтаж"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#имеетГодВинтажа"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Мы задали свойство имеетГодВинтажа как функциональное, что то же самое, как если сказать, что каждый Винтаж имеет не более одного ГодВинтажа. Применение этого свойства к Винтаж с использованием ограничения кардинальности задает более строгое отношение, что каждый Винтаж имеет строго один ГодВинтажа.
Выражения кардинальности со значениями, ограниченными 0 или 1 являются частью OWL Lite. Это позволяет пользователю уточнить отношения 'по меньшей мере один', 'не более одного' и 'точно один'. Позитивные целочисленные значения кроме 0 и 1 разрешены в OWL DL. owl:maxCardinality может использоваться для указания верхнего предела. owl:minCardinality может использоваться для указания нижнего предела. В комбинации друг с другом они могут использоваться для ограничения кардинальности свойства в пределах числового интервала.
3.4.3. hasValue [OWL DL]
hasValue позволяет нам определять классы, основанные на существовании специфических значений свойства. Следовательно, индивид будет членом такого класса всякий раз, когда по крайней мере одно из его значений свойства будет равно ресурсу, указанному с помощью hasValue. <owl:Class rdf:ID="Бургундское"> ... <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#имеетСладость" /> <owl:hasValue rdf:resource="#Сухое" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Здесь мы объявляем, что все Бургундские вина - сухие. То есть, их свойство имеетСладость должно иметь по крайней мере одно значение, равное Сухое.
Как и для allValuesFrom и someValuesFrom, это локальное ограничение. Оно относится к свойству имеетСладость только в отношении Бургундского.
4. Картирование онтологий
Для того, чтобы онтологии имели максимальный эффект, они должны быть широко распространены. А чтобы минимизировать интеллектуальные усилия, затрачиваемые на разработку онтологий, они должны быть пригодными для многократного использования. В лучшем из всех возможных варианте они должны быть составлены из компонентов. Например, Вы могли бы воспользоваться онтологией даты из одного источника и онтологией физического местоположения из другого, и затем расширить понятие местоположения, включив в него период времени, в течение которого данное местоположение сохраняется.
Важно понять, что большая часть усилий по разработке онтологии посвящена связыванию вместе классов и свойств так, чтобы максимально точно передать заложенный в понятия смысл. Мы хотим, чтобы простые утверждения о членстве в классе имели широкие и полезные последствия. Это - самая сложная часть разработки онтологии. Если Вы можете найти существующую онтологию, которая уже широко используется и хорошо проработана, то имеет смысл приспособить ее для своих нужд.
Также заманчиво будет слить воедино целую коллекцию онтологий. В этом случае помощь специального инструментария будет почти наверняка необходима для поддержания согласованности.
4.1. Эквивалентность между классами и свойствами equivalentClass, equivalentProperty
Чтобы связать вместе ряд онтологий, входящих в качестве компонентов в какую-то третью онтологию, часто полезно иметь возможность указать, что данные класс или свойство в одной онтологии эквивалентны классу или свойство во второй онтологии. Эта способность должна использоваться с осторожностью. Если объединенные онтологии являются противоречащими (все А - это Б, в другой все А - это не Б), то не будет никакого расширения (ни индивидов, ни отношений), который удовлетворяли бы получающуюся комбинацию.
В онтологии пищи мы хотим связать особенности вина в описаниях обеденных блюд обратно с онтологией вина. Один из способов сделать это - определить класс в онтологии пищи (&food;Wine), а затем объявить его эквивалентным существующему классу вина в винной онтологии. <owl:Class rdf:ID="Вино"> <owl:equivalentClass rdf:resource="&vin;Вино"/> </owl:Class>
Свойство owl:equivalentClass используется, чтобы показать, что два класса имеют абсолютно одинаковых представителей. Заметьте, что в OWL DL классы просто обозначают наборы индивидов, но не самих индивидов. Однако, в OWL Full мы можем использовать owl:sameAs между двумя классами, чтобы показать, что они идентичны во всех отношениях.
Конечно, пример выше несколько запутанный, так как мы всегда можем использовать &vin;Вино везде, где мы использовали бы #Вино, и получали бы при этом тот же самый эффект без переопределения. Более оправданное использование было бы в случае, если б мы зависели от двух независимо созданных онтологий, и заметили, что они используют URI O1:foo и O2:bar для ссылки на один и тот же класс. Чтобы свести их вместе, мог бы использоваться owl:equivalentClass, т.е., чтобы постулаты от этих двух онтологий были объединены.
Мы уже видели, что выражения класса могут быть адресатами конструкций rdfs:subClassOf. Также они могут быть адресатом owl:equivalentClass. Опять таки, это избавляет от необходимости изобретать названия для каждого выражения класса и обеспечивает мощную способность определения, основанную на удовлетворении характеристик свойств. <owl:Class rdf:ID="ТехасскиеВещи"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="#расположенВ" /> <owl:someValuesFrom rdf:resource="#РегионТехас" /> </owl:Restriction> </owl:equivalentClass> </owl:Class> ¬
ТехасскиеВещи - это именно те вещи, что расположены в Техасском Регионе. Различие между таким использованием owl:equivalentClass и использованием rdfs:subClassOf - это различие между условиями "необходимого" и "необходимого и достаточного". В случае использования subClassOf вещи, расположенные в Техасе не обязательно должны относится к классу ТехасскиеВещи. Но при использовании owl:equivalentClass все, что расположено в Техасе, должно быть в классе ТехасскиеВещи.
Отношение |
Результат |
subClassOf |
ТехасскиеВещи(x) предполагает расположенВ(x,y) и РегионТехас(y) |
equivalentClass |
ТехасскиеВещи(x) предполагает расположенВ(x,y), и РегионТехас(y) расположенВ(x,y) и РегионТехас(y) считается ТехасскиеВещи(x) |
Чтобы связать подобным образом свойства, мы используем owl:equivalentProperty.
4.2. Идентичность между индивидами sameAs
Этот механизм похож на тот, что для классов, но объявляет идентичными двух индивидов. Примером может быть: <Вино rdf:ID="ЛюбимоеВиноМихаила"> <owl:sameAs rdf:resource="#StGenevieveТехасскоеБелое" /> </Вино> ¬
Данный пример не несет большой пользы. Все, что мы узнаем из него - это то, что Михаил любит недорогое местное вино. Более типично использовать sameAs для того, чтобы приравнять друг с другом индивидов, определяемых в разных документах с целью унифицировать две онтологии.
Здесь мы сталкиваемся с важным моментом. В OWL нет допущения об уникальном имени. То, что два имени отличны друг от друга, не означает, что они обозначают различных индивидов.
В последнем примере мы провозгласили идентичность между двумя разными именами. Но такой вид идентичности также можно получить путем вывода. Вспомните следствия, которые могут быть получены из функциональное свойства. При том, что свойство имеетПроизводителя - функциональное, следующий пример не обязательно приведет к конфликту. <owl:Thing rdf:about="#BancroftШардоне"> <имеетПроизводителя rdf:resource="#Bancroft" /> <имеетПроизводителя rdf:resource="#Beringer" /> </owl:Thing> ¬
В том случае, если это не находится в противоречии с другой информацией в нашей онтологии, это просто означает, что Bancroft = Beringer.
Заметьте, что использование sameAs для того, чтобы приравнять два класса - это не то же самое, что приравнивание их с помощью equivalentClass; это заставляет классы быть интерпретируемыми как индивиды, а этого достаточно, чтобы отнести онтологию к категории OWL Full. В OWL Full sameAs может использоваться, чтобы приравнять что-угодно: класс и индивида, свойство и класс, и т.д., и приводит к тому, что оба параметра интерпретируются как индивиды.
4.3. Различность индивидов differentFrom, AllDifferent
Этот механизм обеспечивает эффект, противоположный sameAs. <СладостьВина rdf:ID="Сухое" /> <СладостьВина rdf:ID="Сладкое"> <owl:differentFrom rdf:resource="#Сухое"/> </СладостьВина> <СладостьВина rdf:ID="Полусухое"> <owl:differentFrom rdf:resource="#Сухое"/> <owl:differentFrom rdf:resource="#Сладкое"/> </СладостьВина>
Это - один из способов утверждать, что эти три значения взаимно отличны. В ряде случаев важно гарантировать такие неперекрывающиеся характеристики. Без таких утверждений мы могли б описать такое вино, которое было бы и Сухое, и Сладкое одновременно. Теперь же мы заявили, что свойство hasSugar, характеризующее вино, не может иметь более одного значения. Если бы мы допустили ошибку и утверждали бы, что вино одновременно и Сухое, и Сладкое, без тех элементов differentFrom, что указаны выше, это подразумевало бы, что Сухое и Сладкое идентичны. С элементами - мы вместо этого получили бы противоречие.
Существует более удобный мех |