OnePage Documentation

November 24, 2015

All Documentation


Copyright © 2014 (Inception year 2014 ) FORGE FP7 Project

Please send comments on this specification to the <> list.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Permission to use, copy, modify and distribute the accompanying documentation for any purpose and without fee ishereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies.

1.1 Preface

Forging Online Education through FIRE (FORGE) is a project bringing the FIRE and eLearning worlds together. FORGE will align FIRE (Future Internet Research and Experimentation) with the ongoing education revolution. FORGE is an FP7 funded project . FORGE’s major objective is to create processes, methods and tools and provide an ecosystem for introducing the eLearning community to the FIRE experimental facilities and promote the concept of experimentally driven research in education. Pilot courses have been defined (in the scope of WP5) and will be used as an interactive learning and training channels for both students and professionals by raising the accessibility and usability of FIRE facilities.

FORGE focuses on defining: generic concepts around courses, initial details about widgets and FIRE adapters and an overall architectural solution called FORGEBox. FORGEBox will be an aggregation of services able to support all FORGE concepts and requirements, learning widgets, FIRE adapters and solve most of our identified challenges. FORGEBox will be delivered as a middleware solution, deployed into institutions executing courses or into a Cloud infrastructure, bridging the interfaces between learning means and FIRE tools and facilities. FORGE also defines the architecture of common repositories of courses, widgets and FIRE adaptations and how our FORGEBox solution interoperated with all these aspects. All the above concepts are presented and discussed in this deliverable.

FORGE has to provide some technologies to cover the whole lifecycle of remote experimentation on FIRE facilities to learners. Widgets have been conceived as the means to present tools and infrastructure access in a more friendly way, via web tools independent of the underlying platform. FIRE Adapters will try to wrap and adapt FIRE APIs to a set of common tools (scripts, libraries) used by these widgets. Therefore an environment (in terms of middleware) could be provided in order to host widgets, FIRE Adapters and any tools and utilities that will ease the proposed FORGE process. This architectural approach is called FORGEBox.

2 Download FORGEBox

You can download the FORGEBox setup via GitHub.

You can also find some instructions how to setup FORGEBox from GitHub or in this documentation.

3 User Manual


3.1 Learners

The user can register to FORGEBox via the form registration, or login with gmail account or with GRNet login as a member of Greek Universities.

With any way you loged in, you have the role of Learner and the only action that you can do is to see Interactive courses that are not publish to anonymous users.

3.2 Instructors/Designers

The instructors/Designers have many functionalities in FORGEBox. They have full permission in the section Courses. They can create parts, interactives or presentations and a hole Interactive course Modules. They have a list of interactive course that they create, export to epub file or scorm file, edit preview and deleted. They have also as an option the choice to publish an Interactive course to anonymous user or only in register user. They can see analytics from the Interactive courses, add it in an LMS as a scorm file or as a external tool. 

Also in section Widgets an Instructo/Designer can install Widgets o his account, they can se all installed widgets in a table, and of course all the widgets can use it as an interactive part in a course module as many time as you want.


3.2.1 Interactive Course Module overview

An Interactive Course Module in the FORGEBox platform use a lot of learning technologies which its availiable until now. In this section we tried to describe which are that technologies.

When you create an interactive course module in the second frame there is some metadadata known as Learning Resource Metadata Initiative (LRMI). The Learning Resource Metadata Initiative (LRMI) is a project to establish a common vocabulary for describing learning resources. More information you can see in

A course module consists of "Presentation parts" and "Interactive parts" (widgets). That parts are reused.

When you finish the interactive course module you have several options like export the course as an epub file and you can see it in a epub reader. Also you can export as scorm file and you can add it in a Moodle LMS.

We also use learning analytics in any intaractive course module, and we also export to a file to uploaded at FORGEStore, install it from FORGEStore to FORGEBox.Also we use Interoperability tool like Learning Tools Interoperability (LTI) to connect with your Moodle LMS in FORGEBox with your Moodle account and use the interactive course module as an external tool.


3.2.2 Create an interactive course module

If you want to create or edit a course you have to go in section Course -> My Courses.

There you can see the course that you have created and you can edit or create a new.

The course that you have created you can do some action like :


Download Scorm file

Download epub file

See the parts of the course module



If you want to create a new course module you click the button "New Course Module".

You must fill some fields like Title, Description, the category that owned the course module and some of the LRMI metadata. When you finish with editing you press save to save the course module.

When you create a new interactive course module you can add Presentation parts and Interactive parts and you can rearrange with drag and drop method.

In the section Courses -> My Course Modules you see a table view with all your Interactive courses. In the column Parts, you can click the image and you start additing interactives and presentation parts as you see below.

When you select all the parts and re-ordered as you want, with drag and drop method you press save and you have an insteractive course module.

Then if you return to Courses -> My courses modules section and click the image with the pencil ,, you can edit the course.

In the buttom of edit form you can find some extra features that is Create epub file, scorm file change author and add LRS in youw Interactive course module.



3.2.3 Learning Analytics

Learning analytics is the measurement, collection, analysis and reporting of data about learners and their contexts, for purposes of understanding and optimising learning and the environments in which it occurs.

FORGEBox is compatible with Learning Analytics.


Instructors can create LRSs (Learning Record Store).

If you don't have any Learning Analytics Repository you can try FORGEBox LRS to collect your records. How to use LRS

We have already install Learning Locker which is the Learning Analytics we use.



If you want to use our Learning analytics you have to create account in Learning Locker .

Then send an information email to tranoris [at] to give you the rights to use Learning Analytics platform.

To create an LRS you can select at the left menu the link Create new LRS.

You can create more than one LRS. Inside your LRS you can find information about xAPI Statements and of course you can the reporting guide to get some reports for your analytics. Using LRS at FORGEBox

Its very easy to configure your course that you create in FORGEBox with your LRS to store your Learning Analytics.

First of all you must have role permission to configure a LRS in FORGEBox.

To Configure you LRS you have to follow the next steps.

First go to System->LRS Configuration.

Then fill the fields below :

In the field LRS name you can write avery name you want, but at LRS Endpoint, Username and Password you get the information from LRS.

If you use Learning Locker that information are in the section "xAPI statements".

You can add more than one LRS in your account. In the page where you edit a course you find an area that you can select the LRS you want to use in that course and save your choice.


3.2.4 FORGEBox compatible with Moodle

The FORGEBox as LTI Provider can connect with any LTI Consumer (Learning Management Systems).

We have a Moodle setup and we add an interactive course as an external tool inside the moodle course module and work successfully.

You have all the advantages that an LMS gives to organize a course.

In the Figures that are below we give a help how can an instructor put the Interactive course from FORGEBox in moodle course module as an external tool.

First of all you select the course and "Turn editing on".

Click at link "Add an activity or resource" and in the pop menu select "External Tool"

Press add and then fill in the fields and save it.

In the field launch url just write the FORGEBox Interactive course URL.



3.3 Administrator


3.3.1 Using FORGEBox GettingStarted

You can use FORGEBox in many different ways, ranging from embedding Jetty in applications, launching it from different build systems, from different JVM-based languages, or as a standalone distribution. This guide covers the latter, a standalone distribution suitable for deploying web applications.

3.3.2 Customize FORGEBox

The FORGEBox customized from FORGEBox admin. There are several changes that you can do and organize the FORGEBox as a platform. You have a GUI to manage the roles, the access control, to create/install another course, to ceate and use widget and services.

User management

FORGEBox admins have lite user management that set roles to users.

If you go to System-> User management you can organize the permissions between users and roles. 



If someone register in FORGEBox the role that will assign to him is "Learner".

The learner must contact with FORGEBox admin to change his role.


Access Control

As FORGEBox admin you can visit the System -> Access Control and you can assign specific action to roles.

The image below view as the GUI that you can manage the Access control.


3.3.3 Widget Repository

The FORGEBox have two, by default, repositories that the Administrator, Designer and Widget provider have access to create, install, edit, delete etc.

The tow repositories are :

  • Local Repository (inside the FORGEBox) and have access only the members of FORGEBox
  • Remote Repository(FORGEStore) that have access many instants of FORGEBox.

In the section Widget-> Manage Widgets of local FORGEBox installation the user that have role Administrator, Designer or Widget provider can add a widget for local use.


3.3.4 Add a Widget

To add widget in the local repository at FORGEBox you have to select the section Widget -> Manage Widget of local FORGEBox installation.

There you can Add or edit your widget. The widgets can see only the user that are member in that FORGEBox instants and have the role Designer, Widget Provider and administrator.


3.3.5 Install a widget

At section Widgets-> Install New a user with the role Designer, Widget Provider and administrator can install widgets in their account and use it as interaction part inside a course module.

In the section Install New you can select between the local repository and the FORGEStore Repository.

To install a widget you have to find the widget that you are interresting, press "View Details"  and then install.

All the installed widgets you can find it in section "My Installed Widgets".

4 Developer Manual

If you are a developer you can setup the forgebox locally or over web.

After the installation you can manage FORGEBox, user, roles and others. Also you can create/install widgets and services to give instructors the tools to create interactive courses.

You can see more information about the documentation above this section.

4.1 The FORGEBox architecture

Figure 1.1. The FORGEBox architecture


The Figure provides a detailed view of FORGEBox proposed architecture. The figure displays also the concept of a FORGE repository that will host any shared published items such as Lab Courses, widgets and FIRE adapters to be used by the learning community and by other organizations hosting a FORGEBox instantiation. At its simplest form the core consists of services that make some tasks easier such as creating, managing and operating Lab Courses and their content as well as widgets and adapters. FORGEBox will contain a set of managing services, a Widgets layer, a FIRE adapters layer and a local repository of hosted Lab Courses.


FORGEBox managing services


A FORGEBox instantiation will contain a set of management services. A web control panel will be the mechanism to access and configure those services. Through these management services, FORGEBox admins will be able to perform the following tasks: - User management. Create and manage accounts for users that are Lab course assistants, or simple users that want to use FORGE technology - Manage FORGEBox services that can be exposed and used by other users. - Configure repository access. The admin can configure access points (i.e. URLs) that point to other FORGE repositories or even update and configure repositories content - FORGEBox updates. The admin can perform updates to any core services of FORGEBox

The widgets layer

Widgets usually provide interactive web content to learners. This means that access should be provided by web containers and web services. Therefore the widget layer will not be a specific service, but rather an abstract concept, since widgets can be provided by several web containers. As web containers can be consider for example the Apache server or Tomcat. However, we expect that a local repository will keep track of the deployed widgets.


The FIRE adapters layer


As widgets layer is a concept, the same also holds for the FIRE adapters’ layer. FIRE adapters can be developed in any language or hosted by some kind of container. Still, a local repository needs to be in place, to keep track of what is deployed and what can be exposed as a FIRE adapter service


Synergies between FORGE widgets, adapters and FIRE resources


When a lab course is executed by a learner, either via a LMS web page or an iBook there are some underlying interactions that happen between different components. Especially between widgets, adapters and the course related FIRE resources. Widgets, as envisioned by FORGE, are going to be the main element towards the Learner for accessing and manipulating some FIRE resource parameters through web pages, LMSs and iBooks.


A widget is a micro-application performing a dedicated task. This task can be as simple as showing news headlines or weather forecasts, but also more complex such as facilitating language learning or collaborative authoring. Widgets can be either desktop-based or web-based. Desktop-based widgets reside locally on a computer and may access the Web for information, such as a desktop widget can show the local temperature and weather forecast. Web-based widgets reside on the Web and can be embedded on a web page, such as an RSS reader widget that fetches news on your start page. Web-based widgets have proven quite popular as they enhance the interactivity and personalisation of web sites. The portability of widgets allows them to be embedded and used within different environments, either on the Web or the desktop. This has a great impact on the reusability of the learning solutions implemented as widgets.

A widget bundle is a set of widgets that complement each other and are utilised together for a common purpose. For example, a widget bundle for collaborative authoring can consist of widgets such as Google Docs and Google Talk.

A widget store is a directory of widgets. Widgets are commonly categorised within a widget store according to their purpose, e.g. widgets for planning, communication or collaboration. Users can browse and download widgets, as well as provide feedback on widgets in the form of ratings and comments. FORGE will develop a number of widgets that will expose FIRE facilities to learners and educators. These widgets will function as standalone learning applications that will be embedded inside eBooks using the Apple iBooks format [9] or more general formats like the ePub, as well as inside online courses that are delivered via Learning Management Systems (LMSs). FORGE will also develop an Educational Widget Store, where the widgets developed both by project partners and by external contributors will be made available to the public so that they can be downloaded and reused in different learning contexts.

FIRE adapters

A FIRE adapter is a service that enables a widget to communicate with the FIRE facilities with the functionality that is required for usage in an eLearning context. To this end, FIRE adapters will try to interact with the ‘Fed4FIRE APIs’ and ‘Fed4FIRE tools’ (see above).

These FIRE adapters can have different functionalities:

  • extend or add functionality of Fed4FIRE APIs and Fed4FIRE tools (only if needed and not possible within the scope of Fed4FIRE)
  • wrap the communication with the Fed4FIRE APIs and Fed4FIRE tools into a different format when required (e.g. to call Fed4FIRE APIs and tools from within a web page)

FORGE actors

The following actors using and interacting with the envisaged FORGE tools and services have been identified so far. It is assumed that an entity interacting with FORGE tools can have simultaneously different roles (i.e. Lab Course Designer and Assistant). However, by separating those roles will enable us to clearly distinguish between the required services.


Learner is the actor who utilizes FORGE provided tools and services in order to learn a specific subject following a course supported by some FIRE infrastructures. The Learner can use different means to access the courses: electronic books or LMS web pages and manipulate FIRE resources through widgets.

Lab Course Designer

Lab Course Designer is the actor responsible for designing a course and implementing it by using learning material (e.g. text, figures, videos), widgets and FIRE adapters. Lab Course Designers are responsible also for describing and publishing courses.

Lab Course Assistant / Teacher

This actor is responsible for the normal execution of a course. Lab Course Assistants/Teachers have different responsibilities, such as creating accounts for FORGE learners, scheduling and reserving FIRE resources (if not carried out automatically when a Learner starts a course), delegating control. They can provide support in teaching a class or in preparing material for remote users support. The lab course assistant needs to be aware of FIRE resources needs and must be capable of properly configuring the, through the FIRE adapters.

Widget Provider

Widget provider is an entity that develops and maintains widgets (usually for web consumption) providing a user interface for learners to manipulate the experimentation environment. Widget Provider is also capable of maintaining and publishing widgets to the widget repository.

FIRE Adapter Provider

This actor is responsible for developing and maintaining FIRE adapters, deployed into FORGE services like FORGEBox.

FORGEBox admin

Person responsible for maintaining a FORGEBox deployed instance on behalf of his organization. Usually also responsible for administering services and accounts (i.e. account for Lab Course assistants). He or she is also responsible for deploying widgets and FIRE adapters or delegating access to other roles.

4.2 Installing FORGEBox

Download the FORGEBox package from here.

Extract the package in the forder you want to install.

In the folder db_installation_script you can find the SQL script (filename : forgebox.sql).

Create a MySQL database and import the SQL script.

Now go back to the folder and rename the file conf.php.default to conf.php. The file found in folder functions.


Open the conf.php and fill the adove variables :


Database Host

Database username

Database password

Database Name

Site Installation

Site Note Teaser


If you want to login users with Google mail account you have to fill either the






Finally you have to change for some folders the permissions to read/write.

That folders are :







Your installation has finished.

You can logged in as administrator with the demo account :


username :

password : admin



4.3 Widgets at FORGEBox

What widget is?

The Widget is stand alone web application. The widget developed for a general or specific purpose and can used by the Instructors to interact with testbeds.

In FORGEBox we use the widget in iframe tag and learner can interactive with the lab. 

Mostly the widgets are developed with html5 and javascript to run over web without compatibility problems.

The widget can hsted everywhere. They can have user role, permission access and any policy from the creator.

At FORGEBox there are three roles that have access to a widget.

The Widget Developer : who develop the widget 

The Instructor : who can use the widget , configured and use it in his course as an interactive part.

The Learner : use it to execute exercises or labs as a part of them.


4.3.1 Widgets reference architectur

This section defines a generic reference architecture for developing widgets that are coupled with FIRE adapters to enable interaction with remote lab resources while integrating modern technologies from the education domain, like the LTI and Experience API. The proposed architecture intents to be a blueprint and a guide for widget developers that want to achieve the best result of supporting education on top of FIRE resources.

This figure refers to widgets as FORGE uses within the courses: consumable web applications that are hosted in a web server interacting with remote resources. In FORGE case, they are also a bind with FIRE adapters, the services that handle communication with remote FIRE resources. Next, when we refer to widgets, we refer to this combination of web content and backend support for remote interactivity through FIRE adapters.

In the above figure, displays our proposed reference architecture for a widget, with architectural components that a developer would need to implement in order to achieve the best desirable result of bridging learning with FIRE remote resource interactivity. Since widgets are web services hosted somewhere on the Internet ready to be consumed by other web content, the architecture defines both the widget UI as well as the backend domain logic and core architectural components. Next we discuss supported usage roles and each architectural component.

User roles that are able to use a widget

Widget Service administrator

Service Administrator is the user responsible for the whole widget web service. Service Administrator can login to the host machine and administer the service that provides the widget to consumers. Service Administrator can also manage for example users, registrations etc. The use cases are specific to the capabilities that the widget service will offer. E.g. the administrator of the ssh2web widget can allow specific domains that can use the service.

LMS/VLE administrator

This user is the one responsible to integrate the widget to the target learning system LMS/VLE or even in an eBook. He needs to pay attention to the widget documentation, how it is delivered (i.e. as a URL), its API, its LTI compatibility, etc. For example, an administrator responsible for a Moodle installation could visit FORGEStore and read the documentation of the widget. Then he could register the widget into the Moodle environment by using the LTI registration URL of the widget service.


This user will define the behaviour and settings for a specific course. He can also use the interface to reserve resources or setup the testbed.


This user will interact with the widget and the remote resource during the learning process.

Approach on creating widgets

FORGEBox architecture will not enforce specific methods of implementing and deploying widgets. This is left to widget developers to implement widgets in any programming language as long as they provide the best functionality and web access. The only constraint at this point will be to use open source tools and software. For example Apache and Tomcat could be used for web deployment and Java, PHP, ruby and Perl for widgets implementation.

Widgets, in general, consist of components built in XML, HTML, and JavaScript. XML is used to describe the specifications of the widget and contains instructions on how to process and render the widget. The XML description of the widget can contain all of the data and code of the widget, or it can have references (URLs) for where to find the rest of the elements. HTML is used to deliver the static content of the widget. Finally, JavaScript is used in order to add dynamic elements to the widget.


4.3.2 Widgets as LTI Tool Providers

In Figure below we see a Widget support the LTI standard

Another way to support interoperability between FORGE technologies and LMSs/VLEs is that widgets themselves support the LTI standard. Although this requires some extra implementation effort by the widget developer, LTI will allow widgets to be securely connected to the LMSs/VLE in a standard way without having to develop custom integrations. A widget therefore will have access to all the features and user information available from the LMS/VLE such as user account, and could also be used to provide feedback about user activity directly back to LMS/VLE.

LMS/VLE Administrators are responsible for registering a widget to their LMS /VLE. When a teacher is creating a course within the LMS /VLE, he needs to integrate and configure the widget with the course content.

An advantage of the widgets supporting LTI is that LTI provides flexibility to lab course designers. A disadvantage is that user experience is sometimes broken by LMSs/VLEs since they put in different web pages each widget and therefore you cannot have many LTI widgets in the same web page. The next example image shows where a widget is directly consumed by Moodle. A problem of Moodle is that it displays LTI tools in separate pages, therefore you cannot have multiple widgets on a single page.


4.3.3 Proposed User Interfaces for widgets

The widget UI is the main component that a user uses to interact with the widget. To behave correctly, the Widget service must know the context that it works under, in order to properly display the equivalent UI according to the user role. Thus, if possible, the widget should be aware of:

  • The consumer service into which it is hosted and operating (i.e. is it an LMS/VLE, the VLE url, an eBook, etc);
  • The kind of consumer (i.e. its capabilities, browser, tablet etc);
  • The identity of the current user and his role;
  • The current course (content or page reference).

All this information can be passed either through a widget API (e.g. passing URL parameters) or via more modern ways like the LTI API. According to the user role there should be different UIs. Thus some first requirements for a widget service should be:

It is not necessary for widgets to implement all these user interfaces. For example the FORGE widgets of Teacher Companion Lab courses don’t need to provide a Learner UI since they can be used only by Teachers.

Next sections present these proposed UIs and some minimum example functionality.

Service Admin UI

The administrators of the web service use this UI. Through this interface the widget administrator can manage for example:

  • The service, its specific entities and configures it;
  • All users and User policies;
  • LTI registrations;
  • All registered courses that consume service;
  • Backend connections etc.

The following figure is an example of a Service Admin UI, where the ssh2web administrator can manage all users and all registered systems.

In the above figure we see Service Admin UI of the ssh2web administrator.

LMS/VLE Consumer Admin UI

Through this user interface the administrator of a VLE can interact with the widget. For example the LMS/VLE administrator through this UI can:

  • Request to register (i.e. for LTI) the service for usage;
    • For example the administrator of Moodle can register the Widget via LTI in order all courses of Moodle to use the widget;
  • Configure the service for his LMS/VLE users;
  • Configure a globally xAPI end point for Learning Analytics usage in the LMS/VLE;
  • Monitor his users and assign policies or change roles (for LTI this could be done automatically for example).

Next figure displays an example of a Moodle Administrator using the ssh2web widget through LTI to administer his users. The widget has automatically recognized the user name (Admin User) and role (Instructor), which are provided by Moodle via the LTI2.0 API.

In that figure we see Moodle Administrator using the ssh2web widget through LTI

Teacher/Instructor UI

Through this user interface the Teacher/Instructor of a course that uses this widget could do the following:

  • Defines behaviour and settings for a specific course;
  • Schedules resources and setup the testbed;
  • Might assign users to exact resources (or leave it to assign them by the service).

Learner UI

Through this user interface the learner interact with the remote FIRE resource. Many examples have been presented so far in different deliverables.



4.3.4 Widget and Learning Analytics

For the prototype FORGEBox implementation running at we selected as an Learning Record Store (LRS) the Learning Locker solution. Learning Locker ( is a well-known open source LRS with very good support. Thus FORGEBox users that want to track learners need to have an account on the LRS. To properly use it, they need to configure the proper LRS API endpoint for their course as well as some authorization keys.

Widgets should also be configured properly, since they are web services running separately from the course content. For courses hosted in FORGEBox we have defined a very simple protocol. Widgets are embedded through the iframe tag thus FORGEBox passes four variables:

Url example :; 



For most widgets that are web based a simple javascript xAPI implementation should suffice. Since FORGEBox will be also an LTI 2.0 Tool Provider the user identity and his behaviour will be also tracked from the LMS/VLE

You can try this demo to see how you can send analytics from your widget to LRS.


4.4 Interoperability with LMSs and VLEs

Integrating FORGE technology with tools that organizations are using for deploying their courses, such as advanced Virtual Learning Environments (VLEs), will increase FORGE’s impact. Therefore within FORGE we need to consider: i) how FORGE content can be easily consumed by VLEs, ii) how widgets/FIRE Adapters can seamlessly exchange user information with the VLE and be integrated with the content provided by a VLE. The technologies considered for interoperability with VLEs are:

  • The Learning Tools Interoperability (API) and its latest version 2.0;
  • SCORM packaging.

The Learning Tools Interoperability (LTI ) is a specification that standardizes the APIs between LMSs and external tools, enabling external tools to function as if they were native tools inside the LMS. LTI has been developed by the IMS Global Learning Consortium, a non-profit member organisation with a mission to enable the growth and impact of learning technology in the education and corporate learning sectors worldwide. The IMS Global Learning Consortium develops open interoperability standards and supports their adoption with technical services and programs that highlight effective practices.

The LTI specifies a standard way of integrating learning applications with platforms like LMSs, portals, or other educational environments. As shown in Figure 3, the primary use case behind the development of the LTI specification is to allow the seamless integration of web-based, externally hosted applications and content with other platforms. For example, an interactive assessment tool or a virtual lab hosted by a LMS can be securely connected to another educational platform in a standard way without having to develop and maintain custom integrations for each platform.

In the figure below we see a usage scenario of the IMS LTI specification

LTI’s primary usage within FORGE exists on widgets and FORGEBox created content in order to integrate tools like FORGE widgets that enable the interactivity with FIRE remote testbed resources. LTI will allow FORGE widgets be securely connected and integrated to an educational platform in a standard way without having to develop and maintain custom integrations for each platform. In LTI these learning applications are called Tools (delivered by Tool Providers) and the VLEs are called Tool Consumers.

SCORM on the other hand will help FORGE content to be easily consumed by systems able to host SCORM content. SCORM stands for “Sharable Content Object Reference Model” and is all about creating units of online training material that can be shared across systems. SCORM defines how to create “sharable content objects” or “SCOs” that can be reused in different systems and contexts.

The main objectives of the SCORM standard are the easy portability of learning content from one LMS to another, as well as the reusability of learning objects. The metadata model of the LOM standard integrated in the SCORM supports the retrieval of learning objects. SCORM denominates the smallest unit that can be administered by an LMS as a SCO, which represents the lowest level of content granularity that can be tracked by an LMS. A SCO is independent of any learning context in order to be reusable for different learning purposes. SCOs can form learning or exercise units on a superordinate level.

SCORM is based on the following three components :

  • Content packaging: It refers to the packaging of all resources needed to deliver a course into a single zip file. The format for this file is described by the SCORM aggregate model, which is based upon the IMS Content Packaging Specification. The zip file contains not only the course files, but also an XML file, referred to as the manifest file, describing the course contents and content sequencing;
  • Runtime communications: These are conducted using two elements:
    • Runtime commands for communicating student information to and from the LMS;
    • Student metadata for storing information on individual students.
  • Course metadata: These are metadata packaged with a course when it is archived in a SCORM repository. These metadata enable a course author or student to search a learning repository and to identify the learning content they want to use or view. For example, the course title, description, keywords, etc. are all considered course metadata.



In the figure below we see a VLE user access to a FORGEBox course through LTI

The first usage of LTI is to support interoperability scenarios in order to allow LMSs/VLEs to consume course content directly from a FORGEBox instantiation. This is useful in cases like the deployment, where FIRE courses are hosted in a FORGEBox. In this case the whole FORGEBox will be offered as an LTI Tool Provider, thus the VLE will be able to consume the whole course together with its interactive widgets. For such cases, the VLE administrator will need to register the VLE to FORGEBox as a tool consumer and need to select courses that will be offered through the VLE. Any interactive content provided by widgets will function the same as it works when providing the course directly from FORGEBox.

An advantage of this approach is the direct simple consumption of a whole course with interactive elements and no further configuration. A disadvantage is that widgets cannot be directly manipulated by the VLE, but offered as it is through the FORGEBox provided course.

In the next figure, displays how a FORGEBox course is displayed in Moodle. Moodle via LTI is a Tool Consumer and FORGEBox is a Tool Provider. Through LTI user information is exchanged and thus Moodle users are able to access a FORGEBox course.