Defining and resolving Web-services discovery problems using description logics formalism
Now Web-services allow to solve the business-problems that realize business-processes in different areas of human activities. But it is necessary to solve a lot of problems of Web-services on all stages of their life cycle to obtain executed Web-service. Description logics formalism is the effective...
Збережено в:
| Дата: | 2018 |
|---|---|
| Автор: | |
| Формат: | Стаття |
| Мова: | Ukrainian |
| Опубліковано: |
Інститут програмних систем НАН України
2018
|
| Теми: | |
| Онлайн доступ: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/311 |
| Теги: |
Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Репозитарії
Problems in programming| id |
pp_isofts_kiev_ua-article-311 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/f1/14b4e6b7ea2a98d3908459170f5d5bf1.pdf |
| spelling |
pp_isofts_kiev_ua-article-3112024-04-28T11:45:31Z Defining and resolving Web-services discovery problems using description logics formalism Определение и решение задачи по-иска Веб-сервисов с использованием аппарата дескриптивных логик Визначення та вирішення задачі виявлення Веб-сервісів за допомогою апарату дескриптивних логік Zakharova, O.V. semantic Web-service; description logics; discovery task; web-service search; web-services composition; semantic description; domain ontology; service ontology UDC 004.94 семантический Веб-сервис; дескриптивная логика; задача поиска; поиск веб-сервиса; композиция веб-сервисов; семантическое описание; онтология домена; онтология сервиса УДК 004.94 семантичний Веб-сервіс; дескриптивна логіка; задача виявлення; пошук веб-сервісу; композиція веб-сервісів; семантичний опис; онтологія домену; онтологія сервісу УДК 004.94 Now Web-services allow to solve the business-problems that realize business-processes in different areas of human activities. But it is necessary to solve a lot of problems of Web-services on all stages of their life cycle to obtain executed Web-service. Description logics formalism is the effective and powerful tool to solve problems of Web–services due to its reasoners and abilities of logical inference and giving semantics to descriptions. Goal of this research is to define Web-services tasks chain on functional level and to find approaches for their resolving with description logics formalisms.Problems in programming 2017; 4: 066-078 В настоящее время Веб-сервисы позволяют решать конкретные бизнес-задачи, реализующие бизнес процессы в разных сферах жизнедеятельности человека. Но для того, чтоб получить выполняемый Веб-сервис, необходимо уметь эффективно решать целое множество задач самих Веб-сервисов на всех этапах их жизненного цикла. Аппарат дескриптивных логик, благодаря своим механизмам суждений и возможностям логического вывода и придания описаниям семантического содержания, является эффективным и мощным инструментом для решения задач Веб-сервисов. Цель данной работы заключается в определении цепочки задач Веб-сервисов на функциональном уровне и подходов к их решению с использованием аппарата дескриптивных логик.Problems in programming 2017; 4: 066-078 На сьогодні Веб-сервіси дозволяють вирішувати конкретні бізнес-задачі, що реалізують бізнес процеси у різних галузях життєдіяльності людини. Але для того, щоб отримати виконуваний Веб-сервіс, треба вміти ефективно вирішувати цілу низьку задач самих Веб-сервісів на всіх етапах їх життєвого циклу. Апарат дескриптивних логік, завдяки своїм механізмам міркувань та можливостям логічного виводу та надання описам семантичного змісту, є ефективним та потужним інструментом для вирішення задач Веб-сервісів. Мета данної роботи полягає у визначенні ланцюжка задач Веб-сервісів на функціональному рівні та підходів до вирішення цих задач із застосуванням апарата дескриптивних логік.Problems in programming 2017; 4: 066-078 Інститут програмних систем НАН України 2018-11-15 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/311 10.15407/pp2017.04.066 PROBLEMS IN PROGRAMMING; No 4 (2017); 66-78 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2017); 66-78 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2017); 66-78 1727-4907 10.15407/pp2017.04 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/311/306 Copyright (c) 2018 PROBLEMS OF PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2024-04-28T11:45:31Z |
| collection |
OJS |
| language |
Ukrainian |
| topic |
semantic Web-service description logics discovery task web-service search web-services composition semantic description domain ontology service ontology UDC 004.94 |
| spellingShingle |
semantic Web-service description logics discovery task web-service search web-services composition semantic description domain ontology service ontology UDC 004.94 Zakharova, O.V. Defining and resolving Web-services discovery problems using description logics formalism |
| topic_facet |
semantic Web-service description logics discovery task web-service search web-services composition semantic description domain ontology service ontology UDC 004.94 семантический Веб-сервис дескриптивная логика задача поиска поиск веб-сервиса композиция веб-сервисов семантическое описание онтология домена онтология сервиса УДК 004.94 семантичний Веб-сервіс дескриптивна логіка задача виявлення пошук веб-сервісу композиція веб-сервісів семантичний опис онтологія домену онтологія сервісу УДК 004.94 |
| format |
Article |
| author |
Zakharova, O.V. |
| author_facet |
Zakharova, O.V. |
| author_sort |
Zakharova, O.V. |
| title |
Defining and resolving Web-services discovery problems using description logics formalism |
| title_short |
Defining and resolving Web-services discovery problems using description logics formalism |
| title_full |
Defining and resolving Web-services discovery problems using description logics formalism |
| title_fullStr |
Defining and resolving Web-services discovery problems using description logics formalism |
| title_full_unstemmed |
Defining and resolving Web-services discovery problems using description logics formalism |
| title_sort |
defining and resolving web-services discovery problems using description logics formalism |
| title_alt |
Определение и решение задачи по-иска Веб-сервисов с использованием аппарата дескриптивных логик Визначення та вирішення задачі виявлення Веб-сервісів за допомогою апарату дескриптивних логік |
| description |
Now Web-services allow to solve the business-problems that realize business-processes in different areas of human activities. But it is necessary to solve a lot of problems of Web-services on all stages of their life cycle to obtain executed Web-service. Description logics formalism is the effective and powerful tool to solve problems of Web–services due to its reasoners and abilities of logical inference and giving semantics to descriptions. Goal of this research is to define Web-services tasks chain on functional level and to find approaches for their resolving with description logics formalisms.Problems in programming 2017; 4: 066-078 |
| publisher |
Інститут програмних систем НАН України |
| publishDate |
2018 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/311 |
| work_keys_str_mv |
AT zakharovaov definingandresolvingwebservicesdiscoveryproblemsusingdescriptionlogicsformalism AT zakharovaov opredelenieirešeniezadačipoiskavebservisovsispolʹzovaniemapparatadeskriptivnyhlogik AT zakharovaov viznačennâtaviríšennâzadačíviâvlennâvebservísívzadopomogoûaparatudeskriptivnihlogík |
| first_indexed |
2024-09-16T04:07:48Z |
| last_indexed |
2024-09-16T04:07:48Z |
| _version_ |
1818568249538772992 |
| fulltext |
Експертні та інтелектуальні інформаційні системи
© О.В. Захарова, 2017
66 ISSN 1727-4907. Проблеми програмування. 2017. № 4
УДК 004.94
О. Захарова
ВИЗНАЧЕННЯ ТА ВИРІШЕННЯ ЗАДАЧІ ВИЯВЛЕННЯ
ВЕБ-СЕРВІСІВ ЗА ДОПОМОГОЮ АПАРАТУ
ДЕСКРИПТИВНИХ ЛОГІК
На сьогодні Веб-сервіси дозволяють вирішувати конкретні бізнес-задачі, що реалізують бізнес процеси
у різних галузях життєдіяльності людини. Але для того, щоб отримати виконуваний Веб-сервіс, треба
вміти ефективно вирішувати цілу низьку задач самих Веб-сервісів на всіх етапах їх життєвого циклу.
Апарат дескриптивних логік, завдяки своїм механізмам міркувань та можливостям логічного виводу та
надання описам семантичного змісту, є ефективним та потужним інструментом для вирішення задач
Веб-сервісів. Мета данної роботи полягає у визначенні ланцюжка задач Веб-сервісів на функціональ-
ному рівні та підходів до вирішення цих задач із застосуванням апарата дескриптивних логік.
Ключові слова: семантичний Веб-сервіс, дескриптивна логіка, задача виявлення, пошук веб-сервісу,
композиція веб-сервісів, семантичний опис, онтологія домену, онтологія сервісу.
Вступ
Згідно визначення W3C [1–5], під
сервісом розуміють таку програмну систе-
му, що ідентифікується URI, публічні ін-
терфейси, прив'язки якої визначені та опи-
сані мовою XML. Опис цієї програмної
системи може бути знайдено іншими про-
грамними системами, які можуть взаємо-
діяти з нею відповідно до цього опису з
використанням повідомлень, що базуються
на XML та передаються за допомогою Ін-
тернет-Протоколів. Веб-сервіси базуються
на чотирьох ключових технологіях [5–7]:
eXtensible Markup Language (XML), Simple
Object Access Protocol (SOAP), Web Servi-
ces Description Language (WSDL) та Uni-
versal Description, Discovery and Integration
(UDDI). Ці технології використовуються
для забезпечення функціонування Веб-сер-
вісів.
Хоча Веб-сервіси базуються на ши-
роко прийнятих стандартах, відсутність
формального опису значень їх функціо-
нальності та обміну даних є значною пере-
шкодою у реалізації інтеграціонних пер-
спектив. Так як кількість Веб-сервісів зро-
стає, важливо мати автоматизовані засоби
для виявлення та композиції Веб-сервісів.
Ступінь опису, що є доступною в іс-
нуючому стандарті WSDL, залишає місце
для неоднозначних інтерпретацій функціо-
нальності та даних Веб-сервісів. Неодно-
значність інтерпретації ускладнює автома-
тизацію таких задач, як виявлення, компо-
зиція, виклик сервісу тощо. Семантичні
описи таких Веб-сервісів відкривають
шлях до автоматизації їх композиції.
На практиці існує два рівні пред-
ставлення сервісів, а саме: функціональна
та процесна модель сервісів [8]. На функ-
ціональному рівні сервіси розглядаються
як окремі існуючі в мережі прикладні ком-
поненти, які можуть бути викликані шля-
хом відправлення повідомлення. При цьо-
му сервіс виконує свою задачу та (в деяких
випадках) виробляє відповідь тому, хто
його викликав. Таким чином, відсутня без-
перервна взаємодія між запитувачем серві-
су та самим сервісом. Опис таких Веб-сер-
вісів фокусується на їх функціональності в
термінах імені сервіса, імен операцій, імен
повідомлень (що відомі також як вхідні та
вихідні повідомлення/параметри), імені
інтерфейсу.
Сервіси процесного рівня містять
декілька операцій, які слідують загальній
поведінці сервіса. Такі сервіси потребують
розширеної взаємодії між запитувачем сер-
вісу та множиною операцій, забезпечуючи
конкретну функціональність. Таким чи-
ном, це, як правило, композитні сервіси,
тобто взаємодія з ними складається не ли-
ше з окремого крока запит-відповідь, для
досягнення потрібного результату вони по-
винні слідувати складному протоколу. Ці
кроки можуть складатися з довільних
(умовних та ітеративних) комбінацій з
http://uk.wikipedia.org/wiki/URI
http://uk.wikipedia.org/wiki/%D0%86%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81
http://uk.wikipedia.org/wiki/%D0%86%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81
http://uk.wikipedia.org/wiki/XML
http://uk.wikipedia.org/wiki/XML
http://uk.wikipedia.org/wiki/%D0%86%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB
http://uk.wikipedia.org/wiki/%D0%86%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB
Експертні та інтелектуальні інформаційні системи
67
умовними виходами. На цьому рівні необ-
хідний деталізований опис внутрішньої
поведінки сервісів, наприклад, за допомо-
гою (STS). Очевидно, що на процесному
рівні Веб-сервіси також мають фун-
кціональний опис своїх операцій та сер-
вісів. Але сервіси на функціональному рів-
ні не мають поведінкових взаємодій. Це є
головною відмінністю цих двох моделей.
Предметом розгляду данної статті є
вирішення задачі виявлення для онтологіч-
но анотованих Веб-сервісів, що представ-
лені функціональною моделлю, із застосу-
ванням апарату дескриптивної логіки (ДЛ).
Визначення семантичного
Веб-сервісу
ДЛ – формальна мова, яка підтри-
мує концепцію відкритого світу та власні
механізми міркувань. Все це робить її ба-
жаною та ефективною як для представлен-
ня функціональної частини опису Веб-сер-
вісу, так і для представлення семантичних
елементів (анотацій) у процедурному описі
Веб-сервісу. А така властивість ДЛ, як під-
тримка можливостей логічного виведення,
забезпечує ефективність вирішення бага-
тьох задач Веб-сервісів, як елементів за-
гальної складної задачі композиції. Так,
наприклад, при анотуванні сервісу може
виникнути потреба у розширенні загальної
онтології домена чи онтології домена кон-
кретного сервісу. Резонери ДЛ дозволять
перевірити коректність доданих аксіом. Це
зводиться до стандартної задачі виконува-
ності, що вирішується для цих аксіом.
Онтологія домена
Відповідно до понять ДЛ [5], в ме-
жах загальноприйнятої онтології існує тер-
мінологічний компонент (Т-BOX) [6] і
стверджувальний (assertional) компонент
(A-BOX). Вважаємо, що T-BOX є єдиним
для всіх сервісів, які необхідно анотувати в
домені. Він містить всі концепти, які необ-
хідно представляти в домені застосування.
Якщо анотації винести до окремого файлу
(із посиланнями на файл процесу), то це
дозволить глобальні твердження, які дійсні
для всіх станів процесу, а саме твердження
T-BOX, не повторювати в описі кожного
стану процесу, а визначити однократно у
відповідному розділі файлу анотацій. A-
BOX містить визначення твердження двох
різних типів: твердження концептів та тве-
рдження ролі. З кожним станом кожного
сервісу пов’язується свій А-BOX. Він опи-
сує наслідки даної дії в термінах твер-
джень концепту і ролі. Тим не менш, є де-
які твердження, які не залежать від будь-
яких дій, але виконуються скрізь. Такі тве-
рдження завжди є правильними.
Розглянемо як приклад задачу бро-
нювання квітків на літак. Призначення
сервісу – визначити прийнятний до запиту
користувача рейс. Входами сервісу є ім’я
клієнта, дата відправлення, пункт від-
правлення та призначення. Виходом є кві-
ток на літак. Онтологія домена буде опи-
сана засобами ДЛ. Анотації входів, ви-
ходів, передумов та ефектів сервісу є ак-
сіомами визначення або аксіомами вклю-
чення ДЛ. У WSDL-описі сервісу вони бу-
дуть представлені посиланнями на концеп-
ти онтології домену POOntology.
Спочатку продемонструємо вико-
ристання апарату ДЛ для визначення онто-
логії домену POOntology. Для цього необ-
хідно визначити TBox та ABox ПО.
Відповідний узагальнений TBox мо-
же містити такі твердження: Year, Month,
Day, Date, Client, Status, Location, Country,
FlightID
Date ⊑ has.Year;
Date ⊑ has.Month;
Date ⊑ has.Day;
Location⊑ isLocatedIn. Country; Trip ⊑
hasStartPoint. Location;
Trip ⊑ hasEndPoint. Location; Trip ⊑
hasDeparture.Date
Trip ⊑ hasArrival.Date; Flight⊑
belonguesTo.AirLineRoute
Flight ⊑ hasDeparturDate.Date; Flight ⊑
hasDeparturTime.Time
Flight ⊑ from.Location; Flight ⊑ to.Location
Flight⊑ hasSeats.NUMBER; Flight⊑
hasStatus.Status;
Експертні та інтелектуальні інформаційні системи
68
Status = {Available, NotAvailable, booked}
Роль hasStatus, що зв’язує два кон-
цепти Flight та Status, фіксує поточний
стан запиту клієнта і може приймати на-
ступні значення: Available – якщо поїздка
доступна; NotAvailable – коли поїздка не
доступна, booked – квиток заброньований.
Додамо передумову до нашого сер-
вісу. Припустимо, що сервіс виконується
лише при бронювання квитків до країн Єв-
ропи. Ефектом є бронювання квитка на лі-
так. Визначимо відповідні умови у TBox,
щоб уможливити їх використання. Для
цього додамо до TBox концепт Europe, а
до ABox множину індивидів, які будуть
визначати цей клас.
Europe
Ukraine:Europe, France:Europe,
Italy:Europe, Lituva:Europe,
Hungary:Europe, etc.
EuropeanTrip⊑ hasStartPoint Europe ⊓
hasEndPoint Europe
FlightBooked ≡ hasStatus.{booked}
EuropeanTrip ⊑ Trip
Семантичне анотування сервісу на
функціональному рівні
Для вирішення задач Веб-сервісів їх
опис має спиратися на існуючі стандарти.
Функціональна модель сервісу (його про-
філі), що зберігаються в UDDI, ви-
значаються у WSDL, а семантизованих
Веб-сервісів, опис яких розширений анота-
ціями, у розширені WSDL, як, наприклад
WSDL-S або ASWSDL.
WSDL-S представлення сервісу, що
описаний у прикладі, може мати наступ-
ний вигляд:
<?xml version="1.0" encoding="iso-
8859-1"?>
<definitions name="
flightTicket"
targetNamespace=http://lsdis.cs
.uga.edu/projects/meteor-
s/wsdl-
s/examples/flightTicket.wsdl
xmlns="http://www.w3.org/2004/0
8/wsdl"
xmlns:tns=http://lsdis.cs.uga.e
du/projects/meteor-s/wsdl-
s/examples/flightTicket.wsdl
xmlns:xs="http://www.w3.org/200
1/XMLSchema"
xmlns:xsd1="http://lsdis.cs.uga
.edu/projects/wsdl-
s/examples/flightTicket.wsdl"
xmlns:wssem="http://lsdis.cs.ug
a.edu/projects/wsdl-
s/examples/flightTicket.wsdl"
xmlns:Flight="http://lsdis.cs.u
ga.edu/projects/wsdl-
s/ontologies/POOntology">
<--опис типів -->
<types>
<xs:import
namespace=http://lsdis.cs.uga.e
du/projects/wsdl-
s/examples/flightTicket.wsdl
schemaLocation="http://lsdis.cs
.uga.edu/projects/wsdl-
s/examples/WSSemantics.xsd"/>
<xs:schema
xmlns:xs="http://www.w3.org/200
1/XMLSchema"
targetNamespace=http://lsdis.cs
.uga.edu/projects/wsdl-
s/examples/flightTicket.wsdl
xmlns="http://lsdis.cs.uga.edu/
projects/wsdl-
s/examples/flightTicket.wsdl">
<!--Semantic annotation is
added directly to leaf element
-->
<xs:complexType
name="processflightTicketReques
t">
<xs:all>
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/wsdl-s/examples/flightTicket.wsdl
http://lsdis.cs.uga.edu/projects/wsdl-s/examples/flightTicket.wsdl
Експертні та інтелектуальні інформаційні системи
69
<xs:element
name="locationToInf
o" type="xs:string"
wssem:modelReferenc
e="POOntology#Locat
ion />
<xs:element
name="locationFromInfo"
type="xsd1:string"/>
<xs:element
name="dateitem"
type="xs:date"
wssem:modelReferenc
e="POOntology#Date
/>
<xs:element
name="ClientInfo"
type="xs:string"
wssem:modelReferenc
e="POOntology#Clien
t />
</xs:all>
</xs:complexType>
<!--Semantic annotation is
added directly to leaf element
-->
<xs:element
name="processflightTicketRespon
se" type="xs:string"
wssem:modelReference="POOntolog
y#Flight"/>
</xs:schema>
</types>
<interface
name="PurchaseOrder">
<operation
name="processflightTicket"
pattern="wsdl:in-out">
<input
messageLabel
="processflightTicketRequest"
element="tns:processflightTicke
tRequest"/>
<output
messageLabel
="processflightTicketResponse"
element="
processflightTicketResponse"/>
<!--Precondition and
effect are added as extensible
elements on an operation-->
<wssem:precondition
name="ExistingLocationsPrecond"
wssem:modelReference="POOntolog
y#LocationsExist"/>
<wssem:effect
name="FlightBookedEffect"
wssem:modelReference="POOntolog
y#flightBooked"/>
</operation>
</interface>
</definitions>
У WSDL-S, як і у більшості фор-
мальних мов, зв’язок з онтологією домена
POOntology здійснюється за допомогою
використання простору імен. Використан-
ня конкретних концептів онтологій у се-
мантичних описах вхідних та вихідних па-
раметрів, перед- та пост-умов досягається
використанням префіксу з ім’ям онтології
перед назвою концепта. Наприклад, конст-
рукція <xs:element name="locationToInfo"
type="xs:string" wssem:modelReference=
"POOntology#Location /> вказує, що еле-
мент locationToInfo є екземпляром конце-
пта Location онтології POOntology. Зв’язок
онтологій між собою, наприклад, онтології
конкретного сервісу та онтології сервісу
верхнього рівня, або (та) онтології домену
прикладної області, досягається шляхом
інтеграції онтологій. Побудова інтегрова-
ної онтології може здійснюватися за допо-
могою застосування різноманітних опера-
цій маніпуляції онтологіями, таких як ві-
дображення, узгодження, уточнення, пого-
Експертні та інтелектуальні інформаційні системи
70
дження онтології та інше, а також шляхом
застосування до онтологій операцій алге-
бри онтологій. Ці питання були досліджені
та викладені у [7].
Вирішення задачі
автоматизованого виявлення
семантичних Веб-сервісів
Загальні вимоги до алгоритму
співставлення. Щоб знайти Веб-сервіси
для виконання конкретних задач в бізнес-
процесі, запитувач має, перш за все, ви-
значити умови, які повинен задовільняти
цей Веб-сервіс. Такий підхід називається
співставлення на основі цілі (goal based
matchmaking) [8, 9] та має справу з визна-
ченням умов на оголошення Веб-сервісу та
перевіркою, чи може Веб-сервіс задовіль-
няти ці умови. Цілі, як правило, слідують з
бізнес-цілей, та можуть виводитись з них
автоматично або не автоматично.
Опис чи оголошення сервісу відпо-
відає запиту, якщо запит є досить близь-
ким до сервісу, що запитується. Тут необ-
хідно специфікувати, що означає «досить
близький». У найсуворішій інтерпретації,
оголошення та запит є «досить близьки-
ми», якщо вони описують точно один і той
самий сервіс. Але це визначення є занадто
обмеженим. Потрібно більш гнучке визна-
чення поняття «достатньої близькості».
Тобто, необхідні механізми співставлення,
які розпізнають ступінь подібності між
оголошеннями сервісів та запитами. А в
того, хто запитує сервіс, має бути можли-
вість визначати ступінь гнучкості, яку во-
ни надають системі. Чим менша гнучкість,
тим менша вірогідність знаходження сер-
вісів, що задовільняють вимогам.
Таким чином:
механізм співставлення має під-
тримувати гнучке семантичне співставлен-
ня між оголошеннями сервісів та запитами
на основі онтологій, що доступні сервісам
та механізму співставлення;
запитувач має володіти деяким
контролем ступеня гнучкості співстав-
лення, що дозволяється системі;
механізм співставлення має за-
охочувати обидві сторони бути чесними у
своїх описах у питаннях вартості;
процес співставлення має бути
ефективним: він не повинен навантажува-
ти запитувача надмірними затримками, які
перешкоджатимуть його ефективності.
Алгоритми співставлення взагалі є
ключовим питанням в області досліджень
Веб-сервісів, та є основою вирішення не
лише задачі виявлення сервісів, але й їх ав-
томатизованої композиції. У загальному
випадку, співставлення (matchmaking) Веб-
сервісів містить у собі співставлення IOPE
описів (співставлення за входами, вихода-
ми, передумовами, та ефектами). Дійсно,
входи, виходи, передумови та ефекти утво-
рюють опис функціональних можливостей
сервісу. Наочно, IO надають синтаксичну
інформацію про Веб-сервіси, тоді як PE –
відображають їх семантику. Метод, який
використовується у співставленні входів-
виходів відрізняється від того, що ви-
користовується для передумов та ефектів.
Та семантики, які відображаються входа-
ми-виходами й передумовами та ефектами
також різні. На сьогодні досягнуто знач-
них результатів у співставленні Веб-сер-
вісів за входами-виходами, але відсутній
ефективний підхід щодо співставлення пе-
ред-умов та ефектів. У роботі [10] наво-
диться алгоритм PE спіставлення, на осно-
ві формалізма ДЛ SHOIN+(D).
Безперечна доцільність використан-
ня апарату ДЛ для вирішення багатьох за-
дач Веб-сервісів обумовлена тим, що сис-
теми ДЛ забезпечують користувачів різни-
ми механізмами виводу, які виводять не-
явні знання з тих, що явно представлені, та
більше того, на сьогодні існує вже чимало
реалізованих механізмів міркувань (резо-
нерів) ДЛ, що готові до використання.
Але, варто пам’ятати, що окремою склад-
ною задачею залишається вибір такої ДЛ,
що є компромисним рішенням між її вира-
зністю та розв’язуваністю.
Далі пропонується алгоритм вияв-
лення Веб-сервісів на основі ДЛ, який
адоптує множину стратегій. Задача вияв-
лення полягає у знаходженні всіх Веб-сер-
вісів, що задовільняють запиту. Іншими
словами, це можна назвати фільтрацією
множини сервісів у репозиторії за запитом.
Тобто оголошення кожного сервісу спів-
ставляють із запитом. При чому запит та-
Експертні та інтелектуальні інформаційні системи
71
кож є своєрідним оголошенням сервісу, а
саме, того сервісу, який реалізує потрібну
користувачеві функціональність. Таким
чином, відношення між запитом та оголо-
шенням сервісу ідентичні відношенням
між оголошеннями двох сервісів.
Критерій та ступені відповідності
Спочатку розглянемо задачу вияв-
лення для сервісів, що задаються лише
входами-виходами. Основу вирішення та-
кої задачі становить встановлення IO-від-
повідності (Input-Output).
Вважаємо, що оголошення сервісу
відповідає запиту, якщо всі виходи запиту
співпадають з виходами оголошення, а всі
входи оголошення співпадають зі входами
запиту. Точне співпадання знайти досить
важко, тому визначають ступені відповід-
ності і обирають сервіси з найбільшим сту-
пенем відповідності. Базовий критерій ви-
явлення полягає у тому, що сервіс має
задовільняти потреби запитувача, а запиту-
вач має забезпечувати сервісу всі входи,
які необхідні для його коректного функці-
онування.
Критерій відповідності. Якщо 𝓣 –
ациклічний Tbox ДЛ ℒ, ) ,(=S ss OutIn –
сервіс та ) ,(= qq OutInQ – запит, де:
qIn – кінцева множина входів
запиту,
sIn – кінцева множина входів
оголошення сервісу,
qOut – кінцева множина вихо-
дів запиту,
sOut – кінцева множина вихо-
дів оголошення сервісу, що виражені твер-
дженнями 𝓛, то відповідність сервісу запи-
ту гарантується включеннями qs InIn та
sq OutOut .
Таким чином, сервіс відповідає за-
питу, якщо запит містить всі вхідні твер-
дження сервісу та, можливо, ще додаткові,
а множина вихідних тверджень запиту,
навпаки, має бути вужча за множину вихі-
дних тверджень сервісу, тобто сервіс може
повертати більше ефектів ніж того потре-
бує запит.
Запити співставляються за цим
критерієм з усіма оголошеннями сервісів,
які є у реєстрі. Як тільки знайдена відпо-
відність запиту та оголошення, вона запи-
сується, щоб знайти відповідність більш
високого ступеня. Ступінь успіху зале-
жить від його виявленого співпадання.
Ступінь відповідності між двома входами
або двома виходами залежить від відно-
шення між концептами, які пов’язані з
цими входами або виходами, а саме, міні-
мальною відстаню між цими поняттями у
дереві таксономії. Розрізняють такі сту-
пені відповідності [11, 12]:
Exact – точне співпадання:
o sq OutOut – еквівалентність,
або
o sq OutsubclassOfOut – резуль-
тат точний у припущенні, що оголошуючи
Outs провайдер сервісу повинен за-
безпечити виходи, що погоджені з кожним
безпосереднім підтипом sOut .
InPlug – більш слабкий зв’язок
)( qs OutsubsumesOut . Якщо sOut
qOutsubsumes , то sOut – це множина, яка
включає виходи qOut , або іншими слова-
ми, sOut може бути підключений замість
qOut .
Subsumes )( sq OutsubsumesOut –
якщо sq OutsubsumesOut , то провайдер не
повністю задовільняє запит. Це означає,
що запитувач може використовувати про-
вайдера для досягнення своєї мети, але
йомовірно йому прийдеться модифікувати
свій план або виконати інші запити, щоб
завершити свою задачу.
Fail – невдача, не знайдено будь-
якого nsubsumptio між qOut та sOut .
Ступінь відповідності відобража-
ється на дискретній шкалі, де найбільш пе-
реважним є точна відповідність (Exact), на-
ступний рівень – Plug In, так як вихід, що
повертається, може бути використаний за-
мість того, що очікує запитувач. Subsumes
– третій рівень, так як вимоги запитувача
виконуються лише частково: оголошений
сервіс може забезпечити лише деякі кон-
кретні варіанти того, що бажає запитувач.
Експертні та інтелектуальні інформаційні системи
72
Самий низький рівень Fail – не прийнят-
ний результат. Ці значення дозволяють
ранжувати знайдені сервіси за ступенем
відповідності запиту. Обираються сервіси
з найбільшим ступенем відповідності ви-
ходів. Співставлення входів використову-
ється лише як допоміжна (вторинна) оцін-
ка, щоб розмежувати еквівалентно оцінені
виходи.
Функціональна (IOPE) модель сер-
вісу у загальному випадку буде мати ви-
гляд:
);;;({ COOICIssS , (1)
де CI – передумови сервісу, I – список
вхідних параметрів, O – список вихідних
параметрів та CO – після-умови.
Запит сервісу [13], в цьому випад-
ку, розширюється та визначається як
),;;;( OCOIICQ (2)
де IC – передумови, I – список вхідних
параметрів, O – список вихідних параме-
трів та OC – після-умови. Всі ці елементи
є параметрами сервісу, що запитується.
Валідні рішення щодо запиту, у да-
ному випадку, мають задовільняти наступ-
ним умовам:
(i) вони мають виробляти хоча б
один вихідний параметр запиту;
(ii) вони мають використовувати
вхідні параметри тільки з наданого списку
вхідних параметрів та задовільняти перед-
умови запиту;
(iiі) вони мають виробляти ефекти
запиту.
Деякі рішення можуть бути занадто
обмеженими, але вони розглядаються як
дійсні, якщо задовільняють вимогам вхід-
них та вихідних параметрів, перед/після
умов та ефектів.
Окрім IOPE атрибутів, співставля-
тися можуть і категорії сервісів, і додатко-
ві параметри сервісів, як наприклад, не
функціональні характеристики. В такому
випадку, мова йде про багаторівневе спів-
ставлення. Значення ступеней відповідно-
сті на різних рівнях мають різну вагу. Ре-
зультуюче значення є агрегацією багато-
рівневих зважених оцінок.
Запитувач може вирішити будь-які
невідповідності шляхом вирішення додат-
кової задачі або шляхом запиту до реєстру,
щоб знайти додаткових провайдерів.
Розглянемо задачу виявлення на
прикладі бронювання авіаквітків. Тобто
треба знайти сервіс бронювання квитків на
літак, директорія сервісів містить сервіси
1S та 2S (таблиця далі).
Таблиця
Сервіс 1S має вхідні параметри
StartL, DestinationL, DateFrom, DateTo,
CCNumber та вихідні параметри Status,
Flight. Для його виконання задана перед-
умова LocationExist. Сервіс 2S має вхідні
параметри StartL, DestinationL, Dt,
CCNumber, та вихідні параметри Status,
Flight, TrNumber та для його виконання за-
дана передумова CorrectCard. Для пошуку
сервісу бронювання квитків заданий запит
зі вхідними параметрами Start,
Destination, Date, CCNumber, вихідними
Сер
віс
Входи
Перед-
умови
Вихо-
ди
Піс-
ля-
умови
1S StartL,
Destina-
tionL,
Date-
From,
DateTo,
CCNum-
ber
Location
Exist
status,
Offer
-
2S StartL,
Dt,
Destina-
tionL,
CCNum-
ber
Correct-
Card
status,
Offer,
TrNum
ber
-
За-
пит
-
Q
Start, Dt,
Destina-
tion,
CCNum-
ber
Correct-
Card
-
Експертні та інтелектуальні інформаційні системи
73
параметрами Status, Flight та передумовою
на номер кредитної картки CorrectCard.
Семантичні описи вхідних та вихід-
них параметрів сервісу мають бути такі
самі як для параметрів запиту або мати
відношення subsumption. Механізм вияв-
лення повинен мати можливість вивести
той факт, що параметри запиту Start,
Destination та вхідні параметри StartL,
DestinationL сервісів семантично одні й ті
самі концепти. Це може бути виведено, ви-
користовуючи семантики онтології доме-
на. (При цьому припускаємо, що сервіси та
запит спираються на єдину інтегровану он-
тологію домену.) Запит також має перед-
умову на CCNumber, яке повинно мати
числове значення, що логічно має означати
передумову сервісу, який шукається.
Визначення задачі виявлення. За-
даний репозиторій 𝓡 (3) та запит 𝓠 (4),
задача виявлення може бути визначена як
автоматичне знаходження множини серві-
сів S з репозиторію 𝓡 таких, Rs , та
I ⊑ I , AA = , OAO = A , O ⊒ O}, та
існує така інтерпретація ℐ, що 𝐶𝐼’ℐ ⊆ 𝐶𝐼ℐ,
𝐶𝑂ℐ ⊆ 𝐶𝑂’ℐ, де ⊑ – означає відношення
включення (subsumes). Слід зазначити, що
в даному випадку IC , CI , I , I , A , A ,
AO , OA , CO, OC , O, O – це кінцеві
множини вхідних/вихідних параметрів,
перед- та пост-умов. Операції включення,
що наведені в цьому визначенні, це опера-
ції на цих множинах.
Задача виявлення графічно поясню-
ється на рисунку.
Де 𝐶𝐼’ℐ ⊆ 𝐶𝐼ℐ, 𝐶𝑂ℐ ⊆ 𝐶𝑂’ℐ,
I’⊒ I, O ⊒ O’
Рисунок. Задача виявлення
Визначення сервісу та запиту за
допомогою ДЛ-онтологій. ДЛ [14] дозво-
ляють представити домен, що нас ціка-
вить, у термінах концептів або описів
(унарні предикати), що характеризують
підмножини об’єктів (екземплярів) в до-
мені, та ролей (бінарні предикати) на та-
кому домені. Концепти визначаються ви-
разами, які формуються за допомогою
спеціальних конструкторів [14]: верхній
концепт (⊤), нижній концепт (⊥),
кон’юнкція концептів (⊓), універсальний
кваліфікатор (∀R.C), числові обмеження (≥
nR) та (≤ nR) (для різних ДЛ цей набір
конструкторів різниться).
Онтологія домену для наведеного
прикладу була предствлена вище. Для опи-
су наших сервісів, доповнимо TBox онто-
логії POOntology декількома концептами
та твердженнями. Додамо до онтології
концепти: Operation, TrackingNumber, та
визначимо наступні твердження, які дозво-
лять нам описати параметри запиту та сер-
вісів:
CreditCardNumber ⊑ hasType.{String}
Flight ⊑ hasCreditCard.CreditCardNumber
Operation ⊑ hasTrackingNumber.Number
Number ⊑ hasType.Type
Type = {String, Numeric, Boolean}
Для вирішення задач Веб-сервісів
визначимо онтологію сервісу верхнього
рівня ServiceOntology.
Service, InputParameter, OutputParameter,
PreCondition, PostCondition, Parameter,
Name, Value, Type
Service ⊑ has.InputParameter; Service ⊑
has.OutputParameter
Service ⊑ has.PreCondition; PreCondition ⊑
Condition
PostCondition ⊑ Condition; Condition ⊑
hasValue.Boolean
Service ⊑ has.PostCondition; InputParameter
⊑ Parameter
OutputParameter ⊑ Parameter; Parameter ⊑
has.Name
Type = {String, Numeric, Boolean}
S
CI,I CO,O CO’,O
’
CI’,I
Q
Експертні та інтелектуальні інформаційні системи
74
IS ⊑ InputParameter
OS ⊑ OutputParameter;
CIS ⊑ PreCondition;
COS ⊑ PostCondition;
Parameter ⊑ has.Value; Name ⊑
hasType.{String}; Value ⊑ hasType.Type
Запит є також сервісом, але аб-
страктним. Точніше, абстрактним описом
сервісу, що реалізує поставлену бізнес-
задачу. Таким чином, онтологію запиту Q
можна визначити як:
TBox
Q ⊑ Service зв’язок з онтологією
сервісу верхнього рівня
Q ⊑ =4has.InputParameter;
Q ⊑ =2has.OutputParameter
Q ⊑ =1has.PreCondition;
IQ ⊑ InputParameter
OQ ⊑ OutputParameter;
CIQ ⊑ PreCondition
ABox
Start: IQ; Destination : IQ; Dt : IQ;
CCNumber : IQ
Offer:OQ, status: OQ ; CorrectCard : CI
Start:Location; Destination:Location;
Dt : Date;
Offer ⊑ hasCreditCard.CCNumber;
Offer:Flight;
status:Status
Сервіс 1S можна визначити як:
TBox
1S ⊑ Service зв’язок з онтологією
сервісу верхнього рівня
1S ⊑ = 5has.InputParameter;
1S ⊑ =2has.OutputParameter;
1S ⊑ = 1has.PreCondition;
IS1 ⊑ InputParameter
OS1 ⊑ OutputParameter;
CIS1 ⊑ PreCondition
ABox
StartL: IS1,
DestinationL : IS1,
DateFrom : IS1,
DateTo: IS1,
CCNumber : IS1
Status: OS1,
Offer: OS1;
EuropeanTrip: CIS1
StartL: Location зв’язок з онто-
логією POOntology
DestinationL: Location;
DateTo: Date;
DateFrom: Date
Offer ⊑ hasCreditCard.CCNumber;
Offer: Flight;
status: Status
Сервіс S2 можна визначити як:
TBox
S2 ⊑ Service зв’язок з онтологією
сервісу верхнього рівня
S2 ⊑ = 4has.InputParameter;
S2 ⊑ =3has.OutputParameter;
S2 ⊑ = 1has.PreCondition;
IS2 ⊑ InputParameter;
OS2 ⊑ OutputParameter;
CIS2 ⊑ PreCondition;
StartL: IS2,
Експертні та інтелектуальні інформаційні системи
75
DestinationL: IS2,
Dt: IS2,
CCNumber: IS2,
Offer: OS2,
Status: OS2.
TrNumber: OS2 ;
CorrectCard: CIS2
StartL: Location зв’язок з онто-
логією POOntology
DestinationL: Location;
DateTo: Date;
DateFrom: Date;
Offer ⊑ hasCreditCard.CCNumber;
Offer:Flight;
status:Status;
TrNumber:TrackingNumber
Визначимо онтологію задачі вияв-
лення DiscoveryOntology:
Q ⊑ Service;
S ⊑ Service
ExactInput ≡ (IQ⊑IS) ⊓ (IS⊑IQ)
SubsumesInput ≡ (IS⊑IQ)
SubsumedInput ≡ (IQ⊑IS)
ExactOutput ≡ (OQ⊑OS) ⊓ (OS⊑OQ)
SubsumesOutput ≡ (OQ⊑OS)
SubsumedOutput ≡ (OS⊑OQ)
FailOutput≡ ¬((𝑂𝑄 ⊑ 𝑂𝑆) ⊓ (𝑂𝑆 ⊑
𝑂𝑄))
FailInput≡ ¬((𝐼𝑄 ⊑ 𝐼𝑆) ⊓ (𝐼𝑆 ⊑
𝐼𝑄))
ExactPreCondition ≡ (CIQ ⊑ CIS) ⊓
(CIs ⊑ CIQ)
SubsumesPreC ≡ (CIs ⊑ CIQ)
ExactPostCondition ≡ (COQ ⊑ COS) ⊓
(COs ⊑ COQ)
SubsumesPostC ≡ (COQ ⊑ COS)
Можемо встановити наступні спів-
відношення між елементами кортежей
описів сервісів та запиту.
Для сервісу S2:
IS2 ⊑ IQ – для входів,
OS2 ⊒ OQ – для виходів,
CI Q ⇒ CI S2, в силу їх еквівалентнос-
ті – для передумов.
Для сервісу S1:
IS1 ⋢ IQ – для входів,
OS1 ⊒ OQ та OS1 ⊑ OQ – для виходів.
Таким чином, сервіс S2 задовільняє
запиту, а сервіс 1S – ні, тому що він вима-
гає як вхідний параметр DateTo, що не за-
безпечується запитом. Запит вимагає Flight
та Status як вихідний параметр та S2 виро-
бляє Flight, Status та TrNumber. До-
датковий вихідний параметр може просто
ігноруватися. При такому підході до опису
запиту та сервісів (за допомогою ДЛ), по-
шук, співставлення та висновок про від-
повідність сервісу та запиту може здійсню-
ватися автоматично, за допомогою існу-
ючих резонерів ДЛ.
Але слід зазначити, що при вирі-
шенні задачі включення для пар концептів,
що є елементами кортежу опису сервісу та
запиту, наприклад, IS та IQ виконується не
лише співставлення екземплярів, що задані
іменами, аналізується їх семантика –
зв’язок з онтолгією домена. Вирішення
задачі знаходження найбільш специфічно-
го класу для індивіда є стандартним алго-
ритмом ДЛ, як і задача включення на кон-
цептах.
Таким чином, якщо є два параметри
x і y такі, що x:C1 та y:C2, та C1 ⊑ C2, то
x:C2, та можна казати про відповідність
вхідних параметрів.
Формально задачу виявлення мож-
на визначити наступним чином:
Q ⊑ Service
S ⊑ Service
Експертні та інтелектуальні інформаційні системи
76
MatchingQueryXY(Q,S) ⊑
∃𝒙. 𝑰𝒒, ∃𝒚. 𝑰𝒔: (C1(x) ⊓ C2(y) ⊓
((C1⊑C2)⊓(C2⊑C1))⊔ (C1⊑C2)).
Висновки
Наведений підхід базується на вико-
ристанні ДЛ як для представлення пред-
метної області задачі (онтологія домена),
так і для вирішення безпосередньо задачі
виявлення Веб-сервісів, шляхом представ-
лення сервісів та запиту за допомогою он-
тологій.
Семантичні описи Веб-сервісу явля-
ють собою твердження або аксіоми ДЛ.
Кожен сервіс представляється ДЛ-
онтологією на основі загальної онтології
сервісу верхнього рівня. Кожна онтологія
конкретного сервісу базується на базі
знань інтегрованої ДЛ-онтології домену.
Враховуючі, що опис профілей се-
мантичних Веб-сервісів, що зберігаються в
реєстрі, є WSDL документом, який допов-
нений семантичними анотаціями, тобто є
звичайним XML, можливий автоматичний
розбір цього XML-визначення та побудова
онтології конкретного сервісу на основі
онтології сервісу верхнього рівня.
Існуючі резонери ДЛ дозволять
здійснювати автоматичне співставлення
запиту та сервісів, сервісів один з одним за
входами виходами. Це стандартні задачі
виводу ДЛ. Відношення між концептами
та індивідами, що представлятимуть вхід-
ну та вихідну інформацію запиту, визна-
чають ступінь відповідності сервісів, що
співставляються та ранжувати їх за цим
показником. Запропонований Алгоритм
співставлення на основі ДЛ може бути
застосований для співставлення сервісів
при композиції.
Але, слід зазначити, що наведений
підхід розглядає задачу встановлення від-
повідності окремого сервісу з репозиторію
та запиту (пряме співставлення), але в ре-
альності малоймовірно знайти один існую-
чий сервіс, що буде задовільняти запиту
для вирішення задачі. Як правило, нам тре-
ба знайти множину сервісів, що разом доз-
волять нам визначити новий сервіс, який
буде відповідати запиту, або іншими сло-
вами, «покривати» цей запит. Ця множина
сервісів формує композитний сервіс, що
покриває запит, та виконує поставлену
бізнес-задачу (не пряме співставлення).
Для формування такого сервісу може бути
використана задача знаходження найкра-
щого покриття запиту [15, 16], що з техні-
чної точки зору належить до загальної
структури для рерайтингу (перезапису)
[17, 18], використовуючи термінологію з
[19].
1. http://www.w3.org/2002/ws/
2. http://www.informit.com/articles/article.aspx?
p=336265
3. Formal Description of Web Services for
Expressive Matchmaking. Dipl.-Inform.
Sudhir Agarwal, 2007 Karlsruhe
4. Web Service composition: Semantic Links
based approach. Freddy L´ecu´, Doctor of
Philosophy, 2008
5. Ortiz M., Calvanese D., and Eiter T. Charac-
terizing Data Complexity for Conjunctive
Query Answering in Expressive Description
Logics./AAAI, 2006.
6. Staab S., Studer R. Handbook on Ontologies.
Second edition
7. Захарова О.В. Основні принципи побудови
онтологічного граф-орієнтованого опису
прикладної області. Проблеми про-
грамування. 2010. № 4. С. 51–59.
8. Ruben Lara. Definition of semantics for web
service discovery and composi tion. In
Knowledge Web Deliverable D2.4.2, 2004.
9. D2.4.6 A Theoretical Integration of Web
Service Discovery and Composition. Roberti
Pierluigi (ITC-IRST) Marco Pistore
(University of Trento) with contributions
from: Walter Binder (EPFL), Ion
Constantinescu (EPFL) Axel Polleres (UIBK),
Holger Lausen (UIBK), Paolo Traverso (ITC-
IRST), Michal Zaremba (NUIG). 2005.
KWEB/2005/D2.4.6A/v1.0.
10. Hai Wang, Zengzhi Li. A Semantic
Matchmaking Method of Web Services Based
On SHOIN+(D). /Institute of Computer
System Structure and Networks School of
Electronics & Information Engineering, Xi’an
Jiaotong University, Xi’an Shaanxi 710049,
http://www.w3.org/2002/ws/
http://www.informit.com/articles/article.aspx?p=336265
http://www.informit.com/articles/article.aspx?p=336265
Експертні та інтелектуальні інформаційні системи
77
PR China hwang@mailst.xjtu.edu.cn,
lzz@mail.xjtu.edu.cn.
11. Integrating Description Logics and Action
Formalisms for Reasoning about Web-
services. Franz Baader, Carsten Lutz, Maja
Milieie, Ulrike Sattler, Frank Wolter. LTCS-
Report 05-02.
12. Akkiraju R., et al. (2005, December 6). Web
Service Semantics. WSDL-S. Available:
http://www.w3.org/Submission/WSDL-S/.
13. http://life-prog.ru/view_zam2.php?id=
204&cat=5&page=13
14. Baader F. and Nutt W.; In Baader F.,
Calvanese D., McGuinness D., Nardi D., and
Patel-Schneider P. Basic Description Logics./
The Description Logic Handbook. P. 43–95.
Cambridge University Press, 2003.
15. Baader F., Ku¨sters R., and Molitor R.
Computing Least Common Subsumer in
Description Logics with Existential
Restrictions. In T. Dean, editor, Proc. of the
16th Int. Joint Conf. on AI. P. 96–101. M.K,
1999.
16. Franz Baader, Ralf Kiisters, and Ralf Molitor
LuFg Theoretische Informatik, RWTH
Aachen. Computing Least Common
Subsumers in Description Logics with
Existential.
17. Beeri C., Levy A.Y., and Rousset M-C.
Rewriting Queries Using Views in Descrip-
tion Logics. In L. Yuan, editor, Proc. of the
ACM PODS , New York, USA. P. 99–108,
Apr. 1997.
18. Alon Y. Halevy. Answering queries using
views: A survey. VLDB Journal, 10(4):270–
294, 2001.
19. Franz Baader, Ralf Ku¨sters, and Ralf
Molitor. Rewriting Concepts Using
Terminologies. In Proc. of the Int.
Conf.KRColorado, USA. P. 297–308, Apr.
2000.
References
1. http://www.w3.org/2002/ws/
2. http://www.informit.com/articles/article.aspx?
p=336265.
3. Formal Description of Web Services for
Expressive Matchmaking. Dipl.-Inform.
Sudhir Agarwal, 2007 Karlsruhe.
4. Web Service composition: Semantic Links
based approach. Freddy L´ecu´, Doctor of
Philosophy, 2008.
5. M. Ortiz, D. Calvanese, and T. Eiter. Charac-
terizing Data Complexity for Conjunctive
Query Answering in Expressive Description
Logics./AAAI, 2006.
6. S. Staab, R. Studer. Handbook on Ontologies.
Second edition.
7. Zakharova O. General Principes for building
the ontological graph – oriented description of
application area. /Problems of programming. -
№4, 2010. pp.51-59.(Ukrainian).
8. Ruben Lara. Definition of semantics for web
service discovery and composi tion. In
Knowledge Web Deliverable D2.42, 2004.
9. D2.4.6 A Theoretical Integration of Web
Service Discovery and Composition. Roberti
Pierluigi (ITC-IRST) Marco Pistore
(University of Trento) with contributions
from: Walter Binder (EPFL), Ion
Constantinescu (EPFL) Axel Polleres (UIBK),
Holger Lausen (UIBK), Paolo Traverso (ITC-
IRST), Michal Zaremba (NUIG). 2005.
KWEB/2005/D2.4.6A/v1.0.
10. Hai Wang, Zengzhi Li. A Semantic
Matchmaking Method of Web Services Based
On SHOIN+(D). /Institute of Computer
System Structure and Networks School of
Electronics & Information Engineering, Xi’an
Jiaotong University, Xi’an Shaanxi 710049,
PR China hwang@mailst.xjtu.edu.cn,
lzz@mail.xjtu.edu.cn.
11. Integrating Description Logics and Action
Formalisms for Reasoning about Web-
services. Franz Baader, Carsten Lutz, Maja
Milieie, Ulrike Sattler, Frank Wolter. LTCS-
Report 05-02.
12. R. Akkiraju, et al. (2005, December 6). Web
Service Semantics. WSDL-S. Available:
http://www.w3.org/Submission/WSDL-S/
13. http://life-
prog.ru/view_zam2.php?id=204&cat=5&page
=13
14. F. Baader and W. Nutt; In F. Baader, D.
Calvanese, D. McGuinness, D. Nardi, and P.
Patel-Schneider. Basic Description Logics./
The Description Logic Handbook, pages 43–
95. Cambridge University Press, 2003.
15. F. Baader, R. Ku¨sters, and R. Molitor.
Computing Least Common Subsumer in
Description Logics with Existential
Restrictions. In T. Dean, editor, Proc. of the
16th Int. Joint Conf. on AI, pages 96–101.
M.K, 1999.
16. Franz Baader, Ralf Kiisters, and Ralf Molitor
LuFg Theoretische Informatik, RWTH
Aachen. Computing Least Common
Subsumers in Description Logics with
Existential.
mailto:lzz@mail.xjtu.edu.cn
http://www.w3.org/Submission/WSDL-S/
http://life-prog.ru/view_zam2.php?id=204&cat=5&page=13
http://life-prog.ru/view_zam2.php?id=204&cat=5&page=13
http://www.w3.org/2002/ws/
http://www.informit.com/articles/article.aspx?p=336265
http://www.informit.com/articles/article.aspx?p=336265
mailto:lzz@mail.xjtu.edu.cn
http://www.w3.org/Submission/WSDL-S/
http://life-prog.ru/view_zam2.php?id=204&cat=5&page=13
http://life-prog.ru/view_zam2.php?id=204&cat=5&page=13
http://life-prog.ru/view_zam2.php?id=204&cat=5&page=13
Експертні та інтелектуальні інформаційні системи
78
17. C. Beeri, A.Y. Levy, and M-C. Rousset.
Rewriting Queries Using Views in
Description Logics. In L. Yuan, editor, Proc.
of the ACM PODS , New York, USA, pages
99–108, Apr. 1997.
18. Alon Y. Halevy. Answering queries using
views: A survey. VLDB Journal, 10(4):270–
294, 2001.
19. Franz Baader, Ralf Ku¨sters, and Ralf
Molitor. Rewriting Concepts Using
Terminologies. In Proc. of the Int.
Conf.KRColorado, USA, pages 297–308,
Apr. 2000.
Одержано 29.08.2017
Про автора:
Захарова Ольга Вікторівна,
кандидат технічних наук,
старший науковий співробітник.
Кількість наукових публікацій в
українських виданнях – 25.
http://orcid.org/0000-0002-9579-2973.
Місце роботи автора:
Інститут програмних систем
НАН України,
проспект Академіка Глушкова, 40.
Тел.: 526 5139.
E-mail: ozakharova68@gmail.com.
|