An outline and rationale for my proposal for “next generation SCORM”. I call it STARLET: Shareable Tools Activities and Resources for Learning Education and Training

This is the second in a series of papers prepared for an Education Priorities Working Group being run by W3C. While the first paper, Proposed W3C Priorities for Education, took a high level overview, this paper drills down into a proposal for a specific work item. At the technical level, which is not education-specific, I call this XDMDL, eXtensible Data Model Declaration Language. At the education level, I propose that the XDMDL should be used to underpin a new digitial ecosystem for learning. It is this education-specific ecosystem for which I propose the name STARLET: Shareable Tools Activities and Resources for Learning Education and Training. As before, if you are interested in what you read and want to get involved in the W3C discussions, email me at crispin.weston@saltis.org.

 Background

This is the second in a series of papers intended to scope out new work in W3C to improve technical interoperability standards for education. The first paper, Proposed W3C priorities for education, took a high-level overview of the key priorities for education. This paper makes a narrower proposal for a pragmatic and achievable first step. Although this means reducing the scope, I believe that we should nevertheless expect that this first step will generate a level of engagement and momentum that will help build a viable set of complementary standards to support a digital ecosystem for learning. In building such an ecosystem, W3C will need to collaborate closely with other standards organisations working in education, such ADL, IEEE LTSC and IMS GLC.

This paper defines four new acronyms, which reflect different aspects of the work being proposed.

Acronym	Explanation
XDMDL	Extensible Data Model Declaration Language The development of this specification lies at the heart of the work proposed. It will allow different agencies to declare meaningful, structured data models, maintain consistent meaning in those declarations, and share, combine and map each other’s declarations. This will enable the exchange of semantically meaningful data between different services, while at the same time allowing the resilience required to support differing communities of practice and innovation.
STARLET	Shareable Tools Activities and Resources for Learning Education and Training An ecosystem of interoperable digital services for education, based on the use of XDMDL. In the proposed W3C Community Group, STARLET will define the implementation of XDMDL that will allow the abstract specification to be tested. The use of xAPI will be another foundational piece of the piloting of STARLET.
LAD	Learning Activity Declaration A metadata record describing a learning activity in the STARLET ecosystem
RDP	Runtime Data Payload A data instance that is passed at runtime between two communicating services. I use this acronym as a generic  term: an xAPI statement is one particular type of RDP.

Prioritising requirements

The first paper, Proposed W3C Priorities for Education, recommended building on top of the work already done on the Experience API specification (aka. TinCan), adding five further areas in which work was required. This paper proposes reducing these five areas to just two areas that could together be addressed by a single work item:

• a simple but consistent method of publishing metadata for learning content, supporting both discoverability and the declaration of runtime functionality.
• a data model description language which will enable supplier communities to specify new data structures in a consistent and extensible manner, allowing for the development of new metadata and runtime data models in a timescale that mirrors product innovation

The first of these objectives is closely related to what was referred to by participants in LETSI (2008-2012) as “Learning Activity Definition” (LAD), a term created, I believe, by Tyde Richards. In this paper, I replace “definition” with “declaration” to avoid confusion between the declaration of data types with the definition of terms, which is an important part of any standardisation process.

The second objective corresponds to what in the LETSI discussions was called “Data Model Definition” (DMD), a term which I believe was created by Avron Barr. Again, I am replacing the “definition” with “declaration” and adding an X, partly to show that this is the same sort of thing as other members of the XML family: a sort of high level schema language.

I recommend postponing action on the remaining three points mentioned in our earlier paper, for the reasons outlined below.

Deferred objective	Reason for deferral
A new specification for the adaptive sequencing of learning content.	It is not possible to sequence activities until the atomic activities have themselves been defined.
A specification for the machine-readable description of learning objectives and curricula	Work on this requirement is being considered in the IEEE LTSC. I recommend that any CG in W3C co-ordinates closely with the LTSC group, looking for synergies but avoiding any duplication of work.
A machine-readable data handling description language, allowing for the specification of procedures for data protection and privacy	Though important, this is a challenging objective, with implications that reach far outside education. We need to generate momentum before we can claim to be ready to tackle it.

Reiteration of the requirements

Learning Activity Declaration (LAD)

The LAD is a metadata instance that:

• describes a learning activity;
• conforms to the XDMDL specification.

Being an instantiation of XDMDL, LAD itself requires little work. It may nevertheless be useful to reiterate the requirement for LAD metadata and to illustrate the part that it will play in the STARLET ecosystem.

What is metadata?

In the context of specifications like Learning Object Metadata (LOM), the term “metadata” is often understood to refer to bibliographic or classification metadata, the purpose of which is to support search and discovery. The requirement for metadata is nevertheless much broader than this. For example, metadata may also contain:

• interface data to describe how an object should be described and branded in third-party interfaces;
• rights information;
• technical descriptions of how to use the resource, including authentication requirements and information about its runtime behaviours.

An illustration of what is meant by “runtime behaviours” is the field called ScormType that the SCORM specification added to IMS Content Packaging. This could equal either “sco” (meaning the webpage used the CMI runtime) or “asset” (meaning it did not). Proposed W3C Priorities for Education argued that developers need more flexibility in the sort of runtime data that a learning activity can read from a launch service or write back to a reporting service. Providing such flexibility will require a greatly expanded description of runtime behaviour in the learning activity’s metadata.

Extensible Data Model Declaration Language (XDMDL)

XDMDL is proposed as a sort of schema language that will allow suppliers to create strongly typed extensions to existing data models. By focusing on the creation of this schema language, the problem that has bedevilled the ed-tech community for fifteen years is finessed. Instead of asking, “how can the community agree a single data model that provides for perfect data interoperability?”, it answers a slightly different question: “how can the community agree a single way of defining the different data models that will be required, both by different communities of practice and to support new innovations, such that services can achieve satisfactory data interoperability while also accommodating the need for resilience?”

Both the LAD and RDP data will in the STARLET ecosystem represent instantiations of XDMDL.

The communication of meaning in educational data

For the last twenty years, a theory of “criterion referencing” has been popular in education. This held that learning objectives can be summarised in short descriptive rubrics. In America, these rubrics are called “Learning Standards”, in the UK’s 1988 National Curriculum, they were called “Statements of Attainment”. These evolved into “Level Descriptors”, which were recently abolished, on the grounds that every teacher tended to interpret such descriptors differently.

Maintaining a consistent understanding of such learning objectives throughout a community is a complex task. Commonly, it requires the circulation of mark schemes, sample scripts and examiners’ reports, and the administration of moderation and appeals processes. Although many of these activities depend on good peer-to-peer communication, ultimately they require a process of active management by some authority, such as an awarding body.

From the point of view of a data specification, the consequence of this discussion is that the semantic meaning of a particular element is not “defined” by a short rubric, but “stewarded” by an organisation that can be understood as “owning” the definition.

This process can be captured by the following technical provision. An XDMDL identifier shall be defined to be an Internationalized Resource Identifier (IRI) that is also a locator for a XDMDL metadata object. In this way, the identified object will always be associated with its description and that description shall be controlled by the owner of the domain on which the description is located.

I refer to this principle as that of “authoritative metadata”: that is, metadata that is located at the IRL indicated by its IRI.

It may be objected that systems using authoritative metadata may be easily disrupted when links are deprecated or are temporarily unavailable. But the principle of authoritative metadata does not preclude any system that depends on the ability to access such metadata from making a local copy. Community sites could also keep copies against the possibility that the authoritative site might close permanently. Such community sites could also be responsible for monitoring the conformance of different domains to the rules for the persistence of such data and version management. In essence, reputable domains would ensure that once a declaration was declared to be final, no substantive changes could be made, other than to deprecate the declaration (in which case, it might be superseded by a later version). Nor would the principle of authoritative metadata preclude local services creating declarations with only local scope. The requirement that metadata should be “authoritative” does not extend beyond the scope within which the data can be read.

STARLET

STARLET refers to an ecosystem in which multiple services and data instances work together in an integrated environment. The diagram opposite illustrates how this would work to ensure the reporting of learning outcome data in RDPs (such as xAPI statements).

The activity to be launched is identified by an Activity IRI. The diagram does not specify where or how this IRI is found. The Third Party Service, which might be a Learning Management System (LMS), reads the Activity IRI and, by de-referencing the IRI, reads the LAD that describes the activity and defines the data which the activity will need in order to be launched, and the learning outcome data that it will report when it terminates. The meaning of this data is specified by Data Definition IRIs that point to  declaration objects, which may be located in one or more XDMDL libraries. The LAD will also contain the technical information required to launch or establish communication with the Activity Provider—the software that will deliver the particular activity that the LAD describes.

Having established that it can interoperate usefully with the AP and having launched or established communication with it, the Third Party Service and the AP can exchange runtime data according to the rules already declared in the LAD, the XDMDL, and any other referenced specifications, such as xAPI.

Relationship to xAPI

Outline of xAPI

This section of the paper refers to the xAPI specification, version 1.0.0, which is available at http://www.adlnet.gov/wp-content/uploads/2013/05/20130521_xAPI_v1.0.0-FINAL-correx.pdf.

The xAPI specification describes how Activity Providers can report statements to a Learning Record Store (LRS) about what a learner has done with/to/in the context of a particular object. Each statement is based on a core syntax made up of the following properties:

Term	Meaning
actor	person undertaking the activity, normally the learner
verb	what the actor did (e.g. “passed”, “completed”, “made” etc.)
object	what the actor did this to, normally a reference to the activity or some feature of the activity
result	an optional data record containing more information about what the actor did, with a default specification that maps the original CMI data model used in SCORM
context	an optional data record giving more information about the circumstances in which the action occurred

The need for an extension mechanism

The ways in which actor and object are identified use well-established specifications; but the definition of the verb, result and context parts of the statement are left open for different communities of practice to define their own terms and data models.

While this decision is entirely understandable, for reasons already discussed, it makes the xAPI specification dependent on communities of practice coming together to create shared vocabularies and data models. The social and commercial dynamics through which this normally happens are complex and often these dynamics tend to inhibit innovation.

The XDMDL will provide a mechanism for small groups of innovative developers to propose new data types and structures, allowing the success of their practice rather than any kind of community consensus to determine whether these proposals are more widely adopted. It seeks to resolve the impasse by which new interoperability standards cannot be created until they have been proven and cannot without great difficulty be proven until they have been standardised.

The XDMDL therefore seeks to address a requirement that the abstract nature of the xAPI specification explicitly highlights: the need for a robust extension mechanism that does not depend on achieving prior community consensus.

The interdependence between runtime data and metadata

Significant sections of the xAPI specification concern the exchange at runtime of data that would be better provided, prior to launch, through LAD metadata. The advantages of such an approach would be that it would:

• reduce network traffic and processing time by reading data once rather than many times;
• improve the reliability and consistency of the data by avoiding duplication;
• avoiding concurrency and authorization issues by reading the data from an authoritative source (i.e. from the location at which the activity’s identifier is de-referenced) rather than from a communicating service which might attempt to edit data when it had no authority to do so or when a more up-to-date version was already stored by the interoperating service;
• inform users of the extent of interoperability that can be achieved at registration time (when a teacher might be considering what activity to use in tomorrow’s class) rather than at runtime (when a teacher may have 30 students in front of them, waiting to get on with some productive work).

A simple example of this principle is the xAPI verb object, which has the following properties (page 13):

Verb Object
Property	Type
id	IRI
display	LanguageMap

The display property contains a list of ways that the verb might be rendered in different languages. The specification suggests that the verb may also be embedded in natural language text, in which case the verb might be adapted to use different tenses. Such a scenario suggests a more complex display matrix, specifying languages, tenses, and maybe conjugations as well. As this data could be extensive and will always be the same, it would be much better declared once, in the LAD metadata rather than passed repeatedly at runtime, every time the verb was used.

A more complex example is provided by the Activity Object, which is declared as follows.

Activity Object
Property	Type
objectType	Always “Activity”
id	IRI
definition	Object (see below)

Activity Definition Object
Property	Type
name	LanguageMap
display	LanguageMap
type	IRL
moreInfo	IL
…
extensions	Object

Without explaining the meaning of the various properties in this nested object, it should be apparent that most of his data would be better advertised in a single LAD, rather than passed repeatedly at runtime.

The xAPI specification comprises not one but several APIs. The Agent Profile API and Activity Profile API allow third party systems to write unspecified data as a series of name-value pairs, describing an activity or a learner to an LRS. Although the scenarios in which these APIs might be used are not fully illustrated in the specs, it seems that such a mechanism is likely to suffer from drawbacks:

• because the data is not comprehensible to the LRS, it cannot reliably be used to support analytics, even though descriptions of activities and learners are, in principle, very useful for this purpose;
• the LRS is required, “to the extent that it is possible”, to decide whether different clients are authorized to add and delete such data;
• it is likely that this data will need to be copied to multiple LRSs, while in most cases, it would be more reliably stored in a single place.

These comments are not meant as a criticism of the xAPI specification but as an illustration of how it might be improved were it embedded within a broader ecosystem, of the type that STARLET would provide.

The principle of authoritative metadata

The proposals outlined so far depend on the central notion of “authoritative metadata”. It is interesting to see that the xAPI specification recommends the same approach. This may not be so surprising, since xAPI and XDMDL both originated in the same set of discussions that occurred in LETSI in 2008-12.

On page 16, the xAPI specifications describe the possibility of including Activity Metadata using exactly the same mechanism that is being proposed in this paper.

If an Activity IRI is an IRL, an LRS SHOULD attempt to GET that IRL…as soon as possible after the LRS first encounters the Activity id.

This proposal would require that the xAPI “If an Activity IRI is an IRL, an LRS SHOULD…” be changed to a STARLET “An Activity IRI MUST be an IRL and an LRS MUST…”. The principle is the same, except that xAPI offers no specification for the formatting of the activity metadata that would be loaded in this way.

Once the activity metadata had been defined, much of the data passed in the runtime statement could then be transferred into the metadata object, where it really belongs.

An illustration drawn from basic coding

The following illustration contains a piece of simple code, written in Pascal.

It should be possible even for a non-programmer to follow what is happening in this snippet of code. First, the program makes a type declaration, then it declares two variables, both of which conform to the new type, and finally it assigns values to the variables, which are then be manipulated and the calculated result displayed.

This extract illustrates the fundamental role played within most coding languages of type and variable declarations. It illustrates how:

• the assignment of values to variables depends on prior variable declarations;
• variable declarations depend on prior type declarations
• type declarations may themselves depend on prior type declarations (in this instance, the type “name” is declared to conform to the primitive datatype “string”).

In terms of the STARLET diagram on page 4:

• the XDMDL Library contains type declarations;
• the LAD and runtime data instances correspond to variable declarations;
• the population of those instances with actual data corresponds to the assignment of values to the variables.

This example illustrates how the STARLET ecosystem aspires to create an environment in which strongly typed, structured data can be shared between different services, using principles that are already well-established in coding languages.

Summary of the purpose of STARLET

The STARLET ecosystem, in which the DMD specification will play a foundational part, will allow different agencies:

• to share, extend, combine and assert equivalencies between different data definitions;
• to maintain a consistent understanding of what those data definitions mean;
• to instantiate data records based on a heterogeneous mix of data definitions;
• to understand, at the time at which different services first discover each other, how much data they can usefully exchange, and whether the parties will be able to make enough sense of that data to support useful interaction.

Characteristics of XDMDL

In the STARLET diagram on page 4, XDMDL specifies how to construct:

• the XDMDL declaration library,
• the STARLET LAD
• the STARLET RDP (such as an xAPI statement).

It will also specify how the two data instances should reference the data declarations contained in the library.

Each XDMDL library will be a single XML file and that each file will contain multiple declaration objects.

Declaration objects may be nested within one another to allow both for declaration of properties (ie. nested declaration objects combined with a logical AND) and the XDMDL equivalent of object inheritance (i.e. nested declaration objects that are combined with a logical OR).

Structures will be provided to allow for the declaration of collections and arrays.

Each declaration may be individually referenced, using one of two fragmentary referencing schemes.

• When referenced from another XDMDL instance, a native XDMDL referencing scheme will be used. This will be simple to read and will ensure that only valid declaration objects are referenced and not component XML elements.
• When a reference needs to be passed to a context in which XDMDL is not understood, the XDMDL reference will be converted into a generic XPointer.

The set of possible XDMDL references being a subset of the set of possible XPointers, XDMDL references will always be convertible to XPointers but not necessarily vice versa.

The existence of a robust fragmentary referencing syntax will allow:

• data instances to reference appropriate type definitions;
• type definitions to reference other type definitions (for example to support inheritance between libraries);
• data instances to reference other data instances (allowing the XDMDL equivalent of pointers—a powerful data type commonly used in many coding environments).

Being based on a presumption that all data will be strongly typed, STARLET data instances will be easily checked by industry standard validation tools. This will help to address a recurring problem in previous education specifications of poorly formed XML which often failed to comply with underlying data standards.

Relationships with other standards work

xAPI

The relationship with xAPI has already been explained. STARLET aims to complement and extend xAPI but not to change the underlying xAPI specification. All STARLET implementations that use any part of the xAPI specification will be compliant with the current xAPI specification, though not vice versa.

We hope and expect that a new W3C Community Group will enjoy close liaison with the current xAPI community and would welcome future collaboration that aims to exploit the synergies between xAPI and the proposed XDMDL.

IEEE LTSC

We note that work is planned in IEEE LTSC on a new approach to competency definitions, which is similar to the requirement described in Proposed W3C priorities for education as “learning objectives and curricula”. I expect that any new W3C Community Group would take a close interest in such work by the LTSC, that many of its members might like to contribute individually to such work, and that as a group, we would be interested to see how any output from the LTSC work might be incorporated into the STARLET ecosystem.

IMS GLC

There are at present no IMS standards that are currently of direct interest in the development of the XDMDL specification or the STARLET ecosystem. Once the ecosystem has been defined, there may be scope for work that ensures the integration of IMS specifications such as LTI and QTI.

IDPF and EDUPUB

The initial work on XDMDL and STARLET will not depend on integration with e-Textbooks that are created using the EDUPUB specification. In the longer term, I believe that it will be important to integrate e-Textbooks within a wider ecosystem that supports the reporting of learning outcome data from interactive experiences. There has already been useful prototyping work being undertaken in the Actionable Data Book project, led by Tyde Richards in the IEEE LTSC, and when the STARLET work is a little more mature, we would be interested to discuss with the LTSC how that work could be leveraged to integrate EDUPUB textbooks into a STARLET ecosystem, using methods demonstrated by ADB.

CMI-5

CMI-5 was the last iteration of the Computer Managed Instruction (CMI) specification, originally developed by the Aircraft Industry CBT Committee (AICC), parts of which were used by ADL’s SCORM standards. The AICC recently closed and the CMI-5 was inherited by ADL. Its principAL interest, I believe, is now as a profile of xAPI that supports legacy CMI content—though this is a point which I will be interested to discuss further with ADL. Similar profiles of xAPI have been developed by ADL to support legacy SCORM content.

Proposed next steps

A recurring difficulty in standards work, particularly in the world of education, is the doubtful utility of specifications that are developed without being grounded in robust implementations, and the difficulty of attracting serious implementers to experimental standards work.

I recommend that work should start on creating a base document for XDMDL which is:

• sufficiently detailed to allow work to start on prototyping;
• sufficiently simple to be easily accessible to those who are not yet persuaded of the merits of serious investment in this work.

Such a document may take 3 or 4 months to create, working with a small group that combines expertise in educational standards with expertise in W3C standards.

Once such a document has been created, it can be advertised to potential implementers and the W3C Community Group can be launched formally. Further work on the development of the specification would then be undertaken on the basis of prototyping and piloting work.

The momentum achieved by the group should be monitored and decisions taken at the appropriate time on what opportunities exist to:

• bid for funding from public sector bodies who might have an interest in supporting more extensive prototyping and piloting;
• initiate spin-off projects and liaisons with other standards organisations;
• consider the level of interest that might exist in formal standardisation of all or some of this work.

If the existing W3C Education Priorities Working Group is interested in this outline proposal, I would be happy to lead work on XDMDL by presenting my ideas in a sequence of perhaps three stepped presentations.