An Ontology-enabled Context-aware Learning Record Store

Compatible with the Experience API

Jonas Anseeuw

, Stijn Verstichel

, Femke Ongenae

, Ruben Lagatie

, Sylvie Venant

and Filip De Turck

Department of Information Technology, Ghent University - iMinds, Technologiepark-Zwijnaarde 15, 9052 Ghent, Belgium

Televic NV, Leo Bekaertlaan 1, 8870 Izegem, Belgium

Keywords:

Learning Analytics, Ontologies, Experience API, Linked Data, Learning Management System, Learning

Record Store, Context-aware.

Abstract:

In education, learners no longer perform learning activities in a well-deﬁned and static environment like a

physical classroom. Digital learning environments promote learners anytime, anywhere and anyhow learning.

As such, the context in which learners undertake these learning activities can be very diverse. To optimize

learning and the environment in which it occurs, learning analytics measure data about learners and their

context. Unfortunately, current state of the art standards and systems are limited in capturing the context of

the learner. In this paper we present a Learning Record Store (LRS), compatible with the Experience API,

that is able to capture the learners’ context, more concretely his location and used device. We use ontologies

to model the xAPI and context information. The data is stored in a RDF triple store to give access to different

services. The services will show the advantages of capturing context information. We tested our system by

sending statements from 100 learners completing 20 questions to the LRS.

1 INTRODUCTION

In education there is a shift from traditional teacher-

led learning within single classroom boundaries, to a

digital learning environment where learners can learn

anytime (during class, training, preparing examina-

tion, examination,...), anywhere (classroom, at home,

library, train & bus,...) and anyhow (PC, tablet, smart-

phone,...) (Fiedler and V

aljataga, 2010). As a result,

the context in which the learners perform activities

such as exercises, assessments and examinations is no

longer well-deﬁned and static, but happens in very di-

verse contexts. Context can be deﬁned as any infor-

mation that can be used to characterize the situation

of an entity (Abowd et al., 1999), e.g., a combination

of time, location and used device.

For purposes of understanding and optimizing

learning and the environments in which it occurs, the

Society for Learning Analytics Research has coined

the concept of learning analytics as the measurement,

collection and analysis of data about learners and their

contexts

Currently, the Experience API (xAPI) speciﬁca-

http://www.solaresearch.org/mission/about/

tion (Experience API Working Group, 2013), for-

merly known as Tin Can API, and the successor to

SCORM

, is the de facto standard to log learners their

learning experiences. It captures these learning expe-

riences in the form of I did this and it resulted in that

statements.

The speciﬁcation already provides a context ﬁeld

to add some contextual information. However, in

spite of the effort, there are no details about how in-

formation such as device and location should be cap-

tured. To add more contextual information the spec-

iﬁcation offers an extensions ﬁeld allowing arbitrary

data to be attached as context. This extensions ﬁeld

is merely intended to provide a natural way to extend

the context ﬁeld.

In this paper we present a system that is able to

also capture the environment in which learning expe-

riences happened. Consequently, our system stores

more information about the learner than current state

of the art systems. To make sure that statements

sent to our system are still backwards compatible to

other systems that support the xAPI speciﬁcation, we

extend the xAPI speciﬁcation using the extensions

http://adlnet.gov/adl-research/scorm/

Anseeuw, J., Verstichel, S., Ongenae, F., Lagatie, R., Venant, S. and Turck, F.

An Ontology-enabled Context-aware Learning Record Store Compatible with the Experience API.

DOI: 10.5220/0006049000880095

In Proceedings of the 8th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2016) - Volume 2: KEOD, pages 88-95

ISBN: 978-989-758-203-5

mechanism.

Ontologies are used extensively to model context

(Gruber, 1993). Describing the xAPI speciﬁcation

as an ontology facilitates the integration with exist-

ing context ontologies describing context informa-

tion. Also, the xAPI speciﬁcation is built on top of the

Activity Streams speciﬁcation, which is already com-

patible with JSON-LD (J. Snell, M. Atkins, W. Nor-

ris, C. Messina, M. Wilkinson, and R. Dolin, 2015).

The object properties in JSON-LD documents map to

concepts in an ontology.

Initial research has been done to map the xAPI to

an ontology model (De Nies et al., 2015; Vidal et al.,

2015). We extend on this work by creating our own

context ontology and import this with the xAPI ontol-

ogy.

The use of ontologies offers additional advantages:

• Validation: the concepts and axioms of an ontol-

ogy provide a sound foundation for the validation

of the xAPI statements.

• Reasoning: ontologies deﬁned in OWL 2, sup-

port reasoning mechanisms provided by descrip-

tion logics.

• Query: xAPI statements deﬁned in RDF can be

stored in a triple store and queried through a

SPARQL endpoint.

The remainder of this paper is structured as follows.

First, we motivate this research with concrete use case

scenarios in Section 2. We present the state of the

art with regards to capturing learner’s data in Section

3. In Section 4 we present the xAPI ontology and

our extended context model. In Sections 5 and 6, we

show the architecture and implementation of our sys-

tem. Finally, we give an evaluation in Section 7 and

give our conclusions and outlook to future work in

Section 8.

2 MOTIVATION

Learning analytics have already been proven bene-

ﬁcial in supporting learners and instructors in edu-

cation. While it can be sufﬁcient to log which ac-

tivities a learner performs and use this data to dis-

cover the real learning process followed by the learn-

ers (Vzquez-Barreiros et al., 2015; Kinnebrew et al.,

2013), predict learner’s performance (Romero et al.,

2013; Fernndez-Delgado et al., 2014) and recommend

learning resources (Verbert et al., 2012).

Taking into account also contextual dimensions

such as location and device information can further

optimize the learning environment for learners and

give more insights to instructors.

• Learners can be recommended course material

based on their location and device. For exam-

ple, when accessing course material with a smart-

phone on a train during commuting where there

is limited network connectivity, it is not rec-

ommended to stream high-quality video lectures.

When making exercises in a cafeteria with high

noise levels, it is more appropriate to rehearse

content instead of introducing new content.

• Instructors can monitor students during an exam-

ination. Fraud detection services can take into ac-

count the location of where a student is sitting,

because it is more likely that students sitting next

to each other commit fraud. When a student is

struggling on an exercise, it can help the instruc-

tor to not only provide the name of the student,

but also provide information about where exactly

the student is located in the room.

To realize these use cases, it is key to capture not

only the user their activities, but also in which con-

text these activities were performed.

3 STATE OF THE ART

The ﬁrst step in capturing and storing learner’s data,

is to properly model and store the interactions the

learner did with respect to the learning objects, e.g.,

completing an exercise or passing an exam.

A high-level overview of how current learning

systems work is depicted in Figure 1. A Learning

Management Systems (LMS) serves learning objects

to the learner. A learning object is a collection of

content items and assessment items that are combined

based on a single learning objective. The interactions

that the learner has with respect to the learning ob-

ject are tracked and stored in a Learning Record Store

(LRS).

Since 2001, the Shareable Content Object Refer-

ence Model (SCORM) (Bohl et al., 2002) has been

Figure 1: Overview of how current e-learning systems cap-

ture learner’s activities (De Meester et al., 2015).

An Ontology-enabled Context-aware Learning Record Store Compatible with the Experience API

the most used learning object standard by the Ad-

vanced Distributed Learning initiative (ADL)

. Un-

fortunately, SCORM is limited to storing simple data

points such as a ﬁnal score or that a course has been

started or completed. Other standards such as the

IEEE standard 1484.11.1/2 (IEEE Std, 2005), Ac-

tivity Streams (J. Snell, M. Atkins, W. Norris, C.

Messina, M. Wilkinson, and R. Dolin, 2015), the

Experience API (xAPI) (Experience API Working

Group, 2013) and the Caliper framework by IMS

(IMS Global Learning Consortium et at., 2013), were

extensively reviewed by Corbi & Burgos (Corbi and

Burgos, 2014). We can conclude that the xAPI stan-

dard and IMS Caliper framework already have a no-

tion of context. However this context is related to the

course material, e.g., to which curriculum a course

belongs or who the instructor of the course is. It does

not capture the environment where the user performed

the learning or which device he used. The xAPI spec-

iﬁcation is open source and can be extended.

The xAPI speciﬁcation, formerly known as Tin

Can API, has emerged as a successor of SCORM

and captures much richer activity data compared to

SCORM. The speciﬁcation is built on top of the Ac-

tivity Streams speciﬁcation, used in social networks

to capture user activity in the form of I - did - this

statements. The xAPI speciﬁcation added extra func-

tionality to the statements speciﬁcally for storing and

transferring records of learning experiences. A result

object is added to better collect outcomes of learning

and a context object is added to record learning done

in context. However, the speciﬁcation lacks the deﬁ-

nition of an extensive context model and merely pro-

vides an extendable extensions ﬁeld. With over 160

adopters

, such as Moodle

, Blackboard

and Sakai

it is fair to say that this is now the de facto standard.

(Verbert et al., 2012) already illustrated in a re-

view paper that including context aspects in exist-

ing standards, such as SCORM and xAPI, or map

standardized representation of context to these stan-

dards, is a challenging future line of research to en-

able data compliant to these standards and speciﬁ-

cation to be exchanged and reused. Therefore, we

extend the xAPI speciﬁcation with a formal context

model using ontologies.

Some initial research has successfully mapped the

xAPI speciﬁcation to an ontology (De Nies et al.,

2015; Vidal et al., 2015). The SmartLAK architec-

ture, a big data architecture for supporting learning

https://www.adlnet.gov/

http://experienceapi.com/adopters

https://www.moodle.org

http://www.blackboard.com

https://sakaiproject.org

analytics services (Rabelo et al., 2015) uses an ontol-

ogy, based on the xAPI speciﬁcation. Their system is

however limited to the xAPI ontology model and only

uses the model for data conformance validation. The

system presented in this paper uses an extended ver-

sion of the xAPI ontology model with a context on-

tology and not only uses the ontologies for validation

purposes, but also for reasoning.

4 ONTOLOGY DEFINITION

At the moment of writing, the xAPI speciﬁcation is

only available in a GitHub repository

. The spec-

iﬁcation is not available in a machine-interpretable

version and thus not suitable to be used as an OWL

ontology or RDF Schema. Lately, we see that the

xAPI speciﬁcation is adopting Semantic Web Tech-

nologies. The xAPI Vocabulary Working Group pro-

vided IRIs for the Verb (e.g. completed, answered,...)

and Activity (assessment, course,...) terms online at

https://w3id.org/xapi/adl to improve semantic inter-

operability. This vocabulary is available as RDFa and

can also be retrieved as machine-readable JSON-LD.

In the future it is expected that more vocabularies will

become available as the ADL working group recently

published an xAPI companion guide and vocabulary

primer (xAPI Vocabulary Working Group, 2016) for

publishing vocabulary datasets as Linked Data (xAPI

Vocabulary Working Group, 2015).

To allow us to extend the xAPI context extensions

with concepts from a context ontology, an ontology

of the xAPI speciﬁcation is needed.

The statements of xAPI are a good candidate to

be described in the Resource Description Framework

(RDF) because it is built on top of Activity Streams

and the second version of this speciﬁcation even re-

quires that the statements must be serialized con-

form JSON-LD (M. Sporny, G. Kellogg, M. Lanthaler

(Eds.), and W3C RDF Working Group, 2014). There

is a JSON-LD @context deﬁnition

and an OWL on-

tology

of the speciﬁcation available online.

Since there is no ontology available from xAPI

speciﬁcation itself, we extend from an ontology of the

xAPI described by other researchers (De Nies et al.,

2015; Vidal et al., 2015). In section 4.1 we describe

this xAPI ontology. We describe how we extended

this ontology with our context ontology in section 4.2.

http://GitHub.com/adlnet/xAPI-Spec

https://www.w3.org/TR/activitystreams-core/

activitystreams2-context.jsonld

https://www.w3.org/TR/activitystreams-vocabulary/

activitystreams2.owl

KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development

Figure 2: The xAPI ontology.

4.1 xAPI Ontology

The most important classes and relationships of the

xAPI ontology are shown in Figure 2. The statement

class represents the statements of the form I did this,

where I, did and this, are the Actor, Verb and Object

classes respectively. The statement can also contain

the outcome or result and the context associated with

the event by using the Result and Context classes.

The Context class has relations to concepts , such

as the instructor for an experience, if the experience

happened as part of a team activity, or how an expe-

rience ﬁts into some broader activity. We can for ex-

ample state that a learner took some course, under the

instruction of a speciﬁc instructor, as part of a speciﬁc

curriculum, in a speciﬁc school.

To add more contextual information, the Context

class has an extensions relationship that allows rele-

vant domain-speciﬁc context. For example, in a ﬂight

simulator altitude, airspeed, wind, GPS coordinates

might all be relevant.

4.2 Context Ontology

The context its extensions are described by our own

context ontology. Figure 3 shows some classes. As it

is depicted, our ctx:Extensions class is a subclass of

the xAPI Extensions. Two important properties of our

context are location and device. The location can be

Figure 3: Part of the context ontology.

a Library, Home and Classroom. The Device can be a

Smartphone, PC or Tablet.

An illustrative example of how these concepts can

be used for the progress and fraud detection services

(Section 5 and Section 6) is as follows: the concept

of a Classroom, PC and relationship number which

numbers all the PC and Room individuals can be used

to ﬁlter learners by examination room and detect at

which device the slacking student is located. The PC

has a property adjecentTo to model which devices are

located next to each other, this can help the algorithm

to detect fraud.

5 ARCHITECTURE

Once the ontology has been designed, the architecture

can be built to process data, map it to our ontology

and deﬁne different services to support learners and

instructors. Figure 4 depicts an overview of the archi-

tecture of our system.

The Learning Record Store contains 4 components:

• Data Collection & Transformation component

is responsible for capturing the xAPI JSON state-

ments that are sent to our system through the API.

The component then processes these JSON state-

ments, transforms the statements to RDF and ﬁ-

nally forwards the transformed RDF statements to

the Storage In component.

• Storage In efﬁciently stores the xAPI RDF state-

ments coming from the Data Collection & Trans-

formation component.

• Triple Store is responsible for storing the OWL

2 ontologies and RDF data. The triple store sup-

ports reasoning to infer knowledge not explicitly

stated in the data.

• Storage Out forms the link between the triple

store and the different services. The component

facilitates access to the data by query answering.

The Services are independent components that pro-

cess the LRS data to provide valuable information to

learners and instructors. Each service has an endpoint

that allows the service to be consumed by applications

or other services. The current version of our architec-

ture contains services that are specially designed to

support instructors during class room assignments or

examinations. These services are the following:

• Progress Service measures the progress from

learners during an examination or exercises. Cap-

turing the location where the learner is sitting in a

room aids instructors identifying where struggling

learners are sitting and help them more proac-

tively.

An Ontology-enabled Context-aware Learning Record Store Compatible with the Experience API

Figure 4: The architecture of our system.

• Fraud service detects anomalous behavior from

learners during an examination. Taking into ac-

count context information such as where learners

are located in the room can help detecting anoma-

lous behavior.

6 IMPLEMENTATION

Our architecture is built on top of LimeDS

, an

OSGi-based framework for building REST/JSON-

based server applications (Verstichel et al., 2015).

LimeDS allows us to adapt our architecture more efﬁ-

ciently for future demands, e.g. adding additional ser-

vices or plug in different triple store implementations.

LimeDS also provides support for load-balancing and

data caching so that our system is scalable.

LimeDS facilitates development by leveraging on

the Data Flow abstraction. The Data Flow abstraction

deﬁnes how data ﬂows through the different compo-

nents in the architecture. This Data Flow system re-

volves around two conceptual component types:

• Flow Functions consume an optional JSON argu-

ment and can optionally produce processed JSON

data

• Flow Processes that execute a speciﬁc set of ac-

tions when triggered (e.g. time-based).

By combining instances of these two conceptual

types, complex data-oriented services can be built. In

our current architecture implementation, only Flow

Functions were used. The different Flow Functions

are depicted in Figure 4.

http://limeds.intec.ugent.be

6.1 Data Collection & Transformation

The data in our LRS must be in a format that maps

to the xAPI and context OWL 2 ontologies. There-

fore, we have to transform our data to RDF data.

Since xAPI statements are JSON documents, convert-

ing these document to JSON-LD is the most straight-

forward approach. Additionally, the JSON-LD doc-

uments can then in the future also be stored in other

data stores that are not aware of Linked Data, e.g.,

MongoDB.

Converting a JSON document to JSON-LD is

done using a JSON-LD context document

, which

maps all the terms that may occur in the xAPI JSON

statement to IRIs in the ontology. This is illustrated in

Example 1. A @context entry referencing this docu-

ment is added to the root of the JSON, an @type entry

with value xapi:Statement, as well as the following

snipped to every :verb and :object property: ”@con-

text: { ”id”: ”@id”}, because the id is reserved for

the URI. Because the context document introduced in

other research (De Nies et al., 2015) does not include

any context extensions, we extended this document to

map context extensions to IRIs from our own context

ontology.

Next to some additional necessary conven-

tions to have a smooth conversion, mentioned in

(De Nies et al., 2015), the XML Schema dura-

tion (xsd:duration) datatype used in xAPI statements

is discouraged in RDF and OWL

. The XQuery

and XSLT Working Groups have proposed an al-

ternative in the form of two derived datatypes:

xdt:yearMonthDuration and xdt:dayTimeDuration.

The derived datatypes restrict the lexical represen-

tation to contain only year and month components

http://www.w3.org/TR/json-ld/#the-context

https://www.w3.org/TR/swbp-xsch-datatypes/

#section-duration

KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development

or days, hours, minutes and seconds components.

Since learning experiences will generally not take

longer than days, we used the xdt:dayTimeDuration

datatype.

6.2 Triple Store

The Learning Record store is composed out of two

LimeDS Flow Functions: Data Collection & Trans-

formation and Storage Out and a triple store that

stores the xAPI ontology, the context ontology and

the processed xAPI statement triples.

We choose RDFox as our triple store implementa-

tion. RDFox is a highly scalable RDF store that sup-

ports materialisation-based parallel datalog reasoning

and SPARQL query answering (Nenov et al., 2015).

6.3 Storage Out

Storage Out provides a HTTP REST API that accepts

SPARQL queries through HTTP POST. The service

{

"@context": "http://http://users.ugent.be

/˜joanseeu/xapi.jsonld",

"@type": "http://users.ugent.be

/˜joanseeu/Statement",

"actor": {

"name": "John Doe",

"objectType": "Agent"

"verb": {

"@context": { "id" : "@id" },

"id": "xapi-verbs:completed",

"display": { "en": "completed" }

"object": {

"@context": { "id" : "@id" },

"id": "http://example.org/exercise1",

"objectType": "Activity",

"definition": {

"name": { "en": "Example Activity" }

}

"result": {

"score": { scaled: 0.7 },

"duration": "PT50S"

"context" {

"extensions": {

"room": { "number": 209 },

"device": { "number": 5 }

}

Figure 5: An example xAPI JSON-LD document.

returns an array of RDF triples. An example of a

JSON message is given below.

{

"query":"SELECT ?x WHERE{?x rdf:type :Result}"

}

6.4 Services

Different services have been developed, mainly to

provide teachers added value from the data available

in the LRS. Each service is contained in a LimeDS

Flow Function. The following services are imple-

mented:

Progress Service

Progress service returns a list of places in the room

where learners take longer than average to complete

their exercises/assessments are, enabling teachers to

help students more proactively. The captured device

identiﬁer as context can be used to locate where the

student is sitting in a room (e.g. the PC number). An

illustrative example of a query that this service uses

is shown below. This service sends the query to the

Storage Out component.

SELECT ?pcnumber

WHERE {

?result rdf:type :Result.

?statement :result ?result.

?statement :context ?context.

?context ctx:device ?pc.

?pc ctx:number ?pcnumber.

?result :duration ?d FILTER(?d > x)

}

Fraud Service

The fraud service queries on the progress learners

make and at which device they are located. This is

similar to the query that the progress service uses, but

without ﬁltering. The service infers potential cheating

behavior when learners have similar progress and sit

at adjacent devices. A simpliﬁed version of the used

query is shown below.

SELECT ?name1 ?name2

WHERE{

{ SELECT ?name1 ?result1 ?duration1 ?device1 }

{ SELECT ?name2 ?result2 ?duration2 ?device2 }

?device1 ctx:adjacentTo ?device2

FILTER(?result1 = ?result2 &&

fn:numeric-abs(?duration1-?duration2) < x)

}

The list of adjacent devices, described as triples, is

loaded in the triple store as background knowledge.

@prefix : <http://www.example.org/> .

:device1 :adjacentTo :device2 .

:device2 :adjacentTo :device3 .

An Ontology-enabled Context-aware Learning Record Store Compatible with the Experience API

7 EVALUATION

Since our LRS transforms the xAPI statements to

Linked Data, all information in the xAPI statements

must also be present as Linked Data. As long as the

information in the statements is also deﬁned in the

xAPI and context ontologies and the corresponding

mapping, we observed no loss in information when

transforming the xAPI statements to Linked Data.

The RDFox triple store implementation used in

our LRS supports OWL 2 RL, an OWL 2 proﬁle that

trades expressive power for the efﬁciency of reason-

ing by placing restrictions on the structure of OWL

ontologies. Reasoning and query answering can then

be solved in time that is polynomial with respect to

the size of the ontology.

Furthermore, the triple store implementation

seems to be highly-scalable according to the evalua-

tion of the creators (Nenov et al., 2015). The LimeDS

framework used to implement the architecture is scal-

able due to its load balancing support.

The evaluation was done on an Ubuntu 14.04

server with an Intel Xeon CPU E5645 @ 2.40 GHz

with 24 GB of memory. Statements were simulated

and sent to the LRS to evaluate. The statements de-

scribed the activity of 100 learners completing 20 ex-

ercises with an average time of 30 seconds and stan-

dard deviation of 5 seconds per question. The LRS

captured and stored 2000 statements. To evaluate the

performance of our system, the time for processing

the data and executing the services was measured.

Since these services support instructors during class

room exercises, the services should respond in an

acceptable time. Transforming the xAPI statements

takes on average 10ms. Figures 6 and 7 plot service

execution times, which are both around 160ms when

the LRS stores 2000 statements. We can conclude that

the execution time of the services scales linear with

100

120

140

160

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Time (ms)

Number of statements

Figure 6: Progress service execution time as a function of

the amount of statements stored.

100

120

140

160

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Time (ms)

Number of statements

Figure 7: Fraud service execution time as a function of the

amount of statements stored.

the number of statements stored in the triple store.

Since there is 1 statement per user and per question

answered. The system will also scale linearly with

the number of questions and number of users.

8 CONCLUSIONS AND NEXT

STEPS

In this paper we presented a Learning Record Store

that is able to capture more context information com-

pared to current state of the art systems. We extended

the xAPI speciﬁcation using its extensions mecha-

nisms so that learning activity sent to our system is

still backward compatible to other systems. We de-

scribed our extensions using an ontology and used an

ontology based on the xAPI speciﬁcation. We have

implemented our system on top of LimeDS and built

services that offer learning analytics services that take

advantage of context information.

In next steps, our system will be integrated with

the learning software of one of the partners in the

CAPRADS project. This will allow us to collect real-

life data to evaluate how the services behave with re-

gard to false negatives and false positives.

ACKNOWLEDGEMENTS

The iMinds CAPRADS project is co funded by

iMinds (Interdisciplinary Institute for Technology),

a research institute founded by the Flemish Govern-

ment with project support of the IWT.

KEOD 2016 - 8th International Conference on Knowledge Engineering and Ontology Development

REFERENCES

Abowd, G. D., Dey, A. K., Brown, P. J., Davies, N., Smith,

M., and Steggles, P. (1999). Towards a better un-

derstanding of context and context-awareness. In

Handheld and ubiquitous computing, pages 304–307.

Springer.

Bohl, O., Scheuhase, J., Sengler, R., and Winand, U.

(2002). The sharable content object reference model

(scorm) - a critical review. In Computers in Educa-

tion, 2002. Proceedings. International Conference on,

pages 950–951 vol.2.

Corbi, A. and Burgos, D. (2014). Review of Current

Student-Monitoring Techniques used in eLearning-

Focused recommender Systems and Learning analyt-

ics. The Experience API & LIME model Case Study.

International Journal of Interactive Multimedia and

Artiﬁcial Intelligence, 2(7):44–52.

De Meester, B., Ghaem Sigarchian, H., De Nies, T., Ver-

borgh, R., Salliau, F., Mannens, E., and Van de Walle,

R. (2015). SERIF: A Semantic ExeRcise Interchange

Format. In Proceedings of the 1st International Work-

shop on LINKed EDucation.

De Nies, T., Salliau, F., Verborgh, R., Mannens, E., and

Van de Walle, R. (2015). Tincan2prov: Exposing in-

teroperable provenance of learning processes through

experience api logs. In Proceedings of the 24th Inter-

national Conference on World Wide Web, WWW ’15

Companion, pages 689–694, New York, NY, USA.

ACM.

Experience API Working Group (2013). Experience API.

Version 1.0.1.

Fernndez-Delgado, M., Mucientes, M., Vzquez-Barreiros,

B., and Lama, M. (2014). Learning analytics for

the prediction of the educational objectives achieve-

ment. In 2014 IEEE Frontiers in Education Confer-

ence (FIE) Proceedings, pages 1–4.

Fiedler, S. and V

aljataga, T. (2010). Personal learning en-

vironments: concept or technology?

Gruber, T. R. (1993). A translation approach to portable on-

tology speciﬁcations. Knowl. Acquis., 5(2):199–220.

IEEE Std (2005). IEEE Standard for Learning Technology

- Data Model for Content to Learning Management

System Communication. IEEE Std 1484.11.1-2004.

IMS Global Learning Consortium et at. (2013). Caliper

Learning Analytics Framework. Technical report.

J. Snell, M. Atkins, W. Norris, C. Messina, M. Wilkin-

son, and R. Dolin (2015). Activity streams 2.0

w3c working draft. W3C Working Draft, W3C.

http://www.w3.org/TR/2015/WD-activitystreams-

core/.

Kinnebrew, J. S., Loretz, K. M., and Biswas, G. (2013). A

contextualized, differential sequence mining method

to derive students’ learning behavior patterns. JEDM-

Journal of Educational Data Mining, 5(1):190–219.

M. Sporny, G. Kellogg, M. Lanthaler (Eds.), and W3C RDF

Working Group (2014). JSON-LD 1.0: A JSON-

based Serialization for Linked Data. W3C Recom-

mendation, W3C.

Nenov, Y., Piro, R., Motik, B., Horrocks, I., Wu, Z., and

Banerjee, J. (2015). Rdfox: A highly-scalable rdf

store. pages 3–20.

Rabelo, T., Lama, M., Amorim, R. R., and Vidal, J. C.

(2015). Smartlak: A big data architecture for support-

ing learning analytics services. In Frontiers in Ed-

ucation Conference (FIE), 2015. 32614 2015. IEEE,

pages 1–5.

Romero, C., L

opez, M.-I., Luna, J.-M., and Ventura, S.

(2013). Predicting students’ ﬁnal performance from

participation in on-line discussion forums. Comput.

Educ., 68:458–472.

Verbert, K., Manouselis, N., Ochoa, X., Wolpers, M.,

Drachsler, H., Bosnic, I., and Duval, E. (2012).

Context-aware recommender systems for learning: A

survey and future challenges. IEEE Trans. Learn.

Technol., 5(4):318–335.

Verstichel, S., Kerckhove, W., Dupont, T., Volckaert, B.,

Ongenae, F., De Turck, F., and Demeester, P. (2015).

Limeds and the trapist project: a case study. In 7e In-

ternational Joint Conference on Knowledge Discov-

ery, Knowledge Engineering, and Knowledge Man-

agement, Proceedings, volume 2 KEOD, pages 501–

508.

Vidal, J. C., Rabelo, T., and Lama, M. (2015). Seman-

tic description of the experience api speciﬁcation.

In 2015 IEEE 15th International Conference on Ad-

vanced Learning Technologies, pages 268–269.

Vzquez-Barreiros, B., Mucientes, M., and Lama, M.

(2015). Prodigen: Mining complete, precise and mini-

mal structure process models with a genetic algorithm.

Information Sciences, 294:315 – 333. Innovative Ap-

plications of Artiﬁcial Neural Networks in Engineer-

ing.

xAPI Vocabulary Working Group (2015). Companion Spec-

iﬁcation for xAPI Vocabularies.

xAPI Vocabulary Working Group (2016). Experience xAPI

Vocabulary Primer.

An Ontology-enabled Context-aware Learning Record Store Compatible with the Experience API