Разделы
Счетчики
Глава 3. Система анализа естественного языка
- Система анализа естественного языка
- 3.1 Реализация семантически-ориентированного подхода в системе анализа ЕЯ
- 3.2 Концептуализации в семантически-ориентированном подходе
- 3.2.1 Концептуализации в МПО
- 3.2.2 Концептуализации в словаре
- 3.2.3 Концептуализации в анализе запроса
- 3.2.4 Что может дать разбиение МПО на концептуализации?
- 3.2.5 Пример разбиения МПО на концептуализации:
- 3.3 Реализация продукционой программы
- 3.3.1 Строение сети
- 3.3.2 Выбор определяющей концептуализации
- 3.3.3 Выбор главного объекта
- 3.3.4 Разрешение неоднозначности
3.1 Реализация семантически-ориентированного подхода в системе анализа ЕЯ
В описываемой системе в Л-процессоре применяется семантически-ориентированный подход к анализу ЕЯ (Нариньяни 1979). В этом его отличие от многих аналогичных систем построения ЕЯ-интерфейсов, который основаны, как правило, на шаблонном или синтаксически-ориентированном подходе (Androutsopoulos at al, 1995). Суть семантически-ориентированного подхода в том, что лексическим единицам языка (лексемам, словокомплексам) приписываются определенные семантические классы, выражающие смысл данной лексической единицы в регистре запросов к базе данных (Sharoff, Zhigalov 1999). Кроме того, некоторые семантические классы имеют в качестве атрибута семантическую ориентацию, которая в каждом конкретном случае связывает данное слово с определенным элементом модели предметной области.
Система семантических классов и процесс анализа построены таким образом, что в ходе анализа выделяются те комбинации семантических классов, которые в запросе имеют смысл более крупных семантических структур (например, предикатов). Таким образом, осуществляется процесс построения дерева запроса снизу-вверх. Использование семантических ориентаций позволяет выполнять взаимное уточнение смысла лексем, используя их контекстное вхождение в запросе.
Для демонстрации работы семантически-ориентированного подхода рассмотрим анализ запроса к тестовой базе "Кадры", содержащей одну таблицу, в которой каждой записи соответствует сотрудник:
|
Зарплата телефон |
|||||||||
|
Attr(Salary) |
Val(Post) |
LogConj |
Insign |
Attr(HomePhone) |
Attr(WorkPhone) | ||||
|
Attr(HomePhone) | |||||||||
Под каждым словом даны семантические классы с семантической ориентацией в скобках. Классы и ориентации указываются в словаре. В результате анализа собираются предикаты из значений: в этом запросе слово "менеджер" имеет семантическую ориентацию на поле базы данных Post, чего вполне достаточно для собирания предиката:
Post='manager'.
Поисковый образ 'manager' также хранится в словаре, он получается в результате прокачки. Остальные атрибуты не имеют соответствующих значений в значений, поэтому они попадают в часть запроса "выдать". Результирующий запрос на SQL выглядит следующим образом:
select name, lastname, salary, workphone, post
from kadr
where post like '%manager%'
В список выдаваемых атрибутов попадают имя и фамилия сотрудников (эти атрибуты заданы по умолчанию к выдаче), а также должность (поскольку атрибут Post входит в предикат).
Рассмотренный запрос имеет неоднозначность в семантическом значении слова "телефон", которое может означать как служебный, так и рабочий телефон, то есть имеет две ориентации - workphone и homephone. При взаимном уточнении с близким по контексту словом "рабочий", которое имеет значение только рабочего телефона, результирующая семантическая ориентация получается пересечением множеств ориентаций в уточняемых словах. Результирующая ориентация - workphone.
Этот рассмотренный пример запроса - к достаточно простому ЕЯ-интерфейсу к базе данных, состоящей из одной таблицы. Однако опыт разработки ЕЯ-интерфесов показал, что для более сложных предметных областей этот подход в его традиционном исполнении дает ряд сложностей.
Рассмотрим запрос к базе данных "NorthWind", которая описывает деловую деятельность небольшой фирмы, торгующей некоторым набором продуктов.
|
Продукты |
стоимостью |
от |
100 |
руб. |
|
Obj(Product) |
Attr(Product.price) |
(>) |
Val(Product.price) |
Unit(Product.price) |
|
Attr(OrderItem.sum) |
Val(OrderItem.sum) |
Unit(OrderItem.sum) | ||
|
Attr(Order.sum) |
Val(Order.sum) |
Unit(Order.sum) |
Видно, что данный запрос имеет большую неоднозначность на уровне отдельных лексем. Это создает затруднения в правильном понимании системой запроса. Решение данной проблемы идет в предлагаемом подходе по двум основным путям:
- МПО дополняется концептуальными структурами. Под концептуальными структурами, или концептуализациями, здесь понимается совокупность ролевых отношений, которые строятся поверх основной схемы классов МПО. Для рассматриваемого запроса может быть применена концептуализация PRODUCT, которая содержит роли, являющиеся атрибутами класса Product: name, price, и т.д. При анализе определяется наиболее вероятная концептуализация для данного запроса. Критерием вероятности является, например, полнота отождествления лексем запроса ролями данной концептуализации, а также наличие в запросе концепт-маркера, т.е. слова, которое однозначно указывает на определенную концептуализацию. Этот подход выделяет только те смыслы слова, которые определены в "победившей" концептуализации, которая называется определяющей.
- Добавлен новый способ доуточнения: для пары уточняемых слов вычисляются два параметра - сила контекстной связи в запросе и сила связи по предметной области. При разрешении неоднозначности учитываются оба этих параметра, причем преимущества получают варианты с максимальными силами связи.
- Правила взаимного уточнения оригинального семантически-ориентированного подхода дополняются рядом новых правил. Так, например, введение нового класса Obj (объект) повлекло за собой необходимость введения правил для этого класса, аналогичные уточняющим правилам для семантического с классом атрибут (Attr).
Применительно к нашему запросу первый путь (ввод концептуализаций) приводит к тому, что из всех прореагировавших концептуализаций только PRODUCT имеет концепт ("Продукт") в запросе, а, следовательно, и имеет безусловное преимущество. После удаления ролей других концептуализаций получаем:
|
Продукты |
стоимостью |
от |
100 |
руб. |
|
Obj(Product) |
Attr(Product.price) |
(>) |
Val(Product.price) |
Unit(Product.price) |
Таким образом, устраняется неоднозначность для всех лексем в запросе.
Второй путь (введение более гибкого механизма уточнения через силу связи между лексемами) определит, что лексемы "продукт" и "стоимостью" имеют сильную связь в контексте (стоят рядом) и наиболее сильно связаны в МПО (стоимость является атрибутом продукта). После уточнения этих двух слов уточняются аналогичным способом и остальные слова запроса, что также приводит к правильному пониманию запроса.
Сравнивая эффективность двух методов - с концептуализациями и без, надо отметить, что первый приводит к более надежным результатам, но требует предварительного задания концептуализаций для данной ПО, тогда как второй требует меньших усилий при настройке ЕЯИ, будучи при этом менее надежным способом. Однако комбинация этих двух методов приводит к довольно высокому качеству работы системы анализа в целом. В результате качество понимания зависит от усилий, затраченных при настройке системы - адекватное и полное описание концептуализаций предметной области приводит к максимальному эффекту.
В дальнейшем описании концептуализаций и их применения в предлагаемом методе анализе ЕЯ для примеров используется ЕЯ-интерфейс к тестовой базе NorthWind.
3.2 Концептуализации в семантически-ориентированном подходе
Концептуализации - слой отношений между узлами поверх основной сети МПО. Каждую концептуализацию можно рассматривать как некоторый "срез" МПО, применительно к некоторой ситуации либо сущности. Концептуализация состоит из ролей, каждая из которых является слотом, имеющим ориентацию на некоторый узел МПО.
Следует различать два вида концептуализаций - ситуационную и сущностную. Ситуационные концептуализации обозначают, как правило, некоторое действие. Например, ситуационная концептуализация ORDER - это факт заказа клиентом некоторых продуктов, объединенных заказом. Для нее характерны следующие роли: (who) - кто заказал, указывает на узел Customer, (what) - что заказано, может указывать как на продукт Product, так и на заказ в целом Order, (when) - когда заказано, указывает на Order.whenOrdered, (via) - сотрудник, обслуживший заказ - Employee.
Сущностные концептуализации - это как правило классы и их атрибуты, названия ролей совпадают с названиями атрибутов (см. далее описание концептуализаций Product и Employee). Сущностные концептуализации позволяют рассматривать некоторый фрагмент МПО на прагматическом уровне ЕЯ. Например, клиенты сотрудника в концептуализации Employee выражаются аксессором Employee.Order.Customer, то есть через заказ. Поскольку большинство сущностных концептуализаций полностью повторяет структуру класса описываемой сущности, должна быть предусмотрена возможность помечать класс МПО как концептуализацию, а его атрибуты - как роли, вместо того, чтобы вручную создавать концептуализацию. Такой описанный класс при анализе будет создавать концептуализацию, а в концептуальном уровне МПО эта концептуализация будет присутствовать в неявном виде.
Введение концептуализаций в МПО в некоторых случаях позволяет избежать ошибочного понимания смысла запроса. Дело в том, что из-за сетевого представления МПО возможны случаи, когда два класса предметной области можно связать двумя путями. Скажем, в предметной области "Музыка" есть классы предметной области "Произведение" и "Музыкант". Учитывая то, что музыкант может исполнять произведение, написанное другим автором, схема классов допускает две связи между "Произведением" и "Музыкантом" - "автор" и "исполнитель". Тогда в процессе анализа при построении аксессора возникает неоднозначность - по какой связи строить аксессор. Характерно, что сам запрос обычно не содержит неоднозначности такого характера. Введением же двух концептуализаций, в которых эти связи разделены, эта проблема решается. При этом концептуализация представляет собой сеть, состоящую из ролей, связанных (опционально) аксессорными путями. В случае же однозначности построения аксессора от одной роли до другой связи между ролями указывать не обязательно.
Есть некоторый набор предопределенных ролей. Сoncept - концепт-маркер, идентифицирующая концептуализацию в целом. Who (агенс) - обозначает действующий субъект в концептуализации, ориентируется в МПО на класс; роли-обстоятельства времени и места: when, where, from, to; роль-пациенс what, которая обозначает объект в действии или ситуации. Предопределенные роли могут быть включены в анализ продукционной программой непосредственно, также при использовании такой роли возможно добавление в словарь соответствующей лексики, например, слов кто, что, где и т.д. Кроме того, предполагается, что предопределенные роли будут наиболее часто встречающимися в концептуализациях.
Приведенные здесь названия ролей условные, сами по себе они не несут грамматического значения, хотя предполагается, что ролям можно приписывать синтаксические характеристики. В процессе анализа синтаксические характеристики лексем запроса сопоставляются с синтаксическими характеристиками ролей, повышая таким образом надежность выбора определяющей концептуализации запроса: дополнительные преимущества получают концептуализации, в которых синтаксические характеристики ролей совпадают с синтаксическими характеристиками лексем запроса.
Отсутствие концептуализаций, заданных настройщиком, не должно означать, что анализ будет невозможен. При отсутствии их анализ должен основываться на более простых, но менее надежных принципах - на основе сети МПО, омонимия лексем разрешается сочетаемостью контекстных элементов с точки зрения связей между ними в сети МПО. Таким образом, качество работы системы должно быть адекватно затраченным усилиям настройщика, но на каждом уровне усилий система должна использовать все возможное из той информации, что есть в наличии - всеми доступными способами. Можно считать, что сеть МПО составляет концептуализацию по умолчанию, роли в ней совпадают с семантическими ориентациями МПО.
3.2.2 Концептуализации в словаре
В словаре лексемам, помимо обычных семантических ориентаций, указывающих на узлы сети МПО, должны быть сопоставлены и ролевые ориентации для концептуализаций, в которых данное слово значимо. Например, слово "company" будет иметь следующие ролевые ориентации:
ORDER.(who) - "кто заказал"
DELIVER.(who) - "кто доставил заказ"
DELIVER.(to) - "кому доставлен заказ"
SUPPLY.(who) - "кто поставил продукт"
Ролевые ориентации для слова "country":
ORDER.(from) - "из какой страны поступил заказ"
DELIVER.(to) - "в какую страну заказ доставлен"
SUPPLY.(from) - "откуда поступил продукт"
PRODUCT.(from) - то же
Концепт-маркеры в ситуационных концептуализациях выражаются на лексическом уровне глаголами действия, и имеют, как правило, семантические ориентации на объектный атрибут. Например, глагол order указывает на ORDER, work - на EMPLOYEE, product - на PRODUCT и т.д.
Таким образом, лексема в запросе в общем случае имеет трехуровневую семантическую ориентацию: концептуализация - роль - ориентация на элемент схемы классов. Для удобства далее они будут обозначаться следующим образом:
CR-ориентации: концептуально-ролевые (Concept-Role);
CS-ориентации: ориентации на элемент диаграммы классов (Class Scheme).
Далеко не все лексемы могут участвовать в концептуализациях. Семантические классы, не представленные в МПО, например, отношения, отрицания, не могут и быть ролями в концептуализациях. Особый случай со значениями атрибутов - Val. Было бы неправильно явно включать в концептуализации все значения атрибутов. С целью сокращения сложности концептуализаций и усилий по настройке ЕЯ-интерфейса CR-ориентации значений вычисляются по CS-ориентации. Это означает, что CR-ориентация атрибута присваивается значениям этого атрибута.
3.2.3 Концептуализации в анализе запроса
Отождествлением запроса и концептуализации будем называть наложение (унификация) ролей концептуализации и лексем запроса. В процессе анализа строятся начальные цепочки с точки зрения всех концептуализаций, то есть по одной цепочке для концептуализации. При этом узлу цепочки соответствует отождествленная роль, а значит, одна или несколько компонентов с ориентацией на узлы сети МПО. Далее из отождествленных концептуализаций выбираются самые сильные. Критерием силы концептуализации в данном запросе являются следующие параметры:
- Полнота отождествления (концептуализации, наиболее полно покрывающие запрос, сильнее).
- Покрытие ролями лексем-значений. Преимущества получают те концептуализации, которые наиболее полно используют лексемы-значения, чтобы не терялась важная семантическая информация. Появление этого параметра связано с гипотезой о том, что семантический класс значения (Val) имеет наибольшее значение для понимания смысла запроса и не может поэтому оставаться неучтенным.
- Наличие в запросе концепт-маркеров данной концептуализации.
- Роли могут быть отранжированы по важности. Например, (who) - агенс, более важен в концептуализации, чем (what) - пациенс. Преимущество получает концептуализация с более "важными" ролями.
После вычисления "силы" концептуализаций некоторые из них отпадают сразу (например, не имеющие концепт-маркеров, если есть таковые с концепт-маркерами, либо имеющие всего одну отождествленную роль, если есть с несколькими). Остальные отождествления складываются по определенным правилам:
- Если в концептуализации А данная лексема не имеет роли, а в Б имеет, то в суммарном отождествлении за лексемой остается ориентация на узел МПО, на который указывает роль в концептуализации Б.
- Если лексема в двух складываемых отождествлениях имеет роли, и если роли указывают на один и тот же узел МПО, то выполняется связывание концептуализаций по этому узлу МПО (в примере выше таким узлом является product), лексема приобретает ориентацию на этот узел. Связывание концептуализаций в данном случае означает то, что оба отождествления объединяются в одно более общее, а две роли, по которым произошло связывание, объединяются в одну.
- Если роли данной лексемы указывают на различные узлы МПО, то отмечается "внешняя" омонимия (т.е. требующая выбора между концептуализациями). Выбор должен происходить на основе силы концептуализаций в данном запросе.
На основе выбора концептуализации разрешаются все случаи омонимии в запросе. То есть если по анализу всех случаев омонимии (например, вводом некоторого интегрального показателя для каждого из вариантов) выбрана одна наиболее вероятная концептуализация, то она является определяющей для разрешения всех случаев омонимии.
Если в данной лексеме в определяющей концептуализации нет роли, но другие концептуализации образовали внешнюю омонимию в этой лексеме, то выбор ориентации для данной лексемы происходит для этих конкурирующих концептуализаций на основании наиболее вероятной концептуализации после определяющей.
Смысл операции сложения - в получении интегрального отождествления запроса возможным концептуализациям, по возможности непротиворечивого, и использующего максимально все отождествленные роли выбранных концептуализаций. В интегральном отождествлении роли уже не несут такой нагрузки, как в каждой концептуализации - они имеют смысл только относительно конкретной концептуализации. Дальше они используются только для разрешения внешней омонимии, но уже оценивается только важность предопределенных ролей ((concept) важнее остальных ролей, (who) важнее, чем (what) и т.д.).
Если слову не соответствует концептуально-ролевой ориентации, но есть CS- ориентация, то при сложении существующих отождествлений ориентации этих "свободных" слов складываются с результирующим отождествлением по правилам, описанным выше. В случае внешней омонимии вариант свободного слова имеет минимальный приоритет, всегда более низкий по сравнению с приоритетом варианта из концептуализации.
После сложения отождествлений осуществляется выбор главного объекта, а на его основании - выбор окончательной определяющей концептуализации. Возникшие при сложении случаи внешней неоднозначности разрешаются в пользу определяющей концептуализации, если это возможно.
Концептуализации могут содержать синтаксическую информацию об отношении между ролями (например, глагольное управление). Однако следует максимально обходиться более простыми методами, нежели синтаксический анализ запроса (или работать с синтаксисом локально). Сами роли могут иметь грамматические значения (актанты, обстоятельства времени и места и т.д.).
Операция уточнения при таком подходе заменяется на операцию выбора наиболее адекватных концептуализаций. В цепочках каждой концептуализации в процессе анализа смысл лексем уже является уточненным, но с точки зрения данной концептуализации. Большое значение приобретает правильное разбиение МПО на такие концептуализации.
- Большее приближение к естественно-языковому представлению ПО. Например,
концептуализация PRODUCT дает роли, которые "сокращают" связи в МПО, обогащая
их семантическими связями, более характерными для прагматического
представления в естественном языке, чем связи МПО, отражающие строение базы
данных:
product - from (страна, откуда продукт; в МПО: Product - Supplier - Country.name)
product - who_ordered (клиент, заказавший продукт; в МПО: Product - OrdItem - Order - Customer)
- Более многоплановое и вместе с тем конкретное представление отдельных аспектов МПО. Так, для нашей базы есть несколько транзакционных ситуаций, то есть действий: поставка продуктов (SUPPLY), заказ клиентами товаров (ORDER), доставка готовых заказов (DELIVER). Есть также относительно статические разрезы информации: продукты, их характеристики (PRODUCT), сведения о сотрудниках (EMPLOYEE). Каждый такой разрез имеет присущие ему роли, при этом одни и те же узлы МПО в различных концептуализациях выступают в различных ролях: в SUPPLY "мы" покупаем продукт, при этом слово "купить" имеет смысл покупки у поставщика, а в ORDER - обратная роль - продукт продаем "мы", покупает уже клиент.
- Более осмысленное разрешение омонимии. Каждая концептуализация дает свое представление смысла омонимичной лексемы, а вместе с ним и смысл всего запроса. Анализ должен рассматривать варианты от различных концептуализаций и оценивать правдоподобность этих вариантов, анализируя синтаксис запроса.
Ниже дано описание концептуализаций и их ролей в МПО базы данных "North Wind". Для каждой концептуализации приведена таблица ролей, в которой для каждой роли указаны их CS-ориентации, описан смысл, а также приведены примеры слов, имеющих данную CR-ориентацию.
Список концептуализаций:
ORDER - заказы и клиенты
SUPPLY - покупка товаров от поставщиков
EMPLOYEE - сотрудники и их атрибуты
PRODUCT - иерархия категорий продуктов, поставщики
DELIVER - доставка заказов
ORDER
Ситуационная концептуализация, выражает ситуацию "заказывать":
|
Роль |
CS-ориентация |
Семантика |
Типичная лексика |
|
concept |
Customer.Orders |
Факт заказа клиентом |
заказывал; заказ; покупать; продавать |
|
who |
Customer |
Кто сделал заказ |
кто; компания; клиент; заказчик |
|
when |
Order.whenOrdered |
Когда был сделан заказ |
когда; дата; значения дат, попадающие в интервал атрибута Order.whenOrdered |
|
from |
Customer |
Откуда поступил заказ |
Германия; Калифорния; RA-Enterprise |
|
via |
Employee |
Сотрудник, оформивший заказ |
сотрудник; Иванов; обслужил |
|
what |
Product, |
Что именно заказывали |
что; заказы; продукты |
SUPPLY
Ситуационная концептуализация, описывающая поставку продуктов от поставщиков:
|
Роль |
CS-ориентация |
Семантика |
Типичная лексика |
|
concept |
Product.Supplier |
Поставка продукта некоторым поставщиком |
поставщик; поставка; покупать |
|
who |
Supplier |
Кто поставлял тот или иной продукт |
кто; компания; Wim-Bill-Dann; поставщик |
|
what |
Product |
Какой продукт поставлялся |
молоко; алкогольные напитки; рыбные продукты |
|
from |
Supplier.address |
Откуда поставлялся продукт |
откуда; адрес; страна; Франция |
EMPLOYEE
Сущностная концептуализация, описывающая сведения о сотрудниках: все атрибуты сотрудника.
|
Роль |
CS-ориентация |
Семантика |
Типичная лексика |
|
concept |
Employee |
сведения о сотруднике |
работник; сотрудник |
|
born |
Employee.born |
дата рождения |
родившийся; любая дата, попадающая в интервал атрибута Employee.born |
|
hired |
Employee.hired |
дата приема на работу |
работающий с; любая дата, попадающая в интервал атрибута Employee.hired |
|
name |
Employee.name |
имя |
имя; Сергей |
|
lastname |
Employee.lastname |
фамилия |
Иванов |
|
sex |
Employee.sex |
пол |
мужчины; сотрудницы |
|
service |
Employee.service |
отдел |
отдел |
|
age |
Employee.age |
возраст |
старше |
|
post |
Employee.post |
должность |
должность |
|
orders |
Employee.Orders |
заказы, обслуженные сотрудником |
заказы |
PRODUCT
Продукты:
аналогично сотрудникам - все атрибуты продуктов
DELIVER
Доставка заказа клиенту - ситуационная концептуализация:
|
Роль |
CS-ориентация |
Семантика |
Типичная лексика |
|
concept |
Order.Deliver |
Доставка заказа клиенту фирмой, специализирующейся на доставке |
доставлен; доставщик |
|
who |
Deliver |
Кто доставил |
компания; доставщик |
|
what |
Product |
Что было доставлено |
что; заказ; продукты |
|
when |
Order.whenShipped |
Когда был доставлен заказ |
когда; любая дата, попадающая в интервал атрибута Order.whenShipped |
|
whom_to |
Order.Customer |
Кому был доставлен заказ |
заказчик; кому |
|
where_to |
Customer.Country, |
Куда был доставлен заказ |
куда |
За основу описываемой продукционной программы была взята программа, используемая в системе InterBASE (Trapeznikov et al 1993), переведенная в язык SNOOP с языка Lingua.
Перед началом анализа происходит лексический анализ с построением начальной цепочки. Поскольку словарь и лексический анализ поддерживают настоящую омонимию (то есть может быть несколько одинаковых статей в словаре), в цепочке могут быть омоним-группы, т.е. группы компонентов, относящихся к одному слову, но имеющие разные семантические ориентации.
Омоним-группы состоят из омонимичных компонентов, связанных предопределенным отношением <omonim>, каждый из омонимом связан с соседней лексемой отношением <lexrel>. Если омоним-группы стоят рядом в запросе, каждый компонент одной омоним-группы связывается с каждым компонентом второй омоним-группы связью <lexrel>.
Каждый МПО-зависимый узел имеет три ориентации: концептуальную, ролевую и семантическую. Семантическая ориентация анализируется, если не заданы концептуальная и ролевая ориентации (обычно если не заданы концептуализации).
Концептуализации задаются в МПО в виде сетей, в которых роли связаны отношениями <role> с головным узлом - концептом. Каждая концептуализация имеет узел concept и узлы role. В concept задаются название концептуализации и ее уникальный номер, в ролях - название роли и ссылка на concept. И концепты, и роли имеют семантические ориентации на узлы МПО.
После построения начальной цепочки в рабочей сети появляется также узел класса ConceptList, отвечающий за список концептуализаций. Первоначально его поле concepts содержит список всех id концептуализаций (поле типа шкала). Затем просмотром начальной цепочки из этого списка удаляются id тех концептуализаций, которые не были отождествлены хотя бы по одной лексеме. Этот узел далее хранит рейтинг каждой концептуализации в запросе.
После лексического анализа начальная цепочка представляет собой множество отождествлений (каждый компонент отождествления является узлом классов, составляющих МПО и имеет id, совпадающее с id соответствующей концептуализации - т.е концептуальную ориентацию). Дальше происходит ранжирование этих отождествлений. Каждому в результате выполнения правил приписывается некоторый рейтинг. Нулевой рейтинг свидетельствует о том, что отождествление по сравнению с остальными является заведомо "проигрышным", и, однажды получив нулевое значение, рейтинг не может быть изменен - такое отождествление удаляется.
- Полнота отождествления (концептуализации, наиболее полно "покрывающие" запрос, сильнее)
Вычисляется количество отождествленных лексем в каждой концептуализации, это количество записывается в ConceptList, в поле count (шкала), в позицию, соответствующую id данной концептуализации.
- Покрытие лексем-значений ролями (преимущества получают те концептуализации, которые наиболее полно используют лексемы-значения, чтобы не терялась важная семантическая информация)
Вычисляется количество отождествленных лексем-значений (значения, толкования с предикатами) для каждой концептуализации - в поле valcount.
- Наличие в запросе концепт-маркеров данной концептуализации.
Поле concept содержит id концепта в данной позиции, если концепт присутствует, и 0 - если нет.
Дальше выполняются правила, составляющие список аутсайдеров:
- Если отождествление не содержит концепта, но есть содержащие концепт, то удаляем из списка.
- Если count для данного отождествления не превышает 1, но есть отождествления с count, превышающим 1, удаляем из списка.
После заполнения этих полей заполняется поле rate, которое содержит список id концептуализации по убыванию их рейтинга. Все вышеперечисленные действия должны быть инкапсулированы в методы узла ConceptList.
Операция сложения явно не осуществляется - по сути, полученная после удаления отождествлений-аутсайдеров цепочка представляет собой результирующее интегральное отождествление.
Те компоненты, которые не участвуют явно в концептуализациях и МПО (союзы, отрицания, отношения и т.д.), не относятся к какому-либо отождествлению, а являются общими для всех, а значит, для запроса в целом (концептуальная и ролевая ориентации равны 0).
На основании рейтинга выбирается определяющая концептуализация, ее члены в запросе помечаются признаком опр. концептуализации Если определяющая концептуализация не может быть однозначно выбрана, она может доопределиться после выбора главного объекта.
Правила выбора главного объекта (в порядке достоверности):
- Концепт-атрибут либо концепт-объект, перед которым стоит слово - Q-маркер (what company, list the product, all fathers , ...) при этом Q-маркер стоит первым в запросе. Между ним и концептом может быть один или несколько компонентов-значений, в т.ч. и толкований, которые вводят предикаты: father (sex='m', childnum>0), beer (раскрывается в дереве гиперзначения), european orders (Order.Cuctomer.Country in Europe).
- То же - если Q-маркера нет, но концепт стоит первым в запросе, либо перед ним - компоненты-значения.
- Концепт определяющей концептуализации определяет главный объект (каждой концептуализации в МПО должен быть сопоставлен класс, который в дальнейшем станет по умолчанию главным в данной концептуализации).
- Если не сработало ни одно из правил, то главным объектом становится объект, который находится первым в списке кандидатов в главные объекты (может задаваться в МПО). Если этот список не задан настройщиком, главным становится первый объект в запросе (либо берется из первого атрибута или значения объект, к которому они относятся).
Если после выбора главного объекта осталась неоднозначность в выборе определяющей концептуализации, то этот выбор осуществляется на основании уже выбранного главного объекта.
Неоднозначными считаются лексемы, которым соответствуют омоним-группы. Для разрешения неоднозначности надо оставить в каждой омоним-группе по одному элементу.
Если в запросе отождествлены концептуализации, на выбор элементов в омоним-группе будет влиять определяющая концептуализация: роль из определяющей концептуализации в омоним группе всегда побеждает. Если в данной омоном-группе нет ролей определяющей концептуализации, то выбор ведется по рейтингу концептуализаций в запросе - роли концептуализации с большим рейтингом имеют больший приоритет.
Если анализ идет без отождествлений (например, если к. не были заданы настройщиком либо просто ни одна концептуализация не отождествилась), то определяющим при выборе станет:
- расстояние в сети МПО от главного объекта до данного компонента.
- расстояние в сети МПО от данного компонента до контекстно близкого ему в запросе.
В таблице ниже приведены контекстные шаблоны; полужирным шрифтом выделены те из них, которые были добавлены к первоначальному варианту программы. В таблице используется следующие условные обозначения:
V - значения
U - единица измерения
A - атрибут
O - объект
> - сравнение
V U
U V
A A
A > V
> A V
> V A
V > V (ориентация V на атрибут типа Дата)
> V > V
A - V
A V
V A
V V
O * > V
O * - V
> O * V
> V * O
V * O
O * V
В Приложении 1 даны примеры анализа запросов.
В Приложении 2 приведена система правил (основной модуль).
Источник: (Компьютерный диалог)
Дополнительно
Дисертация Владислава Жигалова
http://www.aha.ru/~zhigalov/science/disser.zip - Word'97 (zip - 336k)