Что такое RDF и для чего он хорош?

Эта статья является введением в RDF (Resource Description Framework — модель описания ресурсов), стандарт для кодирования метаданных и других видов знаний в семантическом вебе (Semantic Web). Благодаря семантическому вебу компьютерные программы могут использовать возрастающие объёмы структурированных данных, распределённо и децентрализованно рассеянные по сети в настоящее время. RDF представляет собой абстрактную модель, обеспечивающую способ разбиения знаний на дискретные части. Хотя наиболее известным синтаксисом является RDF/XML, RDF можно хранить в разных форматах. В этой статье рассматриваются: абстрактная модель RDF, два конкретных формата для его представления в последовательной форме, способы использования RDF и его отличия от чистого XML, высокоуровневая семантика RDF, лучшие методы устройства источников RDF-данных и выполнения запросов к ним.

Данный документ был изначально написан в октябре 2005 года. В июле 2006 года он был пересмотрен и расширен материалом из опубликованной мной на xml.com статьи "Что такое RDF" ("What is RDF"). В январе 2008 года была обновлена информация о N3 и RDF/XML и появились новые разделы о связанных данных (Linked Data) в веб и о запросах к базам данных семантического веба.

Почему мы нуждаемся в новых стандартах для семантического веба?

Используя семантический веб компьютеры самостоятельно собирают для нас данные. Семантический веб ("SemWeb") позволяет им разыскивать распределенные в сети знания, связывать их вместе, и затем использовать по назначению. Говоря на языке аналогий, веб в его нынешнем проявлении — это децентрализованная платформа по распространению визуальных представлений, в то время как семантический веб — децентрализованная платформа для распределённых знаний. RDF является стандартом W3C для кодирования знаний.

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

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

Теперь представим себе новый Интернет, в котором настоящим содержимым могут манипулировать компьютеры. Проиллюстрируем это как сеть баз данных. На одном "семантическом" сайте публикуется база данных о линейке продуктов (продукты и их описания). В то же время на другом сайте публикуется база данных, содержащая обзоры продуктов. На третьем сайте для розничной торговли публикуется база данных продуктов на складе. Какие стандарты могут упростить написание приложений для совместного использования распределённых баз данных, обеспечив возможность компьютерной обработки данных из этих трёх источников таким образом, чтобы помочь конечному пользователю принять более обоснованное решение о покупке?

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

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

[[рисунок: Знания в форме графа.]]

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

[[таблица: Начальный узел, метка дуги и конечный узел.]]

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

2. Файлы в семантическом вебе должны соотноситься друг с другом. Прайс-лист, размещенный продавцом, и независимо от него опубликованный потребителем обзор товаров, должны включать в себя способ определения того, что речь идет об одном и том же продукте. Использование только имени продукта недостаточно. В мире может существовать два продукта с именем "Супер Штука 3000", а мы хотим избежать неоднозначности в семантическом вебе, чтобы компьютеры могли обрабатывать информацию с уверенностью. Для семантического веба нужны глобальные уникальные идентификаторы, которые могут быть назначены децентрализовано.

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

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

[[пример: Пример нотации 3.]]

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

[[пример: Пример RDF/XML.]]

RDF изначально был создан в 1999 году в качестве основанного на XML стандарта описания метаданных. Буквально, метаданные - "данные о данных". Метаданными называют, например, сведения об авторе веб-страницы, дату очередной публикации в блоге, и тому подобную информацию, которую можно считать вторичной по отношению к основному содержанию. С момента своего рождения (и особенно после выхода обновленной спецификации 2004 года) RDF расширял рамки своего назначения. Наибольшим обобщением является применение RDF не только для представления информации о ресурсах в сети, но также для описания объектов реального мира и их взаимосвязей: людей, мест, понятий и т.д.

Введение в RDF

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

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

Между RDF и XML можно провести некоторые аналогии. В основу XML тоже заложены принцип простоты и поддержка данных любого типа. XML тоже представляет собой нечто большее, чем просто формат файла. XML - это основа для манипулирования иерархическими, самоописываемыми документами, как сохранёнными на диске в обычном формате с угловыми скобочками и знаками слеш (называемом "brackets-and-slashes"), так и хранимыми в памяти.

Отличает RDF от XML то, что RDF разработан для представления знаний в распределённом мире. Тот факт, что RDF разработан для знаний, а не для данных, означает, что RDF отчасти имеет отношение к смыслу. Всё, что упомянуто средствами RDF, содержит некоторое значение. Это может быть ссылка на что-либо в реальном мире, например, человека или действие, или это может быть абстрактное понятие, например, отношение дружбы. Стандарт RDF описывает, как с помощью объединения трёх таких сущностей можно констатировать некоторый факт. Значение триплета "(Джон, Боб, отношение дружбы)" заключается в том, что Джон и Боб являются друзьями. Совокупность фактов в достаточном количестве может являться некоторой формой представления знаний. Стандарты, основанные на RDF, включая RDFS и OWL, дополняют семантику RDF, делая возможным построение логических выводов на основе совокупности данных.

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

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

[[блок: Для ознакомления с официальной документацией по RDF начните с "RDF Primer".]]

Знания в виде триплетов

RDF обеспечивает универсальный, гибкий метод декомпозиции знаний на маленькие части, называемые триплетами, по некоторым правилам, учитывающим семантику (смысл) этих частей.

Основа метода в разбиении знаний на части и составлении того, что принято называть помеченным направленным графом.

Каждая дуга такого графа представляет собой некоторый факт, отношение между двумя сущностями. На уже упоминавшемся рисунке дуга с меткой starred_in (в ролях), соединяющая узлы vincent_donofrio и the_thirteenth_floor представляет собой утверждение о том, что Винсент Д'Онофрио (Vincent D'Onofrio) снимался (в ролях) в фильме "Тринадцатый этаж" ("The Thirteenth Floor"). Факт (или утверждение), представленный таким способом, состоит из трёх частей: субъект, предикат (аналогичен глаголу в естественных языках) и объект. Субъект представляется узлом, из которого исходит дуга. Значение предиката определяется типом дуги (обозначается с помощью метки дуги). Объект — это узел, к которому направлена дуга.

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

Абстрактная модель RDF: высказывания

RDF — это не что иное, как универсальный метод разбиения информации на части. В этом определении подчёркивается тот факт, что один и тот же метод может быть использован для любого типа информации. А метод состоит в следующем: представить информацию как список утверждений вида СУБЪЕКТ ПРЕДИКАТ ОБЪЕКТ. Субъект и объект указывают на две сущности в реальном мире, а предикат определяет отношение между ними. Вы можете представлять себе предикаты как глаголы.

Вот как я представил бы информацию о моей квартире в виде RDF-высказываний:

СУБЪЕКТ ПРЕДИКАТ ОБЪЕКТ
Я владею моей_квартирой
моя_квартира содержит мой_компьютер
моя_квартира содержит мою_кровать
моя_квартира находится_в Филадельфии

Эти четыре строки выражают четыре факта. Каждая строка называется "высказывание" или "триплет".

В качестве субъектов, предикатов и объектов в RDF выступают имена для сущностей: для конкретных сущностей (например, "моя_квартира"), или для абстрактных (например, "содержит"). Эти имена не имеют внутренней структуры, и сами по себе не имеют смысла. Они используются как имена собственные или как переменные. Не важно какое именно имя вы выберете для той или иной сущности, главное везде использовать его согласованно.

Имена в утверждениях RDF обозначают сущности реального мира, тем самым позволяя на них ссылаться. То, что обозначают эти имена, может называться ресурсами (из-за применения RDF для описания метаданных веб-ресурсов), узлами (как в теории графов), или сущностями. Все эти термины являются синонимами. Например, имя "моя_квартира" обозначает мою настоящую квартиру, которая является сущностью в реальном мире. Есть небольшое, но важное различие между именами и сущностями, которые они обозначают. Например, два разных имени могут быть использованы в качестве ссылок на одну и ту же сущность.

Любой предикат — это отношение между двумя сущностями. "Владею" — это отношение между владельцем и предметом владения. "Содержит" — отношение между контейнером и тем, что контейнер содержит. "Находится_в" — обратное отношение, между тем, что содержится в контейнере, и контейнером. Порядок расположения субъекта и объекта в RDF очень важен.

Следующий аспект RDF почти очевиден, но я хочу отметить его: если кто-то ссылается на что-то как на X в одном месте, и при этом X используется в другом месте, то оба X обозначают одну и ту же сущность. Если я написал "моя_квартира" в первой строке, то используя это обозначение в последующих трех строчках, я подразумеваю всё ту же самую квартиру.

Правила, которые описаны выше, уже позволяют намного больше, чем вы можете себе представить. Взяв эту таблицу утверждений, я могу написать простую программу, которая сможет отвечать, например, на такие вопросы как: "кто владеет моей_квартирой?" или "что содержит моя_квартира?". Каждый такой вопрос соответствует форме RDF-утверждения, за исключением того, что вопросительные слова (такие как "кто" и "что") должны интерпретироваться программой в качестве символов-шаблонов. Простая программа, отвечающая на вопросы, может просто сравнивать вопрос с каждым из утверждений в таблице. Каждое совпадение является ответом. Вот псевдокод:

[[псевдокод: Псевдокод программы отвечающей на вопросы.]]

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

URI в качестве имён ресурсов

Информация в форме RDF предназначена для публикации в Интернете, поэтому использованные мной выше имена несут в себе проблему. Я не могу именовать что-либо "моя_квартира", потому что кто-нибудь другой также может использовать имя "моя_квартира" для своей квартиры. Следуя рассмотренному выше правилу RDF, RDF-инструменты интерпретировали бы обе сущности "моя_квартира" как ссылающиеся на один и тот же объект в реальном мире, тогда как на самом деле подразумеваются две различные квартиры. Последний аспект RDF заключается в том, что имена должны быть глобальными, для уверенности, что вы не выберите имя, которое кто-то другой может также использовать для обозначения чего-либо другого. Формально имена для субъектов, предикатов, и объектов должны являться единообразными идентификаторами ресурсов (Uniform Resource Identifier, сокращённо URI).

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

С одной стороны, предполагается, что URI непрозрачны. URI могут иметь такой же синтаксис или формат как и адреса веб-сайтов, поэтому вы увидете RDF-файлы, содержащие такие URI как http://www.w3.org/1999/02/22-rdf-syntax-ns#type в качестве глобального имени какой-нибудь сущности. Но тот факт, что они выглядят как веб-адреса, совершенно случаен. И не важно, существует на самом деле или нет сайт по этому адресу. Кроме начинающихся с "http:" существуют другие типы URI. URN — это тип URI, который используется для таких вещей, как идентификация книг по их номеру ISBN, например, urn:isbn:0143034650. TAG — это URI общего назначения. Они выглядят следующим образом: tag:govtrack.us,2005:congress/senators/frist. В этой статье будут использованы все три типа URI.

Вне зависимости от их формы, URI, которые вы видите в RDF-документах — это просто состоящие из слов названия для сущностей и ничего более.

Это был один взгляд на URI. С другой стороны, в последние годы (начиная с 2007) обычно ожидается, что если вы создаёте начинающийся на "http:" или другой разыменовываемый URI, то на самом деле размещаете что-либо по этому адресу, чтобы RDF-клиенты могли обратиться к странице и получить с неё некоторую информацию. То есть: то, что URI означает в документе не зависит от того, чем этот URI является. Но если вы используете URI, который можно разыменовать, то другие могут ожидать, что вы разместите что-то по указанному адресу в сети. Мы ещё вернёмся к этому в разделе о связанных данных.

URI используются как глобальные имена потому, что они позволяют разбить пространство всех возможных имён на элементы, имеющие явных владельцев. URI, начинающиеся с http://govtrack.us/ очевидно контролируются мной, или кем-либо, кто управляет сайтом по этому адресу. По традиции, если существует очевидный вледелец URI, никто кроме владельца не будет создавать новые ресурсы с этим URI. Это предотвращает конфликты имён. Если вы создаёте URI в пространстве имён, которое контролируете, то можете быть уверены, что больше никто не будет использовать тот же URI для обозначения чего-то другого. (Конечно, кто-нибудь может использовать ваши URI не так, как вы задумали, но это тема для другой статьи.)

Поскольку URI могут быть достаточно длинными, то в различных RDF-нотациях они обычно сокращаются посредством использования концепции пространств имён, как в XML. Как и в XML, пространства имён обычно задаются в начале RDF-документа и используются для сокращений в этом документе. К примеру, я задал сокращение "taubz" для URI http://razor.occams.info/index.html#. Во многих RDF-нотациях я теперь могу сократить такие URI как http://razor.occams.info/index.html#моя_квартира, заменяя URI пространства имён (точно в таком виде, как оно было задано) его сокращением и двоеточием, в результате чего получится taubz:моя_квартира. Точные правила для пространств имён зависят от используемого синтаксиса записи RDF.

Важно, что пространства имен не занимают никакого важного положения в RDF. Они просто являются инструментом для более короткой записи длинных URI.

Я могу переписать таблицу о моей квартире так, как показано ниже, заменив простые имена, которые я использовал ранее, на произвольные URI:

[[пример: RDF о "моей квартире".]]

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

[[рисунок: RDF в виде графа.]]

Подытожим вышесказанное

Вот и весь RDF. Все остальное в семантическом вебе построено на рассмотренных трёх правилах. Повторим их здесь, чтобы довести до сознания всю простоту системы:

1. Факт представляется в форме триплета (субъект, предикат, объект).
2. Субъекты, предикаты и объекты задаются именами конкретных или абстрактных сущностей реального мира.
3. В роли имён используются URI, являющиеся непрозрачными и глобальными.

Эти концепции формируют абстрактную модель данных RDF для кодирования знаний. Такая модель является аналогом типового API, который предоставляют большинство XML-библиотек. Если бы мы не были такими любопытными людьми и не совали бы все время свой нос в файлы, настоящий формат XML не имел бы для нас никакого значения до тех пор, пока у нас были бы наши методы appendChild, setAttribute, и т.д. Конечно, нам нужен общеупотребительный файловый формат для обмена данными, и фактически существует два таких формата для RDF, которые мы рассмотрим далее.

Анонимные узлы и литеральные значения.

На самом деле, конечно, RDF не исчерпывается тремя приведенными выше правилами. Ранее я описал три типа понятий в RDF: ресурсы (сущности или концепты), существующие в реальном мире; глобальные имена для ресурсов (то есть URI); и RDF-высказывания (триплеты или строки в таблице). Существуют еще два понятия.

Литералы

Первым рассмотрим понятие "литеральное значение". Литеральные значения представляют собой просто текст, который может быть использован вместо объектов в RDF-триплетах. В отличии от имен (то есть URI), которые заменяют собой сущности в реальном мире, литеральные значения — это просто текстовые данные вставленные в граф. Литеральные значения могут быть использованы для того, чтобы установить связь между людьми и их именами, книгами и их номерами ISBN, и т.д.

[[пример: Некоторые способы использования литеральных значений]]

Безымянные/анонимные узлы

Кроме того, существуют анонимные или безымянные узлы (blank nodes или bnodes). Эти термины являются синонимами. Слова "анонимный" или "безымянный" указывают на то, что эти узлы в графе не имеют собственного имени, в силу того, что автор документа не знает имя, не хочет или не может его предоставить. В определенном смысле, это подобно таким высказываниям как: "Джон дружит с кем-то, но я не скажу с кем". Когда мы говорим, что эти узлы не имеют имени, нужно иметь в виду две вещи. Во-первых, сущность реального мира, на которую ссылается данный узел, в свою очередь, не обязана быть безымянной. Друг Джона из нашего примера все-таки имеет имя. Во-вторых, когда мы говорим здесь "безымянный", мы подразумеваем концепцию именования сущностей с помощью URI. На самом деле, анонимные узлы в документе могут иметь "локальные" идентификаторы, так что на них можно ссылаться несколько раз внутри документа. Безымянность лишь означает, что эти локальные идентификаторы, очевидно, не являются глобальными, и не имеют смысла вне того документа, в котором они использованы.

Вот пример использования литеральных значений и анонимных узлов. "Джошуа Тоберер" ("Joshua Tauberer") в примере — это литеральное значение, а _:anon123 — это анонимный или безымянный узел.

[[пример: Анонимные узлы и литеральные значения.]]

Чтобы различать URI, имена, привязанные к пространствам имен (сокращенные URI), анонимные узлы и литеральные значения, я использую следующее общепринятое соглашение:

* Полные URI заключаются в угловые скобки.
* Имена, привязанные к пространствам имен, записываются непосредственно, но название пространства имен отделяется двоеточием.
* Анонимные узлы записываются так же, как и имена, привязанные к пространствам имен, но в качестве пространства имён используется зарезервированное значение "_", соответствующее локальное имя записывается после двоеточия.
* Литеральные значения заключаются в кавычки.

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

В этом примере один анонимный узел – _:anon123. Мы знаем об этом ресурсе, что он автор ресурса <urn:isbn:0143034650>, и то, что его имя Лоуренс Лессиг (Lawrence Lessig). Так как для этого ресурса не используется никакого глобального имени, мы не можем быть уверенными относительно того, о ком на самом деле мы здесь говорим. И если мы захотим сказать что-то еще о чём-либо, связанном с ресурсом _:anon123, мы должны будем сделать это здесь же, в этом RDF документе, потому что у нас нет возможности сослаться на этого самого Лоуренса Лессига за пределами нашего документа.

Подробнее о литералах: дескрипторы языков и типы данных

Литеральные значения могут дополняться одним из двух возможных элементов метаданных. Первый – это дескриптор языка, который указывает, на каком языке представлено текстовое значение литерала. Дескриптор языка нужно рассматривать как рудимент, оставшийся с тех пор, когда RDF только начал использоваться. Сегодня он выглядит как уродливая поделка. Вы можете встретить "chat"@en – литеральное значение "chat" с английским дескриптором языка, или "chat"@fr – то же самое значение с французским дескриптором языка.

Кроме того, литеральные значения могут быть помечены с помощью URI, идентифицирующего тип данных. Тип данных указывает, как интерпретировать текст литерала: как число, URI, дату или время, и т.д. Типом данных может быть любой URI, но обычно для этого используются типы данных, определенные в XML Schema. Для обозначения типа данных обычно используется запись следующего вида: после литерального значения в кавычках следуют два символа "крышка" ("^") и URI, определяющий тип данных (может быть указан в сокращённой форме).

[[пример: Типы данных.]]

Понятие типа данных не такое простое, как может показаться на первый взгляд. Давайте рассмотрим тип данных для чисел с плавающей точкой. Сами числа с плавающей точкой (как абстрактное математическое понятие) отличаются от текста, который мы используем для их представления на бумаге. Например, текст "5.1" представляет число 5.1, которое также можно обозначить как "5.1000" и "5.10". Пример показывает, что существует множество текстовых представлений (так называемых лексических представлений) для одного и того же значения. Тип данных говорит нам как преобразовывать лексическое представление в значение и наоборот.

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

[[пример: Семантика литералов.]]

Иначе говоря, нетипизированный литерал с дескриптором языка или без него — это не то же самое, что типизированный литерал. Второй момент, касающийся семантики литералов, заключается в том, что два типизированных литерала, которые выглядят различными, могут быть равны друг другу, если их типы данных отображают их лексическое представление в одно и то же значение. Следующие два утверждения эквивалентны (по крайней мере для RDF приложений, поддерживающих семантику типов данных XSD):

[[пример: Семантика типов данных.]]

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

Подробнее об анонимных узлах: некоторые предостережения

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

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

Анонимные узлы часто используют для того, чтобы избежать указания URI людей, как продемонстрировано в примере выше. Они также часто используются для представления более сложных отношений:

[[пример: Анонимные узлы для сложных отношений.]]

В этом примере анонимный узел использован в качестве промежуточного шага при описании отношения между мной и частями моего имени. Узел позволяет представить моё имя в структурированном виде, что более точно, чем одно непрозрачное литеральное значение "Joshua Ian Tauberer". RDF допускает только бинарные отношения, поэтому для выражения множественных отношений необходимо использовать промежуточные узлы, в качестве которых часто применяют анонимные.

Чтение и запись RDF

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

Нотация 3

Нотация 3 ("N3") или подмножество, называемое Turtle, фактически является стандартом записи RDF. Этот синтаксис не является стандартом W3C, но широко распространён, обычно используется при обсуждениях в списках рассылки разработчиков семантического веба. Этот синтаксис важен для понимания, поскольку наиболее понятным образом охватывает абстрактный граф.

Вот пример документа, позволяющий легко понять, какие триплеты закодированы.

[[пример: Пример нотации 3.]]

В табличной форме (обычно называемой NTriples) это представляется так:

[[пример: Табличная форма или NTriples.]]

В этом примере представлены утверждения о географических координатах (широте и долготе) Принстонского университета. А также о том, что в университете есть факультет, который называется "Факультет информатики".