Вернёмся в увлекательный мир файловых форматов! Часть 2

(Окончание, начало см. http://rusrim.blogspot.com/2022/07/1.html )

Обзор и обновления описаний форматов (FDD)

В нашем предыдущем посте серии «Увлекательный мир файловых форматов» (Fun with File Formats, первый пост см. здесь: https://blogs.loc.gov/thesignal/2021/12/fun-with-file-formats/?loclr=blogsig ) мы упомянули о том, что отдаём приоритет документированным описаниям (format description document, FDD) новых форматов, если форматы отмечены как предпочтительные или допустимые в Заявлении о рекомендуемых форматах (Recommended Formats Statement, RFS, https://www.loc.gov/preservation/resources/rfs/index.html?loclr=blogsig ). Приоритеты обновления FDD-описаний такие же. Готовясь к выпуску этим летом обновленного «Заявления», мы усердно работали над обновлением FDD-описаний для предпочтительных и допустимых форматов (которых на данный момент насчитывается 55!).

С определённой помощью коллеги по группе мы подготовили скрипт, который анализирует XML-описания в составе всех наших FDD, извлекая содержимое поля «LC Preference» и дату последнего обновления. К этим данным мы применяем кое-какую магию Excel (и человеческие глаза) для выделения FDD-описаний форматов, перечисленных в «Заявлении». Благодаря этим усилиям мы обнаружили, что не всегда были последовательны в плане языка при заполнении поля «LC Preference», что создавало проблемы, когда мы пытались использовать Excel для выделения «допустимых» и «предпочтительных» форматов, а не тех форматов, которые «не являются предпочтительными». Сейчас мы работаем над обеспечением согласованности в этом плане с тем, чтобы уберечь себя от неприятностей в будущем.

Вооружившись списком форматов, представленных в «Заявлении», мы определили приоритеты для наших обновлений на основе даты «Последнее существенное обновление FDD» (Last significant FDD update). Нам неловко признаться в том, что некоторые из наших FDD-описаний не обновлялись, скажем так, достаточно долго. Соответственно, наибольший приоритет был отдан обновлению FDD-описаний тех файловых форматов, которые были отмечены в качестве предпочтительных или допустимых, и существенно не обновлялись более 10 лет. При наличии в общей сложности более чем 500 FDD-описаний (число которых непрерывно увеличивается), подобные задержки неизбежны, что делает такого рода анализ ещё более важным.

Рисунок 3. Фрагмент электронной таблицы, используемой для отслеживания обновления наших FDD-описаний.

На сегодняшний день мы пересмотрели и обновили все FDD-описания для всех предпочтительных и допустимых форматов, которые ранее были обновлены более 5 лет назад. У нас также появились два новых младших научных сотрудника, Мари Эллисон (Mari Allison) и Дэн Хокштейн (Dan Hockstein), которые усердно выявляют неработающие ссылки на другие FDD-описания. Подробнее об их работе мы расскажем в следующем посте серии.

Когда мы пересматривали эти FDD-документы, мы не только искали (как уже упоминалось) неработающие ссылки и опечатки, но и стремились отследить связи с более новыми версиями и подтипами, а также изменения в плане внедрения и использования. Мы также добавили ссылки на уникальные идентификаторы PRONOM (PUID) и идентификаторы в Викиданных (Wikidata ID, QID), когда соответствующие данные были доступны, но не были задокументированы ранее. В некоторые из этих старых FDD-описаний мы добавили недостающие ссылки на спецификации (в дополнение к обновленным спецификациям). Данный всесторонний пересмотр побудил нас стандартизировать и задокументировать наши лучшие практики работы с FDD-описаниями, как обновленными, так и новыми, с тем, чтобы в целом обеспечить большую согласованность. Эта стандартизация поможет нам при извлечении данных из FDD-описаний для использования в других проектах.

Возможно, Вы помните, что в предыдущем посте ( https://blogs.loc.gov/thesignal/2021/12/fun-with-file-formats/?loclr=blogsig ) мы упоминали о том, что мы ежемесячно запускаем Python-скрипт для отслеживания соответствия наших FDD-описаний и идентификаторов PUID и QID. Используя эти данные, мы обнаружили, что в ходе обновлений в рамках подготовки в предстоящему выпуску новой редакции «Заявления» в FDD были добавлены 12 QID и 4 PUID, которые ранее не были указаны. Данное число, безусловно, будет расти по мере продвижения этого проекта.

Опираясь на недавние успехи в сопоставлении с PUID-идентификаторами, группа Библиотеки Конгресса по работе с форматами также разрабатывает рабочий процесс для сопоставления наших FDD-описаний и взаимосвязанных данных о форматах (включая задокументированные расширения и названия файловых форматов) с файлами DROID-сигнатур в системе PRONOM ( https://www.nationalarchives.gov.uk/aboutapps/pronom/droid-signature-files.htm ). Эти файлы сигнатур генерируются в PRONOM и используются программным обеспечением DROID для идентификации и анализа файловых форматов. Поскольку файлы сигнатур представлены в формате XML, мы воспользовались возможностью применить наши навыки написания скриптов для извлечения и анализа данных из этих файлов сигнатур и сопоставления их с нашими собственными FDD-описаниями. Сейчас с помощью этого скрипта мы можем идентифицировать отсутствующие расширения и PUID-идентификаторы, которые можно добавить, чтобы сделать наши FDD-описания более надёжными.

Сопоставление файловых форматов платформы Stacks

Поскольку всей нашей работы над новыми категориями контента и FDD-описаниями было недостаточно, мы организовали проект по анализу и пересмотру файловых форматов, перечисленных на платформе «Стеллажи» (Stacks) Библиотеки Конгреса. Наши онлайн-пользователи могут быть знакомы с контентом ограниченного доступа из читальных залов Библиотеки Конгресса. Платформа Stacks поддерживает группировку по типу данных ( https://www.iana.org/assignments/media-types/media-types.xhtml?loclr=blogsig ), однако отображаемые имена форматов не всегда были полезными для наших пользователей - если только Вы не хотите вести поиск по типу файла “application/vnd.openxmlformats-officedocument.wordprocessingml.document” или аналогичному. Группа по работе с форматами знала, что здесь возможны улучшения.

Рисунок 4. Прежний список типов файлов в Stacks, с указанием в скобках новых меток Stacks.

Начиная со списка меток типов файлов в Stacks, мы использовали такие ресурсы, как ресурсы Администрации адресного пространства Интернета IANA (Internet Assigned Numbers Authority, https://www.iana.org/assignments/media-types/media-types.xhtml ), ведущей реестр типов данных (media types); и списки MIME-типов от Mozilla ( https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types ), чтобы идентифицировать эти загадочные (а иногда и не такие уж загадочные) метки. Во время работы со списком и создания новых меток мы помнили о пользователях, и использовали метки, который с большой вероятностью будет легко понять и узнать. Для тех меток, которые часто идентифицируются по аббревиатуре - от PDF до ELF - мы решили использовать полное имя только для необычных форматов. Так что в этом случае всем известный формат CSV останется именно CSV.

Рисунок 5. Прежний список типов файлов в Stacks

В конечном итоге, мы обновили метки для 62 типов данных в Stacks и предоставили пользователям гораздо более интуитивно понятный интерфейс поиска. В рамках этого проекта мы также разработали правила форматирования меток и написали документацию по извлечению помечающих формат данных, по изучению соответствующих меток и представлению этих изменений группе, поддерживающей платформу Stacks. Когда мы в будущем снова вернёмся к этому проекту, мы будем лучше к нему готовы, располагая стандартами и практиками, освоенными на этом пути.

Наша группа по работе с форматами, безусловно, проделала большую работу, поэтому мы рады поделиться этими обновлениями с нашей фанатской базой любителей файловых форматов. Комментарии и вопросы всегда приветствуются, присылайте их по адресу formats@loc.gov .

Кейт Мюррей (Kate Murray), Маркус Напье (Marcus Nappier) и Лиз Холдзком (Liz Holdzkom)

Источник: блог «Сигнал» (The Signal) на сайте Библиотеки Конгресса США
https://blogs.loc.gov/thesignal/2022/06/return-to-the-fascinating-world-of-file-formats/