Содержание


Широкомасштабная интеграция данных

создание информационных паутин с помощью RDF

О том, как ресурсно-ориентированное мышление способствует интеграции данных

Comments

Серия контента:

Этот контент является частью # из серии # статей: Широкомасштабная интеграция данных

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Широкомасштабная интеграция данных

Следите за выходом новых статей этой серии.

Одна из основных целей программного обеспечения в современном мире – создание и использование потоков данных. Для одного получателя, разделяющего ваш контекст, легко создать модель или схему данных, сопоставить ее с объектной моделью и сериализовать данные в экстернализованном формате. Но сделать это при наличии множества партнеров и контекстов – одна из самых сложных задач, стоящих сегодня перед производителями программного обеспечения. В результате мы склонны браться только за те интеграционные проекты, в которых окупаемость инвестиций очевидна. К издержкам от неиспользования полезных источников данных можно добавить упущенные возможности и неэффективность систем.

Широкомасштабная интеграция данных – это не только техническая, но и социальная проблема. Чтобы обмениваться информацией, нужно договориться о том, что она означает, — опять же, это легко достигается при прямом взаимодействии, но невообразимо усложняется с ростом числа уровней участия. Мы сталкиваемся с ограничениями культурного, лингвистического, психологического, перцепционного и политического характера. Изменяющиеся требования, сдвиг приоритетов и желание сотрудничать с большим числом партнеров делает ситуацию в динамично развивающихся областях еще более безнадежной. А в мире преходящих, мимолетных технологий, таких как схемы реляционных баз данных, XML-схемы и существующие библиотеки кода, этот поток усиливается почти до неуправляемого. Нужно достаточно долго соблюдать соглашения об именах и формах элементов и отношений, чтобы выпускать программное обеспечения прежде, чем что-нибудь снова изменится.

Необходимость консенсуса в омуте хаоса современного бизнеса – одна из главных причин Проблемы программного обеспечения, или того факта, что качественное программное обеспечение трудно производить в предсказуемые сроки. Эта потребность редко получает то внимание, которого заслуживает. Когда модели предметных областей выражены явно и косвенно через схемы реляционных таблиц, файлы объектно-реляционного отображения (ORM), библиотеки кода и описание услуг, наша способность выпускать новые функции или исправления сдерживается чрезмерно зависимыми жизненными циклами. Поэтому приходится использовать все большие команды разработчиков с раздувающимися бюджетами, для чего требуется политическое влияние, которое трудно сместить или перестроить. Мы создаем мастер-планы управления данными (MDM) и корпоративные хранилища данных (EDW), пытаясь унифицировать, стандартизировать и администрировать коллективное понимание предметной области для облегчения управляемого обмена информацией.

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

В этой серии статей дается объяснение новых, эффективных способов решения проблем крупномасштабной интеграции данных. Она постепенно подводит к весьма интересному подходу в сфере жизненного цикла программного обеспечения: инициативе Open Services for Lifecycle Collaboration (OSLC). OSLC строится на архитектурном стиле Representational State Transfer (REST) и технологиях Semantic Web, таких как Resource Description Framework (RDF) и Linked Data Platform (LDP). Первые три статьи этой серии посвящены изложению технологической основы OSLC. В заключительных двух я представлю проект OSLC и продемонстрирую его применение.

Web: масштабируемая платформа взаимосвязанных документов

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

Первая технология – это Uniform Resource Locator (URL). Эта схема имен — сегодня основанная на спецификации Uniform Resource Identifier (URI) — выполняет двойную роль средства идентификации произвольного контента в глобальном информационном пространстве и средства, позволяющего запрашивать это контент. Мы обмениваемся документами и контентом, указывая эти идентификаторы в письмах, твитах, вики, ТВ-рекламе, на бортах автобусов и даже на салфетках. Поскольку идентификаторы основаны на доменных именах, которые мы контролируем, мы можем поддерживать требуемый баланс между центральным управлением и свободой на периферии. Поскольку идентификаторы имеют глобальную область охвата, но обычно привязаны к конкретным доменам, ими можно обмениваться, не опасаясь конфликтов. Я не могу создавать идентификаторы в доменах, контролируемых вами, и наоборот, но в моем собственном домене могу создавать их сколько угодно и когда угодно. Я могу выбрать любое имя и поделиться им с вами для импровизированного сотрудничества, хотя для стабильности, долговечности и гибкости этот URL должен быть хорошо продуман.

Мы привыкли видеть URL-адреса, указанные в документах или веб-приложениях, но архитектурный стиль REST позволяет применять их в самых разных информационных ресурсах.

Мы привыкли видеть URL-адреса, указанные в документах или веб-приложениях, но архитектурный стиль REST позволяет применять их в самых разных информационных ресурсах. Можно вызвать учетную запись посредством идентификатора http://example.com/account/id/12345 или указать на товар посредством идентификатора http://example.com/product/id/sku/9823423. Фактически, мы идентифицируем произвольные биты информации почти в бесконечном информационном пространстве.

Чтобы получить доступ к состоянию ресурса или взаимодействовать с ним тем или иным способом, можно использовать еще одну полезную веб-технологию: HTTP. HTTP предоставляет единый интерфейс к любому информационному ресурсу, произведенному кем-либо каким бы то ни было способом. Как потребитель информации, я ничего не знаю о том, как реализован этот ресурс, но мне это и не нужно. Обратившись к ресурсу с запросом GET, я получу некоторое представление о нем по умолчанию. Если я захочу изменить форму ресурса, то могу попытаться попросить сервер предоставить его мне в другой форме, если это возможно.

И последняя важная технология, которая делает работоспособной Всемирную паутину, – это язык HTML, на котором веб-ресурсы обычно возвращаются в браузер клиента. HTML обеспечивает представление запрашиваемых ресурсов со всеми возможностями, доступными для ресурса в его текущем состоянии. Можно перейти по ссылке на другой документ, создать авторизованный сеанс, войдя в систему и предоставив надлежащие учетные данные посредством формы, и т.п. Связь в этой системе осуществляется между браузером и возвращаемым представлением, а не между браузером и сервером. Сервер может перемещать ресурсы и изменять технологии реализации, а в браузере клиент, когда он запросит этот ресурс в следующий раз, сможет спокойно продолжать работать. Клиент узнает, где найти контент и что пользователь может с ним делать, из представления — а не потому, что он что-то знает о сервере.

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

RDF для взаимосвязанных информационных паутин

Совершив скачок к представлению о присвоении разрешимых идентификаторов произвольным битам информации, мы можем вообразить взаимосвязанные информационные паутины.

Совершив скачок к представлению о присвоении разрешимых идентификаторов произвольным битам информации, мы можем вообразить взаимосвязанные информационные паутины. Допустим, мы хотим указать, что данная статья – о Японии и что ее автор – Боб. Можно предположить, что для того чтобы выразить соответствующие факты и идеи, мы захотим дать произвольные ссылки на некоторые произвольные ресурсы. Люди ходят в определенные школы, работают в определенных организациях, рождаются в определенных местах и имеют семьи, домашних животных, интересы и друзей. Хотелось бы иметь возможность «переплести» (intertwingle – термин Теда Нельсона) все эти вещи между собой. Для этого нужна гибкая структура данных и способ бесконфликтно обозначать все это.

Стандарт URI уже предоставил нам возможность назначать произвольные идентификаторы в глобальном масштабе всему, чему угодно. Остается лишь применить этот стандарт к понятиям, а не только к документам или услугам. В примере из предыдущего абзаца нужны идентификаторы для документа, страны Япония, и Боба; все это объекты системы. Новое и непривычное здесь то, что нам также нужны идентификаторы для отношений: является темой и авторство. Узлом объекта будет идентификатор документа. Идентификаторы Японии и Боба станут узлами объектов. Идентификаторы отношений соединят эти объекты со значениями как именованные, направленные дуги. Гибкая структура, используемая для этой цели, – граф. Графа — в отличие от таблицы базы данных или дерева XML-документа — позволяет добавлять отдельные ассоциации в любое время, не оказывая влияния на остальную структуру.

Большинство систем графов терпят неудачу, пытаясь сохранить весь граф в одной системе хранения. Такие попытки обычно заходят в тупик, когда объем данных превышает определенный размер. Но с помощью разрешимых идентификаторов всемирной паутины (URL) можно сделать нашим графом всю паутину. Тогда мы сможем произвольно наращивать масштабы безразмерного информационного пространства. Нам не нужно упаковать паутину в контейнеры. Мы помещаем вещи в паутину.

Любая RDF-система может получать RDF из любой другой RDF-системы без какого-либо координирования.

RDF – это стандартная модель данных W3C именно с такими свойствами. Объекты используют URI (предпочтительно разрешимые URL-адреса) и связаны с помощью направленных отношений, определенных таким же образом. Как к объектам, так и к отношениям можно обращаться посредством глобальных идентификаторов, которые понятны сами по себе. Сериализовав граф в стандартный формат, мы получим полностью переносимые данные. Любая RDF-система может получать RDF из любой другой RDF-системы без какого-либо координирования. Приложения или пользователи могут пока не знать, что делать с данными, но, по крайней мере, смогут получать их и видеть, что они получают.

Чтобы продемонстрировать работу RDF, я воспользуюсь, казалось бы, глупым примером. Если бы я попросил вас изменить свою систему так, чтобы она приняла одно утверждение – о том, что мой день рождения 26 мая, вы бы не стали этого делать. Ваши таблицы не настроены на прием понятия «люди» и дат их рождения, и вам просто некуда ввести этот факт. А изменять таблицы и структуры классов слишком сложно. Конечно, проблема ввода моего дня рождения не достойна серьезного рассмотрения, но она существует и в менее нелепых сценариях. Отчасти она заключается в том, что мы склонны воспринимать сущности как отдельных вещи, которые хранятся в определенных местах. Мы не считаем вещами понятия, сведения о которых получаем из разных источников. В этом разница между моделью замкнутого мира и RDF-моделью открытого мира. В модели открытого мира мы принимаем тот факт, что кто бы то ни было может делиться фактами о чем угодно. Всего о данном предмете, на данную тему или по данному вопросу мы, возможно, не узнаем никогда. Это предположение может сбить с толку ИТ-менеджеров, которые хотят контролировать все, но оно позволяет системе сохранять гибкость и способность получать произвольные факты из любого источника.

Нам нужно идентифицировать меня, нужно идентифицировать отношения дня рождения и нужно знать, как представлять дату моего рождения. Для ссылки на себя я выбрал URL https://w3id.org/people/bsletten. Этот URL зарегистрирован в сообществе, которое обещало хранить стабильность зарегистрированных идентификаторов – в настоящее время это хранилище GitHub, которое можно копировать, изменять и к которому можно обращаться с pull-запросами для добавления своих собственных идентификаторов.

Я настроил этот идентификатор так, чтобы перенаправлять его в файл с моим описанием посредством HTTP-переадресации 303 See Also. В настоящее время это одна из рекомендаций группы технической архитектуры W3C (TAG) для неинформационных ресурсов. Я не сериализовал его достаточно хорошо, так что, запросив его, вы не сможете получить представление о моем текущем состоянии. Чтобы различать ссылку на меня и документ обо мне (который можно разыменовать и разложить), сообщение 303 предупреждает клиента, что запрос допустим, но не может быть выполнен непосредственно. Вместо этого ответ включает заголовок Location, который указывает на документ с моим описанием. (Я возвращусь к этому процессу в следующем выпуске).

Теперь, когда мы знаем, как сослаться на меня (предмет утверждения), нужен термин для ссылки на день рождения, который определяется как день, когда некто родился. Ничто не мешает мне выбрать свой собственный термин. Подходит что-то вроде http://bosatsu.net/ns/birthday, особенно если поместить в этом месте описание термина, чтобы любой мог разложить идентификатор свойства и выяснить, что оно означает. К счастью, мне это не понадобится. Сообщество, называемое Friend of a Friend (FOAF), согласовало ряд терминов, связанных с распределенными социальными сетями и сообществами во Всемирной паутине. В этой спецификации есть общепринятый термин для дня рождения: http://xmlns.com/foaf/0.1/birthday, что означает именно то, что должно означать. Если обратиться к нему через HTTP, то вы получите документ с описанием набора терминов. В документации также сказано, что формат должен быть следующим: mm-dd. Теперь у нас есть отдельный факт, связывающий предмет (меня), предикат (http://xmlns.com/foaf/0.1/birthday) и значение (05-26). Объединив все это, можно составить направленный граф, отражающий данное утверждение, как показано на рисунке 1. Предмет – это узел. Предикат – дуга. А значение находится с другой стороны дуги.

Рисунок 1. Один факт, выраженный в виде ориентированного графа
Один факт, выраженный в виде ориентированного графа
Один факт, выраженный в виде ориентированного графа

Теперь у меня есть все, что нужно, чтобы опубликовать свой день рождения в виде машинно-обрабатываемого факта. Для хранения утверждения в файле я буду использовать простую RDF-сериализацию, называемую N-Triples. Этот формат содержит один факт в каждой строке, оканчивающейся точкой:

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" .

Этот файл можно хранить в файловой системе или опубликовать в Интернете. Следовательно любая RDF-система должна быть в состоянии воспринять этот факт. Если пользователи этой системы не знают, кто я, они могут разложить идентификатор предмета и получить дополнительные сведения. Если они не знают, что значит день рождения FOAF, они могут сделать то же самое.

Допустим, я хочу опубликовать также свое полное имя. Опять же, я мог бы ввести свой собственный термин name, но это не обязательно, потому что в FOAF уже есть общепринятый термин для этой цели:

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

Граф на рисунке 2 отражает этот новый факт обо мне.

Рисунок 2. Другой факт, выраженный в виде ориентированного графа
Другой факт, выраженный в виде ориентированного графа
Другой факт, выраженный в виде ориентированного графа

Здесь начинается самое интересное. Независимо от того, хранятся ли два этих факта в одном и том же файле или в двух разных файлах, свойства и значения, если они считываются в одну и ту же модель (как показано на рисунке 3), будут отнесены к одному и тому же предмету, потому что оба утверждения относятся к предмету с одним и тем же идентификатором.

Рисунок 3. Два факта, выраженные в виде ориентированного графа
Два факта, выраженные в виде ориентированного графа
Два факта, выраженные в виде ориентированного графа

Вот как я использую N-Triples для хранения двух RDF-фактов об одном и том же предмиете:

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" . 
<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

Чем больше мы узнаем о предмете, тем больше дуг выходит из узла. Реальных границ того, сколько фактов можно узнать о чем-то, не существует, и дополнительные произвольные факты не влияют на остальную часть графа. Не имеет значения и то, откуда берутся эти факты; подсоединить можно все.

Это здорово, что каждый с помощью свойств может что-нибудь сказать о любом предмете, но нам также нужна возможность организовать свои ресурсы по типам вещей, которыми они являются. Это можно представить как распределение по классам. Если ресурс относится к человеку, можно сказать, что это лицо, входящее в класс Person (имена классов принято писать с прописной буквы). Тот же человек, если это инженер, может быть членом класса Engineer. Количество наборов словарей, в которые вы можете входить, и количество самих этих словарей не ограничено.

Схемы можно легко смешивать, но пока я буду придерживаться верного словаря FOAF. Поскольку одна из его основных целей – сообщать о людях, он включает в себя класс Person, который я могу использовать. Чтобы указать, что ресурс является экземпляром класса, нужен специальный предикат. Это принципиально важный предикат, и в RDF есть специальный термин для отношений такого типа: http://www.w3.org/1999/02/22-rdf-syntax-ns#type. Семантика утверждений этого типа отличается от отношений принадлежности, которые мы видели до сих пор, но выражается так же:

<https://w3id.org/people/bsletten> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
    <http://xmlns.com/foaf/0.1/Person> .

Дополнительная дуга в графе на рисунке 4 также подобна тем, что вы уже видели.

Рисунок 4. Экземпляр отношений в ориентированном графе
Экземпляр отношений в ориентированном графе

Наконец, как вы могли догадаться, сочетание всех трех утверждений, выраженное в форме N-Triples, можно объединить:

<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/birthday> "05-26" . 
<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/name> "Brian Sletten" . 
<https://w3id.org/people/bsletten> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 
                 <http://xmlns.com/foaf/0.1/Person> .

На рисунке 5 показаны три факта, выраженные в виде графа.

Рисунок 5. Три факта, выраженные в виде ориентированного графа
Три факта, выраженные в виде ориентированного графа
Три факта, выраженные в виде ориентированного графа

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

Преобразование между RDF-форматами

Формат N-Triples не очень удобен для восприятия человеком. Он рационален для хранения фактов с возможностью легко анализировать их, но все эти повторения затрудняют восприятие сути конкретного предмета. Сейчас я покажу вам более удобный формат, называемый Turtle, что расшифровывается как Terse RDF Triple Language (лаконичный язык RDF- троек). (Существует ряд других форматов, в том числе уродливый XML-формат RDF/XML).

Преобразование между форматами выполняется тривиально. Один из способов заключается в использовании инструмента rdfcat из проекта Apache Jena. Здесь я прошу rdfcat преобразовать триады в формат Turtle:

> rdfcat -out ttl basic.nt 
<https://w3id.org/people/bsletten> 
  a <http://xmlns.com/foaf/0.1/Person> ; 
  <http://xmlns.com/foaf/0.1/birthday> "05-26" ; 
  <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

Как видите, в формате Turtle каждый предмет упоминается только один раз (тот же идентификатор может выступать предметом другого отношения). Каждый факт о предмете отделяется точкой с запятой. Точка завершает факты о данном предмете в данном файле. Конечно, из других источников можно узнать другие факты.

Допустим, что я опубликовал в Интернете еще Turtle-файл, содержащий дополнительные факты обо мне. В этом файле используется свойство http://xmlns.com/foaf/0.1/depiction для указания того, что в Интернете есть моя фотография. Это свойство имеет тот же формат, но только один факт:

> http get http://bosatsu.net/turtle/brian.ttl 
HTTP/1.1 200 OK 
Accept-Ranges: bytes 
Access-Control-Allow-Origin: * 
Content-Length: 124 
Content-Type: text/turtle 
Date: Mon, 10 Mar 2015 04:56:39 GMT 
ETag: "1049e7-7c-50fd9f13a4140" 
Last-Modified: Tue, 24 Feb 2015 18:46:53 GMT 
Server: Apache/2.2.16 (Debian) 
 
<https://w3id.org/people/bsletten> <http://xmlns.com/foaf/0.1/depiction> 
               <http://bosatsu.net/images/briansletten.jpg> .

Теперь вы знаете, что данные из локального и удаленного файлов легко объединяются в общую модель. Так как в обоих местах я использую один и тот же идентификатор, объединить эти данные нетрудно:

> rdfcat -out ttl basic.nt http://bosatsu.net/turtle/brian.ttl 
<https://w3id.org/people/bsletten> 
        a       <http://xmlns.com/foaf/0.1/Person> ; 
        <http://xmlns.com/foaf/0.1/birthday> "05-26" ; 
        <http://xmlns.com/foaf/0.1/depiction> 
                <http://bosatsu.net/images/briansletten.jpg> ; 
        <http://xmlns.com/foaf/0.1/name> "Brian Sletten" .

rdfcat – это один из множества инструментов и библиотек, которые «знают», как манипулировать стандартами и соединять данные из разных источников. Благодаря этим стандартам стоимость интеграции данных падает почти до нуля. Например, можно представить себе преимущества соединения таблицы продаж со сторонним источником данных, содержащим рейтинги проданных товаров. Объединение этих источников сразу покажет, что вам необходимо срочно укрепить службу технической поддержки, потому что вы продаете много товаров с низким рейтингом.

Заключение

RDF – это невероятно мощная модель данных, и в последующих статьях этой серии мы будем расширять свое представление о ее возможностях. Пока же достаточно осознать простоту и гибкость использования произвольных источников данных. Понятно, почему инициатива OSLC стремится соединить информацию из разных продуктов и от разных участников в единое, связанное целое. Немного тщательного планирования, и ресурсы, представляющие требования, можно будет соединить с кодом, который их реализует. А тесты для кода – с результатами их выполнения. Отдельные изменения в исходном коде можно соединить с конкретными событиями или даже ответственными исполнителями.

Использование модели на основе URI и графов вызывает некоторое опасение у разработчиков, знакомых с простотой формата пар ключ/значение JSON. Какое-то усложнение возможно — ведь речь идет о взаимосвязанных графах данных, а не о простой сериализации одного или нескольких объектов, — но не пугайтесь. Такие стандарты, как JSON-LD, позволяют тривиально соединить JSON и RDF и убить сразу двух зайцев.

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


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи: Data integration at scale: Creating webs of data with RDF.
  • RDF: страница о RDF в вики W3C Semantic Web.
  • OSLC: веб-сайт сообщества проекта OSLC по созданию стандартов, которые облегчают и рационализируют обмен данными между инструментами жизненного цикла программного обеспечения. Этот проект, входящий в OASIS Open Standards Network, инициирован IBM и ее партнерами.
  • N-Triples: подробнее о синтаксисе RDF-графов на основе N-Triples.
  • Turtle: RDF-синтаксис Turtle.
  • Apache Jena: чтобы пользоваться rdfcat, нужна Jena.

Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Web-архитектура, Information Management, Open source
ArticleID=1020463
ArticleTitle=Широкомасштабная интеграция данных: создание информационных паутин с помощью RDF
publish-date=11102015