Most people are familiar with the famous quote, “A rose by any other name would smell as sweet.” In other words, if you call a rose something else, it still smells the same. This affectionate Shakespeare reference highlights that the names of things alone do not affect what they really are. Vocabulary has been a key concern for the xAPI community, especially those working in analytics. The new vocabulary companion specification takes a big step forward for our community.
As humans, our natural inclination to label things, change the names of things, or simply trying to figure out what to call “it” is often driven by a desire to prescribe clear and unambiguous meaning. Ironically, the challenges with deciding on how to provide more semantic meaning has remained with us throughout the evolution of xAPI. For example, in addition to changing the name of the spec itself we also removed the requirement for a common vocabulary. As a result, communities of practice were expected develop their own profiles and reuse existing Verb and Activity Type vocabulary terms and identifiers whenever possible. This freedom provides great flexibility, but can also result in disorderly practices and semantic ambiguity.
When considering semantics, there are two fundamental challenges with natural language words:
- Two or more words can be used to represent a single concept (e.g., verbs such as “finished” and “completed”).
- Two or more words that have the same spelling can represent different concepts (e.g., verbs such as passed (to physically move past) or passed (successfully pass an examination)).
xAPI vocabulary concepts (e.g. Verbs and Activity Types) are not natural language words, but approaches to handling semantic ambiguity can inform approaches to handling xAPI ambiguity. As Adam Cooper has pointed out, “the absolutely most important thing is good clear definitions of concepts, with the concepts being relevant to the education/training context and described accordingly. A good balance is struck between concepts that are so vague they are practically useless or are so highly contextualized to a particular way of doing things that they are either not used or are misused.”
However, to simply name and describe things with text alone is not enough. In order to address semantic naming issues, Verb misuse, and other challenges related to vocabulary term discovery and reuse, a Companion Specification and Vocabulary Primer were recently published. These new resources were announced by Russell Duhon during xAPI Camp at AutoDesk in San Francisco, CA. The announcement comes nearly one year since the Vocabulary Considerations for xAPI white paper was published by ADL. The white paper was published as a result of several healthy discussions in xAPI Community groups on vocabulary, and the need to generally improve the design of IRIs and the metadata for xAPI Verbs.
Community veterans Russell Duhon and Dr. Ingo Dahn were some of the first to recommend and share expertise on semantic web standards, and more specifically the W3C’s Resource Description Framework (RDF). Why? Well, RDF provides a common data model and standardized syntax for identifying and describing things or concepts in the world, which is exactly what we needed to describe an abstract concept such as an xAPI Verb. In addition, several new developments, maturity in RDF specs, and adoption have surfaced in recent years since xAPI initially was launched. RDF compatible with JSON (aka JSON-LD) was touted last year as “the new hotness” after being first released in 2014, and was of natural interest to the xAPI community–since xAPI was already based on JSON.
After the white paper was published, ADL facilitated a community-driven xAPI Vocabulary Working Group in Spring 2015 to investigate how to improve semantic interoperability for xAPI. The working group identified several use cases and focused on leveraging existing semantic web technologies and RDF practices that could be leveraged for creating, publishing, and maintaining xAPI Verbs as linked data. These new vocabulary documents are applicable to anyone creating new vocabulary terms for xAPI. They are also relevant to any individuals or organizations developing applications for publishing, storing or retrieving vocabulary identifiers and definitions, or any other types of services that need to obtain the semantic meaning of xAPI vocabulary data.
This new vocabulary guidance can immediately improve our ability to prescribe richer semantic meaning, multilingual translation, discovery and reuse of xAPI vocabulary terms. Conceivably, it will also open up new doors for federated search, dynamic look-up of vocabulary data within authoring tools or other applications, improved learning analytics, and adaptive and personalized learning capabilities.
Clarity on Vocabulary, Profiles, and Recipes
What’s the difference between a vocabulary, a profile, and a recipe? The new vocabulary guidance also attempts to explain the subtle differences in this terminology, which is often used interchangeably in the xAPI community. While these terms are related and may be often used in relation with one another, they actually have different characteristics worth clarifying. Read the Companion Vocabulary Specification to read the new descriptions, which were intended to accompany the preliminary diagram below.
JSON-LD & The Future of xAPI
The vocabulary research work conducted during the past year only focused on Verbs and Activity Types for now, but could be further expanded to provide more structure for extensions and attachment usage. In addition, xAPI could benefit from modernizing other aspects of its JSON-based data model to further support RDF. JSON-LD adds a lot of what is otherwise missing in JSON data. The structure of plain JSON is very simple, but it has no inherent meaning. It often only provides basic information that the person that’s describing it – put in it. With JSON-LD, you can take advantage of that syntactic simplicity in JSON, but provide unambiguous meaning and rich structure. In addition, as Aneesha Bakharia recently posted xAPI extensions at the moment also don’t have enforced typing. If xAPI moved to JSON-LD, it could be a step forward in determining data types in an automated manner for analytics. The JSON-LD typing to describe statements extensions may then easily map to the stricter typing. While there have been some discussions in the xAPI spec community about modernizing the entire xAPI data model to support JSON-LD, fully requiring it would likely be slated for a major future version of the spec. In the meantime, the new vocabulary guidance at least begins to move us in the direction of adopting JSON-LD for IRI metadata.
Other kindred technical specs to xAPI have already began moving toward JSON-LD. For example, Activity Streams 2.0 (Working DRAFT), began modernizing their data model to better support structured and context rich JSON just last year. While such efforts may be similar in their approach (using streams of statements to capture data) they often differ from xAPI in their underlying architecture and implementation details though.
In summary, the new vocabulary guidance isn’t simply about JSON-LD. It was based on a select list of use cases defined by the community. A common objective of these use cases was to improve the overall semantic quality, reuse potential, and discovery of Verbs and Activity Types. Adopting linked data for expanding the vocabulary of xAPI is a good first step in the right direction toward meeting this objective. However, there is still plenty of work to do and the community will need simple tools and resources to more easily and consistently support publishing xAPI vocabularies as linked data. Fortunately, there are plans to provide such tools and resources to the community as early as this year! In the meantime, anyone with technical experience with HTML and JSON can check out the Companion Specification and Vocabulary Primer and look at existing vocabularies published as RDF as examples for getting started.
Disclaimer: Jason Haag is a SETA contractor with The Tolliver Group in support of the Advanced Distributed Learning (ADL) Initiative. The information and views expressed in this article are those of the author(s) and do not necessarily reflect the official policy or position of ADL.
Jason Haag‘s interest and background since 2001 has been in educational technology and distributed learning systems. He spent eight years supporting the U.S. Navy’s e-Learning program in both engineering and management roles before joining the Advanced Distributed Learning (ADL) Initiative in 2009. He is currently employed by The Tolliver Group, Inc. and provides Systems Engineering and Technical Assistance (SETA) support for the ADL. In this capacity his focus is on research and development of distributed learning
technologies such as SCORM, xAPI, and mobile learning. He’s a member of the IEEE Computer & Education Societies, IEEE Learning Technology Standards Committee (LTSC), the eLearning Guild, and the International Association for Mobile Learning (IAMLEARN). He also holds a M.Ed. in Education Management and Instructional Technology from the University of West Florida.