Репрезентативно-ролевая модель содержимого веб-страницы

Автор: Головко А.П., Лапин В.Н.

Журнал: Вестник Нижневартовского государственного университета @vestnik-nvsu

Рубрика: Математическое моделирование и программирование

Статья в выпуске: 3, 2015 года.

Бесплатный доступ

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

Еще

Веб, моделирование, искусственный интеллект

Короткий адрес: https://sciup.org/14116887

IDR: 14116887

Текст научной статьи Репрезентативно-ролевая модель содержимого веб-страницы

1. Постановка задачи

Проблема. Автоматический анализ содержимого (контента) веб-страниц является актуальной задачей, при этом анализ может служить самым разнообразным целям.

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

Одна из практически востребованных задач состоит в автоматическом выделении основной статьи (включая текст и другие компоненты). Далее, например, все остальное удаляется и резко «облегченная» страница хранится в облаке или ином хранилище. Такую услугу предлагают многие сервисы, например, [1]. Весьма перспективной представляется задача автоматического семантического анализа (в первую очередь) основного содержания страницы на предмет «о чем она на самом деле» и т.п. Существующие методы служат, в основном, целям оптимизации сайтов на предмет их продвижения.

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

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

служат для обозначения заголовков этих разделов, причем с явным указанием иерархии: Для заголовка основной статьи естественно использовать и далее вниз по убывающей. Более того, стандарт HTML-5 позволяет и фактически рекомендует проводить и семантическую разметку, вводятся теги, основное предназначение которых именно в этом, такие как
и др. [4]. Некоторые сайты используют внутренний стандарт, согласно которому такая семантическая разметка является обязательной; это выяснено при проведении работы, о которой говорится в данной статье.

Однако, как правило, на практике дело обстоит иначе. Как показал проведенный анализ примерно 20 сайтов, в большинстве случаев HTML-текст структурирован плохо. Используемые генераторы HTML-кода пишутся так, чтобы удовлетворять сиюминутные утилитарные потребности разработчика. О какой семантической разметке может идти речь, если даже синтаксис HTML регулярно нарушается: комментарии внутри дескрипторов, отсутствие обязательных закрывающих дескрипторов или, наоборот, больше, чем открывающих, по несколько дескрипторов

, и т.д. Веб-браузеры «прощают» это, автоматически исправляя, видимо, из соображений конкурентоспособности друг с другом.

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

Каким образом подойти к решению задачи?

Как уже упоминалось, имеется ряд программ, выполняющих очистку страницы от всего, кроме основной статьи. Прямое тестирование этих программ показало, что они действуют безукоризненно примерно в 85% случаев (тестовые примеры подбирались не тривиальные), при этом наблюдается определенная тенденция: одни программы чаще ошибаются, имея дело с таблицами, другие - с фото и видео, и т.д. Можно предположить, что в основе этих программ - движки с «навороченной» логикой, написанные в некоторой традиционной парадигме. Возможности такого подхода представляются ограниченными, особенно если говорить о более глубоком анализе семантики в дальнейшем.

Перспективным представляется другой подход. Человек - посетитель сайта визуально воспринимает интерпретированный браузером текст страницы и, обычно, легко определяет, где главное. Дизайнер проектирует страницу так, чтобы именно человеку было просто сориентироваться. Следовательно, программа-распознаватель ролей должна подражать человеку, т.е. по существу быть системой искусственного интеллекта. Такой подход одновременно готовит почву для более глубокого анализа семантики в перспективе.

Поскольку человек находит главное на странице, не перечитав все тексты и сравнив их, а по тому, как соответствующий фрагмент визуально представлен (ре-презентован), соответствующую модель естественно назвать репрезентативно-ролевой.

Какую парадигму искусственного интеллекта выбрать? Наиболее естественными представляются экспертная система и 1_ГОТЛ1ЛГ~\1_Г1_ГО СГ Г*А^ГТ'Т~ I |/~\Г* ТТАТТиСГСГ ТЭГЛ^А/ТГЛ*'Х'*1-Г/'Л ГТАТЛ— tlCMUUtlrlclX UClb. 1 ТииЛСДМИХ^ DUolVlUTKrIU, 11CU^-спективнее. Однако на первых порах, когда не очень ясно, какие признаки учитывать, при том, что сам объект (текст длиной минимум в несколько килобайт) чрезвычайно многообразен, такое решение представляется трудно реализуемым. Поэтому выбирается экспертная система. Возможно, при накоплении материала станет реальным использование нейронной сети, в частности, комбинируя с экспертной системой. Модель, рассмотренная в данной работе, ориентирована на поиск исполнителей двух ролей: главного заголовка и основной статьи веб-страницы.

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

2. Содержательное описание задачи

Нас будут интересовать две роли: Главный заголовок и Основной текст. Причем Основной текст может содержать разнородные элементы: собственно текст (в том числе - разбитый на части каким-то образом), таблицы, рисунки. Наша задача -действовать, подражая человеку.

Как человек на взгляд определяет, где главное?

Главный заголовок - самый крупный или, по крайней мере, не мельче прочих. Он, скорее всего, имеет много общего с заголовком страницы (тэг

), часто просто совпадает. Наконец, он стоит выше в представлении страницы на экране, чем другие заголовки, имеющие аналогичные характеристики. Он не мерцает, не движется по экрану и т.д.Основной текст, скорее всего, наиболее крупный фрагмент. Он занимает приблизительно центральное положение на экране. Он тесно связан с Главным заголовком. При этом «на его территории» могут находиться и фрагменты, не входящие в его состав, или даже не имеющие к нему отношения (реклама).Здесь приходится обратить внимание на роль Комментарий. По объему текста комментарии пользователей могут значительно превосходить Основную статью. Заголовок комментария может быть не меньше главного, может почти совпадать с заголовком страницы. Текст комментариев верстальщик может поместить в один HTML-контейнер с Основной статьей. Следует отметить, что Главный заголовок не содержит слово «комментарии» в любой форме, если только этого слова нет в <title>.Также остается проблема ошибок и нарушений синтаксиса HTML, допущенных при верстке. 3. Архитектура модели как экспертной системыУчитывая характер задачи, была принята стратегия, аналогичная стратегии «наименьшего риска» [5. С. 153] в его регулярном варианте (без случайных откатов). Стратегия предполагает, что если некоторая подзадача в составе задачи не может быть решена полностью, ее решение пре- рывается, мы переходим к другой подзадаче, а к этой возвращаемся, когда появится нужная информация. При этом однажды принятые решения уже не нуждаются в пересмотре.Согласно выбранной стратегии в ходе вывода сначала отбираются все кандидаты на определенную роль, т.е. фрагменты, которые в принципе могут оказаться в этой роли. Затем последовательно число кандидатов сокращается до одного. Напомним, что в нашем случае (поиск главного заголовка и основного текста) на каждую роль может приходиться ровно один исполнитель.Важным требованием здесь является отсутствие откатов на уровне стратегии и итерационных циклов на тактическом уровне. Все блоки алгоритма верхнего уровня работают последовательно ровно 1 раз.На нижнем уровне обработки информации, где как раз отрабатывается много мелких деталей и где возможны частые модификации подробностей алгоритма, используются небольшие продукционные системы: по 5-10 правил. Здесь есть опасность зацикливания, так как они имеют управляющую структуру по принципу «выполнять, пока есть хотя бы одно релевантное правило». Однако при столь небольшом объеме этим моментом достаточно легко управлять, а при возникновении проблем - исправлять. Каждая такая система имеет свою локальную базу для промежуточных данных, поэтому побочные эффекты не угрожают. Наконец, в перспективе это может пригодиться для распараллеливания процесса, так как продукционная система обладает естественным параллелизмом [2. С. 53].Практически все блоки промежуточной информации имеют структуру списков. Для их обработки используются программные средства обработки именно списков, а не массивов, что исключает зацикливание.Таким образом, работа системы последовательно декомпонирована на мелкие, достаточно независимые фрагменты. Платой за это являются многочисленные и большие по объему массивы промежуточной информации. Они, однако, имеют несложную структуру и четко различаются по назначению, что облегчает задачу управления. 4. Информационный компонент моделиНа уровне модели ее информационная составляющая представлена семантической сетью, которая включает 2 компонента: статический и динамический. Статический содержит понятия, которые используются в процессе вывода и не зависят от конкретной решаемой в данный момент задачи. Динамический отражает именно каждую конкретную задачу (веб-страницу). В целях удобочитаемости эта часть системы представлена в несколько другом виде. Понятия и связи из статической части даны в виде определений, причем опущены те, смысл которых итак понятен; из динамической части - в основном, в виде списков, идентификаторы которых соответствуют коду программы. Например, список TxtListldsPre _ //( 'ТТХЛГ'ГХЦ* D/"W\r>TTTA DPPV РТ ТЛАП/-\Г*1ЛАТТГ*'ТВPTJ-— xW/IIHUUK DUUUJ-ЦС nUCA TL 1 пСААОСиСДСАЪСг!" но содержащих текст», на языке семантической сети означает набор экземпляров r^DCJQTT // Md ТТСГА'ТГ*СГ\\ ПГХАТТТуПЛСПГХТТТТуГУ' ТЛАТЛЛЛ'Т'ЛЛТЛЛЛА LdtijII \\ZLdJAzACA Сл//3 СиСДАПтАлААхэ АДАТА rlCKU 1UUUC множество элементов текста страницы с понятием «Блок, содержащий текст» и т.д. 4.1. Статическая информация (понятия)<ul><li>1. Сам текст кода представлен обычной строкой символов SourHtml. Его элементы (обычные Юникод-символы) будем нумеровать, начиная с нуля.</li><li>2. Элемент текста ЕТ - фрагмент html-кода веб-страницы, который</li></ul><ul><li>1) включает в себя некоторый открывающий дескриптор, соответствующий ему закрывающий дескриптор и текст между ними. Если практически закрывающий дескриптор опущен, но ясно, где он подразумевается (например, <р>), то ЕТ включает фрагмент от начала открывающего де-</li><li>скриптора до точки, где подразумевается закрывающий;</li></ul><ul><li>2) если закрывающий дескриптор не положен по синтаксису языка (например, ), то включает только текст открывающего дескриптора.</li><li>3. АНЕТ - множество всех ЕТ блокового уровня [4], которые могут быть построены для данной SourHtml. Теги , , относим сюда же.</li><li>4. Основной граф TreeOfElems - граф (дерево), представляющий структуру множества АНЕТ. Он является базовым информационным объектом в алгоритме (не считая самой SourHtml). Имеет следующую характеристику</li></ul>Если X - некоторый ЕТ, то beg(X) и end(X) - это, соответственно, номера позиций в SourHtml, соответствующих первому (’<’) и последнему (‘>’) символам, принадлежащих X, a type(X) - тип открывающего дескриптора, с которого начинается этот фрагмент кода, например, <div>.Два ЕТ могут либо не пересекаться, либо один может быть вложен в другой.<ul><li>1) В корне дерева — фиктивный элемент «Все дерево». Дальше — по вложенности.</li><li>2) Дерево TreeOfElems представлено вектором (массивом). При этом</li></ul><ul><li>- каждый элемент представляет один ЕТ (не дескриптор);</li><li>- расположение элементов TreeOfElems всегда соответствует расположению ЕТ в тексте. То есть, если открывающий дескриптор ЕТ А расположен в SourHtml раньше, чем такой дескриптор ЕТ В, то индекс ЕТ А в TreeOfElems будет меньше, чем индекс ЕТ В;</li><li>- любое поддерево всегда представляет собой сплошной фрагмент TreeOfElems, первый элемент фрагмента — корень поддерева.</li></ul><ul><li>3) Каждый элемент имеет уникальный идентификатор - целое число, начиная с нуля. Первоначально (при построении дерева) идентификатор равен индексу в TreeOfElems. Затем, при преобразованиях</li></ul>дерева, индекс может изменяться, идентификатор сохраняется. Все требования предыдущего пункта также сохраняют силу при преобразованиях дерева.<ul><li>4) Каждый элемент TreeOfElems представлен кортежем, включающим информацию, позволяющую определить как положение в дереве, так и по отношению к SourHtml.</li><li>5. Текстовая таблица TblTxt - таблица (ЕТ <table>), служащая для представления данных: текста, рисунков и т.д. Может содержать вложенные текстовые таблицы.<li>б. Организующая таблица TblOrg -таблица (ЕТ <table>), служащая для организации нужного расположения фрагментов страницы на экране. Используется при табличной верстке. Может содержать вложенные организующие и текстовые таблицы.<li>7. Элемент, содержащий текст, -ТхЕТ - это ЕТ, включающий</li><ul><li>- хотя бы один ЕТ типов <р>, <рге>, <blockquote> - непосредственно</blockquote></li></ul>и / или<ul><li>- хотя бы один ЕТ типа <img> и/или текстовую таблицу — непосредственно или не непосредственно.</li><li>8. Путь к элементу РЬЕТ - путь от корня TreeOfElems к какому-то фрагменту.</li><li>9. Марк-лист MrkLst. Подобен РЬЕТ, однако последний элемент этого списка — список Sp: не пустой, но возможно, состоящий из одного элемента. Каждый элемент Sp задает один элемент TreeOfElems тем же способом, что и в РЬЕТ. Все элементы Sp</li><li>10. Корневой предок RootPar (для ЕТ типов <hl>,...,<h6>) - ЕТ, являющийся самым близким предком данного ЕТ и являющийся ТхЕТ.</h6></hl></li><li>11. Гроздь заголовков BrHead (здесь «заголовок» - ЕТ любого из типов <hl>, ...,<h6>). Гроздь - это минимальное подде</h6></hl></li> 12. Используются предикаты: Апс(Х, Y) - X является предком для Y в TreeOfElems, Par(X, Y) - X является родителем для Y в TreeOfElems, DescrBody(X) -X является телом некоторого дескриптора. 4.2 . Динамическая информация (объекты)</ul>РЬЕТ строятся для ЕТ либо отдельных подстрок текста, полностью входящих в состав одного ЕТ — листа дерева, в частности — для отдельных символов.РЬЕТ представляет собой список, в начале которого стоит корень всего TreeOfElems, а в конце — ЕТ, для которого этот РЬЕТ построен, или тот ЕТ, в состав которого входит подстрока, для которой строится матрешка. Каждый элемент РЬЕТ представлен парой (идентификатор элемента дерева, его индекс в дереве).должны являться непосредственными потомками одного и того же элемента TreeOfElems. Список Sp будем называть хвостом марк-листа, а остальную часть — головой. Практическое назначение марк-листов - пометка фрагментов, детектированных на определенную роль.рево в дереве TreeOfElems, в которое входят все эти заголовки. Гроздь содержит не менее двух заголовков.В таблице 1 представлены основные информационные объекты, порождаемые при моделировании одной веб-страницы.Таблица 1<table border="1"><tr><td>№</td><td>Идентификатор</td><td>Семантика</td></tr><tr><td>1</td><td>SourHtml</td><td>Исходный html-код</td></tr><tr><td>2</td><td>TreeOfElems</td><td>Дерево элементов текста (ЕТ)</td></tr><tr><td>3</td><td>TableRgstr</td><td>Реестр таблиц</td></tr><tr><td>4</td><td>Hdrs</td><td>Найденные заголовки, подходящие по совпадению с <title>

HdrsMatr

Информация о взаимном расположении кандидатов в Главный заголовок

BestHeaderld

Идентификатор лучшего кандидата в Главный заголовок

L AIL/loLILlol 1U

Список вообще всех ЕТ, непосредственно содержащих текст

TxtListldlnds

Найденные ЕТ с текстом - первичные

CandCommentWordsPos

Список слов в SourHtml, похожих на «Comment» на разных языках

PrepairedCandCommentWord

CandCommentWordsPosr, подготовленные к рейтингу

BestCandCommentHeader Id

Из кандидатов в заголовки Комментария - самый вероятный

CandMainTxt_Ids

Список кандидатов в Основную статью, учитывая заголовок Комментария

TblForCandMainTxt_Ids

Для каждого кандидата в Основную статью - список текста-

T21.TV 'ТЯгХТТТЛТТ TV’fYTWIXT-T А ЦРГГ) ТЗХ'АТТСГТ МАТТААТЛА ТТАТТ2РЫПГ1 Я А А ТТТЛ вЫХ IdUJJLFlLJ,. KUlUUblC в U вХиДЯ.! rlCllUUUCdvlBCrlrlU- d CvJLH не непосредственно, то не через другую текстовую таблицу

MatrBlkWithLongText

PhET блока с самым длинным текстом. Ищется в пределах, ограниченных HdrsMatr

NessTextlds. Список ЕТ в составе блока с самым длинным текстом, которые следует включить в марк- лист

QuUnusTextlds

ЕТ в составе блока с самым длинным текстом, которые, возможно, не следует включить в марк-лист

MarkList 1 BestHdr

Марк-лист главного заголовка

MarkList 1 MaxText

Марк-лист самого длинного текста

MarkList IHead

Марк-лист для страницы

IvldTKLlSLS 1 XI1 dDICS

Список марк-листов текстовых таблиц

MarkListsImgs

Список марк-листов рисунков

CommParentHeadTxtld

Ближайший общий предок Главного заголовка и Основной стэтьи

5. Процедурный компонент модели Остальные используют (почти) всю имею-Основные этапы/блоки алгоритма щуюся на момент их запуска информацию, приведены в таблице 2. В каждом случае После таблицы содержится очень краткое указаны только выходные данные. Для BlkO описание работы основных блоков алго-входными данными является SourHtml. ритма. Таблица 2 Основные блоки алгоритма
№	Идентификатор блока	Назначение	Что вычисляет/ модифицирует
1	BlkO	Предварительная обработкам Простейшая обработка Реестра таблиц	TreeOfElems, TableRgstr
2	FindHeaders	Определение множества заголовков -кандидатов в Главный заголовок статьи	Hdrs, HdrsMatr
3	FindBestHdr	Определение Главного заголовка	BestHeaderld
4	FindAllTexts	Находит вообще все текстовые блоки	I vt iqtIhqmkp
5	TxtLstCorr	Корректирует списки текстовых фрагментов (TxtListldsPre) в связи с тем, что некоторые из них являются элементами текстовых таблиц	TxtListldlnds
6	FindCommentWords	Находит вхождения всех слов типа «Comment» в текст	CandCommentWordsPos
7	PrepairForRating-CandCommHdrs	Для каждой позиции CandComment-WordsPos находит очищенную строку. Определяет, не включена ли она в { или	PrepairedCandCommentWord
8	RatingCandCommHdrs	Устанавливает, кто из кандидатов в заголовки Комментария - самый вероятный	BestCandCommentHdr_Id
9	MakeCandMainTxtList	Формирует список кандидатов в Основную статью (идентификаторы), учитывая заголовок Комментария	CandMainTxt_Ids
10	OpredTablesForCand	/ 1 ТТСГ IZQ'X* -ГГХГГХ Т/*ОиТТТХТТОТО Т2 ( lr'WP»T2UX Х/Х ^ДЛЯ. КЛ/КДО! U KdHdrlddld ti \_/Ct1Udi1\ i\J статью определяет список текстовых таблиц, входящих в него	TblForCandMainTxt_Ids
11	FindMaxText	Определяет блок с самым длинным текстом и возвращает его PhET	MatrBlkWithLongText
12	PrepairToMarkingHeader AndText	По уже имеющимся и BestHeaderld MatrBlkWithLongText готовит марк-листы для заголовка и текста	MarkList 1 MaxText
13	PrepToMarkingHtmlHead	Готовит HEAD страницы к удалению «лишнего»	MrkLstlHead
14	PrepairToMarkingTxtTbl	По уже имеющимся QuUnusTextlds готовит марк-листы для текстовых таблиц	А /То rVT i etc 1 ’vt 1 ’olxl^c ividiKbists i xi i aoies
15	PrepairToMarkinglmgs	По уже имеющимся QuUnusTextlds готовит марк-листы для	MarkListsImg
16	DeleteByDictLst	Объединяет все марк-листы в один. Удаляет все ЕТ, не включенные в марк-листы	TreeOfElems¹, SourHtml¹

Таблица 2. Продолжение

№	Идентификатор блока	Назначение	Что вычисляет/ модифицирует
17	CommParentHeadText	Находит ближайшего общего предка заголовка и текста	CommParentHeadTxtld
18	Пр1 pfp A ttrR vT 1 sit LVClCLCAxLLl U у L/lol	Из всех потомков CommParentHeadTxtld удаляет атрибут href вместе со значением	SourHtml²

'TreeOfElems. из которого удалены ЕТ, не включенные в марк-листы.

SourHtml, в которой произведены удаления в соответствии с изменениями в TreeOfElems 2SourHtml, измененная в соответствии с выполненным действием.

Основные динамические информационные объекты модели

Предварительная обработка BlkO. Из SourHtml удаляются все скрипты и комментарии. Строится TreeOfElems. Формально операция чисто техническая. Сканируется текст, выделяются дескрипторы, в TreeOfElems добавляются элементы, в них записывается нужная информация. Практически именно здесь выполняется работа по исправлению синтаксических ошибок в тексте и нередко - разгадывание загадок: что имел в виду автор. Кроме того, текст приводится к виду, требуемому для TreeOfElems. Например, если встречается «бесхозный» текст, для него создается тег <р>, и т.д. Так же строится реестр таблиц.

I 1П1ЮП О ПИТИЮ чиП^РДЛтп О I^HII ГТ11ГТЛ _ куИрсДСЛсНИС МНОЖсСМоД кдндидд-тов в Главный заголовок статьи FindHeaders.

1. На первом шаге алгоритма формируется TitleLower: символьная строка, получаемая следующим образом. Получается строка sTitle — тело ЕТ . К sTitle применяется процедура Preaire String, которая «чистит» строку: убирает теги строкового уровня, лишние пробелы, каждый спецсимвол заменяется обычным Юникод-символом и т.д.
2. Формируется список Hdrsl, состоящий из идентификаторов всех элементов текста X, для которых type(X) £ {, ...,
}.
3. Для каждого элемента Hdrsl опре-ТТ А ПСТАТОР CI ОТРПРЫК РГГУ C*VCX ТТРП^ТД Q Г* IiTIaI ATX7Af ДСЛЯС1СЯ ClCHCHb Cl U СХС)ДС1ва С 1 ILICLUWCI^ т.е. по смыслу, степень сходства данного ЕТ с заголовком страницы. Практически ищется самая длинная совпадающая под
4. Для всей совокупности элементов Hdrsl строится гроздь HdrsMatr - структура типа BrHead. С ее помощью можно отследить взаимное расположение кандидатов в тексте.

строка. В дальнейшем может использоваться более интеллектуальная процедура.

Определение Главного заголовка FindBestHdr. Если Hdrs содержит только один элемент, то этот кандидат (единственный) и есть Главный заголовок. Если кандидатов несколько, то они рейтингуются определенным образом. Мы считаем, что самый важный признак — тип ЭТ, содержащий текст заголовка. Реально у настоящего Главного заголовка это практически всегда . Далее, конечно, важна длина подстроки, по которой совпадает текст кандидата с текстом, содержащимся в . А при совпадении (у двух и более конкурентов) обоих признаков лучше считается тот, что встречается раньше по тексту. Эту операцию производит специальная функция.

Нахождение всех текстовых ЕТ. Просматривается весь ЕТ

. Отбираются все ЕТ, отвечающие условию: ЕТ(Х) & (3¥)( ET(Y) & Par(X, У) & ((type(Y) £ {<р>,

} V(TblTxt(Y) & Дзгх TblTxt(Z) & (Y с Z)))), другими словами, отбираются элементы, про каждый из которых можно сказать, что он является родителем (только непосредственным, а не вообще предком) хотя бы одного ЕТ, который отвечает одному из следующих условий: 1) это ЕТ <р> или <рге> или ; 2) это тексто- вая таблица, не вложенная в другую текстовую. В дальнейшем мы будем чаще использовать содержательные, а не формальные описания.Формируем список кандидатов в заголовок комментариев:
FindCommentWords. Принцип состоит в следующем. Заголовок комментариев может состоять из одного слова «Комментарии» или то же на других языках. Заголовок может являться предложением типа «Комментарии по теме», при этом дальше может следовать и название темы, тогда заголовок комментариев будет содержать и заголовок статьи. С другой стороны, о каких-то комментариях может говориться в тексте основной статьи и еще где угодно. Необходимо найти фрагмент - самый вероятный кандидат на роль заголовка комментариев.
Дополнительно обрабатывается список кандидатов в заголовки комментариев: PrepairForRatingCandCommHdrs. Для каждого кандидата определяется его ближайший предок - ЕТ блокового уровня. Его содержимое обрабатывается процедурой PreaireString.
Определение, кто из кандидатов в заголовки Комментария - самый вероятный: RatingCandCommHdrs. Считается, что если текст состоит из одного слова «Комментарии», «Comments» и т.п. на других языках, то это и есть самый важный признак того, что мы имеем заголовок комментариев. Эти слова составляют список CommentWholeHeaderl. Следующим по важности считается «ранг» ЕТ, в котором данный заголовок расположен. Самый при-оритетный<Н1>, далее
,...
,
, любой другой. И далее, при прочих равных условиях, более вероятным считается тот, кто расположен выше по тексту.
Формируется список кандидатов в основной текст: MakeCandMainTxtList. Формируется CandMainTxt_Ids - список кандидатов на роль основного текста, учитывая заголовок Комментария. Сейчас мы просто не включаем в список кандидатов тех, кто стоит в дереве после BestCandCommentHeader_Id. (Иногда заголовок Комментария оказывается выше Главного заголовка, хотя сами комментарии - всегда ниже. Этот случай обрабатывается отдельно, здесь его не рассматриваем). Практически если идентификатор элемента этого списка меньше BestCandCommentHeader_Id (или заголовка Комментария вообще нет), то элемент включается в число кандидатов.
I ПО Ь’О^гЛ?ПЛГЛ ж/*О ПЫППТН П ЛРИЛГ111Л11 U КДНДИДД1Д о ULHUt>HUrl текст составляется список текстовых таблиц, входящих в него: OpredTablesForCand. Говоря просто, если IZQIZQ ТТЛ ТЛА R ПА'ЛААТЛГЛТЛ СТ 'TAIZA'TYAR Q СТ Т^О ГЛ ТТТЛТ ТО KclKCLzi^-1U ИС Dj lUZKUilrlCizl ICKCIUdclzI 1ДиЛИ1ДД содержится в некотором контейнере, являющемся кандидатом в основной текст статьи, то этот факт фиксируется. Список Rest - собрание таких фактов. Он вполне может оказаться пустым, если основная статья не содержит таблиц или их вообще нет. На основе этого списка для каждого кандидата формируется список входящих в него текстовых таблиц, причем не вложенных.
Определяется блок с самым длинным текстом: FindMaxText. Определяется длина текста в каждом кандидате в Основной текст статьи.
1. Для кандидата выполняется следующее:
1) Определяется длина «обычного» (т.е. вне таблиц) текста в кандидате. Для этого сканируется список потомков кандидата. Если тип потомка - один из {<р>,
, , ,
}, то с помощью процедуры CalcPureTxtLen подсчи-
тывается «чистая» длина текста в этом потомке.
2) Определяется длина текста в таблицах, входящих в состав кандидата, используя TblForCandMainTxt_Ids. В каждом случае выбрасываются входящие дескрипторы любых тегов, в том числе вложенные. Отбрасываются ведущие и хвостовые пробелы. Возвращает длину полученной строки.
3) Все длины текстов суммируются.
2. Выбирается кандидат с наибольшим значением показателя. Это и есть Основная статья.
Подготовка марк-листов для Главного заголовка, Основной статьи и ’a html-страницы. Это заключительная стадия алгоритма по собственно распознаванию ролей, включающая несколько блоков таблицы 2.
1. Мы знаем ЕТ с текстом Основной статьи. Следует ли этот ЕТ включать в результат в полном составе? В общем случае - нет. Там могут быть посторонние объекты, например, реклама, ссылки на дополнительные материалы по теме и т.д. Кроме того, в этот ЭТ могут быть включены и комментарии. Мы их должны взять на заметку (для распознавания и этих ролей в будущем), но пока исключить. Поэтому сначала мы отбираем то, что заведомо нужно. Это {X | type(X) £ {<р>, <рге>,
, ,
,,.„, <Ьб>} }. Все остальные пока считаются предположительно ненужными. Получаются, соответственно, 2 списка NessTextlds и QuUnusTextlds. Далее из этих списков удаляем все элементы, имеющие идентификатор больше BestCandCommentHeader_Id, т.е., по-видимому, уже относящиеся к комментариям. Для элементов из NessTextlds формируем марк-лист.
2. Далее формируем MarkListlBestHdr - марк-лист для главного заголовка.
3. В ЕТ нам нужно сохранить и те ЭТ <meta>, в которых есть атрибуты 'charset' и 'http-equiv'. Двух последних может и не оказаться. Мы считаем, что
эти ЕТ входят в непосредственно. Их обнаружение и составление марк-листов не вызывает особенных трудностей.
4. Создается марк-лист для таблиц, которые необходимо включить в Основную статью. Для этого сканируется список ГТТЛА ! П IfA ТТ/УМГТ/ГТ'А TTl~U^ Т-Г АТ-ГХ fM-fT-TT-TV 'ЗПАМАГГТЛР 11иСД11илиЖИ1СЛЬгЮ НиНуЖНЫл OJIUMUHIOd QuUnusTextlds. Если элемент - не вложенная текстовая таблица, то он признается годным и на него составляется марк-лист.
5. Аналогичная процедура выполняется для рисунков (ЕТ ) в составе Основной статьи.
6. Программная реализация
гтя ПЛ11ЦЛ nf'tX'V № I Г> ¥/• п I Юж W ¥ ¥< IV
«У ДЛЛспИс dWa «) НУ ЧсппшА в марк-листы, является технической операцией.
Нахождение ближайшего общего предка Главного заголовка и Основной статьи необходимо для обеспечения правильного отображения страницы на экране после всех модификаций.
Данная модель реализована программно.
На вход программы подается список URL. Программа считывает html-файл по одному из Интернета, удаляет все кроме главного заголовка и основной статьи и сохраняет результат на диске, там он может быть просмотрен с помощью любого браузера. Пользовательского интерфейса фактически нет.
Программа написана на языке Python. Архитектура программы следующая.
Два основных компонента программы: 1) экспертная система, реализующая модель, 2) интерфейс с Интернетом и хранилищем на диске. Развитой базы данных и пользовательского интерфейса фактически
Основным компонентом является экспертная система. Программно она представляет собой набор следующих основных компонентов:
1) Библиотека из примерно 35 мелких функций.
2) Хранилище глобальной информации (см. табл. 1).
3) Класс ProdSyst, реализующий продукционную систему. В ходе работы программы создается некоторое количество экземпляров класса, которые при создании инициализируются набором правил. Каждое правило представляет собой кортеж из двух небольших функций (обычно - в виде лямбда-функций): антецедента и консеквента продукции. Антецедент возвращает логическое значение и содержит, в основном, ссылки на глобальную информацию и на локальную информацию (свойства) данного экземпляра ProdSyst. Консеквент, в основном, содержит вызовы библиотечных функций. Библиотечные функции, как правило, работают только с глобальной информацией, причем узко специализированы. Язык Python здесь очень удобен, так как позволяет действовать в стиле функционального программирования, при этом каждой функцией (или набором) можно манипулировать, как одним объектом.
4) Функция, которая запускает всю систему и организует работу в целом.
7. Экспериментальная проверка
8. Выводы
В начале работы создается объект класса ProdSyst, которому передается система правил, фактически, без антецедентов, а консеквенты реализуют как раз действия, описанные в табл. 2. Те, в свою очередь, создают экземпляры ProdSyst для решения локальных задач и т.д. Этот объект существует до конца работы и разрушается последним.
Проверка работоспособности проводилась на новостных сайтах, сайтах IT- компаний и на сайте habrahabr.ru. Сайты русско- и англоязычные. Результаты в каждом случае оценивались экспертно. Естественно, БЗ многократно дорабатывалась. В конце процесса работы над системой доля правильно обработанных страниц составила 85-90% в случаях табличной верстки и 95-97% - при блочной. Разницу можно объяснить, с одной стороны, тем, что в случае блочной верстки программа чувствительнее к ошибкам в HTML-коде, их сложнее исправлять. С другой стороны, сама модель нуждается в доработке в части распознавания HTML-страницы, созданной с помощью табличной верстки.
Разработана модель содержимого (контента) веб-страницы, позволяющая выделить фрагменты html-кода, выполняющие роли главного заголовка и основной статьи страницы. При этом основная статья может содержать разнородные элементы: текст, рисунки, таблицы и т.д., из нее удаляются внедренные фрагменты другого назначения (реклама и др.), могут использоваться различные компоновки контента на странице и способы верстки.
Модель основана на подражании человеческому способу восприятия информации «на взгляд» при выделении главных фрагментов содержания, т.е. ориентируется на то, как представлена информация.
Технически модель представляет собой экспертную систему.
Модель программно реализована. Экспериментальная проверка показала достаточно высокую адекватность модели.

Список литературы Репрезентативно-ролевая модель содержимого веб-страницы

Приложение для сохранения информации в облаке. Pocket URL: http://getpocket.com.
Продукционные модели // Искусственный интеллект: В 3 кн. Кн. 2. Модели и методы: Справочник / Под. ред. Д.А.Поспелова. - М., 1990.
Семантика в HTML 5. URL: http://habrahabr.ru/post/49734.
Учебник HTML. URL: http://ru.html.net/tutorials/html.
Элти Дж., Кумбс М. Экспертные системы: концепции и примеры. - М., 1977.

Статья научная