Сопоставительный анализ форматов с точки зрения интеграции данных

Выше приведены основные характеристики анализируемых форматов метаданных, теперь рассмотрим, как эти форматы соотносятся между собой. Форматы можно классифицировать, во-первых, по охвату и подробности типов описываемых ресурсов, что отражено в рекомендованном словаре типов описываемых ресурсов. Во-вторых, по ширине и подробности области описания ресурсов и мощности структуры элементов метаданных. Кроме этого, можно классифицировать по предметным областям, или целям разработки и использования формата метаданных. На рис. 1 форматы распределены по мощности своей структуры и по описываемым предметным областям. На рисунке показаны форматы, описывающие наиболее близкие между собой области: описание музейных и исторических ценностей, архивов, издательской продукции, и библиографическое описание. Эти форматы во многих случаях позволяют описывать одни и те же ресурсы, но каждый формат обладает своей спецификой. Можно сказать, что стержнем, связующим эти форматы является цепочка DC – MODS – MARC. Во-первых, потому что указанные форматы наиболее тесно связаны между собой, во-вторых, оскольку предметная область, для которой они предназначены (библиографическое описание) является наиболее общей из представленных на рисунке. Формат DC универсален и предназначен для описания ресурсов любого типа. MODS и MARC предназначены для библиографического описания ресурса. Библиографическое описание является достаточно широким и наиболее общим, по сравнению с областями описания других форматов. Так, используя MODS и MARC, можно описать, в том числе и исторические ценности, но формат CDWA ориентирован на специфику жизненного цикла ресурса как исторической ценности, чего нельзя добиться с помощью MODS и MARC. Точно также, PRISM и ONIX описывают статьи, книги, которые можно описать, используя MODS и MARC. Но эти форматы обладают своей спецификой — нацелены на нужды производителей и распространителей издательской продукции и новостей. EAD и GILS ориентированы на специфику обслуживания информационных ресурсов и архивов, и предоставления к ним доступа. Также на рис. 28 показано распределение форматов по мощности структуры их элементов.

Рис. 28 - Распределение форматов по мощности структуры их элементов и описываемой предметной области.

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

Рис. 29 показывает оценку мощности пересечения элементов той же группы форматов, что была показана на первом рисунке. Самая большая мощность у пересечения форматов с мощной структурой, это MARC и ONIX (на рисунке это показано стрелкой между ними). Форматы MARC, ONIX, MODS, GILS, PRISM имеют практически одинаковое пересечение с форматом DC. Поэтому на рисунке указанные форматы объединены одним большим овалом и пересечение их всех с DC показано одной стрелкой. Точно так же как и DC с указанными форматами соотносится формат CDWA, поэтому он помещён в один овал вместе с DC. Аналогичная картина с форматами MODS, GILS, PRISM с одной стороны и MARC, ONIX с другой стороны.

Рис. 29 - Оценка количества элементов, которое может быть перенесено из одного формата в другой.

Даже если установлена связь между элементами в двух разных форматах метадан

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

− проблемы, связанные с разнородностью атрибутов;

− проблемы, связанные с потерей данных;

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

Перечислим некоторые из этих проблем.

Связанные атрибуты в разных форматах отличаются математическим преобразованием данных, хранящихся в них. Например, время может быть указано в 12-часовом виде (с указанием до или после полудня) или в 24-часовом виде. Для корректного переноса данных из одного формата метаданных в другой в такой ситуации достаточно использовать один или несколько общепринятых стандартов. Другая проблема связана с различием типов данных у связанных атрибутов в разных форматах. Так, зачастую в рекомендациях к форматам метаданных указывается, что значение атрибута может быть выбрано из того или иного словаря, либо указано в произвольной форме. Например, в схеме DCMES (DC Simple) в качестве значения элемента type (обозначает тип ресурса) рекомендуется использовать одно из значений специального словаря типов ресурсов DCMITYPE (DCMI Type Vocabulary). Список допустимых терминов из словаря DCMITYPE представлен на рис. 3 слева. Элементу type (из DCMES) в схеме MODS соответствуют два элемента15: typeOfResource и genre. Исходя из набора значений словаря DCMITYPE, элементу type ближе по смыслу элемент схемы MODS typeOfResource. Для элемента typeOfResource тоже существует рекомендованный словарь типов ресурсов, он представлен на рис. 3 справа. Сопоставление словаря типов ресурсов DCMITYPE и словаря типов ресурсов, рекомендованного в схеме MODS показывает, что соответствие между словарями неполное (некоторому термину в одном словаре не соответствуетни одного термина в другом словаре) и неоднозначное (некоторому термину в одном словаре соответствует более одного термина в другом словаре). Использование такого неполного и неоднозначного соответствия грозит потерей данных при конвертации данных из одного формата в другой. В приведённом примере несоответствие словарей друг другу обусловлено различием в типах ресурсов, которые описывают форматы метаданных DC и MODS. DC предназначен для описания более широкого круга типов ресурсов, чем MODS, что и видно из сопоставления словарей на рис. 30.

Рис. 30- Сопоставление словаря типов ресурсов DCMITYPE (слева) и словаря типов ресурсов, рекомендованного в схеме MODS (справа)

Понятие, обозначаемое одним из атрибутов, не существует в другом, сопоставимом формате метаданных. Зачастую это связано с традициями того или иного сообщества, разрабатывавшего формат. Это одна из причин, по которой существуют два направления развития MARC (UNIMARC и MARC21) — различия в национальных правилах составления библиографических описаний. Другие случаи: система научных званий, отличающаяся в России и США; налог, существующий в России и не существующий в США — также являются примерами несопоставимости понятий в одной предметной области, но в разных сообществах. Одно и то же понятие в одной схеме выражается одним атрибутом, а в другой схеме набором атрибутов. Например, в DCMES определён элемент identifier, в котором рекомендуется указывать в зависимости от контекста URI, URL, DOI либо ISBN, причём тип идентификатора можно указывать в этом же поле. В других форматах метаданных, например MODS, LOM, для обозначения типа идентификатора предназначен специальный атрибут. То есть идентификатор представляется двумя атрибутами — в одном указывается тип идентификатора, в другом значение идентификатора.

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

Есть несколько проблем, связанных с человеческим фактором, которые несколько усложняют жизнь людям, занимающимся интеграцией форматов метаданных. Так, дополнительной памяти и внимания требуют атрибуты, у которых название не выражает семантику (как в MARC — числовые метки). Для машинной обработки числовые метки подходят идеально, а человек их воспринимает хуже, чем текстовые и осмысленно названные. Другая проблема из этого разряда — атрибуты, которые обладают разными именами в разных форматах метаданных, при этом значат одно и то же. Например, элементу DC Description соответствует элемент GILS Abstract. Следует отметить, что разработчики форматов обычно не по прихоти называют близкие по смыслу атрибуты разными именами, а потому что эти атрибуты всего лишь близки, но не в точности соответствуют друг другу. Яркий тому пример, spatial, уточняющий coverage в DC (пространственные характеристики описываемого ресурса) и < subject >< geographic > в MODS (географическое расположение). Ещё одна проблема стоит упоминания, хотя не является специфичной для задачи интеграции данных в разных форматах метаданных. Это интеграция данных на разных языках. Например, в качестве значений атрибута содержатся текстовые данные, обозначающие одно и то же, но на разных языках. Так, в общем случае название ресурса имеет множество представлений: на русском, английском, других языках. Проблема заключается в том, чтобы система автоматизировано принимала решения о сопоставимости элементов данных, если они на одном языке, либо их несопоставимости, если на разных. Существуют разные подходы для решения этой проблемы, но универсального решения нет. Наиболее удачным является подход, используемый в XML. В форматах данных, использующих XML, конструкция xml:lang позволяет указать язык элемента данных. Решение полностью аналогично случаю с указанием типа идентификатора в специально предназначенном для этого атрибуте. Для указания кода языка существуют международные стандарты (ISO 639, RFC 1766,).

Теперь рассмотрим проблемы интеграции в другом разрезе. Рассмотрим особенности интеграции каждого элемента из набора элементов DCMES с другими форматами метаданных. Согласно комментариям к формату элементы данных contributor, creator, publisher скорее всего могут быть персоной, организацией или сервисом. Хотя в комментариях к DCMES рекомендуется в качестве значений этих полей указывать имя соответственно распространителя, создателя или издателя, для задач интеграции данных предпочтительнее другой вариант. Для описания персон и организаций существует широко распространённый стандарт vCard, поэтому значением элемента данных contributor, creator, publisher можно указывать ссылку на ресурс в формате vCard. Остановимся подробнее на вопросе, чем ссылка на ресурс в формате vCard лучше имени. Дело в том, что для написания имени человека нет единых правил: оно может быть указано как имя с фамилией, возможно ещё и с отчеством, а возможно только фамилия с инициалами, к тому же все эти элементы могут быть указаны в разном порядке. С названием организации тоже нет однозначности: часто существует полное и сокращённое название, может указываться в кавычках или u1073 без, также может указываться форма собственности организации. В таких условиях, если у нескольких ресурсов один и тот же создатель (элемент creator), то в каждом случае его имя может быть занесено посвоему. Например, в одном случае имя человека может быть занесено в формате ФИО, а в другом как имя, отчество, фамилия. В такой ситуации создатели этих ресурсов не могут быть однозначно идентифицированы как одно лицо. В случае со ссылкой на ресурс в формате vCard, если у нескольких ресурсов один и тот же создатель (элемент creator), то в каждом случае в поле creator будет указана ссылка на один и тот же ресурс в формате vCard. Таким образом, использованием vCard (либо других сопоставимых общепринятых форматов) можно достигнуть большей интероперабельности данных. Элемент coverage описывает пространственное расположение и временной период, связанные с существованием ресурса. В качестве значений этого элемента, в комментариях к формату рекомендуется использовать стандартные форматы или словари, например словарь Type Vocabulary, Thesaurus of Geographic Names16 (TGN) касательно пространственного расположения. Во многих других форматах метаданных для идентификации географического местоположения используются ISO 3166–1, ISO 3166–2, RFC 3066, marcgac, marccountry. Элемент date описывает дату, связанную с существованием ресурса. В качестве общепринятого формата даты / времени используется ISO 8601. В качестве значений элементов identifier, relation и source к омментарии к формату рекомендуют использовать идентификаторы соответственно самого описываемого ресурса, связанных с ним ресурсов и источника, из которого взят описываемый ресурс. В качестве идентификаторов рекомендуется использовать значения общепринятых идентификационных систем, таких как URI, URL, DOI, ISBN. В качестве значения элемента description, помимо просто текстового описания, также допускаются ссылки на ресурсы, представляющие описание данного ресурса. А роль ссылки выполняют, как известно, указанные выше идентификаторы. Эти же идентификаторы используются во всех других форматах метаданных. Для значений элемента format р екомендуется использовать значения из словаря MIME, который рекомендован к использованию также и во многих других форматах метаданных. Не следует путать этот элемент с элементом type, который специфицирует тип информации, независимо от её формата. type ресурса может быть специфицирован как текстовый, при том что format ресурса может быть текстовым, либо графическим, если текст хранится в формате изображения. Как уже упоминалось выше, в качестве значений элемента type рекомендуется использовать словарь DCMITYPE. Пример сопоставления этого элемента DCMES с соответствующим элементом схемы MODS на рис. 3. В качестве значений элемента language комментарий рекомендует использовать через дефис “код страны”-“код языка”. Стандарты, соответствующие словарям кодов географического местоположения уже упоминались. Касательно кодов языка, общепринятыми во многих форматах метаданных являются словари, соответствующие стандартам ISO 639, RFC 1766. Элемент rights можно интегрировать c другими форматами при рассмотрении уточнённых элементов DC. Для значений элемента subject рекомендуется использовать ключевые слова, фразы из словарей с нормируемой лексикой17, либо коды классификационных систем (таких как УДК, ББК и т.п.). К сожалению, хотя таких классификационных систем немного и они общеприняты, но УДК и ББК настолько сложны, что построение их взаимного соответствия в общем виде является практически нерешённой задачей.

Значение элемента title является просто текстовым значением, возможно на нескольких языках.

Таким образом, анализ сопоставлений элементов выбранных нами форматов метаданных показывает, что каждый из отобранных нами для анализа форматов совместим с набором элементов DCMES. С практической точки зрения, например для задачи поиска, это значит следующее: метаданные из разных форматов (допустим, из разных источников) могут быть преобразованы в формат DCMES, что позволяет производить поиск в полях DCMES, независимо от формата хранения или источника метаданных, в которых производится поиск. Иначе говоря, приходим к выводу, что все эти форматы поддаются интеграции через набор элементов DCMES. Варианты интеграции на уровне более сложного формата, чем DCMES (например, DC с использованием квалификаторов, MODS или MARC) ввиду проблем, рассмотренных ранее, требуют дополнительных исследований. Как показывает сопоставительный анализ форматов метаданных, одна из тенденций развития метаданных — постепенная унификация синтаксиса на основе XML. Для некоторых форматов разрабатываются соответствующие им XML схемы (например, для MARCXML18, CDWA Lite19, LOM XML Schema20), другие форматы перешли к поддержке разработчиками в виде XML схемы (ONIX), а часть форматов изначально разрабатывались в таком виде (MODS). Другой тенденцией является описание форматов метаданных на языке более высокого уровня. То есть, описание всех элементов формата метаданных и отношений между элементами на некотором формализованном языке. Например, для DC и PRISM существуют соответствующие RDF схемы. Таким образом, люди, проекты, книги, статьи и многие другие субъекты, объекты и отношения между ними в области наноиндустрии охвачены целой системой форматов метаданных, разработанных для разнообразных практических задач этой области. Разные форматы метаданных, предназначенные для решения разных задач, зачастую описывают одни и те же сущности. За счёт этого пересечения, однажды занесённые данные для решения, например, издательских задач, могут быть перенесены в другой формат и использованы в книжном магазине, библиотеке и т.п. Наименее охваченной форматами метаданных областью из очерченного круга являются научные данные, поскольку они наиболее разнообразны и, следовательно, тяжелее поддаются интеграции. Именно в области разработки стандартов и инструментов для выражения с помощью мета данных всё более сложных отношений идёт сейчас развитие метаданных. В качестве основного стандарта спецификаций метаданных разработчиками из Новгородского государственного университета имени Ярослава мудрого, участвующими в качестве соисполнителя в создании и наполнении федерального интернет-портала «Нанотехнологии и наноматериалы» предложена модель спецификации метаданных, основанная на формате RUS LOM (0 Детальное описание формата RUS LOM), допускающая расширение базовой спецификации метаданных для отрасли наноиндустрии.

Дата добавления: 2014-12-26