ВІКІСТОРІНКА
Навигация:
Інформатика
Історія
Автоматизація
Адміністрування
Антропологія
Архітектура
Біологія
Будівництво
Бухгалтерія
Військова наука
Виробництво
Географія
Геологія
Господарство
Демографія
Екологія
Економіка
Електроніка
Енергетика
Журналістика
Кінематографія
Комп'ютеризація
Креслення
Кулінарія
Культура
Культура
Лінгвістика
Література
Лексикологія
Логіка
Маркетинг
Математика
Медицина
Менеджмент
Металургія
Метрологія
Мистецтво
Музика
Наукознавство
Освіта
Охорона Праці
Підприємництво
Педагогіка
Поліграфія
Право
Приладобудування
Програмування
Психологія
Радіозв'язок
Релігія
Риторика
Соціологія
Спорт
Стандартизація
Статистика
Технології
Торгівля
Транспорт
Фізіологія
Фізика
Філософія
Фінанси
Фармакологія


Ключові абстракції й механізми

Ключові абстракції

Пошук і вибір ключових абстракцій. Ключова абстракція — це клас або об'єкт, що входить у словник ПО. Найголовніша цінність ключових абстракцій полягає в тому, що вони визначають межі нашої проблеми: виділяють те, що входить у нашу систему й тому важливе для нас, і усувають зайве. Завдання виділення таких абстракцій специфічні для предметної області. Правильний вибір об'єктів залежить від призначення ІС і ступеня детальності опрацювання інформації.

Як ми вже відзначали, визначення ключових абстракцій містить у собі два процеси: відкриття й винахід. Ми відкриваємо абстракції, слухаючи фахівців із ПО: якщо експерт про неї говорить, то ця абстракція дійсно важлива. Винаходячи, ми створюємо нові класи і об'єкти, які не обов'язково є частиною предметної області, але корисні під час проектування або реалізації системи. Наприклад, користувач банкомату говорить "рахунок, зняти, покласти"; ці терміни — частина словника предметної області. Розробник системи використовує їх, але додає свої, такі як база даних, диспетчер екрану, список, черга і таке інше. Ці ключові абстракції створені вже не предметною областю, а проектуванням.

Найпотужніший спосіб виділення ключових абстракцій — зводити задачу до вже відомих класів і об'єктів. Через відсутність таких повторно використовуваних абстракцій ми рекомендуємо користуватися сценаріями, щоб виконувати процес ідентифікації класів і об'єктів.

Уточнення ключових абстракцій.Визначивши кандидатів на ролі ключових абстракцій, ми повинні оцінити їх за такими критеріями. Програміст має задавати собі запитання: Як створюються об'єкти класу? Як можна копіювати і/або знищувати об'єкти класу? Які операції можуть бути виконані над цим об'єктом? Якщо відповіді на ці запитання дати важко, то, можливо, загальна концепція не зрозуміла, і краще сісти й подумати ще раз, ніж відразу розпочати програмування.

Визначивши нові абстракції, ми маємо знайти їх місце в контексті наявних класів і об'єктів. Не варто намагатися робити це строго зверху вниз або знизу вгору. Немає особливої необхідності будувати ієрархію класів, починаючи з найвищого класу, і потім доповнювати її підкласами. Частіше ви створюєте кілька незалежних ієрархій, усвідомлюєте їх загальні риси й виділяєте один або кілька суперкласів. Треба кілька проходжень вверх й вниз ієрархією, щоб створити програмний проект. Це лише спостереження, яке базується на досвіді й підтверджує той факт, що об’єктно-орієнтоване проектування — процес послідовних наближень. Найчастіші реорганізації в ієрархії класів — це відомість співпаданих частин двох класів в один і поділ класу на два нових.

Важко відразу розташувати класи й об'єкти на певних рівнях абстракції. Іноді, знайшовши важливий клас, ми можемо пересунути його нагору в ієрархії класів, тим самим збільшуючи ступінь повторності використання коду. Це називається просуванням класу. Аналогічно, можемо дійти висновку, що клас занадто узагальнений, і це ускладнює успадкування: відбувається семантичний розрив або конфлікт зернистості. В обох випадках ми намагаємося виявити зчеплення або недостатню зв’язність абстракцій і зм'якшити конфлікт.

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

Існують такі правила:

· об'єкти варто називати іменниками: theSensor або shape;

· класи варто називати узагальненими іменниками: Sensors, Shapes;

· операції-модифікатори варто називати активними дієсловами: Draw, moveLeft;

· операції-селектори повинні містити запит або форму дієслова "to be": extentOf, isOpen;

· підкреслення й використання великих літер — на ваш розсуд, постарайтеся лише не суперечити самі собі.

Ідентифікація механізмів

Як знайти механізми? У попередньому обговоренні ми називали механізмами структури, за допомогою яких об'єкти взаємодіють один з одним і поводяться так, як потрібно. Як при розробленні класу фактично визначається поведінка окремих об'єктів, так само й механізми служать для задання поведінки сукупності об'єктів. Отже, механізми відображають шаблони поведінки.

Розглянемо вимогу, яка ставиться до автомобіля: натискання на акселератор має приводити до збільшення обертів двигуна, а відпускання акселератора — до їх зменшення. Як це відбувається, водієві зовсім байдуже. Може бути використаний будь-який механізм, який забезпечує потрібну поведінку, і його вибір — справа смаку розробника. Наприклад, припустимо кожне із запропонованих нижче інженерних рішень:

· механічний зв'язок між акселератором і карбюратором (звичайне рішення);

· під педаллю ставиться давач тиску, що з'єднується з комп'ютером, який керує карбюратором (механізм керування через дроти);

· карбюратора немає; бак із пальним розташований на даху автомобіля й паливо вільно тече у двигун; потік палива регулюється затискачем на трубці; натискання на педаль акселератора послабляє затискач (дуже дешево).

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

Ключові абстракції визначають словник предметної області, механізми визначають суть проекту. У процесі проектування розробник має придумати не тільки наповнення класів, але й те, як об'єкти цих класів будуть взаємодіяти один з одним. Механізм взаємодії розкладається на методи класів. У підсумку протокол класу буде відображати поведінку його об'єктів і роботу механізмів, в яких вони беруть участь.

Отже, механізми являють собою стратегічні рішення в проектуванні, подібно до проектування структури класів. З іншого боку, проектування інтерфейсу якогось одного класу — це швидше тактичне рішення. Стратегічні рішення повинні виконуватися явно, інакше ми отримаємо неорганізований набір об'єктів, що кидаються виконувати роботу, розштовхуючи один одного. У найелегантніших, найстрункіших і найшвидших програмах втілені ретельно розроблені механізми.

Механізми відображають лише один із шаблонів, які ми знаходимо в структурованих системах. Так, на нижньому кінці своєрідної біологічної піраміди перебувають ідіоми. Наприклад, в CLOS не прийнято використовувати підкреслення в іменах функцій або змінних, хоча в Ada ця справа звична. Вивчаючи мову, доводиться вчити її ідіоми, які зазвичай передаються у формі фольклору. Однак, ідіоми відіграють важливу роль в кодифікації шаблонів низького рівня. Багато звичних програмістських дій ідіоматичні і тому розпізнавання таких ідіом дозволяє використовувати конструкції C++ для вираження функціональності поза самою цією мовою зі збереженням ілюзії, що вони є частиною мови.

Місце на верху піраміди займає середовище розроблення. Середовище розроблення — це набір класів, призначених для певної прикладної ситуації. Середовище дає готові класи, механізми й послуги, якими можна відразу користуватися або пристосовувати для своїх потреб.

Якщо ідіоми становлять частину програмістської культури, то середовища розроблення — комерційний продукт. Наприклад, Apple MacApp і його спадкоємець Bedrock — середовища, написані на C++ і призначені для побудови ІС зі стандартним інтерфейсом користувача Macintosh. Аналогічну роль для Windows відіграють Microsoft Foundation Classes і ObjectWindows корпорації Borland.

Висновки

· Ідентифікація класів і об'єктів — найважливіше завдання об’єктно-орієнтованого проектування; процес ідентифікації складається з відкриття й винаходу.

· Класифікація є проблемою групування (кластеризації) об'єктів.

· Класифікація — процес послідовних наближень; проблеми класифікації обумовлені, в основному, тим, що є багато рівноправних рішень.

· Є три підходи до класифікації: класичний розподіл за категоріями (класифікація за властивостями), концептуальна кластеризація (класифікація за поняттями) і теорія прототипів (класифікація за подібністю із прототипом).

· Метод сценаріїв — це потужний засіб об’єктно-орієнтованого аналізу, його можна використати для інших методів: класичного аналізу, аналізу поведінки й аналізу предметної області.

· Ключові абстракції відображають словник предметної області; їх шукають в самій області або придумують у процесі проектування.

· Механізми позначають стратегічні проектні рішення щодо спільної діяльності об'єктів багатьох різних типів.

Запитання для повторення та контролю знань

1. Важливість правильної класифікації.

2. Складнощі класифікації.

3. Ідентифікація класів і об'єктів.

4. CRC-картки.

5. Ключові абстракції.

6. Ідентифікація механізмів.

 

РОЗДІЛ 6. ОНТОЛОГІЇ Й ОНТОЛОГІЧНІ СИСТЕМИ

¨ Основні визначення

¨ Моделі онтологій. Онтологічні системи

¨ Системи і засоби подання онтологічних знань

У цьому розділі дається поняття онтології, розглядаються онтологічні системи. Описано моделі онтологій і їх використання під час розроблення інтелектуальних систем. У кінці розділу описано системи та засоби подання онтологічних знань.

6.1. Поняття онтології

Онтологія (від грец. онтос — суще, логос — навчання, по­няття) — термін, що визначає вчення про буття, про сутність, на відміну від гносеології — вчення про пізнання. Вже у X.Вольфа (1679-1754), автора терміну «онтологія», вчення про буття бу­ло відокремлене від вчення про пізнання. Tермін введений у філософську літературу німецьким філософом Р.Гокленіусом (1547-1628). До цього онтологія була частиною метафізи­ки, наукою самостійною, незалежною і не пов’язаною з логікою, з «практичною філософією», з науками про приро­ду. Її предмет складає вивчення абстрактних і загальних філо­софських категорій, таких як буття, субстанція, причина, дія, явище тощо, а сама онтологія як наука домагалася повного по­яснення причин усіх явищ.

Зрозуміло, що таке визначення трохи недоречне для прак­тичного використання, але дає поштовх для подальшої конк­ретизації й обговорення, виходячи з цілей цього видання. У цьому значенні цікавіше визначення онтології, запропоно­ване в межах розроблення системи стандартів на мультиаґентні системи міжнародним співтовариством FIPA (Foundation for Intelligent Physical Agents). У філософському розумінні можна посилатися на онтологію як на певну систему категорій, що є наслідком певного погляду на світ.

При цьому сама система категорій не залежить від кон­кретної мови: онтологія Арістотеля завжди одна і та сама, неза­лежно від мови, використаної для її опису.

З іншої точки зору, ближчої до понять, пов’язаних зі штуч­ним інтелектом, онтологія — це знання, формально відображені на базі концептуалізації. Концептуалізація, як вже об­говорювалося вище, припускає опис безлічі об’єктів і понять, знань про них і зв’язків між ними. Отже, онтологією на­зивається експліцитна специфікація концептуалізації. Фор­мально онтологія складається з термінів, організованих в так­сономію, їх визначень і атрибутів, а також пов’язаних з ними аксіом і правил виведення.

Часто набір припущень, що становлять онтологію, має форму логічної теорії першого порядку, де терміни словника є іменами унарних і бінарних предикатів, званих відповідно концептами і відношеннями. У простому випадку онтологія описує тільки ієрархію концептів, зв’язаних відношеннями категоризації. У складніших випадках в неї додаються відповідні аксіоми для вираження інших відношень між концеп­тами і для того, щоб обмежити їх передбачувану інтерпре­тацію. Враховуючи вищесказане, онтологія є базою знань, що описує факти, які передбачаються завжди істинними в рам­ках певної спільноти на основі загальноприйнятого значення використовуваного словника.

Ще конкретнішим поняття онтології є у відомому проекті Оntolingua, який активно розробляється у Стенфордському університеті. Тут передбачається, що онтологія — це експліцитна специфікація певної теми.

Такий підхід припускає формальне і декларативне подання деякої теми, яке включає словник (або список констант) для посилання до термінів предметної області, обмеження ціліс­ності на терміни, логічні твердження, які обмежують інтерпре­тацію термінів і те, як вони поєднуються один з одним.

Резюмуючи вищесказане, можна констатувати, що на сьо­годні розуміння терміну «онтологія» різне, залежно від контекс­ту і цілей його використання. У роботі [44] дане достатньо змістовне і цікаве обговорення цих питань, яке зводиться до того, що тут виділяються такі аспекти інтерпретації цьо­го терміну:

1) онтологія як філософська дисципліна;

2) онтологія як неформальна концептуальна система;

3) онтологія як формальний погляд на семантику;

4) онтологія як специфікація «концептуалізації»;

5) онтологія як уявлення концептуальної системи через логічну теорію, що характеризується:

· спеціальними формальними властивостями,

· її призначенням;

6) онтологія як словник, використовуваний логічною теорією;

7) онтологія як метарівнева специфікація логічної теорії.

Зазначимо, що перша інтерпретація радикально від­різняється від інших і пов’язана, як пропонують автори ви­щезгаданої роботи, з тим, що тут ми говоримо про Онтологію (з великої літери) і маємо на увазі філософську дисципліну, що вивчає, за Арістотелем, природу й організацію сущого. У цьому значенні Онтологія намагається відповісти на запи­тання: «Що є суще?» або, в іншому формулюванні, на запитан­ня: «Які властивості є загальними для всього сущого?». Коли ж ми говоримо про онтологію (з маленької літери), то поси­лаємося на об’єкт, природа якого може бути різною, залежно від вибору між інтерпретаціями 2-7. За другою інтерпре­тацією онтологія є концептуальною системою, яку ми можемо припускати як базис визначеної БЗ. Згідно з інтерпрета­цією 3 онтологія, на основі якої побудована БЗ, виражається в термінах відповідних формальних структур на семантично­му рівні. Отже, ці дві інтерпретації розглядають онтологію як концептуальну «семантичну» сутність, неважливо — формаль­ну чи неформальну, тоді як інтерпретації 5-7 трактують онто­логію як спеціальний «синтаксичний» об’єкт. Інтерпретація, що залишилася, четверта, яка була запропонована Грубером як визначення онтології для використання в рамках ШІ-спільноти, — одна з найпроблематичніших, оскільки точне значення її залежить від розуміння термінів «специфі­кація» і «концептуалізація». І разом з тим, саме це визначення найчастіше і використовується сьогодні в роботах з проекту­вання і дослідження онтології.

Для визначеності подальшого викладу ми вважатимемо, що онтології — це бази знань (БЗ) спеціального типу, які можуть «читати­ся» і розумітися, відчужуватися від розробника чи фізично розділятися їх користувачами.

При цьому онтологічний інжиніринґ — гілка інженерії знань, яка використовує Онтологію (з великої букви) для побу­дови онтології (з маленької букви). Зрозуміло, що будь-яка онтологія має під собою концептуалізацію, але одна концептуалізація може бути основою різних онтологій, і дві різні БЗ можуть відображати одну онтологію.

Історично, онтології виникли з гілки філософії, відомої як метафізика, яка працює з природою реальності та буття. Ця фундаментальна гілка аналізує різноманітні типи моделей буття, часто з особливою увагою до зв’язків між частковим і загальним, внутрішнім і зовнішнім, існуванням і буттям.

У середині 70-х років ХХ ст. дослідники в галузі штучного інтелекту зрозуміли, що збирання знань — це ключ до побудови великих і потужних систем штучного інтелекту. Дослідники обговорювали можливість створення онтологій як інструменту чисельного моделювання, що дає змогу виконувати логічне виведення знань. У 80-х роках ХХ ст. дослідники прийшли до висновку, що термін «онтологія» може використовуватися у двох значеннях. По-перше, онтологія — це компонент систем, що базуються на знаннях, по-друге, — це змодельована за допомогою формальних засобів частина реального світу.

На початку 90-х минулого століття років робота Тома Грубера «Майбутні принципи проектування онтологій для поширення та колективного використання знань» містила визначення онтології як технічного терміну в комп’ютерних науках. Грубер описував термін «онтологія» як специфікацію концептуалізації деякої області. Це означало, що онтологія — це опис концептів і зв’язків між ними, які існують для деякої множини аґентів. Це визначення узгоджується з використанням онтологій як множини визначень концептів, але є більш загальним, і, звичайно, має інший сенс, ніж у філософії. Онтології часто порівнюють з таксономічними ієрархіями класів і з визначеннями класів з категоризацією зв’язків, але онтології не обмежуються лише цими формами. Онтології не обмежуються консервативними визначеннями, на зразок систем теорем та аксіом.

Формування семантичного Webу почалось з розроблення мови RDF консорціумом W3C. Але історія роботи з метаданими у W3C почалася 1995 року з появою PICS (Platform for Internet Content Selection). PICS — це механізм для передавання комунікаційних ярликів Web-сторінок від сервера до клієнта. Ці ярлики містили інформацію про вміст Web-сторінок, для прикладу, про рецензовані наукові статті, розміщені на сторінці, чи про авторизацію ресурсу акредитованим дослідником. Також ярлики часто містили публічні дані авторів сторінок, посилання на іншомовні версії сторінки тощо. Замість того, щоб визначити фіксований набір критеріїв, PICS забезпечувала загальний механізм створення ярликових систем. Різні організації визначали власний вміст сайту, залежно від їхніх цілей, необхідності і користувачів. Розроблення PICS мотивувалося тим, що назрівають зміни у Webі, причому ці зміни мали стосуватися, в основному, різного роду обмежень у США та інших країнах.

Після серії обговорень, були ідентифіковані обмеження в PICS, і змінилися функціональні вимоги. Вимоги почали охоплювати загальніші проблеми, ніж асоціація дескриптивної інформації з Інтернет-ресурсами, базованими на PICS архітектурі. Як результат, W3C створив нову робочу групу PICS-NG (Next Generation), яка почала досліджувати загальніші проблеми опису ресурсів.

Через деякий час нова команда розробила попередню специфікацію документу PICSMOD, який визначав новий формат. Цей формат відразу був застосований у кількох, різних за своєю структурою, аплікаціях і при цьому він залишився незмінним. Побачивши результат, W3C сконсолідував групу для роботи над RDF. Нова група була названа «W3C Resource Description Framework working group».

Мова RDF стала результатом роботи численних об’єднань спеціалістів, що займалися дослідженням метаданих. У RDF є кілька попередників. Технічно найближчим до RDF був проект MCF, ініційований Раманатаном Гуа в компанії «Apple Computer» і продовжений після купівлі цього проекту компанією Netscape. Ідеї «Dublin Core» та PICS також мали ключове значення при створенні RDF.

Специфікація RDF-моделі та її XML-синтаксис був опублікований 1999 року у вигляді W3C-рекомендації. Потім почалася робота над створенням нових пов’язаних специфікацій, які були опубліковані 2004 року.

Історія онтологічних розроблень у комп’ютерних науках досить давня. Починаючи з 90-х минулого століття років частина дослідників намагалася поширити ідеї про використання знань у Webі. Ці дослідження включали створення різноманітних мов, базованих на HTML (наприклад, SHOE), на XML(XOL, пізніше OIL) та на фреймах.

OWL, в основному, базований на дослідженнях DARPA (Defense Advanced Research Projects Agency), які створили мову DAML+OIL. Вона своєю чергою, базувалася на мовах DAML та OIL.

World Wide Web Consortium створив робочу групу "Web Ontology Working Group", яка почала роботу 1 листопада 2001 року очолювалася Джеймсом Хендлером та Гусом Скрейбером. Перший робочий документ був опублікований в липні 2002 року. Документ став офіційною рекомендацією W3C 10 лютого 2004 року. Група була розформована 31 травня 2004 року.

Одним із найскладніших і найдовших етапів у формуванні семантичного Webу є створення SPARQL (Simple Protocol and RDF Query Language) — мови запитів до RDF, яка розроблена групою DAWG (RDF Data Access Working Group).

Спочатку, в квітні 2006 року, SPARQL була подана як кандидат W3C - рекомендації, але потім її повернули на доопрацювання у статусі робочого стандарту. У червні 2007 року SPARQL знову висувається в кандидати до рекомендації. 12 листопада 2007 року SPARQL став запропонована до рекомендації і 15 січня 2008 року стала офіційною рекомендацією W3C.

Мова SPARQL дозволяє робити запити за допомогою триплетів «суб’єкт-предикат-об’єкт», кон’юнкцій, диз’юнкцій та необов’язкових шаблонів. Існує кілька реалізацій SPARQL для програмних мов, зокрема для Java.

Загалом RDF, SPARQL та OWL створюють цілісну картину засобів семантичного Webу, необхідних для побудови онтологічних моделей.

У книзі «Семантичний Web: введення в майбутнє XML, Web сервісів та управління знаннями» М. Даконта та інші автори описали, що таке RDF, чому вона не користувалася популярністю і чому виникли онтології. Автору дають таке пояснення, що таке RDF. На найпростішому рівні RDF є XML базованою мовою для опису ресурсів. Якщо XML має метадані лише в частині документу, то RDF описує всі метадані, які необхідні для опису знань в документі. Дуже хорошим прикладом використання RDF є опис ресурсів, які є невидимими для користувача, наприклад, аудіофайли.

Модель RDF складається із тверджень (триплетів), кожен з яких складається з суб’єкта, предиката та об’єкту. На рис. 6.1 наведено RDF-твердження.

Рис. 6.1.RDF твердження.

Суб’єкт. Граматично суб’єкт — це іменник, який в реченні виконує певну дію. Наприклад, у реченні «Компанія купує продукт» суб’єктом є «компанія». У RDF суб’єкт — це ресурс, інформація про який описується в предикаті та об’єкті. Тому для ідентифікації суб’єкту використовується URI (Unified Resource Identifier), наприклад, «http://www.business.org/ontology/#company».

Предикат. Граматично предикат є дієсловом чи дієслівним зворотом, наприклад, у тому самому реченні «Компанія купує продукт» предикат — «купує». Іншими словами предикат каже нам щось про суб’єкт. У RDF предикат є зв’язком між суб’єктом та об’єктом. Тому, предикат у RDF подається як URI на зразок: «http://www.business.org/ontology/#buy» .

Об’єкт. Граматично об’єкт є іменником, якого стосується дія задана в дієслові (предикаті). У попередньому прикладі об’єктом є «продукт». У RDF об’єкт — це ресурс або літерал, пов’язаний предикатом. У прикладі об’єкт має такий URI: «http://www.business.org/ontology/#product», але в загальному випадку об’єктом може бути літеральне значення, наприклад, «Змінна рівна 5», де 5 — літеральне значення об’єкту.

Твердження. У RDF сукупність суб’єкту, предиката та об’єкту прийнято називати твердженням. Наприклад, у N3 (Notation3) твердження називають триплетами.

М.Даконта та інші автори у своїй книзі також пояснили причини, чому RDF активно не використовується. По-перше, мова RDF не достатньо добре інтеґрується в XML-файли. Це пояснюється тим, що RDF завжди має простір імен, тоді як XML чи XHTML-документи можуть описувати лише дані без необхідних інфраструктурних елементів метаданих (таких як простори імен). Хоча RDF-об’єкти серіалізуються так само, як і XML об’єкти, все ж існувала проблема інтеґрації RDF у XHTML та XML. Виправивши синтаксис, робоча група W3C із RDF вирішила цю проблему інтеґрації. Для прикладу, існують спеціальні утиліти на зразок SMORE, які вміють читати вкладені RDF документи в HTML та XHTML.

Рис. 6.2. Порівняння використання технологій RDF та XML.

По-друге, мова RDF складніша, ніж XML, яка своєю чергою не є достатньо читабельною для розробників і через це складною. Складність RDF полягає в тому, що насправді в RDF-документах існують і дані, і метадані, які також мають складний синтаксис. Тобто при роботі з RDF треба знати не лише ієрархічну структуру даних, але й ієрархічну структуру метаданих, які тісно між собою переплітаються.

Автори книги навели статистику (рис. 6.2) щодо кількості книжок, програмних продуктів та сайтів компаній, присвячених використанню RDF та XML відповідно. Статистика яскраво показує, що використання XML суттєво перевищує RDF, і що більше реальні програмні продукти з використанням RDF фактично не створюються.

Отже, виникла гостра необхідність створити нову мову, яка б описувала знання на вищому рівні абстракції, ніж звичайні Web-ресурси, як це робить RDF. Тому виникла мова OWL. Вона була покликана змінити типову архітектуру систем з метою перетворити дані у знання, а системи зробити ближчими до реального світу. На рис. 6.3 наведено типовий процес роботи зі знаннями.

На першому рівні відбувається ввід інформації з певного джерела (від людей, з джерел даних таких як бази даних, Інтернет тощо).

На другому рівні відбувається продукування, на якому дані записуються в базу даних, цифрові файли чи пошукову машину. Основною проблемою є те, що група чи проект вводять одну і ту саму інформацію по-різному. Як результат отримують багато жорстко-зв’язаних систем.

Третім рівнем процесу може бути (а може й не бути) інтеґрація, яка залежить від складності інформаційної структури комплексу. Оскільки всі інформаційні системи є жорстко-зв’язаними, то зазвичай інтеґрація цих систем для отримання цілісної картини є не дуже хорошим рішенням. Відповідно, процес інтеґрації систем не буде містити повторюваних частин, тобто кожен раз інтеґрацію треба буде починати спочатку. Якщо навіть існує інтеґраційне рішення, то корпорації платять великі гроші інтеґраторам за дуже дорогу інформаційну систему, що буде інтеґрувати інші системи.

Четвертий рівень процесу — пошук знань серед внутрішніх ресурсів корпорації (необов’язково включаючи інтеґраційну систему). Це довготривалий та, за суттю, майже випадковий процес. Понад усе, часто інформація, яка шукається, може бути недостатньо релевантною через свою загальність.

Наступний рівень — це утворена програма з результатів пошуку. Із цієї системи можна отримати, зазвичай, презентацію чи звіт. Після того, як новий продукт створений, результати звітів можуть зберігатися, але зазвичай вони ще складніше класифікуються, ніж жорстко-зв’язані системи. Ще одною проблемою в системах такого роду є версифікація документів, адже перебирати кожен раз документи у всіх системах нереально, а явну версифікацію запроваджувати для всіх файлів теж дуже складно. Ну і нарешті, останньою постає проблема повторного використання даних.

Рис. 6.3. Процес роботи зі знаннями в типових системах.

Як результат така система знань має дуже складну архітектуру, і тому її важко інтеґрувати з іншими системами. При інтеґрації треба дотримуватися такого правила: системи не можуть розпізнавати одна одну, якщо вони не працюють через однаковий контракт. Інформаційний контракт декларує способи взаємодії систем таким чином, що одна система підтримує контракт, а інша, знаючи про його існування, використовує цей контракт як вхідний інтерфейс системи. У загальному випадку такий контракт треба спеціально описувати. У випадку з онтологіями сама онтологія є контрактом між двома системами, які інтеґруються.

Тепер онтології все частіше використовуються в реальних проектах. Переваги онтологій:

¨ використання єдиних термінів у біохімічних знаннях пришвидшує розроблення, а також дає можливість передавати знання;

¨ онтології забезпечують додаткові можливості з формування і тестування наукових тез, з опрацювання даних на природній мові, з інтеґрації даних.

Одним із прикладів проектів, які використовують онтологій для роботи з біохімічними знаннями, є GONG. Він був спрямований на ґенерацію генетичної онтології GO (Gene Ontology).

Іншими прикладами розроблених онтологій в галузі біохімії є онтологія DOLCE та онтологія Ontology Works. Вони містять формальні визначення базових елементів в біохімії (процесів, подій, випадків, типів тощо).

Висновки, які випливають наступні. Проекти GONG, DOLCE та інші описують частину загальних характеристик біологічних даних. Основною метою роботи була оцінка складності використання загальноприйнятих технік моделювання за допомогою онтологій. Автори переконують, що використання онтологій допоможе описувати різноманітні аспекти біохімії та молекулярної біології розподілено та дистанційно. Біохімічні онтології використовуються як основа побудови баз даних для зберігання інформації. Як результат роботи створений спеціальний стандарт XML — SBML (Systems Biology Markup Language), який використовується для обміну інформацією між імітаційними моделями біохімічних реакцій.

У [144] описане використання онтологій у блогах з відкритим кодом. Проект VIStology’s IBlogs покликаний розробити розподілену інтелектуальну систему для автоматичного моніторинґу блогів. У проекті розроблені онтологія Blog та онтологія News Event. Вони дають можливість отримувати знання з блогів і передавати їх у вигляді стрічок новин RSS.

Автори підводять підсумки своєї роботи: проект IBlogs робить перші кроки в побудові технології, яка повинна вирішити проблему аналізу, інтерпретації та аґреґації вмісту блогів. Проект демонструє, що використання онтологій є корисним для перегляду інформації про блоги та взаємозв’язки між його складовими — публікаціями, у вигляді невеликих заміток про нові події, методи, технології тощо.

Стаття про моделювання знань в системі EON [6] описує як використовувати систему для побудови інформаційних моделей знань про пацієнтів, медичні спеціальності та про медичні рішення і дії у відповідних випадках. Система EON має складну серверну архітектуру, складається з багатьох компонентів, обмін між якими здійснюється за допомогою онтологій.

За визначенням авторів, система EON створена для структурування інформації про пацієнтів, медичні концепції та загальні знання. У цій системі клінічні рекомендації можуть бути інтерпретовані для читання пацієнтами чи для формування таксономічних ієрархій медичних термінів.

У статті [42] описується, як за допомогою онтологій та правил можна порівнювати різні ступені та оцінки у різноманітних системах оцінювання. Наводиться приклад порівняння оцінок у північно американських (оцінки від “F” до “A+”), східноєвропейських (оцінки від “2” до “5”) та інших вузах.

На основі GO (Gene Ontology), яка згадувалася раніше, розроблені засоби для анотації біомедичних даних. Ці засоби є базованими на онтологіях і дають можливість не лише індексувати біомедичні ресурси, але й давати доступ до інформації про них на Web-сторінках. Архітектура системи побудована так, щоб вона інтеґрувалася з Web-порталом з одного боку, і щоб видобувала знання з різнотипних ресурсів з іншого.

У підсумку роботи над GO (Gene Ontology) описана реалізація прототипу системи анотування, базованої на онтологіях. Завданням системи було описати велику кількість біомедичних ресурсів для створення каталогу анотованих елементів. Ресурси NCBO (National Center for Biomedical Ontology) складені в найбільшу бібліотеку біомедичних ресурсів, і система анотування дозволяє користувачеві знаходити різноманітну біомедичну інформацію, використовуючи одну точку входу, тобто єдиний репозиторій знань і, отже, не витрачати час на пошук біомедичних ресурсів у Webі. Система здатна опрацьовувати метадані з множинами генетичних виразів, радіологічних рисунків, клінічних звітів тощо, перетворюючи їх у відповідні онтології.

У середовищах eHealth використовуються онтології для поширення клінічних знань та даних про онкологічні дослідження. В eHealth описано процес створення онтологій, які повинні максимально відповідати реаліям в сучасних дослідженнях та відображеннях знань. Причини вибору онтологій як засобу відображеннях знань:

¨ логічна структура, яку можна алгоритмічно опрацьовувати;

¨ пряма відповідність термінів та знань;

¨ інтероперабельність (можливість взаємодії мереж).

Висновки, зроблені авторами, є наступними. Середовища eHealth надають зручні та корисні утиліти для роботи з біомедичними онтологіями. Досягнуто консенсусу між розробниками у великій кількості аспектів, пов’язаних з описом знань, алгоритмами роботи тощо.

Абсолютно очевидним є той факт, що онтології набули найбільшого використання в біомедичній галузі. Основною причиною є те, що знання в медицині є неточними та часто слабо формалізованими. До початку використання онтологій в медицині існувала велика кількість аплікацій, які по різному трактували одні і ті самі поняття. На сьогодні ситуація суттєво покращилась за рахунок можливості загального доступу до знань. Системи стали менш залежними одна від одної. Цього намагалися досягти розробники онтологій. Також онтології починають активно застосовувати для добре досліджених предметних областей, наприклад, блогів, об’єднань людей, форумів тощо.

6.2. Моделі онтології й онтологічної системи

Вище вже наголошувалося, що поняття онтології припускає визначення і використання взаємозв’язаної та взаємоузгодженої сукупності трьох компонентів: таксономії термінів, визна­чень термінів і правил їх опрацювання. Враховуючи це, введемо наступне визначення поняття моделі онтології.

Під формальною моделлю онтології О будемо розуміти впорядковану трійку такого вигляду:

О = <С, R, F>,

деС —скінченна множина концептів (понять, термінів) предметної області, яку задає онтологія О; R— скінченна множина відношення між концептами (поняттями, термінами) заданої предметної області; F — скінченна множина функцій інтерпретації (аксіоматизація), заданих на концептах чи відношеннях онтології О.

Зазначимо, що природним обмеженням, що накладається на множину С, є його скінченність і непустота. Інша справа з компонентами Fі R у визначенні онтології О. Зрозуміло, що і в цьому випадку F і R мають бути скінченними множинами. Розглянемо окремі випадки, коли ці множини порожні.

Нехай R = Ø і F= Ø. Тоді онтологія Отрансформується у простий словник:

О = V = <С, {}, {}>.

Така вироджена онтологія може бути корисна для спе­цифікації, поповнення і підтримки словників ПО, але онто­логічні словники мають обмежене використання, оскільки не вводять експліцитно значення термінів. Хоча в деяких випад­ках, коли використовувані терміни належать до дуже вузько­го (наприклад, технічного) словника, і їх значення вже напе­ред добре узгоджені в межах певного (наприклад, наукового) об’єднання, такі онтології застосовуються на практиці. Відо­мими прикладами онтології цього типу є індекси машин пошу­ку інформації в мережі Інтернет.

Інша ситуація у разі використання термінів природної мо­ви або в тих випадках, коли спілкуються програмні аґенти. У цьому випадку необхідно характеризувати передбачуване значення елементів словника за допомогою відповідної аксіоматизації, мета використання якої — вилучення небажа­них моделей і в тому, щоб інтерпретація була єдиною для всіх учасників спілкування.

Інший варіант відповідає випадку R=Ø, але FØ. Тоді кожному елементу множини термінів із С може ставитися у відповідність функція інтерпретації f з F. Формально це твердження може записуватися таким чином.

Нехай С = С1 С2, причому С1 С2 = Ø, де С1— множина термінів, що інтерпретуються; С2— множина інтерпретаційних термінів.

Тоді

С1, у¹, у², ....., у С2),

такі що

с = f ( y¹, y²,…, y

© 2013 wikipage.com.ua - Дякуємо за посилання на wikipage.com.ua | Контакти