С помощью оригинальной методологии трансляции онтологий рассматриваемая платформа преобразует онтологии в карты тем XML, а затем в представления, воспринимаемые механизмом поиска.
Крупные организации испытывают потребность в решениях, предназначенных для добычи текстов и предлагающих расширенные возможности извлечения информации, а также в приложениях выявления знаний и управления ими. Однако реализация подобных приложений — весьма сложный процесс. Любая предметная область имеет свою собственную лексику и требует специализированных средств грамматического разбора. Научные статьи используют определенный вид так называемого лабораторного языка. Государственные и правоохранительные органы требуют следования четко установленному словарю. Патентные специалисты изъясняются с помощью особой смеси лабораторного языка и научной терминологии.
Как результат, несмотря на изобилие программных продуктов общего назначения, универсальный подход к добыче текстов себя не оправдывает. Даже если цель состоит в том, чтобы реализовать добычу текстов в рамках крупной коммерческой или технической предметной области, организации придется адаптировать, по крайней мере, часть выбранного решения добычи текстов, чтобы гарантировать, что оно отвечает ее особым целям и соответствует ее специфическим требованиям.
Как видно из врезки «Онтологии и добыча текстов», онтологии предлагают массу возможностей усовершенствовать извлечение информации в рамках предметной области, но часто несовместимы с конкретной технологией механизма поиска. Урегулировать эту несовместимость трудно, поскольку взаимодействие между ИТ-специалистами, которые разбираются в механизмах поиска, и теми, кто должен будет использовать механизмы поиска, крайне затруднено. ИТ-департаменты разрабатывают онтологию, не понимая потребности своих пользователей. В то же время, конечные пользователи пытаются применять существующие онтологии, но далеко не так эффективно.
Многие организации по-прежнему тратят десятки тысяч долларов в попытке приобрести «правильный» инструментарий добычи текстов. Альтернативный подход — попытаться поддержать еще более дорогую научную программу анализа информации, результат которой неясен, или тратить большие силы и заниматься дорогостоящей разработкой узконаправленного приложения.
Более разумная альтернатива — найти способ максимально эффективного использования уже имеющихся инструментов добычи текстов и извлечения информации и уже применяемых онтологий. Зачастую эти инструменты обладают полезными возможностями, которые компания не в состоянии в полной мере реализовать, если не разработает онтологию, адаптированную к своим собственным нуждам. Создание систематики и онтологии — дело не только дорогостоящее, но и чреватое серьезными политическими и техническими осложнениями, в силу которых добиться гармонии крайне трудно. Например, приблизительно пять лет назад компания GlaxoSmithKline (в то время она называлась GlaxoWellcome) приняла решение адаптировать Verity, программный инструментарий индексации и поиска, к решению задач извлечения знаний в рамках внутрикорпоративной сети. Система Verity была выбрана потому, что она поддерживала просмотр, ориентированный на систематику, и поиск, ориентированный на понятия. Эта система также предлагала средства для создания, управления и работы с систематиками и группировку, а также была рассчитана на автоматическое распределение документов по категориям. Однако весь этот инструментарий остался невостребованным. Дело в том, что компания не смогла разработать и применить систематики, которые потенциальные пользователи, в частности ученые, посчитали бы надежными и практически применимыми.
Чтобы эффективно использовать возможности Verity, подразделение Data Exploration Sciences компании GlaxoSmithKline в конце 2002 года начало реализацию проекта Babylon, ставя перед собой две основные цели.
- Разработать платформу добычи текстов, которая могла бы послужить основой для разнообразных приложений и которую можно было бы расширять на разные предметные области.
- Разработать несколько серьезных прототипных приложений на этой платформе. Первое из числа запланированных прототипных приложений было связано с анализом отчетов о неблагоприятных последствиях применения лекарственных препаратов; оно было призвано выявить тенденции, касающиеся связи между приемом лекарства и реакцией на них или взаимодействия лекарственных средств, которые не могут быть обнаружены в нетекстовых структурированных базах данных.
После того, как первоначальные цели проекта будут достигнуты, основной задачей станет создание платформы, полезной для других подразделений компании, работающих с иными специализированными предметными областями, такими, как управление персоналом, отзывы клиентов и генетические исследования.
Архитектура платформы
Как показано на рис. 1, платформа Babylon состоит из расширяемого графического интерфейса Knowledge Navigator, конвертера карты тем XML (XTM — XML Topic Map) и модуля грамматического разбора запросов. Онтология вводится в платформу после того, как специалист по работе со знаниями, знакомый с онтологией, — или специалист по работе со знаниями вместе со специалистом по предметной области — напишет программу, которая переводит онтологию в канонический формат XTM. Затем XTM-конвертер переводит представление XTM в представление, воспринимаемое технологией механизма поиска.
Knowledge Navigator
Пользователь обращается к Knowledge Navigator, чтобы просмотреть документы, классифицированные в соответствии с иерархией онтологии, передать ориентированные на понятия запросы и получить результаты. В существующем виде Knowledge Navigator обладает двумя основными функциями.
Просмотр на основе онтологии. Когда пользователь выбирает онтологию, с помощью которой он намерен представлять и просматривать документы, Knowledge Navigator отображает графическое древовидное представление категорий в этой онтологии. По мере того, как пользователь перемещается по дереву, он видит ссылки на документы, соответствующие выбранной категории в данной онтологии, которые он затем может выбрать для более тщательного изучения.
Среди технологий, представляющих для GSK интерес, следует отметить Emtree компании Elsevier, Gene Ontology, словари Международной организации здравоохранения, MedDRA (Medical Dictionary for Regulatory Activities) и внутренние ресурсы, такие как GSK Thesaurus и GSK Metabolic Thesaurus. В других отраслях имеются аналогичные словари или онтологии, часто находящиеся под контролем профессиональных организаций наподобие IEEE или ACM, отраслевых рабочих групп или госучреждений. Онтологии могут быть огромными и открытыми для широкого доступа, например, большой Web-каталог Open Directory Project (http://dmoz.org/about.html). К тому же, любая крупная организация практически всегда имеет несколько различных систем классификации, определений метаданных или структур категорий в таких областях, как производство и сбыт, юридические вопросы, маркетинг, отзывы клиентов, исследования и разработка.
Поиск, ориентированный на понятия. Когда пользователь вводит в текстовое поле запрос на естественном языке, модуль грамматического разбора интерпретирует запрос и выделяет термины, которые пользователь мог бы выбрать для расширения понятия относительно выбранной онтологии. Затем пользователь выбирает термины для расширения и определяет, как именно они расширяются. Например, для простого запроса pediatric cancer («педиатрический рак») пользователь может указать, что понятие pediatric («педиатрический») расширяется за счет использования вариантов написания слов, таких как paediatric, и синонимов, таких как childhood («детский»); и расширить cancer («рак») за счет терминов, обозначающих более узкие его виды, таких как lymphoma («лимфома») и carcinoma («карцинома»).
Транслятор онтологий
Транслятор выполняет грамматический разбор конкретной онтологии в специфическом представлении, а затем создает каноническое представление данной онтологии в стандартном формате XTM. Разработчик, который пишет транслятор, не обязан знать технологию механизма поиска, механизм запросов и извлечения или пользовательский интерфейс. В идеале задачу создания транслятора должны решать специалисты, скажем, в области биоинформатики или управления информацией (возможно, с помощью консультаций ИТ-специалиста). Добавление онтологии требует только, чтобы кто-то написал транслятор. Остальное произойдет автоматически, и знания из преобразованного источника сразу же станут доступными в Knowledge Navigator.
XTM-конвертер
Набор инструментальных средств Babylon включает в себя XTM-конвертер, который воспринимает любую онтологию в каноническом формате XTM и выполняет три задачи. Первая заключается в создании представления онтологии, приемлемого для технологии механизма поиска; в нашем случае — это набор тем Verity. Для других продуктов, таких как RetrievalWare компании Convera, XTM-конвертер будет преобразовывать онтологию в формат семантической сети.
Вторая задача состоит в создании словаря понятий, который связывает каждый термин с набором терминов. Этот набор состоит из связей понятий для оригинального термина, к которым пользователи обращаются в рамках поиска, ориентированного на понятия.
Третья задача конвертера — создание компонентов интерфейса, например, модули или фрагменты кода, к которым Knowledge Navigator будет автоматически обращаться, чтобы отобразить новую иерархию онтологии.
Персонифицированный грамматический разбор
Модуль грамматического разбора запросов интерпретирует запрос пользователя, определяет, какие части необходимо расширить с помощью словаря понятий, формирует итоговый запрос для механизма поиска и передает его.
Определение связей понятий
Добыча текстов на базе онтологий использует технологию выявления понятий. Knowledge Navigator, по существу, выявляет пространство понятий, организованное как определенные типы связей («ассоциаций» в терминологии XTM). Каждая такая связь может быть иерархической или неиерархической. Иерархические связи составляют основу для древовидного просмотра. И иерархические, и неиерархические связи важны для расширения запроса.
Внутри любой иерархической связи понятия имеют упорядочение «содержащийся/содержащий». Скажем, в предметной области управления персоналом имеется общая иерархическая связь «подчиняется»; менеджер может восприниматься как субъект, «содержащий» в себе каждого из своих сотрудников. Точно так же, в онтологии изделий часто встречается иерархическая связь «является компонентом» и каждый компонент принадлежит изделиям, частью которых он является.
Неиерархическая связь может быть либо связью «эквивалентно», либо связью «один-ко-многим».
Чтобы проиллюстрировать, как эти связи используются при поиске, предположим, что я хочу получить информацию о Zantac. Мне также может понадобиться информация о других лекарствах или продуктах, относящихся к терапевтическому или фармакологическому классу Zantac, об аналогах Zantac или о заболеваниях, для лечения которых применяется Zantac. Рис. 2 иллюстрирует возможный запрос в GSK Thesaurus. Действительно, поиск информации о терапевтическом или фармакологическом классах включает в себя иерархические связи, поскольку классы являются содержащими. Поиск аналогов или излечиваемых заболеваний, однако анализирует связи «аналог« и «используется для лечения», которые являются связями «один-ко-многим» и тем самым — неиерархическими.
|
| Рис. 2. Взаимосвязи понятий, использующие Zantac в качестве основного термина при поиске в пределах GSK Thesaurus |
Карта тем
Карта тем XML представляет каждое понятие (например, Zantac) в виде темы; каждую связь как тему, которая является видом ассоциации; каждый экземпляр связи как тему, которая является конкретной ассоциацией.
|
| Рис. 3. Фрагмент карты тем XML, который представляет понятия и связи между ними как темы. Карта тем отражает связи понятий, показанные на рис. 2 |
Понятие роли в карте тем (элемент ) показывает, когда понятие является субъектом связи «один-ко-многим» или элементом «содержащийся» или «содержащий». На рис. 3 в элементах для неиерархических связей «конкурент» и «используется для лечения» тема Zantac играет роль «субъект связи». А в элементе для иерархической связи in-therapeutic-class тема anti-ulcer agent играет роль содержащего, а Zantac — содержащегося.
Я исключил пример связей «используется для», которые являются общими в словаре. Карта тем представляет их за счет использования XTM-тегов , и .
Состояние проекта
Хотя пока говорить о результатах проекта, безусловно, преждевременно, мы уже серьезно продвинулись в двух областях.
Выбор формата XTM
Выбор XTM для канонического представления уже кажется весьма разумным. XTM — новый стандарт, который предлагает многофункциональный и гибкий язык для представления знаний и является мощным формализмом. Используя его, мы избежали необходимости разрабатывать собственный формализм представления знаний и сразу получили набор инструментальных средств, ориентированных на XML, для обработки или тестирования представлений XTM. Скажем, мы уже применяем программное обеспечение Omnigator компании Ontopia для тестирования XTM-конвертера. Этот инструментарий позволяет определять, насколько хорош результат работы транслятора, насколько адекватно преобразованная онтология соответствует оригиналу, и не привнесло ли преобразование каких-либо ошибок. Многие ориентированные на XML продукты распространяются свободно (например, Apache), многие языки поддерживают XML.
Возможно, еще важнее то, что, согласно нашим данным, очень многие организации преобразуют онтологии в формат XTM, как правило, по тем же причинам, что и мы. Надо сказать, что первоначально мы приняли решение разрабатывать свой канонический формат (типы связей, связи «содержащийся/содержащий» и так далее) самостоятельно и с учетом своих собственных требований. Однако позже мы пришли к выводу, что наша архитектура практически идентична способу, выбранному Ассоциацией международной федерации фармацевтических производителей (http://www.meddramsso.com) для организации своей онтологии, MedDRA. Если наше XTM-представление использует иерархические связи, эквивалентность или связи «один-ко-многим», то представление MedDRA использует иерархические связи, эквивалентность и ассоциативные связи (различие между «один-ко-многим» и ассоциативными связями, по сути, заключено только в названии). Такое сходство концептуальных моделей подтверждает, что мы выбрали мощную и надежную архитектуру. Наконец, усилия, которые требуются для изменения представления онтологий, относительно невелики. Создание транслятора для Emtree, GSK Thesaurus и WHO Drug Dictionary потребовало менее 300 новых строк кода на Python для каждого из трансляторов. Кроме того, у нас есть библиотека, состоящая приблизительно из 250 строк кода на Python, которую мы повторно используем в каждом новом трансляторе для форматирования определений XTM в выходном файле.
Преимущества расширяемости
На первый взгляд кажется, что проще избежать использования промежуточного формата и просто преобразовывать каждую онтологию непосредственно в набор тем Verity, семантическую сеть RetrievalWare или во что-то иное, воспринимаемое выбранной технологией извлечения информации. Считается, что написать один транслятор значительно легче, поскольку в этом случае не нужен сложный XTM-конвертер.
Однако на самом деле намного проще выполнить преобразование произвольной онтологии в четкий и хорошо определенный формат, такой, как наше каноническое представление XTM, чем во внутренний формат какого-либо производителя. Например, набор тем Verity поддерживает только связь «тема/подтема», поэтому определить, как отображаются многочисленные связи сложной онтологии на такую упрощенную структур, может оказаться делом непростым. Однако даже самая сложная онтология (такая как GSK Thesaurus) в наше представление XTM преобразуется довольно естественным образом.
Итак, основное преимущество расширяемости состоит в том, что один конвертер обрабатывает все детали определенного производителем представления. Необходимо написать такой конвертер лишь однажды, и все требования и знания для преобразования в формат производителя в нем инкапсулируются. Любой человек, от ученого до специалиста по персоналу и маркетингу, желающий добавить конкретную онтологию к платформе добычи текстов, должен разобраться только в простой и высокоуровневой структуре канонического формата XTM и преобразовать эту онтологию в данный формат.
Еще одно преимущество заключается в том, что критически важное представление знаний и ценное содержание онтологии удается отделить от устанавливаемого производителем формата. В будущем мы, скорее всего, захотим использовать эти онтологии вместе с иными механизмами поиска, нежели Verity — либо потому, что нам потребуется дополнительная технология, либо для того, чтобы заменить Verity. Попытка преобразовать онтологии из формата Verity потребует значительных усилий. Преобразование онтологий в формате XTM, наоборот, будет относительно простым, т. е. ненамного сложнее, чем модификация XTM-конвертера. Кроме того, формат набора тем Verity реализует относительно простое и низкоуровневое представление, имеющее только связь «тема/подтема». И Verity не исключение; это простейшее представление применяется во многих других механизмах поиска. Следовательно, определенный объем информации во время преобразования «богатого» представления XTM в представление, ориентированное на механизмы поиска, попросту теряется. Большая часть этой информации в формате XTM относится к различным типам связей, причем эти связи могут быть иерархическими, «один-ко-многим» и «эквивалентность». Все эти дополнительные структуры и сложность в наборе тем Verity не отражаются. (Вообразите себе попытку представить ту же самую программу на языке высокого уровня, таком как Java, на ассемблере или в виде байт-кода). Мы используем свое представление XTM и для создания словарей понятий и интерфейсных компонентов — информацию, требуемую для этого, нелегко (если вообще возможно) извлечь из установленного производителем формата.
Наконец, интересное и неожиданное преимущество того факта, что платформа является расширяемой, заключается в том, что в итоге появляется возможность выявить ошибки и недостатки онтологии, которые ранее обнаружить не удавалось. Это практически не относится к онтологиям, разработанным отраслевыми рабочими группами, профессиональными организациями или коммерческими компаниями. Однако, что же касается внутренних онтологий, такое изменение представления может дать ценную информацию тем, кто их создавал. Во время преобразования GSK Thesaurus, например, на двух переходах от оригинального формата к XTM и от XTM к набору тем Verity, было выявлено около 40 недостатков, ошибок или изъянов архитектуры. В онтологии, содержащей примерно 35 тыс. терминов, это число не кажется огромным, но некоторые ошибки могли иметь весьма серьезные последствия.
Преодоление трудностей
За счет использования распознаваемых и заслуживающих доверия онтологий вместо попыток найти средства, ресурсы и возможности для реализации новых проектов, которые, по сути, будут представлять собой попытки изобрести то, что уже существует, компания может потратить значительно меньшие средства и получить высокий возврат от инвестиций в уже существующую технологию механизма поиска. Для нас возможность использовать существующие онтологии в Verity в качестве тем и наборов тем позволила реализовать мощные возможности поиска, категоризации и объединения, имеющиеся в Verity, применительно к тем предметным областям, которые представляют для нас интерес.
За счет применения формализма XTM мы смогли создать мощный и вместе с тем простой механизм представления знаний, служащий для преобразования существующих онтологий, систематик и словарей в промежуточный формат, не зависящий от нашего представления механизма поиска. Наша платформа решает задачу расширяемости, позволяя легко ассимилировать уже существующие (и зачастую очень большие) онтологии в платформу добычи текстов. Это позволит тем, кто не является специалистом по технологии извлечения информации, расширять платформу на новые предметные области с минимальными усилиями. Она решает проблему компетентности в предметной области: как гарантировать, что профессиональные пользователи посчитают платформу адекватной в интересных для них предметных областях. Вместо того чтобы быть вынужденным разрабатывать точную и адекватную онтологию с самого начала в очень сложной предметной области, мы можем использовать методологию Babylon, ассимилируя онтологии, которые уже применяются в данной предметной области. Следовательно, можно гарантировать, что наши приложения добычи текстов будут использовать словарь и структуру понятий, которые уже подтвердили свою состоятельность.
Гери Меррилл (gary.h.merrill@gsk.com) — директор подразделения Data Exploration Sciences фармацевтической компании GlaxoSmithKline.
Онтологии и добыча текстов
Основная идея проекта Babylon заключается в использовании уже существующих систематик, словарей и онтологий. Более того, эти источники получили широкое признание, и компания, скорее всего, уже работает с ними, хотя и не без сложностей.
В основной части статьи я использую практически один только термин «онтология», поскольку в добыче текстов границы между систематиками, онтологиями и словарями весьма нечетки. К примеру, GSK Thesaurus начал свое существование как словарь, но постепенно превратился в достаточно сложную онтологию.
Возможно, наиболее общее из этих понятий онтология, возникло из истории философии. Онтология — это описание или организация того, что есть, множества вещей, которые существуют, и определяет, как эти вещи взаимосвязаны. Связи внутри онтологии могут, таким образом, быть многосторонними и сложными.
Систематика, вид древовидной онтологии — это набор категорий и подкатегорий. Она, проще, чем истинная онтология, и не демонстрирует всего богатства реляционной структуры онтологии.
Словарь — список слов со ссылками на слова со сходными значениями. В классических словарях связи между объектами являются, конечно, связями между словами — «более широкий термин», «более узкий термин», «используется для» и т.д.
Онтологии важны для улучшения возможностей извлечения информации и добычи текстов. Они служат в качестве источника словаря для поиска, ориентированного на понятия, и для реализации более совершенных методик вычислительной лингвистики, которые требуют разметки фрагментов речи или идентификации объектов. Например, если я хочу выбрать информацию (или документы) о раке, то здесь целесообразно использовать онтологию, поскольку она позволит автоматически расширить мой запрос и включить в него такие слова, как «лимфома», «болезнь Хожкина», «саркома», «карцинома» и «неоплазма». Таким образом, простой запрос термина, который ищет только слово «рак», заменяется на запрос понятия (запрос, который ищет набор терминов, связанных с раком). Онтология также предлагает иерархический способ организации информации (факты или извлекаемые документы), которые помогают в создании графических интерфейсов, дающих пользователям возможность относительно просто работать в сложной предметной области.
***Рынок не испытывает недостатка в продуктах добычи текстов, но их качество значительно разнится. Даже самые качественные продукты данной категории трудно развертывать, поскольку они часто игнорируют специфические лингвистические требования конкретной предметной области.
***Диссонанс между технологией добычи текстов и возможностью успешно применять ее в рамках конкретной предметной области вряд ли удастся устранить в ближайшее время. Специалисты по технологиям, разрабатывающие инструменты добычи текстов, не разбираются в достаточной мере во множестве конкретных предметных областей.
***Намного проще выполнить преобразование произвольной онтологии в открытый, четкий и хорошо определенный формат, чем во внутренний формат какого-либо отдельного производителя.
Gary H. Merrill, The Babylon Project: Toward an Extensible Text-Mining Platform. IEEE IT Pro, March-April 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.
