Разработка системы автоматизации функций формирования SCORM совместимых метаданных для информационных ресурсов

4. Описание предметного содержания ЭУМ должно отражать состав учебных объектов и характер работы. Например: «Модуль включает  текст, слайды, анимации, представляющие размножение и развитие папоротников, а также контрольные вопросы». Или: «…проводится лабораторная работа (такая-то)», «…выполняются практические задания (такие-то)».

При этом в описании не нужно указывать, что они «выполняются в интерактивном  режиме» - идеология ЭОР нового поколения иных режимов не предусматривает, а уровень интерактивности зафиксирован в метаданных ЭУМ.

Описание ЭУМ должно также включать краткую информацию о методах  организации интерактива. Например: «Учащемуся предлагается расставить в  правильной последовательности изображения…» или «… собрать электрическую схему…» и т.п.

5. Кроме названия, каждый ЭУМ характеризуется версией. Формат версии определяется четырьмя целыми числами, разделенными точками:

<k. l. m. n>, k, n ≥ 1,    l,m ≥ 0

где: n – внутренний параметр разработчика, определяющий номер сборки ЭУМ;

m – увеличивается при каждой технической коррекции мультимедиа компонентов (опечатки, улучшение качества визуальных и звуковых фрагментов и т.п.) и/или коррекции scenario, моделера (мелкие ошибки в программах), а также при внесении изменений в метаданные;

l – увеличивается после содержательных изменений в учебном контенте (замена, исключение, добавление учебных объектов, изменение методов организации интерактива и т.д.);

k – увеличивается при значительный переработках (от новой сцены до полного изменения контента) ЭУМ при сохранении его названия.

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

Файл манифеста всегда должен называться «imsmanifest.xml» и располагаться в корневой папке ЭУМ.

Пример файла «imsmanifest.xml»:

 

<?xml version="1.0" encoding="UTF-8"?>

<manifest identifier="FCIOR-4F257C32-D9D7-19E0-C3FF-33BF3E71CEAD"

xmlns="http://www.imsglobal.org/xsd/imscp_v1p1" xmlns:adlcp="http://www.adlnet.org/xsd/adlcp_v1p3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd">

<metadata>

<schema>ADL SCORM</schema>

<schemaversion>CAM 1.3</schemaversion>

<adlcp:location>/META-INF/manifest.xml</adlcp:location>

</metadata>

<organizations/>

<resources/>

</manifest>

 

Часть файла, заключённая в теги <organization> </organization> служит для описания структуры последовательности ЭУМ, к которой относится файл манифеста. Каждый элемент в этой структуре должен быть описан между тегами <item> </item>. Внутри тегов <resources> </resources> заключены ссылки на конкретные ЭУМ, которые используются в последовательности. Каждый такой ЭУМ должен иметь уникальный в пределах последовательности идентификатор, по которому и производится привязка к конкретному месту в последовательности.

4. Манифест дистрибутивного пакета, информационная модель

На верхнем уровне манифест содержит 4 раздела (рис. 2.5):

1) метаданные для ИР в целом;

2) логические организации контента;

3) спецификация физических ресурсов;

4) вложенные манифесты.

Рис. 2.5. Укрупненная структура манифеста

 

Модель манифеста инвариантна  к педагогическим аспектам формирования ДП и использования представляемого  им ИР (дидактике, методике, организационным  схемам и т.п.). Она не регламентирует количество уровней в дереве ЕУД, интерпретацию относящихся к ним элементов, объем и степень агрегации связанного с ними контента и подчиненных модулей. Таким образом, данная метамодель фиксирует только иерархический характер отношений между элементами логической организации, а их трактовка (типология ЕУД и фрагментов учебного материала) определяется применяемыми педагогическими и методическими подходами.

Следует подчеркнуть, что логическая организация контента не сводится к  физической структуре ДП. Файлы, входящие в ДП, обычно распределены по иерархической системе папок. Однако эта структура, в отличие от дерева ЕУД, не содержит информации о сценарии применения ИР в учебном процессе и обусловлена техническими, а не педагогическими решениями. Основное назначение логической организации - описание взаимосвязей ЕУД, выполняемых с помощью наборов физических ресурсов. Формализованное представление данного описания обеспечивает его интерпретируемость LMS, осуществляющей поддержку соответствующей учебной деятельности.

Состав физических компонентов  ИР представляет раздел манифеста resources. В нем описываются как внутренние (локальные) ресурсы, входящие в ДП, так и внешний контент, размещенный в Интернет и применяемый для поддержки ЕУД, указанных в манифесте.

Раздел содержит последовательность элементов resource, каждый из которых специфицирует набор файлов, имеющих общую точку входа, и отношения зависимости этого набора от других ресурсов. Зависимость одного ресурса от другого означает, что в первом используются файлы из второго набора. Если в наборе файлов присутствуют компоненты, реализующие интерфейс С LMS, то соответствующему ресурсу приписывается тип SCO; в противном случае он классифицируется как актив.

Ссылка на элемент resource может быть указана в листе дерева ЕУД. Переход  к такой ЕУД в рамках управления навигацией приводит к запуску ресурса, на который она ссылается, т.е. передаче точки входа в него СИ. На один элемент resource могут ссылаться несколько ЕУД.

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

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

Интегрированная информационная модель манифеста, описанная в SCORM, поддерживает расширения аналогично базовой модели. В ней используются типы данных string, boolean, decimal, ID и IDREF в соответствии с их определениями в языке XML Schema. Набор символов для типа string установлен в и обеспечивает поддержку представления символов разных естественных языков. Тип decimal специфицирует символьное представление десятичного числа.

9. Средства автоматизации

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

1. Рубрикатор

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

Рис. 2.6. Рубрикатор

 

 

 

 

Таблица 2.4

Свойства рубрикатора

№	Свойство	Описание
1	Название	Название рубрики
2	Код	Код рубрики в рубрикаторе. Значение свойства устанавливается  автоматически. Возможность изменить исходное значение предусмотрена для  случая, когда в базу введен не весь рубрикатор, но конечная нумерация рубрик уже известна
3	Этап сдачи	Этап сдачи модулей. Введен для генерации выходных документов
4	Очередь	Очередь сдачи модулей  в рамках этапа. Введена для фильтрации списка  модулей и генерации  выходных документов
5	Авторы	Один или несколько  авторов модуля из соответствующего справочника
6	Уровень образования  (класс общеобразовательной  школы)	Уровень образования. При  определенных уровнях образования  можно ввести класс общеобразовательной  школы
7	Образовательная направленность	Возможные значения: «базовый вариант учебной программы», «профильный  вариант учебной программы»
8	Характер обучения	Возможные значения: «базовое», «специальное (коррекционное)»
9	Версия оформления	Версия оформления модулей. По сути, версия оформления это версия папки «data\skin» и некоторых других файлов папки «data», которая будет копироваться в модуль при его экспорте из Хранилища. Справочник версий оформления ведется администратором системы
10	Версия скриптов	Версия скриптов. По сути, версия скриптов это версия папки «script» которая будет копироваться в модуль при его экспорте из Хранилища. Справочник версий скриптов ведется администратором системы
11	Дата публикации	Дата публикации модулей

2. Автоматизация заполнения свойств модулей

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

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

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

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

 

Рис. 4.3. Свойства модуля

 

3. Использование справочников

В системе можно выделить три вида справочников: стандартные справочники RUS_LOM, пользовательские справочники, системные справочники.

Стандартные справочники RUS_LOM – содержат классификаторы, описанные в «Унифицированных требованиях (расширенных) к электронным учебным модулям открытых образовательных модульных мультимедиа систем, 2008 г.» и в данной версии системы не могут быть модифицированы.

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

4. Пакетная обработка модулей.

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

 Генерация метаданных и автоматическая упаковка модулей происходит при каждой выгрузке/публикации модулей. При этом состав модуля и содержание его метаданных зависит от ранее загруженной версии модуля, свойств модуля заданных в системе и содержания справочников.