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	пространственная характеристика ресурса – может включать географическое название, широту и долготу и другую пространственную информацию.	coverage
temporal	Временные характеристики ресурса, связанные с содержимым ресурса, а не его жизненным циклом (в последнем случае используется элемент date). Например, палеонтологический ресурс может содержать характеристику «юрский период».	coverage
mediator	Персона или сущность, являющаяся посредником при использовании ресурса. Например, это может быть преподаватель, либо программная система, благодаря которой данный ресурс «проигрывается».	audience
dateAccepted	Дата принятия ресурса (например, к публикации статьи в журнале или диссертация к защите)	date
dateCopyrighted	Дата фиксации авторских прав	date
dateSubmitted	Дата подачи ресурса (например, статьи в журнал)	date
educationLevel	Класс персон, на которых ориентирован образовательный ресурс, например, «школьники», «4-5 курс», «послевузовское образование».	audience
accessRights	Информация о том, кто может получить доступ к данному ресурсу, например, «доступен по подписке».	rights
bibliographicCitation	Рекомендуется использовать этот элемент для формулирования максимально подробной библиографической ссылки на описываемый ресурс. Для российских пользователей, вероятно, следует рекомендовать использовать соответствующий ГОСТ 7.1-84.	identifier

Схемы кодирования Дублинского ядра

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

Элемент	Схема кодирования	Комментарии
subject	LCSH	Library of Congress Subject Headings – классификация ресурсов, принятая в библиотеке конгресса США.
	MeSH	Medical Subject Headings – классификация в области медицины
	DDC	Dewey Decimal Classification – классическая классификация Дьюи.
	LCC	Library of Congress Classification
	UDC	Всем известная УДК
date	DCMI Period	Спецификация временных интервалов
date	W3C-DTF	Формат обозначений дат и времени – спецификация W3-консорциума на основе ISO8601
type	DCMI Type Vocabulary	Базовый словарь типов ресурсов, предлагаемый DC
format	IMT	Тип Интернет-носителя ресурса
identidfier	URI	Унифицированный идентификатор ресурса
language	ISO639-2RFC3066	Стандарт по двух- и трехбуквенному сокращению названий языков
relation	URI	см. выше
coverage	DCMI Point	Формат описания точек в пространстве на основе географических координат
	DCMI Period	см. выше
	ISO3166	Сокращения имен государств
	DCMI Box	Спецификация DC по описанию областей на основе географических координат
	TGN	Словарь Гетти географических названий
	W3C-DTF	см. выше.

Базовый словарь типов ресурсов

Уделим особое внимание ключевому словарю Дублинского ядра – DCMI Type Vocabulary, – определяющему тип ресурса. Этот словарь является базовым классификатором ресурсов, и должен пониматься практически всеми системами, поддерживающими Дублинское ядро. Поэтому его использование предоставляет возможности работы с ресурсом даже тем системам, которые не способны обрабатывать более специфическую информацию из других элементов. Этот словарь состоит из следующих элементов:

Элемент словаря	Значение
Collection	Коллекция является совокупностью блоков, частей, элементов. Термин collection означает, что ресурс описывается как группа, причем его части могут быть самостоятельно описаны и в них доступна навигация
Dataset	Структура данных. Обозначает информацию, представленную в строгих форматах (списки, таблицы, базы данных и т.д.).
Event	Событие. Представляет собой зависящее от времени событие, не имеющее большую длительность. Метаданные для событий обеспечивают описание события, которое может служить основой для понимания его цели, места проведения, ответственных лиц и связей с другими событиями и ресурсами.
Image	Изображение. Такой ресурс представляет собой визуальные данные в символическом формате, отличном от текста. Например, картинки, фотографии физических объектов, рисунки, графики, анимация, фильмы, карты и т.д.
InteractiveResource	Интерактивный ресурс – ресурс, который подразумевает реакцию от пользователя, которая должна быть понята и обработана. Например, это формы в веб-страницах, апплеты, мультимедийные обучающие объекты, чаты, виртуальная реальность.
Service	Сервис это система, реализующая одну или несколько функций, полезных для конечного пользователя. Примеры включают банковские сервисы, системы авторизации, межбиблиотечный абонемент и т.д.
Software	Компьютерная программа, в виде кода-источника, или откомпилированная, которая доступна для инсталляции на других компьютерах. Для программ, обеспечивающих только интерактивные функции, рекомендуется использовать InteractiveResource
Sound	Звук – ресурс, чье содержимое расчитано на аудиопроигрование. Например, файл в mp3-формате, аудио компакт-диск, записанное выступление.
Text	Ресурс, чье содержимое представляет собой в первую очередь последовательность слов для чтения. Примеры – книги, письма, диссертации, поэмы, газеты, статьи, списки рассылок. Факсимиле или изображения текстовых документов также принадлежат типу «текст».
PhisicalObject	Неодушевленный объект или субстанция в трех измерениях. Например, компьютер, пирамида Хеопса, скульптура. Виртуальные модели физических объектов должны иметь другие типы (текст, изображение и т.д.)
StillImage	Статичное изображение – картина, рисунок, фотография, графический дизайн, карта, план. Практика показывает, что изображения текстовых материалов должны иметь не данный тип, а тип Text. Кроме того, тип StillImage могут иметь только такие ресурсы, которые описываемы более широким понятием Image.
MovingImage	Серия изображений, которые, будучи показанные в последовательности и с необходимой скоростью, вызывают впечатление движения. Примеры движущихся изображений – анимация, фильмы, телевизионные программы, видео, визуальные результаты моделирования. Тип MovingImage могут иметь только такие ресурсы, которые описываемы понятием Image.

Основные принципы построения DC

К серьезным достижениям группы разработчиков Дублинского ядра следует отнести тщательно продуманные принципы построения системы метаописаний.

Простота

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

Всеми понимаемая семантика

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

Интернационализация

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

Расширяемость

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

Как отмечалось выше, в этом смысле DC выступает в роли «пиджина» – упрощенного языка, одинаково понимаемого разными сообществами. «Графически» это представлено на рисунке. Такое использование DC является основой для интероперабельности между разными сообществами, предметными областями, образовательными системами и т.д.
   Кроме этих базовых принципов успех проекта обеспечили несколько более тонких методологических идей. Три из них перечислены в:

Принцип «один к одному» (One-to-One Principle)
   DC-метаданные описывают непосредственно саму версию ресурса, а не то, как одна версия ресурса замещает другую. Например, цифровое изображение Моны Лизы имеет сходство с оригиналом из Лувра, но разница между ними очевидна. Раз так, то цифровое изображение Моны Лизы должно описываться само по себе, а не как представитель оригинальной картины. Например, поле Creator (создатель ресурса) скорее должно содержать информацию об авторе цифрового изображения, чем авторе всемирно известного шедевра. Кроме того, принцип один-к-одному означает, что для каждой единицы информации должен использоваться отдельный экземпляр соответствующего элемента. Например, если ресурс имеет двух авторов, то каждый из них должен быть описан в отдельном экземпляре элемента Creator.

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

Корректность значений
   На практике конкретные значения элементов Дублинского ядра могут варьироваться в зависимости от контекста. Однако при разработке конкретных метаописаний нельзя ориентироваться на то, что эти описания будут использоваться только компьютерами. Это накладывает ограничения на структуру метаданных. При этом требование, чтобы данные в элементах описания были полезны при поиске иформации, остается одним из ключевых ограничений.
   Хотя спецификация DC с самого начала была преимущественно ориентирована на описание ресурсов, имеющих тип «документ», благодаря своей гибкости и выразительности, она может также применяться к ресурсам других типов. Успешность применения DC как способа метаописаний «недокументальных» классов ресурсов зависит от того, насколько структура элементов DC отражает природу этих классов, а также от целей разработки этих метаодисаний. Страница [DC-proj] содержит информацию о большом количестве разнообразных проектов, базирующихся на DC.
   mona Приведенные выше принципы Карл Лагоуз в своей статье [LK2001] демонстрирует на примере «электронного произведения» Джорджа Кастальдо «Мона Лиза в бигуди» - постмодернистской интерпретации картины Леонардо да Винчи. При построении метаописания этого ресурса возникает ряд вопросов. Кто создатель данного ресурса? Каково его имя? Когда ресурс был создан? В соответствии с идеологией Дублинского ядра в это метаописания могут быть включены следующие данные:

Title = “Мона Лиза в бигуди”
Creator = “Леонардо да Винчи”
Creator = “Джордж Кастальдо”
Date = “1506”
Date = “1994”
Coverage = “Лувр”
Identifier = “ http://www.studiolo.org/Mona/MONA08.htm ”
Format = “image”
Format = “12597 B”
Format = “210 x 320 pixels”

В соответствии с принципом «один-к-одному» каждый ответ на вопрос «Кто является создателем ресурса?» дан в метаданных в виде отдельного утверждения (DC-элемента). То же самое касается дат, связанных с данным ресурсом. Отметим, что основной набор элементов не позволяет уточнить роль приведенной даты в жизненном цикле ресурса. Для того, чтобы это сделать, нужно использовать квалификаторы элементов.

Привязка DC к синтаксическим схемам

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

Пространства имен

Для основных элементов Дублинского ядра рекомендуется использовать следующее пространство имен:

xmlns:dc="http://purl.org/dc/elements/1.1/"

Префикс dc является стандартным префиксом для основных элементов Дублинского ядра. Например,

<dc:creator>Alexander Pushkin</dc:creator>

Для квалификаторов предусматривается следующее пространство имен:

xmlns:dcterms="http://purl.org/dc/terms/"

Наконец, для уточнения значений элементов с помощью их типизации рекомендуется использовать пространство имен для типов данных XML-схемы:

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

поскольку типизация значений DC-элементов унаследована от типов данных значений в XML-схеме.

Начнем с общих рекомендаций.

Абстрактная модель простого DC

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

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

Рекомендации, связанные с простым DC:

Абстрактная модель квалифицированного DC

имеет следующие базовые свойства:

• В квалифицированном DC (также, как и в простом) одна запись представляет собой одно или несколько свойств со значениями, ассоциированными с ними
• Так же, как и в простом Дублинском ядре, каждый DC-элемент представляет собой свойство (атрибут) описываемого ресурса.
• Каждое свойство представляет собой:

o либо один из базовых DC-элементов;
o либо один из других элементов, рекомендованных DCMI [DCTERMS] (например, audience);
o либо одно из уточнений базовых DC-элементов

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

Рекомендации для квалифицированного Дублинского ядра: