xAPI Definitions Registry

Project Information & Contribution


We at the Learning Technologies Research Group believe in xAPI as data format and are strong advocates of Open Source and Open Science. We initiated this project to create an open, reliable source for xAPI definitions constantly maintained and expanded by the scientific community. If you are interested in this idea, read this page and get in touch with us.

Visit our website at learntech.rwth-aachen.de or get in contact by heinemann@informatik.rwth-aachen.de .

Implementation approach


The implementation consists of two components according to the separation of representation and data: The first one is the database and can be regarded as a "living object", the second component represents the representation layer.

A repository for definitions


Creating and maintaining a common vocabulary in a repository brings many advantages that have long been standard in software development. Git is an established, distributed, open source version control system. A central aspect is the inherent versioning, which makes further developments and progress visible, but also allows access to past versions. Thus, in the sense of and as an extension to the idea of Trusted Learning Analytics, an extension in the statement could contain the commit to which the verb refers, so that meta-information is reliable and accessible without change even much later, but further developments can still take place, through which the retained identifier does not endanger the bijection and thus problem-free evaluability in aggregated data sets.

Sophisticated rights management, as all advanced implementations of git do, also ensures secure and reliable work with the system, while still allowing the responsibility for success to be shared on many shoulders. Active developers who want to contribute to the continuous development of the project can develop new semantic contexts in branches and merge them into the master branch after completion. One-time stakeholders who need a special context, e.g. for a research project or the development of a new product, can fork the repository and then trigger the inclusion in the repository via a pull request. With many contributors, an extension can thus take place quickly and easily.

Of course such a system does not get along without rules. These should be supported and developed by the community. The following is suggested as a basis for discussion:

  • Contexts are created in folders. Each folder contains a further level of subfolders according to the functionality of the vocabulary in xAPI: verbs, activities, extensions
  • Contexts should provide semantic clarity, but also not become overly specific
  • Definitions are stored as files in JSON format
  • It is strongly recommended to enrich the objects with meta information. Even if the specification may not provide the attributes, this meta information should be rendered in the presentation layer
  • Attributes required by the specification must be implemented
  • The use of LanguageMaps for the implementation of multilingualism is explicitly welcomed. As common denominator and generic fall-back, English identifiers are mandatory
  • In order to simplify future aggregation even with already collected data, it is desirable to reference already existing, similar or identical definitions elsewhere according to the syntax suggested in the xAPI profile definition

In addition to the definition files, the repository should contain information that explains the purpose of the repository, presents the participation process transparently in several languages, and explains the above-mentioned rules for dealing with the repository, all in markdown format. The only additional file is a configuration file, which is necessary for the interaction with the remaining components.

The presentation layer


In contrast to the data repository, the presentation layer is not an essential part of this proposal. The presentation layer is also being actively worked on, also in a git repository, and participation is welcome, but this is not a continuous process with a rolling release strategy, but pursues the plan to serve as a reference implementation after completion and to be further developed if necessary for new features. The presentation layer is intended to provide a comfortable handling of the data from the above mentioned repository. It will currently work in the frontend as a single page application (SPA) based on Vue, Vuetify and Nuxt. In the backend it provides a rest API. If a browser makes a normal HTTP request, the SPA is delivered, requests the SPA objects, it gets the full scope from the registry with all meta data, to other requests the server responds with JSON objects according to specification. Continuous integration means that changes to the master branch in the repository are passed on directly to the frontend. The presentation layer will initially allow users to search, filter and sort the definition inventory, but over time, convenience features such as bookmarks, drag-and-drop compilation of custom "wish lists" and variable views for different target groups will follow. In addition, it should be possible to track changes in definitions via the interface and access specific versions if necessary.

Interaction, extensibility, processes


With the planned approach of Continuous Integration, a clean separation of data and application can be implemented without endangering the integrity of your own servers. It enables the development of further applications with direct access to the definitions without exposing database interfaces and can, provided sufficient acceptance in the community, actively promote the Open Data principle. Currently, it is planned to grant all members of the research community, who have a proven track record in a public research institution related to e-learning or Learning Analytics research, the same maintainer rights in the data repository as the authors of this paper. Explicitly, no central governance is intended, so that they can also add additional maintainers. Individual developers or stakeholders with commercial interests can obtain developer rights from the maintainers upon request. This allows them to maintain their extensions in their own branches, which are then integrated into the master branch after completion by the maintainers.

Profiles


The work with xAPI profiles was only marginally discussed in this paper and goes far beyond the basic work of defining the semantics of single elements. Profiles require clear definitions and represent concrete application purposes that are not congruent with the contexts presented here. For example, a profile "Serious Games on Multitouch-Tabletops" could use definitions from the areas of serious games, touch interaction and collaboration without completely representing them. In addition, profiles define rules, e.g. for combinations of verbs and extensions in statements or provide interaction schemes for validation. Currently, an "xAPI Profile Server" on behalf of ADL according to specifications of the DoD is under development by two American consulting companies, MakingBetter and Veracity Technology Consultants, which is announced for September 2020. According to the technical report, which represents the requirement profile, the project presented here should not contradict it. The announced solution will undergo a thorough review after publication and the presentation layer of this project will be extended with a profile configuration component. Assuming that the project is compatible with the Open Science idea, these profiles can then either be stored in the ADL server or, if necessary, in a third repository that is still to be planned.

Acknowledgement

The develoment of this initative was partially funded! Our research group gratefully acknowledge the funding by the Federal Ministry of Education and Research (BMBF) for the joint project Open Digital Lab 4 you (grant no. 16DHB2114).