Data Model

Since the eLAT implementation is supposed to be independent from a particular VLE, we searched for a neutral (standardized) data model that supports all the major data types as well as an extension model to fit in special types. At the time of creating this data model, there was no established data format, which could be adopted. The orientation of data types, such as assessments and resources, towards a specific VLE, runs the risk to become dependent on this system. These systems are not designed for data collection and analysis. They are not designed for data mining. Hence, “its thorough analysis requires long and tedious preprocessing” (Krüger, Merceron, and Wolf 2010, p. 131)

SharePoint Moodle XML Files Mining3DB Evaluation3 Service3 Instances eLAT3Website Instructor Indicator3 Framework Visualizer Report3DB Report3 Service 1.3Extraction3&3

Transformation 2.3Validation3_&3Loading

4.3Execute3 Indicator 2.Configure33 Indicator 1.3Select3 Indicator3 3.3Request33 Evaluation3 7.3Show3 Visualization 6.3Query3 Report3Status 5.3Store3Result3 DataSet

For data mining, Krüger, Merceron, and Wolf (2010) present a data model to structure and export usage data, which comes from learning environments. Still, from this work’s point of view, they oriented the design of their data model to the LMS Moodle, which in turn is similar to SCORM. Hence, they took a lot of dependencies from the database structure of Moodle. Their data model did not allow for integration of more detailed information or extensions. Under these circumstances, the storage of personal data, such as gender, age or specific prior knowledge could not be implemented (Zielke 2011).

In the case of the first version of eLAT’s data model (Figure 17), we modeled a learning environment as a general virtual learning space dedicated to a specific course, which could be implemented in any VLE. Hence, the central element of the data model is the object ‘Learning Environment’. The ‘Learning Environment’ can include several objects of the types ‘User’, ‘Activity’, ‘Event’, ‘Assessment’, and ‘Area’, which are connected to lists of assets (resources)10.

Each user object corresponds to exactly one user identity (one person). But a user (one person) might have multiple identities, if she is taking several courses. The user object is assigned a pseudonymous user identifier to protect personal data. It also stores the role of the user, e.g., ‘instructor’, ‘tutor’ or ‘student’ and it can hold custom properties in ‘User Extension’, like gender, field of study, or additional information, which can be added to enhance the model for new analytics purposes. Sometimes users can have multiple roles within one course. For example, in L²P a teacher can additional book himself as a student in his virtual course room in order to have a student’s preview of what students can see. In this case, the role with highest privileges is used. This ensures that the activities of instructors are not mistakenly counted as a student’s activities (Zielke 2011). Also of central importance is the linkages of ‘User’ objects to ‘Activity’ objects and content, represented as ‘Asset’ in the data model. Thus, each activity – along with timestamp and user information – is clearly assigned to an actor and each object is assigned an owner (see ‘CreatedBy’ field in Figure 17). ‘Asset Activity’ logs interactions with content. The interaction types can distinguish between create, view, change, delete, copy, rename, and search for individual assets. An ‘Event’ is a scheduled temporal unit, which is important for a blended learning design. As typically every course has a calendar and special events like course start, assessment and exam dates, it is useful to use this information in the parameter selection and analytics visualization process. E.g., it is a requirement to narrow down the activity to certain time spans such as the time between two exams or visualizing the usage statistics of the forum activities only in the time between two evaluations of weekly assignments, which then could be defined as events. An event is not necissarily part of a VLE. One example for an event is a traditional face-to-face lecture. The event object was introduced in the data model

10 _{This and the following paragraphs are a partly cited from A. L. Dyckhoff et al. (2012) and}

to integrate lectures, field trips or examination dates in the analysis. But it could also be used to store other activities that should be highlighted; e.g, the event of sending an important reminder notification to all students. It can be interesting to use events as variable parameters for configuration of investigations to correlate them with other data and check for dependencies.

For some activities, like exams, it is essential to store the outcomes. The interactions of users with assessement assets are held in activity objects. Hence, an ‘Assessment Activity’ only needs to save the value of the assessment outcome. Additionally, we wanted to store assessment instances separately from the user submission to allow for different handling and support of various assessment types. This also supports an extension model to fit in properties like completion time or group work submissions, which are not common, but sometimes available. In most VLE, there are multiple sources of content data, structured by using content areas and content lists or libraries. Therefore, the data model includes the objects ‘Area’ and ‘List’. Collaborative, interactive features or content are frequently arranged in separate areas, such as a learning materials section or group workspace areas, in order to facilitate navigation. Furthermore, several external systems can be used in a course, such as platforms for the provision of videos or electronic tests in addition to the central VLE. The semantic distinction into areas can be re-used in the analysis. Algorithms can, for example, differentiate the areas for storage of documents or collaborative areas with forums and wiki pages by using the ‘Type’ field.

Table 11. Similarities of eLAT's data model to IMS LD.

eLAT IMS LD

User Person

Role Role

Activity Activity

AssessmentActivity Outcome

Learning environment Environment

Event Method, support activity, notification Asset, lists, areas Learning objects, service

List and libraries can be used to organize elements of the same type or context, such as lists of wiki pages or similar learning resources. The individual elements are referred to as ‘Assets’ in the data model. An asset stores the name and a type of an asset. It also records which user created the element and when it was created

or last changed. The field ‘IsInfrastructure’ is used to highlight elements, which are part of the infrastructure of the learning environment. This way, graphics, documents, or web pages can be marked, if they are just needed for the documentation of the design or functions of the LMS, but serve no actual learning objective. Additionally, there are ‘Asset Extensions’ dedicated to extent content items with properties that are not always available, like for example a forum post, which has a property for the depth inside the discussion thread – in any other case that post can be regarded like any other content item, with properties like title, creation date and the user responsible.

The eLAT data model can be compared to the main objects of IMS Learning Design (IMS LD) (see section 5.1.4), which is illustrated in Figure 18 and Table 11 (see also Figure 17).

Figure 18. Conceptual model of IMS Learning Design. Source, IMS (2003).11

For the prototype evaluations of the framework’s design, data of courses from L²P and a Moodle instance, which was used in one course to host assessments, was extracted (Zielke 2011). In order to extract and transform data to the data model, custom code was used for each VLE, as shown in the blue boxes in Figure 16. Also, a general XML schema, which can be used to create and validate XML files from any VLE data output, was specified. The user interface evolution (see section 6.5), which continued also after the backend was implemented, as well as pilot phase experiences revealed limitations and the need for enhancements of the first design of the data model.