Удосконалення технологій доступу та обробки пов’язаних даних семантичних додатків LinkedData Текст научной статьи по специальности «Математика»

УДК 519.7:007.52

IM. ГАЛУШКА, В. В. ЗАВГОРОДН1Й, С.М. СОЛОШИЧ, С. С. ЩЕРБАК

УДОСКОНАЛЕННЯ ТЕХНОЛОГ1Й ДОСТУПУ TA ОБРОБКИ ПОВ'ЯЗАНИХ ДAНИХ СЕМАНТИЧНИХ ДОДATKIВ LINKEDDATA

Зpоcтaння попyляpноcтi концeпцiï пов'язaниx дaниx ropHA з опиcом iнфоpмaцiï y вигляд тpиплeтiв RDF зумовило нeобxiднicть доcлiджeння пpоцeдyp взаемоди з1 cxовищaми тpиплeтiв. У peзyльтaтi pозpоблeно yнiвepcaльний пошуковий iнтepфeйc, що зaбeзпeчye в1зуальну побудову запипв до cxовищ тpиплeтiв. В1зуальш запити автоматично пepeтвоpю-ютьcя у мову запипв SPARQL, яка викоpиcтовyeтьcя для доcтyпy до cxовищ тpиплeтiв. Пicля виконання запиту коpиcтyвaч отpимye конгeкcт з тpиплeтaми, що ввдповщають шука-ним з ypaxyвaнням задант обмeжeнь на пpeдикaти i об'екти.

Вступ

Шиpокий pозвиток cтaндapтiв i пiдтpимкa концeпцiï LinkedData вeликими IT компaнiями визначае тeндeнцiï pозвиткy майбутнього WWW як глобально!' бази дaниx, в якш можна чepeз cпeцiaлiзовaнi пошyковi iнтepфeйcи отpимyвaти доcтyп до cтpyктypовaниx пpeдcтaв-лeнь дaниx, докyмeнтiв, pозподiлeниx по Web, для виpiшeння завдань пошуку i подiбниx.

В paмкax LinkedData iнфоpмaцiя опиcyeтьcя в тepмiнax мови RDF (англ. ResourceDescription Framework), а caмe, у виглядi тpиплeтiв, тpiйок вигляду ««уб^кт-пpeдикaт-об'eкт» або квад (quad) - iмeновaниx гpaфiв виду «гpaф-cyб'eкт-пpeдикaт- об'ект». Дaлi, якщо ад нe бyдe пpизводити до пpотиpiччя, бyдeмо викоpиcтовyвaти поняття «тpип-лeт» для поняття як «тpиплeт», так i «квад».

Модeль дaниx RDF пepeдбaчae pозподiлeнe збepiгaння об'екпв i ïx cxeм, за ïx нaявноcтi, на piзниx web-cepвepax з iнтeгpовaним або зовнiшнiм cпeцiaлiзовaним cxовищeм тpиплeтiв (Triplestore). Для доcтyпy до cxовищ тpиплeтiв викоpиcтовyeтьcя пpотокол i мова запипв SPARQL (англ. SPARQL Protocoland RDF QueryLanguage), яка e в швному ceнci аналогом мови SQL, що викоpиcтовyeтьcя для обpобки дaниx peляцiйниx баз. Bикоpиcтaння подiбниx мов зaпитiв пepeдбaчae нaявнicть cпeцiaлiзовaниx знань для eфeктивного ïx зacтоcyвaння, що нe cпpияe нi попyляpизaцiï мови SPARQL як зacобy отpимaння дaниx, нi збiльшeнню пошиpeноcтi cxовищ тpиплeтiв.

Метою дaноï pоботи е пiдвищeння eфeктивноcтi пошуку на оcновi cxовищ тpиплeтiв шляxом змeншeння cклaдноcтi пpоцeдyp динaмiчного фоpмyвaння зaпитiв на мовi SPARQL i зacтоcyвaння шаблошв зaпитiв для гeнepaцiï пошукового iнтepфeйcy коpиcтyвaчa. Тому до задач доcлiджeння вiдноcятьcя:

- aнaлiз пiдxодiв щодо викоpиcтaння та доcлiджeння можливоcтeй пов'язaниx дaниx в контeкcтi пошуку;

- фоpмaлiзaцiя пов'язaниx дaниx та пpоцeдyp пошуку;

- доcлiджeння тexнологiй побудови cyчacниx iнтepфeйciв коpиcтyвaчa для cxовищ пов'я-зaниx дaниx;

- pозpобкa apxiтeктypи та peaлiзaцiя типового piшeння пошукового iнтepфeйcy коpиcтy-вача на бaзi мови зaпитiв SPARQL.

1. Пошуковi iнтерфейси користувача до сховищ триплетiв

Пошук iнфоpмaцiï в paмкax LinkedData rpyнтyeтьcя на викоpиcтaннi данж, пpeдcтaвлeниx у виглядi об'eктiв, що нaлeжaть до дeякоï пpeдмeтноï облает! У paмкax такого пiдxодy вмют докyмeнтa подaeгьcя як cyкyпнicть об'екпв, об'eднaниx дeяким контeкcтом. Для визнaчeння контeкcтy об'eктiв бyдeмо викоpиcтовyвaти поняття «гpaф» квада. Tодi пошук iнфоpмaцiï зводитьcя до iдeнтифiкaцiï за заданими кpитepiями (коpиcтyвaльницькими обмeжeннями) тpиплeтiв ^афа i виcновкy контeкcтiв з тpиплeтaми, що вiдповiдaють iдeнтифiковaним.

Для cтвоpeння eфeктивниx пошyковиx iнтepфeйciв, «дpyжнix» до коpиcтyвaчa, нeобxiднa pозpобкa типовиx prnem - пaтepнiв peaлiзaцiй, якi могли б дозволити вiзyaльно конcтpyювa-ти запити до iмeновaниx гpaфiв cxовищa тpиплeтiв i нe вимагали б вщ pозpобникa або коpиcтyвaчa пpогpaмниx cиcтeм cпeцiaлiзовaниx знань пpо мову SPARQL.

На прикладi веб-додатку розглянемо архитектуру класичного ршення на 0CH0Bi сховища триплета i мови запитiв SPARQL (рис. 1).

HTML/CSS

SPARQL

1нтерфейс користувача

Интернет

Веб-сервер

XML/JSON

Серверное додаток

Сховище триплетiв

PDO/ODBC

Рис. 1. Архитектура веб-додатку на основi сховища триплелв Запит користувача на мовi SPARQL передаеться вiд web-додатку, ктентська частина якого написана на мовах HTML та CSS, до сховища триплета, де вщбуваеться виконання запиту через штерфейси доступу PDO або ODBC, а результати вщсилаються назад ктенту в формат XML або JSON.

Ключова особливють класичного ршення полягае в необхiдностi формування, найчасть ше вручну, запиту на мовi SPARQL, що вимагае спецiалiзованих знань не тшьки про цю мову, але i знань про структуру об'екта, що мiстяться у сховищi триплетiв.

Одним з додаткiв, що реалiзують подiбну функцiональнiсть, е веб-штерфейс isql компанп OpenLink, що застосовано в Dbpedia, який поряд з ушверсальнютю доступу до даних в^^зняеться стабiльнiстю роботи.

Розглянемо архiтектуру запропонованого ршення, що виключае взаемодiю користувача з сховищем триплета через SPARQL (рис.2).

1меноваш графи

Конструктор запит1в SPARQL

Предикати

Обмеження користувача

Типи даних

Операци

Рис. 2. Архитектура в1зуального засобу побудови запипв SPARQL до сховища триплелв

У рамках такого ршення користувач через веб-штерфейс вiзуального засобу побудови запита SPARQL отримуе доступ до перелшу iменованих графiв сховища триплетiв, вибiр з яких дасть можливiсть автоматично отримати шформащю про топологiю графа, а саме про його предикати i типи даних об'екпв, що може бути використано для формування пошуко-вого запиту шляхом встановлення користувальницьких обмежень (фiльтрiв) на даш, якi виводяться з сховища триплета.

Обмеження користувача визначимо як набiр правил з умовами виведення об'екпв iменованого графа, типи яких визначають семантику операцiй порiвняння, що застосову-ються. Як основу для умов виведення визначимо перелш операцiй, а саме «=» (дорiвнюе), «>» (бiльше), «<» (менше), якi можуть бути застосоваш до об'ектiв.

Семантика операцш «=», «>», «<» визначаеться типом об'екпв iменованого графа, тобто яким саме чином буде реагувати конструктор запита на символьш iмена операцш «=» «>» «<».

Для цiлочисельного типу об'екта (xsd: integer) операцп «=», «>», «<» мають такий сенс: «=» - порiвнюванi об'екти рiвнi;

«>» - об'ект, з яким проводиться порiвняння, бiльший порiвнюваного; «<» - об'ект, з яким проводиться порiвняння, менший порiвнюваного. Для рядкового типу (xsd: string) тд операщями «=», «>», «<» будемо розумгги таке: «=» - порiвнюванi об'екти рiвнi;

«>» - порiвнюваний об'ект е пiдрядком об'екта, з яким проводиться порiвняння; «<» - об'ект, з яким проводиться порiвняння, е тдрядком порiвнюваного. ДЦ «=», «>», «<» для об'ектiв типу «xsd: float» (число з плаваючою точкою) мають таку ж семантику, як i вiдповiднi операцп з цшочисловим типом об'ектiв.

Таким чином, користувач може формувати правила виводу вмюту того чи шшого iменованого графа сховища триплетiв. На основi отриманих правил може бути автоматично сформований типовий SPARQL-запит до сховища триплета, практичш аспекти створення якого розглянуп в роздiлi 3, а вщповщна формальна модель триплетiв i пов'язаних даних в цiлому представлена в роздш 2.

2. Формальна модель пов'язаних даних на 0CH0Bi часткововизначених схем Пов'язаш данi, як елемент концепцп LinkedData, формально можуть бути представлеш за допомогою формули:

t =< g, s, p, o >, (1)

де t - триплет; g - iменований граф; s - суб'ект; p - предикат; o - об'ект.

Сукупнють структур t, визначених формулою (1), будемо вважати сховищем даних:

T = {ti },i = (ГТП), (2)

тут ti - i-й триплет; n - кiлькiсть триплета у сховища

Враховуючи необхiднiсть використовувати для пошуку iнформацiю про контекст пов'язаних даних, будемо вважати, що вс ti, в яких g однакове, об'еднаш одним контекстом. Контекст визначимо такою формулою:

G={gj },j = am), (3)

де G - множина контекстiв сховища; gj - j-контекст сховища даних; m - кшьюсть контекстiв сховища.

Кожному контексту, зпдно з формулою (1), поставимо у вщповщнють трьохелементний набiр <s,p,o>. Таким чином, контекст визначимо за допомогою формули:

V g е G : g =< S,P,O >, (4)

тут g - контекст сховища даних; G- множина вшх контекстiв; S - множина суб'екпв; P-множина предикатiв; O - множина об' екпв. Розширимо поняття об'екта так:

V o е O : o =< T, L,V >, (5)

де T - тип даних; L - мова представлення; V - значення.

Враховуючи особливють концепцп LinkedData, а конкретно, необов'язковють визначен-ня схем, титв даних та мов, на яких представлеш значення об'екта О у випадку рядкового типу, будемо вважати елементи об'екта o необов'язковими для визначення, а схему об'екта, зпдно з формулою (5) будемо вважати часткововизначеною схемою пов'язаних даних, яю визначаються формулами (1)-(4).

Враховуючи, що на множинi G необхiдно виршувати пошуковi задачi, модифiкуемо формулу (4) шляхом введення допомiжного елемента - множини функцш, якi можуть виконуватись на множинах елеменпв контекстiв G:

V g е G : g =< S,P,O,F >, (6)

де g - контекст сховища даних; G - множина вшх контекстiв; S - множина суб'екпв; P - множина предикаив; O - множина об'ектiв; F - множина функцiй.

Практичнi аспекти реалiзацil функцiй F формули (6) покладемо на стороннiх розробниюв програмного забезпечення та наведемо приклади запипв на мовi SPARQL, на основi яких можуть бути реалiзованi функцп F, в наступному роздш.

Зауваження. Далi, якщо це не буде призводити до протирiччя, «контекст», Именований граф» будемо використовувати як синошми.

3. Практичнi аспекти peani3a^T пошукового iнтерфейсу до сховища трипле^в Формальна модель пов'язаних даних з часткововизначеними схемами (наведена на рис. 2) та архггектура веб-штерфейсу вiзуального засобу побудови запитiв SPARQL до сховища триплепв передбачають виконання набору зумовлених дш за допомогою SPARQL для динамiчного отримання топологи iменованого графа. До таких дiй вщносяться:

• отримання списку iменованих графiв;

• отримання списку предикатiв iменованого графа;

• отримання типу даних предиката.

Для отримання списку вшх наявних iменованих графiв у сховищi триплетiв можна використовувати такий запит на мовi SPARQL:

SELECT distinct ?G WHERE {

GRAPH ?G {?S ?P ?O}

}

Для отримання конкретного iменованого графа або групи, iм'я яких вiдповiдае деякому критерда, можна використовувати такий запит на мовi SPARQL:

SELECT distinct ?G WHERE

{

GRAPH ?G

{?S ?P ?O. Filter (regex (?G, <http://shcherbak.net/>)) }

}

де з перелiку всiх графiв обираються тi, у яких http://shcherbak.net/ зус^чаеться в iменi графа.

Для отримання списку предикаив в iменованому графi можна використовувати такий запит на мовi SPARQL: SELECT distinct ?P

FROM <http://shcherbak.net/User> {

?S ?P ?O

}

де з графа <http://shcherbak.net/User> будуть вибраш всi ушкальш предикати, якi повер-нутi у виглядi набору як результат вибiрки.

Для отримання типу предиката можна використовувати такий запит на мовi SPARQL:

SELECT datatype (?O)

FROM <http://shcherbak.net/User>

WHERE

{

?S ns: date_of_ birthday ?O }

де для предиката ns:date_of_birthday графа http://shcherbak.net/User буде отриманий тип об'екта.

На 0CH0Bi подiбних запинв можна будувати довiльнi запити на B^ipKy з iменованих графiв, наприклад:

sparql SELECT? s? p? o FROM <http://shcherbak.net/User> WHERE {? S? P? O FILTER (? S = ns: 2)

}

де з графа http://shcherbak.net/User будуть обраш триплети користувача ns:2. ^iM того, як обмеження користувача можуть виступати мовш теги (langtags). У цьому випадку, для виведення шформацп з графа http://shcherbak.net/User можна встановити фшьтр на вибiркy об'екпв росiйською мовою, у яких мовний тег встановлено у значення «ru»:

SELECT? Name? Second_name FROM <http://shcherbak.net/User> WHERE

{? S ns: name? Name. ? S ns: second_name? Second_name.

FILTER (? Name = '1ван' @ ru&&? Second_name = '1ванов' @ ru)

}

Для пошуку об'екта з урахуванням декшькох користувальницьких обмежень можна використовувати такий SPARQL-запит: PREFIX ns: <http://shcherbak.net/> SELECT? O

FROM <http://shcherbak.net/User> WHERE {? S ns: name? O FILTER regex (? O, "1ван", "i") FILTER regex (? O, "Петров", "i")

}

Реалiзацiя пошукового iнтерфейсy на основi наведених вище запитiв (рис.3) надае корис-тувачу допомiжнy iнформацiю, яка може значно полегшити процедуру складання запиту до сховища триплетiв i зменшити час його складання.

Рис. 3. Приклад пошукового штерфейсу Процедура складання запиту зводиться до вибору iменованих графiв, що представляють зацiкавленiсть в контекст пошуку, i накладення обмежень на предикати та значення виводяться в результат пошуку об'екпв.

Результати пошуку будуть згруповаш по приналежносп до деякого суб'екта в табличному виглядi (рис. 4). Таким чином, на сторош клieнта з множини триплета, отриманих у результат виконання запиту 8РАЯ0Ь на сторош сервера, компонуеться запис у зручному для читання виглядi.

Рис. 4. Приклад виведення результатiв пошуку в табличному поданш

Мова RDF дозволяе формувати дов1льно! складност графов1 структури для представ-лення даних, що складае як в обчислювальному плаш, так i в плаш ефективного використан-ня проблеми по оргашзаци взаемоди через iнтерфейс ODBC (англ. Open Database Connectivity) 3i сховищем триплетiв, тому розглянемо обмеження запропонованого ршення.

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

Обмеження дають можливiсть бiльш зручно! роботи зi сховищем триплетiв для розроб-никiв програмного забезпечення, що використовують у свош роботi реляцiйнi системи управлшня базами даних. Без врахування обмежень запропоноване ршення е працездат-ним, але реальний сенс генерацп даних як результатiв пошуку змшиться.

Для врахування обмежень на даш об'екти пропонуеться створювати iменованi графи на основi типових, запропонованих нижче, SPARQL запита.

Для створення iменованих графiв можна використовувати такий SPARQL-запит:

CREATE GRAPH <http://shcherbak.net/User> де створюеться граф користувача «http://shcherbak.net/User» в поточному сховищi трип-летiв.

Для додавання триплета в iменований граф можна використовувати наступний SPARQL-запит:

INSERT DATA INTO

<http://shcherbak.net/User>

{

ns: logl ns: login "userl". ns: logl ns: firstname "1ван". ns: logl ns: lastname "1ванович". ns: logl ns: grantname "1ванов".

}

Висновки

l. Запропоновано архiтектуру та наведено приклад реалiзацii вiзуальних засобiв побудо-ви запитiв SPARQL, орiентована на пiдвищення швидкостi введення запита та покращення якостi пошуку в сховищах даних, який дозволяе на основi часткововизначених схем об'ектiв проводити пошук даних.

2. Запропонована формальна модель пов'язаних даних на 0CH0Bi частково-визначених схем.

3. Отримала подальший розвиток модель процесу пошуку даних в розподшених середо-вищах на основi часткововизначених схем.

4. Запропоноваш технологiчнi рекомендацп щодо реалiзацil iнтерфейсiв користувача до сховищ триплетiв та 1х автоматичного формування.

5. Промислова значущють запропонованих моделей та технологш полягае у високш ринковiй привабливостi та защкавленосп компанiй в новiтнiх рiшеннях щодо тдвищення ефективностi пошукових засобiв семантичних додатюв.

6. Запропонована архiтектура ушверсального пошукового iнтерфейсу, яка забезпечуе вiзуальну побудову та виконання запитiв до сховищ триплетв на мовi SPARQL. Пюля виконання запиту користувач отримуе контекст з триплетами, що вщповщають потрiбним з урахуванням заданих обмежень на предикати i об'екти.

7. Практична реалiзацiя рiшення створена на мовi програмування PHP i пройшла устш-ну апробацiю на базi серверу OpenLinkVirtuoso.

Список лiтератури: 1. DuCbarme B. Learning SPARQL / B.DuCbarme. O'ReillyMedia: 2011. 258 c. 2.Powers S. Practical RDF / S. Powes. O'ReillyMedia: 2008. 352 c. 3. Бек К. Шаблоны реализации корпоративных приложений.: Пер. с англ. М. :ООО " И. Д. Вильямс", 2008. 176 с.

Надшшла до редколегИ 12.06.2012

Галушка 1лона Миколшвна, асистент кафедри 1УС КрНУ. Науковi iнтереси: iнтелектуальнi алгоритми, семантичнi додатки, iнтеграцiйнi процеси. Адреса: Украша, 39600, Кременчук, вул. Першотравнева, 20 , тел./факс: (05366) 3-60-00. E-mail: anoli@gmail.com. Завгороднш Валерш Вшторович, старший викладач кафедри ПЗС ДДТУ. Науковi iнтереси: iнтелектуальнi алгоритми, бази даних. Адреса: Украша, Дтпродзержинськ, вул.Дншробуд-iвська, 2, тел. (0569) 55-13-89.E-mail: valera_ddtu@i.ua.

Солошич Сергш Миколайович, аспiрант кафедри 1УС КрНУ. Науковi iнтереси: iнтелекту-альнi алгоритми. Адреса: Украша, 39600, Кременчук, вул. Першотравнева, 20 , тел./факс: (05366) 3-60-00. E-mail: soloshich@gmail.com.

Щербак Сергш Сергшович, доцент кафедри 1УС КрНУ, канд. техн. наук, доцент, с.н.с. Науковi iнтереси: iнтелектуальнi алгоритми, семантичнi додатки, агентш технологй. Адреса: Укра!на, 39600, Кременчук, вул. Першотравнева, 20, тел./факс: (05366) 3-60-00.E-mail: sergey.shcherbak@gmail.com. www: http://щербак.net.

УДК 681.5+548.55

А.П. ОКСАНИЧ, С.Э. ПРИТЧИН, В.В. МАЛЁВАНЫЙ

РАЗРАБОТКА МАТЕМАТИЧЕСКОЙ МОДЕЛИ И УСТРОЙСТВА АВТОМАТИЧЕСКОГО КОНТРОЛЯ И ПОДДЕРЖАНИЯ ДИАМЕТРА СЛИТКОВ ГЕРМАНИЯ ВЫРАЩИВАЕМЫХ ПО МЕТОДУ ЧОХРАЛЬСКОГО

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

1. Введение

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