Semantic Web и Linked Data. Исправления и дополнения

Хочу представить вниманию публики фрагмент вот этой недавно вышедшей книги:

Онтологическое моделирование предприятия: методы и технологии [Текст]: монография / [С. В. Горшков, С. С. Кралин, О. И. Муштак и др.; ответственный редактор С. В. Горшков]. — Екатеринбург: Изд-во Уральского ун-та, 2019. — 234 с.: ил., табл.; 20 см. — Авт. указаны на обороте тит. с. — Библиогр. в конце гл. — ISBN 978-5-7996-2580-1: 200 экз.

Цель выкладки этого фрагмента на Хабре четвероякая:

• Вряд ли у кого-то получится подержать эту книжку в руках, если он не является клиентом уважаемого SergeIndex; в продаже её нет совершенно точно.
• В текст внесены исправления (ниже они никак не выделены) и сделаны дополнения, не очень совместимые с форматом печатной монографии: злободневные примечания (под спойлерами) и гиперссылки.
• Хочется собрать вопросы и замечания, чтобы учесть их при включении этого текста в переработанном виде в какие-либо другие издания.
• Многие адепты Semantic Web и Linked Data все еще считают, что их круг столь узок в основном потому, что широкой публике до сих пор по-хорошему не объяснили, как же это здорово — быть адептом Semantic Web и Linked Data. Автор фрагмента, хоть к этому кругу и принадлежит, такого мнения не придерживается, но, тем не менее, считает себя обязанным сделать еще одну попытку.

Итак,

Semantic Web

Эволюцию Интернета можно представить следующим образом (или говорить о его сегментах, формировавшихся в указанном ниже порядке):

1. Документы в интернете. Ключевые технологии — Gopher, FTP и т. п.
   Интернет является глобальной сетью для обмена локальными ресурсами.
2. Интернет документов. Ключевые технологии — HTML и HTTP.
   Характер выставляемых ресурсов учитывает особенности среды их передачи.
3. Данные в интернете. Ключевые технологии — REST и SOAP API, XHR и пр.
   Эпоха интернет-приложений, потребителями ресурсов становятся не только люди.
4. Интернет данных. Ключевые технологии — технологии Linked Data.
   Этот четвертый этап, предсказываемый Бернерсом-Ли, создателем ключевых технологий второго и директором W3C, и называется Semantic Web; технологии Linked Data призваны сделать данные в вебе не только машиночитаемыми, но и «машинопонимаемыми».

Из дальнейшего читателю станет ясно соответствие ключевых понятий второго и четвертого этапов:

• аналогами URL являются URI,
• аналогом HTML является RDF,
• HTML-гиперссылкам аналогичны вхождения URI в RDF-документы.

Semantic Web — скорее системное видение будущего интернета, чем конкретный стихийный или лоббируемый тренд, хотя способен учитывать и эти последние. Например, важной характеристикой того, что называется Web 2.0, считается «создаваемое пользователями содержимое». Принимать её во внимание призваны, в частности, рекомендация W3C «Web Annotation Ontology» и такое начинание, как Solid.

Мёртв ли Semantic Web?

Если отказаться от нереалистичных ожиданий, ситуация с семантическим вебом примерно такая же, как с коммунизмом во времена развитого социализма (а уж блюдется ли верность условным заветам Ильича, каждый пусть решает сам). Поисковые системы довольно успешно принуждают веб-сайты к использованию RDFa и JSON-LD и сами используют технологии, родственные описываемым далее (Google Knowledge Graph, Bing Knowledge Graph).

В общем виде автор не может сказать, что препятствует большему распространению, но может высказаться на основе личного опыта. Задачи, которые решались бы «из коробки» в условиях наступления SW, есть, хотя и не очень массовые. Как следствие, у тех, перед кем эти задачи стоят, нет средств принуждения в отношении тех, кто способен обеспечить решение, самостоятельное же обеспечение решения этими последними противоречит их бизнес-моделям. Так что продолжаем парсить HTML и склеивать различные API, одно другого shittier.

Однако технологии Linked Data получили распространение и за пределами массового веба; этим их применениям книга, собственно, и посвящена. В настоящее время сообщество Linked Data ожидает, что эти технологии получат еще большее распространение благодаря фиксации (или провозглашению, кому как нравится) Gartner таких трендов, как как Knowledge Graphs i Data Fabric. Хочется верить, что будут иметь успех не «велосипедные» реализации этих концепций, а имеющие отношение к рассматриваемым далее стандартам W3C.

Linked Data

Бернерс-Ли определял Linked Data как «правильно сделанный» семантический веб: cовокупность подходов и технологий, позволяющую достичь его конечных целей. Базовые принципы Linked Data Бернерс-Ли выделял следующие.

Принцип 1. Использование URI для именования сущностей.

URI являются глобальными идентификаторами сущностей в противоположность локальным строковым идентификаторам записей. Впоследствии лучшее выражение этот принцип нашел в слогане Google Knowledge Graph «things, not strings».

Принцип 2. Использование URI в схеме HTTP, чтобы их было возможно дереференсировать.

Обратившись к URI, должно быть возможно получить означаемое, стоящее за этим означающим (тут понятна аналогия с названием оператора «*» в Си); точнее, получить некоторое представление этого означаемого — в зависимости от значения HTTP-заголовка Accept:. Быть может, с наступлением эпохи AR/VR можно будет получить сам ресурс, пока же, скорее всего, это будет RDF-документ, являющийся результатом выполнения SPARQL-запроса DESCRIBE.

Принцип 3. Использование стандартов W3C — в первую очередь, RDF(S) и SPARQL — в частности, при дереференсировании URI.

Эти отдельные «слои» стека технологий Linked Data, известного также под названием Semantic Web Layer Cake, будут описаны нами далее.

Принцип 4. Использование при описании сущностей ссылок на другие URI.

RDF позволяет ограничиться словесным описанием ресурса на естественном языке, и четвертый принцип призывает этого не делать. При всеобщем соблюдении первого принципа появляется возможность при описании ресурса ссылаться на другие, в том числе «чужие», отчего данные и называются связанными. На самом деле почти неизбежно использования URI, поименованных в словаре RDFS.

RDF

RDF (Resource Description Framework) — формализм описания взаимосвязанных сущностей.

О сущностях и их взаимосвязях делаются утверждения вида «субъект-предикат-объект», называемые триплетами. В простейшем случае и субъект, и предикат, и объект — это URI. Один и тот же URI может в различных триплетах находиться в различных позициях: быть и субъектом, и предикатом, и объектом; тем самым триплеты образуют своего рода граф, называемый RDF-графом.

Субъекты и объекты могут быть не только URI, но и так называемыми пустыми узлами, а объекты могут быть еще и литералами. Литералы — экземпляры примитивных типов, состоящие из строкового представления и указания типа.

Примеры записи литералов (в Turtle-синтаксисе, о нем ниже): "5.0"^^xsd:float i "five"^^xsd:string. Литералы с типом rdf:langString могут быть снабжены еще и языковым тегом, в Turtle это записывается так: "five"@en i "пять"@ru.

Пустые узлы — «анонимные» ресурсы без глобальных идентификаторов, о которых, однако, могут делаться утверждения; своего рода экзистенциальные переменные.

Итак (в этом, собственно, и заключается вся суть RDF):

• субъект — это URI или пустой узел,
• предикат — это URI,
• объект — это URI, пустой узел или литерал.

Почему предикаты не могут быть пустыми узлами?

Вероятная причина — желание неформально понимать и переводить на язык логики предикатов первого порядка триплет s p o как нечто наподобие , gdzie — предикат, i — константы. Cледы такого понимания есть в документе «LBase: Semantics for Languages of the Semantic Web», имеющем статус заметки рабочей группы W3С. При таком понимании триплет s p [], gdzie [] — пустой узел, будет переведен как , gdzie — переменная, но как тогда перевести s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semantics» предлагает другой способ перевода, но возможность предикатов быть пустыми узлами все равно не рассматривает.

Впрочем, Ману Спорни разрешили.

RDF — абстрактная модель. RDF может быть записан (сериализован) в различных синтаксисах: RDF/XML, Turtle (наиболее человекочитаемый), JSON-LD, HDT (бинарный).

Один и тот же 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

RDFS (RDF Schema) — базовый словарь моделирования, вводит понятия свойства и класса и такие свойства, как rdf:type, rdfs:subClassOf, rdfs:domain i 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 (SPARQL Protocol and RDF Query Language) — язык запросов к RDF-данным. В простом случае SPARQL-запрос представляет собой набор образцов, с которыми сопоставляются триплеты опрашиваемого графа. В образцах в позициях субъектов, предикатов и объектов могут находиться переменные.

Запрос возвратит такие значения переменных, при подстановке которых в образцы может получиться подграф опрашиваемого RDF-графа (подмножество его триплетов). Одноименные переменные в различных образцах триплетов должны иметь при этом одинаковые значения.

Например, на приведенном выше наборе из семи RDFS-аксиом следующий запрос вернет rdfs:domain i rdfs:range в качестве значений ?s i ?p соответственно:

SELECT * WHERE {
 ?s ?p rdfs:Class .
 ?p ?p rdf:Property .
}

Стоит отметить, что SPARQL декларативен и не является языком описания обхода графа (впрочем, некоторые RDF-хранилища предлагают способы корректировки плана выполнения запроса). Поэтому некоторые стандартные графовые задачи, например, поиск кратчайшего пути, не могут быть решены на SPARQL, в том числе и с использованием механизма property paths (но, опять же, отдельные RDF-хранилища предлагают специальные расширения для решения этих задач).

SPARQL не разделяет презумпцию открытости мира и следует подходу «negation as failure», в нем возможны такие конструкции, как FILTER NOT EXISTS {…}. Распределенность данных учитывается с помощью механизма федеративных запросов.

Точка доступа SPARQL — RDF-хранилище, способное обрабатывать SPARQL-запросы — не имеет прямых аналогов из второго этапа (см. начало данного параграфа). Её можно уподобить базе данных, на основе содержимого которой генерировались HTML-страницы, но доступной вовне. Точка доступа SPARQL является аналогом скорее точки доступа API из третьего этапа, однако с двумя основными отличиями. Во-первых, есть возможность объединять несколько «атомарных» запросов в один (что считается ключевой характеристикой GraphQL), во-вторых, такой API полностью самодокументирован (чего пытался достичь HATEOAS).

Полемическое замечание

RDF — способ публикации данных на вебе, поэтому RDF-хранилища следовало бы считать документными СУБД. Правда, поскольку RDF — граф, а не дерево, они заодно получились и графовыми. Удивительно, что вообще получились. Кто бы мог подумать, что найдутся умники, которые реализуют blank nodes. У Кодда вот не вышло.

Имеются и менее полнофунуциональные способы организации доступа к RDF-данным, например, Linked Data Fragments (LDF) и Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) — формализм представления знаний, синтаксический вариант дескрипционной логики (всюду ниже правильнее говорить OWL 2, первая версия OWL была основана на ).

Концептам дескрипционных логик в OWL соответствуют классы, ролям — свойства, индивиды сохраняют свои прежнее название. Аксиомы также называются аксиомами.

Например, в так называемом манчестерском синтаксисе для записи OWL уже известная нам аксиома будет записана так:

Class: Human
Class: Parent
   EquivalentClass: Human and (inverse hasParent) some Human
ObjectProperty: hasParent

Имеются и другие синтаксисы для записи OWL, например, функциональный синтаксис, используемый в официальной спецификации, и OWL/XML. Кроме того, OWL может быть сериализован в абстрактный синтаксис RDF и в дальнейшем — в любой из конкретных синтаксисов.

OWL в отношении к RDF выступает в двояком отношении. Его, с одной стороны, можно рассматривать как некий словарь, расширяющий RDFS. С другой стороны, это более мощный формализм, для которого RDF лишь формат сериализации. Не все элементарные конструкции OWL можно записать посредством единственного RDF-триплета.

В зависимости от того, какое подмножество конструкций OWL разрешено использовать, говорят о так называемых профилях OWL. Стандартизованные и наиболее известные — это OWL EL, OWL RL и OWL QL. Выбор профиля влияет на вычислительную сложность типовых задач. Полный набор конструкций OWL, соответствующий , называется OWL DL. Иногда также говорят об OWL Full, в котором конструкции OWL разрешено использовать с полной свободой, присущей RDF, без семантических и вычислительных ограничений . Например, нечто может быть и классом, и свойством. OWL Full неразрешим.

Ключевые принципы присоединения следствий в OWL — принятие презумпции открытого мира (open world assumption, OWA) и отказ от презумпции уникальности имен (unique name assumption, UNA). Ниже мы увидим, к чему могут приводить эти принципы, и познакомимся с некоторыми конструкциями 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 поддерживает SWRL; Jena и GraphDB предлагают собственные языки правил.
• Отказ от дедуктивных возможностей OWL, использование для моделирования того или иного подмножества, близкого к RDFS. — См. об этом далее.

Другая проблема — более существенное внимание, которое в корпоративном мире возможно уделить проблемам качества данных, и отсутствие в стеке Linked Data инструментов валидации данных. Выходы здесь следующие.

• Опять-таки, использование для валидации конструкций OWL с семантикой закрытого мира и уникальности имен при наличии соответствующего движка вывода.
• Zastosowanie SHACL, стандартизованного уже после того, как перечень слоев Semantic Web Layer Cake был зафиксирован (впрочем, он может использоваться и в качестве движка правил), или ShEx.
• Осознание того, что все в конечном итоге делается SPARQL-запросами, создание собственного несложного механизма валидации данных с их использованием.

Впрочем, даже полный отказ от дедуктивных возможностей и инструментов валидации оставляет стек Linked Data вне конкуренции в задачах, ландшафтно сходных с открытым и распределенным вебом — в задачах интеграции данных.

Как насчет обычной корпоративной информационной системы?

Это возможно, но следует, конечно, отдавать себе отчет, какие именно проблемы должны будут решить соответствующие технологии. Опишу здесь типовую реакцию участников разработки, чтобы показать, как выглядит этот технологических стек с точки зрения конвенционального IT. Немного напоминает притчу о слоне:

• Бизнес-аналитик: RDF — это что-то типа непосредственно хранимой логической модели.
• Системный аналитик: RDF — это как EAV, только с кучей индексов и удобным языком запросов.
• Разработчик: ну, это все в духе концепций rich model и low code, читал недавно об этом.
• Руководитель проекта: да это же collapsing the stack!

Практика показывает, что стек чаще всего используется в задачах, связанных с распределенностью и гетерогенностью данных, например, при построении систем класса MDM (Master Data Management) или DWH (Data Warehouse). Такие задачи имеются в любой отрасли.

Что до применений с отраслевой спецификой, в настоящее время технологии Linked Data наиболее популярны в следующих отраслях.

• биомедицинские технологии (где их популярность, по-видимому, связана со сложностью предметной области);

актуальное

В «Точке кипения» на днях в проходила организованная ассоциацией «Национальная база медицинских знаний» конференция «Объединение онтологий. От теории к практическому применению».

• изготовление и эксплуатация сложных изделий (крупное машиностроение, добыча нефти и газа; чаще всего речь идет о стандарте ISO 15926);

актуальное

Здесь тоже причиной является сложность предметной области, когда, например, на этапе 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… Вероятно, все искали, кого можно будет отправить на Knowledge Graph Conference. Найти удалось довольно многим: финансовые организации заняли всё утро первого дня.

На HeadHunter же что-то интересное попадалось только у Сбербанка, речь шла о «EAV-хранилище с RDF-подобной моделью данных».

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

• вопросно-ответные системы, имеющие коммерческое применение (IBM Watson, Apple Siri, Google Knowledge Graph);

актуальное

К слову, создатель Siri Томас Грубер — автор того самого определения онтологии (в ИТ-значении) как «спецификации концептуализации». На мой взгляд, перестановка слов в этом определении не меняет его смысл, что, возможно, свидетельствует о том, что его там и нет.

• публикация структурированных данных (с большим основанием это может быть отнесено уже к Linked Open Data).

актуальное

Большие любители Linked Data — так называемые GLAM: Galleries, Libraries, Archives, and Museums. Тут достаточно сказать, что на замену MARC21 Библиотека Конгресса продвигает BIBFRAME, который provides a foundation for the future of bibliographic description и, разумеется, основан на RDF.

Часто в качестве примера успешного проекта в сфере Linked Open Data приводят Wikidata — своего рода машиночитаемую версию Википедии, содержимое которой, в противоположность DBPedia, не генерируется импортом из инфобоксов статей, а создается более-менее вручную (и в последующем становится источником информации для тех же инфобоксов).

Рекомендуем также для ознакомления список пользователей RDF-хранилища Stardog на сайте Stardog в разделе «Customers».

Как бы то ни было, в гартнеровском «Hype Cycle for Emerging Technologies» 2016 года «Enterprise Taxonomy and Ontology Management» помещен в середине спуска в долину разочарования с перспективой выхода на «плато продуктивности» не ранее чем через 10 лет.

Connecting Enterprise Data

Прогнозы, прогнозы, прогнозы…

Из исторического интереса свел в таблицу ниже гартнеровские прогнозы различных лет по интересующим нас технологиям.

Впрочем, уже в «Hype Cycle…» 2018 года появился другой восходящий тренд — Knowledge Graphs. Произошла некая реинкарнация: графовые СУБД, на которые оказалось переключено внимание пользователей и силы разработчиков, под влиянием запросов первых и привычек последних стали обретать контуры и позиционирование своих предшественников-конкурентов.

Практически каждая графовая СУБД теперь объявляет себя подходящей платформой для построения корпоративного «графа знаний» («linked data» иногда заменяется на «connected data»), но насколько оправданы подобные притязания?

Графовые базы данных по-прежнему асемантичны, данные в графовой СУБД — все тот же data silo. Строковые идентификаторы вместо URI делают задачу интеграции двух графовых СУБД все той же задачей интеграции, в то время как интеграция двух RDF-хранилищ зачастую сводится просто к объединению двух RDF-графов. Другой аспект асемантичности — нерефлексивность графовой модели LPG, делающая затруднительным управление метаданными с использованием той же платформы.

Наконец, графовые СУБД не имеют движков вывода и движков правил. Результаты работы таких движков могут быть воспроизведены усложнением запросов, но такое возможно даже в SQL.

Впрочем, ведущие RDF-хранилища не испытывают затруднений с поддержкой модели LPG. Наиболее солидным считается подход, предложенный в свое время в Blazegraph: модель RDF*, объединяющая RDF и LPG.

Więcej informacji

Подробнее о поддержке RDF-хранилищами модели LPG можно прочитать в предыдущей статье на Хабре: «Что сейчас происходит с RDF-хранилищами». Про Knowledge Graphs и Data Fabric будет, надеюсь, однажды написана отдельная статья. Заключительный раздел, как легко понять, дописывался в спешке, впрочем, и спустя полгода с этими концепциями все не намного яснее.

Литература

1. Halpin, H., Monnin, A. (eds.) (2014). Philosophical Engineering: Toward a Philosophy of the Web
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2nd ed.)
3. Staab, S., Studer, R. (eds.) (2009) Handbook on Ontologies (2nd ed.)
4. Wood, D. (ed.). (2011) Linking Enterprise Data
5. Keet, M. (2018) An Introduction to Ontology Engineering

Źródło: habr.com