К базовому профилю - за представлением Linked Data

W3C определяет широкий спектр стандартов Semantic Web и Linked Data, подходящих для многих применений. Используя Linked Data в качестве технологии интеграции приложений в области управления жизненным циклом приложений (Application Lifecycle Management - ALM), IBM обнаружила, что часто существует несколько возможных способов применения стандартов, однако мало сказано о том, как их объединить. В этой статье содержится общая информация, поясняющая, для чего это нужно, и предлагается проект базового профиля Linked Data.

Для чего это нужно

Существует заинтересованность в использовании технологий Linked Data для самых разных целей. Например, для представления в машиночитаемой форме в Интернете такой информации, как государственные архивы. Или для получения новой информации из уже имеющейся в фармацевтических приложениях или в системе IBM Watson (см. ссылки в разделе Ресурсы). Группа IBM Rational использует Linked Data в качестве архитектурной модели и технологии реализации интеграции приложений.

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

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

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

Хотя мы довольны - и даже очень - полученными результатами использования Linked Data в качестве технологии интеграции, успешное внедрение этого подхода оказалось непростым делом. Для достижения того уровня понимания технологии, какой мы имеем сегодня, понадобилось несколько лет экспериментов. Мы совершили некоторые дорогостоящие ошибки и пока не видим близкого конца проблемам и поискам.

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

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

Ресурсы

Краткое описание стандартных методов HTTP и RDF, а также практические рекомендации по их применению и предостережения, которые нужно учитывать при создании клиентов и серверов, умеющих читать и создавать Linked Data.
 

Контейнеры

Определяют ресурсы, позволяющие с помощью запросов HTTP POST и существующих ресурсов создавать новые ресурсы, которые можно найти с помощью запросов HTTP GET.
 

Разбиение на страницы

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

Проверка

Определяет простой механизм для описания свойств, которыми может или должен обладать определенный тип ресурсов.
 

В следующих разделах приводятся детали этого проекта базового профиля Linked Data.

Смежные работы

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

W3C Linked Enterprise Data Patterns Workshop
Этот проект имеет целью разработать то, что считается недостающим или необходимым и обсуждается в меморандуме IBM, представленном на семинаре.

Open Services for Lifecycle Collaboration (OSLC)
Спецификация OSLC Core v2 определяет некоторые из этих рекомендаций и антирекомендаций, хотя, возможно, и не идеальным образом. Это предложение может служить основой для более простого и стандартизованного пути к будущим спецификациям OSLC.

Терминология

Следующие определения основаны на архитектуре W3C World Wide Web и Hyper-text Transfer Protocol, HTTP/1.1 (см. раздел Ресурсы).

Ссылка (Link)

Отношение между двумя ресурсами, когда один ресурс (представление) ссылается на другой ресурс посредством URI. (См.: WWWArch)
 

Linked Data

Тимоти Бернерс-Ли дал определение в виде четырех следующих правил.

1. Использовать синтаксис URI для именования вещей и понятий.
2. Использовать URI HTTP, чтобы эти имена можно было искать.
3. Предоставить полезную информацию для поиска URI, используя стандарты (RDF*, SPARQL).
4. Включать ссылки на другие URI, чтобы можно было находить другие вещи. (См. LinkedData).

 

Спецификация

Акт точного описания или определения чего-то или точного указания требований.
 

Базовый профиль (Basic Profile)

Спецификация, определяющая необходимые компоненты спецификации других спецификаций и содержащая пояснения и шаблоны.
 

Клиент

Программа, которая устанавливает соединения с целью передачи запросов (см. HTTP)
 

Клиент базового профиля

Клиент, который придерживается правил, определенных в базовом профиле
 

Сервер

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

Примечание. Любая программа может быть и клиентом, и сервером. Мы будем использовать эти термины только применительно к роли программы по отношению к данному соединению, а не к возможностям программы в целом. Аналогично, любой сервер может выступать в качестве исходного сервера, прокси-сервера, шлюза или туннеля, меняя поведение в зависимости от природы каждого запроса (см. HTTP).
 

Сервер базового профиля

Сервер, который придерживается правил, определенных в базовом профиле
 

Ресурсы базового профиля

Ресурсы базового профиля ― это HTTP-ресурсы Linked Data, которые соответствуют простым моделям и соглашениям. Большинство ресурсов базового профиля - это специальные ресурсы, содержащие данные по предмету, относящемуся к определенной области, которая, в свою очередь, может относиться к торговле, государственному управлению, науке, религии и т.п. В спецификации базового профиля определены несколько межотраслевых ресурсов базового профиля. Все ресурсы базового профиля следуют правилам Linked Data, приведенным выше в разделе "Терминология":

1. Использовать синтаксис URI для именования вещей.
2. Использовать HTTP URI, чтобы эти вещи можно было искать.
3. Предоставить полезную информацию для поиска URI, используя стандарты (RDF*, SPARQL).
4. Включать ссылки на другие URI, чтобы можно было находить больше вещей.

Базовый профиль добавляет еще несколько правил. Некоторые из этих правил можно считать уточнением основных правил Linked Data.

1. Ресурсы базового профиля - это HTTP-ресурсы, которые можно создавать, изменять, удалять и считывать стандартными методами HTTP.
   (Уточнение или расширение правила 2 Linked Data). Ресурсы базового профиля создаются с помощью HTTP-запросов POST (или PUT) к существующему ресурсу, удаляются с помощью HTTP-запросов DELETE, редактируются с помощью HTTP-запросов PUT или PATCH и извлекаются с помощью HTTP-запросов GET. Кроме того ресурсы базового профиля можно создавать, обновлять и удалять с помощью SPARQL-запроса Update.
2. Для определения своего состояния ресурсы базового профиля используют выражение RDF.
   (Уточнение или расширение правила 3 Linked Data). Состояние ресурса базового профиля (в том смысле, в котором термин состояние используется в архитектуре REST) определяется набором троек RDF. Двоичные ресурсы и текстовые ресурсы не являются ресурсами базового профиля, так как их состояние нельзя легко или полно представить в виде выражения RDF. XML-ресурсы могут быть ресурсами базового профиля. Некоторые XML-ресурсы на самом деле представляют собой ресурсы, ориентированные на данные, в формате XML, которые легко представить в виде RDF. Другие XML-документы, по существу, представляют собой размеченные текстовые документы, которые нельзя легко представить в виде RDF. Ресурсы базового профиля можно смешивать с другими ресурсами в одном и том же приложении.
3. Для любого ресурса базового профиля можно запросить RDF/XML-представление.
   (Уточнение или расширение правила 3 Linked Data). Ресурс также может иметь и другие представления. Это могут быть другие форматы RDF, такие как Turtle, N3 или NTriples, но популярными дополнениями могут быть и не-RDF-форматы, такие как HTML и JSON; базовый профиль не налагает здесь никаких ограничений.
4. При обновлении клиенты базового профиля используют принцип оптимистического обнаружения конфликтов (Optimistic Collision Detection).
   (Уточнение или расширение правила 2 Linked Data). Так как в процессе обновления нужно сначала получить ресурс, а затем изменить его и возвратить на сервер, существует возможность конфликта (например, с момента начала действия запроса GET другой клиент мог обновить этот ресурс). Для смягчения этой проблемы в целях обнаружения конфликтов реализации базового профиля должны использоватьзаголовок HTTP If-Match и HTTP ETags.
5. Ресурсы базового профиля используют стандартные типы носителей.
   (Уточнение или расширение правила 3 Linked Data). Базовый профиль не требует и не поощряет определения каких-либо новых типов носителей. Цель базового профиля заключается в том, чтобы любой стандартизованный клиент RDF или Linked Data мог читать и записывать данные базового профиля, а определение новых типов носителей в большинстве случаев воспрепятствует этому.
6. Ресурсы базового профиля используют стандартные словари.
   Для общих понятий (классов, свойств и т.п) ресурсы базового профиля используют общие словари. Многие Web-сайты определяют свои собственные словари общих понятий, таких как тип ресурса, метка, описание, автор, время последнего изменения, приоритет, перечисление значений приоритета и т.п. Обычно это приветствуется пользователями, которым нужно, чтобы их данные соответствовали локальной терминологии и процессам, но это значительно затрудняет организациям последовательную интеграцию своей информации в более общую систему. Базовый профиль требует, чтобы все ресурсы выражали общие понятия с использованием единого словаря свойств. Сайты могут дополнительно предоставлять те же значения тех же ресурсов и под своими собственными частными именами. В целом базовый профиль по возможности избегает изобретения новых имен свойств. Вместо этого он использует имена из популярных RDF-стандартов, таких как сами стандарты RDF, Dublin Core и т. п. Базовый профиль вводит новые URL свойств тогда, когда их нет в популярных стандартных словарях. Примечание. Ниже перечислены некоторые из стандартных свойств, рекомендованных для использования в ресурсах базового профиля.
7. Ресурсы базового профиля явно задают rdf:type.
   Участие ресурса в class extent может быть неявно выведено или явно указано тройкой в представлении ресурса с использованием предиката rdf:type и URL класса. В RDF не требуется размещать тройку rdf:type в каждом ресурсе, но это хорошая практика, потому что она делает запрос более полезным в тех случаях, когда логический вывод не поддерживается. Напомним также, что один ресурс может иметь несколько значений rdf:type. Например, в статье dpbedia о Бараке Обаме десятки значений rdf:type. Базовый профиль не устанавливает никаких ограничений на количество допустимых типов ресурсов.
8. Ресурсы базового профиля используют ограниченное количество стандартных типов данных.
   RDF не определяет типы данных, которые будут использоваться для значений свойств, поэтому базовый профиль содержит набор стандартных типов данных для использования в базовом профиле.
   • Boolean: логический тип в соответствии с XSD Boolean http://www.w3.org/2001/XMLSchema#boolean, см. типы данных XSD.
   • DateTime: тип даты и времени в соответствии с XSD dateTime http://www.w3.org/2001/XMLSchema#dateTime, см. типы данных XSD.
   • Decimal: тип десятичного числа в соответствии с XSD Decimal http://www.w3.org/2001/XMLSchema#decimal, см. типы данных XSD.
   • Double: тип числа двойной точности с плавающей запятой в соответствии с XSD Double http://www.w3.org/2001/XMLSchema#double, см. типы данных XSD.
   • Float: тип числа с плавающей запятой в соответствии с XSD Float http://www.w3.org/2001/XMLSchema#float, см. типы данных XSD.
   • Integer: тип целого числа в соответствии с XSD Integer http://www.w3.org/2001/XMLSchema#integer, см. типы данных XSD.
   • String: строковый тип в соответствии с XSD String http://www.w3.org/2001/XMLSchema#string, см. типы данных XSD.
   • XMLLiteral: литеральное значение XML
     http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
9. Клиенты базового профиля могут встречать неизвестные свойства и содержание.
   Базовый профиль обеспечивает механизмы для поиска клиентами перечней ожидаемых свойств ресурсов, но также предполагается, что любой данный ресурс может иметь гораздо больше свойств. Некоторые серверы поддерживают только фиксированный набор свойств ресурсов определенного типа. Клиенты всегда должны предполагать, что набор свойств ресурса определенного типа на произвольном сервере может быть открытым в том смысле, что все ресурсы одного и того же типа могут иметь неодинаковые свойства, и набор свойств, которые используются в состоянии ресурса, не ограничен каким-либо заранее определенным набором. Однако при работе с ресурсами базового профиля клиенты должны предполагать, что имея предварительную информацию, сервер базового профиля может отбрасывать тройки свойств. Иными словами, серверы могут ограничить себя известным набором свойств, а клиенты - нет. При выполнении обновления с помощью HTTP-запроса PUT клиент базового профиля должен сохранить все значения свойств, полученных с помощью HTTP-запроса GET. Сюда относятся все значения свойств, которые он не изменяет или не понимает. (Использование для обновлений HTTP-запроса PATCH или SPARQL-запроса Update вместо HTTP-запроса PUT снимает с клиентов это бремя).
10. Клиенты базового профиля не делают предположений о типе ресурса на другом конце соединения.
    Многие спецификации и наиболее традиционные приложений имеют "закрытую модель", под которой мы понимаем условие, что любая ссылка из ресурса в спецификации или приложении обязательно указывает на ресурс в той же спецификации (или в указанной спецификации) или в том же приложении. В противоположность этому, тег HTML anchor может указывать не только на другие HTML ресурсы, но и на любой ресурс, адресуемый HTTP URI. В этом смысле базовый профиль работает подобно HTML. Ссылка HTTP URI в одном ресурсе базового профиля в общем случае может указывать на любой ресурс, а не только на ресурс базового профиля. Существует множество причин для сохранения HTML-подобной открытой модели. Одна из них заключается в том, что это позволяет в будущем включать в Web данные, которые пока не определены. Другая причина: это позволяет отдельным приложениям и сайтам развиваться с течением времени. Если клиенты предполагают, что они "знают", что их ждет на другом конце соединения, то при обновлении версии форматы данных всех ресурсов должны оставаться постоянными в рамках транзитивного замыкания всех связей.

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

11. Серверы базового профиля реализуют простую проверку процессов создания и обновления.
    Серверы базового профиля должны пытаться облегчить программным клиентам создание и обновление ресурсов. Если реализации базового профиля связывают множество весьма сложных правил проверки, которые должны соблюдаться при обновлении и создании, то клиенту становится трудно или невозможно использовать протокол без обширной дополнительной информации, специфичной для сервера, которую необходимо передать за пределы спецификаций базового профиля. Рекомендуемый подход состоит в том, что серверам разрешается создание и обновление на основе некоторого рода простых проверок, которые можно программно передавать посредством типа Shape (см. раздел об ограничениях). Дополнительные проверки, требуемые для реализации более сложных политик и ограничений, должны приводить к тому, что ресурсы помечаются как требующие большего внимания, но не должны вызывать отказ в выполнении базовых операций Create или Update.

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

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

Общие свойства

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

Таблица 1. Общеиспользуемые префиксы пространств имен

Из Dublin Core

Таблица 2

Из RDF

URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#

Таблица 3

Из RDF Schema

URI: http://www.w3.org/2000/01/rdf-schema#

Таблица 4

Контейнер базового профиля

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

1. По какому URL-адресу обращаться для создания новых ресурсов?
2. Где получить список имеющихся ресурсов?

В мире XML в качестве стандартных ответов на эти вопросы стал популярным протокол Atom Publishing Protocol (APP). APP плохо сочетается с Linked Data, потому что настоящий базовый профиль показывает, как те же проблемы, которые решаются APP для XML-ориентированных конструкций, можно решить с помощью простой модели Linked Data с простыми соглашениями по размещению в RDF-контейнерах. Те RDF-контейнеры, в которые можно поместить (POST) информацию, называются контейнерами базового профиля. Вот некоторые из их характеристик:

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

Представление контейнера базового профиля - это стандартное представление контейнера RDF с использованием предиката rdfs:member. Например, если существует контейнер с URL-адресом http://example.org/BasicProfile/container1, то он может быть представлен, как показано в листинге 1.

Листинг 1. Представление контейнера базового профиля

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
<http://example.org/BasicProfile/container1>
        a rdfs:Container;
        rdfs:member <http://acme.com/members/000000000>;
        # … 999999998 more triples here …
        rdfs:member <http://acme.com/members/999999999>.

Базовый профиль не признает и не рекомендует использовать другие формы контейнеров RDF, такие как Bag и Seq, так как они не облегчают запросы. Это соответствует стандартным рекомендациям по использованию RDF Linked Data.

Базовый профиль рекомендует использовать с контейнерами набор стандартных свойств Dublin Core. Субъектом троек, использующих эти свойства, является сам контейнер.

Таблица 5. Свойства домена rdfs:Container

Получение свойств невходящих элементов

Представление контейнера с множеством элементов будет громоздким. Проанализировав свои сценарии использования, мы заметили, что существует несколько важных случаев, когда клиенту требуется доступ только к свойствам, не относящимся к элементам контейнера. (Свойства dcterms, перечисленные на этой странице, могут показаться недостаточно важными, чтобы заниматься решением этой проблемы, но у нас были случаи, когда в контейнеры добавлялись другие предикаты, такие как сведения о проверке и связанные с ними конечные точки SPARQL). Так как получение всего представления контейнера для извлечения этой информации обременительно, мы решили найти способ извлечения только значений свойств, не относящихся к элементам контейнера. Для этого мы определили для каждого контейнера базового профиля соответствующий ресурс, называемый "non-member ресурсом", состояние которого представляет собой подмножество состояний контейнера. HTTP URI non-member ресурса можно получить следующим образом.

Если HTTP URI контейнера {url}, то HTTP URI соответствующего non-member ресурса будет {url}?non-member-свойства. Представление {url}?non-member-свойства идентично представлению {url}, за исключением того, что тройки членства отсутствуют. Субъектами троек по-прежнему будут {url} (или то, как они выглядели в представлении {url}), а не {url}?non-member-свойства. Любой сервер, не поддерживающий non-member-ресурсы, при обращении к non-member-ресурсу должен возвращать ошибку HTTP 404 File Not Found.

Этот подход аналогичен использованию HTTP HEAD рвместо HTTP GET. Разница в том, что HTTP HEAD используется для получения с помощью запроса HTTP GET заголовков ответов ресурса, а не всего представления ресурса. Пример приведен в листингах 2 и 3.

Листинг 2. Пример HTTP GET, запрос

GET /container1?non-member-properties HTTP/1.1
HOST: example.org 
Accept: text/turtle

Листинг 3. Пример HTTP GET, ответ

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dcterms: <http://purl.org/dc/terms/>. 
@prefix bp: <http://open-services.net/ns/basicProfile#>.
<http://example.org/container1>
        a rdfs:Container;
        dcterms:title "An Basic Profile Container of Acme Resources";
        bp:containerPredicate rdfs:member;
        dcterms:publisher <http://acme.com/>.

Мотивация и предпосылки проектирования

Концепция non-member-ресурсов не вызвала особых возражений, чего нельзя сказать об использовании шаблона URL {url}?non-member-свойства для их идентификации. Некоторые считают это неприемлемым вмешательством в пространство URL, которое принадлежит серверу, определяющему {url}, и контролируется им. Более существенное возражение заключается в том, что серверы непредсказуемо отвечают на непонятные для них URL, особенно со знаком "?". Например, некоторые серверы возвращают ресурс, указанный той частью URL, который предшествует знаку "?", и просто игнорируют все остальное.

Возможно, эту проблему можно смягчить использованием в шаблоне URL знака, отличного от знака "?". Альтернативная конструкция, которая тоже обсуждалась, использует поле заголовка в заголовке ответа {url}, чтобы сервер мог контролировать и устанавливать связь с URL соответствующего non-member-ресурса. Наличие или отсутствие поля заголовка позволит клиентам знать, поддерживается ли этот non-member-ресурс сервером.

• Преимуществом такого подхода является то, что он не ущемляет пространство URL сервера, и серверы, не понимающие концепции non-member-ресурса, будут реагировать предсказуемым образом.
• Однако для извлечения non-member-ресурсов требуется два обращения к серверу, HEAD и GET, и должен быть определен специальный HTTP-заголовок, что некоторым кажется обременительным.

Дополнительные соображения

Контейнеры базового профиля должны обеспечивать инструкции в следующих ситуациях:

• при изменении dcterms:modified или Etag, или того и другого, когда членство в контейнере меняется, чтобы позволить эффективное кэширование контейнеров;
• при наличии ограничений членства (как правило, ресурс будет только частью одного контейнера, хотя могут существовать исключения).

Проверка и ограничения базового профиля

Ресурсы базового профиля - это ресурсы RDF, а у RDF есть хорошее свойство: "он может говорить все обо всем". В принципе это означает, что, любой ресурс может иметь любое свойство, и не требуется, чтобы любые два ресурса имели одинаковый набор свойств, даже если это ресурсы одного и того же типа или типов. Тем не менее, на практике свойства, которые устанавливаются для ресурсов, обычно следуют регулярным моделям, зависящим от назначения этих ресурсов. Хотя конкретный ресурс может иметь произвольные свойства, с точки зрения конкретного приложения или примера использования набор свойств и значений свойств, подходящий для этого ресурса в этом приложении, часто будет предсказуемым и ограниченным. Например, если на сервере есть ресурсы, которые представляют программные продукты и сведения об ошибках в них, то для целей отображения информации в табличном формате, создания и обновления ресурсов или для других целей клиенту может потребоваться знание свойств программных продуктов и сведений об ошибках на этом сервере. Спецификация Basic Profile Validation and Constraints направлена на получение информации о таких свойствах и ограничениях.

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

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

Замечание о взаимосвязи Shape с другими стандартами.
Хотя по реляционным базам данных и объектно-ориентированному программированию мы все очень хорошо знакомы с моделью, в которой допустимые свойства ограничены типом, для RDF эта модель не является "естественной", как и для реального мира. Знакомая модель говорит, что если вы принадлежите к типу X, то будете иметь те свойства, для которых характерны значения определенных типов. Для RDF и в значительной степени для реального мира справедливо обратное; если у вас такие-то свойства, то вас следует относить к типу X. Нам не известно ни о каких конструкциях OWL или RDFS, которые позволяли бы сказать: "С точки зрения приложения X ресурсы, имеющие тип RDF Y, будут иметь набор свойств Z" или ограничить типы значений для этих свойств.

Класс: PropertyConstraint

URI: http://open-services.net/ns/basicProfile#PropertyConstraint

Свойства домена bp:propertyconstraint

Таблица 6

Спорный вопрос: нужен ли отдельный класс bp:PropertyConstraint со свойством bp:constrainedProperty, или лучше использовать rdfs:Property и просто определить новые предикаты с rdfs:Property как домен.

Однако важно не использовать rdfs:range ввиду другой семантики.

Класс: bp:AllowedValues

URI: http://open-services.net/ns/basicProfile#AllowedValues

Свойства домена bp:AllowedValues

Таблица 7

Класс: bp:Shape

URI: http://open-services.net/ns/basicProfile#Shape

Таблица 8. Свойства домена bp:Shape

Семантика проверки

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

Связывание форм и контейнеров

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

Таблица 9. Свойства домена rdfs:Container

Разбиение на страницы в базовом профиле

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

Для решения этой проблемы ресурсы базового профиля могут поддерживать метод paging, позволяющий клиентам получать представления ресурсов постранично. Для каждого ресурса с адресом {url} реализация базового профиля может определить сопутствующий ресурс с адресом {url}?firstPage. Смысл этого ресурса: первая страница {url}. Клиенты, которые ожидают, что определенный ресурс будет слишком большим, могут вместо него запросить этот альтернативный ресурс. Серверы, которые определили, что запрошенный ресурс слишком велик, могут ответить сообщением переадресации 302, направив клиента к ресурсу firstPage.

Представление {url}?firstPage будет содержать подмножество троек, определяющих состояние ресурса с адресом {url}. Тройки остаются неизмененными, так что субъект троек будет тем, каким он был в представлении {url}, как правило, {url}, а не {url}?firstPage. Кроме того, представление {url}?firstPage будет включать в себя несколько троек с субъектом {url}?firstPage. Примерами могут служить тройки с предикатами, bp:nextPage, dcterms:description и т.д.

Так, если имеется контейнер базового профиля с адресом http://acme.com/BasicProfile/container/1, то может возникнуть следующее представление (в нотации Turtle):

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. 
http://acme.com/BasicProfile/container/1
        rdfs:member <http://acme.com/BasicProfile/resource/000000000>; 
        # ... 999999998 more triples here … 
        rdfs:member <http://acme.com/BasicProfile/resource/999999999>.

Это представление содержит миллиард троек и свыше 90 млрд символов, то есть довольно велико. В предположении, что реализация этого ресурса поддерживает разбиение на страницы, клиент может обратиться к сопутствующему ресурсу: http://acme.com/BasicProfile/container/1?firstPage. Представление этого последнего ресурса будет выглядеть следующим образом:

 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
  @prefix bp: <http://open-services.net/ns/basicProfile#>.
 <http://acme.com/BasicProfile/container/1> 
        rdfs:member <http://acme.com/BasicProfile/resource/000000000>; 
        # ... 98 more triples here … 
        rdfs:member <http://acme.com/BasicProfile/resource/000000099>.

# pay attention to the subject URL of the following triple
<http://acme.com/container/1?firstPage> bp:nextPage
<http://acme.com/xxxxxxxxx/page2>.

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

Как показано выше, когда возвращается страница, она содержит тройку:
<url текущей страницы> bp:nextPage <url следующей страницы>

Когда <url следующей страницы> равен bp:nilPage, можно заключить, что вы находитесь на последней странице.

К тому времени, когда клиент отправляется по ссылке bp:nextPage, следующей страницы уже может не быть. В этом случае реализация сервера базового профиля должна ответить пустой страницей, где bp:nextPage равен bp:nilPage.

Базовый профиль допускает использование {url}?pageSize={n} в качестве псевдонима {url}?firstPage. Это просто псевдоним, и его значение и поведение ничем не отличается. Реализация сервера базового профиля может (но не обязана) регулировать количество троек на первой и последующих страницах, основываясь на значении n .

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

Нестабильность разбиения на страницы

Так как HTTP представляет собой протокол без запоминания состояния, а серверы базового профиля управляют ресурсами, которые могут часто меняться, клиенты базового профиля должны предполагать, что ресурсы могут измениться, пока они просматривают их страницы с помощью механизма bp:nextPage. Тем не менее, каждая тройка ресурса, существовавшая на момент передачи первой страницы и не удаленная во время передачи страниц, должна содержаться, как минимум, на одной странице. (Включение той же тройки более одного раза допустимо - в RDF идентичные тройки всегда отбрасываются, - но серверы должны гарантировать, что одна и та же тройка не будет возвращена несколько раз с разными значениями объекта). Тройки, добавленные после передачи первой страницы, сервер может включать или не включать в последующие страницы.

Класс bp:Page

URI: http://open-services.net/ns/basicProfile#Page

Таблица 10. Свойства bp:Page

Заключение

Мы надеемся, что простой базовый профиль будет способствовать широкому внедрению принципов Linked Data для интеграции приложений. Для завершения такого профиля потребуется дополнительная разработка некоторых концепций. Цель этой статьи - инициировать столь необходимую разработку спецификаций, которые восполнили бы этот пробел.