4936-1 (618526), страница 5

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 5)

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

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

Также онтология не должна содержать все возможные свойства классов и различия между классами в иерархии.

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

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

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

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

5. Определение свойств – боле подробно

В этой главе мы затронем еще несколько деталей, которые нужно иметь при определении слотов в онтологии (Шаги 5 и 6 в Главе 3). В основном, мы обсуждаем обратные слоты и значения слота по умолчанию.

5.1. Обратные слоты

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

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

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

5.2. Значения по умолчанию

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

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

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

6. Об именах

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

Определить единые правила присваивания имен классам и слотам и придерживаться их.

На выбор правил присваивания имен влияют следующие особенности системы представления знаний:

Имеет ли система одно и то же пространство имен классов, слотов и экземпляров? То есть, позволяет ли система иметь класс и слот с одинаковым именем (как, например, класс винный завод и слот винный завод)?

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

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

К примеру, Protеgе-2000 имеет единое пространство имен для всех своих фреймов. Она различает регистр букв. Таким образом, у нас не может быть класса винный завод и слота винный завод. Однако у нас может быть класс Винный завод (не прописные буквы) и слот винный завод. С другой стороны, CLASSIC не различает регистр букв и имеет разные пространства имен для классов, слотов и индивидных концептов. Таким образом, с точки зрения системы, мы можем с легкостью присвоить имя Винный завод и классу, и слоту.

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

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

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

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

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

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

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

6.2. Единственное или множественное число

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

Использование все время одной и той же формы также предотвращает такие ошибки разработчика при моделировании, как создание класса Вина, а затем создание класса Вино как его подкласса (см. Раздел 4.1).

6.3. Договоренность в отношении использования префиксов и суффиксов

Некоторые методологии по базам знаний советуют придерживаться договоренности в отношении использования префиксов и суффиксов в именах для того, чтобы различать классы и слоты. Существует две распространенных традиции: добавлять к именам слотов has-⁶ или предлог –of⁷. Таким образом, наши слоты меняются на его-производитель и его-винный_завод, если мы выберем использование его-. Слоты меняются на maker-of и winery-of⁸, если мы выберем использование of-. Этот подход позволяет любому, кто посмотрит на термин, сразу же определить, что это: класс или слот. Однако имена терминов становятся немного длиннее.

6.4. Другие соображения по присваиванию имен

Еще несколько моментов, которые нужно иметь в виду при определении правил присваивания имен:

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

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

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

Имя надкласса должно входить или во все имена прямых подклассов, или ни в одно из них. Например, если мы создаем два подкласса класса Вино для представления красных и белых вин, то подклассы должны называться или Красное Вино и Белое Вино, или Красное и Белое, но не Красное Вино и Белое.

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

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

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

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

8. Заключение

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

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

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

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

Brickley, D. and Guha, R.V. (1999). Resource DescriptionFramework (RDF) Schema Specification. Proposed Recommendation, World Wide WebConsortium:http://www.w3.org/TR/PR-rdf-schema.

Chimaera (2000). Chimaera Ontology Environment.www.ksl.stanford.edu/software/chimaera

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

Характеристики

Список файлов курсовой работы