Smart-E - Assembly Process Description

SMART-E

ASSEMBLY PROCESS DESCRIPTION

E RI K S I EG E L V0.8 - 5 J UNE 2008

S M A R T - E - A S S E M B L Y P R O C E S S D E S C R I P T I O N V 0 . 8 - 5 J U N E 2 00 8 C O M B I N I N G T H E S E P A R A T E C P ’ S

0. TABLE OF CONTENTS

0. Table of contents...... 2 0.1. Version summary...... 3 1. Introduction...... 4 1.1. Additional documentation...... 4 2. Data and workspaces...... 5 2.1. Overall structure...... 5 2.2. Workspace structure...... 6 2.3. Assets...... 6 2.4. Metadata details...... 7 2.4.1. Workspace metadata...... 7 2.5. File metadata...... 7 2.5.1. Asset metadata...... 8 3. The overall assembly process...... 9 4. Generic content package components...... 11 4.1. Manifest file...... 11 4.1.1. Manifest file header...... 11 4.1.2. Metadata...... 12 4.2. Package content...... 13 4.2.1. Root...... 13 4.2.2. Package content guideliness...... 13 5. CP type “Webopdrachten”...... 14 5.1. Workspaces for “webopdrachten”...... 14 5.2. Manifest file components...... 14 5.2.1. Organization...... 14 5.2.2. Resources...... 15 5.2.3. CPI extension...... 17 5.2.4. Teletop menu extension...... 18 5.2.5. Studiewijzer...... 18 5.3. Package content...... 20 5.3.1. Wordrecycler handling...... 20 5.3.2. Item subdirectories...... 20 5.3.3. System...... 21 5.4. File creation/generation...... 21 5.4.1. Object.xml...... 21 5.4.2. Item configuration file...... 22 5.4.3. index.html...... 22 6. CP type “Webschriften”...... 23 6.1. Workspaces for “webschriften”...... 23 6.2. Manifest file components...... 23 6.2.1. Organization...... 23 6.2.2. Resources...... 24 6.2.3. CPI extension...... 24 6.2.4. Teletop menu extension...... 25 6.2.5. Studiewijzer for webschriften...... 25 6.3. Package content...... 26 7. CP type “Webboeken”...... 27 7.1. Workspaces for “webboeken”...... 27 7.2. Manifest file components...... 27 7.2.1. Organization...... 27 7.2.2. Resources...... 28 7.2.3. CPI extension...... 28 7.2.4. Teletop menu extension...... 29 7.2.5. Studiewijzer for webboeken...... 29 7.3. Package content...... 29 8. Combining the separate CP’s...... 30

P A G E 3 O F 3 4 S M A R T - E - A S S E M B L Y P R O C E S S D E S C R I P T I O N V 0 . 8 - 5 J U N E 2 00 8 C O M B I N I N G T H E S E P A R A T E C P ’ S

8.1. Manifest file components...... 30 8.1.1. Organization...... 30 8.1.2. Resources...... 30 8.1.3. CPI extension...... 31 8.1.4. Teletop menu extension...... 31 8.1.5. Studiewijzer...... 32 8.2. Package content...... 33

0.1. VERSION SUMMARY

Versie Auteur(s) Omschrijving V0.1 – 21 June 2007 Erik Siegel First draft V0.2 – 29 June 2007 Erik Siegel Changes because of introduction studiewijzer editor V0.3 – 21 August 2007 Erik Siegel Major update, adding info for webschriften and –boeken + numerous small changes. V0.4 – 29 August 2007 Erik Siegel Several small but important specification changes. V0.5 – 15 October 2007 Erik Siegel Small usability changes. V0.6 – 22 October 2007 Erik Siegel A menu extension is mandatory for all assemblies: par. 8.1.4/pg. 32. V0.7 – 6 February 2008 Erik Siegel Added support for the word recycler type: par. 5.3.1/pg. 21. All changes are marked yellow. V0.8 – 5 June 2008 Erik Siegel Error in wordrecycler specification removed: par. 5.3.1/pg. 21.

1. INTRODUCTION

This document describes the process for creating content packages for Smart-e. In a nut- shell: . With Mentor, authors and editors create content. This content consists mainly of QTI type questions, but other kinds of data are also possible. . This content is stored in workspaces in Mosaic. Assets (images, audio, film) are stored in Mosaic. . There is an assembly process that combines the data from several workspaces into a SCORM Content Package. This includes generation of additional data like CPI’s, “studiewijzers”, etc. This assembly process is not as straightforward is it seems. Several conversions, look ups and the addition of external files complicate it. For the first version of Smart-e/Mentor, this assembly process will be a (light weight) build-in part of Mentor. However, for the future, the assembly will be done by a separate system, the assembly system. This document describes the assembly process in detail. With this description it must be possible to design and implement the assembly system for Smart-e. Because this will be done by a foreign company, the document is in English. Goal for this document is to describe the Smart-e/Mentor assembly process in enough detail for a developer to implement it. Main target group for this document are therefore the designers/developers of the assembly process and the people around them (managers, architects, etc.) who have to understand what’s going on. The reader is expected to have some background in Smart-e and the technology involved. An introduction can be found in [1]. To understand the codes and coding standards, please read [2]. These documents are in Dutch.

1.1. ADDITIONAL DOCUMENTATION

[1] Smart-e – Systeem architectuur Erik Siegel, Frank Aarts; Mei 2007 [2] Smart-e – Informatiestromen oplevering Erik Siegel; Juni 2007 [3] Documentum webservices – Technical documentation Erik Siegel, Jos Persoon; May 2007 [4] Mosaic webservices – Technical documentation Erik Siegel; April 2007 [5] Smart-e Webtoetsen CP description Erik Siegel; June 2007

2. DATA AND WORKSPACES

This chapter describes the starting point for the assembly operation: The data (and metadata) stored in workspaces.

2.1. OVERALL STRUCTURE

. Smart-e works in units called “streams”. . A stream contains all materials for a product/school-type/school-year combination . A stream consists of five separate components. . Each component is stored in a separate workspace. Component Workspace name suffix Basis ICT opdrachten; webopdrachten wo Webschriften ws Webboeken wb Webtoetsen wt Docenten basismateriaal db . Every component and so every workspace type has different types of content. . There are naming conventions for workspaces, streams, etc. These are described in detail in [2]. . Watch out: Due to historic reasons, naming conventions for streams and workspaces differ! An example of a stream name would be: geo_e2_havo4_m1 This would result in five workspaces called: smarte_geo_e2_havo_4_m1_wo smarte_geo_e2_havo_4_m1_ws smarte_geo_e2_havo_4_m1_wb smarte_geo_e2_havo_4_m1_wt smarte_geo_e2_havo_4_m1_db

2.2. WORKSPACE STRUCTURE

Workspace

Organization Item file Item file Item file file (XML) (XML) (XML) (XML) File metadata File metadata File metadata File metadata

Workspace metadata

. Workspaces are stored in the content management system Documentum . Conceptually, a workspace can be seen as a single directory with files (but without sub-directories), with the following additional functionality: . A set of metadata for the workspace . A set of metadata for each file . Each file is version managed (older versions of the file are kept and can be restored if necessary) . Each workspace contains an organization file (organization.xml). This file holds the organization of the item files (which belong together, etc.). It also serves as an index to the item files. . Important: The organization file defines the hierarchy of the workspace. . Workspaces only store the textual (non-asset) data for a stream. All assets are stored in the asset management system Mosaic.

2.3. ASSETS

Mosaic Workspace

Asset Asset metadata

Item file (XML) File metadata

Asset Asset metadata Workspace metadata

. Assets are stored in the asset management system Mosaic (not in a workspace) . Item files can contain references to an asset stored in Mosaic. . Assets also have metadata attached.

2.4. METADATA DETAILS

2.4.1. WORKSPACE METADATA . A workspace has the following metadata fields (See [3] for more details): Field Description workspaceId Primary key to the workspace. This is a hexadecimal string, e.g. 0b014f3d800d53d4 created Creation date for this workspace (kept by Documentum) name The name of the workspace archived Whether or not the workspace is archived. Values are true or false. role The role of a user for this workspace planId Information about the educational usage/purpose of the workspace. educationLevel organizationId method educationYear

. Here is an example of the XML profile that comes back on a getWorkspace SOAP call on Documentum. This response shows the available metadata for a workspace called test_degeoob_e8_bk_1_wo through the webservice interface: 2007/06/11 11:06:00 flexible vmbo-bk false test_degeoob_e8_bk_1_wo De geo onderbouw 1 0b014f3d80021a80 Every workspace contains a file called organization.xml. The metadata of this index file also contains workspace related values.

2.5. FILE METADATA

A file has the following metadata (See [3] for more details): Field R/O? Description id Yes Primary key to the file. This is a hexadecimal string, e.g. 0b014f3d800d53d4 document The document itself created Yes The file’s creation date/time. Kept by Documentum. owner Yes The userId of the owner of the file lockOwner Yes If a file is locked, this field returns the full user information of the user who has locked it version Yes Format: x.y size Yes The size of the document in bytes locked Yes Whether the file is locked. false or true attributes Yes An XML construction with all the attributes of the file. (?) name Other information about the file (mostly free text fields) title educationLevel theme documentType

Field R/O? Description status contentType language profile educationYear modified creator description subject method

. Here is an example of the XML profile that comes back on a getFile SOAP call on Documentum. This response shows the available metadata for a file through the webservice interface. . Please note that there are two ways metadata is encoded: . Fields with a fixed element name, like title of status . Fields encoded in elements This separation has historical reasons. Both types of fields are however equally important and should be treated the same. 2007/06/11 11:59:04 text Hfst 1 Edward via nieuwe map evwester text definitive xml text-text 09014f3d80021a90 1.0 2007/06/12 15:12:26 age 12-16 . . . evwester false … Dit is het eerste hoofdstuk met een intro 256 Hfst 1 Edward via nieuwe map

2.5.1. ASSET METADATA Assets also have metadata. This list, however, is rather long. For more details, please refer to [4].

3. THE OVERALL ASSEMBLY PROCESS

The overall assembly is as follows:

Mentor

Documentum

Workspace Workspace Workspace Workspace Workspace Workspace Studiewijzers Webopdrachten Webschriften Webboeken Webtoetsen Docentmateriaal

Optional conversion Assembly step 1

Webopdrachten Webschriften Webboeken Webtoetsen Docentmateriaal CP CP CP CP CP

Assembly step 2

Webtoetsen CP for app

Combined CP

To Webtoetsen application

To Exploiation server/Teletop/ELO's Important remark: For now the workspaces for “Webtoetsen” and “Docentmateriaal” are not described yet. The first release of Smart-e will not use these (other mechanisms are used to provide this information). Content generation and assembly: (from top to bottom) . The users (editors, writers) work with Mentor to create/edit the content. . The Mentor application uses Documentum and Mosaic (not shown) for storage. . In Documentum, every type of content for a stream is stored in a separate workspace (the white workspaces in the diagram above). . The assembly process step 1 takes the content of each workspace for a stream and makes a CP for each of them. Since the content structure for each type of workspace differs, all five CP’s are structured differently also. . The assembly process step 2 takes these five CP’s and combines into one, SCORM compliant, CP. . For some workspaces (currently for Webtoetsen), another output is needed: A separate CP with content for the application that handles it (see also [5]).

P A G E 1 0 O F 3 4 S M A R T - E - A S S E M B L Y P R O C E S S D E S C R I P T I O N V 0 . 8 - 5 J U N E 2 00 8 C O M B I N I N G T H E S E P A R A T E C P ’ S

Studiewijzer (Teletop roster) generation and assembly: A “studiewijzer” (or Teletop roster) is a list of actions for the students. This is created from the content of the other workspaces. . A process generates a default studiewijzer from the contents of the stream workspaces. . This generated studiewijzer can be edited by hand and is stored in a special workspace (the grey workspace in the diagram above). . When there is new content and the studiewijzer is re-generated, changed and added lines will not be affected. . The studiewijzer must be part of the final CP, so, after a possible conversion process, it is inserted in this CP in assembly step 2 (as a manifest extension).

Short qualitative description for every type (colored cells mean “to be determined”): Type Content of workspace Content of separate CP Content of CP for app Webopdrachten XML files for the ques- A SCORM CP with the - tions and tests in the Proctor player and all webopdrachten files transformed into playable content. In- cludes assets Webschriften XML files with no inter- HTML files that link to - esting content. The the webschrift metadata contains the URL to the right webschrift. Webboeken XML files with a refer- All referenced PDF’s. - ence to the PDF file The studiewijzer contains a line per PDF. Webtoetsen Postponed to next ver- Postponed to next ver- A CP with all files sion sion transformed to QTI type. Includes assets (described in [5]) Docentmateriaal Postponed to next ver- Postponed to next ver- - sion sion

4. GENERIC CONTENT PACKAGE COMPONENTS

This chapter describes the generic content package components: The parts the CP that will always be the same, regardless of which type of workspace is transformed.

4.1. MANIFEST FILE

A CP must have a manifest file called imsmanifest.xml. It consists of the following components: Manifest file component Remarks Header Generic, contains declarations of namespaces, etc. Metadata Generic, this is the metadata for the complete CP. Organization Workspace type dependent Resources Workspace type dependent Extensions Workspace type dependent. Used for things like authorization info (CPI’s), Teletop rosters (“studiewijzer”), etc.

4.1.1. MANIFEST FILE HEADER

Namespace declarations: The following namespaces must be declared: Namespace Proposed Schema name Description prefix http://www.imsglobal.org/ none, imscp_v1p1.xsd Default content package xsd/imscp_v1p1 default manifest schema http://www.adlnet.org/xsd/ adlcp adlcp_v1p3.xsd SCORM content package adlcp_v1p3 extensions http://www.adlnet.org/xsd/ adlnav adlnav_v1p3.xsd SCORM content package adlnav_v1p3 navigation extensions http://www.w3.org/2001/ xsi - Namespace for pointing to XMLSchema-instance the appropriate schema files http://www.imsglobal.org/ md imsmd_v1p2p4.xsd Namespace for the LOM xsd/imsmd_v1p2 metadata

Namespace Proposed Schema name Description prefix http://www.thiememeulenhoff. cpi ThiemeMeulenhoffC Namespace for the Thie- nl/CpiExtension piExtension.xsd meMeulenhoff CPI information extension http://www.teletop.nl/roster roster Teletoproster.xsd Namespace for the Tele- top roster extension http://www.teletop.nl/menu menu Teletopmenu.xsd Namespace for the Tele- top menu extension The grey marked namespaces are specific namespaces for ThiemeMeulenhoff and are used to define extensions to the manifest. Schema locations: . An xsi:schemaLocation points to the accompanying schemas. . These schemas will be part of the CP and will always be stored in its root (par. 4.2.1/pg. 14). identifier . The (IMS CP mandatory) identifier for a Smart-e CP is (by convention) always equal to its filename. . The filename must satisfy the naming conventions in [2]: _ Examples: geo_e2_hv4_m2_v1s0 goforit_e1_kgt2_v2s3r17 carteorgange_e1_vwo3_v2s1

4.1.2. METADATA . The content package must contain metadata according to the LOM, using the more narrow specification from Edustandaard (www.edustandaard.nl) “Content-zoek- profiel PO-VO-BE”. . Because metadata must always survive the processing of the exploitation server, it will be embedded in the manifest (and not in an external, referenced, file). . Example section: ADL SCORM 2004 3rd Edition . Elements: Element Value Remarks ADL SCORM Fixed mandatory value for a SCORM package 2004 3rd Edition Fixed mandatory value for a SCORM package Metadata according to the Defined in an external file: LOM Metadata voor CP.xml

4.2. PACKAGE CONTENT

4.2.1. ROOT . The root of the package will always contain the following files. File(s) Description imsmanifest.xml Manifest file for the content package schemas Schemas for the namespaces referenced in the manifest file header (par. 4.1.1/pg. 12). . Watch out: Spaces in schema filenames seem to be illegal according to the ADL vali- dator. So don’t use them! . Example: For a CP with a manifest file header as described in par. 4.1.1/pg. 12, the following files will be present in the root: imsmanifest.xml imscp_v1p1.xsd adlcp_v1p3.xsd adlnav_v1p3.xsd imsmd_v1p2p4.xsd ThiemeMeulenhoffCpiExtension.xsd Teletoproster.xsd Teletopmenu.xsd When other content inside the package references schemas (e.g. the QTI files might), the root of the package is a good place to store these schema’s also. Of course, the references to these schema’s in the XML file must be relative (e.g. ../../../schema.xsd).

4.2.2. PACKAGE CONTENT GUIDELINESS . All other package content will be stored in subdirectories and never in the root of the package. . As described in chap. 3/pg. 10, the final CP will be a merge of several distinct CP’s. To make sure this merge will be as painless as possible, the first level sub-directory below the root will always be the workspace name. . Example for a “webopdrachten” CP: (root of package)  Files in root (par. 4.2.1/pg. 14) smarte_geo_e2_havo_4_m1_wo/ objects/ 09014f3d800fc329/  Files for this object/item 09014f3d800fd50d/  Files for this object/item system/  System files

5. CP TYPE “WEBOPDRACHTEN”

5.1. WORKSPACES FOR “WEBOPDRACHTEN”

Some additional details about the workspaces that store the content for “webopdrachten”: . The item files in workspaces for “webopdrachten” contain the XML representation for questions, tests (combinations of questions), additional files and groups (like chapters, paragraphs, etc.) . When the questions are used by the players, they should be in QTI format. However, QTI is too complex to be handled well (and user friendly) by the editor in Mentor. Therefore, a somewhat simpler, but QTI like, format is used. Let’s call this format MXML (Mentor XML) . There is an MXML Schema available, one for each file type stored in the workspace. . There is also an XSLT for each MXML file type that transfers the MXML: . To real QTI for questions and tests . To something else (might be a zero operation) for other file types. . The MXML file type is stored in the metadata field profile. . Watch out: V0.7 of this document introduces two special MXML file types dictionary and recycler that need very special handling! Refer to par. 5.3.1/pg. 21 for more detail.

5.2. MANIFEST FILE COMPONENTS

See also par. 4.1/pg. 12 for the generic parts of the manifest file.

5.2.1. ORGANIZATION . The organization is used by other (non-Teletop) SCORM player when accessing the CP. It is used for displaying the structure of the SCO’s in the CP. . There will only be one organization (SCORM recommendation). . The default attribute of the element will refer to this organization using the value of it’s identifier attribute. . Organization structure: Title metadata of workspace Concatenation of: - Numbering dependent on chapter/paragraph hierarchy for this test (e.g. 1.2, 2.3, 3.1.2) (from the organization.xml) - Title metadata field - “Omschrijving/instructie” metadata field

. Example: Geo wenopdrachten 1.1 – Ga lekker wat doen – Maak de opdrachten …

Remark: Delivery to other ELO’s SCORM allows other, navigation related, information to be present in the organization. We might create these, but it depends on the ELO what the effect will be. Therefore it is not unlikely that for delivering to some other ELO, we need to slightly modify the manifest in an ELO specific way. This can be done by the assembly system

5.2.2. RESOURCES . Important assumption: The smallest unit of delivery is a test. A test consist of one or more questions. A test will become a single SCO. . This means that questions cannot be addressed separately. They will not be a SCO. . Watch out: Do not use backslashes (\)as path separator in file/path names. Always use slashes (/)! The resource section will contain the following types of resources: System resource: . This is a list of the files in the system subdirectory (par. 5.3.3/pg. 22) . It is nor an asset nor a SCO, so it cannot be launched and also has no metadata. . It will be referenced by most of the other resources in their elements. . Attributes on element: Attribute Value Remarks identifier res-system- Smart-e convention type other Fixed value (IMS standard) xml:base Points to the directory where Optional, but this will keep the path names the system files are (see in the elements short. par. ??/pg. 22): {workspacename}/system adlcp:scormType asset SCORM standard (every resource must have a scormType attribute) . Example: . . .

SCO test resources: . Test resources are SCO’s. They can be launched and have separate metadata. . The metadata is placed inline in the manifest file so it will survive the processing of the assembly server. . For details on the metadata, see external file Metadata voor test.xml

. This resource consist of: . The QTI assessment test file + assets . All QTI files with the questions within this test + assets . Additional files for this test (“Studiewijzer”, “bronnen”) + assets . Attributes on element: Attribute Value Remarks identifier Proposal: Anything that is unique (unique also res-objectidoftestitem when the workspaces are merged!) will do. The object id of the test item will always be unique. Prefixing it with res- makes it recognizable as a resource identifier. type webcontent Fixed value (IMS standard) href reference to the index.html file Starting point for this resource when for this test (par. 5.3.2/pg. 21): played in an ELO. {testitemfileid}/index.html adlcp:scormType sco Fixed value (SCORM standard) xml:base Points to the directory where the Optional, but this will keep the path system files are (see names in the elements par. ??/pg. 22): short. {workspacename}/objects . A test resource always depend on the system resource. So it must contain the following dependency: . Example: <-- Studieadvies item: --> <-- Bronnen item: --> <-- Question item in test: --> SCO Group resources . The specification for group resources is the same as for test resources, but group resources only contain one item (no sub items like questions, studieadvies or bronnen). . Groups reference other SCO resources. These references will be part of the object.xml file and need not to be reflected in the resource element.

. Example:

5.2.3. CPI EXTENSION . The CPI extension is a manifest extension for defining the authorization rules for this CP. More information can be found in [2]. . The extension defines its own namespace and an xsi:schemaLocation attribute pointing to the schema for the extension . The schema for this extension is included in the CP and stored in its root. . For webopdrachten, we need only one CPI group (please note, for a complete merged CP for a stream we need more. However, this will be done by the merge process so we can keep it simple here). Proposal: The name of this CPI group should be equal to the workspace name, prefixed with cpigroup- to make it recognizable as a CPI group. . In [2] you can find a matrix that maps Smart-e components (like webopdrachten) on CPI’s. Webopdrachten will always be authorized for a stream, so all stream CPI’s should be listed. . The manifest extension should look like this: {CpiForBasis} {CpiForPlus} {CpiForSolowebboek} {CpiForSolowebschrift} {CpiForDocentbasis} {CPiForDocentplus} . . .

. Example: geo_e2_havo_4_m1_b geo_e2_havo_4_m1_p geo_e2_havo_4_m1_wb geo_e2_havo_4_m1_ws geo_docent geo_docentplus . . .

5.2.4. TELETOP MENU EXTENSION . Every Smart-e assembly must have one and only one Teletop menu extension. Refer to par. 8.1.4/pg. 32.

5.2.5. STUDIEW IJZER . The Teletop roster extension is a manifest extension for defining the Teletop roster (“studiewijzer”) in the default ELO for Smart-e. More information can be found in [2]. . The schema for this extension is included in the CP and stored in its root. . As described in chap. 3/pg. 10, the studiewijzer is generated from the workspace content. After this, it can be hand edited. Header . The header of the roster however is the same for all packages:

Studiewijzer for webopdrachten: . Only SCO resources (see par. 5.2.2/pg. 16) will result in a line (row) in the Teletop roster. . So SCO group resources will not be present in the studiewijzer (although they are present in the organization, par. 5.2.1/pg. 15). . An example:

. cell3 content must contain a reference to an icon. This should be coded as HTML inside the element. The < and > characters must be escaped: <img src=”url-to-img” alt=”webopdracht”> The URL to the image is: http://assets.thiememeulenhoff.nl/assets/smart-e-icons/wo.gif

5.3.1. WORDRECYCLER HANDLING The types added for the wordrecycler need special treatment: Dictionary files: Dictionary files (profile name dictionary) contain lists of words. They do not appear in the CP (not as a file and not in mentioned in the manifest). Word recycler files: Word recycler files (profile name recycler) reference one or more (parts of) dictionary files. These files result in multiple files in the CP: . A file that represents a test (SCO test). This will result in: . An item subdirectory, containing the necessary files (par. 5.3.2/pg. 21). . Entries in the CP manifest this file (like every other test file) in the (par. 5.2.1/pg. 15) and in the (par. 5.2.2/pg. 16 under “SCO test resources”) section; exactly like a test that comes directly from Mentor. . Every word referenced in the dictionary(ies) will generate a separate QTI item file. This will result in: . An item subdirectory, containing the necessary files (par. 5.3.2/pg. 21). . Mentioning these files in the for the generated SCO test file (par. 5.2.2/pg. 16 under “SCO test resources”). . Mentioning these file in the resource section of the test these words belong to.

5.3.2. ITEM SUBDIRECTORIES . Every item file in Documentum will result in a separate subdirectory in the content package. . Proposed naming convention: /{workspacename}/objects/{itemfileid}/ Examples: smarte_geo_e2_havo_4_m1_wo/objects/09014f3d800fc329/ smarte_geo_e2_havo_4_m1_wo/objects/09014f3d800fd50d/ . Adding the workspace name to the directory path is done so we can more easily merge CP’s together that have been generated from different workspaces. . Please note that the hierarchy as found in the workspace organization.xml is not reflected here. This is “just” a linear list of items/objects.

. Within this item subdirectory the following files: File(s) Description Where from? Detailed info object.xml This is the file that contains the Result of a conversion of par. 5.4.1/pg. 22 content and is used by Proctor to the item file + additional display things. If the item is a data question or test, it will be in QTI format. Otherwise, the format will be Proctor defined. configuration.xml Parameter file for Proctor. Generated from the par. 5.4.2/pg. 23 metadata index.html Only for items that will become Generated from a tem- par. 5.4.3/pg. 23 separate SCO’s: tests and groups. plate file HTML file that serves as a starting point when this item is used a separate SCO. assets All assets referred to by Downloaded from Mosaic object.xml.

5.3.3. SYSTEM . The CP will contain a system subdirectory that holds all Proctor and related files. . Proposed naming convention: /{workspacename}/system/ Example: /smarte_geo_e2_havo_4_m1_wo/system/ . Adding the workspace name to the directory path is done so we can more easily merge CP’s together that have been generated from different workspaces. . The content of the system directory depends on the Proctor player/configuration that must be used for this workspace. Information about this is found in the workspace configuration file (plan.xml).

5.4. FILE CREATION/GENERATION

5.4.1. OBJECT.XML This document will not go into the transformations in detail. However, the generation of the object.xml needs a lot of information: Information source Reason/remarks Object item file Main source for transformation Item metadata Needed to fill in several fields Workspace metadata Needed to fill in several fields Workspace organization (organization.xml) Needed to find references to possible children (for chapters, tests, etc.) Other item files + metadata Needed to create the references to possible children (for chapters, tests, etc.) Workspace structure (plan.xml) Needed to find information about what this item is

Important: . Some object.xml files (depending on their type) will need an extra style sheet reference in the object.xml. These style sheets always reside somewhere in or under the system folder. Example:

5.4.2. ITEM CONFIGURATION FILE . This is a Proctor specific configuration file. . Example: ../../system/style.xml object.xml Methode Titel . Root element is always . Contents (fixed): Element Content Name and path for a file with the fixed name style.xml, residing in the system folder (par. 5.3.3/pg. 22) of the package Name of the Proctor data file. Currently fixed to object.xml Metadata field method from the workspace metadata. Example: De geo onderbouw Metadata field title from the item metadata Example: Woordkennistest 1 (optional) A reference to additional information in the books. Currently not used and will be absent.

5.4.3. INDEX.HTML

. The index.html is the start for this SCO. . At this moment, index.html is a static (fixed) file. . However, this might change in the future. Therefore, it is recommended that, within the assembly process, a generation script for index.html is added. . Possible inputs for this generation script are the same as for the object.xml (see par. 5.4.1/pg. 22).

6. CP TYPE “WEBSCHRIFTEN”

6.1. WORKSPACES FOR “WEBSCHRIFTEN”

. There are two types of item files for “webschriften”: . Groups (like chapters, paragraphs, etc.). Only the metadata is interesting, the content can be ignored. . Webschrift links. Only the metadata is interesting (contains the URL to the actual webschrift in a field called ).

6.2.1. ORGANIZATION . There will only be one organization (SCORM recommendation). . The default attribute of the element will refer to this organization using the value of it’s identifier attribute. . Organization structure: Title metadata of workspace Concatenation of: - Numbering dependent on chapter/paragraph hierarchy for this webschrift (e.g. 1.2, 2.3, 3.1.2) (from the organization.xml) - Title metadata field - “Omschrijving/instructie” metadata field . Example: Geo wenopdrachten 1.1 – Ga lekker wat doen – Lees het webschrift …

6.2.2. RESOURCES A webschrift will become a single SCO: . Only the links to the webschriften will become a SCO. Group information will not be transformed into SCO’s. So watch out: Not all item files should be transformed into resources, only the item files that contain actual references to webschriften! Group/structure item files can be ignored. . The metadata is placed inline in the manifest file so it will survive the processing of the assembly server. . Metadata generation is equivalent to the webopdrachten metadata. . This resource consist of a single HTML file that links to the actual webschrift resource (through the URL given in the metadata of the item). . Attributes on element: Attribute Value Remarks identifier res-objectidofwsitem The object id of the test item will always be unique. Prefixing it with res- makes it recognizable as a resource identifier. type webcontent Fixed value (IMS standard) href reference to the index.html Starting point for this resource when file for this webschrift played in an ELO. index.html adlcp:scormType sco Fixed value (SCORM standard) xml:base Points to the directory where the Optional, but this will keep the path files are names in the elements short. {workspacename}/objects/ objectidofwsitem . Example:

6.2.3. CPI EXTENSION . For webschriften, we need only one CPI group (please note, for a complete merged CP for a stream we need more. However, this will be done by the merge process so we can keep it simple here). The name of this CPI group should be equal to the workspace name, prefixed with cpigroup- to make it recognizable as a CPI group. . In [2] you can find a matrix that maps Smart-e components (like webschriften) on CPI’s.

. The manifest extension should look like this: {CpiForPlus} {CpiForSolowebschrift} {CPiForDocentplus} . . . . Example: geo_e2_havo_4_m1_p geo_e2_havo_4_m1_ws geo_docentplus . . .

6.2.5. STUDIEW IJZER FOR W EBSCHRIFTEN Identical to webopdrachten. All webschrift references will result in a row (line) in the studiewijzer. See par. 5.2.5/pg. 19. . cell3 content must contain a reference to an icon. This should be coded as HTML inside the element. The < and > characters must be escaped: <img src=”url-to-img” alt=”webschrift”> The URL to the image is: http://assets.thiememeulenhoff.nl/assets/smart-e-icons/ws.gif

. The item files in Documentum that contain a webschrift link will result in a separate subdirectory in the content package. So group item files will not result in a subdirectory. . Naming convention: /{workspacename}/objects/{itemfileid}/ Examples: smarte_geo_e2_havo_4_m1_ws/objects/09014f3d800fc329/ smarte_geo_e2_havo_4_m1_ws/objects/09014f3d800fd50d/ . Adding the workspace name to the directory path is done so we can more easily merge CP’s together that have been generated from different workspaces. . Please note that the hierarchy as found in the workspace organization.xml is not reflected here. This is “just” a linear list of items/objects. . Within this directory a single file called index.html . index.html should do/contain the following: . Immediately, after zero seconds, (through a meta tag) refer the browser to the URL of the webschrift. . Display a text like: Als u niet automatisch wordt doorverwezen naar het webschrift, klik dan hier and of course clicking “hier” takes you to the webschrift”

7. CP TYPE “WEBBOEKEN”

7.1. WORKSPACES FOR “WEBBOEKEN”

. There are two types of item files: . Groups (like chapters, paragraphs, etc.). Only the metadata is interesting, the content can be ignored. . Webboek item files. These files contain metadata and, as content, a link to a PDF resource: . A webboek item file contains only a single reference to a PDF file . The actual PDF files are stored in Mosaic.

7.2.1. ORGANIZATION . There will only be one organization (SCORM recommendation). . The default attribute of the element will refer to this organization using the value of it’s identifier attribute. . Organization structure: Title metadata of workspace Concatenation of: - Numbering dependent on chapter/paragraph hierarchy for this webboek (e.g. 1.2, 2.3, 3.1.2) (from the organization.xml) - Title metadata field - “Omschrijving/instructie” metadata field . Example: Geo wenopdrachten 1.1 – Ga lekker wat doen – Lees het webboek …

7.2.2. RESOURCES Every reference to a webboek PDF file will become a SCO: . Only the links to the webboek PDF’s will become a SCO. Group information will not be transformed into SCO’s. So watch out: Not all item files should be transformed into resources, only the item files that contain actual references to webboeken! Group/structure item files can be ignored. . The metadata is placed inline in the manifest file so it will survive the processing of the assembly server. . Metadata generation is equivalent to the webopdrachten metadata. . The resource consists of the actual PDF file . Attributes on element: Attribute Value Remarks identifier res-objectidofwsitem The object id of the test item will always be unique. type webcontent Fixed value (IMS standard) href reference to the PDF file Starting point for this resource when played in an ELO. adlcp:scormType sco Fixed value (SCORM standard) xml:base Points to the directory where the Optional, but this will keep the path files are names in the elements short. {workspacename}/objects/ objectidofwsitem . Example:

7.2.3. CPI EXTENSION . For webboeken, we need only one CPI group (please note, for a complete merged CP for a stream we need more. However, this will be done by the merge process so we can keep it simple here). The name of this CPI group should be equal to the workspace name, prefixed with cpigroup- to make it recognizable as a CPI group. . In [2] you can find a matrix that maps Smart-e components (like webboeken) on CPI’s. . The manifest extension should look like this: {CpiForPlus} {CpiForSolowebboek} {CPiForDocentplus}

. . . . Example: geo_e2_havo_4_m1_p geo_e2_havo_4_m1_wb geo_docentplus . . .

7.2.5. STUDIEW IJZER FOR W EBBOEKEN Identical to webopdrachten. All webboek PDF’s will result in a row (line) in the studiewijzer. See par. 5.2.5/pg. 19. . cell3 content must contain a reference to an icon. This should be coded as HTML inside the element. The < and > characters must be escaped: <img src=”url-to-img” alt=”webboek”> The URL to the image is: http://assets.thiememeulenhoff.nl/assets/smart-e-icons/wb.gif

. The item files in Documentum that contain a pdf link will result in a separate subdirectory in the content package. So group item files will not result in a subdirectory. . Naming convention: /{workspacename}/objects/{itemfileid}/ Examples: smarte_geo_e2_havo_4_m1_ws/objects/09014f3d800fc329/ smarte_geo_e2_havo_4_m1_ws/objects/09014f3d800fd50d/ . Within this directory the PDF file referenced.

8. COMBINING THE SEPARATE CP’S

This chapter describes how to combine the separate CP’s into one big CP (assembly step 2 in the overview in chap. 3/pg. 10).

8.1.1. ORGANIZATION . All separate organizations must be merged into a single organization. . For the organization’s title we use the title from the webopdrachten workspace . Organization structure: Title metadata of webopdrachten workspace

8.1.2. RESOURCES . All resources in the separate CP’s should be transferred to the combined CP:

8.1.3. CPI EXTENSION . All CPI groups in the separate CPI extensions should be transferred to the combined CPI extension . All resource/CPI group links should be transferred to the combined CPI extension

8.1.4. TELETOP MENU EXTENSION . The Teletop menu extension is a manifest extension for defining the Teletop menu in the default ELO for Smart-e. More information can be found in [2]. . The extension defines its own namespace and an xsi:schemaLocation attribute pointing to the schema for the extension . The schema for this extension is included in the CP and stored in its root. . The menu contains a logo attribute (the name of a file containing the logo for this stream). For now, this is fixed to: http://assets.thiememeulenhoff.nl/assets/smart-e-logos/{streamname}.jpg For example: http://assets.thiememeulenhoff.nl/assets/smart-e-logos/geo_e2_havo4_m1.jpg . For now, the contents of the basic menu extension is:

. The following two lines should be added to this menu. These lines will open pages on another website. This must be done in a new window, The code for this is a target=”new” attribute. . A link to the docentenmateriaal. This stored in Boardwalk (the ThiemeMeulenhoff website CMS) under a page name equal to the CPI for docent basis: Docentmateriaal For now, the href above should be: http://www.smart-e-online.nl/smart-e/pagina.asp?pagnaam={docentbasiscpi} For example: http://www.smart-e-online.nl/smart-e/pagina.asp?pagnaam=geo_docent . A link to the toetsenbank. This stored in Boardwalk under a page name equal to the CPI for docent plus: Toetsenbank For now, the href above should be: http://www.smart-e-online.nl/smart-e/pagina.asp?pagnaam={docentpluscpi} For example: http://www.smart-e-online.nl/smart-e/pagina.asp?pagnaam=geo_docentplus

8.1.5. STUDIEW IJZER . All studiewijzer rows must be transferred to the combined studiewijzer. . The generic part can be copied from the webopdrachten workspace.

Since we have done our best to use distinguishing directory names in the separate CPs, all package content can simply be copied to the combined CP. An example:

/(root of package)  Files in root imsmanifest.xml (combined) imscp_v1p1.xsd adlcp_v1p3.xsd adlnav_v1p3.xsd imsmd_v1p2p4.xsd ThiemeMeulenhoffCpiExtension.xsd Teletop roster.xsd Teletop menu.xsd

/smarte_geo_e2_havo_4_m1_wo/  Content for webopdrachten objects/ 09014f3d800fc329/  Files for this object/item 09014f3d800fd50d/  Files for this object/item system/  System files

/smarte_geo_e2_havo_4_m1_ws/  Content for webschriften objects/ 09014f3d800fc3aa/  Files for this object/item 09014f3d800fd5bb/  Files for this object/item

/smarte_geo_e2_havo_4_m1_wb/  Content for webboeken objects/ 09014f3d800fc3cc/  Files for this object/item 09014f3d800fd5cd/  Files for this object/item

P A G E 3 4 O F 3 4