CC BY
119
УДК 004.91
© А. О. Шигаров
ПРОЕКТ ИНТЕЛЛЕКТУАЛЬНОЙ СИСТЕМЫ ИЗВЛЕЧЕНИЯ ТАБЛИЧНОЙ ИНФОРМАЦИИ ИЗ НЕСТРУКТУРИРОВАННЫХ ТЕКСТОВ1
Данная работа посвящена актуальной проблеме — разработке средств автоматизации для извлечения информации из произвольных таблиц со сложной компоновкой, представленных в неструктурированных текстах. Такие таблицы не включают формальную модель данных (например, реляционную модель данных), но имеют различные идентификаторы структуры (например, графическое форматирование, элементы компоновки и разметки).
Ключевые слова: анализ и обработка табличной информации, извлечение информации из таблиц, анализ и распознавание документов, системы анализа документов, информационный поиск, обработка неструктурированной информации.
© A.O. Shigarov
DESIGN OF INTELLEGENT SYSTEM FOR TABLE INFORMATION EXTRACTION FROM UNSTRUCTURED TEXTS
The paper is addressed to actual problems of development of tools for automation information extraction from random tables with a complex arrangement in unstructured texts. These tables do not include a formal data model (e.g. relational data model), but they have different structure identifiers, (e.g. graphical formatting, layout, or markup)..
Keywords: analysis and processing of table information, information extraction from tables, document analysis and recognition, document analysis systems, information search, unstructured information processing.
Введение
В настоящее время многие исследователи, в т. ч. один из наиболее известных исследователей в области управления данными - Inmon B. [1] - отмечают важность проблем управления и интеграции неструктурированной информации. Под термином «неструктурированная информация» или «неструктурированные данные» (англ. unstructured information or unstructured data), как правило, понимается любая информация, которая не имеет предопределенной формальной модели данных или не укладывается в таблицу реляционной базы данных [2]. Примерами такой информации являются изображения, научные статьи, отчеты, e-mail сообщения. Следует отметить, что иногда также используются более аккуратные термины — слабоструктурированные документы (англ. weakly structured documents) для обозначения текстовой информации, включающей в себя некоторые индикаторы структуры в виде элементов графики, компоновки или разметки, и полуструктурированные документы (англ. semi-structured documents) для обозначения текстовой информации, включающей в себя некоторые структурные и содержательные метаданные (например, HTML страницы). Подробное обсуждение этих терминов можно найти в работе Feldman R. и Sanger J. [3]. По аналогии со слабоструктурированными документами в данной работе под слабоструктурированными понимаются таблицы, не имеющие формальной модели данных, но при этом включающие некоторые индикаторы структуры, а также, возможно, некоторые структурные метаданные. Поскольку в таких таблицах отсутствует схема данных, предназначенная для высокоуровневой машинной обработки (например, выполнение запросов к данным по аналогии с SQL), то в определенном ранее смысле они также являются примером неструктурированной текстовой информации.
В литературе преобразование табличной информации от неструктурированной формы представления к структурированной принято называть извлечением информации из таблиц [4]. Сложность
1 Работа выполнена при финансовой поддержке РФФИ грант № 12-07-31051, и Совета по грантам Президента РФ СП-3387.2013.5.
этой исследовательской проблемы обусловлена огромным разнообразием способов и форм представления, изображения таблиц. В зависимости от этого необходимо решать задачи анализа физической компоновки (обнаружения и сегментации) и логической компоновки таблицы (восстановление отношений и типов данных). Современное состояние данной области исследований не позволяет говорить о полном решении проблем извлечения информации из таблиц. Известные методы и системы анализа и обработки табличной информации преимущественно ориентированы на заранее определенные компоновки и особенности таблиц и документов. Эффективность таких методов и систем во многом зависит от вида таблиц, на которые они ориентированы. Являясь эффективными для таблиц определенного вида, они могут оказаться неэффективными для таблиц другого рода. Например, известные программные продукты OmniPage (Nuance Communications), Cuneiform (Cognitive Technologies), FineReader (ABBYY), PDF2XL (Cogniview) и Solid Converter PDF (Solid Documents) выполняют только обнаружение и сегментацию таблиц. Причем класс обрабатываемых ими таблиц ограничен простой «решеточной» компоновкой, когда табличные строки непосредственно соответствуют записям реляционной таблицы, а столбцы — ее полям. В работе [5] показано, что большинство исследований в этой области посвящено решению проблем низкоуровневой обработки табличной информации — обнаружению и сегментации таблиц из растровых изображений документов. При этом проблемы анализа логической компоновки и извлечения информации из слабоструктурированных таблиц остаются малоизученными.
Известные методы и системы основаны на различных подходах, например, на основе динамического программирования [8], машинного обучения [9] или статистических методов [10]. Однако для большинства из них при построении алгоритмов анализа характерно использование предположений (часто достаточно сильных) о компоновках обрабатываемых таблиц. По сути, такие знания (предположения) встроены в эти известные алгоритмы анализа и поэтому ограничивают классы эффективно (точно и полно) обрабатываемых ими таблиц. Использование логического вывода дает возможность разделить алгоритмы анализа слабоструктурированных таблиц и знания об обрабатываемых таблицах. В отличие от известных, такой подход позволяет реализовать различные программы (базы знаний) для различных форм (способов) представления и оформления слабоструктурированных таблиц. Данный подход положен в основу предлагаемой интеллектуальной системы извлечения табличной информации. Это обеспечивает обработку более широкого класса слабоструктурированных таблиц со сложной компоновкой по сравнению с известными исследованиями и программными продуктами.
1. Родственные работы
Наиболее близкими к данному исследованию являются работы S. Douglas и др. [6] и Y. Tijerino и др. [7]. В этих работах рассматривается преобразование (структурирование) табличной информации,
называемое канонизацией таблицы (англ. table canonicalization). В работе S. Douglas и др. приводится
определение канонической формы таблицы, под которой условно понимается отношение в терминах реляционных баз данных, а также предлагается метод интерпретации и канонизации таблиц, которые содержатся в спецификациях, используемых в строительной промышленности. Для этого S. Douglas
S. и др. предлагают использовать обработку естественного языка. В частности, для разделения табличных заголовков и данных, а также для отнесения заголовков к определенным типам данных (доменам) предлагается использовать онтологию предметной области (подъязык спецификаций строительной промышленности). Основным недостатком этой системы является ориентированность на узкий класс таблиц. В работе Y. Tijerino и др. описывается платформа TANGO (Table ANalysis for Generating Ontologies, http://tango.byu.edu), предназначенная для инкрементальной генерации концептуальной онтологии из таблиц, содержащихся в web-страницах. В TANGO приведение таблицы к канонической форме является первым этапом в процессе генерации онтологии. Предлагаемый ими способ канонизации основан на использовании библиотеки фреймов, содержащей знания о лексическом содержании таблиц. Каждый фрейм данных описывает один тип данных и используется для отнесения выражений на естественном языке (табличных заголовков и значений) к этому типу. Для описания типов данных Y. Tijerino и др. предлагают использовать регулярные выражения, словари, лексическую базу данных английского языка WordNet (http://wordnet.princeton.edu) и другие ресурсы. Следует отметить, что приведение к канонической форме используется для слабоструктурированных таблиц со сложной компоновкой. Таким образом, в TANGO канонизация таблицы выполняется на
основе анализа ее естественно-языкового содержания. На практике этого не всегда достаточно. Для более точного и полного извлечения информации из таблицы часто также требуется анализ пространственной и графической информации.
2. Модель таблицы
На основе представлений табличной информации в основных широко распространенных форматах данных документов - табличного процессора Excel, текстового процессора Word, страниц HTML и системы LaTeX - предлагается оригинальная, достаточно общая, модель слабоструктурированной таблицы. В данной модели сделано несколько общих для этих представлений предположений: 1) ячейка может располагаться в одной или нескольких соседних строках и в одном или нескольких соседних столбцах (например, атрибуты “colspan” и “rowspan” в HTML) и имеет прямоугольную форму в пространстве строк и столбцов; 2) внутри ячейки не могут располагаться другие ячейки (это не допускается в Excel); 3) текстовое содержимое ячейки может являться либо меткой (заголовком), либо вхождением (данными); 4) метки могут адресовать вхождения либо в строках - метки строк, либо в столбцах — метки столбцов. Сделанные предположения описывают широкий класс обрабатываемых таблиц. Пример описания слабоструктурированной таблицы в терминах предложенной модели приводится на рис. 1.
Используемые в данной работе термины “метка” и “вхождение” соответствуют смыслу терминов “label” и “entry” из работы X. Wang [11]. Предлагаемая модель слабоструктурированной таблицы включает два уровня, которые в упрощенном виде можно описать следующим образом.
1. Уровень физической компоновки Tp=(Sr, Sc, С) состоит из: пространства строк — Sr и столбцов
— Sc; набора ячеек — С, в котором каждая ячейка — с=(р, c', F, G) включает информацию о своих координатах в пространстве строк Sr и столбцов Sc (cl — левой, rt — верхней, cr — правой и rb — нижней гранях соответственно) — p=(cl, rt, cr, rb), содержании — c'; графическом форматировании (цветовые схемы, шрифтовые метрики, выравнивание и др.) — F, и разграфке (оформлении границ)
— G.
2. Уровень логической компоновки Tl=(D, Lr, Lc, A, E) состоит из: набора измерений — D; дерева меток строк — Lr, дерева меток столбцов — Lc, отражающих связи между метками — l=(l', Di), где l'
— содержание метки, а Di — сопоставленное ей измерение из набора D; набора значений измерений A={Ai}, где Ai — подмножество значений измерения Di, представленных в обрабатываемой таблице; набора вхождений — E, в котором каждое вхождение — e=(e', A', L') включает информацию о своем содержании — e', связанных с ней значениях измерений — A' (A' является подмножеством A) и метках — L' (L' является подмножеством объединения меток из деревьев Lr и Lc).
Рис. 1. Пример описания слабоструктурированной таблицы в терминах предложенной модели
3. Ядро анализа табличной компоновки
Основная идея, лежащая в основе предлагаемого подхода к анализу табличной компоновки, состоит в следующем. Обычно внутри тематической коллекции документов от одного поставщика таблицы компонуются и форматируются однообразно. Для такой коллекции документов можно определить набор формализованных правил анализа табличной компоновки, который удовлетворяет всем или (почти всем) ее таблицам. Эти правила можно представить в виде базы знаний, а процесс анализа табличной компоновки реализовать как логический вывод. При этом база фактов формируется из доступной в неструктурированном текстовом источнике табличной информации и внешней информации (фактах о типах данных и отношениях между понятиями). В результате логического вывода формируются новые факты о табличной компоновке, т.е. выполняется восстановление информации, отсутствующей в исходном представлении. На основе восстановленной информации выполняется структурирование (канонизация) таблицы.
Пример 1
rule "Recovering row labels in the stub"
dialect "mvel"
when
$c : CCell( cl == 1 )
then
modify ( $c ) { setRole( Role.ROWLABEL ) };
end
Пример 2
rule "Binding column labels in the head"
dialect "mvel"
when
$c1 : Ccell( role == Role.COLLABEL )
$c2 : Ccell( role == Role.COLLABEL,
rt == $c1.rb + 1,
( $c1.cl <= cl && cr < $c1.cr ) ||
( $c1.cl < cl && cr <= $c1.cr ) )
then
$c1.addConnectedCell( $c2 );
end
Пример 3
rule "Recovering ignored row labels without nulls"
dialect "mvel"
when
$c : CCell( role == null, cl == 1, cl == cr,
content matches "(?i).*(total)|. *(average)" )
then
modify ( $c ) { setRole( Role.IGNORED ROWLABEL ) }
end
Пример 4
rule "Binding entries and column labels"
dialect "mvel"
when
$l : CCell( role == Role.COLLABEL )
$e : CCell( role == Role.ENTRY, cl == $l.cl, cr == $l.cr)
then
$e.addConnectedCell( $l );
end
5ис. 2. Примеры правил анализа логической компоновки на языке MVEL
Табличная информация, представленная на уровне физической компоновки предлагаемой модели, формируется в результате анализа физической компоновки (обнаружения внутри источника и сегментация таблицы) исходной информации (изображений, ASCII-текста, PDF, Excel и др.). Информация, представленная на уровне логической компоновки предлагаемой модели, формируется в результате анализа логической компоновки информации о физической компоновке. В данной работе обсуждаются именно задачи анализа логической компоновки, которые остаются малоизученными в мире по сравнению с задачами анализа физической компоновки.
Предлагаемый анализ компоновки основан на логическом выводе, который выполняется в свободной системе исполнения правил Drools Expert (JBoss Community, http://www.jboss.org/drools). Продукционные правила анализа табличной компоновки записываются на языке выражений MVEL (http://mvel.codehaus.org) и используют предлагаемые структуры данных. Для анализа логической компоновки такие правила отображают доступную информацию — позиции (координаты) элементов таблицы (ячеек, строк и столбцов), графическое форматирование (цветовые схемы, шрифтовые метрики, выравнивание и др.) и текстовое содержание ячеек, в отсутствующую изначально информацию
— семантические отношения между ячейками, роли (метки или вхождения) и типы данных (домены) содержимого ячеек. С помощью этого решаются следующие задачи: 1) разделение ячеек на метки и вхождения; 2) восстановление связей между вложенными и охватывающими метками, между метками и вхождениями; 3) восстановление типов данных для меток.
На рис. 2 приводится ряд простых примеров возможных правил анализа логической компоновки на языке MVEL. Пример 1: если ячейка “$c” находится в первом столбце “cl==1”, то необходимо пометить, что ее содержание является меткой строки “modify ($c) {setRole(Role.ROWLABEL)}”. Пример 2: если две ячейки “$c1” и “$c2” содержат метки столбцов “role==Role.COLLABEL” и вторая ячейка “$c2” расположена непосредственно под первой “$c1” таким образом, что первая ячейка “$c1” полностью охватывает вторую “$c2” по столбцам, то необходимо задать связь между этими ячейками “$c1.addConnectedCell($c2)”. Пример 3: если ячейка “$c” с неопределенной ролью “role==null” расположена полностью в первом столбце “cl == 1, cl==cr” и содержит текст, удовлетворяющий регулярному выражению вида “(?i).*(total)|.*(average)”, то необходимо ее отметить как игнорируемую в дальнейшем процессе обработки. Пример 4: если ячейка “$e” содержит вхождение
“role==Role.ENTRY” и находится в одном столбце с ячейкой “$l”, содержащей метку столбца “role==Role.COLLABEL”, то необходимо задать связь между этими ячейками “$e.addConnectedCell($l)”.
На практике для одного или нескольких схожих источников, из которых необходимо извлечь табличную информацию, можно разработать набор подобных правил. Например, для обработки таблиц из одного источника (Statistical Handbook of Japan 2007. Statistics Bureau of Japan) потребовалось составить 9 правил, которые занимали 94 строки кода на языке MVEL. По сравнению с известными предлагаемый подход требует развития моделей анализа табличной информации (наборов правил) для различных случаев исходных данных, но при этом он применим для существенно более широкого класса слабоструктурированных таблиц без потери эффективности (точности и полноты) извлечения информации.
Дополнительные алгоритмы обработки табличной информации
Для нормализации и структурирования информации о табличной компоновке, восстановленной в процессе логического вывода, предлагается ряд оригинальных алгоритмов. Далее приводится их краткое описание.
Метки внутри одной или нескольких таблиц могут различаться по написанию, но иметь одно лексическое значение, т.е. могут являться синонимами. Например, следующие метки: “2010”, “FY2010”, “Year 2010” и “Previous Year”, “2010 г.”, “Текущий год” могут быть синонимами, означающими 2010 г. В качестве эталонного значения приведенных выражений может использоваться “2010”. Нормализация меток начинается с замены таких выражений на их эталоны путем сопоставления со словарем эталонов, который содержит набор отношений вида (S, R), где S — естественно-языковое или регулярное выражение, а R — соответствующее ему эталонное выражение. Например, если в словаре задать отношения вида (“FY[2][0][0-1][0-3]”, “[2][0][0-1][0-3]”), то все заголовки, соответствующие регулярному выражению “FY[2][0][0-1][0-3]”, т.е. “FY2000”,..., “FY2013”, будут заменены на соответ-
ствующие эталоны “2000”,..., “2013”. Кроме того, в таблице может содержаться несколько меток с одинаковым значением. Предполагается, что они являются экземплярами одной растиражированной метки. В процессе нормализации все экземпляры такой метки заменяются ею. При этом для каждого вхождения его связь с экземпляром метки заменяется связью с растиражированной меткой.
□энные Qnceatinfl Год Тип отграп пемия Регион Стознз
462.9 Sent 2010 Letters EU Spain
62 9 Sent гою Letters EU Cyprus
352.3 Sent 2010 Letters EU Belgium
21.1 Sent 2010 Letters Middle East Lebanon
зэз.а Sant 2010 belters Middle Easl Israel
102.2 Sent гою Parcels EU Spain
- ' I . iCJ.0. ..Patcris... Mi№. insL- .L-дЬйпел ..
460.4 Sent 2011 Letters EU Spain
69.7 Sent 2011 Letters EU Cyprus
cgTD |enj) (g^M) <£etters)(EU) <|elSS>
21.5 Sent 2011 Letters Middle East Lebanon
4ВД.0 Sent 2011 Letters Middle East Israel
Ю9.3 Sent 2011 Parcels EU Spain
Jil . SfMi Ж ..Paccela... Middle £aaL_ .Lebanon..
556Э Received 2010 Letters EU Spajn
97 f Received 2010 Letters EU Cyprus
■367.2 Received 2010 Letters EU Belgium
19. В Received 2010 Letters Middle East Lebanon
3550 Received 2010 Letters Mfddle East Israel
134 2 Received 2010 Parcels EU Spain
ALL .mo. __PMwJs___WridJiLEi£l_ ..Labanan..
57Б.4 Heoeived 201 \ Letters EU Spain
101*7 Received 2011 Letters EU Cyprus
366 1 Received 2011 Letters EU Belgium
19.5 Received 2011 Letters Middle East Lebanon
3760 Received 2011 Letters Middle East Israel
145.4 Received 2011 Parcels EU Spain
11.Э Received 2011 Parcels Middle East Lebanon
Рис. 3. Пример канонической формы для слабо структурированной таблицы из рис. 1
Структурирование информации о логической компоновке таблицы включает дополнительную разметку, которая состоит в сопоставлении метки с измерением. Этот процесс основан на использовании словаря измерений, в котором естественно-языковые и регулярные выражения сопоставляются с заранее заданными измерениями. Словарь измерений содержит набор отношений вида ^, Di), где S
— выражение, а Di — соответствующее измерение. Дополнительно в процессе разметки могут определяться метки, указывающие на вычислимость данных (“проценты”, “итоги” и др.). Такие данные часто целесообразно исключать из дальнейшего преобразования табличной информации к целевой форме. Описанная разметка также доступна и в процессе логического вывода, а соответствующие словарям и измерениям структуры данных могут использоваться в определениях правил при разработке баз знаний.
По разметке выполняется восстановление используемых в таблице значений измерений. Из деревьев меток Lr и Lc исключаются метки, которые являются значениями измерений из D. Каждая исключаемая метка добавляется в список значений соответствующего измерения — Аь В случае, когда каждая метка соотнесена с некоторым измерением, деревья меток вырождаются. Из невырожденных деревьев строятся пути меток от листьев до корней. По вхождениям (данным), построенным путям меток, и восстановленным значениям измерений формируется таблица в канонической форме, соответствующая по смыслу отношению в терминах реляционной модели данных. Предлагаемая канони-
ческая таблица включает следующие атрибуты (поля): DATA — поле вхождений (данных); ROW_LABEL — поле путей из невырожденного дерева меток строк, COL_LABEL — поле путей из невырожденного дерева меток столбцов; D1, D2,... , Dn — поля значений соответствующих измерений. Пример канонической формы обработанной таблицы приводится на рис. 3. Сформированная каноническая таблица может экспортироваться в формат реляционной базы данных с помощью стандартных средств управления данными.
Реализация и практическое использование
На основе предложенных в данной работе подходах, модели и алгоритмов разработан прототип интеллектуальной системы извлечения информации из слабоструктурированных таблиц со сложной компоновкой, который был успешно применен в практической задаче.
В прототипе предлагаемой системы реализованы алгоритмы: 1) загрузки исходной табличной информации, представленной в формате табличного процессора Excel (тестовых данных со специализированной разметкой); 2) нормализации и структурирования табличной информации, восстановленной в процессе логического вывода; 3) экспорта результатов в формате Excel. Предлагаемая в работе модель таблицы реализована в виде ряда структур данных, основные из которых: CELL, ENTRY, LABEL, LABELNODE. Структура CELL предназначена для представления ячейки и прежде всего информации о ее физической компоновке, однако она также включает уровень логической компоновки ячейки (т.е. она позволяет накапливать информацию о ее связях с другими ячейками, ее роли и типе данных). На практике это позволяет разрабатывать правила анализа логической компоновки в более лаконичной манере по сравнению со случаем, при котором используются дополнительные структуры данных для представления информации уровня логической компоновки. Структуры ENTRY, LABEL, LABELNODE используются исключительно на уровне логической компоновки. ENTRY служит для представления вхождения, а LABEL — метки. Структура LABELNODE является оболочкой для структуры LABEL и обеспечивает представление деревьев меток. Все предложенные структуры данных и алгоритмы реализованы на платформе Java.
В рамках совместного российско-монгольского проекта РФФИ № 11-07-92204 с помощью данного прототипа наполнено хранилище данных по социально-экономическому положению территорий Монголии из неструктурированных текстовых источников, предоставленных Институтом национального развития Монголии (http://mdi.gov.mn). Информация извлекалась из более чем 40 слабоструктурированных таблиц в формате табличного процессора Excel. Примеры таких таблиц представлены на рис. 4. Для анализа этой информации потребовалось описать следующие измерения: “время” — (D1={"19\d\d.0", "200\d.0", "201[0-2].0"}), “пространство” — (D2={"Bayan-Olgii", "Govi-Altai",..., "Ulaanbaatar"}), соответствующее административному делению Монголии, и “отрасли” — (D3={"Agriculture", "Industry",., "Services"}). Еще два дополнительных измерения “показатели” и “меры” были сформированы из названий таблиц в процессе обработки их контекста. Также потребовалось составить 9 правил, занимающих 81 строку кода на языке MVEL. В условиях (левых частях) данных правил используется информация о расположении ячеек и их текстовом содержимом. При этом некоторые правила определяли игнорируемые метки и вхождения. Например, в процессе логического вывода для меток, удовлетворяющих регулярному следующему выражению: "(?i).*(total)|.*(region)|.*(average)|(Y\s*)", задавалась роль игнорируемых меток —
"IGNORED_ROWLABEL" (пример 3 на рис. 2). Кроме того, в правой части некоторых правил использовались дополнительные вычисления по преобразованию текстовых выражений (строковых представлений чисел) к числам с помощью регулярных выражений и методов класса Math из состава платформы исполнения Java.
2003 ... 2011
Total, bln.tog Share to total, % Total, bln.tog
Agriculture ... Services .. ... Services
TOTAL 1479,70 20,60 54,00 10829689,60 52,00
Western region 118,50 63,50 32,20 455942,30 41,40
Bayan-Olgii 27,30 59,30 36,70 91968,90 51,90
Govi-Altai 14,60 62,00 39,10 60036,60 49,40
Khentii 25,90 74,80 20,30 99575,30 29,10
Ulaanbaatar 861,50 0,80 • •• 73,00 •• 6991314,80 • 68,80
Aimags and the Capital 1992 1993 .. 2011
TOTAL 806,00 765,40 1037,70
Total 160,10 152,00 167,80
Bayan-Olgii 26,70 22,00 42,01
Govi-Altai 26,90 25,30 24,44
Total 78,20 70,20 76,70
Dornod 30,80 27,60 25,77
Khentii 29,00 25,50 26,20
Ulaanbaatar 206,30 195,80 .. . 361,40
Рис. 4. Примеры обрабатываемых таблиц
В разработанном прототипе системы извлечения табличной информации не реализованы механизмы анализа физической компоновки таблиц, и, в частности, средства обнаружения таблиц внутри текста. Чтобы избежать сложности, связанной с анализом физической компоновки таблиц, использовалась дополнительная разметка внутри листов табличного процессора Excel. Как показано на рис. 5, используются теги, указывающие позиции начала — SSTART и конца — $END таблицы, а также элементы ее контекста: название — SNAME и единицу измерения — SMEASURE. На данном этапе исследования использование формата Excel с дополнительной разметкой в качестве исходного представления позволяет свести анализ физической компоновки таблицы к ряду достаточно тривиальных процедур загрузки и предобработки данных. Всего в процессе обработки этих таблиц извлечено более 15 000 неагрегированных значений данных (вхождений). Время обработки этих данных составляет менее 40 с на компьютере со следующими параметрами: Intel Core 2 Quad 2,66ГГц, 4Гб.
$NAME Table 1. ...
$MEASURE bln.tog
$START
$END
Рис. 5. Дополнительная р азметка таблицы внутри листа Excel
Заключение
В работе изложен оригинальный подход к анализу компоновки слабоструктурированных таблиц на основе логического вывода. Использование этого подхода позволяет разрабатывать различные программы (базы знаний) для различных форм (способов) представления и оформления таблиц. Данный подход положен в основу разрабатываемой интеллектуальной системы извлечения табличной информации из неструктурированных текстов. Реализованный прототип этой системы успешно применен для автоматизации ввода в хранилище данных информации из таблиц по социальноэкономическому положению Монголии, которые представлены изначально в неструктурированных текстах.
Литература
1. Inmon B. Matching unstructured data and structured data // The data administration newsletter. 2006. URL: http://www.tdan.com/view-articles/5009
2. Blumberg R., Atre S. The problem with unstructured data // DM Review, 2003. URL: http: //soquelgroup.com/Articles/dmreview_0203_problem.pdf
3. Feldman R., Sanger J. The Text Mining Handbook: Advanced Approaches in Analyzing Unstructured Data // Cambridge University Press. 2006. 422 p.
4. Embley D.W., Hurst M., Lopresti D., Nagy G. Table-processing paradigms: a research survey // Int. J. on Document Analysis and Recognition. Springer-Verlag. 2006. Vol. 8, No. 2. P. 66-86.
5. e Silva A.C., Jorge A.M., Torgo L. Design of an end-to-end method to extract information from tables // Int. J. on Document Analysis and Recognition. Springer-Verlag. 2006. Vol. 8, No. 2. P. 144-171.
6. Douglas S., Hurst M., Quinn D. Using Natural Language Processing for Identifying and Interpreting Tables in Plain Text // In Proc. of the 4th Annual Symposium on Document Analysis and Information Retrieval. Las Vegas. 1995. P. 535-546.
7. Tijerino Y., Embley D., Lonsdale D., Nagy G.: Towards ontology generation from tables // World Wide Web: Internet and Web Information Systems. 2005. Vol. 8, No 3. P. 261-285.
8. Hu J., Kashi R., Lopresti D., Wilfong G. Medium-independent table detection // In Proc. of the Document Recognition and Retrieval VII. 2000. P. 291-302.
9. Tengli A., Yang Y., Ma N. L. Learning table extraction from examples // In Proc. of the 20-th Int. Conf. on Computational Linguistics. Stroudsburg, USA. 2004. Article 987.
10. Pinto D., McCallum A., Wei X., Croft B. Table extraction using conditional random fields // In Proc. of the 26-th Int. ACM SIGIR Conf. on Research and Development in Informaion Retrieval. New York, USA. 2003. P. 235-242.
11. Wang X. Tabular Abstraction, Editing, and Formatting. PhD Thesis. Waterloo, Ontario, Canada. 1996.
Шигаров Алексей Олегович, кандидат технических наук, старший научный сотрудник ИДСТУ СО РАН, тел. (3952) 453102, e-mail: [email protected]
Shigarov Alexey Olegovich, candidate of technical sciences, senior researcher, Institute for System Dynamics and Control Theory SB RAS. Ph.: (3952) 453102, e-mail: [email protected]
