A схема crosswalk - это таблица, в которой показаны эквивалентные элементы (или «поля») в более чем одной схеме базы данных. Он сопоставляет элементы одной схемы с эквивалентными элементами другой схемы.
Таблицы переходов часто используются в корпоративных системах или параллельно с ними, особенно когда несколько систем сопряжены или когда система включает устаревшую систему данные. В контексте интерфейсов они функционируют как своего рода внутренний механизм Извлечение, преобразование, загрузка (ETL).
Например, это метаданные переход от стандартов MARC к Dublin Core :
поле MARC | Dublin Core element | |
---|---|---|
$ 260. c (Дата публикации, распространения и т. д.) | → | Date.Created |
522 (Примечание по географическому охвату) | → | Coverage.Spatial |
$ 300a (Физическое описание) | → | Format.Extent |
Пешеходные переходы показывают людям, где поместить данные из одной схемы в другую. Они часто используются библиотеками, архивами, музеями и другими учреждениями культуры для перевода данных в стандарты MARC, Dublin Core, Text Encoding Initiative (TEI) и другие схемы метаданных. Например, предположим, что в каталоге архива есть запись в формате MARC, описывающая рукопись. Если архив делает цифровую копию этой рукописи и хочет отобразить ее в сети вместе с информацией из каталога, ему придется преобразовать данные из записи каталога MARC в другой формат, такой как Описание объекта метаданных Схема, которую можно просмотреть на веб-странице. Поскольку поля MARC отличаются от полей MODS, необходимо принять решение о том, куда поместить данные в MODS. Этот тип «преобразования» из одного формата в другой часто называется «преобразованием метаданных» или «преобразованием полей» и связан с «преобразованием данных » и «семантическим преобразованием »..
Пешеходные переходы также имеют несколько технических возможностей. Они помогают базам данных, использующим различные схемы метаданных, обмениваться информацией. Они помогают сборщикам метаданных создавать сводные каталоги. Они позволяют поисковым системам выполнять поиск в нескольких базах данных одновременно с помощью одного запроса.
Одна из самых больших проблем для пешеходных переходов заключается в том, что никакие две схемы метаданных не эквивалентны на 100%. В одной схеме может быть поле, которого нет в другой схеме, или поле, разделенное на два разных поля в другой схеме; Вот почему вы часто теряете данные при преобразовании сложной схемы в более простую. Например, при отображении из MARC в Simple Dublin Core вы теряете различие между типами заголовков:
поле MARC | Dublin Core element | |
---|---|---|
210 Abbreviated Title | → | Title |
222 Key Title | → | Заголовок |
240 Унифицированный заголовок | → | Заголовок |
242 Переведенный заголовок | → | Заголовок |
245 Заявление о заголовке | → | Заголовок |
246 Вариант Заголовок | → | Заголовок |
Только Simple Dublin Core имеет один элемент «Заголовок», чтобы все различные типы заголовков в формате MARC объединялись без каких-либо дополнительных различий. Это называется сопоставлением «многие к одному». Вот почему после того, как вы перевели эти заголовки в Simple Dublin Core, вы не сможете перевести их обратно в MARC. Как только они становятся Simple Dublin Core, вы теряете информацию в формате MARC о том, какие типы заголовков они представляют, поэтому при отображении из Simple Dublin Core обратно в MARC все данные в элементе «Title» сопоставляются с основным заявлением заголовка MARC 245
Элемент Dublin Core | поле MARC | |
---|---|---|
Заголовок | → | 245 Заявление заголовка |
Заголовок | → | 245 Заявление заголовка |
Заголовок | → | 245 Заявление заголовка |
Заголовок | → | 245 Заголовок |
Заголовок | → | 245 Заголовок |
Заголовок | → | 245 Заголовок |
Вот почему пешеходные переходы называются «боковыми» (односторонними) отображениями от одной схемы к другой. Для отображения схемы A на схему B и схемы B на схему A потребуются отдельные пешеходные переходы.
Другие проблемы отображения возникают, когда:
Некоторые из этих проблем просто не решаемы. Как говорит Карен Койл в «Метаданных перекрестного цитирования: опыт Калифорнийского университета»
«Чем больше у нас опыта работы с метаданными, тем яснее становится, что совершенство метаданных недостижимо, и любой, кто попытается это сделать, будет сильно разочарован. Когда метаданные перемещаются между двумя или более несвязанными источниками, будут элементы данных, которые невозможно согласовать идеальным образом. Ключом к успешному переходу метаданных является интеллектуальная гибкость. Важно сосредоточить внимание на важных целях и быть готовым к компромиссу. для практического завершения проектов ».