TeaCODE.com. Заметки

Концепты

Заметки

МЕТА

Главная > Концепция > Заметки > Дублинское ядро

• Структура DC
• Контролируемые словари
• Базовые элементы DC
• Расширения простой модели DC
• Уточнение элементов
• Схемы кодирования
• Базовый словарь
• Основные принципы построения DC
• Привязка DC к синтаксическим схемам

А.В. Манцивода.
Система метаописаний Dublin Core

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

Дублинское ядро – Dublin Core (DC) – является, пожалуй, самым грамотным и успешным проектом, связанным с разработкой структуры метаописаний ресурсов. Инициативной группой (Dublin Core Metadata Initiative, DCMI) был принят ряд точных концептуальных решений, позволивший найти приемлемый компромисс между выразительностью и простотой, естественностью и полнотой метаописаний. Поскольку проект DublinCore построен весьма элегантно и, в то же время, эффективно, он достоин подробного рассмотрения в качестве эталлоной на сегодняшний день системы метаописаний ресурсов. В данном пункте мы не только рассматриваем DC, но на примере этого успешного проекта изложим основные принципы и правила построения систем метаописаний.
   Инициативная группа по разработке DC была создана в 1995 году в ответ на очевидную необходимость появления эффективных механизмов поиска в Интернете. С самого начала она включает специалистов из разных областей – библиографов, архивистов, представителей гуманитарных школ, специалистов в области стандартизации, и информационных технологий. Первые встречи рабочей группы привели к разработке пятнадцатиэлементного Дублинского ядра, которое с тех пор остается относительно неизменным. Эта основа включает частично элементы, которые имеют одинаковые значения в совершенно разных предметных областях, например, относящиеся к созданию, именованию и определению предметной области ресурсов. В то же время другие, вероятно, выходят за рамки общепринятых, в частности, темпоральные (временные) и пространственные характеристики (элемент Coverage), а также элементы, ответственные за описание прав интеллектуальной собственности.
   Первоначальной целью DC-описаний были простые документы, разработанные в HTML. Такие документы обобщенно характеризуются не очень благозвучным по-русски понятием, как «документоподобные объекты» (document-like objects, DLO). Существенным качеством DLO является простота их структуры и жизненного цикла. В частности, концепция DLO не включает в себя ни подчастей (например, глав, параграфов и т.д.), ни сложных взаимосвязей с другими объектами – реальными или виртуальными. Конечно, имидж автономных, отдельных объектов, описанных одномерными каталожными записями, больше подходит к обычным книгам, стоящим на библиотечных полках. Для таких ресурсов как, например, базы данных, такой механизм представляется не совсем подходящим. С другой стороны, концепция DLO весьма полезна как простая метафора для характеризации разнообразных веб-ресурсов, которые формируют основу для междисциплинарного поиска и обмена информацией.
   Том Бейкер для характеристики простых описательных утверждений Дублинского ядра использовал такое понятие как «пиджин» (pidgin). Пиджин – особого рода язык, предназначенный для удовлетворения потребностей в межэтническом общении. Пиджин не является родным ни для кого из говорящих на нем (его название происходит из искаженного на китайский манер английского слова «бизнес»). Такой язык появляется, когда, например, представители разных этносов становятся беженцами, и попадают в один лагерь. Представители таких сообществ очень быстро развивают простой декларативный язык, обеспечивающий базовое общение между этническими группами. Пиджином можно назвать и язык разговорников – наборов основных фраз, предназначенных для туристов, когда они посещают чужую страну. Основными свойствами таких языков являются

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

Представляется, что это наиболее точная характеристика набора базовых элементов Дублинского ядра. Дублинское ядро можно понимать как компактный язык для разработки утверждений определенных типов, описывающих ресурсы. В этом языке имеется два класса терминов – элементы («существительные») и квалификаторы («прилагательные»). Существительные и прилагательные в этом языке формируют простые предложения, предметом описания которых являются ресурсы. В многообразном мире Интернета DC является «простейшим всеобщим языком для виртуальных туристов», на котором могут общаться почти все. И пусть он не всегда обеспечивает глубокое описание сложных концептов, зато его легко понять.

Структура DC

Структурно Дублинское ядро состоит из двух уровней

• Simple Dublin Core – простой уровень, который еще называется неквалифицированным;
• Qualified Dublin Core – квалифицированный уровень.

Простой уровень состоит из 15 базовых элементов, квалифицированный уровень содержит еще один элемент – Audience, а также группу квалификаторов (атрибутов) базовых элементов, позволяющих уточнять информацию из базовых элементов метаописаний.
Каждый элемент DC является опциональным (необязательным) и может повторяться в метаописании сколько угодно раз. Кроме того, порядок элементов в метаописании также никак не регулируется. Порядок, в котором несколько экземпляров одного и того же элемента (например, Creator – создатель) входят в метаопиание, может иметь значение в некоторых системах, но не гарантируется, что этот порядок будет сохраняться в других реализациях. Упорядочение зависит от синтаксиса, в котором реализуется Дублинское ядро. Например, в синтаксисе RDF/XML порядок поддерживается, а в HTML нет.

Контролируемые словари

Важная роль словарей в информационных системах уже обсуждалась нами выше. При наличии словаря значения для соответствующего поля метаописаний выбираются из строго фиксированного множества слов, ограниченного набором тщательно подобранных терминов. Это может очень серьезно улучшить возможности автоматической обработки метаописаний, а также повысить качество результатов поиска, поскольку компьютеры хороши в побуквенном сравнении слов, но чувствуют себя намного хуже, когда описание термина сделано в «человеческом» стиле, с синонимами, контекстом и т.д. Без терминологического контроля несовместные и некорректные метаданные способны самым плохим образом сказаться на качестве результатов поиска информации.
Приведем несколько примеров контролируемых словарей. Стандарт ISO639 кодирует имена естественных языков. Версия ISO639-1 обеспечивает двухбуквенные обозначения языков, а ISO639-2 трехбуквенные. В таблице приведены некоторые коды, являющиеся элементами соответствующего контролируемого словаря:

коды 639-1	коды 639-2	язык
en	eng	английский
fr	fre	французский
-	rap	рапандуйский
ru	rus	русский

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

Код	Определение
51	Математика
517	Анализ
517.1	Введение в анализ
517.5	Теория функций, включая метрическую теорию, комплексные переменные и специальные функции.
61:355	Медицина в вооруженных силах

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

   Элементы больших словарей, как правило, образуют сложные иерархические системы – таксономии. Если моделируемая предметная область имеет сложную организацию и большое количество разнообразных объектов, то количество элементов в словаре также достаточно большое. Например, УДК имеет более ста двадцати тысяч элементарных кодов. С учетом богатых возможностей УДК по образованию сочетаний общее количество вариантов приближается к бесконечности. По сути, это группирование объектов предметной области в классы с определением отношения наследования. При разработке метаданных регулярная иерархическая структура в значительной степени облегчает выбор нужного элемента описания. Таксономии также являются одной из основ для построения «интеллектуальных» сервисов обработки метаданных.
   Но эти качества уже выходят за рамки понятия «словарь». Они будут рассмотрены нами в последующих пунктах этой главы. Здесь можно провести аналогию с энциклопедиями, которые формируют совокупность терминов в алфавитном порядке. Понятно, что объясняемые в энциклопедии термины имеют сложные взаимосвязи, соответствуют разным классам объектов и т.д., но явно это никак не влияет на структуру энциклопедии, которая представляет собой словарь с упорядоченными в алфавитном порядке терминами.
   Ценой использования таких контролируемых словарей является необходимость существования некоторой административной группы, которая поддерживает существование, строгость и развитие того или иного словаря. Например, библиотека конгресса США поддерживает словарь LCSH (US Library of Congress Subject Headings). Консорциум UDC поддерживает УДК. Кроме того, нетривиальной задачей является продвижение словаря в сообщество, обучение словарю людей, занятых работой с метаданными. Сегодня ситуация не очень хорошая. Например, из десяти изданных в России книг, взятых нами наугад, только две имели корректные коды УДК. У остальных книг коды либо не соответствовали тематике, либо были устаревшими. Это довольно серьезная проблема, поскольку вряд ли можно построить поисковую систему на некорректных данных.
   Системы поиска и обработки метаданных должны отличать ситуации, когда в метаданных используется не обычное ключевое слово, а термин из словаря. Для этого служат специальные квалификаторы, которые явно указывают на используемый в данном метаописании словарь.

Базовые элементы DC

Ниже представлены базовые элементы DC с описаниями и рекомендациями для разработчиков метаданных (с использованием материалов из ряда источников). Базовые элементы DC на сегодняшний день являются основой для многих систем метаописаний, и в первую очередь, образовательных. В частности, на Дублинское ядро опирается система метаописаний IMS/LOЬ. Кроме того, на примере базовых элементов можно продемонстрировать ряд важных тонкостей и полезных деталей, связанных с созданием метаописаний ресурсов. Поэтому мы уделим внимание каждому базовому элементу Дублинского ядра, дав стандартное описание элемента, рекомендации для разработчиков метаданных, а также наиболее характерные примеры использования элементов. В примерах элементы будут представляться в виде пар

атрибут = значение

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

Title (название, имя ресурса)

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

Примеры:
title = "Курс математического анализа"
title = "Учебник полифонии"
title = "Коммерсантъ"

Creator (создатель ресурса)

Название	Описание	Рекомендации разработчикам
Creator	Сущность (персона, организация, сервис и т.д.), непосредственно ответственная за создание содержимого ресурса.	Создатели должны перечисляться в отдельных экземплярах элемента Creator, желательно в той последовательности, как они появляются в публикации/ресурсе. Рекомендуется сначала указывать фамилию человека, а затем имя и, возможно, отчество. Когда неясно, где имя, а где фамилия, используйте тот порядок, который имеется в публикации. В случае, когда создателем является организация, и когда ясна иерархия организация-подразделение, разделяйте названия подразделений точкой и пробелом. Когда эта информация неочевидна, используйте последовательность, которая появляется в публикации. Если создатель и публикатор (Publisher) – одно и то же лицо, то не повторяйте его имя в элементе Publisher. Если тип ответственности неочевиден, рекомендуется использовать поле Creator для индивидуумов и поле Publisher для организаций. В случае сомнительности роли данного лица, организации или сервиса, используйте элемент Contributor.

Примеры:
Creator = "Shakespeare, William"
Creator = "Манцивода Андрей Валерьевич"
Creator = "ЦРУ"

Subject (предметная область ресурса)

Название	Описание	Рекомендации разработчикам
Subject	Область знания (тема), которой посвящено содержимое ресурса. Как правило, этот элемент содержит ключевые слова, ключевые фразы, или классификационные коды, описывающие тему ресурса. Практика показывает, что значение этого элемента лучше выбирать из контролируемого словаря.	Выбирайте ключевые слова из имени ресурса или его описания (Description). Если предметом ресурса являются персоны, следует использовать формат имени, как это рекомендовано для элемента Creator. Используйте максимально значимые и уникальные слова. Subject может включать элементы классификации, например, УДК. Если используются значения из разных словарей, то каждое значение должно быть оформлено в виде отдельного экземпляра Subject,

Примеры:
Subject = "открытое образование"
Subject = "УДК 517.1"
Subject = "Маркс Карл"

Description (Текстовое описание содержимого ресурса)

Название	Описание	Рекомендации разработчикам
Description	Текстовое описание содержимого ресурса. Описание может включать: аннотацию, оглавление и иные блоки.	Практика показывает, что в этот элемент лучше включать полные предложения, ориентированные на чтение человеком – как правило, это поле используется пользователями для оценки содержимого ресурса. Не рекомендуется включать в этот элемент размеченные тексты, например, HTML-страницы, поскольку нет гарантии, что разметка будет правильно интерпретироваться автоматическими обработчиками.

Примеры:
Description = "Эта книга посвящена использованию современных информационных технологий для развития распределенных систем открытого и дистанционного образования"

Publisher (публикатор)

Название	Описание	Рекомендации разработчикам
Publisher	Сущность (человек, организация или сервис), ответственная за обеспечение доступности описываемого ресурса.	Цель данного поля – дать описание лица, обеспечивающего доступ к ресурсу.

Пример:
Publisher="Российский государственный институт открытого образования”
Publisher="Издательство Детгиз"

Contributor (участник создания ресурса)

Название	Описание	Рекомендации разработчикам
Contributor	Сущность (человек, организация или сервис), сделавшая вклад в создание содержимого данного ресурса.	Используйте те же правила использования имен, как и для элемента Creator. Contributor – наиболее общее описание для лица, имеющего отношение к созданию и жизни ресурса. Используйте этот элемент в тех случаях, когда использование элементов Creator и Publisher не соответствует ситуации, либо неочевидно.

Примеры:
Contributor = "Ресторан Славянский Базар"

Date (Дата)

Название	Описание	Рекомендации разработчикам
Date	Дата, связанная с событием в жизненном цикле ресурса. Как правило, даты определяют моменты создания, изменений, обеспечения доступности ресурса. При записи дат рекомендуется использовать формат стандарта ISO 8601 [ISO8601], определяющего дату в виде YYYY-MM-DD.	Если точные данные неизвестны, дата может представляться в форматах YYYY-MM или даже YYYY. Можно употреблять и другие форматы, но при этом не гарантируется, что сервисы смогут воспользоваться этой информацией при решении своих задач.

Пример:
Date="1998-02-16"
Date="1998-02"
Date="1998"

Type (тип ресурса)

Название

Описание

Рекомендации разработчикам

Type

Природа или жанр содержимого ресурса. Type включает термины, описывающие общие категории, функции, жанры, уровни агрегации содержимого. Рекомендуется использовать в качестве значений элементы некоторого контролируемого словаря (например, [DCT]).

Если ресурс составлен из нескольких смешанных типов, главные из них должны быть представлены, причем каждый в отдельном экземпляре элемента Type. Поскольку в разных предметных областях могут использоваться разные контроллируемые словари, из соображений интероперабельности в дополнение к специализированным словарям рекомендуется включать в метаописание хотя бы один экземпляр элемента Type, чьи значения берутся из DCMI Type Vocabulary [DCT]. Несколько последовательных экземпляров элемента Type – удобный инструмент, чтобы дать всестороннее описание объекта.

Примеры: Последовательность, определяющая «Каталог выставки электронного искусства»:
Type="Image"
Type="Text"
Type="Каталог выставки"
Первые два значения принадлежат словарю DCMI Type Vocabulary. Третье не специфицировано.

Понятие «Интерактивная мультимедийная образовательная программа»:
Type="Image"
Type="Text"
Type="Software"
Type="Interactive Resource"
Все значения взяты из словаря DCMI Type Vocabulary.

Format (физическое или цифровое представление ресурса)

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

Примеры:

Title="Dublin Core icon"
Type="Image"
Format="image/gif"
Format="4 kB"

Title="Мона Лиза в бигуди"
Type="Image"
Format="image/jpeg"
Format="210 x 320 pixels"
Date = “1994”

Title="Синий гребень"
Creator="Кандинский Василий"
Type="живопись"
Format="масло"
Format=”картон”
Format="104 x 133 cm"

Identifier (идентификатор ресурса)

Название	Описание	Рекомендации разработчикам
Identifier	Уникальный, точно выраженный идентификатор (имя) ресурса в рамках данного контекста. Рекомендуется выражать идентификаторы в строковой или числовой форме в соответствии с одной из формальных идентификационных систем, например, унифицированный идентификатор ресурса (URI), цифровой идентификатор объектов (DOI), либо международный стандарт нумерации книг (ISBN).	Этот элемент может быть также использован для локальных идентификаторов, присваиваемых ресурсу его разработчиком в рамках его работы. Не рекомендуется использовать этот элемент для идентификации самих метаданных.

Примеры:
Title="открытое образование"
Identifier="http://www.openet.ru/glossary#open-education"
Subject="словарь"

Identifier="ISBN:0385424728"

Source (источник ресурса)

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

Примеры:
Source=”Третьяковская галерея”
Source=”Картинка из издания Ромео и Джульеты 1922 года, стр. 54”
Source=”http://www.izvestia.ru”

Language (язык ресурса)

Название	Описание	Рекомендации разработчикам
Language	Язык, на котором представлено содержимое ресурса. Рекомендуется использовать формат ISO639, который вместе с RFC 3066 образует двух- или трехбуквенные коды языков с опциональными подкодами, например, “ru”, “en-US”.	Элемент может содержать как текстовые описания используемых языков в строковом формате, так и коды. Элемент может повторяться, если содержимое ресурса представлено на нескольких языках.

Примеры:
Language="ru"
Language="fr"
Language="Русский с резюме на английском"
Language="en-US"

Relation (взаимосвязь ресурса с другими ресурсами, свойства

Название	Описание	Рекомендации разработчикам
Relation	Ссылка на ресурс, связанный с данным ресурсом. Базовый набор DC-элементов не позволяет уточнить тип взаимосвязи. Это делается в расширенном DC с помощью квалификаторов.	Для идентификации Relation и организации соответствующей ссылки старайтесь пользоваться стандартизированной системой идентификации, например, URI, формальными библиографическими ссылками и т.д.

Примеры:
Title="Теория моделей"
Relation="Справочная книга по математической логике в 4-х томах" [Отношение “являться частью” (IsPartOf). “Теория моделей” – первый том четырехтомника]

Title="Краткий курс математического анализа. Электронная версия"
Relation="Курс математического анализа. Электронная версия"
[Отношение ”являться версией” (IsVersionOf). Краткий вариант электронного учебного пособия по математическому анализу является версией курса в целом]

Title="Рапсодия"
Creator=”Рахманинов”
Relation="Компакт-диск"
[Отношение «являться форматом» (IsFormatOf)]

Title="О русской повести и повестях г. Гоголя"
Relation="Миргород"
[Отношение «ссылается-на» (References). В статье В.Белинского дается характеристика сборника повестей Гоголя «Миргород»]

Title="Иван Васильевич меняет профессию"
Relation="Иван Васильевич"
[Отношение «базироваться-на» (IsBasedOn) (фильм снят по мотивам пьесы Булгакова)]

Title="Автомобиль"
Relation="Бензин"
[Отношение «требует» (Requires)]
Обратите внимание на то, что в базовом DC никак не уточняется тип отношения (конкретизация отношений появляется только в квалифицированном Дублинском ядре). Поэтому в базовом варианте системы метаописаний можно зафиксировать только факт, что данные ресурсы каким-то образом связаны.

Coverage (временная и пространственная область действия)

Coverage

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

И в случае пространственной информации, и в случае временных данных очень рекомендуется использовать форматы, понятные человеку, в частности, для обеспечения механизмов интероперабельности, особенно в тех случаях, когда не поддерживаются продвинутые механизмы поиска на основе географической или временной информации. Рекомендуется использовать контролируемые словари (например, тезаурус географических имен) и формальные схемы, например, [DCP], [DCI] и [DCB].

Примеры:
Coverage="1995-1996"
Coverage="Иркутская область"
Coverage="Серебряный век"
Coverage="20 км на север от Брюсселя"

Rights (имущественные и авторские права)

Название	Описание	Рекомендации разработчикам
Rights	Информация о правах, связанных с данным ресурсом. Данный элемент может содержать информацию об авторских правах, ссылки на лицензии и другие юридические документы по теме. Если элемент Rights в метаописании отсутствует, то статус ресурса остается неопределенным – никаких выводов «по умолчанию» не может быть сделано.	Можно использовать элемент Rights как в текстовом формате (или в виде URI, указывающем на декларацию о правах), так и в смешанном формате – краткой информацией, представленной непосредственно в метаописании, и ссылкой на более подробное описание.

Примеры:
Rights="Пиво только членам профсоюза"
Rights="http://cs-tr.cs.cornell.edu/Dienst/Repository/2.0/Terms"

Расширения простой модели DC

По свидетельству Карла Лагоуза первые же дискуссии разработчиков DC обнажили внутренний раскол между минималистами и структуралистами. Минималисты говорили, что значение Дублинского ядра состоит в согласованном множестве широких категорий, используемых для создания простых метаданных в формате «атрибут = значение». Вторые видели в Дублинском ядре основу богатого и однородного языка описаний – «эсперанто» метаданных. Это движение в сторону большей сложности было мотивировано желанием построить формат описаний, который мог бы описывать ресурсы детализировано, аналогично тому, как это делается в типичных библиографических каталогах. В 1997 году было принято решение, согласно которому DC должен был быть расширен с помощью так называемых квалификаторов, позволяющих уточнять утверждения о ресурсах. Данное расширение Дублинского ядра было сделано чрезвычайно аккуратно, и допускало, по сути, только два типа квалификаторов. Первый из них касался уточнения самого элемента, а второй – уточнения допустимых значений элемента:
   Уточнение элементов. Эти квалификаторы делают значение элемента более узким и специфичным. Уточненный («квалифицированный») элемент имеет тот же смысл, что и неуточненный элемент, но с более узкой и строгой областью действия. Например, общее понятие Creator (создатель) может быть уточнено более конкретным понятием Author (автор). Пользователь (программа, сервис или человек), который не понимает смысла данного уточнения, должен иметь возможность игнорировать квалификатор и работать с элементом, как если бы он был неквалифицированным. Строгие и корректные определения уточнений элементов должны быть публично доступными.
   Схема кодирования. Квалификаторы этого вида определяют схему интерпретации («понимания») значений элементов. Эти схемы включают в себя контролируемые словари, условные обозначения или правила разбора (парсинга) значения. Значение, сформированное в соответствии со схемой кодирования, будет либо элементом некоторого контролируемого словаря (например, термином из некоторой классификационной иерархии, такой как УДК), либо строкой, сформатированной в соответствии с формализованной нотацией (например, «1960-12-20» в качестве стандартной записи даты). Если схема кодирования непонятна обработчику, значение элемента все равно должно остаться полезным для читателя-человека. Строгое описание схемы кодирования для квалификаторов должно находиться в свободном доступе.
   Любой квалификатор Дублинского ядра должен принадлежать одному из этих двух типов. В примерах квалификаторы элементов будем записывать через двойное двоеточие. В зависимости от типа квалификатора, он находится либо слева, либо справа от равенства.

Элемент	Комментарий
Date::Modified = “2002-12-15”	Дата модификации ресурса – 15 декабря 2002 г.
Language = ISO639-2::”RU”	Язык ресурса – русский в соответствии с обозначением (контролируемым словарем), представленном в стандарте ISO639-2.
Relation::hasPart = URI::”http://somesite.ru/glava5”	Частью ресурса является ресурс с URI ”http://somesite.ru/glava5”

и так далее. Те квалификаторы, которые находятся в левой части равенства, имеют тип уточнения элементов. Те из них, которые находятся в правой части, имеют тип схемы кодирования.
Кроме квалификаторов, расширение простой модели DC включает новый – шестнадцатый – элемент

Название элемента	Описание элемента	Рекомендации разработчикам метаданных
Audience	Сущность или класс объектов, на которые данный ресурс ориентрован как на потенциальных пользователей, либо для которых он будет полезен. Аудитория ресурса может определяться создателем, публикатором или иными лицами.	Наиболее эффективно данный элемент работает, если он принимает значение среди элементов некоторого контролируемого словаря. Ни один из таких словарей пока не принят рабчей группой DC, однако в ряде отраслей такие словари активно разрабатываются.

Пример использования:
Audience = “Старшие классы средней школы”

Уточнение элементов Дублинского ядра

Теперь перечислим уточнения элементов DC, принятые к настоящему времени.

Название элемента	Описание элемента	Уточняемый базовый элемент
Alternative	Альтернативное название ресурса.	title
tableOfContents	Список частей ресурса в виде символьной строки (например, «введение; основы математического анализа; современные исследования в области анализа»)	description
abstract	Аннотация ресурса.	description
created	Дата создания ресурса	date
valid	Период времени, в течение которого ресурс является действительным, имеющим силу (например, ресурс, описывающий условия конкурса является действительным до окончания проведения этого конкурса)	date
available	Дата начала доступа к ресурсу. Используется, когда дата начала доступа к ресурсу не совпадает с датой его создания.	date
issued	Дата формальной публикации ресурса. Используется, когда эта дата отлична от других дат жизненного цикла ресурса.	date
modified	Дата модификации ресурса. В зависимости от задач этот элемент может указывать только на последнюю дату модификации, либо с помощью нескольких экземпляров этого элемента можно перечислить все даты изменений ресурса.	date
extent	Размер или продолжительность ресурса. Поскольку размер и продолжительность могут измеряться в разных единицах, значения этого элемента могут содержать числа с указанием соответствующей единицы измерения, например, “115 Kb”.	format
medium	Носитель, на котором хранится ресурс, например, “холст”, “компакт-диск”. Используется, когда ресурс имеет физическую природу или используется только на физическом носителе.	format
isVersionOf	Используется, когда данный ресурс является версией, изданием или адаптацией другого ресурса. Версия подразумевает существенные изменения в содержимом ресурса, а не только особенности формата. Пример, ресурс «Вестсайдская история» является версией (адаптацией) ресурса «Ромео и Джульета».	relation
hasVersion	Отношение, обратное отношению isVersionOf.	relation
isReplacedBy	Описываемый ресурс замещается, вытесняется, заменяется другим ресурсом, например, когда существует цепочка версий, и только одна версия является действительной.	relation
Replaces	Отношение, обратное отношению isReplacedBy	relation
isRequiredBy	Указываемый ресурс необходим описываемому ресурсу – либо физически, либо логически. Часто встречается, например, в информации о привязке программного обеспечения к конкретному оборудованию.	relation
Requires	Отношение, обратное отношению isRequiredBy	relation
isPartOf	Описываемый ресурс является частью указанного ресурса	relation
hasPart	Указанный ресурс является частью описываемого ресурса	relation
isReferencedBy	Указанный ресурс ссылается на описываемый ресурс. Используется, когда указанный ресурс играет существенную роль для данного ресурса. Пример - стихотворение и пародия на стихотворение.	relation
References	Отношение, обратное isReferencedBy	relation
isFormatOf	Указывает на ресурс, имеющий то же содержание, что и данный ресурс, но представленный в другом формате.	relation
hasFormat	Описываемый ресурс существовал до указанного ресурса, имеющего аналогичное содержание, но другой формат представления.	relation
conformsTo	Ссылка на стандарт, спецификации, которым удовлетворяет описываемый ресурс.	relation
spatial	пространственная характеристика ресурса – может