AIMS

Второй семинар-практикум Сельскохозяйственной Онтологической Службы АОС 2001

1. Резюме:

ФАО ставит перед собой следующие задачи: сократить масштабы голода, отсутствия продовольственной безопасности и неполноценного питания в мире. Распространение информации является важным и необходимым инструментом для достижения этой цели, поэтому мы должны обеспечить последовательный и улучшенный доступ к информационным ресурсам. Было предложено спроектировать справочный инструмент - Сельскохозяйственную Онтологическую Службу АОС, структурирующую и стандартизирующую терминологию на нескольких языках в области сельского хозяйства, которая может быть повторно использована в различных системах. Была подготовдена и представлена концептуальная записка под названием «Сельскохозяйственная Онтологическая служба (АОС) - инструмент для улучшения доступа к знаниям», которая была распространена между участниками на Первом Международном Симпозиуме «Semantic Web» в Стэнфорде, с 30 июля – по 1 августа 2001 года. Впоследствии было организовано заседание для обсуждения различных вопросов (представленных в концептуальной записке) в штаб-квартире ФАО (Рим, 14-15 ноября 2001 г.). В качестве докладчиков были приглашены эксперты в области представления знаний, онтологий, баз данных и Семантического Веба, которые также высказали своё видение развития проекта.

2. Тематическая организация

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

  • Начальная загрузка/бутстрапирование, создание и поддержка семантических знаний и доменных онтологий
  • Повторное использование существующих семантических знаний (как систем организации знаний/KOSs так и уже существующих модулей / доменов)
  • Связь знаний с основными данными
  • Поиск и анализ информации
  • Распределенные коммуникационные и вычислительные инфраструктуры
  • Резервные хранилища данных и знаний
  • Интерфейс пользователя
  • Вопросы безопасности
  • (Техническое) критерии оценки и приоритетов
  • Вопросы организация и финансирования

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

2.1 Создание и обслуживание специфических доменных онтологий

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

2.1.1 Инструменты Для Разработки, Обслуживания И Контроля Версий Онтологии

Существующие инструменты, которые поддерживают разработку онтологии, представляют модели данных «сущность-связь» (ER-модели), позволяющих описывать концептуальные схемы предметной области. В следующем разделе обсуждается многоуровневый подход к разработке онтологий, который может оказаться полезным в контексте Системы.

Существующие инструменты для создания онтологий: InfoSleuth Ontology Editor (ER model), OKBC Editor (Frame model), Protégé, OntoEdit (Free and commercial), Ontology Builder.

Некоторые бесплатные инструменты, разработанные на онтологии UML, включают в себя: I-logix, Uniting Software Design and Tigris.

Список третьих сторон, а также инструментов с открытым исходным кодом (на основе стандартов RDF и DAML) можно загрузить с:

Некоторые вопросы, связанные с инструментами для создания и технической поддержки различных версий онтологий: 

  • Введение: локальные языки / условия / понятия (вероятно, распределённые по разным группам и языкам) для существующего ядра АОС.
  • Разработка, обработка и техническая поддержка эквивалентностей;
  • Определение и предложение различных представлений информации и возможность переключения между различными видами представлений; 
  • Инструменты для управления структурой федеративной онтологии вместе с различными версиями онтологий.

2.1.2 Многоуровневый подход для построения онтологии

Предлагается многоуровневый подход к дескрипционной логике (описательной логике) для моделирования онтологий АОС. Количество и размеры каждого уровня еще не определены, но могут следовать этим правилам:

  • Главный уровень «Представление/Главное Ядро» («Representation/Core») будет содержать самые простые, но основные элементы языка. Онтологии, разработанные в рамках АОС будут гарантированно использовать элементы уровня «Core». Базовый набор «Core set» должен быть относительно прост в освоении и применении, и отвечать основным требованиям. Некоторые примеры элементов на этом уровне могут включать: класс / подкласс, часть / целое и связи
  • «Средний / верхний уровень онтологии» («Intermediate/Upper-level Ontology») обеспечит более богатый набор примитивов, реализующих наиболее полные стандарты дескрипционной логики. Некоторые примеры элементов этого уровня могут включать (в дополнение к основным элементам): примитивные / определенные классы, экземпляры, очерёдность ограничений, домены, кардинальность, обратные связи.
  • «Средний уровень онтологии» («Middle-level Ontology») фиксирует общую информацию о различных предметных областях. Примеры элементов на этом уровне: дерево, рыба и т.д. Уровень «Онтология специфического домена») («Domain Specific Ontology») фиксирует информацию, которая является специфической для того или иного модуля / домена. Некоторые примеры элементов на этом уровне: банан и т.д.

Абсолютно ясно, что следует использовать существующие языковые стандарты для построения онтологий, а не изобретать новые языки специально для АОС. Главный уровень может следовать стандартам RDF, в то время как средний уровень может следовать спецификациям + DAML. Тем не менее, не существует единства мнений о деталях или стандартах, доступных для «Среднего» уровня и уровня «Онтология специфического домена». 2.1.3 Совместное создание «Онтологий специфического домена».Предполагается, что для реализации онтологии будет вовлечено большое количество доменных экспертов из разных организаций-спонсоров, работающих в нескольких предметных областях. В предыдущем разделе были представлены инструменты для создания (также через многоуровневый подход) онтологий. Существуют продукты / сервисы / инструменты (например, WebOnto и Ontolingua), разработанные на основе групповой работы, поддерживающие совместную информационно-техническую разработку и редактирование документов и онтологий.

2.1.4 Репрезентативные Языки для Онтологий: дескрипционная логика

Для создания описания концептов / объектов онтологии, необходимо перейти от традиционных связей, предлагаемых тезаурусами (BT / NT / RT / UF / TT / SA / С.Н.) к более формальным и более богатым наборам языковых примитивов. Такой подход будет способствовать созданию более высокой степени семантического представление, цель которой - улучшение поиска информации. Дескрипционные логики (описательные логики) – это семейство формальных языков представления знаний, позволяющих описывать понятия предметной области в недвусмысленном, формализованном виде. Они сочетают в себе, с одной стороны, богатые выразительные возможности, а с другой — хорошие вычислительные свойства, такие как разрешимость и относительно невысокая вычислительная сложность основных логических проблем, что делает возможным их применение на практике. Например, связи BT/NT, применяемые в тезаурусах, используются часто неоднозначно /несколько двусмысленно и с очень широкой трактовкой, чтобы представить «суперкласс / подкласс», а также» часть / целое». В дескрипционной логике, понятиям «суперкласс / подкласс» и «часть / целое» присваиваются различные и недвусмысленные языковые элементы. Естественно, к этому вопросу нужно подходить с осторожностью, так как большинство из основных групп пользователей ещё незнакомы с дескрипционной логикой (раздел 2.7) и "чувствуют себя более комфортно" (в случае каталогизаторов), используя связи стандартных тезаурусов или (в случае конечного пользователя) ожидая, что механизмы, поддерживающие подробную репрезентативность будут либо полностью скрыты либо отображаться через определённый интерфейс визуализации данных высокого уровня.

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

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

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

2.1.5 Многоязычная среда

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

2.2 Повторное использование существующих семантических знаний

Учитывая то, что реализация онтологии является весьма трудоёмким и дорогостоящим мероприятием, должна быть предпринята попытка исследования повторного использования существующих систем организации знаний / KOSs и доменных онтологий в целях проектирования и создания онтологий в системе АОС.

2.2.1 Создание и повторное использование существующей АОС

Модули - это отдельные разделы АОС, являющиеся специфическими для домена, например, для лесного хозяйства и рыболовства. Возможно также наличие нескольких KOSs для конкретного модуля онтологии, например, одновременное присутствие схожих между собой тезаурусов - CABI и АГРОВОК. Кроме того, существующие KOSs, такие как АГРОВОК включает в себя понятия из разных предметных областей, таких как лесное хозяйство и рыболовство. Возможно либо (сначала) принять решение о разработке модуля и затем определить соответствующие ему KOSs, или, наоборот, использовать существующую систему KOS для принятия решений о создании конкретного модуля. Некоторые инструменты для моделирования онтологий поддерживаются конкретными методологиями и процессами разработки онтологий (например, процесс разработки онтологии EDEN в области экологической информации).

Перечень некоторых сценариев процессов повторного использования знаний:

  • Поиск релевантных систем организации знаний (KOSs)
  • Выбор систем KOS для их повторного использования
  • Перевод систем KOS на желаемые языки
  • Оценка выбранной системы KOS для её повторного использования
  • Обогащение выбранной системы KOS (схемы базы данных или словаря) в области конкретной онтологии
  • Ассемблирование блоков (интеграция)
  • Объединение переплетающихся понятий (слияние)
  • Анализ качества полученной АОС

2.2.2 Повторное использование существующих KOSs и информационных источников

  • Предварительная разработка алгоритмов и методов для повышения семанатической выразительности систем KOSs через онтологию может существенно сократить затраты времени и усилий на создание онтологий. Анализ различных систем KOSs покажет, что необходимо для репрезентативного / верхнего уровня онтологии («representation/upper level ontology») (Раздел 2.1.3). Конструкции, определенные на этом уровне могут быть использованы для представления конкретных концепций домена в онтологии АОС. Для определения необходимых требований, мы должны использовать два подхода: «сверху вниз» и «снизу вверх».

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

  • Время, например: списки классификаций, контролируемые словари, тезаурусы, схемы баз данных
  • Специфика: - Общая, например: «CYC», и т.д., или Специфическая, например: тезаурусы АГРОВОК, AGRIS/CARIS, CABI, и т.д.
  • Домен, например: рыболовство, лесное хозяйство и т.д.
  • Формат: цифровой, неоцифрованный, текстовый и т.д. Степень формализации: формальная, например, с использованием языка KR; неофициальная, например, с использованием естественного языка.

Если для повторного использования системы KOS требуется слишком много времени и усилий, можно прибегнуть к повторному использованию только части системы KOS или выстроить концепции системы в АОС с нуля, без их повторного использования. Отмечались попытки преобразования и активация схем баз данных в онтологии домена. Продуктом, генерирующим модель E-R после анализа схем баз данных является ERWin. Другие типы KOS, предложенные на рассмотрение: тезаурусы, словари, глоссарии, предметные рубрики, классификационные списки, и т.д. Пока ещё не было выявлено никакого известного программного обеспечения, способного преобразовывать и усиливать представленные типы KOS в онтологии.

2.2.3 Повторное использование существующих онтологий

В этом разделе мы обсудим требования к инструментам и методам, необходимых для включения существующих онтологий предметных областей в онтологии АОС. Вопросы, связанные с интероперабельностью распределенной онтологии, будут обсуждены в другом разделе. Некоторые установленные требования: создание онтологии путём слияния и интеграции. Инструмент Protégé, разработанный в Стэнфордском университете, поддерживает ручное слияние онтологий. В некоторой степени интеграцию поддерживает Ontolingua Server. KSL Stanford Cimaera используется для слияния. Импорт концептов /определений/частей из существующих онтологий и KOSs Перевод онтологий / KOSs на несколько языков реализации. Существует несколько переводчиков в Ontolingua Server, но они предназначены только для получения первоначальных версий, которые должны быть улучшены вручную. Идентификация подобных понятий в различных онтологиях / KOSs (с согласованными и перекрывающенными концепциями), основаны не только на соответствующих названиях, но и на определениях и, по возможности, на перекрывающихся наборах элементов, относящихся к понятиям. Сравнение различных версий повторно используемых онтологий / KOSs. В настоящее время - это объект исследования в области онтологий. Инструменты для управления отображениями между терминами различных тезаурусов и их интеграции.

2.3 Связь знаний с базовыми данными

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

2.3.1 Идентификация типов ресурсов

Рекомендуется идентифицировать типологии информационных ресурсов (т.е. рекомендации, статья журнала, веб-сайт, сегмент видео, неподвижное изображение, и т.д.) в стандартизованной форме. Это даст пользователям возможность поиска конкретного типа информационного носителя. Такая установка присутствует в стандарте Dublin Core, где атрибут «ресурс» ассоциирован с метаданными. В RDF, любой активный URL считается ресурсом. Тем не менее, было бы трудно сформулировать такой список в качестве устойчивой составной части АОС, и во многих случаях назначение такого типа ресурса может быть неоднозначным. Вместо того, чтобы идентифицировать типологию ресурсов как формальную часть АОС, можно предположить создание онтологии типов ресурсов по запросу каталогизаторов. Такая онтология ресурсов может быть изменена, а также поддерживаться в течение долгого времени. Для того, чтобы использовать однозначные определения ресурсов, они должны быть описаны недвусмысленно в каждом случае.

2.3.2 Отображения для структурированных данных

Первый набор инструментов – это те инструменты, которые связывают схемы баз данных с концептами и атрибутами онтологии. Примеры коммерческих инструментов с подобными функциями: инструменты для реляционного отображения объекта в IDE среде, ассоциированной с набором программного обеспечения J2EE, позволяющего определить соответствие между компонентами объектных моделей EJB и реляционной схемы баз данных. В Университете Карлсруэ были разработаны инструменты, используемыя вместе с системами InfoSleuth/EDEN и Kaon-reverse.

2.3.3 Аннотация для текстовых и мультимедийных документов

Существует широкий круг инструментов, которые могут помочь аннотировать текстовые документы с понятиями из онтологии. Примеры: програмное обеспечение IKA class и Onto-Mat. На настоящий момент отсутствует программное обеспечение для аннотации изображений с онтологическими концептами. Существуют инструменты для создания веб-сайтов на основе онтологий, например, Semantic Miner, и инструменты для узучения онтологических аннотаций текстовых документов, например, TextToOnto, которые могут быть полезными в этом контексте. 2.3.4 Вопросы, связанные с обработкой естественного языка Существует большая заинтересованность в поддержке обработки естественного языка (NLP) в рамках AOS (на определённом уровне). Применение NLP включает в себя обработку запроса (пользователи запрашивают информацию в виде запросов на естественном языке), машинный перевод (преобразование текста с одного языка на другой), и извлечение информации (извлечение фактов и другой информации из oн-лайновых текстов). NLP может помочь определить контекст запроса информации пользователя и автоматически выбрать соответствующие смысловые слова для используемых терминов. Ожидается, что NLP станет важной технологией в ближайшие годы, и что системы NLP будут иметь постребность в таком терминологическом ресурсе, как АОС (в качестве основополагающего компонента). Обогащение АОС возможностями поддержки NLP может потребовать использование продвинутого (более высокого) уровня (Advanced-level) поддержки дискрипционной логики, а также очень сложных и обширных структур данных. В настоящее время наблюдается значительное расхождение мнений о том, какую форму приобретут эти структуры данных. В дополнение к информации о частях речи (связанных с терминами), расширения NLP на АОС будут также включать в себя грамматические модели, связанные с лексическими записями, и способы отображения синтаксических моделей в семантических представлениях.

2.4 Поиск и анализ информации

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

2.4.1 Интероперабельность между Распределенными Онтологиями и Интер-Онтологиями

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

  • получить описание для определенного термина
  • получить все термины с иерархическими (broader/narrower; шире/уже) и неиерархическими (related, ассоциирован) связями
  • предоставить синонимы, антонимы для данного термина
  • найти аналоги (переводы) терминов в другом языке
  • добавить / обновить термин
  • безопасность (управление функциями разрешения /ограничения доступа, создания /модификации термина)
  • обмен данными через XML / RMI / CORBA / OKBC.

Тем не менее, каждый сервер должен быть в состоянии использовать связи между онтологиями, которые способны извлекать любое дублирование между онтологиями и переводить запросы, выраженные с помощью терминов одной онтологии в терминологию другой онтологии. Были предложены алгоритмы, выполняющие запросы переписи (query re-writing) по всем онтологиям, а также вычисляющие потери информации, накопленные через переводы. Некоторые научно-исследовательские проекты, запущенные для решения этих проблем: ONION system в Стэнфорде и OBSERVER System.

2.4.2 Распределённый Запрос и Поиск

В контексте обработки запросов из нескольких баз данных, исследования по вышеуказанному вопросу проводятся на протяжении уже десяти лет. Некоторые примеры распределенной обработки запросов: Carnot, Mermaid и Interbase systems. InfoSleuth/ EDEN также представляет интересный вариант обработки запросов в распределенной базе данных, с учётом отдельных ограничений на составные источники данных. Существует довольно большое число алгоритмов распределенной индексации текста и мета-поиска, созданные в контексте WWW. Система индексирования изображений на основе контента была реализована на самом базовом уровне текстуры, формы, цвета, сегментации и т.д. Некоторые продукты доступны из IBM (QBIC system) и Virage. Интересен пример распределенной обработки запросов - "толчок" (“push”) Уведомления / Подписки. Для фильтрации документов были предложены различные алгоритмы и методы, а также были реализованы триггеры в реляционных базах данных. InfoSleuth/ EDEN реализует онтологии на основе механизма подписки / уведомления, где пользователи могут идентифицировать соответствующие онтологические понятия в своих профилях. Как только соответствующие данные (документы, информация) станут доступными в системе, они могут быть переправлены пользователю.

2.4.3 Извлечение информации из данных (Data Mining), Машинное Обучение (Machine Learning) и обнаружение знаний (Knowledge Discovery)

Методы, использующие алгоритмы обучения для автоматизации аннотации текстовых и графических документов, а также поддержка, предоставленная методами «Data Mining» и «Knowledge Discovery» могут быть рапределены по следующим классам программного обеспечения:

  • дерево решений на основе алгоритмов обучения, например, C4.5;
  • подходы на основе Нейронной сети («Neural Network»);
  • подходы на основе Статистической Кластеризации («Statistical Clustering»), такие как K-means, иерархические подходы, основанные, в свою очередь, на векторном пространстве на основе индексации текстовых документов, например, «Latent Semantic Indexing»;
  • подходы «Data Mining», такие как «association rule mining».

2.5 Распределенные вычисления и коммуникационные инфраструктуры

Систему АОС можно рассматривать как чрезвычайно разветвлённую систему, которая состоит из онтологий, баз знаний, систем организации знаний / KOSs, процессоров запросов, и реляционных и текстовых хранилищ данных, доступных в онлайн системах. Лежащая в основе коммуникационная инфраструктура, используемая для поддержки коммуникационных процессов и координации между структурами, имеет решающее значение для успеха системы АОС.

2.5.1 Компонентные и объектные инфраструктуры

В последнее время было проведено много исследований в области распределённых вычислительных технологий, таких как компонентные модели J2EE и NET. Существенной особенностью этих компонентных архитектур являются их функции:

  • сопоставление баз данных и доступ к ним;
  • транзакция и параллельный контроль, управляемые «контейнерами», имплементированными в соответствии с отраслевыми стандартами и спецификациями.

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

2.5.2 Веб-сервисы и агент-ориентированные инфраструктуры

Новые стандарты развивающиеся на основе веб-сервисов, такие как WSDL, UDDI и SOAP, представляют интересные и практичные альтернативы компонентным и объектным инфраструктурам. Архитектура системы АОС может быть представлена как совокупность услуг, предлагаемых различными компонентами системы и форматированными сообщениями, передаваемых по протоколу SOAP. Для этой цели могут быть также анализированы «агент-ориентированные» инфраструктуры, такие как «InfoSleuth agent system» и «FIPA agent shell». Важно отметить наличие различных стандартов для кодирования сообщений в различных языках разметки, таких как:

  • OKBC и KIF для представления знаний
  • XML и RDF в веб-контексте
  • KQML для коммуникации агента
  • WSDL, UDDI, SOAP для веб-служб
  • CORBA, RMI, RPC для распределенной связи

2.6 Репозитории бэк-энд для управления данными и знаниями

В этом разделе будут обсуждены резервные технологии, используемые для хранения и управления данными (находящихся в различных KOSs), с одной стороны, и онтологий и знаний, с другой стороны. Следует отметить, что одна и та же технология (DBMS) может быть использована для хранения и управления как онтологий так и данных в системе АОС.

2.6.1 Системы управления базами данных

Система управления базами данных необходима в качестве основы для физической реализации АОС, содействуя, таким образом, ускорению таких операций, как поиск и выборка информации, и использованию преимуществ коммерческих систем управления базами данных (например, управление транзакциями, безопасностью и контролем целостности). Системы управления базами данных (ODBMS) предлагают интересные преимущества для хранения онтологий, т.к. объектная структура и таксономический характер ODBMS позволяют параллельное создание онтологии. Системы управления реляционными базами данных (RDBMS) имеют хорошие коммерческие каналы и более широкую поддержку. Существуют методы для отображение структур объектов в реляционных базах данных. Тем не менее, вопрос о том, какие архитектуры баз данных являются наилучшим для АОС – это деталь имплементации. АОС должна быть определена с точки зрения стандартов, в то время, физическая реализации этих стандартов может быть рассмотрена в соответствии с требованиями локальной имплементации. Некоторые хорошо известные DBMS: Oracle, Sybase, MySQL, SQL Server (реляционная) и ObjectStore, Versant, Poet (объектно-ориентированный). 2.6.2 Системы управления знаниями Системы управления знаниями состоят из технологий, основанных на стандартной базе знаний, а также систем, используемых для поддержки новых веб-стандартов, таких как RDF (S) и DAML+ OIL. Они также включают в себя системы, предназначенные для управления знаниями, находящихся в тезаурусах и словарях. Примеры систем первого типа: KL-ONE системы, такие как LOOM, CLASSIC, BACK, etc. и т.д. RDF-основанные системы: система ICS-Forth, SESAME, RDFDB и т.д. Примеры систем, поддерживающих управление тезаурусами: LEXICON, MultiTes и Knowledge Map. 2.6.3 Системы управления контентом Эти системы ориентированы на хранение и управление контентом (текстовые данные, изображения и веб-страниц) в онлайн среде. Среди доступных и хорошо известных CMSs: Verity, Documentum, Isis, Basis, т.д. Существуют системы, которые поддерживают шаблоны и сайты с доступом к данным, хранящихся в системе баз данных и использующих шаблонные представления, такие как JSP и ASPs.

2.7 Пользовательские интерфейсы

Пользовательский интерфейс в системе АОС имеет решающее значение в том смысле, что от него зависит успех системы. Мы попытались идентифицировать разные группы пользователей АОС, а также исследовать технологии для визуализации знаний, запросов и результатов в системе. 2.7.1 Категории пользователей В ходе семинара были были идентифицированы следующие категории пользователей: "Конечный пользователь" –пользователь, использующий результатную информацию (здесь: в области сельского хозяйства). Предположительно, этот поиск будет поддержан одной из онтологий в области сельского хозяйства. Этот тип пользователей может включить в себя: производителей сельскохозяйственной продукции, исследователей, разработчиков политики, студентов и других.

  • Какие особенности АОС будут привлекать таких пользователей?
  • Возможность просматривать онтологию для поиска информации
  • Возможность использовать обычный язык (пользователи не хотят использовать контролируемый словарь)
  • Чувствительность к контексту (попытки идентификации системой смысла используемых слов)
  •  

Разработчики и Каталогизаторы Онтологии – эти люди будут использовать стандарты и инструменты:

  • предоставляемые АОС для реализации онтологий,
  • для повторного использования существующих онтологий, элементов информационных каталогов внутри этих онтологий, и / или информации, которая предоставляется в рамках онтологий в аграрном секторе.

Некоторые вопросы, заслуживающие проработки:

Профессиональные каталогизаторы, знакомые со связями тезаурусов (BT / NT / RT / UF / TT / SA / SN), должны иметь возможность вводить локальные термины / лексические единицы (Local Terms, LT), опираясь также на механизм для ввода некоторых из этих терминов в авторитетную (центральную) онтологию. Следует принять во внимание, что онтологии используют богатый и точный набор связей (см. Дискриптивные логики). АОС должен представить определения терминов:

  • официально - через использование семантических связей,
  • неофициально - через "глоссу" или определения на основе текста из одного или двух предложений.

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

2.7.2 Инструменты визуализации

Существующие инструменты визуализации можно использовать для просмотра и редактирования онтологий, используя графики 2D (и, возможно, интерфейсы на базе 3D / VRML) или графические пользовательские интерфейсы, основанные на общепринятых конструкциях, таких как «outliners». Гораздо больше работы требуется для разработки надлежащих интерфейсов для более удобной навигации по онтологии. Большинство пользователей будут ознакомлены с возможностями просмотра онтологий. Многие из деталей онтологии должны быть скрыты (особенно на промежуточном и продвинутом/ более высоком уровнях дискриптивной логики). Чтобы позволить пользователям легко определять части онтологии (в которых они заинтересованы) в интерактивном режиме - с прогрессивным уточнением запроса на уточнение информации на основе получаемых результатов - могут быть задействованы также альтернативные средства визуализации. В случае большого количества возвращаемых результатов, могут быть задействованы инновационные методы визуализации результатов по категориям (онтологические концепты для классификации результатов).

2.8 Вопросы безопасности

Вопросы безопасности будут зависеть от потребностей организаций, участвующих в проекте «Agricultural Ontology Server». Несмотря на важность этого пункта, он не был подробно обсуждён на семинаре.

2.9 Критерии (технической) оценки и приоритеты

Список приоритетных пунктов повестки заседания:

  • Высокий приоритет - Спецификация ключевых языковых элементов - Визуализация конечного пользовательского интерфейса - Обработка запросов - Стандарты для поддержки имплементации (например, реализации баз данных) - Технические характеристики для распределенного сервера онтологий и для обмена информацией - Минимизация издержек
  • Средний приоритет - Элементы языка промежуточного представления - Аспекты многоязычности системы - Инструменты в помощь каталогизации - Средства визуализации для разработчиков
  • Низкий приоритет - Элементы представления более высокого уровня - Идентификация типов информационных ресурсов - Обработка естественного языка - Инструменты, позволяющие проверять целостность, автоматическую классификацию, концептуальную кластеризацию 2.10 Источники финансирования и организационные вопросы Ниже обсуждаются вопросы финансирование и организационные вопросы, связанные с проектом.

2.10.1 Сфера применения проекта

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

2.10.2 Участие

Согласно предложенным общим принципам (разработанным в рамках сотрудничества и координации), различные партнёры, работающие в предметных областях, представляющих интерес для проекта, должны иметь возможность присоединиться к проекту консорциума. Партнёры могут также выступить с предложением своих KOSs. Например, CABI Publishing может участвовать в проекте и может предложить свой тезаурус. АОС – это результат совместных усилий с ФАО, действующей в качестве координационного центра и секретариата по проекту. В качестве возможной схемы участия, были предложены следующие роли:

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

Проектное предложение должно чётко определить возможных участников и потенциальных партнёров в конкретныхопредметных областях. ФАО может взять на себя роль посредника или интегратора. Сам проект – это результат совместных усилий. Вопрос интеллектуальной собственности пока ещё не может быть чётко вырисован. Участники смогут получить пользу от проекта через эффективное сотрудничество в его рамках, а значит через обмен своими знаниями и опытом с другими участниками. Доверие к проекту растет благодаря его поддержке проекта со стороны ФАО. Проект должен быть открыт для всех участников с соответствующей авторизацией. Необходимо определить, какие предложенные KOS могут быть включены в проект. Существует несколько ограничений по использованию информационных ресурсов, наложенных лицензированием, авторским правом, сферой действия, партнерства и т.д. Например, если определённый KOS будет использоваться в рамках АОС, и организация, создавшая KOS, является партнёром проекта АОС, важно, чтобы эта организация не покидала настоящий проект . После слияния разных KOSs и их повторного использования, они теряют свою идентичность. Что можно предпринять, чтобы решить потенциальную потерю идентичности в этом случае?

2.10.3 Временной диапазон

Проектное предложение должно быть улучшено и расширено в следующем году, с целью разработки новой версии, которая может быть предолжена для консультирования руководителей старшего звена, а также служить в качестве проектного предложения в ЕС и в другие государственные органы, которые осуществляют финансирование проекта. Сам проект должен начаться в конце 2002 года и займёт примерно 3-4 года. Предложение должно уточнить преимущества проекта, затронуть все аспекты проекта, определить возможности использования его результатов, определить заинтересованные стороны и их отдельные права в интеллектуальной собственности. Участники должны чётко понимать о чём идёт речь в этом документе , а также чётко представлять цели проекта.Усовершенствованное предложение должно быть представлено в 3-м квартале 2002 года.

2.10.4 Требования проекта

Проектные требования будут выложены после представления пересмотренного варианта предложения проекта. Это предложение должно учитывать потребности пользователей, бизнес-перспективы и цели проекта. Преимущества должны быть чётко определены для каждой категории пользователей:

  • Лица, занимающиеся решением конкретных проблем
  • Лица, занимающиеся поиском знаний
  • Внешние СМИ / Информационные агентства

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

2.10.5 Финансирование

Получение первоначального финансирования необходимо для продвижения проекта. Финансирование может быть предоставлено:

  • Участниками: например ФАО, чтобы убедить высшее руководство обеспечить финансирование проекта c учётом баланса между распределением затрат и выгод от проекта.
  • Внешним финансированием: государственными агентствами, например, 6 Рамочной программой ЕС, NSF и другими правительственными учреждениями аграрного сектора.

3. Итоги

  • Семинар был инициирован ФАО с целью установления сотрудничества и создания команды специалистов для реализации проектного предложения
  • Была рассмотрена концепция АОС, а также определены области, которые требуют к себе большего внимания
  • Обсуждения на заседании были весьма подробными и интенсивными; были определены преимущества и трудности, связанные с освоением возможностей системы в полной мере
  • Было выражено согласие в том, что следует делать больший упор на практическую сторону работы системы, чем на научные исследования
  • Было решено, что в перспективе должен быть сформирован «Launch Committee», которому будет поручено внести предложения по пересмотру проекта, и собрать вместе всех заинтересованных лиц и экспертов в январе.

Презентации  семинара AOS