Recently, a number of usage data representations have emerged that enable the representation of user activities across system and application boundaries. Based on these user activity data, systems can adapt to the users and provide personalized information. A lot of usage data representation formats are already successfully used in real world applications. However, dependent on the purpose, the formats show different advantages and disadvantages one must consider when choosing a format for a system. In this paper, we will present the four most commonly used data representations, namely Contextualized Attention Metadata, Activity Streams, Learning Registry Paradata and NSDL to alleviate the selection of a suitable format.
Attention or Usage Metadata represent the activities of users and their usage of
data objects in specific applications. Aggregating and analysing the usage data provides
the basis for advanced user support systems, e.g. learning recommendation or
selfreflection support. Furthermore, usage data can be employed for annotating data
objects with information about their users and usages, thereby rendering possible object
classifications according to use frequency, use contexts and user groups [
Particularly in the domain of learning analytics (see [
Recently, a number of data representation formats for usage data have emerged. In contrast to simple logging files, these representations focus on the activities of users and not on those of a system. In this paper, we will present the most prominent examples, namely Contextualized Attention Metadata, Activity Streams, Learning Registry Paradata and NSDL Paradata. 2 2.1
The CAM scheme [
Additionally, only the basic information about an event is stored, e.g. the event type and the time stamp. All other information, e.g. metadata describing users or documents involved in the event, are linked. In this way, each entity and also each session can be described in a different and suitable way and no information is duplicated.
Fig. 1 shows the complete CAM scheme. The main element of a CAM instance is the event entry which comprises its id, the event type, the timestamp, and a sharing level reference. Examples for event types are “send“, “update” or “select”. The sharing level reference points to a description of the specific sharing level which describes the privacy related issues of the event. Depending on the event, various entities with different roles can be involved, e.g. when sending an e-mail, there is a person with the role sender, at least one person with the role receiver and a document with the role email. Each event can be conducted in a session. A session can, for example, be the time between booting and shutting down a computer or the time between the login and logout of a user in a portal.
The current CAM scheme does not have fixed bindings so far. The information can be stored in XML, RDF, JSON or in a relational database, depending on the purpose of the data collection.
1 https://sites.google.com/site/camschema/ 2.2
The Activity Streams specification [
Fig. 2 shows the core elements of the Activity Streams scheme. A single activity must at least contain a description of the entity that performed the activity (actor property) and the date and time at which the activity was published (published property). The Activity Stream Working Group recommends that an activity also contains a verb, an object, and an id property. The verb identifies the action that the activity describes (e.g. “accept”, “add”, “dislike” etc.), the object property describes the primary object of the activity (e.g. the watched movie or the sent e-mail) and the id property provides a unique identifier for the activity in the form of an absolute IRI (Internationalized Resource Identifier). The target property is optional and can be used if indicated by the verb. For instance, in the activity, "John sent an e-mail to Bill", “Bill” is the target of the activity.
The value of the actor, object, and target property respectively is an Activity
Stream Object. An Activity Stream Object comprises several properties describing the
object and should at least contain an IRI (id property) and a plain-text name for the
object (display property). Additionally, it can contain others such as an object type.
The Activity Base Schema [
The Learning Registry Paradata format [
As for the Activity Streams, a basic LR Paradata statement consists of three key elements: actor, verb, and object (see Fig.3). The actor refers to the person or group that does something and is represented by a string or LR Paradata object (as defined later). The verb refers to the action that is taken. In its simplest form, it just contains the action name (e.g. “taught” or “viewed”), but it can also be specified in more detail, which is the main difference of the LR Paradata and the AS scheme. The object refers to the thing being acted upon using a string or a LR Paradata object.
A LR Paradata object may contain an id, an objectType, a description of the object,
i.e. an array of keywords, a measure related to the object, a date and a context. Apart
from description and date, each element can be represented by a string or by a JSON
object without pre-defined scheme. The values of the elements depend on the
objectType, which can be e.g. a person, a group, a learning resource, a LMS, etc. Within
the verb, an action is specified that holds the verb’s value (action), additionally, it can
contain any element specified for the LR Paradata object [
The NSDL Paradata format was defined to capture aggregated usage data about a
resource (e.g. “downloaded”, “favourited”, “rated”) which is designated by audience,
subject or education level [
Besides its type and value, each usageDataSummary element contains the beginning and ending date for the usage data (dateTimeStart, endTimeStart), information about the audience that conducted the event (“educator”, “student”, “general public”, the subject of the used resource (e.g. “computing” or “mathematics”) and in which educational level (edLevel) the resource was used (e.g. “MiddleSchool”, “Grade 7”).
For lack of space, these elements are not shown in Fig. 4, but only the elements that are dependent on the type of the usageDataSummary element. Please see http://ns.nsdl.org/ncs/comm_para/1.00/records/planets.xml for an extensive example. 3
We reviewed the four most popular usage data representation formats that are being used in the learning domain in this paper and described their main properties. Each format has been created with a specific purpose in mind, so one must be clear about the further applications that will use the collected usage data when choosing the most suitable format.
In order to enhance the interoperability among usage data analysis tools and usage data storage silos, our next step will be to provide guidelines on how mappings between formats can be implemented and what has to be considered. All formats are open and allow supplemental, not pre-defined elements. Additionally, the specified vocabularies are not perceived as complete and for instance in a CAM instance, an entity can be described by any metadata scheme. Thus, no one-size-fits-all mapping among the formats is possible. In contrast, mapping can only be defined for specific application scenarios. By providing automatic mapping rules based on specific application scenarios, access to usage data collections will be facilitated. Nevertheless, further work remains to be done in terms of further generalizing the mapping rules so that the automatic conversion tools become less application scenario dependent.