Хочу представити до уваги публіки фрагмент ось цієї книги, що нещодавно вийшла:
Онтологічне моделювання підприємства: методи та технології [Текст]: монографія / [С. В. Горшков, С. С. Кралін, О. І. Муштак та ін; відповідальний редактор С. В. Горшков]. - Єкатеринбург: Вид-во Уральського ун-ту, 2019. - 234 с.: Іл., табл.; 20 см. - Авт. вказані на звороті тит. с. - Бібліогр. наприкінці гол. - ISBN 978-5-7996-2580-1: 200 прим.
Мета викладення цього фрагмента на Хабре чотирияка:
- Навряд чи в когось вдасться потримати цю книжку в руках, якщо він не є клієнтом шанованого ; у продажу її немає абсолютно точно.
- До тексту внесено виправлення (нижче вони не виділено) і зроблено доповнення, не дуже сумісні з форматом друкованої монографії: злободенні примітки (під спойлерами) і гіперпосилання.
- Хочеться зібрати питання та зауваження, щоб врахувати їх при включенні цього тексту в переробленому вигляді будь-які інші видання.
- Багато адептів Semantic Web і Linked Data все ще вважають, що їхнє коло настільки вузьке в основному тому, що широкому загалу досі по-хорошому не пояснили, як це здорово — бути адептом Semantic Web і Linked Data. Автор фрагмента, хоч до цього кола і належить, такої думки не дотримується, проте вважає себе зобов'язаним зробити ще одну спробу.
Отже,
Семантичний Веб
Еволюцію Інтернету можна уявити так (або говорити про його сегменти, що формувалися у вказаному нижче порядку):
- Документи в Інтернеті. Ключові технології - Gopher, FTP і т.п.
Інтернет є глобальною мережею обміну локальними ресурсами. - Інтернет документів. Ключові технології - HTML та HTTP.
Характер ресурсів, що виставляють, враховує особливості середовища їх передачі. - Дані в інтернеті. Ключові технології - REST і SOAP API, XHR та ін.
Епоха інтернет-додатків, споживачами ресурсів стають не лише люди. - Інтернет даних. Ключові технології – технології Linked Data.
Цей четвертий етап, передбачуваний Бернерсом-Лі, творцем ключових технологій другого та директором W3C, і називається Semantic Web; Технології Linked Data покликані зробити дані в Інтернеті не тільки машиночитаними, а й «машинорозуміння».
З подальшого читачеві стане ясно відповідність ключових понять другого та четвертого етапів:
- аналогами URL є URI,
- аналогом HTML є RDF,
- HTML-гіперпосиланням аналогічні входження URI в RDF-документи.
Semantic Web — скоріше системне бачення майбутнього інтернету, ніж конкретний стихійний або тренд, що лобіюється, хоча здатний враховувати і ці останні. Наприклад, важливою характеристикою того, що називається Web 2.0, вважається вміст, що «створюється користувачами». Приймати її до уваги покликані, зокрема, рекомендація W3C» і таке починання, як .
Чи мертвий Semantic Web?
Якщо відмовитися від , Ситуація з семантичним вебом приблизно така ж, як з комунізмом в часи розвиненого соціалізму (а чи дотримується вірність умовним завітам Ілліча, кожен нехай вирішує сам). Пошукові системи примушують веб-сайти до використання RDFa і JSON-LD і самі використовують технології, споріднені з описаним далі (Google Knowledge Graph, Bing Knowledge Graph).
Загалом автор не може сказати, що перешкоджає більшому поширенню, але може висловитися на основі особистого досвіду. Завдання, які б вирішувалися «з коробки» в умовах наступу SW, є, хоча і не дуже масові. Як наслідок, у тих, перед ким ці завдання стоять, немає засобів примусу щодо тих, хто здатний забезпечити рішення, самостійне забезпечення рішення цими останніми суперечить їхнім бізнес-моделям. Так що продовжуємо ширяти HTML і склеювати різні API, одне одного shittier.
Однак технології Linked Data набули поширення і за межами масового вебу; цим їх застосуванням книга, власне, і присвячена. В даний час спільнота Linked Data очікує, що ці технології отримають ще більше поширення завдяки фіксації (або проголошенню, кому як подобається) Gartner таких трендів, як Графіки знань и Data Fabric. Хочеться вірити, що матимуть успіх не «велосипедні» реалізації цих концепцій, а такі, що мають відношення до стандартів W3C, що розглядаються далі.
Пов'язані дані
Бернерс-Лі визначав Linked Data як «правильно зроблений» семантичний веб: сукупність підходів та технологій, що дозволяє досягти його кінцевих цілей. Базові принципи Linked Data Бернерс-Лі наступні.
Принцип 1. Використання URI для іменування сутностей.
URI є глобальними ідентифікаторами сутностей на противагу локальним ідентифікаторам рядкових записів. Згодом найкращий вираз цей принцип знайшов у слогані Google Knowledge Graph «».
Принцип 2. Використання URI у схемі HTTP, щоб їх можна було дереференсувати.
Звернувшись до URI, має бути можливо отримати означення, що стоїть за цим (тут зрозуміла аналогія з назвою оператора «*»в Сі); точніше, отримати деяке уявлення цього означуваного - залежно від значення HTTP-заголовка Accept:. Можливо, з настанням епохи AR/VR можна буде отримати сам ресурс, поки, швидше за все, це буде RDF-документ, що є результатом виконання SPARQL-запиту DESCRIBE.
Принцип 3. Використання стандартів W3C — в першу чергу RDF(S) і SPARQL — зокрема, при дереференсуванні URI.
Ці окремі "шари" стеку технологій Linked Data, відомого також під назвою , будуть описані далі.
Принцип 4. Використання для опису сутностей посилань на інші URI.
RDF дозволяє обмежитися словесним описом ресурсу природною мовою, і четвертий принцип закликає цього не робити. При загальному дотриманні першого принципу з'являється можливість при описі ресурсу посилатися інші, зокрема «чужі», чому дані і називаються пов'язаними. Насправді майже неминуче використання URI, названих у словнику RDFS.
RDF
(Resource Description Framework) - формалізм опису взаємопов'язаних сутностей.
Про сутності та їх взаємозв'язки робляться затвердження виду «суб'єкт-предикат-об'єкт», які називають триплетами. У найпростішому випадку і суб'єкт, і предикат і об'єкт — це URI. Один і той же URI може у різних триплетах перебувати у різних позиціях: бути і суб'єктом, і предикатом, і об'єктом; цим триплети утворюють свого роду граф, званий RDF-графом.
Суб'єкти та об'єкти можуть бути не тільки URI, але й так званими порожніми вузлами, а об'єкти можуть бути ще й літералами. Літерали - екземпляри примітивних типів, що складаються з рядкового подання та вказівки типу.
Приклади запису літералів (в Turtle-синтаксисі, про нього нижче): "5.0"^^xsd:float и "five"^^xsd:string. Літерали з типом rdf:langString можуть бути забезпечені ще й мовним тегом, Turtle це записується так: "five"@en и "пять"@ru.
Порожні вузли — «анонімні» ресурси без глобальних ідентифікаторів, про які можуть робитися твердження; свого роду екзистенційні змінні.
Отже (в цьому, власне, і полягає вся суть RDF):
- суб'єкт - це URI або порожній вузол,
- предикат - це URI,
- об'єкт – це URI, порожній вузол або літерал.
Чому предикати не можуть бути порожніми вузлами?
Імовірна причина — бажання неформально розуміти та перекладати мовою логіки предикатів першого порядку триплет s p o як щось на кшталт 
, Де - Предикат, и - Константи. Сліди такого розуміння є в документі «», Що має статус нотатки робочої групи W3С. При такому розумінні триплет s p [], Де [] — порожній вузол, буде перекладено як , Де - Змінна, але як тоді перекласти s [] o? Що має статус рекомендації W3C документ «пропонує інший спосіб перекладу, але можливість предикатів бути порожніми вузлами все одно не розглядає.
Втім, Ману Спорні .
RDF – абстрактна модель. RDF може бути записаний (серіалізований) у різних синтаксисах: , (найбільш людяний), , (Бінарний).
Один і той же RDF може бути серіалізований в RDF/XML різними способами, тому, наприклад, XML, що вийшов, безглуздо валідувати за допомогою XSD або намагатися витягувати дані за допомогою XPath. Також JSON-LD навряд чи задовольнить бажання рядового Javascript-розробника працювати з RDF з використанням точкової та квадратно-скобкової нотації Javascript (хоча JSON-LD і рухається в цьому напрямку, пропонуючи механізм ).
Більшість синтаксисів пропонує способи скорочення довгих URI. Наприклад, оголошення @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> в Turtle дозволить потім писати замість <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> просто rdf:type.
RDFS
(RDF Schema) - базовий словник моделювання, що вводить поняття властивості та класу і такі властивості, як rdf:type, rdfs:subClassOf, rdfs:domain и rdfs:range. За допомогою словника RDFS можуть бути записані, наприклад, такі вірні вирази:
rdf:type rdf:type rdf:Property .
rdf:Property rdf:type rdfs:Class .
rdfs:Class rdfs:subClassOf rdfs:Resource .
rdfs:subClassOf rdfs:domain rdfs:Class .
rdfs:domain rdfs:domain rdf:Property .
rdfs:domain rdfs:range rdfs:Class .
rdfs:label rdfs:range rdfs:Literal .RDFS є словником опису та моделювання, але не є мовою обмежень (хоча офіційна специфікація та можливість такого вживання). Слово «Schema» не слід розуміти в тому ж значенні, що й у виразі «XML Schema». Наприклад, :author rdfs:range foaf:Person означає, що rdf:type всіх значень властивості :author - foaf:Personале не означає, що про це має бути сказано заздалегідь.
SPARQL
(SPARQL Protocol and RDF Query Language) — мова запитів до даних RDF. У простому випадку SPARQL-запит є набір зразків, з якими зіставляються триплети опитуваного графа. У зразках у позиціях суб'єктів, предикатів та об'єктів можуть бути змінні.
Запит поверне такі значення змінних, при підстановці яких зразки може вийти підграф опитуваного RDF-графа (підмножина його триплетів). Однойменні змінні в різних зразках триплетів повинні мати однакові значення.
Наприклад, на наведеному вище наборі із семи RDFS-аксіом наступний запит поверне rdfs:domain и rdfs:range як значення ?s и ?p відповідно:
SELECT * WHERE {
?s ?p rdfs:Class .
?p ?p rdf:Property .
}Варто зазначити, що SPARQL є декларативним і не є мовою опису обходу графа (втім, деякі RDF-сховища пропонують способи коригування плану виконання запиту). Тому деякі стандартні графові завдання, наприклад пошук найкоротшого шляху, не можуть бути вирішені на SPARQL, у тому числі і з використанням механізму (але, знову ж таки, окремі RDF-сховища пропонують спеціальні розширення для вирішення цих завдань).
SPARQL не поділяє презумпцію відкритості світу і слідує підходу «negation as failure», в ньому такі конструкції, як FILTER NOT EXISTS {…}. Розподіл даних враховується за допомогою механізму .
Точка доступу SPARQL - RDF-сховище, здатне обробляти SPARQL-запити - не має прямих аналогів другого етапу (див. початок даного параграфа). Її можна уподібнити до бази даних, на основі вмісту якої генерувалися HTML-сторінки, але доступної зовні. Точка доступу SPARQL є аналогом скоріше точки доступу API третього етапу, проте з двома основними відмінностями. По-перше, є можливість об'єднувати кілька «атомарних» запитів в один (що вважається ключовою характеристикою GraphQL), по-друге, такий API є повністю самодокументованим (чого намагався досягти HATEOAS).
Полемічне зауваження
RDF — спосіб публікації даних на Інтернеті, тому RDF-сховища слід вважати документними СУБД. Правда, оскільки RDF - граф, а не дерево, вони заодно вийшли і графовими. Дивно, що взагалі вийшли. Хтось міг би подумати, що знайдуться розумники, які реалізують blank nodes. У Кодда ось .
Є і менш повнофункціональні способи організації доступу до даних RDF, наприклад, (LDF) та (LDP).
OWL
(Web Ontology Language) - формалізм уявлення знань, синтаксичний варіант дескрипційної логіки (Всюди нижче правильніше говорити OWL 2, перша версія OWL була заснована на ).
Концептам дескрипційних логік у OWL відповідають класи, ролям – властивості, індивіди зберігають свою колишню назву. Аксіоми також називаються аксіомами.
Наприклад, у так званому для запису OWL вже відома нам аксіома буде записано так:
Class: Human
Class: Parent
EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParentЄ й інші синтаксиси для запису OWL, наприклад, , що використовується в офіційній специфікації, та . Крім того, OWL може бути серіалізований і надалі - у будь-який із конкретних синтаксисів.
OWL щодо RDF виступає в двоякому відношенні. Його, з одного боку, можна розглядати як словник, що розширює RDFS. З іншого боку, це потужніший формалізм, для якого RDF лише формат серіалізації. Не всі елементарні конструкції OWL можна записати за допомогою єдиного триплету RDF.
Залежно від того, яке підмножина конструкцій OWL дозволено використовувати, говорять про так звані . Стандартизовані та найбільш відомі – це OWL EL, OWL RL та OWL QL. Вибір профілю впливає обчислювальну складність типових завдань. Повний набір конструкцій OWL, що відповідає називається OWL DL. Іноді також говорять про OWL Full, в якому конструкції OWL можна використовувати з повною свободою, властивою RDF, без семантичних та обчислювальних обмежень . Наприклад, може бути і класом, і властивістю. OWL Full нерозв'язний.
Ключові принципи приєднання наслідків до OWL — ухвалення презумпції відкритого світу (open world assumption, ) та відмова від презумпції унікальності імен (unique name assumption, ). Нижче ми побачимо, до чого можуть наводити ці принципи і познайомимося з деякими конструкціями OWL.
Нехай онтологія містить наступний фрагмент (у манчестерському синтаксисі):
Class: manyChildren
EquivalentTo: Human that hasChild min 3
Individual: John
Types: Human
Facts: hasChild Alice, hasChild Bob, hasChild CarolЧи буде зі сказаного слідувати, що Джон багатодітний? Відмова від UNA змусить двигун висновку відповісти на це питання негативно, адже Аліса і Боб можуть бути однією і тією ж людиною. Щоб слідування мало місце, потрібно додати таку аксіому:
DifferentIndividuals: Alice, Bob, Carol, JohnНехай тепер фрагмент онтології має такий вигляд (Джона оголошено багатодітним, але в нього вказано лише двоє дітей):
Class: manyChildren
EquivalentTo: Human that hasChild min 3
Individual: John
Types: Human, manyChildren
Facts: hasChild Alice, hasChild Bob
DifferentIndividuals: Alice, Bob, Carol, JohnЧи ця онтологія буде суперечливою (що можна інтерпретувати як свідчення невалідності даних)? Прийняття OWA змусить двигун висновку відповісти негативно: «десь» ще (в іншій онтології) цілком може бути сказано, що Керол також є дитиною Джона.
Щоб унеможливити це, додамо новий факт про Джона:
Individual: John
Facts: hasChild Alice, hasChild Bob, not hasChild CarolЩоб виключити появу та інших дітей, скажімо, що всі значення властивості «мати дитину» — люди, яких у нас лише четверо:
ObjectProperty: hasChild
Domain: Human
Сharacteristics: Irreflexive
Class: Human
EquivalentTo: { Alice, Bill, Carol, John }Тепер онтологія стане суперечливою, про що двигун висновку не забариться повідомити. Останньою з аксіом ми в якомусь сенсі «замкнули» світ, і зверніть увагу, яким способом унеможливлено те, що Джон є дитиною самому собі.
Linking Enterprise Data
Набір підходів та технологій Linked Data спочатку призначався для публікації даних у Інтернеті. Використання їх у внутрішньокорпоративному середовищі стикається з низкою труднощів.
Наприклад, у замкнутому корпоративному середовищі виявляється надто слабкою дедуктивна сила OWL, заснованого на прийнятті OWA та відмові від UNA — рішеннях, зумовлених відкритим та розподіленим характером Інтернету. І тут можливі такі виходи.
- Наділення OWL семантикою, що передбачає відмову від OWA та прийняття UNA, реалізація відповідного движка виведення. — Таким шляхом RDF-сховище Stardog.
- Відмова від дедуктивних можливостей OWL на користь двигунів правил. - Stardog підтримує ; Jena та GraphDB пропонують правил.
- Відмова від дедуктивних можливостей OWL, використання для моделювання того чи іншого підмножини, близького до RDFS. - Див. про це далі.
Інша проблема — більш істотна увага, яку в корпоративному світі можна приділити проблемам якості даних, і відсутність у стеку Linked Data інструментів валідації даних. Виходи тут такі.
- Знов-таки, використання для валідації конструкцій OWL із семантикою закритого світу та унікальності імен за наявності відповідного движка виведення.
- Використання , стандартизованого вже після того, як перелік шарів Semantic Web Layer Cake був зафіксований (втім, він може використовуватися і як двигун правил), або .
- Усвідомлення того, що все зрештою робиться SPARQL-запитами, створення власного нескладного механізму валідації даних з їх використанням.
Втім, навіть повна відмова від дедуктивних можливостей та інструментів валідації залишає стек Linked Data поза конкуренцією у задачах, що ландшафтно схожі з відкритим та розподіленим вебом — у задачах інтеграції даних.
Як щодо звичайної корпоративної інформаційної системи?
Це можливо, але слід, звичайно, усвідомлювати, які саме проблеми повинні будуть вирішити відповідні технології. Опишу тут типову реакцію учасників розробки, щоб показати, як виглядає цей технологічний стек з погляду конвенційного IT. Трохи нагадує притчу про слона:
- Бізнес аналітик: RDF - це щось типу безпосередньо логічної моделі, що зберігається.
- системний аналітик: RDF - це як , тільки з купою індексів та зручною мовою запитів.
- Дизайнер: ну, це все в дусі концепцій rich model і low code, нещодавно про це.
- Керівник проекту: так це ж !
Практика показує, що стек найчастіше використовується в задачах, пов'язаних із розподіленістю та гетерогенністю даних, наприклад, при побудові систем класу MDM (Master Data Management) або DWH (Data Warehouse). Такі завдання є у будь-якій галузі.
Щодо застосувань з галузевою специфікою, в даний час технології Linked Data найбільш популярні у таких галузях.
- біомедичні технології (де їх популярність, мабуть, пов'язана зі складністю предметної галузі);
актуальне
У «Точці кипіння» днями проходила організована асоціацією «Національна база медичних знань» конференція «».
- виготовлення та експлуатація складних виробів (велике машинобудування, видобуток нафти та газу; найчастіше йдеться про стандарт );
актуальне
Тут теж причиною є складність предметної області, коли, наприклад, на етапі upstream, якщо говорити про нафтогазову галузь, простий обліковий потрібно мати деякі функції САПР.
У 2008 році пройшла організована Chevron представницька установча .
ISO 15926 зрештою здався нафтогазовій галузі важкуватим (і чи не більше застосування знайшов у машинобудуванні). Ґрунтовно на нього підсіла хіба що Statoil (Equinor), в Норвегії навколо нього склалася ціла . Інші намагаються робити щось своє. Наприклад, за чутками, вітчизняний Міненерго має намір зайнятися створенням «концептуальної онтологічної моделі ПЕК», аналогічної, мабуть, .
- фінансові організації (навіть XBRL можна розглядати як гібрид SDMX і онтології RDF Data Cube);
актуальне
LinkedIn на початку року активно спамив автора вакансіями чи не у всіх гігантів фінансової індустрії, яких він знає за серіалом «Форс-мажори»: Goldman Sachs, JPMorgan Chase та/або Morgan Stanley, Wells Fargo, SWIFT/Visa/Mastercard, Bank of America, Citigroup, ФРС, Deutsche Bank… Мабуть, усі шукали, кого можна буде відправити на . Знайти вдалося досить багатьом: фінансові організації зайняли все .
На HeadHunter щось цікаве траплялося тільки в Ощадбанку, йшлося про «EAV-сховище з RDF-подібною моделлю даних».
Ймовірно, відмінність у ступені любові до відповідних технологій вітчизняних та західних фінансових інституцій обумовлена транснаціональним характером діяльності останніх. Очевидно, інтеграції крізь державні кордони вимагають якісно інших організаційних і технічних рішень.
- питання-відповіді системи, що мають комерційне застосування (IBM Watson, Apple Siri, Google Knowledge Graph);
актуальне
До речі, автор Siri Томас Грубер — автор того самого визначення онтології (в ІТ-значенні) як «специфікації концептуалізації». На мій погляд, перестановка слів у цьому визначенні не змінює його змісту, що, можливо, свідчить про те, що його там і немає.
- публікація структурованих даних (з великою основою це може бути віднесено вже до Linked Open Data).
актуальне
Великі любителі Linked Data - так звані GLAM: Galleries, Libraries, Archives, and Museums. Тут досить сказати, що на заміну MARC21 Бібліотека Конгресу просуває , Який забезпечується foundation for future of bibliographic description і, зрозуміло, ґрунтується на RDF.
Часто як приклад успішного проекту у сфері Linked Open Data наводять Wikidata — свого роду машиночитану версію Вікіпедії, вміст якої, на противагу DBPedia, не генерується імпортом з інфобоксів статей, а створюється більш-менш вручну (і надалі стає джерелом інформації для тих же інфобоксів).
Рекомендуємо також для ознайомлення користувачів RDF-сховища Stardog на сайті Stardog у розділі «Customers».
Як би там не було, у гартнерівському "Enterprise Taxonomy and Ontology Management" поміщений в середині спуску в долину розчарування з перспективою виходу на "плато продуктивності" не раніше ніж через 10 років.
Connecting Enterprise Data
Прогнози, прогнози, прогнози...
З історичного інтересу звів у таблицю нижче гартнерівські прогнози різних років за технологіями, що нас цікавлять.
| рік | Технологія | Звіт | Положення | Років до плато |
|---|---|---|---|---|
| 2001 | Семантичний Веб | Нові технології | Тригер інновацій | 5-10 |
| 2006 | Corporate Semantic Web | Нові технології | Пік завищених очікувань | 5-10 |
| 2012 | Семантичний Веб | Великий даних | Пік завищених очікувань | > 10 |
| 2015 | Пов'язані дані | Advanced Analytics and Data Science | Корито розчарування | 5-10 |
| 2016 | Enterprise Ontology Management | Нові технології | Корито розчарування | > 10 |
| 2018 | Графіки знань | Нові технології | Тригер інновацій | 5-10 |
Втім, вже в з'явився інший висхідний тренд - Knowledge Graphs. Відбулася якась реінкарнація: графові СУБД, на які виявилася переключена увага користувачів та сили розробників, під впливом запитів перших та звичок останніх стали набувати контурів та позиціонування своїх попередників-конкурентів.
Практично кожна графова СУБД тепер оголошує себе платформою для побудови корпоративного «графа знань» («linked data» іноді замінюється на «connected data»), але наскільки виправдані подібні домагання?
Графові бази даних, як і раніше, асемантичні, дані в графовій СУБД — той самий data silo. Рядкові ідентифікатори замість URI роблять завдання інтеграції двох графових СУБД все тим самим завданням інтеграції, тоді як інтеграція двох RDF-сховищ часто зводиться просто до об'єднання двох RDF-графів. Інший аспект асемантичності - нерефлексивність графової моделі LPG, що утруднює управління метаданими з використанням тієї ж платформи.
Нарешті, графові СУБД немає двигунів виведення і движків правил. Результати роботи таких двигунів можуть бути відтворені ускладненням запитів, але таке можливо навіть у SQL.
Втім, провідні RDF-сховища не мають труднощів з підтримкою моделі LPG. Найбільш солідним вважається підхід, запропонований свого часу Blazegraph: модель RDF*, що поєднує RDF і LPG.
Детальніше
Докладніше про підтримку RDF-сховищами моделі LPG можна прочитати в попередній статті на Хабрі: . Про Knowledge Graphs і Data Fabric буде, сподіваюся, одного разу написано окрему статтю. Заключний розділ, як легко зрозуміти, дописувався поспіхом, втім, і через півроку з цими концепціями все не набагато ясніше.
література
- Halpin, H., Monnin, A. (eds.) (2014). Philosophical Engineering: Toward a Philosophy of the Web
- Allemang, D., Hendler, J. (2011) Semantic Web для Working Ontologist (2nd ed.)
- Staab, S., Studer, R. (eds.) (2009) Handbook on Ontologies (2nd ed.)
- Wood, D. (Ed.). (2011) Linking Enterprise Data
- Keet, M. (2018) An Introduction to Ontology Engineering
Джерело: habr.com