Atlantis Learning Management System (ALMS) API

License

Copyright 2017-2022 Atlantis Learning Network

Unless required by applicable law or agreed to in writing, software distributed under this License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

Please send all feedback and inquiries to info@atlantislearning.net

Table of Contents

1. Introduction
2. How to Use This Document
3. Serialization and JavaScript Object Notation (JSON)
4. Definitions
5. Data Flow in ALMS API
6. Agent and Persona Management
7. Extending xAPI
8. Profiles, Vocabularies, and Learning Communities

1.0 Introduction

The Atlantis Learning Packets (ALPs) API provides an interface for learners and teachers to interact by sending and receiving data as JSON (JavaScript Object Notation) objects.

The ALPs API provides access to the content of your site and uses authentication restrictions to keep all content private and password-protected so content is only available with authentication or if you specifically set it to be “public.”

What Is A REST API?

The ALPs API is an extension of REST API.

REST API is an Application Programming Interface. REST, standing for “REpresentational State Transfer,” is a set of concepts for modeling and accessing your application’s data as interrelated objects and collections.

The ALPs REST API provides REST endpoints (URLs) representing the posts, pages, taxonomies, and other built-in content types.

The @lantis Network Nodes can send and receive JSON data to these endpoints to query, modify and create content on your site.

JSON is an open standard data format that is lightweight and human-readable, and looks like Objects do in JavaScript.

When you request content from or send content to the ALPs API, the response will also be returned in JSON.

Because JSON is widely supported in many programming languages, developers can build their own learning applications in client-side JavaScript (like the block editor), as mobile apps, or as desktop or command line tools.

Why the ALPs API

Note: The information we need is often scattered across a wide variety of sources.  Optimally accumulating and curating information from a wide variety of sources is a clear 21st Century need.  The Atlantis Learning Network and the ALPS API were born to help fill that need.

ALPS API assumes that developing a commonly-accepted framework for gathering, storing, and exchanging learning content would be a good thing.

The Atlantis Learning Packet Standard (ALPS) API is a technical specification that facilitates the sharing of “Learning Packets”  throughout a networked community.

ALPS API

• Specifies the JSON Format of a “Learning Packet.”
• Specifies a structure to add, store, and retrieve Learning Packets on a network.

The document that follows sets out the APLS API specification which is designed to achieve these goals.

The ALPS API is an effort of the @lantis Learning Network.

The goals of the ALPS API are:

• To make it easier to learn and take action on that learning. (This is done by having automated digital engines gather and curate potential learning information from a wide variety of contexts, platforms, and technologies.)
• To maximize interoperability of services that create, gather, store and process learning information. (The Network Effect.)
• To provide criteria against which conformance to this specification can be tested.

The document that follows sets out the ALPS API specification which is designed to achieve these goals.

2.0 How to Use This Document

This is intended to be an Open-Source working document.

Sections that provide a high-level overview of a given facet of the ALPS API are labeled description or rationale.

Items in this document labeled as requirements, details, or examples are more technical.

This specification is split into three parts:

• Part one is this introduction. It offers some background, high-level summaries, and directions on how to read the rest of the specifications.
• Part two of this specification defines a data model for various data objects that are used in this specification.
  • The most significant object within the ALPS API data model is the “Learning Packet” object.
  • This specification defines the properties of the Learning Packet object
    • Required Properties
      • Content
        • Raw Data -.jpeg, .mp4, .txt, .doc, and all forms of raw bits.
        • Lessons – Standalone lesson on one topic
        • Classes – Groups of Lessons
      • Action
        • Push – Add Learning Packets to the Network
        • Pull – Retrieve Learning Packets from the Network
      • Author
      • Date Stamp
    • Meta Data – Optional/Recommended
      • Author
      • Belief
      • Premise
      • Context
      • Definition
      • Authority
      • Modification Date
      • Courses
      • Lessons
    • Blockchain
      • History of transactions
    • The rules of syntax for the values of those properties and how they are represented.
    • This part helps to ensure that services implementing the specification follow a consistent data structure.
  • Part three of this specification sets out the transfer methods that must be used when communicating information.
    • This includes the format of requests and the expected responses.
    • Note that communication in ALMS API is not restricted to a “Learning Community Library (LCL)”  “Learning Communities” communication only. LCLs can communicate with a wide range of “Authors” and a wide range of “Consumers.”
    • ALMS API follows the guidelines of the REST software architecture style, (https://www.quora.com/topic/REST-software-architectural-style, https://en.wikipedia.org/wiki/Representational_state_transfer) and as such data is transferred via HTTP requests and responses.
    • Part three also defines security methods allowing for the trusted exchange of information between the LCL and trusted “LCs”.

2.1 MUST / SHOULD / MAY

There are three levels of obligation with regards to conformance to the ALMS API specification identified by the terms MUST, SHOULD and MAY.

• A service or system that fails to implement a MUST (or a MUST NOT) requirement is non-conformant.
• Failing to meet a SHOULD requirement is not a violation of conformity, but goes against the recommendations of the specification.
• MAY indicates an option, to be decided by the developer with no consequences for conformity. Usage of these terms outside of requirement language does not designate a requirement and is avoided whenever possible.
• “SHOULD NOT” and/or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

Complete definitions of MUST, SHOULD, MAY, MUST NOT and SHOULD NOT are found in https://www.ietf.org/rfc/rfc2119.txt.

The use of an asterisk* following SHOULD indicates a very strong recommendation. It is planned that these recommendations will become MUST requirements in a future version. Not following these recommendations could risk interoperability and and/or lead to various other issues depending on the specifics of the recommendation.

These recommendations cannot be MUST requirements within this version as these would be breaking changes. The ALMS API Working Group strongly encourages adopters to implement these requirements as though they were MUST requirements, while continuing to support other adopters that might not do so.

2.2 Guidelines for Interpreting Descriptive Text and Tables

As a rule of thumb, if the guideline appears technical or seems to be a requirement, interpret it as such. This is especially true of longer, more, detailed explanations and of tables, each of which would be unintuitive and/or lengthy to dissect into a list of requirements.

Tables are used throughout this specification to define requirements for lists of properties, parameters, etc.

The tables define which properties are required, recommended and optional. Generally, the notion of “optional” relates to the service creating the object, while services receiving and interpreting the object need to be able to interpret all properties of that object. Often, properties are optional because the data may not be relevant in every context; if the data is relevant in a particular context, then it is expected the property will be populated.

If an optional property or parameter contains an object with properties that are recommended or required, then these properties are only recommended/required if the property or parameter containing them is used.

Examples are provided throughout the specification and in appendices to illustrate implementation. The content of these examples is fictional in order to illustrate the requirements of the specification and may not always illustrate the best practice approach to tracking the particular learning experience used in the example.

Examples can be used to inform interpretation of requirements, but are not intended to take precedence over requirements.

Where the specification does not include requirements relating to a particular facet of implementation, that detail can be considered to be outside of the scope of this specification. It is up to the implementer to determine a sensible approach. This specification tries to avoid vagueness and will usually give a rationale even if there no requirement in a given area.

3.0 Serialization and JavaScript Object Notation (JSON)

Serialization is the process of translating data objects and structures into a format for storage or transmission, such that the original data object can be recreated from the resulting serialization.

In some cases it might be possible to serialize a piece of data in more than one way. For example, a boolean property with a value corresponding to true might be represented as true or 1 depending on the serialization used.

ALMS API follows the rules of JSON for serializations (so boolean values are represented as true or false). It might also be possible to represent the objects defined in this specification using other serializations, such as XML. This is out of scope of this specification and use of anything other than JSON to represent the objects defined in this specification is not conformant.

Even within the rules of JSON there are possible variations of how data can be serialized, especially in relation to data about time. This is significant as a number of features of ALMS API rely on systems being able to determine whether two Statements are equivalent. See Immutability and exceptions for more details about the properties of the Statement affected by this.

JSON allows for objects to have properties that contain empty objects. This is not recommended within ALMS API; if the Statement is not intended to contain data about a property then it is expected that the property will not be used at all. All required properties are required to contain values.

4.0 Definitions

Activity (A): A type of Object making up the “this” in “I did this”; it is something with which an Author interacted. It can be a unit of instruction, experience, or performance that is to be tracked in meaningful combination with a Verb. Interpretation of Activity is broad, meaning that Activities can even be tangible objects such as a chair (real or virtual). In the Statement “Anna tried a cake recipe”, the recipe constitutes the Activity in terms of the ALMS API Statement. Other examples of Activities include a book, an e-learning course, a hike, or a meeting. 

Activity Author (AA): The creator of the Packet. 

ALMS API (ALMS API): The collection of rules articulated in this document which determines how learning experiences are defined, formatted, and exchanged so that independent software programs can exchange and make use of this information.

Application Programming Interface (API): A set of rules and standards created to allow access into a software application or tool. Authentication: The concept of verifying identity. Authentication allows interactions between two “trusted” parties. 

Authorization (Au): The affordance of permissions based on role; the process of making one party “trusted” by another. 

Avatar: The Public Persona used by the Learner or Learning Community.

Blockchain: The historical record of a particular Statement or Question

Client (C): Refers to any entity that might interact through requests. Some examples could be a Learning Community (LC), an Unregistered Consumer (UC), a Registered Consumer (RC), a Learning Community Library (LCL), or a Learning Management System (LMS).

Community of Practice (CoP): See Learning Community

Conclusion:  A Statement that cannot be proved as it is a construct of an individual Learners experience.  Conclusions can be reasonable or not-reasonable.  Conclusions cannot be True or Not-true.

Endpoint (EP): An entry point in a service-oriented-architecture. ALMS API mirrors this approach with resources by defining the IRI from which communication takes place as an endpoint.

Fact Statement (FS):  A sentence where the intent of the sentence can be directly observed.

Fact (F):  A Fact Statement that can be directly observed.

Immutable: Adjective used to describe things which cannot be changed. With some exceptions, Statements in the ALMS API are immutable. This ensures that when Statements are shared between LCLs, multiple copies of the Statement remain the same.

Internationalized Resource Identifier (IRI): A unique identifier which could be an IRL. Used to identify an object such as a verb, activity or activity type. Unlike URIs, IRIs can contain some characters outside of the ASCII character set in order to support international languages. IRIs always include a scheme. This is not a requirement of this standard, but part of the definition of IRIs, per RFC 3987. What are sometimes called “relative IRIs” are not IRIs.

Internationalized Resource Locator (IRL): In the context of this document, an IRL is an IRI that when translated into a URI (per the IRI to URI rules), is a URL.

Inverse Functional Identifier: An identifier which is unique to a particular persona or Group.

Learner (L): An individual or group representation tracked using Statements performing an action within an Activity. Is the “I” in “I did this”.

Learning Community (LC): A group of practitioners connected by a common cause, role or purpose, which operates in a common modality. Learning Communities are focused on implementing ALMS API within a specific knowledge domain or use case. Individual LCs or Groups of LCs, can create domain-specific vocabularies, profiles, and curriculums. These practices usually involve work around defining use cases and curating the various vocabulary terms, synonyms, and other related metadata that might be preferred within a LC. They can also reuse existing vocabularies, profiles, and recipes already published by other LCs or participants of the ALMS API community.

Learning Community Library (LCL): A server (i.e. system capable of receiving and processing web requests) that is responsible for receiving, storing, and providing access to Learning Records.

Learning Experience: An event associated with learning. It is highly diverse as far as what it can be.  Examples include reading a book, post, or watching a video, taking an online course, going on a field trip, engaging in self-directed research, or receiving a certificate for a completed course.

Learning Management System (LMS): “A software package used to administer one or more courses to one or more learners. An LMS is typically a web-based system that allows learners to authenticate themselves, register for courses, complete courses and take assessments” (Learning Systems Architecture Lab definition). An LMS in this document is used as an example of how a user is identified as “trusted” within a system and able to access its Learning Experiences.

Learning Nugget: A packet made up of data (jpg, mp4, txt, doc) and meta-data that describes what the data teaches.

Learning Record: An account of a learning experience that is formatted according to the rules of ALMS API. A Learning Record takes on many forms, including Statements, documents, and their parts. This definition is intended to be all-inclusive.

Learning Library Consumer (LLC): An ALMS API Client that accesses data from Learning Community Library(s) with the intent of processing the data, including interpretation, analysis, translation, dissemination, and aggregation.

Learning Record Provider (LRP): An ALMS API Client that sends data to Learning Community Library(s). Often, the Learning Record Provider will create Learning Records while monitoring a learner as a part of a Learning Experience.

Metadata Consumer: A person, organization, software program or other thing that seeks to determine the meaning represented by an IRI used within this specification and/or retrieves metadata about an IRI. An LCL might or might not be a metadata consumer.

Metadata Provider: A person, organization, software program or other thing that coins IRIs to be used within this specification and/or hosts metadata about an IRI.

Persona: A set of one or more representations which defines an Actor uniquely. Conceptually, this is like having a “home email” and a “work email”. Both are the same person, but have different data, associations, etc.

Profile: As much background as possible about the Author or Creator of the Statement.

Question:  A information packet design to recieve a response Statement.

Recommended Action: A Statement that describes a action the Learner should take.  For example: “Bring an umbrella.”

Representational State Transfer (REST): An architecture for designing networked web services. It relies on HTTP methods and uses current web best practices.

Service: A software component responsible for one or more aspects of the distributed learning process. An LMS typically combines many services to design a complete learning experience.

Statement: A single packet of bits.  Follows the ALMS API data sctructure showing evidence for any sort of experience or event which is to be tracked in ALMS API as a Learning Record. A set of several Statements, each representing an event in time, might be used to track complete details about a learning experience.

Verb (V): Is the action being done by the Actor within the Activity within a Statement. A Verb represents the “did” in “I did this,” or “I found this.”

Vocabulary (V): A list or collection of the terms that are used by a LC for labeling or categorizing information in a particular domain. The use of a vocabulary ensures that everyone is using the same word to mean the same thing. This section explains and shows graphically how different pieces of xAPI can fit together.

5.0 Data Flow in ALMS API

Figure 1 – ALMS Algorithm

Figure 1 shows the information flow of learning experiences.

A learner either completes a learning experience, whereby they “Push” or “Add” that information to the LCL.  Or they have a Question, whereby they “Pull” the answer to that question from the LCL.

This experience could take place in an online course, it could be on the job or it could be part of recreation. It really could be anything.

This experience could be tracked, on the learner’s behalf, by a trusted Learning Community (LC). The LC can also be responsible for the trusted relationship between the experience and the learner. This might even include launching content for the learner and managing digital rights associated with the content.

The LC creates Learning Records and sends them to one or more Learning Community Libraries (LCLs). The LCL stores the Learning Records and makes them available to any authorized Client. A Learning Record Consumer (LRC) is a type of Client that accesses Learning Records and makes use of them.

6.0 Agent and Persona Management

ALMS API Agent and Persona Management

ALMS API grants the framework for allowing selective access to one’s personal data.

This is done through the management of what are called personas. In ALMS API, each persona represents the “I” in “I did this” and is logically the subject of the Statement. Each Agent or Group in ALMS API corresponds to a persona.

A learner sending Learning Records to an LRS could have multiple personas (Agents) associated with him or her. In Figure above a learner accesses multiple services. Some of these services are used at work, others at home. Some are used for social purposes and others are used for educational or professional puproses. Thus, there are multiple personas functioning collectively within these services.

Each of these services send data to the LCL. Afterwards, there are Statements from three different personas of the same learner. The LCL can aggregate all of the information of each of the personas into one “Person” Object. This object can be retrieved from The LCL via the Agents Resource.

How the LCL knows that these multiple personas belong to a single person is out of scope of this specification and there are several different approaches that an LCL can take. It’s also possible that some LCLs will have no mechanism for associating personas.

7.0 Extending xAPI

The ALPs API exposes many fields on API responses, including things you might not need, or which might not fit into how your site works.

While it’s tempting to modify or remove fields from ALPs API responses, this will cause problems with API clients that expect standard responses. This includes mobile clients or third-party tools to help you manage your site.

You may only need a small amount of data, but it’s important to keep in mind that the API is about exposing an interface to all clients, not just the feature you’re working on. Changing responses is dangerous.

Adding fields is not dangerous, so if you need to modify data, it’s much better to duplicate the field instead with your modified data.

Removing fields is never encouraged; if you need to get back a smaller subset of data, use the _fields parameter or work with contexts instead.

It is recommended that LCs agree on how to use extensions for their particular use cases and use profiles whenever possible.

Implementation details are covered in 4.1 Extensions.

The About Resource is another instance where ALMS API supports extensions.

The LCL may find it useful to communicate features or behaviors beyond this specification. The LCL can use extensions to the About Resource to facilitate this communication.

8.0 Profiles, Vocabularies, and Learning Communities

ALMS API strictly defines the structure of Statements, but is very flexible as to the contents of that structure.

For example, the specification requires that all Statements have a “verb” property, but does not restrict the values of that property; any Verb can be used. This flexibility enables ALMS API to be used in any context, including future use cases not envisaged by the specification authors.

It is intended that LCs will define Verbs, Activity types, contextual relationships, extensions, etc. to be used in their profiles by providing unique identifiers wherever applicable.

The CoP will define these identifiers and their metadata in a Vocabulary. A profile is a set of rules and vocabularies to implemented in addition to xAPI for the particular use case being addressed. It is very important that such communities exist and share best practices. For more information on publishing vocabularies, see the Vocabulary Companion Specification and Vocabulary Primer documents.

It is recommended that a profile use a unique “category” within a Statement’s context to refer to any Statement which implements the profile. An example of a LC for the medical field is the MedBiquitous Learning Experience Working Group.

• Discussion Structure
  • Nouns
  • Verbs
  • Objects
  • Fact
  • Conclusion
  • Action
• Meta
  • Author
  • Creation Date
  • Is it Original Content
  • Links
  • Taxonomy – (Describes how the discussions are “Connected.”  The organizational structure of the information.)

9.0 Statements

9.1 Purpose:

Statements are the information, evidence, experience, or event which is to be tracked in ALMS API
While Statements follow a machine readable JSON format, they can also easily be described
using natural language. This can be extremely useful for the design process. Statements are
meant to be aggregated and analyzed to provide larger meaning for the overall experience than
just the sum of its parts.

9.2 Formatting Requirements

Requirements

• Statements and other objects SHOULD NOT include properties with a value of an empty object.
• A Statement MUST use each property no more than one time.
• A Statement MUST use “actor”, “verb”, and “object”.
• A Statement MAY use its properties in any order.
• The ALMS Library MUST NOT return a different serialization of any properties except those
  listed as exceptions.

Learning Community Requirements

The following requirements reiterate especially important requirements already included elsewhere, to emphasize,
clarify, and provide implementation guidance. Some types of validation, such as complete IRI validation and validation
that properties appear only once, are extremely difficult, so much of the burden
for ensuring data portability is on the Learning Community.

• Values requiring IRIs MUST be sent with valid IRIs.
• A library SHOULD be used to construct IRIs, as opposed to string concatenation.
• Values SHOULD be considered to be case sensitive unless specified otherwise.
• Lowercase SHOULD be used to send case insensitive data.
• Additional properties SHOULD* NOT be added to Statements unless explicitly allowed by this specification.
• A property SHOULD not occur multiple times in an object. If properties are used multiple times within an object, the behavior of the LRS is undefined; it is expected that most LRSs will use existing JSON parsing functionality of whichever code languages they use.

Note: The ALMS Library is recommended to reject Statements containing additional properties. Additional properties in
Statements would mean that the Statement would not be interoperable with all ALMS Libraries.

ALMS LIbrary Requirements

• The ALMS LIbrary MUST reject Statements
  • with any null values (except inside extensions).
  • where the wrong data type is used, for example:
    • with strings where numbers are required, even if those strings contain numbers, or
    • with strings where booleans are required, even if those strings contain booleans.
  • with any non-format-following key or value, including the empty string, where a
    string with a particular format (such as mailto IRI, UUID, or IRI) is required.
  • where the case of a key does not match the case specified in this specification.
  • where the case of a value restricted to enumerated values does not match
    an enumerated value given in this specification exactly.
  • where a key or value is not allowed by this specification.
  • containing IRL or IRI values without a scheme.
• The ALMS LIbrary MUST at least validate that the sequence of token lengths for language map keys
  matches the RFC 5646 standard.
• The ALMS LIbrary MUST process and store numbers with at least the precision of IEEE 754 32-bit
  floating point numbers.
• The ALMS LIbrary MUST validate parameter values to the same standards required for values of the
  same types in Statements. Note: string parameter values are not quoted as they are in JSON.
• The ALMS LIbrary SHOULD treat all values as case sensitive unless specified otherwise.
• The ALMS LIbrary MAY use best-effort validation for IRL and IRI formats to satisfy the
  non-format-following rejection requirement.
• The ALMS LIbrary MAY use best-effort validation for language map keys to satisfy the
  non-format-following rejection requirement.
• Additional properties SHOULD* NOT be added to Statements and other objects unless explicitly
  allowed by this specification and the LRS SHOULD* reject Statements containing such additional properties.

9.3 Statement Lifecycle

Statements are information about a tracked learning experience. Typically, the information represented in the Statement has already happened. Thus, the natural language used in “display” or in the human-readable portion of
the Verb id will usually use the past tense.

Statements are expected to be permanent. The only way to undo a Statement within this specification is to
void it. Voiding does not destroy a Statement, rather indicates the evidence in the Statement is to be disregarded.

9.3.1 Statement Immutability

Statements are immutable (they cannot be changed). The following are exceptions or areas not covered by this rule:

• Potential or required assignments of properties during LRS processing
  (“id”, “authority”, “stored”, “timestamp”, “version”).
• Activity Definitions referenced by a Statement. The content of Activity Definitions that are
  referenced in Statements is not considered part of the Statement itself. This means a deep serialization of a Statement
  into JSON will change if the referenced Activity Definition changes Statement Resource’s “format”
  parameter for details).
• Verbs referenced by a Statement. The “display” property of the Verb is not considered
  part of the Statement itself Statement Resource’s “format” parameter for details).
• Serialization of Timestamp data. This is not considered part of the immutable Statement itself.
  For example, the “timestamp” and “stored” properties of a Statement can be returned in a different timezone to the one with
  which they were stored so long as the point in time referenced is not affected.
  See 2.4.7 Timestamp and 2.4.8 Stored for details.
• Serialization of un-ordered lists. The list of Agents in a Group is not considered to be an ordered
  list. Thus, the LRS can return this list of Agents in any order. See Groups.
• Attachments. These are not part of Statements and an LRS will return Statements without
  Attachments when a Client requests them (see the Statement Resource’s “attachments” parameter for details).
• Case sensitivity. Some properties are case insensitive and changes in case therefore do not affect
  immutability. For example, the domain portion an e-mail address is case insensitive. It is recommended to use lowercase
  for any case insensitive text.

The following explicitly are not exceptions and are covered by this rule:

• Result Duration. Due to variable lengths of months, years and even minutes and the flexible nature of the “timestamp” property as representing either the start, middle or end of the experience, it is not possible for an LRS to accurately deserialize the Result Duration and convert between units of time. For this reason, the
  Result Duration is considered a string for purposes of Statement comparison.

Statement Comparision Requirements
There are a number of scenarios outlined in this specification which require Statements to be compared to see if they match. In these scenarios, the following rules apply:

• exceptions to Statement immutability MUST be ignored.

2.3.2 Voiding

Rationale

The certainty that an LRS has an accurate and complete collection of data is guaranteed by the fact that Statements
cannot be logically changed or deleted. This immutability of Statements is a key factor in enabling the distributed
nature of Experience API.

However, not all Statements are perpetually valid once they have been issued. Mistakes or other factors could dictate
that a previously made Statement is marked as invalid. This is called “voiding a Statement” and the reserved
Verb http://adlnet.gov/expapi/verbs/voided is used for this purpose. Any Statement that voids another
cannot itself be voided.

Requirements

• When issuing a Statement that voids another, the Object of that voiding Statement MUST have
  the “objectType” property set to StatementRef.
• When issuing a Statement that voids another, the Object of that voiding Statement MUST specify
  the id of the Statement-to-be-voided by its “id” property.
• An LRS MUST consider a Statement it contains voided if and only if the Statement is not itself
  a voiding Statement and the LRS also contains a voiding Statement referring to the first Statement.
• Upon receiving a Statement that voids another, the LRS SHOULD reject the entire request which
  includes the voiding Statement with 403 Forbidden if the request is not from a source authorized to void Statements.
• Upon receiving a Statement that voids another, the LRS SHOULD NOT* reject the request on the
  grounds of the Object of that voiding Statement not being present.
• Upon receiving a Statement that voids another, the LRS MAY roll back any changes to Activity or
  Agent definitions which were introduced by the Statement that was just voided.
• A Learning Record Provider that wants to “unvoid” a previously voided Statement SHOULD issue
  that Statement again under a new id.

Note: See “Statement References” in When the “Object” is a Statement
for details about making references to other Statements. To see how voided statements behave when queried,
See StatementRef in Part 3).

Example

This example Statement voids a previous Statement which it identifies with the Statement id “e05aa883-acaf-40ad-bf54-02c8ce485fb0”.

{
	"actor" : {
		"objectType": "Agent",
		"name" : "Example Admin",
		"mbox" : "mailto:admin@example.adlnet.gov"
	},
	"verb" : {
		"id":"http://adlnet.gov/expapi/verbs/voided",
		"display":{
			"en-US":"voided"
		}
	},
	"object" : {
		"objectType":"StatementRef",
		"id" : "e05aa883-acaf-40ad-bf54-02c8ce485fb0"
	}
}

2.4 Information Packet Properties

Terms used throughout Development

• Information Packet – A single content unit (article, post, page, graphic, tweet, etc)
• Source – The site or location from which

Details

The details of each Field in the Information Packet are described in the table below.

The details of each Field in the Information Packet are described in the table below.

• item_id
• source_title
  item_date
  item_author
  item_link
  item_feat_img
  item_wp_date
  item_tags
  source_repeat
  sortable_item_date
  readable_status
  revertible_feed_text
  pf_feed_item_word_count
  Displayed
• origin_item_ID
  nomination_count
  submitted_by
  source_title
  item_added_date – the date the item was added into the PressForward system via a feed.
  posted_date
  authors
  nomination_permalink
  date_nominated
  item_tags
  source_repeat
  Nominations
• origin_item_ID – The unique ID of the feed-item within the PressForward site.
  nomination_count – The number of times a feed-item was nominated.
  submitted_by – The numerical user ID who first submitted the post.
  nomination_permalink – A permanent link to the original story location.
  authors – A string with the authors of the original post (when available).
  date_nominated – The date the item was sent to nomination.
  item_tags – A string of tags from the original item.
  nominator_array – an array of users or a single string representing the user IDs of all users who nominated the post. [Needs work]
  source_repeat – If the same item was retrieved by more than one feed (accounts for aggregation feeds) this lists the number of different feeds that attempted to retrieve it.
  item_feed_post_id – The post_ID assigned to the origonal feed-item when it entered the PressForward system