МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ

(МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION

(ISC)

ГОСТ

33246—

2015

(ISO/IEC

12785-1:2009)

Информационные технологии

ОБУЧЕНИЕ, ОБРАЗОВАНИЕ И ПОДГОТОВКА. УПАКОВКА КОНТЕНТА

Часть 1

Информационная модель

(ISO/IEC 12785-1:2009, MOD)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

Цели, принципы и основной порядок проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0-92 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2-2009 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, применения, обновления и отмены»

Сведения о стандарте

1    ПОДГОТОВЛЕН Федеральным государственным бюджетным образовательным учреждением высшего профессионального образования «Московский государственный технологический университет «СТАНКИН» на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2    ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3    ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 18 июня 2015 г. № 47)

За принятие проголосовали:

Краткое наименование страны по MK (ИСО 3166) 004—97 Код страны по МК (ИСО 3166) 004—97 Сокращенное наименование национального органа по стандартизации Армения AM Агентство «Армстандарт» Киргизия KG Кыргызстандарт Россия RU Росстандарт Узбекистан UZ Узстандарт

4    Приказом Федерального агентства по техническому регулированию и метрологии от 17 ноября 2015 г. № 1835-ст межгосударственный стандарт ГОСТ 33246-2015 (ISO/IEC 12785-1:2009) введен в действие в качестве национального стандарта Российской Федерации с 1 ноября 2016 г.

5    Настоящий стандарт модифицирован по отношению к международному стандарту ISO/IEC12785-1: 2009 Information technology — Learning, education and training — Content packaging — Part 1: Information model (Информационные технологии. Обучение, образование и подготовка. Упаковка контента. Часть 1. Информационная модель) путем исключения справочных приложений С и D.

Перевод с английского языка (еп).

Сравнение структуры международного стандарта со структурой настоящего межгосударственного стандарта приведено в дополнительном приложении ДА.

Степень соответствия — модифицированная (MOD)

6 ВВЕДЕН ВПЕРВЫЕ

3.18    ссылочный манифест: Манифест или компонент манифеста, на который есть ссылка из другого манифеста.

Примечания

1    Манифест может содержать ссылку на структуру в другом манифесте.

2    Манифест, содержащий компонент, на который имеется ссылка, называется манифест-ссылка.

3    Манифест может содержать ссылки на локальные или удаленные компоненты.

См. также: локальный, удаленный.

3.19    относительная ссылка: Выражение URI-ссылки, относящееся к пространству имен другого иерархического URI [IETF RFC 3986 (2005)] [11].

Пример — relative/path/to/resource.txt является относительной ссылкой, которая интерпретируется с точки зрения контекста (алгоритм для разрешения относительных ссылок с точки зрения контекста определен в подпункте 5 RFC3986:2005).

Примечание — Для создания целевой URI объединяются расширение и контекст.

3.20    удаленный: Компонент логического пакета, который находится вне пакета обмен.

См. также: обмен пакета, логический пакет.

3.21    ресурс (в упаковке контента): Один URL-адрес точки входа и ноль или более ссылок на файлы, которые необходимо выполнить до запуска содержимого.

Примечание — Файлы, описываемые ресурсом, могут быть локальными или удаленными.

См. также: исполняемый URI, локальный, удаленный.

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

Примечания

1    Связанные манифесты могут содержаться в одном пакете контента или быть доступны как URI адресуемый внешний ресурс.

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

3.23    универсальный идентификатор ресурса (URI): Компактная последовательность символов, которая определяет абстрактный или физический ресурс (IETF RFC 3986).

3.24    унифицированный указатель ресурса (URL): Указатель, как подмножество URI, обеспечивает средства размещения ресурса путем описания основных механизмов доступа (IETF RFC 3986).

3.25    вариант: Контейнер для ссылки и описания частично отличающегося образовательного контента.

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

Примечания

1    Конкретный ресурс может иметь варианты различных форматов и различного предназначения.

2    Список вариантов в пределах ресурса определяет альтернативные наборы файлов для ресурса.

3    Метаданные используются для описания предполагаемого использования оригинального ресурса и предполагаемого использования вариантов.

См. также: метаданные ресурса.

Основные структурные компоненты:

-    логический пакет — представление одной или более единиц полезного (и многоразового) образовательного контента. Логический пакет включает в себя полный набор компонентов, описываемых манифестом, в том числе локальные компоненты и удаленные компоненты, включенные по ссылке;

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

-    манифест — компонент, который описывает полный экземпляр логического пакета. Манифест может содержать ссылки на локальные или удаленные компоненты;

-    структура — логические связи между единицами образовательного контента. Могут быть описаны несколько логических структур;

-    ресурсы — описание образовательного контента и файлов ресурсов, используемых в логическом пакете. Файлы могут быть локальными или удаленными;

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

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

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

Информационная модель определяет эти основные структурные компоненты для описания и организации LET-содержания для обмена. Важным является обоснование поддержи расширяемости. Пользователи настоящего стандарта могут применять эти механизмы расширения для определения новых терминов словаря и структуры.

6 Описание классов и требований к взаимосвязи

Информативный обзор всей информационной модели упаковки контента (CPIM) предоставляется в виде платформонезависимой модели (PIM), выраженной в конструкциях UML. Все UML-диаграммы, выраженные как «платформонезависимая модель», не являются нормативными. Нормативные таблицы, определяющие классы в этой информационной модели, следуют информативным диаграммам UML.

Полное определение профиля UML и термины, используемые в нормативных табличных описаниях в этом документе для описания PIM, можно найти в руководстве IMS Profile UML [12].

В таблицах настоящего раздела последовательность символов «N/А» используется для обозначения значения «не применяются». Любые поля, отмеченные таким образом, не относятся к определяемому классу. Функции, имеющие такое значение, должны игнорироваться при привязке класса, определяемого этой информационной моделью.

Расширенная форма Бэкуса-Наура (ABNF) используется для определения определенных правил в таблицах. Расширенная форма Бэкуса-Наура определена в [13].

6.1 Основные термины и понятия

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

-    класс «container»: класс «container» может быть родителем одного или нескольких дочерних классов;

-    класс «value»: класс «value» не может быть родителем. То есть он не должен объединять классы типа «characteristic», «container», «value» или «неопределенность». Класс «значение» всегда должен быть дочерним класса «container» и иметь семантические значения в рамках семантических значений своего родительского класса;

-    класс «characteristic»: класс «characteristic» не должен быть родительским. Класс «characteristic» должен декларировать особенности или значения, которые являются неотъемлемой функцией или ча-

ГОСТ 33246-2015

стью класса «container». Класс «characteristic» тесно связан с классом «container», который он изменяет, или с одним из аспектов, который он описывает;

- класс «unspecified»: класс «unspecified» может быть родительским классом. Класс «unspecified» служит точкой расширения для этой информационной модели.

В случае, если число элементов больше одного, важность упорядочения равнозначных элементов указывается путем добавления «упорядочено» или «не упорядочено». «Упорядочено» определяет последовательность равнозначных элементов как список, «не упорядочено» определяет набор или портфель равнозначных элементов. Порядок данных не важен.

В таблице 1 перечислены классы дескрипторов, используемых для описания абстрактных классов и определения дескрипторов.

Таблица 1—Классы дескрипторов

Дескриптор Определение Class name (Имя класса) Описывается имя, данное классу Class type (Тип класса) Тип абстрактного класса для этого класса Data type (Тип данных) Разрешенная структура допустимых значений класса для значений и характеристик классов. Допустимые типы данных: -    URI: любой синтаксически правильный экземпляр URI, соответствующий RFC3986. Примечание: многие основополагающие спецификации, стандарты и рекомендации, упоминаемые в информационной модели, используют RFC3986 и RFC2732 [14] для определения URI. Это отменено RFC3986, но многие основополагающие документы не были обновлены, чтобы ссылаться на RFC3986; -    LUID: идентификатор, локально уникальный в пределах манифеста. Это будет основано на типе данных String, который имеет ограниченную область значений; -    LUIDref: ссылка на LUID, который был определен в другом месте в пределах манифеста. Значения LUID и LUIDref, которые на его ссылаются, должны быть одинаковыми; -    Boolean: простой, двузначный тип данных, который использует ключевые слова «true» и «false», чтобы указать логическое состояние объекта; -    String: последовательность печатных символов; -    Unspecified: тип данных, который не известен или не важен Value space (Область значений) Диапазон допустимых значений для этого класса. Если область значений не определена, то это не известно или не важно Multiplicity (Кратность) Собственность класса, указывающая, сколько раз он может быть использован или появляться в данном родительском контексте. Значения этого свойства выражаются в виде диапазона или сокращенного диапазона использования этой нотации: -    «0 .. 1» [опционально; ограничено]; -    «0 .. неограничено» [опционально; неограничено]; -    «1 .. 1» [обязательно; ограничено]; -    «1 .. неограничено» [обязательно; неограничено]. Кратность может также появиться в сокращенных нотациях моделей UML. Сокращенные эквиваленты должны быть (без учета комментариев в квадратных скобках): -    «*» [опционально; неограничено]; -    «1» [обязательно; ограничено]; -    «* .. 1» [обязательно; неограничено]. Где кратностью больше единицы, важность упорядочения родственных значений указывается путем добавления «ordered» или «unordered» Characteristic classes (Классы характеристик) Списки классов характеристик, связанных с этим классом в виде characteristic characteristic ”}”. Одна или более характеристик могут быть представлены в фигурных скобках. Характеристики должны разделяться запятыми. Когда имеется две и более характеристики, важность упорядочения родственных элементов указывается добавлением «ordered» или «unordered» Parents (Родители) Списки классов, которые могут быть родительскими для этого класса

Окончание таблицы 1

Дескриптор Определение Children (Наследники) Перечисление возможных дочерних классов этого класса в виде “[” child child “]”. Один или несколько дочерних классов могут быть представлены в квадратных скобках. Каждый дочерний класс должен быть разделен запятыми. Когда имеются два и более наследников, важность упорядочения родственных элементов указывается добавлением «ordered» или «unordered» Description (Описание) Содержит описания, связанные с классом, и его область значений

6.2 Платформонезависимая модель информационной модели упаковки контента

На рисунке 2 приведено структурное представление информационной модели упаковки контента (CPIM).

Структура на рисунке 2 ориентирована на отношения между начальными классами и не содержит сведений о кратности, упорядоченности или атрибутах для классов.

6.3 Класс InterchangePackage

Пакет обмена идентичен логическому пакету, когда все компоненты в логическом пакете являются локальными для пакета обмена. Критерии для определения компонент логического пакета, которые 8

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

В таблице 2 приведен класс InterchangePackage в информационной модели упаковки контента (CPIM).

Таблица 2 — Определение класса InterchangePackage

Дескриптор Определение Class name (Имя класса) InterchangePackage Class type (Тип класса) Container Data type (Тип данных) N/A Value space (Область значений) N/A Multiplicity (Кратность) 1..1 Characteristic classes (Классы характеристик) N/A Parents (Родители) Нет Children (Наследники) [Manifest] Description (Описание) Объект InterchangePackage является подмножеством логического пакета, который обменивается между системами. InterchangePackage должен соответствовать следующим условиям: a)    InterchangePackage должен включать объект Manifest и может включать в себя файлы контента и управляющие файлы; b)    любой файл, описанный в Manifest с использованием URI, которые должны располагаться в InterchangePackage, должен быть включен в InterchangePackage; c)    все файлы, включенные в InterchangePackage, должны быть описаны в Manifest; d)    файлы, содержащиеся в InterchangePackage, могут содержать внутренние ссылки на другие файлы (например, файл контента HTML может ссылаться на файл контента JPEG или файлы управления XML Schema могут ссылаться на другие файлы управления XML Schema). Когда файл, содержащийся в InterchangePackage ссылается на другой файл с помощью URI, находящийся в InterchangePackage, указанный файл должны быть описан в Manifest InterchangePackage. Файл пакета обмена (PIF) является частным случаем InterchangePackage. Считыватели и записыватели пакетов не обязаны поддерживать чтение или запись PIF. PIF должны соответствовать следующим условиям: a)    физическая инкапсуляция должна быть в виде сжатого двоичного файла, соответствующего RFC1951; b)    PIF должен содержать один объект Manifest документа в корне PIF. Этот объект должен быть привязан как документ XML с именем «imsmanifest.xml». Этот документ называется корневой Manifest документа для PIF; c)    любые управляющие файлы, включенные в PIF, должны размещаться в корне PIF; d)    все ссылки из корня Manifest документа на файлы, содержащиеся в PIF, должны быть выполнены посредством относительных ссылок. Ссылки должны быть относительны корня PIF; e)    PIF не должен включать никаких файлов с абсолютным путем (объявленным или полученным по относительной ссылке) ранее, чем объект Manifest документа в том же иерархическом пути, или когда их абсолютный путь полностью отличается от расположения Manifest документа

9

6.4 Семейство классов Manifest

Этот раздел определяет следующие классы в информационной модели упаковки контента (CPIM):

-    Manifest;

-    ManifestMetadata;

-    Schema;

-    SchemaVersion;

-    MetadataModel.

Этот раздел определяет отношения следующих классов, определенных в 6.5.1, 6.6.1, 6.9 и 6.10 соответственно:

-    Organizations;

-    Resources;

-    IPointer;

-    Extension.

На рисунке 3 показан класс Manifest платформонезависимой модели (PIM).

6.4.1 Класс Manifest

В таблице 3 определен класс Manifest в информационной модели упаковки контента (CPIM).

Таблица 3 — Определение класса Manifest

Дескриптор Определение Class name (Имя класса) Manifest Class type (Тип класса) Container Data type (Тип данных) N/A Value space (Область значений) N/A Multiplicity (Кратность) 1..1 в случае, если дочерний InterchangePackage 0..unbounded в случае, если дочерний Manifest, unordered Characteristic classes (Классы характеристик) {Identifier, Version, Base, Other}, unordered Parents (Родители) InterchangePackage Manifest Children (Наследники) [ ManifestMetadata, Organizations, Resources, Manifest, IPointer, Extension ], ordered Description (Описание) Объект Manifest представляет собой контейнер для структуры данных, который описывает полный экземпляр логического пакета. Manifest может содержать дочерние объекты класса Manifest (дочерний манифест). Дочерний манифест определяет полные экземпляры логических пакетов, которые являются частью большого логического пакета. Manifest также может содержать дочерние объекты класса IPointer, которые ссылаются на дочерние манифесты, являющиеся внешними по отношению к Manifest. Разрешено любое сочетание дочерних манифестов и дочерних манифестов по внешним ссылкам, их порядок в Manifest не имеет существенного значения. Соответствующие цели для IPointer, объявленные как прямые наследники Manifest, определены в 6.9. Manifest может содержать ссылки на локальные или удаленные компоненты родительского объекта InterchangePackage. Ссылки делаются через дочерние объекты Resource, File и IPointer. Resource и File используются для ссылок на файлы контента и управляющие файлы. IPointer используется для идентификации ссылочного манифеста. Manifest должен содержать объекты File, которые описывают все управляющие файлы, необходимые для интерпретации манифеста

Дескриптор	Определение
Value space (Область значений)	N/A
Multiplicity (Кратность)	0..1
Characteristic classes (Классы характеристик)	N/A
Parents (Родители)	Manifest
Children (Наследники)	[ Schema, Schema Version, IPointer, Metadata Model ], ordered
Description (Описание)	Объект ManifestMetadata содержит описательную информацию о родительских объектах Manifest. Целью ManifestMetadata является весь логический пакет, описываемый родительским Manifest. Schema и SchemaVersion, дочерние ManifestMetadata, представляют информацию о спецификации или профиле, который регулирует значение родительского Manifest. MetadataModel, дочерний для ManifestMetadata, служит в качестве заполнителя для общей описательной информации о своем родительском Manifest. MetadataModel является точкой расширения, которая разрешает метаданные с информационной структурой, определенные в другом пространстве имен. Множественные, отличающиеся модели метаданных могут быть объявлены как расширения, содержащиеся в одном объекте ManifestMetadata. Если метаданные определены во внешнем объекте Metadata, то ссылка на это объект делается с использованием объекта IPointer. Разрешены любая комбинация Metadata Model и метаданных по внешним ссылкам, их порядок в объекте Metadata не имеет существенного значения. Соответствующие цели для IPointer, объявленные как наследники ManifestMetadata, определены в 6.9

6.4.3 Класс Schema

В таблице 5 определен класс Schema в информационной модели упаковки контента (CPIM). Таблица 5 — Определение класса Schema

Дескриптор	Определение
Class name (Имя класса)	Schema
Class type (Тип класса)	Value
Data type (Тип данных)	String
Value space (Область значений)	Набор печатных символов из [UCS]
Multiplicity (Кратность)	0..1
Characteristic classes (Классы характеристик)	N/A
Parents (Родители)	ManifestMetadata
Children (Наследники)	N/A

Дескриптор

Определение

Description (Описание)

Объект Schema декларирует имя спецификации или профиля для своего родительского объекта Manifest. Значение Schema информирует считыватель пакета о спецификациях или профиле, которые регулируют значение Manifest. Это значение не следует путать с названием или меткой, присвоенными данной схеме метаданных. Требования к содержанию или синтаксису строки, декларируемой как значение Schema, не предъявляются, за исключением того, что строка не должна включать информации о версиях. Значение по умолчанию должно быть «LET контент»

6.4.4 Класс SchemaVersion

В таблице 6 определен класс SchemaVersion в информационной модели упаковки контента (CPIM). Таблица 6 — Определение класса SchemaVersion

Дескриптор	Определение
Class name (Имя класса)	SchemaVersion
Class type (Тип класса)	Value
Data type (Тип данных)	String
Value space (Область значений)	Набор печатных символов из [UCS]
Multiplicity (Кратность)	0..1
Characteristic classes (Классы характеристик)	N/A
Parents (Родители)	ManifestMetadata
Children (Наследники)	N/A
Description (Описание)	Объект SchemaVersion декларирует версию спецификации или профиля, которые декларированы как значения для их родственного объекта Schema. Это значение сообщает считывателю пакетов о версии модели или профиля, определенных родственной Schema. Значение для SchemaVersion не должно включать никакой другой информации. Значение по умолчанию должно быть «ISO/IEC 12785:2009». «LET контент» объявлено как значение для родственной Schema, Manifest документа регулируется привязкой этой информационной модели. Ни синтаксис для информации о версиях, ни эвристические характеристики для применения любых версий синтаксиса не определяются данной информационной моделью

6.4.5 Класс MetadataModel

В таблице 7 определен класс MetadataModel в информационной модели упаковки контента (CPIM).

Таблица 7 — Определение класса MetadataModel

Дескриптор Определение Class name (Имя класса) MetadataModel Class type (Тип класса) Unspecified

ГОСТ 33246-2015

Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (ww.gost.ru)

© Стандартинформ, 2016

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

Дескриптор	Определение
Data type (Тип данных)	Unspecified
Value space (Область значений)	Unspecified
Multiplicity (Кратность)	0..unbounded, ordering also unspecified
Characteristic classes (Классы характеристик)	Unspecified, ordering also unspecified
Parents (Родители)	ManifestMetadata Metadata
Children (Наследники)	Unspecified, ordering also unspecified
Description (Описание)	Объект MetadataModel является заполнителем. Он информирует привязки этой информационной модели о допустимых местоположениях для включения метаданных в пакет обмена. Фактические имена расширенных контейнеров или значения типов классов, содержащих одну или более моделей метаданных, будут известны только тогда, когда привязка этих классов будет импортирована в связанный экземпляр этой информационной модели. Таким образом, фактический тип класса не определен в этой информационной модели. MetadataModel используется двумя контейнерами метаданных: ManifestMetadata и Metadata. MetadataModel является единственным средством для выражения модели метаданных и ассоциированной с ней информации в связанном экземпляре этой информационной модели. Записыватель пакетов может представлять столько различных моделей метаданных, сколько это необходимо для адекватного описания контента, инкапсулируемого в родительский объект MetadataModel. MetadataModel должен использоваться только для объявления одной или нескольких моделей метаданных и информации, связанной с ними. Семантика MetadataModel должна оставаться в пределах семантики его родителей в этой информационной модели. Семантика MetadataModel не должна перекрывать или переопределять семантику родителей, как определено в данной информационной модели

6.5 Семейство классов Organizations

Этот раздел определяет следующие классы в информационной модели упаковки контента (CPIM)

-    Organizations;

-    Organization;

-    Title;

-    Lingual Title;

-    Item.

Он также определяет отношения классов, определенных в 6.7, 6.9 и 6.10 соответственно:

-    Metadata;

-    IPointer;

-    Extension.

На рисунке 4 показан класс Organizations платформонезависимой модели (PIM).

Содержание

1    Область применения..................................................................1

2    Нормативные ссылки..................................................................1

3    Термины и определения...............................................................1

4    Сокращения.........................................................................5

5    Концептуальная модель упаковки    контента (СРСМ)........................................5

6    Описание классов и требований к    взаимосвязи............................................6

6.1    Основные термины и понятия.......................................................6

6.2    Платформонезависимая модель информационной модели упаковки контента...............8

6.3    Класс InterchangePackage..........................................................8

6.4    Семейство классов Manifest.......................................................10

6.5    Семейство классов Organizations...................................................14

6.6    Семейство классов Resources......................................................19

6.7    Класс Metadata..................................................................22

6.8    Класс Variant....................................................................23

6.9    Класс IPointer...................................................................25

6.10    Класс Extension.................................................................26

6.11    Классы характеристик...........................................................28

7    Соответствия.......................................................................37

7.1    Формулировки...................................................................37

7.2    Экземпляры пакетов обмена.......................................................37

7.3    Считыватели пакетов.............................................................37

7.4    Записыватели пакетов............................................................37

7.5    Расширения (расширение соответствий).............................................37

Приложение А (справочное) Первоисточник стандарта......................................39

Приложение В (справочное) Подтверждение прав интеллектуальной собственности.............40

Приложение ДА (справочное) Сравнение структуры международного стандарта

со структурой межгосударственного стандарта...............................41

Библиография........................................................................42

IV

ГОСТ 33246-2015

Введение

ИСО (Международная организация по стандартизации) и МЭК (Международная электротехническая комиссия) являются частью специализированной системы всемирной стандартизации. Национальные организации, которые являются участниками ИСО или МЭК, принимают участие в разработке международных стандартов посредством технических комитетов, основанных соответствующими организациями, для работы с отдельными отраслями технический деятельности. Сотрудничество технических комитетов лежит в сфере общих интересов. Другие международные организации, как государственные, так и коммерческие, поддерживают связь с ИСО и МЭК и также участвуют в их работе. В сфере информационных технологий ИСО и МЭК создали объединенный технический комитет — ИСО/МЭК СТК 1.

Международные стандарты разрабатываются в соответствии с правилами, описанными в директивах ИСО/МЭК, часть 2.

Главная задача объединенного технического комитета — подготовка международных стандартов. Предварительные проекты международных стандартов, утвержденные объединенным техническим комитетом, передаются в государственные организации для голосования. Для выхода международного стандарта требуется как минимум 75 % голосов организаций, участвующих в голосовании.

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

-    тип 1, когда необходимая поддержка не может быть получена для публикации международного стандарта, несмотря на повторные усилия;

-    тип 2, когда предмет все еще является объектом технического развития или где по любой другой причине есть будущее, но не непосредственная возможность соглашения по международному стандарту;

-    тип 3, когда объединенный технический комитет собрал данные различного вида от того, что обычно издано как международный стандарт («состояние», например).

Технические отчеты о типах 1 и 2 подвергаются рассмотрению в течение трех лет после публикации, чтобы решить, могут ли они быть преобразованы в международные стандарты. Технические отчеты о типе 3 не обязательно должны быть рассмотрены, пока данные, которые они обеспечивают, как полагают, больше не действительны или не полезны.

Особое внимание уделяется ситуации, когда некоторые части документа могут быть субъектом патентного права. ИСО и МЭК не несут ответственность за идентификацию некоторых или всех патентных прав.

Настоящий стандарт разработан на основе спецификации IMS Global Learning Consortium (IMS GLC) (Упаковка контента версии 1.2) [1-4]. Спецификация IMS Content Packaging широко используется по всему миру для поддержки технологии обучения. IMS Content Packaging является неотъемлемой основой SCORM [5] от его зарождения до текущей версии. Но самое главное, IMS Content Packaging также широко используется за пределами SCORM на самостоятельной основе. IMS Content Packaging также используется во многих других высокоуровневых учебных целях, например, для архивирования MIT OpenCourseWare, распространения контента данных, которые не содержат исполняемых модулей и метаданных для Федерации обучения Австралии, и предоставления общенациональных услуг электронного обучения для Кибернетической системы домашнего образования в Корее. IMS GLC предоставляет постоянную помощь для использования, профилирования и совершенствования стандарта упаковки контента по адресу http://www.imsglobal.org/contentpackaging.html.

Стандарт ИСО/МЭК 12785 «Информационные технологии. Обучение, образование и подготовка. Упаковка контента» состоит из следующих частей:

Часть 1. Информационная модель;

Часть 2. XML-привязка;

Часть 3. Лучшие практики и руководство по применению.

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

Спецификация упаковки контента IMS была первоначально задумана для упаковки образовательного контента.

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

упаковка контента является основной спецификацией, указанной в эталонной модели контента для совместного пользования (SCORM) инициативной группы ADL. Внедряющие IMS упаковку контента распространили ее использование не только для упаковки учебного контента. На IMS упаковку контента теперь ссылаются другие спецификации IMS для упаковки и обмена другими типами данных.

Запросы на основные функциональные дополнения не были включены в серию IMS упаковки контента версии 1.1 .х и накапливались как практика, созревшая вокруг реализации IMS упаковки контента. Оценка этих запросов в 2006 г. в сочетании с обратной связью от более широкого сообщества пользователей указали IMS, что это правильное время, чтобы сделать совместно с ИСО/МЭК СТК1/ПК36 существенное обновление и окончательный релиз этой спецификации.

Новая функциональность и разъяснения, содержащиеся в настоящей спецификации упаковки контента:

a)    уточнены значения терминов, используемых в спецификации;

b)    уточнено и усовершенствовано использование (суб)манифеста, теперь называемого дочерний манифест:

-    уточнена интерпретация объекта, указывающего на дочерний манифест;

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

-    добавлена поддержка внешних дочерних манифестов;

c)    добавлена поддержка внешних справочных файлов метаданных;

d)    все внутренние словари удалены и в настоящее время поддерживаются за счет процесса регистрации IMS-словарей (см. http://www.imsglobal.org/vdex/index.html);

e)    добавлен новый тип ресурса «stand alone resource», позволяющий использовать другие пакеты, как часть содержимого LET;

f)    уточнены синтаксис и использование классов информационной модели Base, Parameter, IsVisible и Href;

g)    добавлена поддержка вариантов ресурсов. Это включает в себя поддержку альтернативных ресурсов для доступности LET-контента;

h)    добавлена поддержка названия организации и пункта на нескольких языках;

i)    уточнена поддержка для обмена пакетами, которые содержат только контент, и для обмена пакетами, которые не имеют локальных файлов содержания.

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

a)    с точки зрения информационной модели IMS упаковки контента информационная модель IMS упаковки контента версии 1.1.4 [6, 7] есть собственное подмножество этой информационной модели IMS упаковки контента;

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

Структура остальной части настоящего стандарта:

1 Область применения	Определяет область применения настоящего стандарта
2 Нормативные ссылки	Перечень ссылок на другие стандарты и RFC, приведенные в настоящем стандарте
3 Термины и определения	Определяет термины и определения
4 Сокращения	Раскрывает сокращения, используемые в настоящем стандарте
5 Концептуальная модель упаковки контента	Иллюстрирует концептуальную структуру информационной модели упаковки контента
6 Описание классов и требований к взаимосвязи	Охватывает структурные отношения, тип данных, пространство значений и число допускаемых вхождений для каждого вида информационного объекта
7 Соответствие	Набор заявлений соответствия, которые необходимо соблюдать для соответствия экземпляров систем и документов

ГОСТ 33246-2015

ИСО/МЭК 12785 был принят объединенным техническим комитетом ИСО/МЭК СТК 1, информационные технологии, подкомитет ПК 36, информационная технология для обучения, образования и подготовки.

От Российской Федерации функции постоянно действующего национального рабочего органа ИСО/МЭК СТК 1 ПК 36 выполняет ТК 461 «Информационно-коммуникационные технологии в образовании» (ИКТО), активно участвующий в разработке международных стандартов, осуществляющий разработку комплекса национальных стандартов ИКТО.

VII

ГОСТ 33246-2015 (ISO/IEC 12785-1:2009)

СТАНДАРТ

Информационные технологии ОБУЧЕНИЕ, ОБРАЗОВАНИЕ И ПОДГОТОВКА. УПАКОВКА КОНТЕНТА

Часть 1 Информационная модель

Information technology. Learning, education, and training. Content packaging. Part 1. Information model

Дата введения — 2016—11—01

1    Область применения

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

Информационная модель упаковки контента сохраняет IMS информационную модель упаковки контента версии 1.2 в качестве базовой модели и предоставляет новые функциональные возможности путем расширения этой базовой модели.

Эта спецификация заменяет IMS информационную модель упаковки контента версии 1.1.4 и отменяет все предыдущие описания и определения IMS информационной модели упаковки контента.

2    Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий межгосударственный стандарт:

ГОСТ 7.75—97 Система стандартов по информации, библиотечному и издательскому делу. Коды наименований языков

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если ссылочный стандарт заменен (изменен), то при пользовании настоящим стандартом следует руководствоваться заменяющим (измененным) стандартом. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 дочерний манифест: Полный, подчиненный манифест, содержащийся в ро- child manifest дительском манифесте, или на который имеется ссылка из родительского манифеста.

Примечания

1    Манифест может содержать несколько дочерних манифестов (по IMS Content Packaging версии 1.2).

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

Издание официальное