Skip to main content

Table 4 Challenges identified and recommended solutions

From: Enriching context descriptions for enhanced LA scalability: a case study

Category

Challenges identified

Recommended solutions

Context

The distinction between ContextActivities and extensions appears artificial, and it is not always clear which to use.

Use a unified structure for context in xAPI, i.e., context dimensions, with appropriate (low-level) properties for each context dimension. Use data typing and validation to restrict properties and value types for context dimensions. Depending on the property, the value type can be Activity, but other value types should also be supported (e.g., JSON object and string).

Extensions are flexible in how data can be registered and therefore could make it more difficult to integrate data.

ContextActivities is not a good fit for all types of context data.

Grouping of related activities in ContextActivities can be done within three different structures (grouping, category or other). It is not clear how the three structures differ. The grouping structures are all very high-level.

Remove distinction between grouping, category, and other. All context data that do not have an explicit (parent) relationship to the statement should be placed in the same structure. For the suggested unified structure for context, i.e., context dimensions, the related information can be listed more explicitly as property values belonging to the appropriate dimension and property.

The query capabilities of LRSs are seen as limited. The example given is that it is only possible to filter statements on contextual data that are instances of an activity type. Thus, to allow filtering of resources in AVT (without extra development work), resources were registered as activities, even if they were not really activities on the semantic level.

The xAPI specification defines the query interface that all LRSs must implement (Advanced Distributed Learning, 2017d). In the case of filtering based on resources, the specification needs to be extended, so that it is possible to filter contextual data by any resource type. Individual LRS providers have addressed this issue on an ad hoc basis (Learning Locker, 2020), but the problem needs to be further addressed in the xAPI specification to ensure LRS interoperability (e.g., for xAPI users not to have to rewrite substantial amounts of code if moving data between LRSs).

Concepts from the xAPI vocabulary not sufficient to describe all data.

Use of xAPI profiles to add additional concepts.

The same vocabulary concept may be represented in different public xAPI profiles, which make up the xAPI vocabulary.

Stricter curation/approval process of the public profiles.

Data typing and validation

Tools generating data at multiple levels of granularity is a challenge, which may make it more difficult to meaningfully integrate data.

To help tool developers identify and enforce the expected level of granularity, xAPI data typing and validation can be used. For instance, if a property takes a list of activities (more granular), validation can ensure that less granular values (e.g., integer) will not be accepted.

Data typing and validation

Difficulties in mapping real-world data to xAPI due to its assumptions.

Data typing and validation can help to ensure that the assumptions of xAPI (e.g., expected value for an xAPI concept) are made more explicit and tested against the data, to avoid wrong use of the specification. It is also crucial that the xAPI specification can be extended as new use cases reveal new needs for data registration.

Data typing and validation

Different tools may generate different numbers of statements for the same type of event.

Validation could be tied to the number of statements generated for a given type of event, and to ensure that the statements generated follow an ordered pattern.

Data typing and validation

Documentation

The openness and flexibility of xAPI allows data and relationships of the same type to be modelled in a myriad of different ways.

Add clearer modelling guidelines to the documentation. Add data typing and validation of properties and property values. Use of profiles to specify vocabularies.

Documentation

It may be challenging to correctly use concepts from the xAPI vocabulary.

Improve xAPI documentation, e.g., document more solutions for specific use-cases, and add more examples of how to use the xAPI vocabulary concepts in order to avoid misunderstandings and remove ambiguity.