Descriptive logic using in Web-service problems

Currently, Web services allow us to solve specific business problems that implement business processes in various fields of human activity. But in order to get an executable Web service, we have to be able to efficiently solve many Web services’ problems at all stages of their life cycle. Descriptiv...

Ausführliche Beschreibung

Gespeichert in:

Bibliographische Detailangaben
Datum:	2017
1. Verfasser:	Zakharova, O.V.
Format:	Artikel
Sprache:	Ukrainian
Veröffentlicht:	Інститут програмних систем НАН України 2017
Schlagworte:	Web services descriptive logics UDC 004.94
Online Zugang:	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/127
Tags:	Tag hinzufügen Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:	Problems in programming

Institution

Problems in programming

id	pp_isofts_kiev_ua-article-127
record_format	ojs
resource_txt_mv	ppisoftskievua/0a/20cabbfa5a209151331de292b232b60a.pdf
spelling	pp_isofts_kiev_ua-article-1272018-07-23T13:46:01Z Descriptive logic using in Web-service problems Использование дескриптивных логик в проблематике Web-сервисов Використання дескриптивних логік в проблематиці WEB-сервісів Zakharova, O.V. Web services; descriptive logics UDC 004.94 Web-сервисы; дескриптивные логики УДК 004.94 Web-сервіси; дескриптивні логіки УДК 004.94 Currently, Web services allow us to solve specific business problems that implement business processes in various fields of human activity. But in order to get an executable Web service, we have to be able to efficiently solve many Web services’ problems at all stages of their life cycle. Descriptive logics, due to their reasoning mechanisms and capabilities of logical inference and semantic descriptions, are an effective and powerful tool for solving Web services problems. The purpose of this work is to establish a chain of Web services’ tasks at the functional level and define approaches to their solution using the mechanisms of descriptive logics. В настоящее время Web-сервисы поз-воляют решать конкретные бизнес-задачи, реализующие бизнес-процессы в различных областях жизнедеятельности человека. Но для того, чтобы получить исполняемый Web-сервис, надо уметь эффективно решать множество задач самих Web-сервисов на всех этапах их жизненного цикла. Аппарат дескриптивных логик, благодаря своим механизмам суждений и возможностям логического вывода и придания описаниям семантического смысла, является эффективным и мощным инструментом для решения задач Web-сервисов. Цель данной работы состоит в определении цепочки задач Web-сервисов на функУДК 004.94циональном уровне и подходов к их решению с использованием аппарата дескриптивных логик. На сьогодні Web-сервіси дозволяють вирішувати конкретні бізнес-задачі, що реалізують бізнес процеси у різних галузях життєдіяльності людини. Але для того, щоб отримати виконуваний Web-сервіс, треба вміти ефективно вирішувати цілу низьку задач самих Web-сервісів на всіх етапах їх життєвого циклу. Апарат дескриптивних логік, завдяки своїм механізмам міркувань та можливостям логічного виводу та надання описам семантичного змісту, є ефективним та потужним інструментом для вирішення задач Web-сервісів. Мета даної роботи полягає у визначенні ланцюжка задач Web-сервісів на функціональному рівні та підходів до вирішення цих задач із застосуванням апарата дескриптивних логік. Інститут програмних систем НАН України 2017-06-13 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/127 PROBLEMS IN PROGRAMMING; No 1 (2015) ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 1 (2015) ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 1 (2015) 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/127/120 Copyright (c) 2017 ПРОБЛЕМИ ПРОГРАМУВАННЯ
institution	Problems in programming
baseUrl_str	https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date	2018-07-23T13:46:01Z
collection	OJS
language	Ukrainian
topic	Web services descriptive logics UDC 004.94
spellingShingle	Web services descriptive logics UDC 004.94 Zakharova, O.V. Descriptive logic using in Web-service problems
topic_facet	Web services descriptive logics UDC 004.94 Web-сервисы дескриптивные логики УДК 004.94 Web-сервіси дескриптивні логіки УДК 004.94
format	Article
author	Zakharova, O.V.
author_facet	Zakharova, O.V.
author_sort	Zakharova, O.V.
title	Descriptive logic using in Web-service problems
title_short	Descriptive logic using in Web-service problems
title_full	Descriptive logic using in Web-service problems
title_fullStr	Descriptive logic using in Web-service problems
title_full_unstemmed	Descriptive logic using in Web-service problems
title_sort	descriptive logic using in web-service problems
title_alt	Использование дескриптивных логик в проблематике Web-сервисов Використання дескриптивних логік в проблематиці WEB-сервісів
description	Currently, Web services allow us to solve specific business problems that implement business processes in various fields of human activity. But in order to get an executable Web service, we have to be able to efficiently solve many Web services’ problems at all stages of their life cycle. Descriptive logics, due to their reasoning mechanisms and capabilities of logical inference and semantic descriptions, are an effective and powerful tool for solving Web services problems. The purpose of this work is to establish a chain of Web services’ tasks at the functional level and define approaches to their solution using the mechanisms of descriptive logics.
publisher	Інститут програмних систем НАН України
publishDate	2017
url	https://pp.isofts.kiev.ua/index.php/ojs1/article/view/127
work_keys_str_mv	AT zakharovaov descriptivelogicusinginwebserviceproblems AT zakharovaov ispolʹzovaniedeskriptivnyhlogikvproblematikewebservisov AT zakharovaov vikoristannâdeskriptivnihlogíkvproblematicíwebservísív
first_indexed	2025-07-17T09:38:15Z
last_indexed	2025-07-17T09:38:15Z
_version_	1838408940508938240
fulltext	Моделі та засоби систем баз даних і знань © О.В. Захарова, 2015 38 ISSN 1727-4907. Проблеми програмування. 2015. № 1 УДК 004.94 О.В. Захарова ВИКОРИСТАННЯ ДЕСКРИПТИВНИХ ЛОГІК В ПРОБЛЕМАТИЦІ WEB-СЕРВІСІВ На сьогодні Web-сервіси дозволяють вирішувати конкретні бізнес-задачі, що реалізують бізнес процеси у різних галузях життєдіяльності людини. Але для того, щоб отримати виконуваний Web-сервіс, треба вміти ефективно вирішувати цілу низьку задач самих Web-сервісів на всіх етапах їх життєвого циклу. Апарат дескриптивних логік, завдяки своїм механізмам міркувань та можливостям логічного виводу та надання описам семантичного змісту, є ефективним та потужним інструментом для вирішення задач Web-сервісів. Мета даної роботи полягає у визначенні ланцюжка задач Web-сервісів на функціональ- ному рівні та підходів до вирішення цих задач із застосуванням апарата дескриптивних логік. Вступ На сьогодні Web-сервіси – це про- грамні компоненти, що дозволяють вирі- шувати конкретні бізнес-задачі, реалізуючі відповідні бізнес-процеси. Як правило, не- можливо знайти один Web-сервіс, що реа- лізує бізнес-процес. Є необхідність у побу- дові складних – композитних Web- сервісів, поєднуючі існуючі сервіси у кру- пніші системи. Зрозуміло, що створення такого сервісу має здійснюватися автома- тизованим чином. А ефективність вирі- шення цієї задачі та вибору тих чи інших алгоритмів на кожному з етапів життєвого циклу сервісу, перш за все, залежить від обраної моделі формалізації сервісу. Потрібний формалізм, що забезпе- чуватиме хороше семантичне анотування сервісів та підходи для семантичного спів- ставлення сервісів для автоматизованого виявлення підходящого сервісу та побудо- ви композитного сервісу, який реалізує конкретний бізнес-процес. Так як сервіси можуть створювати змінення в світі, точне представлення їх функціональності повин- но мати справу з динамічним аспектом (поведінкою). Це є одним з ключових аспектів, що робить очевидною доцільність викорис- тання дескриптивних логік (ДЛ) для опи- сання сервісів, так як ДЛ забезпечує мож- ливість міркувань для сервісів, і таким чи- ном дозволяє описати їх динамічний ас- пект. Окрім цього, було б доцільним, щоб формалізм базувався на онтології задач, які реалізуються сервісом. А ДЛ лежать в основі таких широко відомих мов описан- ня онтологій, як OWL та його модифікації. Визначення сервісу Сервіс-орієнтована архітектура (SOA) з кожним днем набирає сили як но- ва модель організації взаємодії різноманіт- них корпоративних прикладних систем. Але однією з суттєвих проблем цієї галузі є відсутність чітких стандартів та нестача інформації про сервіси при стрімкому зро- станні кількості SOA- розробок. У галузі розробки та прийняття стандартів та спе- цифікацій для Web-сервісів можна виділи- ти три основні організації: WS-I (Web Services Interoperability Organization), W3C (World Wide Web Consortium) та OASIS (Organization for the Advancement of Structured Information Standards). Згідно визначення W3C [1], під сер- вісом розуміють таку програмну систему, що ідентифікується URI, та публічні інтер- фейси та прив’язки якої визначені та опи- сані мовою XML. Опис цієї програмної системи може бути знайдено іншими про- грамними системами, які можуть взаємо- діяти з нею відповідно до цього опису з використанням повідомлень, що базуються на XML та передаються за допомогою Ін- тернет-Протоколів. Web-сервіси базуються на чотирьох ключових технологіях [1–25]: eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) та Universal Description, Discovery and Integration (UDDI). Ці технології викорис- 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 Моделі та засоби систем баз даних і знань 39 товуються для забезпечення функціону- вання Web-сервісів. XML – розширювана мова розмітки, призначена для зберігання і передачі стру- ктурованих даних, є основою для таких технологій, як SOAP та WSDL. Визначає формат даних, що використовується для обміну інформацією між споживачем сер- вісу та самим сервісом. SOAP (Simple Object Access Protocol, або Services-Oriented Architecture Protocol) – заснований на мові XML стан- дарт для взаємодії між сервісами та їх споживачами. WSDL – це мова опису зовнішніх інтерфейсів Web-служби на базі XML. Описаний таким чином інтерфейс містить всю інформацію, яка необхідна для досту- пу до даного сервісу. З точки зору WSDL- документа Web-сервіс являє собою колек- цію портів, які, в свою чергу, є колекцією абстрактних операцій та повідомлень. Аб- стракція операцій та повідомлень дозволяє зв’язувати їх з різними протоколами та форматами даних типу SOAP, HTTP GET/POST або MIME. UDDI (Universal Discovery, Descrip- tion, and Integration) – універсальний інтер- фейс розпізнавання опису та інтеграції. За- дача UDDI – надати механізм для публіка- ції інформації про Web-сервіси, а також за- безпечити підтримку пошуку Web- сервісів, що є доступними. В цілому UDDI – це регістраційна система, до якої входять набір XML-файлів та асоційовані схеми, що містять описи послуг, які надаються Web-сервісами. Зв’язки між цими стандартами по- казані на рис. 1. Базовими ролями сервіс- орієнтованої архітектури є провайдер сер- вісу, запитувач сервісу та механізм вияв- лення [17]:  провайдер сервісу – будь-яка організація, що надає сервіс, така сутність забезпечує специфічну реалізацію сервісу;  запитувач сервісу (клієнт) – сутність, яка шукає сервіс та запускає кон- кретний сервіс, щоб досягти своїх цілей;  механізм виявлення діє як репо- зиторій або довідник сервісів (реєстр). Рис. 1 Постановка задачі Швидкий розвиток сервіс-орієн- тованих технологій, можливості повтор- ного використання Web-сервісів та реалі- зація прикладних бізнес-систем як серві- сів, що існують в Інтернет, величезна кі- лькість доступних сервісів виводить на передній план задачу створення такого механізму, що б дозволив автоматично знайти коректний Web-сервіс, який задо- вольнятиме вимоги користувача. Але, скоріше за все, може не існувати такого окремого Web-сервісу і тоді потрібна мо- жливість сформувати вибірку існуючих сервісів та інтегрувати їх таким чином, щоб задовольнити функціональність ко- ристувача. Така можливість називається композицією Web-сервісів. Результат ком- позиції має генеруватися автоматично при інтерактивній взаємодії з користувачем на базі існуючих сервісів та цільового запи- ту. На сьогодні процес інтеграції містить багато ручної праці. Враховуючи велику кількість сервісів, які треба інтегрувати для реалізації функціональності найпрос- тішої прикладної системи, питання авто- матизації процесу побудови композиції стає критичним для забезпечення масшта- бованості сервіс-орієнтованих систем. Тобто необхідно передати функції люди- ни машині. Для цього, перш за все, треба доповнити моделі сервісів семантикою, UDDI WSDL HTTP/HTTPS, SMTP, FTP XML SOAP Моделі та засоби систем баз даних і знань 40 яка може бути потім використана механі- змами міркувань при вирішенні різних задач життєвого циклу сервісів. Необхід- ність реалізації автоматизованого логіч- ного виведення обумовлює доцільність використання в алгоритмах вирішення задач Web-сервісів дескриптивних логік, що мають готові, та вже досить розвинені механізми міркувань. Дескриптивні логіки Дескриптивні логіки (ДЛ) [2] – це родина мов представлення знань, що мо- же використовуватися для представлення знань прикладного домена структурова- ним та формально добре зрозумілим спо- собом. Назва дескриптивні (описові) логі- ки мотивується тим фактом, що з одного боку важливі поняття домена описуються дескрипторами концептів, тобто вираза- ми, які будуються з атомних концептів (унарних предикатів) та атомних ролей (бінарних предикатів), використовуючи конструктори ролей та концептів, які за- безпечуються конкретною ДЛ. Множина цих конструкторів й визначає виразну потужність ДЛ. Мінімальний набір конструкторів наведений у табл. 1 далі [3] (за основу бе- реться 𝓐𝓛𝓒𝓠𝓘𝓞 – базова ДЛ 𝓐𝓛𝓒, що розширена номіналами та інверсними ролями). Таблиця 1. Синтаксис та семантика 𝓐𝓛𝓒𝓠𝓘𝓞 Назва Синтаксис Семантика Інверсна роль {(y,x) \| (x,y) ∈ } Кон’юнкція C ⊓ D Доповнення Обмеження «щонайменше» ( {x \| card({y \| (x,y) ∈ ∧ y ∈ }) ≥ n} Номінали {a} { За допомогою цих конструкторів може бути визначений ряд інших кон- структорів, як абревіатура: диз’юнкція (⊔), верхній концепт (⊤), обмеження «щонай- більше» ( rC), обмеження існування (∃r.C). Семантики концептів та ролей ДЛ визначаються в термінах Інтерпретації [18]. Це модель, що формально складаєть- ся з непорожньої множини (домена) та функції інтерпретації , яка співставляє кожному атомарному концепту A дескрип- тивної логіки деяку підмножину , а кожній атомарній ролі R — деяку під- множину , кожному індивіду a – елемент . ДЛ відрізняються від своїх поперед- ників, таких як семантичні мережі та фрей- ми, тим, що вони наділені формальними семантиками, що засновані на логіці. Завдяки тому, що:  у ДЛ знання доступні для ма- шинної обробки – автоматизованого логіч- ного виводу нових знань з наявних;  мова має точну семантику, а ло- гічні проблеми є вирішувальними (мають практично допустиму обчислювальну складність);  мова має значну виразну силу, що пригодна для формулювання на цій мові практично всіх значимих фактів. ДЛ стали основою декількох мов Web-онтологій. База знань ДЛ складається з інтен- сіональних знань у вигляді термінології (TBox) та екстенсіональних знань (asser- tional), що специфічні для екземплярів до- мена (ABox). TBox будується за допомо- гою оголошень, що описують загальні вла- стивості понять, та, як правило, не зміню- ються, тому вважається статичним. Знан- ня ABox часто змінюються. Якщо жоден концепт TBox не виз- начається сам через себе, тобто його виз- начення не містить його ім’я напрямку, або побічно, то такий TBox називається ациклічним [14]. Системи ДЛ забезпечують користу- вачів різними механізмами виводу, що ви- водять неявні знання з тих, що явно пред- ставлені. Більш того, на сьогодні існує Моделі та засоби систем баз даних і знань 41 вже чимало реалізованих механізмів мір- кувань ДЛ, що готові до використання. Всі ці переваги обумовлюють безперечну доцільність використання апарату ДЛ для вирішення багатьох задач Web-сервісів. Але, тут варто пам’ятати, що окремою за- дачею залишається вибір такої ДЛ, що є компромісним рішенням між її виразніс- тю та розв’язуваністю. Ця проблема пот- ребує уваги, але залишається за межами даної роботи. Для демонстрації прикладів цієї роботи досить можливостей 𝓐𝓛𝓒𝓠𝓘𝓞. Основні задачі життєвого циклу сервісу на функціональному рівні На практиці існує два рівні пред- ставлення сервісів, а саме: функціональна та процесна модель сервісів [17]. На фун- кціональному рівні сервіси розглядаються як окремі існуючі в мережі прикладні ком- поненти, які можуть бути викликані шля- хом відправлення повідомлення. При цьо- му сервіс виконує свою задачу та (в деяких випадках) виробляє відповідь тому, хто його викликав. Таким чином, відсутня без- перервна взаємодія між запитувачем серві- су та самим сервісом. Опис таких Web- сервісів фокусується на їх функціонально- сті в термінах імені сервісу, імен операцій, імен повідомлень (що відомі також як вхі- дні та вихідні повідомлення /параметри), імені інтерфейсу. Сервіси процесного рівня містять декілька операцій, які слідують загальній поведінці сервісу. Такі сервіси потребу- ють розширеної взаємодії між запитува- чем сервісу та множиною операцій, забез- печуючи конкретну функціональність. Таким чином, це, як правило, композитні сервіси, тобто взаємодія з ними склада- ється не лише з окремого кроку запит- відповідь, для досягнення потрібного ре- зультату вони мають слідувати складному протоколу. Ці кроки можуть складатися з довільних (умовних та ітеративних) ком- бінацій з умовними виходами. На цьому рівні необхідний деталізований опис вну- трішньої поведінки сервісів, наприклад, за допомогою (STS). Очевидно, що на про- цесному рівні Web-сервіси також мають функціональний опис своїх операцій та сервісів. Але сервіси на функціональному рівні не мають поведінкових взаємодій. Це є головною відмінністю цих двох мо- делей. Предметом розгляду в цій роботі є лише функціональна модель сервісу. Як ми вже зазначили, функціональ- на модель сервісу [15] описує його функці- ональність та визначає способи, як клієнт може взаємодіяти з сервісом для досягнен- ня його функціональних можливостей. Це робиться шляхом вираження перетворення даних з входів і виходів і перетворення стану з передумов і ефектів. Тобто сервіс розглядається як атомний елемент, а ком- позитний сервіс як пов’язана сукупність атомних елементів. Процес, що відбува- ється всередині сервісу залишається поза увагою. Вирішення задач Web-сервісів з урахуванням їх процедурної поведінки виходить за межі цієї статті. Можна визначити наступні базові задачі життєвого циклу сервісу на функ- ціональному рівні, для вирішення яких до- цільне використання апарату ДЛ:  формалізація Web-сервісу на фу- нкціональному рівні. Передумови та ефек- ти сервісу задаються як твердження ДЛ;  виявлення Web-сервісу: а) визначення цілі виявлення як кон’юнктивного запиту, що є кон’юнкцією тверджень ДЛ; б) співставлення (matching) пошу- кового запиту та сервісів на функціональ- ному рівні, перевірка відповідності перед- умов та ефектів цілі виявлення (goal discovery), перевірка істинності передумов; в) верифікація Web-сервісу – пере- вірка відповідності сервісу його специфі- кації за допомогою резонерів ДЛ; г) перевірка не функціональних ха- рактеристик сервісу [18, 25], таких як вар- тість, повноваження, ступінь довіри до сервісу, репутація сервісу та інші. Слід зазначити, що врахування не функціональ- них характеристик сервісу підвищує якість відбору сервісів, але суттєво ускладнює задачу;  побудова композитного сервісу на функціональному рівні – перевірка від- повідності між передумовами та ефектами складових сервісів. Моделі та засоби систем баз даних і знань 42 Опис Web-сервісу на функціональному рівні На цьому рівні надаються можливо- сті опису сервісу у термінах вхідних та ви- хідних параметрів, передумов (умов вико- нання сервісу) та ефектів (результатів ви- конання сервісу). Вхідні параметри – це те, що по- требує сервіс, щоб виробити бажаний ре- зультат. Передумови представляють умови у світі, які мають виконуватися, тобто бути істинними, для успішного виконання сер- вісу. Виконання сервісу може мати резуль- тат у діях в світі. Ці умови описуються як ефекти сервісу. В результаті можуть бути встановлені значення вихідних парамет- рів сервісу, які надалі можуть бути вико- ристані в задачі, наприклад, як значення вхідних параметрів для іншого сервісу. За типами вхідних параметрів роз- різняють два види сервісів: базові та пара- метричні [3]. Під базовими розуміють сервіси, вхідні параметри яких вже встановлені іменами індивідів. Параметричні сервіси містять на місці імен індивідів змінні, та повинні роз- глядатися як компактне представлення всіх їх базових (ground) екземплярів. Для простоти далі розглядаються лише базові сервіси, вважаючи, що параметричні сер- віси вже були визначені екземплярами. Профілі сервісу описують як самі сервіси, що надаються, так і запити до сер- вісів. Запит складається з опису гіпотетич- ного сервісу, що виконує задачу, яка по- трібна особі, що запитує сервіс. Виходячи з вищесказаного та врахо- вуючи існуючі визначення сервісу [3, 22], можна формально описати сервіс на базі формалізму ДЛ наступним чином. Нехай 𝓣 – ациклічний TBox. Атом- ний сервіс ( , , ; )S in out pre post для аци- клічного TBox 𝓣 складається з 1) кінцевої множини pre ABox чи TBox тверджень – передумов, типу )(aA , );( bas , де A – ім’я примітивного конце- пта в 𝓣 а s – ім’я ролі; 2) кінцевої множини in вхідних параметрів; 3) кінцевої множини post умов- них постумов (або ефектів) форми  , де  – це твердження ABox і воно є приміти- вним літералом для 𝓣, тобто, твердження ABox )(aA , )(aA , );( bas , або );( bas з ім’ям примітивного концепта A в 𝓣 та ім’ям ролі s . Умовні пост умови  ка- жуть, що, якщо  було істинно до вико- нання сервісу, то  має бути істинним після; 4) кінцевої множини out вихідних параметрів. Інтуїтивно, сервіс є відношенням на інтерпретаціях. Тобто, сервіс S зв’язує ін- терпретацію 𝒥 з інтерпретацією 𝒥’ при ви- конанні наступного твердження: якщо в результаті виконання сервісу S можна от- римати інтерпретацію 𝒥’, то цей сервіс може бути застосований в 𝒥. А саме, це означає, що виконання сервісу S перево- дить інтерпретацію 𝒥 в 𝒥’. Це можливо лише, якщо 𝒥 та 𝒥’ задовольняють пред- та пост- умови сервісу S [19]:  умови, що мають задовольня- тися для виконання S , описуються у pre . Умова A вимагає, щоб кожний інди- від в 𝒥 був екземпляром концепта A . Реш- та умов відповідають твердженням ABox ДЛ [2];  умови, що мають задовольняти- ся після виконання S (тобто інтерпретаці- єю 𝒥’), описуються в post . Так як стан світу до S може впливати на ефекти S , пост-умови трохи відрізняються від пред- умов. Ідея, що стоїть за кожним  , по- лягає у тому, що, якщо кожна умова в  міститься в 𝒥, то  має міститися в 𝒥’. Більше того, бажано, щоб 𝒥’ міні- мально відрізнялася від 𝒥, тобто лише в тих аспектах, які вимагаються пост- умовами. Це забезпечується семантиками сервісу та є сутністю підходу мінімізації змін. Інтерпретації відрізняються одна від одної, якщо існує концепт або роль, ін- терпретація якого(ої) присутня в одній моделі, але відсутня в іншій. Формально це можна визначити наступним чином. Моделі та засоби систем баз даних і знань 43 Визначення 1 [19]. Дві інтерпретації 𝒥 та 𝒥’ відрізняються відносно 𝓣 (𝒥 𝒥’) в та імені концепта , якщо та або та . Аналогічно, дві інтерпретації 𝒥 та 𝒥’ відрі- зняються відносно 𝓣 в та імені ролі R, якщо < та < або < та < . У даному визначенні або < , відповідно, утворюють симетрич- ну різність інтерпретацій. В роботі [6] визначається відношен- ня пріоритетності на інтерпретаціях, що характеризує їх “близькість” до заданої (вихідної) інтерпретації 𝒥. Тоді, інтерпре- тацію, якій надається перевага, можна виз- начити наступним чином. Визначення 2 [3]. Нехай 𝓣 – ацик- лічний TBox, );( postpreS  – сервіс для 𝓣, та 𝒥 – модель для 𝓣. Бінарне відношен- ня на моделях 𝓣, визначається, як 𝒥’ 𝒥’’, якщо 𝒥’ 𝒥’’ ; , де позначає симетричну різність між двома множинами. Виходячи з цього, застосування сер- вісу можна визначити наступним чином. Визначення 3 [3]. Нехай 𝓣 – ацик- лічний TBox, );( postpreS  – сервіс для 𝓣, та моделей 𝓣 - 𝒥,𝒥’, які розділяють той самий домен та інтерпретацію всіх імен індивидів. S може перетворювати 𝒥 в 𝒥’ (𝒥 𝒥’) лише, коли 𝒥,𝒥’ post, та не існує моделі TBox 𝓣 такої, що 𝒥, post, 𝒥’, та 𝒥’. Аналогічно, композитний сервіс kSS ,,1 може перетворювати 𝒥 в 𝒥’ (𝒥 𝒥’) лише тоді, якщо існують моделі з 𝒥= , 𝒥’ = , та для ki 1 . Але нав’язування цієї мінімізації змін є занадто обмеженою [4, 5], і не для всіх примітивних літералів може бути за- стосована умова мінімізації. Тому, для ви- рішення цієї проблеми, а саме для опису таких літералів, ряд підходів до формалі- зацій сервісу, пропонують використовува- ти окклюзії [3] – перепони. Тобто до скла- дових визначення додається кінцева мно- жина occ окклюзій форми )(aA або );( bar , де A примітивне ім’я концепта з 𝓣, r – ім’я ролі, та ba ; – індивіди. Також, слід зазначити, що множина вхідних параметрів In, може розглядатися як частина передумов сервісу, тому що ви- мога до наявності того чи іншого вхідного параметра також є умовою виконання сер- вісу – найпростіша умова. Аналогічно, множина вихідних параметрів Out може розглядатися як частина множини посту- мов, де  – це просто тавтологія, а ефек- том є формування значення вихідного па- раметра. Композитний сервіс для 𝓣 визнача- ється як кінцева послідовність kSS ,,1 атомних сервісів для 𝓣. Як приклад визначення сервісів, ро- зглянемо простий сервіс продажу велоси- педів [19]: 1 2 2({ ( , ), ( , ), ( , ),owns a b wants a b owns a p 2( )}, { ( , ),Bicycle b owns a b 1( , )})owns a p . (1) Тобто множина передумов сервісу: 1 2 2{ ( , ), ( , ), ( , ),pre owns a b wants a b owns a p ( )}Bicycle b , множина умовних пост-умов: 2 1{ ( , ), ( , )}post owns a b owns a p   , де – порожня множина умов в умовній пост-умові. Порожня множина задоволь- няється кожною інтерпретацією. У наведеному прикладі – функціо- нальна роль (або база знань, що містить ак- сіоми типу ), вартість ве- лосипеда моделюється за допомогою аб- страктного об’єкта p , та нічого більше не має змінюватися при купівлі/продажу ве- лосипеда. Такий простий сервіс описує продаж велосипеда відповідним чином: завдяки семантикам, лише власник велоси- педа та його винагорода змінюються серві- сом. Так, наприклад, b залишається вело- сипедом. Якщо велосипед виявився пога- ним, новий власник буде не задоволений, а Моделі та засоби систем баз даних і знань 44 колишній – навпаки задоволений. Це мож- на змоделювати наступним чином: 1 2 2({ ( , ), ( , ), ( , ),owns a b wants a b owns a p ( )},Bicycle b 2 2{ ( , ), { ( ) ( )}owns a b Bad b Happy a  1 1( , ), { ( ) ( )}})owns a p Bad b Happy a . (2) Зазвичай ми не маємо повної інфор- мації про світ, тобто модель 𝒥 Tbox 𝓣 не відома повністю. Нам відомі лише деякі факти, тобто ми маємо ABox , та разом з 𝓣 розглядаються всі моделі 𝓐, як можливі стани світу. Перш ніж використовувати сервіс, треба знати, чи може він бути за- стосованим, тобто, чи задовольняються всі передумови. Якщо так, можливо треба знати, чи досягає його застосування бажа- ного ефекту, тобто, чи дійсно твердження, яке ми бажаємо зробити правильним, збе- рігається після виконання сервісу. Ці про- блеми є базовими задачами виводу в ДЛ [7], та в наведеній вище постановці мо- жуть формально визначатися наступним чином. Визначення 4. Нехай kSS ,,1 – сервіс для ациклічного TBox 𝓣, з iS = ( ; )i ipre post та A - ABox.  Виконуваність: сервіс kSS ,,1 є виконуваним в 𝓐 відносно 𝓣 лише тоді, якщо наступні умови вірні у всіх моделях 𝒥 𝓐 та 𝓣: o 𝒥 ⊨ 1pre та o для всіх i з 1≤ i ≤ k та всіх ін- терпретацій 𝒥’ з 𝒥 𝒥’, маємо 𝒥’ ⊨ 1ipre  .  Проекція: твердження є послідов- ністю застосування kSS ,,1 в 𝓐 відносно 𝓣 лише тоді, якщо для всіх моделей 𝒥 𝓐 та 𝓣, та всіх 𝒥’ з 𝒥 𝒥’, маємо 𝒥’ ⊨ . Таким чином, щоб досягти ефекту  (твердження ABox), сервіси kSS ,,1 мають бути виконуваними в 𝓐 відносно 𝓣, кожний iS має бути погодженим з 𝓣 для ki 1 , та  має бути послідовністю за- стосування kSS ,,1 в 𝓐 відносно 𝓣. Виявлення сервісів на функціональному рівні Щоб знайти Web-сервіси для вико- нання конкретних задач у бізнес-процесі, запитувач має, перш за все, визначити умо- ви, які має задовольняти цей Web-сервіс. Такий підхід називається співставлення на основі цілі (goal based matchmaking) [8, 9] та має справу з визначенням умов на ого- лошення Web-сервісу (вхідні, вихідні па- раметри, передумови та ефекти) та пере- віркою, чи може Web-сервіс задовольняти ці умови. Цілі, як правило, слідують з біз- нес-цілей, та можуть виводитись з них ав- томатично або не автоматично. Опис чи оголошення сервісу відпо- відає запиту, якщо запит є досить близь- ким до сервісу, що запитується. Тут необ- хідно специфікувати, що означає «досить близький». У найсуворішій інтерпретації, оголошення та запит є «досить близьки- ми», якщо вони описують точно один й той самий сервіс. Але це визначення є за- надто обмеженим. Потрібно більш гнучке визначення поняття «досить близьке». Тобто, необхідні механізми співставлення, які розпізнають ступінь подібності між оголошеннями сервісів та запитами. А в того, хто запитує сервіс, має бути можли- вість визначати ступінь гнучкості, яку во- ни надають системі. Чим менша гнучкість, тим менша вірогідність знаходження сер- вісів, що задовольняють вимогам. Таким чином:  механізм співставлення має підтри- мувати гнучке семантичне співставлення між оголошеннями сервісів та запитами на основі онтологій, що доступні сервісам та механізму співставлення;  запитувач має володіти деяким кон- тролем ступеня гнучкості співставлення, що дозволяється системі;  механізм співставлення має заохо- чувати обидві сторони бути чесними у сво- їх описах у питаннях вартості;  процес співставлення має бути ефе- ктивним: він не має навантажувати запи- тувача надмірними затримками, які пере- шкоджатимуть його ефективності. Далі наводиться алгоритм, який адоптує множину стратегій. Його зміст Моделі та засоби систем баз даних і знань 45 полягає у тому, що оголошення сервісу, який шукають, співставляють із запитом. Слід зазначити, що запит також є своєрід- ним оголошенням сервісу, а саме, того сервісу, який реалізує потрібну користува- чеві функціональність. Таким чином, ого- лошення бажаного сервісу співставляється з оголошеннями сервісів, що існують у реєстрі, і відношення між запитом та ого- лошенням сервісу ідентичні відношенням між оголошеннями двох сервісів. Вважаємо, що оголошення сервісу відповідає запиту, якщо всі виходи запиту співпадають з виходами оголошення, а всі входи оголошення співпадають зі входами запиту. Точне співпадання знайти досить важко, тому визначають ступені відповід- ності і обирають сервіси з найбільшим сту- пенем відповідності. Базовий критерій ви- явлення полягає у тому, що відповідний сервіс має задовольняти потреби запиту- вача, а запитувач має забезпечувати від- повідному сервісу всі входи, які необхідні для його коректного функціонування. Критерій відповідності. Якщо 𝓣 – ациклічний Tbox ДЛ , ),( ss OutInS  – сервіс та ),( qq OutInQ  – запит, де:  qIn – кінцева множина входів запиту;  sIn – кінцева множина входів оголошення сервісу;  qOut – кінцева множина вихо- дів запиту;  sOut – кінцева множина вихо- дів оголошення сервісу, що виражені твер- дженнями 𝓛, то відповідність сервісу запи- ту гарантується включеннями sIn ⊑ qIn та qOut ⊑ sOut . Таким чином, сервіс відпо- відає запиту, якщо запит містить всі вхідні твердження сервісу та, можливо, ще додат- кові, а множина вихідних тверджень за- питу, навпаки, має бути вужча за множину вихідних тверджень сервісу, тобто сервіс може повертати більше ефектів ніж того потребує запит. Запити співставляються за цим кри- терієм з усіма оголошеннями сервісів, які є у реєстрі. Як тільки знайдена відповідність запиту та оголошення, вона записується, щоб знайти відповідність більш високого ступеня. Ступінь успіху залежить від сту- пеня виявленого співпадання. Ступінь від- повідності між двома входами або двома виходами залежить від відношення між концептами, які пов’язані з цими входами або виходами, а саме, мінімальною відс- танню між цими поняттями у дереві таксо- номії. Розрізняють наступні ступені відпо- відності [10, 20]:  Exact – точне співпадання: o qOut = sOut – еквівалентність, або o subclassOfOutq sOut – резуль- тат точний у припущенні, що оголошуючи sOut провайдер сервісу має забезпечити виходи, що погоджені з кожним безпосе- реднім підтипом sOut ;  Plug In – більш слабкий зв’язок ( sOut subsumes qOut ). Якщо sOut subsumes qOut , то sOut – це множина, яка включає виходи qOut , або, іншими слова- ми, sOut може бути підключений замість qOut ;  Subsumes ( qOut subsumes sOut ) – якщо qOut subsumes sOut , то провайдер не повністю задовольняє запит. Це озна- чає, що запитувач може використовувати провайдера для досягнення своєї мети, але ймовірно йому прийдеться модифікувати свій план або виконати інші запити, щоб завершити свою задачу;  Fail – невдача відбувається, якщо не знайдено будь-якого nsubsumptio між qOut та sOut . Ступінь відповідності відобража- ється на дискретній шкалі, де найбільш переважним є точна відповідність )(Exact , наступний рівень – InPlug , так як вихід, що повертається, може бути використаний замість того, що очікує запитувач. Subsumes – третій рівень, так як вимоги запитувача виконуються лише частково: оголошений сервіс може забезпечити лише деякі конкретні варіанти того, що бажає запитувач. Самий низький рівень Fail – не прийнятний результат. Далі сервіси со- ртируються за ступенем відповідності за- Моделі та засоби систем баз даних і знань 46 питу: обираються сервіси з найбільшим ступенем відповідності виходів. Співстав- лення входів використовується лише як допоміжна (вторинна) оцінка, щоб розме- жувати еквівалентно оцінені виходи. Запи- тувач може вирішити будь-які невідповід- ності між доступною інформацією та очі- куваннями провайдера шляхом вирішення додаткової задачі або шляхом запиту до реєстру, щоб знайти додаткових провайде- рів. Слід зазначити, що можливі варіанти, коли оголошення сервісу та запиту повер- хньо виглядають різними, але вони можуть при цьому точно співпадати на основі он- тологічних визначень. Продемонструємо відношення між запитом та оголошеннями сервісів на вище наведеному прикладі сервісів (1) та (2). 1 2 2({ ( , ), ( , ), ( , ),Q owns a b wants a b owns a p ( )},Bicycle b 2 1 2 { ( , ) , ( , ) , { ( )}) owns a b owns a p Happy a    1 1 2 2({ ( , ), ( , ), ( , ),S owns a b wants a b owns a p ( )},Bicycle b 2 1{ ( , ), ( , )})owns a b owns a p  2 1 2 2({ ( , ), ( , ), ( , ),S owns a b wants a b owns a p ( )},Bicycle b 2 2{ ( , ), { ( ) ( )}owns a b Bad b Happy a  1 1( , ), { ( ) ( )}})owns a p Bad b Happy a . Очевидно, що в цьому прикладі QOut subsumes 1SOut , тобто сервіс 1S не повністю задовольняє запит, водночас, як результат співставлення сервісу 2S с запи- том Q буде Fail . Механізм співставлення забезпечує гнучку семантичну відповідність між ого- лошеннями та запитом. Єдиним питанням у ході співставлення є – чи може цей алго- ритм провести виведення між входами та виходами оголошень та запитів на основі онтологій, що доступні реєстру. Більше то- го, результат не є строго правильним або не правильним, він залежить від ступеня подібності понять у співставленні. Не зва- жаючи на таку гнучкість, алгоритм співс- тавлення відсікає оголошення, що не від- повідають запиту, та приймає, але з низь- ким рейтингом, відповідності, які можуть бути незадовільними для запитувачів. За- питувач може визначити свої побажання щодо типів відповідностей, які мають ви- конувати алгоритм співставлення, обме- жуючи при цьому мінімальний ступінь відповідності. Також може бути обмежена кількість пошуків, примушуючи алгоритм співставлення обмежити пошук в замкне- ній підмножині концептів онтології. Побудова композитного сервісу на основі Web-сервісів, які описані за допомогою ДЛ, на функціональному рівні Коли розглядається композиція сер- вісів, треба приймати до уваги зв’язки між різними Web-сервісами. Ці відношення можна класифікувати. Визначення 5 [11]. Нехай 𝓣 – ацик- лічний Tbox, 𝓐 - ABox, та сервіси iS та jS є підсервісами композитного сервіса S , тоді як сервіс iS забезпечує інший тип сервіса, ніж сервіс jS . Зв’язок R між під- сервісами iS та jS може бути визначений наступним чином:  незалежність: ijji SSSS  – кожний підсервіс є вільно незалежним від іншого та порядок їх виконання не має результатом композитний сервіс;  ідентичність: ji SS  – два сервіси забезпечують одну й ту саму послугу, але вони мають деякі різні атрибути;  умовна ідентичність: ji SS  – iS може забезпечувати ту саму функцію, що й jS у деякій ситуації;  підстановка (Substitute): iS ≺ jS – сервіс iS може заміщуватися сервісом jS у будь-якому випадку. Аналогічно, jS ≺ iS ;  умовна підстановка: iS jS – сер- віс iS може бути заміщений сервісом jS в деякій ситуації. Аналогічно, iS jS ;  перекриття: iS jS – існує час- тина перекриття між цими двома сервіса- Моделі та засоби систем баз даних і знань 47 ми. Для створення цього відношення, має бути виключена частина, що є перекрит- тям;  передумова: ji SS  – один сервіс має завершитися до початку другого. Сер- віс iS має завершитися до того, як поч- неться сервіс jS . Виходячи з цього визначення, сер- віси 1S (1) та 2S (2) є умовно ідентични- ми. Для визначених відношень серві- сів, можна сформулювати наступні тео- реми [9]. Теорема 1. Якщо iS та jS є вико- нуваними в 𝓐 відносно 𝓣, то 𝓘’, 𝓘’’, у всіх моделях 𝓘 ABox 𝓐 від- носно 𝓣, якщо виконується 𝓘’ ≡ 𝓘’’, то iS jS у випадку ABox 𝓐 відносно 𝓣. Теорема 2. Якщо iS та jS є вико- нуваними в 𝓐 відносно 𝓣, то 𝓘’, 𝓘’’, у всіх моделях 𝓘 ABox 𝓐 відносно 𝓣, якщо виконується 𝓘’ 𝓘’’, то iS ≽ jS у випадку ABox 𝓐 відносно 𝓣. Відповідно до визначення відно- шення незалежності, можна визначити па- ралельні сервіси. Паралельний сервіс [11] S – це сер- віс, який досягається відношенням неза- лежності. kSSSS 21 , де kSSS  21 еквівалентно 1SSS ik  . Це означає, що сервіси-кандидати у сервісі S можуть ви- конуватися незалежно. Сервіс kSSSS 21 є виконува- ним в 𝓐 відносно 𝓣 лише тоді, якщо кож- ний сервіс в S є виконуваним. Згідно визначенню відношення пе- редумови, можна вивести множину серві- сів, що утворює послідовний сервіс. Послідовний сервіс S [11] – це сер- віс, що досягається відношенням переду- мови, а саме kk SSSS  121 ;; . Сервіс kSSSS ;;; 21  є виконува- ним в 𝓐 відносно 𝓣, лише тоді, якщо на- ступні умови вірні у всіх моделях 𝓘 ABox 𝓐 та TBox 𝓣:  𝓘 ⊨ 1P та  для всіх i з ki 1 та всіх інтерпре- тацій 𝓘’ з 𝓘 𝓘’, маємо 𝓘’ ⊨ P(i+1) та  𝓘 𝓘’, 𝓘’ не має конфліктів. Композиція сервісів – це процес для виявлення кандидатів Web-сервісів, які можна скомбінувати у складний ланцюг, та для визначення порядку виконання для цих сервісів. Формально, задачу композиції мож- на описати кортежем < 𝓣, 𝓐, G, S > [11], де:  𝓣 описує словник прикладного до- мена;  𝓐 містить твердження про іменова- ні індивіди в термінах цього словника,а та- кож позначають вихідний стан світу;  G – множина тверджень, яка пред- ставляє ціль, якої намагаються досягти;  S – множина сервісів. Для побудови композитного сервісу пропонується використовувати підходи та алгоритми на основі методів AI плануван- ня. Для цього необхідно визначити діагра- му станів, щоб представити план та алго- ритм для знаходження відповідних канди- датів сервісів, модель для представлення задачі декомпозиції та шляхи виконання плану. Діаграма станів будується зі станів та переходів. Діаграма переходів зі стану у стан позначається станами, умовами та операціями. Стани можуть бути простими або складними. Простий стан позначається одним компонентним сервісом – дією. Складний стан – це стан, який має графіч- ну декомпозицію, яка може бути OR та AND-станами. OR – стани використовують механізм групування з метою модульності, тоді як AND-стан містить декілька облас- тей, що призначені для одночасного вико- нання. Кожне твердження G можна тран- слювати в діаграми, які заміщують вузол задачі. Таким чином, плани в діаграмі ста- нів визначаються наступним чином. Декомпозиція задачі композиції сервісів [11] – це послідовність декомпо- Моделі та засоби систем баз даних і знань 48 зицій ],,,[ 21 nTTT  , така що 1T – вихідна підзадача, nT – кінцева підзадача, та для кожного стану iT ( ni 1 ):  iT – є безпосереднім успішним результатом підзадач ],,[ 11 iTT  та не є безпосереднім успішним результатом будь-яких інших станів в ],,[ 1 ni TT  ;   jT ],,[ 11 iTT  , де jT та iT належать OR-станам діаграми;  якщо виконується вихідна задача однієї з конкурентних областей AND-ста- ну, то виконуються всі інші гілки цього AND-стану. Виходячи з цього, можна зробити наступні висновки щодо транслювання різних типів сервісів у стани діаграми: згі- дно визначенням паралельні сервіси мож- на транслювати в AND-стани; послідовні сервіси можна зв’язати один з одним; сер- віси ідентичних відношень можна транс- лювати в OR-стани. Якщо діаграма містить OR-стани, вона має декілька шляхів з ви- хідного стану в кінцевий. Кожний шлях – це окремий план для завершення виконан- ня складного сервісу. Структурування та підтримка шляху виконання відіграють ключову роль у підтримці ефективного планування. Одним з ефективних інструментів представлення множини пов’язаних дій є направлений ациклічний граф (DAG). DAG [21] – це граф, ребрам якого присво- єне направлення, та який не містить цик- лів, тобто таких шляхів, що починаються та закінчуються в одній і тій самій верши- ні. DAG забезпечує топологічний пошук, який надає допустимий (загальний) поря- док для виконання базових дій по одному. Діаграма станів перетворюється у план виконання, що представлений DAG ),( EVGG  , де },...,{ 1 nvvV  – множина сервісів та E – множина зважених направ- лених дуг, які ідентифікують залежності. Для кожної задачі iT у діаграмі станів іс- нує множина сервісів-кандидатів, які мо- жуть досягати цільового стану iT . Формально, DAG шляху досягнення задачі визначається наступним чином. Визначення 6 [11]. Задана діаграма станів декомпозиції задачі ],,,[ 21 nTTT  , DAG ),( EVGG  -представлення плану:  DAG має щонайменше два вуз- ли Start та Finish;  ),,,( 21 itiii SSSS  – множина кандидатів сервісів для задачі iT в ST та ii TE  ;  DAG містить один вузел для кожного сервісу ),,,( 21 nSSS  ;  DAG містить ребро від сервісу iS до дії jS , лише тоді, якщо jT – прямий послідовник iT . Додатково, можуть бути визначені операції об’єднання та перетину. Визначення 7 (сформульовано на ба- зі операцій об’єднання та перетину, що введені в [11]). Якщо задані два шляхи ви- конання, які представлені в DAG, ),( 1111 EVGG  та ),( 2222 EVGG  , та кін- цевий вузол 1G є начальним вузлом 2G , тоді об’єднання 1G та 2G ( 1G 2G ) – це також шлях виконання DAG. Нехай ),( 333 EVG  – це 1G 2G , що створю- ється згідно наступним крокам: 1) всі вузли в 1G та 2G розгляда- ються як атомні вузли 213 VVV  ; 2) якщо вузол 21 VVVc  , то DAG 3G розширюється cV та всіма ребра- ми, що відповідають cV ; 3) якщо вузол 21 VVVc  , тоді порівнюються ребра E1c, що відповідають cV в 1G , з ребрами E2c, що відповідають cV в 2G , тоді обираємо оптимальні ребра, щоб розгорнути 3G . Якщо задані два шляхи виконання, які представлені в DAG, ),( 1111 EVGG  та ),( 2222 EVGG  , й кінцевий вузол 1G збі- гається з кінцевим вузлом 2G , та ( 1V ⊓ 2V )−({first,finish}) ∅, тоді перетин 1G та 2G ( 21 GG  ) – також є шляхом вико- нання DAG. Нехай ),( 333 EVG  - 21 GG  створюється згідно наступним крокам: Моделі та засоби систем баз даних і знань 49 1) всі вузли в 1G та 2G розгляда- ються як атомні вузли, нехай 213 EEE  та 3V – множина, яка складається з вузлів, які примикають до кожного з ребер в 3E ; 2) якщо вузол 21 VVVc  , та 3VVc  , тоді додамо cV та пов’язані дуги, щоб розгорнути 3G . Використовуючи ці дві операції, можна інтегрувати дрібно-деталізований план в крупно-деталізований або розділити задачу великого плану на декілька дрібно- деталізованих компонент. Якщо говорити про реалізацію опи- саних методів планування, то такі техніки існують, наприклад, метод HTN плануван- ня [12]. Ключовим моментом цього гло- бального алгоритму є побудова бібліотеки планів, що представляються діаграмами станів. Загальний процес складається з трьох кроків: 1) отримання запиту користувача; 2) планувальник шукає бібліотеку плану, щоб знайти модель діаграми станів та визначити підцілі; 3) обирається шлях, який може бу- ти застосований згідно елементам контекс- ту, та генерується шлях виконання DAG. Однак, алгоритм HTN планування має ряд специфічних для нього обмежень [13]. Ці обмеження створюють проблеми щодо його застосування для задачі компо- зиції Web-сервісів. Щоб їх подолати, в [13] пропонується формалізм планування HTN- DL, який комбінує HTN формалізм з пред- ставленням ДЛ. Його ключові відмінності відносно класичних HTN систем можна сформулювати у наступних категоріях. Опис задач. Задачі описуються із використанням онтологій та співставлен- ням задачі з операторами та методами, що зроблені на базі онтології задач, а саме: символи задач представляються як кон- цепти та оператори ДЛ, а методи – як ек- земпляри. Співставлення задач частково скорочується до задачі пошуку екземпляра в ДЛ. Окрім цього, з задачами пов’язують- ся передумови та ефекти, так, що забезпе- чується більше інформації про задачу, яка використовується також для визначення співставлення сервісів. Опис оператора/метода. Визначен- ня оператора та метода використовують запити ДЛ для опису умов з передумов та ефектів. Ефекти сервісів, які традиційно не розглядаються в системах планування, представляються як екзистенціональні змінні в описах ефектів. Ефекти знань дій виражаються окремо так, що інформаційні сервіси можуть відрізнятися від сервісів, що змінюють світ. Представлення станів. Стан світу описується як база знань ДЛ. Це дозволяє використовувати дуже виразну мову пред- ставлення знань для представлення інфор- мації про світ. Традиційне в ДЛ, тверджен- ня відкритого світу адоптується у мірку- вання. Тобто ДЛ використовується як для опису дій, так й для опису станів як вираз- на мова опису знань. Стислий огляд фор- малізму, а також його формальний синтак- сис та семантика наводиться у [13]. 1. http://www.w3.org/2002/ws/ 2. Staab S., Studer R. Handbook on Ontologies. Second edition. 3. Baader Franz, Lutz Carsten, Miliˇ ci´ c Maja, Sattler Ulrike, Wolter Frank. A Description Logic Based Approach to Reasoning about Web Services. IN PROCEEDINGS OF THE WWW 2005 WORKSHOP ON WEB SERVICE SEMANTICS (WSS2005). 4. Lifschitz V. Frames in the space of situations. AIJ, 46:365–376, 1990. 5. Sandewall E. Features and Fluents. Oxford University Press, 1994. 6. Winslett M. Reasoning about action using a possible models approach. In Proc. of AAAI- 88, pages 89–93, Saint Paul, MN, 1988. 7. Reiter R. Knowledge in Action. MIT Press, 2001. 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- http://www.w3.org/2002/ws/ Моделі та засоби систем баз даних і знань 50 IRST), Michal Zaremba (NUIG). 2005. KWEB/2005/D2.4.6A/v1.0 10. Semantic Matching of Web Service Capabilities. Massimo Paolucci, Takahiro Kawamora, Terry R. Payne, Katya Sycara. 11. Semantic Web Services Composition Using AI planning of Description Logics. Lirong Qiu" Fen Lin" Changlin Wan" Zhongzhi Shi *Key Laboratory of Intelligent Information Processing, Institute of Computing Technology, Chinese Academy of Sciences, 100080, Beijing, China "Graduate School of the Chinese Academy of Sciences, 100039, Beijing, China {qiulr, linf, wancl, shizz}@ics.ict.ac.cn 12. Kutluhan Erol, James Hendler, and Nau Dana S. Htn planning: complexity and expressivity. In Proceedings of the twelfth national conference on Artificial intelligence (vol. 2), pages 1123–1128. American Association for Artificial Intelligence, 1994. 13. Combining Description Logic Reasoning with AI Planning for Composition of WEB Services. Evren Sirin, Doctor of Philosophy, 2006. 14. http://www.dh.cs.fau.de/IMMD8/Lectures/K RR/08a-DL_KB-4.pdf 15. https://www.ics.forth.gr/tech- reports/2010/2010.TR409_Automated_Web_ Service_Composition.pdf 16. https://ru.wikipedia.org 17. Web Service composition: Semantic Links based approach. Freddy L´ecu´, Doctor of Philosophy, 2008. 18. A Conceptual and Formal Framework for Semantic Web Services (v1). Holger Lausen, Francisco Martin-Recuerda, Jos de-Bruijn, and Michael Stollberg (University of Innsbruck) 19. A Proposal for Describing Services with DLs. Carsten Lutz and Ulrike Sattler {lutz, sattler}@cs.rwth-aachen.de 20. Semantic Web Service Composition Based on a Closed World Assumption. Freddy L´ecu´ e, Alain L´eger, France Telecom R&D, France 4 rue du clos courtel, F-35512 Cesson S´evign´ e {(freddy.lecue, alain.leger)@orange- ft.com}, ´Ecole Nationale Sup´erieure des Mines de St-Etienne, France 158, cours Fauriel, F-42023 Saint-´Etienne, http://ieeexplore.ieee.org, 2006 21. http://life-prog.ru/view_zam2.php?id= 204&cat=5&page=13 22. 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 23. http://www.roseindia.net/webservices/Web- Services-technology.shtml 24. http://www.informit.com/articles/article.aspx? p=336265 25. Formal Description of Web Services for Expressive Matchmaking. Dipl.-Inform. Sudhir Agarwal, 2007 Karlsruhe Одержано 11.09.2014 Про автора: Захарова Ольга Вікторівна, кандидат технічних наук, старший науковий співробітник. Місце роботи автора: Інститут програмних систем НАН України, Проспект Академіка Глушкова, 40. Тел.: 526 51 39. E-mail: ozakharova68@gmail.com. mailto:shizz%7d@ics.ict.ac.cn http://www.dh.cs.fau.de/IMMD8/Lectures/KRR/08a-DL_KB-4.pdf http://www.dh.cs.fau.de/IMMD8/Lectures/KRR/08a-DL_KB-4.pdf https://www.ics.forth.gr/tech-reports/2010/2010.TR409_Automated_Web_Service_Composition.pdf https://www.ics.forth.gr/tech-reports/2010/2010.TR409_Automated_Web_Service_Composition.pdf https://www.ics.forth.gr/tech-reports/2010/2010.TR409_Automated_Web_Service_Composition.pdf https://ru.wikipedia.org/ mailto:sattler%7d@cs.rwth-aachen.de 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.roseindia.net/webservices/Web-Services-technology.shtml http://www.roseindia.net/webservices/Web-Services-technology.shtml http://www.informit.com/articles/article.aspx?p=336265 http://www.informit.com/articles/article.aspx?p=336265

Descriptive logic using in Web-service problems

Institution

Ähnliche Einträge