On unification of processing methods of the structured information
The problem of search and collection of information from DOM models of the same type is examined inthe article. A mechanism of collection of the structured information from relevant sources is offered, that allows to build the universal analyzers of data from these sources.Prombles in programming 20...
Збережено в:
| Дата: | 2025 |
|---|---|
| Автори: | , |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
PROBLEMS IN PROGRAMMING
2025
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/826 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-826 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/16/cd3ab3ceb0f8d1c572e27af04f468016.pdf |
| spelling |
pp_isofts_kiev_ua-article-8262025-09-02T15:42:07Z On unification of processing methods of the structured information Про уніфікацію способів обробки структурованої інформації Doroshenko, A.Yu. Molotievskiy, L.G. UDC 004.428.4 УДК 004.428.4 The problem of search and collection of information from DOM models of the same type is examined inthe article. A mechanism of collection of the structured information from relevant sources is offered, that allows to build the universal analyzers of data from these sources.Prombles in programming 2011; 4: 56-62 Розглядаються проблеми пошуку та збору інформації з однотипних DOM-моделей. Запропоновано механізм збору структурованої інформації з релевантних джерел, що дозволяє будувати універсальні аналізатори даних з цих джерел.Prombles in programming 2011; 4: 56-62 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-09-02 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/826 PROBLEMS IN PROGRAMMING; No 4 (2011); 56-62 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2011); 56-62 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2011); 56-62 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/826/878 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-09-02T15:42:07Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
UDC 004.428.4 |
| spellingShingle |
UDC 004.428.4 Doroshenko, A.Yu. Molotievskiy, L.G. On unification of processing methods of the structured information |
| topic_facet |
UDC 004.428.4 УДК 004.428.4 |
| format |
Article |
| author |
Doroshenko, A.Yu. Molotievskiy, L.G. |
| author_facet |
Doroshenko, A.Yu. Molotievskiy, L.G. |
| author_sort |
Doroshenko, A.Yu. |
| title |
On unification of processing methods of the structured information |
| title_short |
On unification of processing methods of the structured information |
| title_full |
On unification of processing methods of the structured information |
| title_fullStr |
On unification of processing methods of the structured information |
| title_full_unstemmed |
On unification of processing methods of the structured information |
| title_sort |
on unification of processing methods of the structured information |
| title_alt |
Про уніфікацію способів обробки структурованої інформації |
| description |
The problem of search and collection of information from DOM models of the same type is examined inthe article. A mechanism of collection of the structured information from relevant sources is offered, that allows to build the universal analyzers of data from these sources.Prombles in programming 2011; 4: 56-62 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/826 |
| work_keys_str_mv |
AT doroshenkoayu onunificationofprocessingmethodsofthestructuredinformation AT molotievskiylg onunificationofprocessingmethodsofthestructuredinformation AT doroshenkoayu prounífíkacíûsposobívobrobkistrukturovanoíínformacíí AT molotievskiylg prounífíkacíûsposobívobrobkistrukturovanoíínformacíí |
| first_indexed |
2025-09-17T09:24:34Z |
| last_indexed |
2025-09-17T09:24:34Z |
| _version_ |
1850413157132009472 |
| fulltext |
Програмування для комп’ютерних мереж та Internet
56
УДК 004.428.4
А.Ю. Дорошенко, Л.Г. Молотієвський
ПРО УНІФІКАЦІЮ СПОСОБІВ ОБРОБКИ
СТРУКТУРОВАНОЇ ІНФОРМАЦІЇ
Розглядаються проблеми пошуку та збору інформації з однотипних DOM-моделей. Запропо-
новано механізм збору структурованої інформації з релевантних джерел, що дозволяє будува-
ти універсальні аналізатори даних з цих джерел.
Вступ
Інформація в всесвітній мережі Ін-
тернет представлена переважно у вигляді
сторінок, написаних мовою гіпертекстової
розмітки HTML. Кожна сторінка має влас-
ну модель DOM, тобто об'єктну модель
документу (від англ. Document Object
Model[1]), яка є специфікацією прикладно-
го програмного інтерфейсу для роботи зі
структурованими документами.
З точки зору об'єктно-орієнтованого
програмування, DOM визначає класи, ме-
тоди та атрибути цих методів для аналізу
структури документів та роботи із пред-
ставленням документів у вигляді дерева.
Все це призначено для того, аби надати
комп'ютерній програмі доступ до DOM
моделі документу та його структури, зміс-
ту та оформлення. Вибірка даних із такої
структури можлива за допомогою запиту
Xpath [2]. XPath (XML Path Language) – це
мова виразів для адресації частин XML
документу, або для обчислення величин
(строкових, числових або булевих) на ос-
нові вмісту XML документа.
Основною проблемою аналізу сто-
рінок є відсутність механізмів які дозволи-
ли б використовувати існуючі дані, для
вибірки інформації з інших подібних (ре-
левантних) сторінок. Релевантність – це
властивість відповідності між бажаною
інформацією та тою, що отримується з
джерела.
В наш час всесвітня мережа Інтер-
нет несе в собі велику кількість сервісів,
що надають однакові послуги. З формаль-
ної точки зору, такі сервіси мають подібну
структуру, функції та інтерфейс користу-
вача. Будемо називати такі сервіси одно-
типними. Для прикладу достатньо розгля-
нути кілька реальних однотипних сервісів,
які займаються, оптовою торгівлею та на-
дають сервіс пошуку туристичних турів:
http://online.newstravel.com.ua/search_tour і
http://online.coraltravel.com.ua/search_tour.
Порівнюючи ці сервіси, можна зазначити,
що вони:
- надають одні й ті ж самі послуги;
- мають подібні візуальні інтерфейси;
- мають одного й того ж розробника;
- мають однакові механізми створення за-
питів;
- несуть у собі взаємно релевантні дані.
Але, на жаль, ми не можемо вико-
ристовувати один і той же XPath запит,
який би дозволив отримати релевантні дані
(наприклад, назву країни для подорожі),
тому що DOM модель у кожного із серві-
сів – різна. Для створення раціонального
підходу до розв’язання задачі уніфікації
сервісів, потрібні механізми, які б дозво-
лили автоматично адаптуватися до нових
однотипних сервісів. З цією метою ство-
рюються аналізатори таких ресурсів. Про-
те існуючі механізми аналізу, такі як:
BeautifulSoup, HTMLParser, Kizna HTML
Parser та Jericho HTML Parser, часто не
гнучкі та потребують доопрацювання при
використанні для інших однотипних серві-
сів. Такий підхід веде до збільшення кіль-
кості аналізаторів.
Мета даної статті – оптимізація ме-
ханізмів аналізу та вибірки інформації із
однотипних сервісів шляхом побудови
уніфікованих аналізаторів для таких серві-
сів. При написанні аналізаторів для одно-
типних сервісів виникають такі проблеми:
© А.Ю. Дорошенко, Л.Г. Молотієвський, 2011
ISSN 1727-4907. Проблеми програмування. 2011. № 4
Програмування для комп’ютерних мереж та Internet
57
- аналіз подібних сервісів, потребує напи-
сання спеціальних механізмів вибірки
даних, що часом мають складну структу-
ру;
- перед написанням аналізатору, розробни-
ку потрібно продивитися DOM модель, та
скласти XPath запити для вибірки даних,
що займає значний час;
- зміна DOM моделі джерела потребує змі-
ну XPath запиту.
Метою системи збору інформації з
однотипних інформаційних джерел є ство-
рення системи, яка може автоматично
створювати XPath запити, використовува-
ти вже існуючи дані для оновлення або
створення нових аналізаторів однотипних
інформаційних джерел.
1. Проблеми існуючих рішень
Існує досить багато рішень, які
дозволяють аналізувати дані DOM, але
більшість із них потребує ручного
втручання розробника в процес аналізу.
Розглянемо два існуючих рішення: Kizna
HTML Parser та Jericho HTML Parser.
Серед їхніх переваг слід відмітити:
- вибірка тексту з документу за запи-
том;
- вибірка з DOM електронних пошто-
вих адрес;
- захоплення ресурсів зі сторінки (ка-
ртинки, Flash анімацію, JavaScript сце-
нарії);
- обробка вихідних даних сторінок
які показані на екрані, з метою виділи-
ти інтерфейсну інформацію. Основна від-
мінність такого виду аналізу від звичай-
ного полягає в тому, що дані спочатку ма-
ли бути використані для сприйняття
людиною, а не для машинної інтерпрета-
ції;
- перевірка Веб-посилань на сторінці;
- трансформація HTML сторінки в ХML.
Головний недолік існуючих рішень
полягає у тому, що вони орієнтовані лише
на побудову та вибірку певної інформації з
однієї сторінки а, отже, не забезпечують
механізмів вибірки даних з релевантних
сторінок.
2. Характеристика однотипних
ресурсів
Для порівняння двох однотипних
ресурсів потрібно дослідити код HTML
сторінок які генеруються даними
сервісами. Для прикладу візьмемо сервіси
пошуку туристичних турів
(http://online.coraltravel .com.ua/search_tour
та http://online. newstravel.com.ua/search_
tour).
Виділимо групу релевантних еле-
ментів. Як приклад візьмемо країни для
подорожі, та дослідимо HTML код даних
елементів
Coraltravel:
<select name="STATEINC" class="STATEINC"
autocomplete="off">
<option value="104">China</option>
<option value="114">Cuba</option>
<option value="143">Dominican Repub-
lic</option>
<option value="58">Egypt</option>
<option value="95">India</option>
<option value="180">Indonesia</option>
<option value="181">Maldives</option>
<option value="182">Ukraine</option>
<option value="183">Korea</option>
<option value="96">Thailand</option>
<option value="51">Turkey</option>
<option value="151">UAE</option>
</select>
Newstravel:
<select name="STATEINC" class="STATEINC"
autocomplete="off">
<option value="25">Болгария</option>
<option value="27">Греция</option>
<option value="7">Кипр</option>
<option value="56">ОАЭ</option>
<option value="51">Таиланд</option>
<option value="8">Тунис</option>
<option value="54">Хорватия</option>
<option value="52">Черногория</option>
<option value="23">Чехия</option>
</select>
Порівнявши ці два коди, можна
стверджувати, що вони несуть релевантні
дані. Наприклад країна ОАЕ присутня в
обох списках. Назва та клас даного компо-
ненту сторінки однакові. Це трапляється в
тому випадку, коли обидві пошукові сис-
Програмування для комп’ютерних мереж та Internet
58
теми були розроблені одним и тим самим
розробником.
3. Засоби для аналізу
Для побудови DOM моделі будемо
використовувати HTML Agility Pack [5].
Ця бібліотека несе в собі можливості які
дозволяють:
- перетворювати будь який правильний
HTML документ в DOM модель;
- для кожного елемента DOM моделі
створюється XPath запит;
- мати зручну деревовидну систему
переходів від одного вузла до іншого;
- не використовує ручну реєстрацію
користувацьких атрибутів;
- мати функції редагування вмісту
HTML
сторінки, що дозволяє видалити, редагува-
ти та створити нові елементи HTML сторі-
нки;
- конвертує HTML документ в XML.
Для вибірки об’єктів з DOM моделі.
продумана реалізація декількох способів,
як це зробити, а саме:
- Linq to XML;
- XPath;
- XSLT.
LINQ to DOM − технологія яка до-
зволяє відділити сутнісну об’єктну модель
даних від фізичних даних, в даному випад-
ку HTML файлу, вводячи логічне відобра-
ження між ними.
Language Integrated Query (LINQ) –
це мова інтегрованих запитів, що допома-
гає отримати дані з джерела даних. Зазви-
чай, запити виражалися на спеціальній мо-
ві запитів. Для реляційних баз даних по-
трібно було використовувати SQL та
XQuery для XML. Таким чином, розробни-
ки змушені вивчати нову мову запитів для
кожного із джерел даних. LINQ спростив
ситуацію, запропонувавши узгоджену мо-
дель, для роботи з даними в різних видах
джерел даних таких як: XML, SQL, ADO
.Net, та різноманітних колекціях даних.
XSLT (eXtensible Stylesheet Languag
e Transformations) – мова конвертації XML
документів. Перетворення виразів через
XSLT, описує правила перетворення вихі-
дного документу в кінцеве дерево. Пере-
творення будується шляхом зіставлення
зразків і шаблонів. Зразок порівнюється з
елементами вихідного дерева, а шаблон
використовується для створення частин
кінцевого дерева. Кінцеве дерево відокре-
млено від вихідного дерева. Структура
кінцевого дерева може повністю відрізня-
тися від структури вихідного дерева. У хо-
ді побудови кінцевого дерева елементи ви-
хідного дерева можуть піддаватися фільт-
рації, також може бути додана нова струк-
тура.
Надважливим компонентом даної
бібліотеки, є конвертація HTML докумен-
ту в XML, та побудова DOM моделі. При
побудові цієї моделі, для кожного із еле-
ментів генерується XPath вираз. Для при-
кладу візьмемо деяку HTML сторінку:
<html>
<body>
<div>Some content1</div>
<div>Some content2</div>
</body>
</html>
Для кожного з елементів, які несуть назву
тегу div, буде створений XPath запит, який
буде мати наступний вигляд:
html[0]/body[0]/div[0] та html[0]/body[0]/
div[1].
4. Підходи до екстрагування даних
з веб-русурсів
Web Mining [3] − це процес отри-
мання даних веб-ресурсів, який, як прави-
ло, має більше практичну складову ніж те-
оретичну. Основна мета Web Mining − це
збір даних (аналіз) з наступним збережен-
ням у потрібному форматі. Фактично, за-
вдання зводиться до написання HTML
аналізаторів. Є кілька підходів до вилу-
чення даних:
- аналіз DOM дерева;
- використання XPath;
- візуальний підхід.
4.1. Аналіз DOM дерева. Викорис-
тання XPath. Цей підхід ґрунтується на
аналізі DOM дерева. Використовуючи цей
підхід, дані можна отримати безпосеред-
Програмування для комп’ютерних мереж та Internet
59
ньо за ідентифікатором імені або інших
атрибутів елемента дерева (таким елемен-
том може служити параграф, таблиця, блок
і т. д.). Крім того, якщо елемент не позна-
чений яким-небудь ідентифікатором, то до
нього можна дістатися за унікальним шля-
хом, спускаючись вниз по DOM дереву,
наприклад:
body → p [10] → a [1] → текст посилання
або пройтися по колекції однотипних еле-
ментів:
body → links → 5 елемент → текст поси-
лання.
Переваги цього підходу:
- можна отримати дані будь-якого типу і
будь-якого рівня складності,
- знаючи розташування елемента, можна
отримати його значення, прописавши шлях
до нього.
Недоліки такого підходу:
- різні HTML / Javascript механізми та
сервіси по-різному генерують DOM дере-
во, тому потрібно прив'язуватися до конк-
ретного механізму;
- шлях елемента може змінитися, тому,
як правило, такі аналізатори розраховані
на короткочасний період збору даних;
- DOM-шлях може бути складний і не
завжди однозначний.
Наступним еволюційним етапом
аналізу DOM дерева є використання XPath
– тобто шляхів, які широко використову-
ються при аналізі XML документів. Суть
даного підходу в тому, щоб за допомогою
деякого простого синтаксису описувати
шлях до елемента без необхідності посту-
пового руху вниз по DOM дереву.
4.2. Візуальний підхід. Сенс у даній
концепції наступний - розглядати веб-
сторінку не як єдине ціле, а як набір інфо-
рмаційних блоків, які будемо вважати
одиницею, що відображається. Такий під-
хід дозволяє виділяти потрібні ділянки ко-
нтенту і аналізувати їх у контексті всієї
сторінки.
Основна ідея такого підходу це по-
діл сторінки на інформаційні блоки. Не зо-
всім тривіальне завдання, як може здатися
на перший погляд. Ранні підходи були по-
в'язані з 1) аналізом DOM моделі; 2) аналі-
зом великої кількості сторінок усередині
сайту та визначення так званого «шабло-
ну» сайту. Як правило, ці підходи не дава-
ли позитивного результату.
Рішенням даної проблеми – вико-
ристання алгоритму VPSA (Vision-based
Page Segmentation Algorithm) [4] від
Microsoft Research Asia. В цьому алгоритмі
використовується комбінований підхід, а
саме аналіз DOM моделі і власні правила
сегментації, виведені експертним або екс-
периментальним шляхом.
Основною складністю використан-
ня даного алгоритму є процес визначення
критеріїв оцінки і те, за якими правилами
розрізняються різні блоки. Або більш кон-
кретно: за якими ознаками можна відріз-
нити набір посилань і основний контент?
Щоб це зробити потрібно виконати аналіз
основних параметрів (характеристик) бло-
ків.
Є одна реалізація даного алгоритму,
вона представлена як SmartBrowser [5].
5. Проблеми аналізу контенту
веб-ресурсів
Проблеми при парсингу HTML да-
них − використання Javascript / AJAX /
асинхронних завантажень, які значно
ускладнюють написання аналізаторів а са-
ме: різні методи візуалізації HTML можуть
видавати різні DOM дерева. Крім того, ці
методи можуть мати помилки, які потім
впливають на результати роботи аналіза-
торів а саме: великі обсяги даних вимага-
ють написання розподілених аналізаторів,
що тягне за собою додаткові витрати на
синхронізацію.
Не можна однозначно виділити під-
хід, який буде 100 % застосовуватись у
всіх випадках. Тому сучасні бібліотеки для
аналізу HTML даних, як правило, комбі-
нують різні підходи. Наприклад,
HtmlAgilityPack [6] дозволяє аналізувати
дерево DOM (використовувати XPath), а
також з недавніх пір підтримується техно-
логія LINQ to XML. Вилучення даних SDK
використовує аналіз дерева DOM, містить
набір додаткових методів для аналізу ряд-
ків, а також дозволяє використовувати те-
хнологію LINQ для запитів в DOM моделі
сторінки.
Програмування для комп’ютерних мереж та Internet
60
6. Алгоритм та опис його роботи
Будь яка правильна HTML сторінка
конвертується в XML-документ, за яким
згодом будується DOM-модель. Будь яка
DOM-модель, що побудована на основі
HTML сторінки представляє собою прави-
льне дерево, що значно полегшує аналіз.
Початковими даними для аналізу
сторінки мають бути дані вилучені будь-
яким способом із іншого або цього-ж са-
мого ресурсу. Чим більше даних, які вико-
ристовуються для визначення релевантно-
сті, буде мати аналізатор, тим точніше бу-
де результат отриманий на виході.
Слід також зазначити, що деякі сер-
віси використовують системи захисту від
автоматичного аналізу. Можна навести де-
кілька способів захисту:
- використання AJAX для отримання да-
них, після завантаження HTML ссторінки;
- використання однакових атрибутів, що
ідентифікують елементи(id);
- використання зображень, які несуть в
собі дані.
Даний алгоритм (рис. 1) виконує
функцію пошуку в будь-якій правильній
DOM моделі HTML сторінки, груп вузлів
які несуть в собі групи, які містять в собі
релевантні елементи. Потім, для кожної з
даних груп створюється свій унікальний
XPath запит. Алгоритм потребує змін, у
випадку якщо використовуються системи
захисту від аналізу даних.
Крок 1. Аналіз та створення DOM.
Першу частину роботи виконує HTML
Agility Pack. Він формує DOM модель для
HTML документу, та створює для кожного
вузла окремий XPath запит.
Крок 2. Створення додаткових да-
них для кожного вузла дерева. Для кожно-
го вузла створюється окремий ідентифіка-
тора, який формується на основі батьків-
ського ідентифікатора, назви тегу. Для
прикладу візьмемо HTML сторінку:
<html>
<head>
…
</head>
<body>
<div class=”info”>
<ul>
<li>Text1</li>
<li>Text2</li>
<li>Text3</li>
<li>Text4</li>
</ul>
</div>
</body>
</html>
Елемент дерева <li> буде мати іден-
тифікатор “htmlbodydivclassinfoulli”. Далі
формується XPath запит: html[0]/body[0]
/div[0]/ul[0]/li[0], а для елемента списку з
вмістом «Text2» буде сформований інший
XPath html[0]/body[0] /div[0]/ul[0]/li[1]. Да-
лі дані вузли додаються до загального спи-
ску елементів. Далі потрібно перевірити чи
є в даного вузла дочірні елементи, якщо
такі існують, то повторити дії описані ви-
ще(крок 1-2).
Крок 3. Формування релевантних
груп. Коли всі вузли були додані до зага-
льного списку, виконується групування
елементів. Для кожної групи елементів
створюється окремий список. З загальним
XPath який дозволяє отримати цю групу з
DOM моделі даного документа.
Крок 4. Формування масиву даних
для кожної із груп. У ході операцій нам
доступні групи елементів які несуть у собі
деякі дані. Для кожної групи створюються
списки даних. Тобто, кожен елемент у
групі несе в собі дані які містяться в са-
мому тезі та його атрибутах. Наприклад,
для даного елемента Html сторінки:
<label>
<input type="checkbox" addition=
”Duna” value="412" >
Дюны
</label>
будуть сформовані 3 списки даних для ат-
рибутів для Value, addition та для вмісту
тегу label. Після чого, потрібно для кожної
із груп провести операцію перетину з вже
існуючими даними для визначення релева-
нтності. Якщо такі дані знайдені, автома-
тично формується XPath запит.
Крок 5. Оптимізація XPath запитів.
Кожен обраний елемент у групі має влас-
ний XPath запит.
Причому цей запит буде відрізняти-
ся лиш порядковим номером елемента
Програмування для комп’ютерних мереж та Internet
61
Рис. 1. Алгоритм роботи аналізатора однотипних сервісів
Програмування для комп’ютерних мереж та Internet
62
(li[1]) тому, щоб отримати запит для групи
елементів, нам лише потрібно видалити
цей номер. Тоді Xpath запит буде вибирати
з DOM моделі відразу групу. Аналіз, про-
ведений у попередньому пункті, дасть ін-
формацію про те, який із атрибутів елеме-
нта несе в собі необхідну інформацію.
Якщо одна множина даних має дві
або більше релевантних груп, то тоді по-
трібен перетин запитів, наприклад:
<html>
<body>
<div class=”info”>
<ul>
<li>Text1</li>
<li>Text2</li>
</ul>
</div>
<div class=”info2”>
<ul>
<li>Text1</li>
<li>Text2</li>
<li>Text3</li>
<li>Text4</li>
</ul>
</div>
<body>
</html>
Буде сформовано 2 групи XPath за-
питів які наведені далі:
html[0]/body[0] /div[1]/ul[0]/li,
html[0]/body[0] /div[0]/ul[0]/li.
Після чого проводиться порівняння
таких XPath та виділення єдиного для ви-
бірки обох груп html[0]/body[0] /div/ul[0]/li.
Якщо такий перетин зробити неможна,
оскільки XPath запити сильно відрізняють-
ся, то тоді вони зберігаються окремо.
Крок 6. Відображення результатів.
У випадку виявлення конфліктів, якщо дві
множини даних входять в одну множину
даних отриманих з однієї групи елементів
DOM моделі, такі XPath мають бути збе-
режені, щоб користувач після повного
аналізу вирішив даний конфлікт.
1. DOM (Document Object Model)
http://www.w3.org/TR/REC-DOM-Level-1/
2. XPath
http://www.w3.org/TR/1999/REC-xpath-
19991116/
3. Степанов Р.Г. Технология Data Mining:
Интеллектуальный анализ данных. – 2008.
– http://m8.ksu.ru/EOS/dm.pdf
4. VPSA (Vision-based Page Segmentation
Algorithm)
http://research.microsoft.com/apps/pubs/default.as
px?id=70027
5. SmartBrowser
http://smartbrowser.codeplex.com/
6. HTML Agility Pack Project home page. –
http://htmlagilitypack.codeplex.com/
7. Smith K.A. Cross-Disciplinary perspectives on
meta-learning for algorithm selection. ACM
Comput. Surv., 41, 1, Article 6 (December
2008). – 2008. – 25 p.
8. Wang X., Smith K.A., Hyndman R. Character-
istic-Based clustering for time series data. Da-
ta Mining Knowl. Discov. 13. – 2006. –
P. 335–364.
9. Adelberg B. NoDoSE: A tool for semiauto-
matically extracting structured and semistruc-
tured data from text documents, In Proceed-
ings of ACM SIGMOD Conference on Man-
agement of Data, 1998. – Р. 283– 294.
10. Bar-Yossef Z. and Rajagopalan S., Template
Detection via Data Mining and its Applica-
tions, In Proceedings of the 11th International
World Wide Web Conf. (WWW2002), 2002.
11. Richter J. CLR via C#. – Microsoft, 2010. –
896 с.
12. Durstenfeld R. Algorithm 235: Random per-
mutation. Communications of the Association
for Computing Machinery, 7:420. – 1964.
Отримано 16.05.2011
Про авторів:
Дорошенко Анатолій Юхимович,
доктор фізико-математичних наук,
професор, завідувач відділом теорії
комп’ютерних обчислень Інституту
програмних систем НАН України.
Молотієвський Леонід Геннадійович,
студент 5 курсу магістратури.
Місце роботи авторів:
Національний технічний університет
України «КПІ», 03056, м. Київ,
проспект Перемоги, 37.
Тел.: 044 4068610,
e-mail: dor@isofts.kiev.ua,
kpi.leon@gmail.com
|