Хмл в человекочитаемом формате: Конвертер выписки Росреестра из xml в pdf (печатное представление)

Роберт П.Milius

¹ Национальная программа доноров костного мозга, Миннесота, США

Michael Heuer

¹ Национальная программа доноров костного мозга, Миннесота, США

Daniel Valiga

¹ Национальная программа доноров костного мозга, Миннесота США

Кэтрин Дж.

¹ Национальная программа доноров костного мозга, Миннесота США

Калеб Дж. Кеннеди

¹ Национальная программа доноров костного мозга, Миннесота США

Юнг-Ци Болон

¹ Национальная программа доноров костного мозга, Миннесота США

Джоэл Шнайдер

¹ Национальная программа доноров костного мозга, Миннесота, США

Джейн Поллак

¹ Национальная программа доноров костного мозга, Миннесота, США

Хва Ран Ким

² HistoGenetics LLC, США

Nezih Cere

² HistoGenetics LLC, США

Джилл А.Холленбах

³ Калифорнийский университет — Сан-Франциско

Стивен Дж. Мак

⁴ Детская больница и исследовательский центр Окленд, Окленд, Калифорния, США

Мартин Майерс

¹ Национальная программа донорства костного мозга, Миннесота США

¹ Национальная программа доноров костного мозга, Миннесота США

² HistoGenetics LLC, США

³ Калифорнийский университет — Сан-Франциско

⁴ Детский госпиталь и исследовательский центр Окленд, Окленд, Калифорния, США

Abstract

Мы представляем электронный формат для обмена данными для генотипирования HLA и KIR с расширениями для секвенирования следующего поколения (NGS). Этот формат направлен на обмен данными NGS путем доработки языка разметки гистоиммуногенетики (HML) в соответствии с предлагаемыми руководящими принципами по отчетности по иммуногеномному генотипированию NGS (MIRING) по минимальной информации (miring.Immunogenomics.org). Наши усовершенствования HML включают два основных дополнения. Во-первых, NGS поддерживается новыми структурами XML для захвата дополнительных данных NGS и метаданных, необходимых для получения результата генотипирования, включая зависимые от анализа (динамические) и зависимые от метода (статические) компоненты. Полный генотип, согласованная последовательность и окружающие метаданные включаются напрямую, в то время как чтение исходной последовательности и документация по платформе имеют внешние ссылки. Во-вторых, неоднозначность генотипа полностью представлена ​​путем интеграции строк списка генотипов, в которых используется иерархический набор разделителей для полного и точного представления неоднозначности аллелей и генотипов.HML также продолжает обеспечивать передачу унаследованных методов (например, сайт-специфический олигонуклеотид, последовательностное праймирование и типирование на основе последовательностей (SBT)), добавляя такие функции, как возможность использования нескольких праймеров для секвенирования, специфичных для группы, и полностью используя методы, сочетающие несколько методы для получения единого результата, такие как SBT, интегрированный с NGS.

Ключевые слова: HML, NGS, HLA, KIR, MIRING, стандарты данных, генотипирование

1. Введение

Генотипирование лейкоцитарного антигена человека (HLA) является фундаментальным для исследований и клинической практики в области иммуногенетики и гистосовместимости. Методы получения этой информации резко улучшились за последние три десятилетия, от новаторских серологических методов до современных методов генотипирования на основе ДНК [1], что со временем выявило, казалось бы, нескончаемое расширение разнообразия аллелей [2], и представило последующую проблему: переосмысление ранее полученных результатов в свете новых знаний [3–6]. Становится все более очевидным, что для того, чтобы результаты были максимально «ориентированы на будущее», необходимы стандарты данных для регистрации и представления этих результатов, которые включают не только присвоение аллелей, но и метаданные (данные, описывающие другие данные). окружающие лабораторные методы и правила присвоения аллелей [5,7].

Новое поколение методов секвенирования усложнило эту задачу. Эти методы характеризуются массово-параллельными технологиями, ведущими к высокопроизводительному секвенированию, что позволяет выполнять рутинный опрос не только выбранных областей гена, но также секвенирование всего экзона или целого гена. Хотя эти технологии, широко известные как секвенирование следующего поколения (NGS), существуют уже несколько лет, их применение к HLA было проблематичным из-за высокой степени аллельного полиморфизма, отсутствия надежных эталонных геномных выравниваний для области MHC и сложные метаданные, необходимые для присвоения аллелей и последующей интерпретации в качестве эталонных последовательностей, уточняются и расширяются.Эти соображения подчеркивают необходимость регистрации и представления полных метаданных, относящихся к сбору данных, и, в частности, для обработки и интерпретации данных.

Недавно группа заинтересованных сторон в области гистосовместимости и иммуногенетики, включая клиницистов, исследователей, производителей инструментов и разработчиков программного обеспечения, собралась на серию встреч, чтобы разработать стандарты для регистрации и представления данных о генотипировании HLA на основе NGS [8]. Одна из целей этих встреч состояла в том, чтобы определить минимальный объем информации для сообщения об иммуногеномном NGS-генотипировании (MIRING) [9] на основе принципов руководства по представлению минимальной информации для биологических и биомедицинских исследований (MIBBI) [10]. MIRING определяет восемь принципов отчетности по генотипированию данных иммуногеномики на основе NGS. Хотя MIRING предоставляет принципы и рекомендации, он не предоставляет технических спецификаций.

Чтобы разработать техническую спецификацию, отвечающую этим принципам, мы расширили язык гистоиммуногенетической разметки (HML) [11]. HML — это формат электронных сообщений, основанный на XML и разработанный как стандарт сообщества, позволяющий явное представление результатов генотипирования для полиморфных иммуногенетических генных систем, таких как HLA и KIR.Первичные данные в виде последовательностей последовательностей специфического олигонуклеотида (SSO) / специфичного к последовательности праймера (SSP) и последовательностей типирования (SBT) могут быть связаны с присвоением аллелей на основе номенклатуры. Основная цель HML — сообщение результатов генотипирования. Благодаря использованию структурированных данных он может информировать тех, кто отправляет и получает эти данные, об их требованиях к их хранению и управлению. Расширяя HML, мы добавили возможность включения отчетов о генотипировании на основе NGS, включая метаданные, окружающие первичные данные и методы сбора, согласованные последовательности, вызов вариантов, включая новые полиморфизмы, и отчет о полной неоднозначности аллелей и генотипов с помощью списка генотипов (GL ) Струны [12].

2. Методы

Разработкой HML 1.0 руководила Национальная программа доноров костного мозга (NMDP) посредством серии встреч и обсуждений с Группой стандартов формата данных обмена информацией HLA, а затем с Консорциумом данных иммуногеномных NGS [8 ], сообщество реестров, клинических и исследовательских лабораторий и отраслевых партнеров сосредоточило внимание на выявлении и выполнении конкретных требований к отчетности для генотипирования на основе NGS и происходило параллельно с разработкой MIRING.

В сентябре 2014 года сообщество заинтересованных сторон, включая исследователей, клиницистов, разработчиков программного обеспечения, поставщиков платформ для секвенирования, разработчиков и администраторов баз данных последовательностей HLA и KIR, ИТ-специалистов реестров и донорских центров, а также вспомогательный персонал лабораторий собралось для участия в хакатоне по стандартам данных ( DaSH) [13] для разработки новых способов обмена данными NGS для HLA и KIR. Во время этого мероприятия текущее состояние HML было проверено сообществом, и в то же время MIRING был доработан.Эти упражнения привели к новым существенным требованиям к окончательной спецификации для HML 1.0, которая содержит все функциональные возможности более ранних версий, таких как HML 0.3.3, но с дополнительными возможностями, позволяющими добавлять информацию, требуемую принципами MIRING.

Для разработки схем XML для HML был использован подход быстрого прототипирования. Гибкий подход, при котором по мере разработки схем были созданы примеры сообщений с различными сценариями генотипирования HLA и KIR и синтаксически подтверждены с использованием инструментов автоматической проверки.Схему и примеры можно найти на https://bioinformatics.bethematchclinical.org/HLA-Resources/HML/.

При разработке HML важно было учесть использование указателей на внешние ссылки и наборы данных. Это позволяет пользователям повторно использовать ранее зарегистрированные метаданные и ссылаться на наборы данных, которые нецелесообразно включать в сообщение HML. К ним относятся зарегистрированные методологии, эталонные последовательности и считывания необработанных последовательностей. Использование указателей на внешние источники является практической необходимостью, учитывая большой размер большей части этих данных.Лица, отвечающие за поддержание этих ресурсов, должны четко представлять себе уровень обслуживания, которого пользователи могут ожидать, а также ожидания в отношении их постоянной доступности.

3. Результаты

HML 1.0 сохраняет общую структуру, аналогичную предыдущим версиям, но с заметными изменениями. Как и в более ранних версиях, представление первичных данных отделено от присвоения аллелей. NGS поддерживается новыми структурами XML для захвата всех данных и метаданных NGS, необходимых для получения результата генотипирования, включая зависимые от анализа (динамические) и зависимые от метода (статические) компоненты.Указатели на внешние расположения относятся к зарегистрированным методам, необработанным чтениям NGS и эталонным стандартам. Отдельный компонент, описывающий согласованные последовательности и варианты, был создан специально для размещения данных NGS, но при желании может быть использован для других методологий. Этот компонент включает метаданные, описывающие согласованные последовательности, такие как последовательности ссылок, информацию о фазах, ожидаемое количество копий, непрерывность блока последовательности и другие метаданные. Отчетность о присвоении аллелей с полной генотипической и аллельной неоднозначностью достигается за счет использования строк GL.

Общая структура HML 1.0 представлена ​​в. Сообщение HML состоит из четырех основных разделов: заголовок документа, методы набора текста, присвоение аллелей и согласованная последовательность. Сообщение HML будет содержать метаданные документа и данные, описывающие один или несколько образцов, сгенерированных одним или несколькими методами типизации для одного или нескольких семейств генов.

В дополнение к нескольким незначительным улучшениям и множеству других компонентов, оставшихся для сохранения обратной совместимости, в HML 1 были внесены два основных улучшения. 0. Во-первых, были добавлены новые элементы, соответствующие руководящим принципам отчетности MIRING. Во-вторых, были добавлены строки GL, чтобы обеспечить выражение полной аллельной и генотипической неоднозначности в дополнение к кодам аллелей NMDP и, в конечном итоге, вместо них. Хотя ожидается, что NGS приведет к однозначному назначению аллелей посредством полного секвенирования генов, более ранние методологии будут по-прежнему использоваться и сообщаться в HML 1.0, а в ближайшем будущем генотипирование на основе NGS может быть ограничено некоторыми лабораториями для исследования конкретных экзонов, что приведет к неоднозначность аллелей и генотипов.Дополнительные изменения включают усовершенствования типирования на основе последовательностей Сэнгера (SBTSanger), внешние ссылки на информацию о типовых наборах и расширения для включения нескольких семейств генов (например, HLA, KIR).

В приведенной ниже спецификации обратите внимание, что объявленные имена элементов и атрибутов выделены шрифтом Courier, чтобы подчеркнуть их абстрактный характер.

3.1. Заголовок HML

Подробная информация о заголовке представлена ​​в. Здесь сообщение контекстуализировано, предоставляя такие детали, как идентификация лаборатории, отправившей сообщение, идентификатор отчета, образец (образцы), описываемый в отчете, и другую справочную информацию.Этот заголовок не содержит подробностей о каком-либо конкретном тесте, а только о контексте, в котором он произошел.

3.1.1. hmlid

Уникальный идентификатор документа HML может быть включен через элемент hmlid . Hmlid следует соглашению HL7 для идентификаторов экземпляров, использующих ключ из двух частей [14]. Идентификатор объекта ISO (OID) [15] может быть предоставлен через корневой атрибут и часто представляет собой уникальный идентификатор организации, публично зарегистрированный для организации.Атрибут расширения содержит уникальный идентификатор документа, управляемый внутри отчитывающейся организации. Вместе атрибуты root и extension объединяются, чтобы обеспечить глобальный уникальный идентификатор.

В качестве альтернативы ISO OID может быть расширен напрямую с помощью расширения в корне или универсальный уникальный идентификатор (UUID), также известный как глобальный уникальный идентификатор (GUID), может быть предоставлен в корне без расширения .Примеры этих различных способов использования hmlid можно найти в.

Примеры использования hmlid

3.1.2. report-center

Элемент reporting-center идентифицирует объект / организацию, отправляющую сообщение HML. Если он включен, он должен содержать уникальный идентификатор центра отчетов , идентифицирующий отправителя. Добавлен новый атрибут reporting-center-context . Это используется для сообщения о контексте / полномочиях именования идентификатора.Это может использоваться различными организациями для идентификации отчитывающейся организации с использованием зарегистрированной контактной информации. Например, хотя этот элемент является необязательным, для протокола NMDP требуется элемент report-center в рабочем контексте. Если контекст-центра-отчетов не включен, предполагается, что это "NMDP" и является уникальным идентификатором, зарегистрированным в NMDP. Другой пример использования этого элемента - ссылка на испытательную лабораторию, зарегистрированную в NCBI Genetic Testing Registry (GTR) [16] через GTR Lab ID.показывает примеры того, как можно использовать идентификатор центра отчетов.

Примеры использования центра отчетов

3.1.3. typing-test-names

Элемент typing-test-names определяет список имен тестов, на которые внутренне ссылаются методы ввода SSO или SSP. Он содержит атрибут test-id , связанный с одним или несколькими typing-test-name , содержащий идентификаторы тестов, которые вместе используются для определения набора для набора текста. Он включает в себя список из элементов typing-test-name , содержащих идентификаторы теста. test-id затем используется в качестве идентификатора внутренней ссылки, который будет использоваться в разделах методов ввода SSO и SSP.

3.1.4. sample

HML-сообщение содержит один или несколько элементов sample , содержащих данные генотипирования, относящиеся к конкретному образцу. Атрибуты id и код центра идентифицируют образец и организацию, из которой был получен образец (например, центр трансплантологии или донорский центр) соответственно. Несколько образцов от одного и того же человека или разных людей могут быть включены в одно сообщение HML.Элемент метода сбора может использоваться для идентификации того, как был взят образец, например, тампон, фильтровальная бумага, аликвота крови. Каждый образец может быть связан с несколькими элементами , типизирующими .

3.1.4.1. typing

Элемент typing инкапсулирует первичные данные из метода генотипирования с результатом генотипирования ( аллель-присвоение ), который был определен на основе первичных данных ( typing-method ) и / или согласованных последовательностей ( консенсус- последовательность ). Атрибут семейства генов используется для ограничения типизации фамилией гена, признанной Комитетом по номенклатуре генов HUGO [17] (например, HLA, KIR).

3.2. Метод генотипирования и первичные данные

описывает метод типирования и первичные элементы данных. Здесь сообщается о методе, использованном для выполнения генотипирования, и о первичных неинтерпретированных результатах этого метода. Это может быть один из вариантов SSO, SSP, SBT-Sanger или SBT-NGS.

Методы набора и первичные данные

3.2.1. Идентификаторы тестов и локус

Для соответствия требованиям MIRING доступны три новых атрибута, ссылающихся на дополнительные метаданные, для более полного описания метода и локуса, нацеленных на каждый метод ввода. Два из этих атрибутов называют тестового регистратора ( test-id-source ) и идентификатор ( test-id ), который может быть разыменован через регистратора. В предыдущих версиях HML элементы sso и ssp ссылались на тестовую информацию в элементе test-id , находящемся в заголовке, который используется для инкапсуляции методов тестирования, состоящих из одного или нескольких отдельных тестов или наборов датчиков в пределах Документ HML. Эти новые атрибуты позволяют лабораториям регистрировать свои методы тестирования во внешних регистраторах тестирования, таких как NCBI GTR [16].

Третий новый атрибут для каждого элемента метода ввода - это , локус , который указывает цель метода ввода. locus - необязательный атрибут. Если присутствует, это должно быть имя гена, признанное Комитетом по номенклатуре генов HUGO [17], например, HLA-A, HLA-DRB1, KIR2DL1.

3.2.2. sso & ssp

Элементы sso и ssp описывают методы генотипирования SSO и SSP соответственно.Эти элементы не изменились по сравнению с предыдущими версиями HML, за исключением добавления атрибутов test-id, test-id-source и locus (см. Выше). Для представлений в NMDP ожидается соответствующая структура typing-test-names / typing-test-name , найденная в заголовке.

3.2.3. sbt-sanger

Элемент sbt (типизация на основе последовательности), обнаруженный в предыдущих версиях HML, был переименован в sbt-sanger . Это отражает признание того, что методы типирования Сэнгера и NGS основаны на последовательностях, но с различиями в метаданных, необходимых для их поддержки.Другие изменения включают дополнительный дочерний элемент для поддержки праймеров и результатов субамплификации. Эти праймеры используются для устранения неоднозначности и могут использоваться либо одновременно с этапом амплификации, либо после него. Кроме того, теперь разрешены множественные элементы GSSP (праймеры для группового секвенирования), описывающие последовательности праймеров ПЦР, используемые для амплификации полиморфных областей последовательностей. В предыдущих версиях HML был разрешен только один GSSP .

3.2.4.sbt-ngs

Новый элемент sbt-ngs описывает типирование на основе последовательностей с использованием высокопроизводительных методов, также известных как NGS (секвенирование следующего поколения). Как и в случае с другими методами, атрибуты test-id, test-id-source и locus описывают метод и целевой локус теста. Каждый sbt-ngs может содержать несколько дочерних элементов raw-reads.

Элемент raw-reads ссылается на необработанные чтения последовательности, сгенерированные платформой NGS.Эти данные могут быть довольно большими даже для относительно небольших участков генома. Из-за этого, если предоставляются необработанных считываний , эта информация не встроена напрямую в документ HML, а вместо этого указывается через атрибут uri (унифицированный идентификатор ресурса), который указывает на внешнее расположение и формат . Атрибут , который описывает, как хранятся данные (например, архив чтения последовательности NCBI (SRA)). Другие атрибуты включают доступность необработанных чтений (общедоступных, частных или с разрешением) и метаданные обработки, указывающие, объединены ли данные в пул ( объединены, ), если адаптеры были обрезаны ( adapterTrimmed ) или были ли обрезаны низкокачественные последовательности ( qualityTrimmed ).

3.3. Назначение аллелей

описывает раздел «Назначение аллелей». Здесь были внесены некоторые изменения по сравнению с предыдущими версиями HML. Элемент, который ранее назывался интерпретация , теперь переименован в аллель-присвоение , чтобы более точно отразить его назначение. Кроме того, этот элемент включает в себя новые атрибуты, которые описывают базу данных аллелей или другой источник номенклатуры (аллель db , например, база данных IMGT-HLA) и версию выпуска базы данных (версия аллеля , e.g., 3.19.0), который использовался для определения аллелей.

О присвоении аллелей можно сообщать в трех различных форматах. Как и в предыдущих версиях HML, доступны и без изменений гаплоидных и элементов списка генотипов . Был добавлен новый третий элемент, представляющий строки списка генотипов (GL) ( glstring ), который позволяет назначать аллели с полным генотипом и неоднозначностью аллелей [12]. Строка GL может быть включена напрямую, или идентификатор ресурса URI, указывающий на службу, которая предоставляет Строку GL (e.g., https://gl.nmdp.org). Пример того, как можно сообщить о строке GL, можно увидеть в.

Пример того, как определение аллелей может использоваться с glstring

3.4. Последовательность согласования

описывает раздел «Последовательность согласования». Это новая структура в HML, которая была создана для обеспечения результата выравнивания или сборки более коротких считываний последовательностей, генерируемых платформой NGS. Это зависит от ряда динамических факторов, таких как конвейер обработки, включая программное обеспечение и входные данные, а также ссылочные последовательности, используемые для выравнивания.Это не считается первичными данными, а скорее как разновидность интерпретации. По этой причине он не включен в раздел о методах набора текста, а рассматривается отдельно. Хотя этот раздел был создан с учетом NGS, при желании он может использоваться другими методами типизации на основе последовательностей.

Этот раздел в значительной степени основан на многих элементах данных, найденных в Variant Call Format (VCF) [18] и метаданных, определенных из MIRING [9]. Примечание. HML использует атрибуты начало и конец с системой координат с отсчетом от 0 с закрытыми-открытыми диапазонами, i.е. диапазон включает позицию начало , но исключает позицию конца . Это соглашение используется во многих моделях геномных данных (например, в схемах Global Alliance for Genomics and Health [19,20], браузере UCSC [21], файлах BED) из-за его преимуществ программирования. Напротив, спецификация VCF индексирует 1-е основание, имеющее позицию 1.

Последовательность сообщается непосредственно через элемент последовательности . Также может быть включен указатель на внешнюю ссылку или как вариант ссылочной последовательности.Если сообщается о варианте, структура предоставляет метод для отчета о влиянии варианта. Также могут быть записаны значения качества, зависящие от местоположения.

3.4.1. reference-database & reference-sequence

Вместе элементы reference-database и reference-sequence описывают базу данных, содержащую эталонную последовательность, используемую в блоках согласованной последовательности . Справочная база данных может указывать на построения полных геномов (например, Genome Reference Consortium), базы данных аллелей (e.g., IMGT-HLA Database) или другую базу данных, содержащую последовательности, которые используются в качестве ссылки (например, GenBank, EMBL-ENA). Метаданные, окружающие справочную базу данных , включают имя, описание, версию, ее доступность, независимо от того, курируется ли база данных, и URI, указывающий на ее внешнее расположение. В случае, когда используется сборка de novo, а не выравнивание по ссылке, доступность устанавливается на none .

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

Примеры использования эталонной базы данных и эталонной последовательности можно найти в.

Примеры использования справочной базы данных и справочной последовательности

3.4.2. блок консенсусной последовательности

Блок консенсусной последовательности инкапсулирует последовательность ДНК, состоящую из нуклеотидов IUPAC [22] и вариантов, против эталонной последовательности, если точное совпадение не найдено, и связанных метаданных. Требуется идентификатор эталонной последовательности , который указывает на эталонную последовательность , найденную в документе HML. Начальная и конечная позиции определяют целевую область на ссылке. Другие необязательные метаданные предоставляются через атрибуты, которые описывают идентифицируемую цепочку, описание целевой области (например,g., «экзон 3 HLA-A»), идентификатор набора фаз для связывания различных блоков согласованной последовательности , флаг непрерывности, чтобы указать, существует ли разрыв между блоками, и число ожидаемых копий, чтобы указать, сколько копии блока последовательности ожидались.

Оценка качества для позиций в согласованной последовательности может быть зафиксирована в элементе качество последовательности с использованием атрибутов start и end , указывающих интересующую область. Метрики качества для качества последовательностей различаются в зависимости от платформы, отражая различия в химии секвенирования и цифровой обработке.Дополнительные показатели, такие как глубина охвата на уровне последовательности и варианта (см. Ниже), не имеют общих стандартов и могут быть рассчитаны по-разному в зависимости от выбранного аналитического метода. По этим причинам отчетность по качеству HML не требует строгих критериев спецификации.

3.4.3. Вариант и вариант-эффект

Элемент вариант должен быть включен, если последовательность не полностью соответствует эталонной последовательности . Типичное использование этого элемента - описание нового аллеля.Доступные атрибуты для варианта соответствуют многим элементам данных, используемым в файлах VCF [18] и в MIRING. Атрибут id используется для однозначной идентификации варианта в документе HML. Начало и конец определяют координаты опорной последовательности, в которой встречается вариант. Нуклеотиды, обнаруженные в этой области ссылки, и то, чем они заменяются, идентифицируются с атрибутами reference-base и alternate-base соответственно.

Об альтернативной внешней ссылке для варианта можно сообщить с помощью атрибута uri . Это может быть место для файла VCF или альтернативный формат, представляющий ту же информацию.

Дочерний элемент вариант , элемент вариант-эффект сообщает о влиянии этого варианта. Эффект или эффекты должны быть описаны с использованием терминов эффекта варианта Sequence Ontology (SO) [23] (например, missense_variant, stop_gained, downstream_gene_variant).Дополнительные атрибуты могут использоваться для предоставления дополнительной информации о влиянии, например, серьезность, прогноз POLYPHEN, оценка SIFT [24,25]. В дополнение к термину может быть включена строка номенклатуры Общества вариаций генома человека (HGVS) [26,27]. uri может использоваться для обеспечения внешней ссылки для этого варианта эффекта.

Такое использование элементов вариант и вариант с эффектом естественно применимо к ссылочным управляемым узлам. В случае сборки de novo, где ссылка не используется, связывание эффекта варианта в этой схеме затруднено, если только для этой цели явно не используются ссылочная база данных и ссылочные аллели.

Пример того, как могут быть захвачены варианты, можно увидеть в.

Пример блока консенсус-последовательности с вариантами

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

HML обеспечивает расширяемость с использованием двух методов. Один из них заключается в использовании элемента свойства , который был введен в качестве необязательного дочернего элемента для нескольких узлов ( hml, образец, типизация, типы типа typeing-method и аллель-присвоение ). Здесь могут быть введены пары имя / значение (совместно определенные и согласованные создателем и потребителем документа HML).Кроме того, элементы свойства могут содержать настраиваемые вложенные структуры, выбранные создателем для добавления дополнительной информации и подробностей во включающий элемент. Другой метод расширения спецификации HML заключается в использовании типа anyAttribute , связанного с « консенсус-последовательность-блок », « последовательность », « вариант » и « вариант-эффект ». "элементы, допускающие дополнительные атрибуты, не указанные в схеме.

4. Обсуждение

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

4.1. MIRING

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

Элементы MIRING и соответствующие примеры решений в HML 1.0 представлены в. В некоторых случаях MIRING предлагает технические решения, касающиеся того, как могут быть рассмотрены конкретные элементы, но они переводятся в различные решения в HML. Например, дескриптор, разделенный вертикальной чертой, найденный в MIRING, необходим для файлов FASTA. Часто та же самая информация находится в структуре XML HML и может не требоваться явно.Например, в HML блоки согласованной последовательности захватываются последовательно, и каждый блок содержит в себе всю соответствующую информацию в атрибутах и ​​дочерних элементах. Из-за этого отдельный идентификатор для блока согласованной последовательности для связывания последовательностей с согласованными последовательностями, ссылочных последовательностей, вариантов и связанных метаданных не требуется.

Таблица 1

Сопоставление элементов MIRING с решениями HML

<центр отчетов
   Reporting-center-id = "000000"
   Reporting-center-context = "NCBI-GTR" />
 

<аллель-присвоение…
  аллель-db = "IMGT-HLADB"
  allele-version = "3.19.0">
  … 
  
 

<справочная база данных>
  <ссылочная последовательность… />
  <ссылочная последовательность… />

 

<ссылочная последовательность
 
  name = "HSCHR6_MHC_MCF_CTG1"
  start = "0"
  end = "4827813"
  accession = "CCDS34373.12"
  uri = "http://www.ncbi.nlm.nih.gov/nuccore/GL000254.2" />
 

<справочная-база данных…
   public = "true"
   curated = "true"
   … \>
 

   HLA-DPB1 * 02: 01: 02 + HLA-DPB1 * 03: 01: 01

 

   HLA-DPB1 * 02: 01: 02 + HLA-DPB1 * 03: 01: 01

 

<блок-последовательность-консенсус… />
  … 
  <вариант…>
    

 

<последовательность-согласование>
 <блок-последовательность-консенсус…>
 … 
 <блок-последовательность-консенсус…>
 … 

 

…

 

<ожидаемый-номер-копии-консенсуса-последовательности-блока = "1"…>…

 

<блок-последовательность-консенсус…>
  … 

 

<блок-последовательность-консенсус…>
  … 
  <вариант…>… 

 

<аллель-присвоение…
  аллель-db = "IMGT-HLADB"
  allele-version = "3.19.0">
  … 
   

<справочная база данных>
  <ссылочная последовательность… />
  <ссылочная последовательность… />

 

4.2. Проверка

HML 1.0 завершена, а схему и примеры XML можно найти на https: // bioinformatics.bethematchclinical.org/HLA-Resources/HML/. Отчетность о генотипировании HLA и KIR на основе NGS в соответствии с принципами MIRING возможна с использованием комбинации HML и инструментов семантической и синтаксической проверки, которые в настоящее время разрабатываются. Синтаксически правильный отчет о генотипировании HML может не соответствовать специфическим бизнес-правилам организации для принятия или соответствия руководящим принципам отчетности, таким как MIRING. С другой стороны, специфические для бизнеса HML-сообщения должны соответствовать определениям общедоступных схем XML (XSD) и подтверждаться ими.Прозрачная проверка поощряет основанный на стандартах подход к взаимному обмену данными для воспроизводимых исследований и клинического применения. Из-за этого необходимо будет разработать различные инструменты проверки в зависимости от вариантов использования и степени семантической проверки. Например, когда URI представлен для ссылки на внешние данные и метаданные, валидатору необходимо будет оценить, существует ли ссылка, и имеет ли информация, на которую она указывает, есть смысл и интерпретируема ли. Если HML расширяется за счет использования элементов свойства , и атрибутов anyAttribute , проверка еще больше усложняется, поскольку они в значительной степени игнорируются инструментами синтаксической проверки.Затем необходимо создать надежные инструменты проверки для этих особых случаев использования. Инструмент для проверки того, соответствует ли данный экземпляр сообщения HML требованиям MIRING, находится в стадии разработки.

4.3. Дальнейшая работа

HML 1.0 был разработан для удовлетворения потребностей сообщества иммуногеномиков. Однако мы осознаем необходимость взаимодействия с большим медицинским сообществом и возможность взаимодействия с системами EMR. В свете этого изучается возможность инкапсулировать HML в сообщения HL7 или клинические структурированные документы.

HML - это стандарт, созданный членами сообщества, перечисленными выше. Тем не менее, NMDP обязуется использовать стандарты, разработанные и поддерживаемые другими сторонами, когда это возможно. HL7 - это международная организация по разработке стандартов, которая занимается обменом медицинскими данными. Мы исследуем полезность OID (упомянутых выше) в качестве уникальных идентификаторов, а также форматов обмена HL7, таких как Архитектура клинических документов (CDA) и Fast Healthcare Interoperability Resources (FHIR), для инкапсуляции HML.Существует активное сообщество, разрабатывающее эти стандарты, которое обслуживает более широкую аудиторию, чем стороны, перечисленные в этом документе. Мы активно взаимодействуем с Рабочей группой по клинической геномике HL7, чтобы гарантировать, что содержимое, содержащееся в спецификации HML 1.0, может содержаться в сообщении HL7. Это позволит сторонам, перечисленным здесь, использовать стандарты, разработанные и внедренные сообществом HL7. HL7 также является участником Интегрированной доменной группы биомедицинских исследований (BRIDG) в качестве члена консорциума, включая FDA, CDISC и NCI.Члены BRIDG разрабатывают артефакты, чтобы помочь в обмене протоколами, основанными на исследованиях, и их регуляторными артефактами, а также в обмене данными молекулярного тестирования в рамках LSDAM (модели анализа предметной области в области наук о жизни). Поскольку модель HML 1.0 по своей сути является инкапсулированием результатов молекулярного теста, мы также хотим использовать работу этих сторон.

Для поддержки HML 1.0 разрабатываются служебные инструменты для проверки и поддержки в конвейере NGS (например,г., https://github.com/nmdp-bioinformatics/ngs). Это включает проверку командной строки HML, а также других инструментов конвейера NGS. Документацию по этой разработке окружающего HML можно найти по адресу http://nmdp-bioinformatics.github.io/ngs/apidocs/org/nmdp/ngs/hml/package-summary.html.

Благодарности

Эта работа была поддержана грантом Управления военно-морских исследований (ONR) N00014-12-1-0142 (MM и RPM), грантом Национального института здравоохранения (NIH) U01AI067068 (SJM и JAH), присужденным Национальным институтом здравоохранения США. Институт аллергии и инфекционных заболеваний (NIAID) и R01GM109030 (SJM, JAH, MM и RPM), награжденный Национальным институтом общих медицинских наук (NIGMS).Представленный контент является исключительной ответственностью авторов и не обязательно отражает официальную точку зрения NIH, NIAID, NIGMS, ONR, Департамента военно-морских исследований, Департамента военно-морского флота, Министерства обороны или правительства США. .

Сокращения

Footnotes

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

Конфликты интересов: Конфликты интересов отсутствуют.

Список литературы

Национальные центры экологической информации (NCEI)

Введение в метаданные

Международная организация по стандартизации (ISO)

Инструменты

Введение в метаданные

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

• Кто собирал данные?
• Кто обрабатывал данные? Кто написал метаданные?
• С кем мне обращаться по вопросам?
• С кем мне связаться, чтобы заказать данные?
• Кому принадлежат данные?

• О чем эти данные?
• Какой проект где собрали под?
• Какие ограничения на их использование?
• Какое качество?
• Какие варианты использования подходят?
• Какие параметры были измерены?
• В каком формате хранятся данные?

• Почему были собраны данные?

• Где были собраны данные?
• Где обрабатывались данные?
• Где находятся данные?

• Когда были собраны данные?
• Когда были обработаны данные?

• Как собирались данные?
• Как обрабатывались данные?
• Как мне получить доступ к данным?
• Как заказать данные?
• Сколько стоят данные?
• Как оценивалось качество данных?

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

• Облегчает поиск и анализ: Метаданные упрощают поиск данных, документ , преобразовать и сообщить.
• Улучшает управление данными: Следование стандартам метаданных делает возможным хорошее управление данными.
• Поддерживает интеграцию: Полная интеграция между пользователями, разработчиками программного обеспечения и распорядителями данных улучшает управление данными.
• Управление проектами: Предоставляет среду для интеграции и записи прогресса.
• Управление данными: Сохраняет итерации разработки данных для мониторинга состояния, оценок и необходимых изменений.
• Безопасность: Помогает обеспечить соблюдение нормативных требований и защитить данные.

Ведение метаданных

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

Руководство по обслуживанию метаданных

• Просмотрите содержимое и убедитесь, что все обновлено.
  1. Все ли ваши архивные фонды содержат метаданные?
  2. Актуален ли URL?
  3. Актуальны ли контакты, номера телефонов и электронная почта?
  4. Актуальны ли ключевые слова?
  5. Перемещает ли ссылка распределения пользователей на страницу доступа к данным?
  6. Орфография и грамматика проверены?
  7. Вы обновляли поле «Дата метаданных»?
• Насколько хорошо метаданные описывают ресурс?
  1. Насколько полны метаданные?
  2. Достаточно ли детализирован объем метаданных для описания ресурса?
  3. Качество записанных данных?
  4. Задокументированы ли входы, выходы, детали обработки и алгоритмы?
• Развивались ли стандарты метаданных и / или инструменты метаданных?
  1. Есть ли новые функции или новые инструменты, которые упрощают редактирование метаданных?
  2. Изменились ли стандарты и какие новые функции помогают лучше документировать данные?
• Взаимодействие:
  1. Существуют ли способы программного повторного использования содержимого метаданных?
  2. Есть ли на домашней странице данных ссылки на метаданные для получения дополнительной информации?
  3. Распространяются ли метаданные с пакетом загрузки данных?
• Связанные проекты и сообщества:
  1. Существуют ли другие проекты и сообщества, частью которых могут быть метаданные?
  2. Есть ли ожидания и рекомендации от проектов и сообществ?
  3. Совместимо ли содержимое метаданных с другими проектами и сообществами?

Обнаружение данных

Предпосылки и законодательство

11 апреля 1994 года президент Билл Клинтон подписал Указ 12906, которым была создана Национальная инфраструктура пространственных данных (NSDI) для поддержки применения геопространственных данных в транспорте в государственном и частном секторах. общинное развитие, сельское хозяйство, реагирование на чрезвычайные ситуации, управление окружающей средой и информационные технологии.Приказ 12906 также учредил электронный Национальный центр обмена геопространственными данными для NSDI, чтобы решать вопросы стандартизации данных, делать геопространственные данные общедоступными и решать проблемы избыточности и несовместимости.

19 августа 2002 года Управление управления и бюджета США (OMB) выпустило правительственный циркуляр (OMB Circular A-16), чтобы дать федеральным агентствам указания по созданию, поддержке или использованию пространственных данных прямо или косвенно путем создания NSDI и Федеральный комитет географических данных (FGDC).В циркуляре установлены руководящие принципы надлежащего использования цифровых пространственных данных и управления ими. В сентябре 2010 года Руководящий комитет FGDC одобрил 64 стандарта, не созданных на федеральном уровне, включая серию ISO 191 **. Политика FGDC гласит, что стандарты, не созданные на федеральном уровне, одобренные FGDC, имеют такой же статус, что и стандарты, разработанные FGDC (такие как CSDGM, BIO, RSE). Поскольку ISO 19115 и связанные с ним стандарты одобрены FGDC, федеральным агентствам рекомендуется перейти на метаданные ISO, поскольку их агентства могут это сделать.

Комитет по управлению экологическими данными (EDMC) координирует разработку стратегии и политики управления экологическими данными NOAA, а также предоставляет рекомендации по продвижению последовательной реализации в NOAA от имени Совета NOSC и CIO. Управление экологическими данными - это непрерывный процесс, который включает в себя сбор, контроль качества, проверку, повторную обработку, хранение, поиск, распространение и долгосрочное сохранение. Цель EDMC - позволить NOAA максимизировать ценность своих активов данных об окружающей среде с помощью надежных и скоординированных методов управления данными.

На странице Процедурной директивы NOAA Data Documentation представлена ​​подробная информация о деятельности, организации и инициативах EDMC.

Порталы

Данные

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

Службы доступа NCEI

Метаданные

Геопортал выполняет поиск в индексированных полях метаданных для всех заархивированных наборов данных, объединяя различные веб-службы обнаружения и метаданные в ориентированную на пользователя структуру.

Запустить геопортал

Другие правительственные порталы

Написание метаданных качества

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

Основы метаданных качества

Организуйте свою информацию

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

Следуйте стандартам метаданных

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

• Создатель метаданных
• Обработчик данных
• Поставщик доступа к данным

Важно правильно задокументировать эти роли и заранее изучить стандарт может помочь обеспечить точность и целостность вашего документа.

Используйте обычный язык

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

Следуйте шаблону или руководству по стилю

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

Примеры

• Всегда размещайте похожие ссылки в одном и том же месте в файлах метаданных, например, добавляя по крайней мере одно лицо или организацию в качестве цитируемого автора в элемент Cited Responsible Party.
• Отдать должное всем, кто работал над проектом.
• Используйте единый стиль и соглашения об именах для заголовков в вашей организации
• Соблюдайте единые правила использования заглавных букв и расстановки переносов

Используйте единообразную терминологию и соглашения об именах

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

Просмотр

Проверьте свой файл на точность и полноту. Добавьте любые детали или контекст, необходимые для обеспечения точного использования данных. Попросите кого-нибудь выполнить второй обзор.

Final Review

Прочтите файл еще раз на предмет опечаток, грамматических ошибок и ошибок форматирования перед публикацией.

Преобразования

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

Методы расширяемого языка разметки (XML) могут использоваться для упрощения управления метаданными за счет автоматизации преобразования форматов, внедрения стандартов и других этапов производственного цикла.

XML можно использовать для отображения схемы или модели исходных данных на целевую схему желаемого вывода. Сопоставление исходной схемы и целевой схемы определяет преобразование (расширение файла xslt).Затем преобразование применяется к исходному XML для создания желаемого вывода. Создание программных метаданных дает множество других преимуществ, таких как уменьшение усилий, согласованность, повышенная точность и повышенная эффективность.

Инструмент Metaserver и Oxygen XML могут преобразовывать записи из одного стандарта в другой. Перед преобразованием XML-документа в Oxygen XML Editor вам необходимо определить сценарий преобразования, который будет применяться к этому документу. Сценарий - это набор значений различных параметров, определяющих преобразование.Это не связано с конкретным документом, а скорее с типом документа. Oxygen XML Editor включает предварительно настроенные встроенные сценарии шаблонов преобразования, но также позволяет пользователям создавать собственные сценарии.

Схема

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

Техническая спецификация ISO 19139 предоставляет схемы расширяемого языка разметки (XML), улучшающие взаимодействие, предоставляя общую спецификацию для описания, проверки и обмена метаданными о географических наборах данных, сериях наборов данных, отдельных географических объектах, атрибутах объектов, типах объектов, свойствах объектов и т. Д.

В этот документ схемы встроены все основные стандарты ISO: 19115/19139 (базовый), 19115-2 (расширения) и 19119 (сервисный).

Проверка

Допустимый XML-документ соответствует правилам схемы, которая определяет его структуру.

В XML легко внести ошибки, особенно при работе над большими проектами с большим количеством файлов. Такие инструменты, как Oxygen, включают средства проверки ошибок, которые быстро и легко выявляют ошибки.

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

Сообщения об ошибках в Oxygen

1. Элемент

Сообщение об ошибке:
cvc-complex-type.2.3: Элемент 'gmd :organisationName' не может иметь персонажа [children],
потому что тип содержимого типа состоит только из элементов.
 

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

  недействительно: 
 Geoscience Australia (GA) 

  действительный: 

     Геонауки Австралия (Джорджия) 

 

2. Ожидаемое содержимое с http://www.opengis.net/gml/3.2

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

Эту ошибку можно исправить, изменив пространство имен gml с gml на gml / 3.2, обычно в корневом элементе документа.

  недействительно:
  xmlns: gml = "http://www.opengis.net/gml"
  действительный:
  xmlns: gml = "http://www.opengis.net/gml/3.2"
 

3. Содержимое элемента

  Описание:  cvc-complex-type.2.4.b: содержимое элемента gmd: CI_ResponsibleParty не является полным.
Ожидается один из "{" http://www.isotc211.org/2005/gmd":role} ".
 

Эта ошибка связана с отсутствием содержимого в объекте gmd: ResponsibileParty.Этому объекту требуется элемент роли, которого нет.

  недействительный: 

     ... 
     ... 


  действительный: 

     ... 
    ... 
    
         pointOfContact 
    

 

4. Обнаружен недопустимый контент

cvc-complex-type.2.4.a: Неверный контент был обнаружен, начиная с элемента someElement.
Ожидается один из '{someListOfElements}'.

Эта ошибка обычно связана с неправильным порядком элементов в записи. Даже правильный элемент может вызвать проблемы, если он находится в неправильном месте. Например:

   UTF8 


   eng 

дает эту ошибку, в то время как тот же контент в правильном порядке:

   eng 


   UTF8 
является действительным.

Эта ошибка также может указывать на отсутствие обязательного элемента.

cvc-complex-type.2.4.a: обнаружен недопустимый контент, начиная с элемента 'gmd: codeSpace'.
Один из "{" http://www.isotc211.org/2005/gmd":authority, http://www.isotc211.org/2005/gmd":code} "
ожидается.
 

Например, в gmd: RS_Identifier отсутствует требуемый элемент кода:

  недействительно: 

    
         имя местоположения 
    


  действительный: 

    
        Код  находится здесь 
    
    
         имя местоположения 
    

 

6.Недействительное значение для

cvc-datatype-valid.1.2.1: '' не является допустимым значением для 'decimal'
 

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

6.Множественные вхождения значения идентификатора

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

cvc-id.2: несколько вхождений значения идентификатора 'sourceTemporalExtent'

  недействительно: 

    
         состояние грунта 
         2004-02 
         2004-03 гг. 
    


    
         состояние грунта 
         2004-02 
         2004-03 гг. 
    


  действительный: 

    
         состояние грунта 
         2004-02 
         2004-03 гг. 
    


    
         состояние грунта 
         2004-02 
         2004-03 гг. 
    

 

7.Атрибут «codeListValue» должен присутствовать в элементе «gmd: CI_DateTypeCode»

При переводе с одного диалекта на другой иногда бывает трудно иметь дело с неизвестными значениями. Элемент в этом примере не имеет реального содержимого, но перевод включал элемент gmd: CI_DateTypeCode, который имеет обязательный атрибут: codeListValue. Решение в этом случае - заменить весь пустым тегом с атрибутом gco: nilReason.

  недействительный: 

  
    
    
      
    
  


  действительный: 

 

8.Недопустимый символ HTML: десятичный 146 или 148

Некоторые специальные символы (умные кавычки / апострофы) недопустимы в html, и таблицы стилей, в которых встречаются эти символы, покажут ошибку. Вы можете найти эти символы в xml, выполнив поиск по & # N; где N - 146 или 148, и используйте инструмент Oxygen Search and Replace in Files, чтобы заменить эти символы в наборе файлов.

Ресурсы

Шаблоны

WAF шаблона NCEI содержит шаблоны метаданных для различных типов данных, включая наборы данных на уровне гранул, события на уровне круиза, публикации, слои карты, сервисы и метаданные уровня сбора.

Шаблон метаданных уровня сбора NCEI предоставляет руководство по разделам для заполнения четырех разделов стандарта ISO 19115-2 и предоставляет минимальную базовую информацию для записей метаданных NCEI. Шаблон может содержать дополнительные разделы в стандарте ISO, другие поля, которые могут потребоваться другим стандартом, например, рубрику полноты NOAA, или другую информацию, относящуюся к конкретному набору данных.

Шаблон предназначен для сотрудников NCEI, которые непосредственно участвуют в управлении записями метаданных уровня сбора или для сотрудников, разрабатывающих инструменты для поддержки метаданных.

Рабочая тетрадь ISO

Рабочая тетрадь ISO была создана в качестве учебного пособия и руководства по внедрению, которое будет использоваться вместе с ISO 19115-2 Географическая информация ─ Метаданные, часть 2: Расширения для изображений и данных с координатной привязкой ISO 19115-2: 2009 (E ).

ISO Explorer

ISO Explorer - это всеобъемлющий веб-обозреватель ISO 19115 и 19115-2. На страницах показан правильный порядок элементов, ссылки на дочерний элемент / объект, обязательства, повторяемость и ссылки на дополнительную информацию и примеры.

Международная организация по стандартизации (ISO)

Что такое ISO

Международная организация по стандартизации (ISO) была основана в 1947 году и является крупнейшим в мире разработчиком добровольных международных стандартов. NCEI следует и внедряет стандарт метаданных ISO, как того требует:

• Административный приказ NOAA 212-15, который обеспечивает руководство высокого уровня для управления данными и информацией об окружающей среде.
• Директива по планированию документации данных Комитета по управлению экологическими данными (EDMC) NOAA, которая устанавливает ISO 19115, части 1 и 2, и рекомендуемый стандарт представления (ISO 19139) для документирования экологических данных и информации.

Геопространственные стандарты ISO

• ISO 19115 Географическая информация - метаданные: Стандарт ISO для документирования геопространственных данных.
• ISO 19115-2 Географическая информация - Метаданные - Часть 2: Расширения для изображений и данных с координатной привязкой : Расширение ISO 19115, используемое для документирования информации об изображениях, данных с координатной привязкой и данных дистанционного зондирования. Корень записей метаданных ISO 19115 изменится с MD_Metadata на MI_Metadata при использовании ISO 19115-2.
• ISO 19110 Географическая информация - Методология каталогизации функций: Отдельный стандарт и документ, на который можно ссылаться в ISO 19115, если необходимо.
• ISO 19111 Географическая информация - Пространственная привязка по координатам: Отдельный стандарт и документ, на который при необходимости можно ссылаться из ISO 19115.
• ISO 19139: Определяет XML-кодировку стандартов метаданных ISO, а также устанавливает структуру и правила для проверки.
• ISO 19115-1: Версия ISO 19115, которая определяет элементы и схемы метаданных, которые описывают геопространственные ресурсы, то есть наборы данных и сервисы.

Организация и содержание ISO

ISO использует диаграммы и таблицы Unified Model Language (UML) для описания стандарта. Схема производственных правил ISO 19115 определяет «MD_Metadata» и показывает отношения включения с другими классами метаданных. ISO организован в разделы и пакеты:

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

UML

Унифицированный язык моделирования (UML) используется для представления отношений между классами и объектами в объектно-ориентированном программировании.

Отношения могут быть представлены в моделях ISO UML как ассоциации, агрегаты, композиции, обобщения и зависимости.

• Связь: Общая связь между классами с предполагаемой двусторонней связью, если не указано иное. Стрелки отмечают конец линии, а также указывают направление ассоциации. Модель также покажет «роль» целевого объекта по отношению к исходному объекту.
• Агрегация: Когда один класс функционирует как «контейнер», а другой вложен внутри / внутрь. Например, MD_Metadata «содержит» MD_Distribution
• Состав (также известный как сильное агрегирование): Используется, когда части внутри контейнера не могут существовать без контейнера.Если контейнер удаляется, то все объекты «внутри» контейнера также удаляются.
• Обобщение: Изображает суперкласс и подклассы, которые могут быть заменены суперклассом. Общие общие ограничения - это документы через MD_Constraints , но подкласс MD_SecurityConstraints может заменять свой суперкласс MD_Constraints (ограничения безопасности имеют те же объекты, что и MD_Constraints, и дополнительные объекты, которые специально предназначены для документирования ограничений, связанных с безопасностью.)
• Зависимость (также известная как создание экземпляра): Аналогично оператору «IF»: если accessConstraints или useConstraints = « otherRestrictions », то необходимо использовать « otherConstraints ».

Мощность UML

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

Сущность метаданных UML

Менеджер коллекций

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

CoMET и DSMQ

NCEI NOAA разработал Опросник зрелости управления данными (DSMQ) в поддержку проекта NOAA OneStop как интуитивно понятный способ быстрой и систематической оценки зрелости управления отдельными наборами цифровых данных об окружающей среде. Построенный на основе матрицы зрелости управления данными NOAA / CICS-NC (DSMM), DSMQ предоставляет пользователям механизм для оценки аспектов управления их наборами данных в упрощенном и удобном для пользователя виде.Полученные в результате количественные оценки зрелости наборов данных полезны при управлении хранилищами данных организации и связанной с ними информацией. DSMQ интегрирован с NCEI Collection Metadata Enterprise Tool (CoMET).

CoMET - это инструмент, который позволяет пользователям импортировать, создавать, редактировать, проверять и публиковать записи метаданных ISO. CoMET - это одно из приложений в составе набора приложений для метаданных, разработанных в NCEI's Collection Manager.

Запустить CoMET

Веб-доступные папки (WAF)

WAF содержат стандартные записи метаданных ISO, заархивированные по темам.Каждую запись можно просмотреть как целевую страницу XML, KML, Full Text или HML, а также как страницу часто задаваемых вопросов. Каждая запись оценивается по RubricV2, готовности DOI, готовности CSW и компонентам, и к ним можно получить доступ с каждой записью.

Доступ к WAF NCEI

Docucomp

Docucomp - это принадлежащее NOAA веб-приложение для вставки, редактирования и управления XML-компонентами, которые представляют собой фрагменты XML, описывающие определенные фрагменты содержимого метаданных. Они хранятся в базе данных и управляются с помощью веб-служб REST.Службы REST поддерживают операции вставки, поиска, обновления и удаления. Вам понадобится учетная запись NOAA, чтобы использовать Docucomp.

Запустить Docucomp

Metaserver

Metaserver - это инструмент, принадлежащий NOAA, который поможет вам:

• Оценка отдельных записей с помощью служб записи
• Обработка записей с помощью WAF On Demand
• Просмотр источников записей
• База данных метрик для качества / полноты

Для использования Metaserver вам потребуется учетная запись NOAA.

Запустить Metaserver

Руководство пользователя Metaserver

Oxygen XML Editor

Oxygen - это инструмент разработки XML, который предоставляет полный набор инструментов создания и разработки XML. Вы можете использовать кислородный редактор XML для работы со всеми технологиями на основе XML, включая базы данных XML, конвейеры XProc и веб-службы.

Как использовать Oxygen

Что такое XML?

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

Тег: Конструкция разметки, которая начинается с «<» и заканчивается «>».

начальные теги 

конечные теги 
 или 
 

Элемент: Логический компонент документа, который либо начинается с начального тега и заканчивается соответствующим конечным тегом, либо состоит только из тега пустого элемента. .Символы между начальным и конечным тегами, если они есть, являются содержимым элемента и могут содержать разметку, включая другие элементы, которые называются дочерними элементами.

<Приветствие> Привет, мир.  

Атрибут: Конструкция разметки, состоящая из пары имя / значение, которая существует в начальном теге или теге пустого элемента. В примере (ниже) элемент img имеет два атрибута, src и alt:

Другой пример - соединение A с B.где имя атрибута - «число», а значение - «3». Дополнительные сведения об атрибутах см. В разделе «Использование атрибутов» ниже.

Пространства имен: Вы можете заметить в XML, что имена элементов имеют трехбуквенный код, за которым следует двоеточие.

 gco: CharacterString 

Эти коды называются пространствами имен. Пространство имен - это контейнер, предоставляющий контекст и правила для элементов. Определение термина может измениться в зависимости от того, какое пространство имен применяется. Таблица сокращений пространств имен определяет пространства имен, которые могут быть найдены в XML.

Использование атрибутов

Элементы XML могут иметь атрибуты, которые предоставляют дополнительную информацию об элементе. Часто дополнительная информация не входит в состав данных. Значения атрибутов должны содержать одинарные или двойные кавычки. Атрибуты обычно «группируются» по определенным типам. Элементы, являющиеся ролями ISO (теги xml, начинающиеся с нижнего регистра), часто допускают атрибуты XLinks, uuidref и nilReason. Элементы, которые являются объектами ISO (теги xml, начинающиеся с двух аббревиатур пакетов в верхнем регистре), часто допускают идентификаторы и uuid.Frame, calendarEraName и indeterminatePosition являются атрибутами gml и находятся в пределах временных позиций.

 разрешит атрибуты id и uuid
 разрешит атрибуты XLink type, href, role, arcole, title, show и actate, а также атрибуты uuidref и nilReason.
 позволит использовать атрибуты gml для frame, calendarEraName и indeterminatePosition.
 

id: Идентификатор элемента, если он указан, должен быть уникальным в пределах документа XML.Значение идентификатора всегда должно начинаться с буквы, подчеркивания (_) или двоеточия (:). Элемент XML может иметь только один атрибут типа ID. Идентификаторы, используемые в атрибуте id, представляют собой имена XML, которые имеют значительные ограничения. Они должны начинаться с буквы, подчеркивания (_) или двоеточия (:) и после первого символа состоять только из букв, цифр, подчеркиваний и дефисов (-). Этот атрибут часто является обязательным для таких элементов, как единицы и экстенты.

 метры 

 

Idref: Ссылка на элемент XML в документе XML. Значение должно соответствовать значению атрибута типа ID в существующем элементе XML. Атрибут idref позволяет элементу XML ссылаться на другой элемент XML в том же документе, который имеет соответствующий атрибут id.

idrefs: Ссылка на один или несколько элементов XML. Значения должны быть разделены пробелами и должны соответствовать существующим идентификаторам XML-элементов.

uuid: UUID назначается объекту при его создании и является стабильным в течение всего срока службы объектов. uuids необходимы для долгосрочного управления распределенными данными и для реализации механизмов обновления. Эти идентификаторы также называются постоянными идентификаторами. UUID - это 16-байтовое число, состоящее из 32 шестнадцатеричных (0-9 и a-f) значений. Значения разделены на пять групп, разделенных дефисом в форме 8-4-4-4-12 или 8-4-4-16, всего 36 символов (32 значения и 4 дефиса).Примечание: uuid любого удаленного объекта нельзя использовать снова.

Примечание: UUID - это универсальные уникальные идентификаторы, которые также имеют особые характеристики.

uuid = ”594D435F-954C-1022-78E7-D62F30CD0592” 

uuidref: Атрибут uuidref используется для ссылки на элемент XML, имеющий соответствующий атрибут uuid.

uuidref = ”594D435F-954C-1022-78E7-D62F30CD0592” 

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

 10,0 

 

frame: Атрибут кадра является необязательным и позволяет пользователю указать временную систему отсчета, которая будет использоваться для интерпретации значения временной позиции.

 - 2500  

calendarEraName: Атрибут calendarEraName является необязательным и предоставляет имя календарной эры, к которой относится дата (например,грамм. эпоха Мэйдзи японского календаря).

   1965 
       1990  

indeterminatePosition: Атрибут indeterminatePosition является необязательным и используется во временных позициях и может использоваться отдельно или может определять конкретное значение для временной позиции. . Этот атрибут часто используется для документирования неизвестных и настоящих дат.Допустимые значения для indeterminatePosition - «unknown», «after», «before» и «now». Если indeterminatePosition = «сейчас», лучше всего указать дату и время создания метаданных.

 состояние грунта 
 1990-11-03T00: 00: 00 


 

XLinks: Язык связывания XML (XLink) позволяет вставлять элементы в документы XML для создания и описания связей между ресурсами, подобно гиперссылкам HTML.Связывающие элементы распознаются на основе использования назначенного атрибута с именем xml: link и набора сопутствующих глобальных атрибутов. Глобальные атрибуты: type, href, role, arcrole, title, show и actate. Если используется XLink, следующий компонент ISO не используется.

type: Атрибут type указывает тип элемента XLink, такой как простой, расширенный, локатор, дуга, ресурс или заголовок.

href: Значение атрибута href в связывающих элементах содержит указатель, который идентифицирует ресурс, например.g., по ссылке URI или по спецификации XPointer. Атрибут xlink href используется для ссылки на компонент, а атрибут заголовка xlink используется для применения понятного человеку имени к компоненту. Компоненты - это фрагменты XML, описывающие определенную часть содержимого метаданных, например информацию о людях, веб-сайтах, документах, архивах, инструментах и ​​т. Д. Компонент - это самый тонкий уровень (атомарный уровень) детализации в записи метаданных. Компоненты хранятся один раз и используются так часто, как требуется в коллекции метаданных.Компоненты обеспечивают значительные преимущества при хранении и редактировании по сравнению с традиционным методом управления метаданными, заключающимся в хранении каждой записи в целом. XLinks можно использовать для ссылки на компонент из неразрешенной записи метаданных (неразрешенная означает, что запись метаданных содержит xlinks). Xlink ссылается на конкретный компонент по его уникальному идентификатору (UUID). Во время процесса разрешения компонент, на который имеется ссылка через XLink, извлекается и внедряется в запись (разрешенная запись метаданных).

роль: Атрибут роли определяет часть семантики ссылки. Значение этого атрибута указывает свойство, которым обладает вся ссылка, и определяет для прикладного программного обеспечения значение ссылки. Это позволяет приложению отображать разные символы для разных типов ссылок.

arcrole: Атрибут arcrole соответствует понятию свойства в структуре описания ресурсов (RDF), где роль может интерпретироваться как указание на то, что «начальный ресурс ИМЕЕТ конечный ресурс arc-role».«Эта контекстная роль может отличаться от значения конечного ресурса, если взята вне контекста данной конкретной дуги. Например, ресурс может в общем представлять« человека », но в контексте конкретной дуги он может иметь роль «мать», а в контексте другой дуги он может играть роль «дочери».

title: Атрибут title указывает удобочитаемое описание всей ссылки.

show: Этот атрибут указывает политики поведения, которые следует использовать при переходе по ссылке с целью отображения или обработки. Значение embed указывает, что назначенный ресурс должен быть встроен в тело ресурса и в то место, где начался обход. Значение replace указывает, что назначенный ресурс должен заменить ресурс, с которого начался обход.Новое значение указывает, что указанный ресурс должен отображаться или обрабатываться в новом контексте.

actate: Атрибут actate используется для выражения политики относительно того, когда должен происходить переход по ссылке. Значение auto указывает, что прохождение ресурса выполняется автоматически. Значение пользователя указывает, что ссылка переходит только по запросу пользователя. Допустимые значения для срабатывания: «onLoad», «onRequest», «other» и «none».

nilReason: Атрибут nilReason используется для объяснения того, почему элемент не включен в XML.Этот атрибут позволяет причине (объясняющей, почему фактическое значение не может быть предоставлено) существовать вместо фактического значения. Он может иметь значения «неприменимо», «отсутствует», «шаблон», «неизвестно» и «удерживается».

        
            
            
                 публикация 
            
        
    

 

Использование списков кодов