Наверх

15 ключевых элементов метаданных

Архив
Время чтения: 6 минут
3
15 ключевых элементов метаданных

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

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

Другая крайность – полнотекстовый поиск: ищем скорее не документ, а нужную информацию в нем.

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

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

Набор дублинских ключевых элементов метаданных – это словарь из 15 свойств, предназначенных для описания любого ресурса. Элементы «ключевые», потому что описывают самые основные свойства, которые можно применить практически к любым данным; «дублинские» - потому что начало их разработке было положено на семинаре в Дублине, штат Огайо, США в 1995 году.

Элементы следующие:

Оригинал

Перевод

Описание

1

Contributor

Автор

Сотрудник, организация или сервис, ответственный за изменения ресурса.

2

Coverage

Покрытие

Область применения, действия ресурса.

3

Creator

Создатель

Сотрудник, создавший ресурс.

4

Date

Дата

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

5

Description

Описание

Любое краткое описание ресурса.

6

Format

Формат

Формат файла, физический носитель или измерения ресурса.

7

Identifier

Идентификатор

Однозначный указатель на ресурс в известном контексте.

8

Language

Язык

Язык ресурса.

9

Publisher

Издатель

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

10

Relation

Связь

Ссылка на другие связанные ресурсы.

11

Rights

Права

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

12

Source

Источник

Ресурс, от которого наследуется настоящий ресурс.

13

Subject

Тема

Тема ресурса; ключевые слова, классификационные коды, ключевые фразы и т.д.

14

Title

Наименование

Наименование ресурса

15

Type

Тип

Тип ресурса, его природа, жанр.

Существуют и дополнительные элементы, а также словари данных для некоторых элементов.

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 3

Позволю себе процитировать одну статью: "Сколь ни важны возможности обработки неструктурированной информации, пропагандируемые как ключевые для многих других систем электронного документооборота, корпоративная политика в области информатизации должна быть направлена больше на обеспечение процесса структурирования корпоративной информации, чем на совершенствование методов обработки неструктурированной информации. Реализация наиболее эффективных технологий обработки возможна именно для структурированной информации, более того, критически важные данные, которые необходимо хранить и извлекать со 100%-й достоверностью, должны быть представлены только в структурированной форме." С одной стороны резковатое и спорное заявление. С другой стороны проблема-то реально есть. И этот блог тому подтверждение.

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