Язык rdf. RDF — инструмент для неструктурированных данных

Модель RDF, разработанная консорциумом W3C для веб-метаданных, использует язык XML в качестве синтаксиса для взаимного обмена. Важнейшая цель RDF состоит в упрощении работы автономных агентов, что очистило бы Интернет посредством совершенствования поисковых машин и сервисных каталогов. Для получения дополнительной информации об RDF прочитайте документ (developerWorks, декабрь 2000 г.).

В оставшейся части этой статьи аннотации HTML-кода в будут рассмотрены с целью демонстрации всех пяти атрибутов спецификации RDFa Lite: vocab , typeof , property , resource , prefix .

Листинг 2. HTML-код для демонстрации RDFa Lite

Атрибут vocab

В показано изменение элемента body с целью упаковки описания всей статьи.

Листинг 3. Использование атрибута vocab

Атрибут vocab готовит почву в RDFa Lite. Он указывает на словарь, который по умолчанию будет использоваться в аннотациях. В нашем примере используется словарь, соответствующий стандарту Schema.org, поэтому мы выбираем элемент типа wrapper (упаковщик), чтобы пометить его надлежащим образом. У вас нет необходимости использовать элемент body , однако вам следует использовать элемент, который упаковывает все аннотации.

Атрибут typeof

В shows the outline of a div to enclose the one article being described.

Листинг 4. Использование атрибута typeof

Атрибут typeof помечает свой элемент как описание или как представление экземпляра заданного класса. Посредством обозначения vocab , заданного стандартом Schema.org , этот элемент помещается в соответствующий контекст, в результате чего становится ясно, с каким определением "article" (статья) мы имеем дело. Article — это один из классов, специфицированных стандартом Schema.org. Каждое определение класса документировано, в том числе соглашения по его использованию и ассоциированные с ним свойства.

Атрибут property

В показан фрагмент, размечающий заголовок статьи.

Листинг 5. Использование атрибута property

Атрибут property предоставляет свойство объекта, который только что был декларирован как объект Article стандарта Schema.org . Свойство name был задано для того, чтобы дать заголовок этому объекту Article .

В показаны первые три атрибута RDFa Lite.

Листинг 6. Три атрибута RDFa Lite

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

Более изощренные утверждения

Спецификация HTML уже предоставляет доступное для машинной обработки место для размещения заголовка статьи — в элементе head . Однако словарь Schema.org позволяет нам сообщить о статье гораздо больше информации, чем один лишь заголовок, в том числе конструкты, выходящие за рамки HTML (и действительно, на момент написания статьи этот словарь содержал 46 свойств). Даже в случае таких свойств, как заголовок, возможности HTML не всегда оказывались достаточными. Представьте себе, что у вас есть страница, включающая индекс статей, или начальная страницы с результатами поиска. Вам пришлось бы на одной HTML-странице описать несколько реальных статей. HTML не располагает никакими возможностями на этот случай, однако Schema.org позволяет нам иметь несколько элементов div — по одному для каждой статьи, на которую производится ссылка.

Атрибут resource

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

Листинг 7. Атрибут resource

Данный фрагмент добавляет информацию о том, что "Автор данной статьи — это человек по имени Uche Ogbuji, который является компаньоном в компании Zepheira". Обратите внимание на то, как p элемент был помечен в качестве описания нового объекта типа Person согласно Schema.org. Кроме того, элемент p имеет элемент property , который соединяет этот объект с объектом, заключающим в себе статью.

Атрибут resource предоставляет объекту, описанному в элементе p, идентификатор, который идентифицирует соответствующий фрагмент по отношению к URL-указателю самой страницы. Например, если эта страница находится по адресу http://www.сайт/developerworks/library/w-rdf, то теперь существует объект, который имеет идентификатор http://www..ogbuji.

Zepheira — это организация. В качестве дальнейшего развития этого примера мы можем выразить Zepheira как еще один вложенный объект, используя для этого класс Organization , описанный в спецификации Schema.org. RDFa позволяет нам аннотировать все, что мы считаем важным. В данном случае нас интересуют более подробные сведения об авторе, а не об организации, в которой он работает.

Атрибут prefix

Заключительный атрибут, описанный в спецификации RDFa Lite — prefix — используется для объединения нескольких словарей в одном описании.В показано, каким образом можно аннотировать индекс "читабельности" статьи.

Листинг 8. Атрибут prefix

Спецификация Schema.org не содержит свойства для индекса читабельности текста Gunning-Fog — в отличие от Freebase. Freebase — несколько более структурированная разновидность Wikipedia — управляет схемами и описаниями для широкого разнообразия объектов и типов объектов. Я задал префикс для ссылки на свойства согласно спецификациям Freebase, а не словарю Schema.org по умолчанию, а затем использовал этот префикс для текста, представляющего собой значение индекса читабельности для данной статьи.

Обобщающий пример

В сведены воедино все продемонстрированные к настоящему моменту элементы, а также добавлены такие элементы, как breadcrumb.

Листинг 9. Использование всех пяти атрибутов RDFa Lite

С точки зрения структуры здесь нет ничего нового, однако в показано несколько других свойств Schema.org, которые вы сможете использовать для какой-либо статьи.

Заключение

Помимо Schema.org существуют и другие словари, в том числе Dublin Core (имеющий базовую поддержку в RDFa) и Facebook Social Open Graph. Тем не менее, стандарт Schema.org в последнее время получил мощную поддержку, особенно с учетом своих выдающихся апологетов. Это новейшее достижение в длинном перечне событий в такой сфере, как оптимизация поисковых механизмов (search-engine optimization, SEO).

Вполне возможно, что идея SEO имеет преимущественно маркетинговый характер, однако она полностью базируется на таких концепциях совершенствования веб-технологий, как достижимость, чистая разметка и аннотирование страниц — везде, где это возможно, и с привлечением большего количества информации о фактическом значении контента. Такие достижения, как RDFa Lite, призваны разместить мощные возможности SEO в пределах досягаемости практически любого сетевого автора. Я надеюсь, что эта статья поможет вам изучить RDFa за один день и призывают вас немедленно приступить к аннотированию своих страниц.

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

Однако для многих все еще совсем не понятно:

• Зачем все это?
• Как с этим работать?
• Что это даст именно мне?

Большинство, хотя бы мельком, видели знаменитый пирог:

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

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

• Логический вывод новых фактов
• Обеспечения семантического поиска
• Гибкость модели данных
• Экстремальная легкость обмена данными между системами

Если вы никогда раньше не изучали формальную логику, то пока отложите в памяти, что имея формально описанные факты можно автоматически получить ряд новых фактов, явно не определенных… эта тема заслуживает отдельного внимания, пока ее не трогаем.

Семантический поиск, зачем, ведь есть гугл?
Да можно ввести и вы получете что угодно только не то набор пользователей. Почему? - потому что гугл будет искать нахождение слова из запроса в тексте документов, и возвращать документы а не факты.
А если бы он понял что нам нужны объекты «пользователь» ресурса «хабр», а формальные описания этих объектов были бы доступны для индексирования в модели RDF (например в форме записи RDFa на странице, чтобы поисковая машина могла бы их проиндексировать) был бы получен набор объектов которые мы искали.
Многие возражают – «я могу походить по паре ссылок, сделать еще пару уточняющих запросов и найти все же что нужно, зачем все это?» – ответ – затем что мы не используем бумажные картотеки сегодня, а предпочитаем вбить в строку поиска пару ключевых слов, и само сабой разумеется сразу же получить информацию. На работу мы почему-то ездим на машинах, а на лошадях – потому что это удобнее.

На вопрос – «Как RDF обеспечивает семантический поиск?» - ответ: RDF модель обеспечивает формальные описания. А там где есть формальные описания поисковый агент может искать факты и знания.

Гугл сегодня такое не ищет – зачем мне надо сейчас париться об этом? В первую очередь для получения преимуществ описанных дальше, а во вторых чтобы не «опоздать» - индустрия у нас такая – «be quick or be dead».

Поговорим более подробно о двух других преимуществах, они гораздо проще для понимания, как мне кажется. Но для начала проясним еще пару моментов.

Что такое модель RDF?

Сразу нужно понять RDF – это модель, абстрактная, очень простая, немного в вакууме. Просто направленный граф с несколькими дополнениями и оговорками. А вот записать его можно по разному, обычно выбор падает на один из вариантов: N3,N-Triples, Turtle,RDF/XML,RDFa и используемую спецификацию придется изучить.

Что описывается: С помощью RDF можно описать как документы, отдельные фрагменты знаний внутри документа, так и объекты реального мира, например конкретного живого человека (тут некоторые it-шники впадают в ступор) .
Идентифицируется все с помощью URI. Притом URI хоть и похож на обычные URL ссылки – немного другое, например можно определить ресурс – реального человека и задать для него URI «http://example.org/people#Вася Пупкин».
Да, можно писать по русски так как юникод а вот что нужно понимать, так то, что это не url – нельзя вставить в браузер и получить человека - наука до этого еще не дошла.

Попробуем разобраться где-же здесь гибкость модели и обмена данными между системами.

Давайте посмотрим как общаются люди:

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

Если вы не знаете китайского языка – это вам не помешает сделать ctrl-c ctrl-v из одного места в другое.

Очень похожим образом работает RDF.

Информацию нужно интерпретировать только при ее формализации приложения в RDF и чтении ее агентом на другом конце. Между этими двумя этапами ее может обрабатывать кто угодно, как угодно ею обмениваться, не обязательно представляя какой смысл заложен, или понимая смысл, только часть утверждений.

Например, RDF утверждение (триплет субъект-предикат-объект)

Таким образом мы можем обмениваться с кем угодно, не делая лишних телодвижений, в том числе мы интегрироваться с n+1 системой делая больше усилий не больше чем мы для показа нашего веб-сайта n+1 пользователю! Не надо программировать ничего для этого. Все понятия которые нужны будут этой системе от вашей - она сможет получить и интерпретировать.

Для сравнения сегодня – надо поля одной системы явно связывать с другой (часто с каждой) с помощью XML, XSLT – или полями, получаемыми из API – и многие из нас знают какая, это головная боль.

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

Этот факт несет следующее важное преимущество – легкость в изменении модели .

Представим, что потребуется сделать в приложении, которое опирается на реляционную модель. Для драматичности представим что делать это надо уже после запуска если требуется изменить модель данных, например, связать с объектом пользователя некую новую сущность, скажем адрес (который к слову, не одна строчка, а содержит отдельные поля для дома, города, улицы и т.д.). Что потребуется сделать с базой данных? Правильно подправить пару табличек, может быть создать новые, добавить связь между ними, изменить процедурки для доступа к данным, подправить веб сервис и все готово. Ну и конечно надо изменить пользовательский интерфейс.

Немного некомфортно этим заниматься, не кажется?

А на сколько проще было бы, если все, что надо было сделать – это только добавить пару полей в интерфейс и выполнить действие добавления одного нового утверждения для каждого нового поля (от этого минимума тоже можно иногда уйти, если у нас более универсально спроектирован интерфейс)? пара строчек кода…
С RDF моделью за спиной эта операция будет выглядеть именно так. Ведь все что хранится - это огромное число утверждений субъект-предикат-объект. Таким образом изменение модели данных перестает быть тем, что портит настроение как только об этом подумаешь, не правда ли здорово?

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

14.11.2012 Владислав Головков, Андрей Портнов, Виктор Чернов

Реляционная модель, десятилетиями служившая основой технологии работы с данными, более не является главенствующей - на сцену выходят новые задачи, требующие учета и выявления существенно большего количества взаимосвязей. Среди новых методов обработки данных выделяется модель RDF: переход от баз данных SQL к системам RDF обещает технологический скачок, сравнимый с переходом от Кобола к SQL.

До сих пор наиболее распространенной моделью хранения данных была реляционная, которая с конца 70-х годов и поныне является стандартом де-факто на хранение структурированных данных, а язык SQL - стандартом на их обработку. Однако доля структурированных данных становится все меньше, и реляционная модель испытывает все больше проблем при работе со значительными объемами данных - давно, например, была замечена деградация производительности реляционных СУБД при решении задач аналитической обработки, характерными чертами которых являются «длинные» SQL-запросы, работающие с несколькими таблицами при наличии большого числа агрегатов.

Сегодня задачи, выходящие за рамки реляционной модели, принято относить к классу NoSQL, каждый подкласс которого решает ту или иную проблему, плохо реализуемую с помощью SQL, - например, базы данных с поколоночным хранением, документо-ориентированные, графовые, базы данных ключ-значение и объектные. Скажем, базы данных ключ-значение применяются для задач, характеризующихся чрезвычайно большими объемами, отсутствием операций join и ограниченными требованиями к обновлению данных (например, только добавление). В силу своего объема такие базы заведомо распределенные, что, в свою очередь, означает полный отказ от транзакций - такая упрощенная модель данных дает новые возможности повышения производительности за счет широкого использования параллельных архитектур.

Еще один класс задач, трудно решаемых на реляционной модели, - это задачи на сильно связанных данных или графовые задачи. Попытки решения таких задач на реляционной модели приводят к непредсказуемому количеству соединений в запросах, поэтому для решения графовых задач сегодня наибольшее распространение получили RDF-хранилища, главным достоинством которых является наличие хорошо проработанных стандартов комитета W3C на язык описания графов (Resource Description Framework, RDF) и на обработку графовых данных (SPARQL - рекурсивный акроним: SPARQL Protocol And Rdf Query Language).

Модель RDF возникла в конце 90-х годов, а в 2001 году в журнале Scientific American была опубликована знаменитая статья Тима Бернерса Ли, провозглашающая приход эры семантической паутины (Semantic Web). С той поры в сетевом сообществе стал лавинообразно нарастать интерес ко всему, что связано с семантической обработкой, в том числе и к RDF, который в 2004 году был принят как стандарт комитета W3C.

Основа RDF - это хорошо известное специалистам по искусственному интеллекту представление данных в виде утверждений (троек, triples) субъект-предикат-объект, описывающих направленную связь от субъекта к объекту. Для идентификации субъектов, объектов и предикатов используется идентификатор Uniform Resource Identifier (URI), являющийся обобщением понятия URL. Например:

субъект/объект:

Предикат:

Объекты, кроме URI, могут быть представлены также литералами, например, название журнала: «Journal 1 (1940)»^^xsd:string.

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

Наиболее известные форматы представления RDF - текстовые файлы XML, JSON, N-Triples, N3 и Turtle. Например, представление некоторых данных в формате Turtle:

@prefix xsd: . @prefix f: . xsd:type ; f:name «Стандарт специализированной медицинской помощи детям с галактоземией»; f:mkb ; f:service , ; f:drug ; xsd:type ; f:name «Оптиконевромиелит [болезнь Девика]»; xsd:type ; f:name «Общее нейропсихологическое обследование»; xsd:type ; f:name «Актовегин»;

Данный пример представляет фрагмент графа, описывающего стандарт медицинской помощи при заболевании, включая диагноз по классификатору МКБ 10, связанные с ним медицинские услуги и медикаментозное лечение.

Модель RDF по существу описывает ориентированный граф (рис.1), в котором каждая тройка - это описание отношения, то есть связи между двумя узлами.

Язык запросов

Модель RDF служит для описания данных, но не описывает методов их обработки. Существует целый ряд языков запросов к RDF-данным: DQL, N3QL, R-DEVICE, RDFQ, RDQ, RDQL, SeRQL и т. д., но самым популярным стал SPARQL, принятый в качестве стандарта W3C. Язык SPARQL, в отличие от SQL (который критикуют, в частности, за отсутствие кросс-платформности, проблемы с обработкой отсутствующих данных, неоднозначную грамматику и семантику), обладает более стройной структурой и мощью. Основная часть запроса на SPARQL - шаблон, описывающий подграф, который требуется найти в общем графе. Шаблон представляется в виде набора троек с переменными - например, запрос на поиск в некотором графе человека по имени Петр:

Select? x where {? x: тип: человек. ? x: имя «Петр» }

Здесь Блок «select» содержит список переменных для вывода результата запроса; «?x» - это переменная, которая в момент поиска приобретет значение URI найденного объекта. Блок «where» содержит набор троек, составляющих шаблон запроса. В результате поиска будет найден подграф, удовлетворяющий шаблону (рис. 2).

Язык SPARQL прост в освоении для человека, знакомого с SQL, - многое в SPARQL ему покажется известным. Например, в языке присутствуют такие конструкции, как UNION, ORDER BY, GROUP BY, DISTINCT, OFFSET и LIMIT. На сегодняшний день SPARQL является одним из самых выразительных языков обработки данных. Кроме языка запросов, стандарт SPARQL регламентирует протокол взаимодействия с базой данных и формат результата, что является большим шагом вперед по сравнению с SQL.

Вместе с достоинствами модель RDF и язык SPARQL имеют и недостатки. Начнем с достоинств.

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

Современная архитектура. Запросы к хранилищу RDF обычно совершаются с помощью протокола HTTP, благодаря чему они легко встраиваются в сервисные архитектуры без построения промежуточных слоев, потери надежности и производительности. RDF и SPARQL лучше работают с интернациональным контентом, чем базы SQL.

Стандартизация. Уровень стандартизации RDF и SPARQL гораздо выше, чем в SQL, - усилиями комитета W3C определены стандарты не только на модель RDF и язык SPARQL, но и на идентификацию ресурсов (URI), протокол взаимодействия компонентов (HTTP), точку доступа SPARQL и т. д. Благодаря стандартизации, данные, выгруженные из любого RDF-хранилища, можно загружать в RDF-хранилища различных производителей. Запросы на SPARQL одинаково выполняются на разных хранилищах, что высоко ценят разработчики, сталкивающиеся с проблемами переноса данных и запросов из одной базы в другую.

Метаданные. SPARQL позволяет легко отследить происхождение любых единиц данных. В RDF легко хранить самые разные метаданные. На основе метаданных можно делать сложные запросы, выбирая, скажем, данные из конкретных источников, в конкретном временном диапазоне и т. д.

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

Инструментарий RDF

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

Berlin SPARQL Benchmark (BSBM). Тест (www4.wiwiss.fu-berlin.de/bizer/berlinsparqlbenchmark) моделирует данные, связанные с электронной коммерцией, включая товары от разных производителей, отзывы покупателей о товарах и т. д. Данный тест предназначен для оценки скорости выполнения SPARQL-запросов. Модель приближена к реляционной, поэтому есть возможность оценить, насколько эффективна была бы замена базы данных SQL на RDF-хранилище. Модель и запросы теста весьма продуманны и приближены к практике. Возможно, поэтому BSBM - один из наиболее популярных тестов. В опубликованных на сайте разработчиков теста результатах за февраль 2011 года лидером являются такие средства разработки для RDF, как Virtuoso, 4Store, OWLIM и Jena TDB.

SP²Bench SPARQL Performance Benchmark. Тест (dbis.informatik.uni-freiburg.de/index.php?project=SP2B) построен на модели известной библиотеки DBLP литературы по логическому программированию (DataBase systems and Logic Programming): публикации, статьи, журналы, книги и т. д. Так же, как и BSBM, данный тест разработан для оценки скорости выполнения SPARQL-запросов, однако он использует более изощренные запросы, в ущерб их реалистичности. Данный тест хорош для тестирования оптимизатора запросов, поскольку содержит много сложных операций объединения. В опубликованных результатах места распределились следующим образом: Virtuoso, Sesame, ARQ. Недавно проведенное нами сравнительное тестирование сервера RDF NitrosBase Storage на тестах SP2Bench показало его значительное превосходство в производительности перед Virtuoso (от 10 до 10 тысяч раз в зависимости от запроса).

DBpedia SPARQL Benchmark. Тест DBPSB (svn.aksw.org/papers/2011/VLDB_AKSWBenchmark/public.pdf) основан на реальных запросах к базе знаний Dbpedia. Методика разработки теста настолько же оригинальна, насколько целесообразна. Авторы анализируют логи реальных обращений пользователей к базе Dbpedia, кластеризуют их и выделяют наиболее статистически значимые группы запросов, которые затем вносятся в очередную версию теста. Таким образом, DBPSB - это максимально приближенный к жизни тест. Наиболее быстро этот тест выполняет Virtuoso, затем идут OWLIM, Sesame и Jena TDB.

Lehigh University Benchmark. Тест LUBM (swat.cse.lehigh.edu/projects/lubm/) специально разработан для оценки семантических возможностей, поэтому не так распространен, как другие. Основан он на онтологической базе знаний о некотором университете. Известны результаты этого теста, прежде всего, для систем со средствами логического вывода, такими как OWLIM, YarcData, Sesame и др.

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

Apache Jena - Java API для разработки приложений Semantic Web. Продукт включает в себя несколько хранилищ, собственное хранилище троек (Jena TDB), интерфейс к реляционному хранилищу (Jena SDB), хранилище в памяти (In-Memory), а также средства для поддержки собственных хранилищ. Наиболее сильная сторона Jena - богатый программный интерфейс. Многие RDF-хранилища используют Jena API для доступа к собственным СУБД (IBM, OWLIM и т. д.). Слабой стороной является низкая производительность даже на родном хранилище.

Ontotext OWLIM - семейство семантических репозиториев или RDF СУБД с собственным ядром, реализованным на Java, с поддержкой семантики на RDFS (RDF Scheme) и OWL. Продукт OWLIM активно используется в научно-исследовательских проектах и программных системах. Выпускается в следующих редакциях: OWLIM-Lite для приложений, поддерживающих менее 100 млн троек; OWLIM-SE (ранее BigOWLIM) предназначен для обработки больших объемов данных, с большими потоками запросов; OWLIM-Enterprise (ранее BigOWLIM Replication Cluster) предназначен для построения масштабируемых производительных надежных решений, основанных на параллельной обработке и имеющих средства автоматической защиты от сбоев.

OpenLink Software Virtuoso - обладает собственным мощным RDF-хранилищем, полной реализацией SPARQL, возможностью чтения данных RDF из файлов формата XML и Turtle. Кроме того, поддерживается SPARQL/Update (SPARUL) - расширение SPARQL для поддержки обновления данных. Продукт является одним из лидеров по производительности.

Крупные корпорации, такие как IBM и Oracle, также разрабатывают собственные RDF-решения. Первая встроила в очередную версию СУБД DB2 вариант модели RDF, имеющий название NoSQL Graph Support, с интерфейсом на основе расширения API Jena. Отличается высокой производительностью выполнения RDF-операций. Компания Oracle подключила RDF к своему продукту для работы с пространственными данными - Spatial Data Option, который теперь называется Spatial and Graph Option.

Кроме того, разрабатываются специализированные компьютеры, ориентированные на работу с графовой информацией и поддерживающие модель RDF. Например, в начале 2012 года компания Cray объявила о создании нового высокопроизводительного программно-аппаратного комплекса uRiKA (universal RDF integration Knowledge Appliance), ориентированного на рынок семантических баз данных.

Задачи

После статьи Тима Бернерса Ли в общественном сознании модель RDF стала прочно ассоциироваться с семантической паутиной, однако потенциал этой модели намного выше. Например, большинство задач, решаемых сегодня в рамках реляционной модели, легко можно решать и на RDF. Кроме того, RDF-хранилища позволяют собирать, хранить и индексировать данные из различных источников - в частности, при решении актуальной задачи интеграции сервисов, которая сводится к объединению разрозненных реляционных баз в единую базу и приводит к задаче обработки квазиструктурированных данных. Данные внутри каждой из баз строго структурированы для работы с реляционной моделью, но каждая база структурирована по-своему, поэтому задача их интеграции в рамках реляционной модели требует реинжиниринга всего решения. Если же конвертировать такие базы в модель RDF, то интеграция сведется к простому слиянию RDF-графов и переписыванию запросов из SQL в SPARQL, что не составляет труда в силу гораздо большей выразительности SPARQL по сравнению с SQL.

RDF-хранилища идеально подходят для задач, требующих учета и выявления большого количества взаимосвязей. Кроме наиболее широко анонсируемых задач, связанных с развитием Semantic Web, существует большое количество классических задач, требующих применения графовых подходов:

• обработка семантических сетей (и других графовых структур), полученных в результате анализа текстов (системы специализированного аналитического поиска, системы анализа рынков, маркетинговые исследования, анализ текстов в системах безопасности и др.);
• представление и обработка данных для анализа поведения в социальных сетях (маркетинговые исследования, например построение портрета покупателя; анализ и выявление центров распространения информации в социальных сетях; анализ политических предпочтений);
• анализ и обработка данных о взаимодействии различных модулей и подсистем (включая анализ логов) для систем обеспечения надежности и безопасности больших программно-аппаратных комплексов;
• представление и обработка графов, содержащих разнородную информацию в системах планирования и управления ведением боевых операций;
• обработка данных сложных научных экспериментов;
• медицинские системы нового поколения, особенностью которых является то, что, например, различные услуги требуют различных структур для своего описания, что очень сложно укладывается в строгую реляционную модель. Как только медицинская система начинает учитывать не только сам факт услуги, но и ее детализацию, то сложность системы резко возрастает - например, услуга «осмотр врача» и услуга «клинический анализ» имеют с точки зрения реляционной модели совершенно различную структуру данных, а RDF позволяет обрабатывать такие данные естественным образом, существенно сокращая трудозатраты на развитие и сопровождение подобных систем;
• интеллектуальные адаптивные системы управления производством, имеющие ярко выраженную графовую структуру;
• финансовый анализ, основанный на моделировании и обработке графов, описывающих взаимодействие участников рынка, выявление аффилированных компаний, коррупционный анализ, анализ движения средств структур и т. д.

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

Владислав Головков ([email protected]), Андрей Портнов ([email protected]), Виктор Чернов ([email protected]) - сотрудники компании «Компайл Груп» (Москва).