W3C
Данный документ представляет собой перевод на русский язык спецификации OWL Web Ontology Language Use Cases and Requirements, W3C Recommendation 10 February 2004, английский вариант которой является единственным официальным изданием.
Перевод данной спецификации на русский язык выполнен специалистом компании ООО "КПП Ранат" Рабчевским Е.А.
Перевод может содержать ошибки и неточности, и мы работаем над его улучшением. Все комментарии, касающиеся настоящего перевода, просьба направлять по адресу: evgeny@ranat.ru
Copyright © 2006 Ранат, Все права защищены. Перевод на русский язык.

OWL Язык Сетевых онтологий
Варианты использования и требования

Рекомендация W3C от 10 февраля 2004

Последняя версия оригинала:
http://www.w3.org/TR/webont-req/
Предыдущая версия оригинала:
http://www.w3.org/TR/2003/PR-webont-req-20031215/
Автор оригинала:
Джэф Хэфлин(Университет Лехай) heflin@cse.lehigh.edu
Автор перевода:
Рабчевский Евгений (Пермский Государственный Университет) evgeny@ranat.ru

Аннотация

Этот документ описывает варианты использования, задачи и требования для языка сетевых онтологий. Онтология формально описывает полный набор понятий, которые используются, чтобы описать и представить предметную область. Онтологии могут быть использованы автоматизированными средствами для таких передовых служб, как более точный веб поиск, интеллектуальные программные агенты и управление знаниями.

Статус этого документа

Этот документ был проверен членами W3 и другими заинтересованными группами, и был одобрен директором, как W3C Рекомендация. Роль W3C в создании рекомендаций состоит в том, чтобы обратить внимание на спецификацию и продвигать повсеместное внедрение. Это повысит функциональность и интер-операбельность сети.

Это одна из шести частей рекомендаций W3C для OWL, языка сетевых онтологий. Документ был разработан рабочей группой Сетевых Онтологий, как части работ W3C по Семантической Сети (Официальный отчет Рабочей группы, Устав Группы) для публикации на 10 февраля 2004.

Схема OWL, выраженная в предыдущих версиях этих документов, была сильно пересмотрена и отвечает требованиям техническим требованиям Рабочей группы. Рабочая группа рассматривала все присланные замечания , делая соответствующие изменения, если это необходимо. Изменения для этого документа, начиная с предложенной версии Рекомендации, детально указаны в журнале изменений.

Замечания принимаются на public-webont-comments@w3.org (архив) дискуссии общего характера по связанным технологиям принимаются на www-rdf-logic@w3.org (архив).

Доступен список реализаций

W3C имеет авторские права на список всех патентов, связанных с этой работой.

Эта секция описывает статус этого документа на момент публикации. Другие документы могут заменить этот документ. Список текущих публикаций и последних ревизий этого технического отчета может быть найдена в каталоге технических отчетов W3C at http://www.w3.org/TR/.

Содержание



1 Введение

Семантическая Сеть это прообраз будущего сети, в которой информации дается точное значение, это делает простым автоматическую обработку и интеграцию машинами информации, доступной в сети. Семантическая Сеть будет построена на способности XML, определять пользовательские схемы тегов [XML] и гибкому подходу при представлении данных в RDF [RDF Понятия]. Следующий элемент, требуемый для Семантической Сети это язык сетевых онтологий, который может формально описать семантику классов и свойств, используемых в веб документах. Для того, чтобы машины успешно выполняли задачи по рассуждению об этих документах, язык должен идти дальше семантики RDF схемы [RDF Терминология].

Этот документ - это часть спецификации OWL, языка веб онтологий. Секция Сетевой Граф документа - Обзор OWL описывает каждый из других документов. Этот документ перечисляет требования к языку веб онтологий, которые поставила рабочая группа. Однако вероятно, что будущие языки расширят OWL, добавляя помимо всего прочего, большие логические возможности и способность укрепить веру в успех Семантической Сети.

Мы мотивируем потребность в языке веб онтологий описанием шести вариантов использования. Некоторые из этих вариантов использования основаны на попытках сегодняшнего дня реализовать это в промышленности и науке, другие демонстрируют более долгосрочные возможности. Варианты использования, следующие за целями разработки, в которых описываются технические требования высокого уровня и руководящие принципы для разработки языка. Эти цели разработки будут приняты во внимание, когда будут оценены предполагаемые возможности. Секция Требования представляет набор возможностей, которым следует быть в языке, и объясняет необходимость этих характеристик /возможностей. Секция Технические требования определяет список возможностей, которые были бы полезными для многих вариантов использования, но необязательных для рассмотрения рабочей группой.

Устав рабочей группы языка веб онтологий обязывает группу производить более выразительные семантические конструкции и специфицировать механизмы, которыми язык может обеспечить "более сложные отношения между сущностями, включая: средства ограничения свойств классов в отношении к экземпляру и типу, средства для вывода, что элементы с различными свойствами являются членами конкретных классов, хорошо описанные модели наследования свойств, и подобных семантических расширений к базовому языку". Детальная спецификация языка веб онтологий будет рассматривать:

1.1 Что такое онтология?

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

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

Обычно онтологии выражаются на языке, основанном на логике, которая детализирована, точна, непротиворечива, обоснованна, и явно могла бы разделять классы, свойства и отношения. Некоторые средства для работы с онтологиями могут выполнять автоматические рассуждения используя онтологии, и тем самым обеспечить продвинутые сервисы для интеллектуальных приложений таких как: концептуальный/семантический поиск, программные агенты, поддержка решений, распознавание речи и естественного языка, управление знаниями, интеллектуальные базы данных и электронная коммерция.

Онтологии играют важнейшую роль в появлении Семантической Сети, как представления семантики документов и возможности использовать эту семантику сетевыми приложениями и интеллектуальными агентами. Онтологии могут оказаться свою полезность для общества, как способ структуризации и описания значений терминов метаданных, которые накапливаются и стандартизуются в настоящий момент. Используя онтологии, приложения будущего смогут быть "интеллектуальными", в том смысле, что они смогут более точно работать на уровне человеческих понятий.

Онтологии решающий фактор для приложений, которые хотят осуществлять широкий поиск или интегрировать информацию из различных источников. Хотя описание типа документов XML и схема XML достаточны для обмена данными между элементами, которые заранее приняли эти описания, их недостаток семантики не позволяет машинам надежно выполнять эти задачи, данные в новых XML словарях. Один и тот же термин может использоваться (иногда неразличимыми) различными значениями в разных смыслах, и разные термины могут быть использованы для элементов, которые имеют одно и тоже значение. RDF и схема RDF начинают подходить к этой проблеме, позволяя ассоциировать простую семантику с идентификаторами. Со схемой RDF вы можете определить классы, которые могут иметь множественные подклассы и суперклассы, определить свойства, которые могут иметь подсвойства, домены и диапазоны. В этом смысле схема RDF это простейший язык онтологий. Однако, чтобы достигнуть интер-операбельности между многочисленными, автономно разработанными и управляемыми схемами, необходима более богатая семантика. На пример RDF схема не может специфицировать, что Персона и Машина являются непересекаемыми классами, или что струнный квартет, в состав котрого входят именно четыре музыканта.

Одна из целей этого документа определить, что необходимо для языка сетевых онтологий. Эти требования будут определяться возможными вариантами использования и основными техническими требованиями разработки, которые примут во внимание затруднения в применении стандартного представления онтологий в уникальную среду Сети.

2 Варианты использования

Онтологии могут быть использованы, чтобы усовершенствовать существующие сетевые приложения и сделать возможным новые варианты использования Сети. В этой секции мы опишем шесть типичных вариантов использования сетевых онтологий. Заметьте, что это не исчерпывающий список, а срез интересующих вариантов использования. Эти варианты использования послужили руководящими принципами в выборе требований для языка OWL (смотри Секция 4). Требования были выбраны, основываясь на аспектах вариантов использования, которые рабочая группа сочла важными, когда рассматривала аспекты устава OWL и другие моменты разработки. По существу мы не должны предполагать, что OWL будет поддерживать все аспекты вариантов использования.

2.1 Веб порталы

Веб портал - это веб сайт, который предоставляет информационный контент общей тематики, например про определенный город или область интересов. Веб портал позволяет отдельным пользователям, которые интересуются темой, получать новости, найти и рассказать друг другу, объединиться в сообщество, и найти ссылки на другие веб ресурсы из общих интересов.

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

Однако, простая индексация предметной области не может обеспечить сообщество дополнительными возможностями искать контент, который требуется членам сообщества. Для того чтобы позволить более интеллектуальное публичное представление веб порталы могут определить онтологии для сообщества. Эта онтология может обеспечить терминологию для описания контента и аксиом, которые описывают термины, используя другие термины из онтологии. Например, онтология может включать такую терминологию, как "статья журнала", "публикация", "персона" и "автор". Эта онтология может включать определения, которые заявляют такие вещи, как "все журнальные статьи есть публикации" или "авторы всех публикаций это люди". Если соединить с фактами, эти определения позволяют другим фактам, которые с необходимостью правдивы, быть логически выведены. Эти выводы могут в свою очередь позволить пользователям получать результаты поиска от портала, которые не возможно получить от традиционных поисковых систем. Такой метод основан на использовании языка веб онтологий контент провайдерами для получения отношений в онтологии высокого качества, и технических требованиях OWL, которые делают возможным контент с совершенно широкими возможностями и полезными метаданными, чтобы оправдать необходимые усилия. Это особая попытка минимизировать эти труды, язык онтологий, вероятно будет иметь огромный импульс, если это сможет продвинуть получение метаданных, как проблемную часть процесса создания информации.

Один пример портала, основанного на онтологиях, это OntoWeb. Этот портал полезен образовательному и промышленному сообществу, которое интересуется разработками онтологий. Другой пример портала, который использует технологии Семантической Сети и может получить выгоду от языка онтологий это Проект открытой директории; огромный, всеобъемлющий редактируемый человеком веб каталог. Он создавался и поддерживается огромным, мировым сообществом авторов добровольцев. RDF карта база данных Проекта открытого каталога доступна для скачивания.

2.2 Мультимедиа коллекции

Онтологии могут быть использованы для того, чтобы обеспечить семантическую аннотацию для коллекций изображений, звуковых и других нетекстовых объектов. Это даже сложнее для машин, извлекать поддающуюся интерпретации семантику из мультимедиа, чем семантику из текстов на естественном языке. Таким образом, такие типы ресурсов обычно индексируются с помощью надписей или метатегов. Однако, так как разные люди могут описывать эти нетекстовые объекты различными способами, это важно, что функциональность поиска превышает простой поиск по ключевым словам. В идеале онтологии будут получать дополнительные знания о предметной области, которые могут быть использованы для более совершенного поиска изображений.

Мультимедиа онтологии могут быть двух типов: специализирующие по типу данных и по тематике контента. Онтологии классифицирующие по типу медиа, могут иметь таксономии различных типов данных и описывать свойства различного медиа. Например, видео может включать свойства необходимые для того, чтобы идентифицировать длину клипа и разрывы на сцены. Онтологии классифицирующие по тематике контента могли бы описывать предмет ресурса, такие как окружающая обстановка или участники (setting or participants). Так как такие онтологии специфицируют медиа, они могли бы быть повторно использованы другими документами, которые имеют дело с той же предметной областью. Такое повторное использование может улучшить поиск, который просто ищет информацию по определенной теме, безотносительно к формату ресурса. Поиски, где тип медиа важен, могли бы комбинировать медиа-специфичные и контент-специфичные онтологии.

Как пример мультимедиа коллекции рассмотрим архив изображений старинной мебели. Онтология старинной мебели была бы классным решением в поиске по такому архиву. Таксономия может быть использована, чтобы классифицировать различные типы мебели. Это было бы также полезным, если бы онтология могла выражать знания определений. Например, если индексатор выбирает значение "Из конца эпохи Георгов" для стиль/период для комода, из этого следует возможность вывести, что элемент данных "дата.созданно" должен иметь значение между 1760 и 1811 нашей эры, и что "культура" - британская. Доступность такого типа фоновых знаний значительно увеличивает поддержку того, что может быть выдано при индексации, также хорошо, как и при поиске. Другая особенность, которая может быть полезной, это поддержка представления знаний "по умолчанию". Примером таких знаний может быть то, что "Ящик комода поздней эпохи Георгов" в отсутствии другой информации предположительно сделан из красного дерева. Это знание ключевое для реальных семантических запросов, например запрос пользователя "старинная мебель для хранения из красного дерева" мог бы сопоставить изображения ящиков комода поздней эпохи Георгов, даже если ничего не сказано о типе дерева в аннотации изображения.

2.3 Управление корпоративным веб сайтом

Крупные корпорации обычно имеют многочисленные веб страницы касающиеся вещей, подобных пресс-релизам, предложениям продуктов и детального изучения готовых решений, принципам работы корпорации, представлению своих товаров и сопоставлению, официальным документам и описанию производственных процессов. Онтологии могут быть использованы, чтобы индексировать эти документы и обеспечить лучшие средства поиска. Хотя многие крупные организации имеют таксономии для организации их информации, этого часто оказывается недостаточно. Одиночная онтология зачастую ограничивается, потому что образующие категории скорее всего сводятся к категориям, представляющим один вид и степень глубины предметной области; возможность одновременно работать с множеством онтологий увеличило бы богатство описания. К тому же возможность искать значения по различным параметрам часто более полезно, чем поиск по ключевым словам в таксономии.

Веб сайт с доступными онтологиями может использоваться:

Типичные проблемы для каждого типа из этих пользователей - это то, что они не могут совместно использовать терминологию автора желаемого контента. Продавец может не знать техническое название для желаемой функциональности, или технические специалисты в разных случаях могут использовать различные термины для одного и того же понятия. В таких случаях было бы полезно, чтобы каждый класс пользователей имел свою онтологию терминов, но все онтологии были взаимно связаны, тогда бы перевод осуществлялся автоматически.

Другая проблема составление запросов на должном уровне абстракции. Руководитель проекта ищет кого-то с опытом в операционных системах, ему нужно иметь возможность разместить сотрудника, который эксперт как в юникс, так и в виндоус.

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

2.4 Разработка документации

Этот вариант использования для технической документации огромного объема, такой как та, которая используется аэрокосмической промышленности. Эта документация может быть нескольких различных типов, включая документацию разработки, документацию производства и документацию тестирования. Эти пакеты документов имеют иерархическую структуру, но структура различается для разных пакетов. Здесь есть также подразумеваемые основные линии, которые взаимоувязывают пакеты документации: например в документах аэрокосмической разработки такой элемент, как лонжерон крыла может присутствовать в каждом.

Онтологии могут быть использованы для того, чтобы строить информационные модели, которые позволяют изучать информационное пространство в терминах тех элементов, которые представлены, ассоциаций между элементами, свойств элементов и ссылок на документацию, которая описывает и определяет их (то есть внешние обстоятельства для существования этого элемента в модели). То есть, онтологии и таксономии не зависят от физических элементов, которые они представляют, но могут разрабатываться/изучаться совместно.

Конкретный пример этого примера использования - это разработка документации для аэро-космической предметной области, где основные пользователи это:

Чтобы поддержать этот вид использования, важно чтобы ограничения могли быть описанны. Эти ограничения могут быть использованы чтобы улучшить поиск или проверить консистентность. Примером ограничения может быть:

biplane(X) => CardinalityOf(wing(X)) = 2
wingspar(X) AND wing(Y) AND isComponentOf(X,Y) => length(X) < length(Y)

Другое общее использование этого вида онтологии - это поддержка визуализации и редактирования диаграмм, которые показывают кадры пространства информации об определенных концептах (например, класс или экземпляр) Это обычно диаграммы активности/правил или диаграммы сущность-связь.

2.5 Агенты и службы

Семантическая Сеть может предоставить агентам способность понимать и интегрировать разнообразные информационные ресурсы. Специфический пример - это планировщик действий для сообщества, который может выбирать предпочтения пользователя (такие, как какие виды фильмов они любят, какой вид еды они любят есть, и т.д.) и использовать эту информацию, чтобы спланировать действия пользователя на вечер. Задача планирования этих действий будет зависеть от предлагаемого разнообразия услуг и потребностей пользователя. В течение определения/ процесса сопоставления, градации и поиска сервисов, также они могут обсуждаться, чтобы найти более близкое соответсвие предпочтениям пользователя (например, обращение к обзорам, рецензиям на фильмы, и рейтингам фильмов и ресторанов, чтобы найти "лучшее").

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

Города агентов является пример инициативы, которая исследует использование агентов в распределенной среде сервисов в Internet. Это приведет к разработке сети агентных платформ, которые представляют реальные или виртуальные города, такие как Сан-Франциско или Территория Покупок, и заполнение их сервисами этих городов. Первоначально, эти сервисы будут ориентироваться на бизнес потребительских услуг, типа гостиниц, ресторанов, развлечений, и т.д., но в конечном счете, они будут расширены, чтобы включить услуги бизнес для бизнеса, типа платежной отчетности, и бизнеса для корпоративных услуг.

Это потребует ряд онтологий предметных областей и сервисов: Ключевые проблемы включают:

2.6 Распределенные вычисления

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

Ключевая технология специализированной сети - это обнаружение (discovery) сервисов. Функциональность, с помощью которой "сервисы" (то есть, функции, предлагаемые различными устройствами, типа сотовых телефонов, принтеров, датчиков, и т.д.) могут быть описываться, рекламироваться, и обнаружаться другими. Все современные механизмы исследования сервисов и описания способностей (например, JINI от Sun, UPNP от Microsoft) основаны на моментальных схемах представления и жестко полагаются на стандартизацию (то есть, на предварительной идентификации всех тех вещей, к которым хотелось бы подключиться или общаться).

Ключевая проблема(и цель) распределенных вычислений это "связанная со счастливой случайностью интер-операбельность" интер-операбельность в неуправляемых ("unchoreographed") условиях, то есть, устройства, которые не разрабатывались, чтобы обязательно работать вместе (такие как, которые сделаны для разных целей, разными производителями, в разное время и т.д.) должны быть способными обнаруживать функциональность друг друга и получать от этого преимущества. Быть способными "понимать" другие устройства и судить об их сервисах/функциональности это необходимо, так как полноценные сценарии распределенных вычислений вовлекут дюжину если не сотню устройств, и предварительная стандартизация сценариев использования - нерешаемая задача.

Сценарии взаимодействия - динамические по природе (то есть, устройства появляются и исчезают в любой момент, когда их владелец вносит их из одной комнаты или здания в другое), и не вовлекает людей в процесс по мере того, как необходима переконфигурация. Задачи, вовлеченные в использование сервисов включают обнаружение, заключение контрактов на предоставление услуг (contracting) и композицию. Взаимодействие сервисов может включать представление информации о безопасности, секретности и доверии, так же как и о деталях, связанных с возмещением (провайдер сервисов может быть должным возместить предоставленные сервисы). В частности, это цель, чтобы корпоративные или организационные политики безопасности выражались в приложение-независимой форме, таким образом, делая возможным ограничения представления для разнообразия механизмов принуждения (например, фаерволы, фильтры/сканеры, мониторы трафика, программные маршрутизаторы и балансировщики загрузки).

Таким образом, язык онтологий будет использоваться, чтобы описать характеристики устройств, средства доступа к этим устройствам, политики, установленные пользователем для использования устройства, и другие технические ограничения и требования, которые затрагивают включение устройства в сеть распределенных вычислений. Потребности, установленные для DAML-S (особенно обсуждаются проблемы выразительности языка), и основанные на RDF схемы для представления информации о характеристиках устройств (а именно Конфигурация Композиции/Профили Предпочтений (W3C's Composite Capability/ Preference Profile (CC/PP)) и Профили Агентов Пользователей WAP Форумов (Forum's User Agent Profile or UAProf)) непосредственно связанные с этим вариантом использования и инфраструктурой ресурсов, которая будет поддерживать приложения, которые будут общаться (negotiate) и динамически конфигурировать сети с моментальной конфигурацией.

3 Цели разработки

Постановка задач описывает основные назначения языка, которые не обязательно вытекают из каждого варианта использования. Параллельно с Вариантами использования, они также определяют Требования и Технические требования в 4 и 5 секциях. В этой секции мы опишем восемь целей разработки для языка веб онтологий, в особенности они связаны с:

Для каждой цели, мы описываем задачу, которая поддерживается, и объясняем оправданность цели. Мы также описываем степень, в которой поддерживается цель в RDF и RDF схеме.

3.1 Совместно используемые онтологии

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

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

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

Зачастую, общедоступных онтологий недостаточно. Организация может определить, что существующая онтология обеспечивает 90% того, что требуется, но оставшиеся 10% переломны. В таких случаях организации не следует создавать новую онтологию на скорую руку, вместо этого можно создать онтологию, которая расширяет существующую онтологию и добавляет желаемые идентификаторы и определения.

RDF схема Поддерживает:
В RDF, каждая схема имеет свое пространство имен, идентифицируемое как URI. Каждый ресурс в схеме имеет идентификатор, и уникальный идентификатор в глобальном смысле может быть создан с помощью комбинирования идентификатора с URI пространством имен. Однако RDF - это неясное определение терминов, которые имеют особенные определения в разнообразных схемах. Спецификация появляется, чтобы представить, что определения это объединение всех описаний, которые используют те же идентификаторами, безотносительно к источникам. Однако, это может привести к проблемам в распределенной среде, где некоторые схемы могут содержать некорректные или ложные определения. Не другого выхода от указания в RDF ресурсах, какой набор он поддерживает.

3.2 Эволюция онтологий

Онтология может меняться с течением своей жизни. Источникам данных необходимо указывать версию онтологии, к которой это относится.

Важная проблема, являются ли документы, которые поддерживаются для одной версии онтологии, совместимыми с теми, которые поддерживаются в других. Должны быть доступны как совместимые, так и совместимые редакции, но следует быть способным различать их друг от друга. Заметьте, что так как формальные описания только обеспечивают соответствия для большинства идентификаторов, для редакций, возможно изменить значения идентификаторов по умолчанию без изменения формальных описаний. Таким образом, описание семантики прошлой совместимости требует больше, чем простого сравенения описаний терминов. По существу, автор онтологий должен быть способным явно указать такие изменения.

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

Обоснование принимаемого технического решения:
Так как Сеть постоянно растет и изменяется, мы должны ожидать такого же изменения онтологий. Онтологии могут нуждаться в изменениях, потому что в предыдущих версиях были ошибки, потому что выбираются новые методы моделирования предметной области, или была создана новая терминология (например, как результат изобретения новой технологии). Язык сетевых онтологий должен быть способен предоставлять редакцию онтологий. Заметьте, что эволюция онтологии отличается от расширения онтологии, которая не меняет оригинальной онтологии.

RDF схема Поддерживает:
Спецификация RDF схемы рекомендует, чтобы каждая версия схемы должна быть отдельным ресурсом со своим URI. Свойства rdfs:subClassOf и rdfs:subPropertyOf могут использоваться для того, чтобы связать новые версии классов и свойств со старыми версиями. Однако, это имеет недостаток в том, что некорректные определения не могут отбрасываться. Например, представим, что в схеме v1, v1:Дельфин это rdfs:subClassOf v1:Рыба. Когда эта ошибка замечена, новая версия схемы v2, говорит, что v2:Дельфин это rdfs:subClassOf v2:Млекопитающее. Однако, если мы сделаем v2:Дельфин rdfs:subClassOf v1:Дельфин, тогда мы также говорим, что v2:Дельфин это rdfs:subClassOf v1:Рыба, что сохранит ошибку.

3.3 Интер-операбельность онтологий

Различные онтологии могут моделировать одни и те же понятия различными путями. Языку следует обеспечить базисные элементы для установления отношений разных представлений, таким образом, позволяя данным быть конвертированными в разные онтологии и быть "сетевыми онтологиями".

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

Обоснование принимаемого технического решения:
Хотя общедоступные онтологии и расширения онтологий допускают определенную степень интер-операбельности между различными организациями и доменами, есть много случаев, где есть различные способы моделирования одной и той же информации. Это может быть благодаря разнице взглядов различных организаций, разных профессий, разных национальностей, и т.д. Для того, чтобы машины могли интегрировать информацию, которая относится к гетерогенным онтологиям, необходимо существование базовых элементов, которые позволяют онтологиям картировать онтологии с их эквивалентами в других онтологиях.

RDF схема Поддерживает:
RDF обеспечивает минимальную поддержку интер-операбельности средствами свойств rdfs:subClassOf and rdfs:subPropertyOf.

3.4 Детекция противоречий

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

Поддерживаемые Задачи:
Любые варианты использования, в которых децентрализация данных и недостаток контролирующего авторитета может привести к конфликтам в данных. Любые задачи расширения онтологий, которые могут привести к несвязанным описаниям (возможно с помощью расширения онтологии в некоторой степени, которое генерируется связанным понятием).

Обоснование принимаемого технического решения:
Сеть децентрализованна, что позволяет любому сказать что угодно. В результате, разные точки зрения могут противоречить друг другу, или даже предоставлять ложную информацию. Для того, чтобы предостеречь агентов от объединения несовместимых данных, или от взятия консистентных данных и приведения в противоречивое состояние, очень важно чтобы противоречия обнаружались автоматически.

RDF схема Поддерживает:
RDF и RDF схема не позволяет выражать противоречия.

3.5 Баланс выразительности и расширяемости

Язык должен быть способным выражать широкое разнообразие знаний, но так же должен предоставлять эффективные средства для рассуждения ими. Так как эти два требования обычно взаимо исключаемы, задача языка веб онтологий - это найти баланс, который поддержит возможность выражать большинство важных видов знаний.

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

Обоснование принимаемого технического решения:
В сети уже свыше биллиона страниц, и потенциальное приложение Семантической Сети для встроенных устройстви агентов ставит вопрос о даже больших объемах информации, чем теми, которыми можно управлять. Язык веб онтологий должен поддерживать системы рассуждения, которые хорошо сопоставимы. Однако, язык так же должен на столько выразительным, насколько это возможно, чтобы пользователи определить виды знаний, которые важны в их приложениях.

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

RDF схема Поддерживает:
RDF легко расширяема (за исключением XML синтаксиса, который крайне многосоловен), но не очень выразительна.

3.6 Простота использования

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

Поддерживаемые Задачи:
Разметка и запросы пользователей к документам семантической сети прямо или косвенно.

Обоснование принимаемого технического решения:
Хотя в идеале большинство пользователей будут изолироваться от языка с помощью интерфейса и средств, основная философия языка должна быть естественна и проста для изучения. Кроме того, ранние приемственники, разработчики средств и сильные пользователи могут работать непосредственно с синтаксисом, человеку хотелось бы видеть синтаксис в читаемом (и записываемом) смысле.

RDF схема Поддерживает:
RDF довольно прост в использовании, но RDF схема более сложна. Синтаксис является основным барьером для большинства.

3.7 Совместимость с другими стандартами

Языку следует быть совместимым с другими широко используемыми в сети и промышленности стандартами. В частности, сюда входят XML и связанные стандарты (такие как XML схема и RDF), и возможно другие языки моделирования, такие как UML.

Поддерживаемые Задачи:
Перевод онтологий и данных к стандартным форматам.

Обоснование принимаемого технического решения:
Совместимость с другими стандартами облегчает разработку средств и распространение языка.

RDF схема Поддерживает:
RDF имеет основанный на XML синтаксис [RDF Syntax].

3.8 Интернационализация

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

Поддерживаемые Задачи:
Задачи, где одни и те же онтологии используются многими странами и культурами.

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

RDF схема Поддерживает::
RDF поддерживает интернационализацию в том объеме, в котором ее поддерживает XML.

4 Требования

Варианты использования и цели разработки приводят к ряду требований к языку веб онтологий. Рабочая группа в настоящий момент чувствует, что требования, описанные ниже существенны для языка. Каждое требование включает короткое описание, и оно объясняется одной или более целью разработки из предыдущей секции.

Т1. Онтологии как ясно выраженные ресурсы

Онтологии должны быть ресурсами, имеют собственные уникальные идентификаторы, такие как URI ссылки.

Мотивация: Общедоступные онтологии

Т2. Распределенные понятия, адресующиеся с помощью URI

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

Мотивация: Обще доступные онтологии, Интер-операбельность онтологий

Т3. Подробно разработанное расширение онтологии

Онтологии должны быть способны явным образом расширять другие онтологии, для того чтобы повторно использовать понятия, когда добавляются новые классы и свойства. Расширение онтологии должно быть транзитивным отношением; если онтология A расширяет онтологию B, и онтология B расширяет онтологию C, тогда онтология A так же неявно, но расширяет онтологию C.

Мотивация: Обще доступные онтологии,

Т4. Связывание онтологий

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

Мотивация: Обще доступные онтологии,

Т5. Метаданные онтологий

Должна быть возможность обеспечить метаданные для каждой онтологии, такие как автор, дата публикации, т.д. Эти свойства могут быть позаимствованы из набора элементов Дублинского Ядра.

Т6. Механизм версий информации

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

Мотивация: Эволюция онтологий

Т7. Базовые элементы определения классов

Язык должен быть способным выражать сложные определения классов. Это включает, но не ограничивается определением подклассов и логическими операциями выражений классов (например пересечение, объединение и дополнение).

Мотивация: Баланс выразительности и расширяемости, Интер-операбельность онтологий, Обнаружение противоречий

Т8. Базовые элементы определения свойств

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

Мотивация: Баланс выразительности и расширяемости, Интер-операбельность онтологий, Обнаружение противоречий

Т9. Типы данных

Язык должен обеспечить набор стандартных типов данных. Эти типы данных могут быть основаны на типах данных XML схемы [XML-SCHEMA2].

Мотивация: Совместимость с другими данными, Простота в использовании

Т10. Эквивалентность классов и свойств

Язык должен включать возможности для объявления того, что два класса или свойства эквивалентны.

Мотивация: Интер-операбельность онтологий

Т11. Эквивалентность экземпляров

Язык должен включать возможности для объявления, что пара идентификаторов представляют один и тот же объект (заметьте, что согласно с терминологией, используемой в OWL документах, объект это экземпляр OWL класса, и необязательно означать человека). Благодаря распределенной природе Сети вероятно, что различные идентификаторы будут ассоциироваться с одними и теми же объектами. Использование стандартного URL не решает этой проблемы потому, что объекты могут иметь множественные URL, как персона, которая имеет домашнюю и рабочую страницу или адреса электронной почты.

Мотивация: Интер-операбельность онтологий

Т12. Присоединение информации к объявлениям

Язык должен предоставлять способ снабжать объявления дополнительной информацией такой, как источник, время модификации, уровень конфиденциальности и т.д. Языку необходимо обеспечить не стандартный набор свойств, которые могут для этого использоваться, а главный механизм для пользователей, чтобы присоединять подобную информацию. RDF reification может быть одним возможным способом ответить всем требованиям, хотя reification это какая-то сомнительная особенность.

Мотивация: Общедоступные онтологии, Интер-операбельность онтологий

Т13. Классы как экземпляры

Язык должен поддерживать возможность рассматривать классы как экземпляры. Потому что одни и те же понятия могут часто быть, как и классом так и объектом, в зависимости от взгляда пользователя. Например, в онтологии биологии, класс Орангутанг может быть экземпляром объектом животные. Однако, класс Орангутанг сам может быть экземпляром класса Род. Заметьте, что Орангутанг не подкласс Рода потому, что тогда будет говориться, что каждый экземпляр Орангутанга (животное) экземпляр Рода.

Мотивация: Интер-операбельность онтологий

Т14. Ограничения кардинальности

Язык должен поддерживать спецификацию ограничения кардинальности свойств. Эти ограничения устанавливают минимальное максимальное число объектов, с которыми каждый обособленный объект может быть связан через указанное свойство.

Мотивация: Задача баланса выразительности и расширяемости, Обнаружение противоречий

Т15. XML синтаксис

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

Мотивация: Совместимость с другими стандартами

Т16. Метки, визуализируемые для пользователя

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

Мотивация: Интернационализация, Простота использования

Т17. Поддержка символьных моделей

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

Мотивация: Internationalization, Compatibility with other standards

Т18. Поддержка уникальных строк в формате уникод

В некоторых кодировках символов, например в кодировках, основанных на уникод, есть несколько случаев, когда две разный последовательности символов выглядит одинаково и вероятно, что большинство пользователей будет принимать их эквивалентными. Например, один использует составную форму символа (только один символ с-сидиль), а другой использует простую форму (символ 'c', следующий за знаком ударения, сидилью) followed by a cedilla accent character). Известно, что рабочая группа I18N W3C решила, что заблаговременная унифицированная нормализация (к Нормальной Форме Уникод С) в качестве постоянного подхода - решение этой проблемы, другие решения должны быть обоснованны.

Мотивация: Интернационализация, Совместимость с другими стандартами

5 Технические требования

В добавок к набору возможностей, которые должны быть в языке (как определенно в предыдущей секции), есть другие возможности, которые были бы полезными во многих вариантах использования. Эти возможности будут адрессоваться рабочей группе, если это возможно, но группа может решить, что есть весомые причины для исключения их из языка, или отложить для выполнения рабочей группой позже. Некоторые из этих технических требований описаны не полностью и по существу требуют дальнейших пояснений, если они адресуются к языку. Заметьте, что порядок технических требований ниже не означает относительную очередность или степень согласования.

ТТ1. Разделение возможностей языка на уровни

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

Мотивация: Баланс выразительности и расширяемости

ТТ2. Значения свойств по умолчанию

Язык должен поддерживать спецификацию для значений свойств по умолчанию. Такие значения могут быть использованы, чтобы сделать вывод о типичных членах классов. Однако, правильные значения по умолчанию (такие как те, которые используются в рассуждениях наследования, которое может быть онулированно) не строги, что может быть проблематично в Сети, где новая информация постоянно открывается или добавляется. Более того, нет обще принятых методов для работы с значениями по умолчанию. Альтернатива для спецификации языка это рекомендовать пользователям, как они могут создавать собственные механизмы значений по умолчанию.

Мотивация: Баланс выразительности и расширяемости

ТТ3. Возможность объявлять замкнутые системы (worlds)

Благодаря размеру и интенсивности изменений в Сети, необоснованное предположения (которые объявляют, что что-либо, что не может быть выведено, предполагается ложным) не приемлемы. Однако, есть много ситуаций когда необоснованная информация была бы полезной. Следовательно, язык должен быть способным объявлять, что данная онтология может рассматриваться как полная. Это тогда бы разрешало вытягивать дополнительные выводы из этой онтологии. Точная семантика таких объявлений (и соответствующий набор выводов) остается для определения, но примеры могут включать предположения о полной информации о свойствах объекта, предположения полноты членства классов и предположения о полноте подклассов.

Мотивация: Совместно используемые онтологии, Обнаружение противоречий

ТТ4. Диапазон ограничений типов данных

Язык должен поддерживать возможность специфицировать диапазоны для значений свойств. Этот механизм может быть позаимствован из типов данных XML схемы[XML-SCHEMA2].

Мотивация: Обнаружение противоречий

ТТ5. Сцепленные свойства

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

Мотивация: Баланс выразительности и расширяемости

ТТ6. Процедура эффективного решения

Язык должен быть разрешимым.

Мотивация: Баланс выразительности и расширяемости

ТТ7. Передача узлам онтологий

Язык должен поддерживать возможность обращения к узлам онтологии, так же как и обращение ко всей онтологии. Однако, неясно как следует использовать здесь степень детализации. Возможны альтернативы, выбрать набор понятий с их полными определениями, или выбрать части определений объектов. Заметьте, что заимствуя частичные определения понятий нужно обращаться к возможным проблемам интер-операбельности, которые могут возникнуть, так как различные приложения будут использовать одинаковые идентификаторы, чтобы обозначить одни и те же вещи.

Мотивация: Совместно используемые онтологии

ТТ8. Механизм представления

Язык должен поддерживать возможность создавать представления онтологий, в которых поднаборы онтологий могут быть специфицированы или понятиям могут быть назначены другие имена. В частности это полезно в разработке мульти-культурных версий онтологий. Заметьте, что это требование может быть удовлетворенно, имея множество онтологий и используя механизм картирования онтологий.

Мотивация: Интернационализация, Интер-операбельность онтологий

ТТ9. Интеграция цифровых подписей

Спецификация Цифровой Подписи XML W3C это важный строительный блок для коммуникации между непроверенными свойствами, которые важны для многих приложений онтологий. Язык сетевых онтологий должен быть разработан способом, который делает честным использование Подписи XML.

Мотивация: Совместимость с другими стандартами

ТТ10. Базовые элементы арифметики

Язык должен поддерживать использование арифметических функций. Это может быть использовано при переводе между различными блоками измерений.

Мотивация: Интер-операбельность онтологий

ТТ11. Работа со стоками

Язык должен поддерживать конкатенацию строк и простое сопоставление шаблонов. Эти возможности могут быть использованы, чтобы установить интер-операбельность между онтологиями, которые обрабатывать сложную информацию, как форматированную строку, и теми, которые имеют отдельные свойства для каждого компонента. Например, одна онтология может представлять адрес электронной почты, как простую строку, когда другая может разделить его на строку имени пользователя и строку для имени сервера. Чтобы интегрировать две онтологии, одной пришлось бы указать, что конкатенация имени пользователя, символа '@' и имени сервера эквивалентна одиночному значению, используемому в первой онтологии.

Мотивация: Интер-операбельность

ТТ12. Агрегация и группирование

Язык должен поддерживать возможность агрегировать информацию способом, подобно оператору GROUP BY в SQL. Это позволит вычислять пересчет, сумму и другие операции для каждой группы. Это разрешило бы интер-операбельность между онтологиями, которые представляют информацию на разных уровнях детализации, и могло бы соотносить такие вещи, как итоги категории бюджета к сумме всех пунктов бюджета, или число персонала к индивидуальным данным работников.

Мотивация: Интер-операбельность онтологий

ТТ13. Прикрепление процедур

Язык должен поддерживать использование исполняемого кода для развития сложных критериев. Прикрепление процедур сильно расширит выразительность языка, но не совсем пригодно для формальной семантики. Механизм Прикрепления процедур для Веб онтологий определит, как располагать и выполнять процедуры. Одним потенциальным кандидатом может быть Java, который уже хорошо пригоден для межплатформенного совместного использования в Веб.

Мотивация: Интер-операбельность онтологий

ТТ14. Предположение локальных уникальных имен

В основном, язык не будет делать предположений о локальных именах. То есть явные идентификаторы не предполагаются для ссылок к различным объектам (смотри Требование Т11 ). Однако, есть много предложений, где предположение локальных имен оказалось бы полезными. Пользователям следует иметь опцию указания, что все имена в частном пространстве имен или документе ссылаются к определенным объектам.

Мотивация: Обнаружение противоречий

ТТ15. Сложные типы данных

Язык должен поддерживать определение и использование сложных/структурированных типов данных. Это может быть использовано для указания дат, пары координат, адресов и т.д.

Мотивация: Совместимость с другими стандартами, Простота в использовании


Ссылки

[DWM]
Industrial Strength Ontology Management, Aseem Das, Wei Wu, and Deborah L. McGuinness. In Isabel Cruz, Stefan Decker, Jerome Euzenat, and Deborah L. McGuinness, editors. The Emerging Semantic Web. IOS Press, 2002. http://www.ksl.stanford.edu/people/dlm/papers/ontologyBuilderVerticalNet-abstract.html
[Hef]
Towards the Semantic Web: Knowledge Representation in a Dynamic, Distributed Environment, Jeff Heflin. Ph.D. Thesis, University of Maryland, College Park. 2001. http://www.cse.lehigh.edu/~heflin/pubs/#heflin-thesis
[RDF Concepts]
Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Latest version available at http://www.w3.org/TR/rdf-concepts/ .
[RDF Syntax]
RDF/XML Syntax Specification (Revised), Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ . Latest version available at http://www.w3.org/TR/rdf-syntax-grammar/ .
[RDF Vocabulary]
RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R. V. Guha, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ . Latest version available at http://www.w3.org/TR/rdf-schema/ .
[XML]
Extensible Markup Language (XML) 1.0 (Second Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, Editors, W3C Recommendation, 6 October 2000, http://www.w3.org/TR/2000/REC-xml-20001006. Latest version available at http://www.w3.org/TR/REC-xml .
[XML-SCHEMA2]
XML Schema Part 2: Datatypes, Paul V. Biron and Ashok Malhotra, Editors, W3C Recommendation, 2 May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ . Latest version available at http://www.w3.org/TR/xmlschema-2/ .

Приложение A: Журнал изменений

Изменения со времени Заявленной Рекомендации располагаются в обратном хронологическом порядке.

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

Raphael Volz и Jonathan Dale сделали значительный авторский вклад в этот документ, и вместе с настоящим редактором были соавторами начальных рабочих черновиков проета. Начальная попытка определить цели разработки и требования приведены вместе с Deborah McGuinness и редактором. Некоторые из требований были приведены непосредственно доктором McGuinness [DWM] опираясь на десять работ по построению систем основанных на онтологии. Другие требования были определенны, как часть диссертации редактора на степень доктора философии в работе по построению прототипа системы Семантической Сети [Hef]. Черновая версия секции Управления Корпоративным Веб Сайтом была написана Michael Smith.

Содержание этого документа это результат щироких дисскусий внутри Рабочей Группы Сетевых Онтологий Рабочей Группы Сетевых Онтологий целиком. Участники этой рабочей группы: Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Ruediger Klein, Natasha Kravtsova, Ora Lassila, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White, Frederik Brysse, Francesco Iannuzzelli, Massimo Marchiori, Michael Sintek and John Yanosy.