Slides from a short presentation on xAPI Vocabulary and how it can be applied in Learning Analytics, as given at the LAK 2016 JISC Learning Analytics Hackathon.

1. VOCABULARY
STONE SOUP
RUSSELL DUHON
@FUGU13
CTO, SALTBOX

2. OTHER THAN
STONE
INGREDIENTS,

3. JISC UDD & XAPI RECIPES
• UDD
• entity-based, formed from HESA standards, HEDIIP feedback
• model all the way from institutions down to students
• xAPI Recipes
• minimal, mostly focused on verbs and a few guidelines
• capture a small number of VLE-type events, plus alerting
• should be considered preliminary but usable
• the extensions seem to have a few problems
https://github.com/jiscdev/xapi-vle https://github.com/jiscdev/analytics-udd

4. IMS CALIPER “METRIC PROFILES”
• based on other IMS standards
• cover numerous VLE & content events
• rich with metadata
• alpha quality; missing documentation, conflicting documentation
• great source of ideas
• badly based on a very outdated draft of Activity Streams 2
• sort of uses JSON-LD, but in ways that have caused problems
https://www.imsglobal.org/activity/caliperram

5. LACE DSLA
• focused almost entirely on verb+object basics
• pretty much ignores everything else
• good source of brainstorming about rich events to work with
• example Statements have mistakes, so be cautious using them
http://www.laceproject.eu/blog/xapi-dsla/

6. SCHEMA.ORG COURSE EXTENSION
• entity based
• very very close to final
• carefully considered around course discovery use cases
• aligns well with other Schema.org metadata
• in particular, plays nicely with LRMI-derived alignment
• best practice RDF
https://www.w3.org/community/schema-course-extend/

7. JSON-LD
THE STONE

8. —HERE, HAVE AN OPEN BADGE—
WHAT DOES IT LOOK LIKE?
{
"@context": "https://w3id.org/openbadges/v1",
"type": "Assertion",
"id": "https://example.org/beths-robotics-badge.json",
"uid": "f2c20",
"recipient": {
"type": "email",
"hashed": true,
"salt": "deadsea",
"identity": "sha256$c7ef86405ba71b85acd8e2e95166c4b111448089f2e1599f42fe1bba46e865c5"
},
"image": "https://example.org/beths-robot-badge.png",
"evidence": "https://example.org/beths-robot-work.html",
"issuedOn": 1359217910,
"expires": 1609458300,
"badge": "https://example.org/robotics-badge.json",
"verify": {
"type": "hosted",
"url": "https://example.org/beths-robotics-badge.json"
}
}

9. WANT TO THINK OF IT AS JSON?
GO AHEAD.
WANT TO THINK OF IT AS RDF?
GO AHEAD.

10. EITHER WAY, THINK OF IT AS…
• standard sets of metadata about entities that can be reused,
remixed, and combined—safely.
• a connector between URIs—universal things—and from URIs to
text and numbers and more.
• (don’t worry, if a universal thing doesn’t have a good URI, you
can still talk about it using a “blank” URI).
• facilitating design by experts for use by non-experts.

11. BUT WE DON’T NEED TO BE
WE’RE NOT ALL JSON-LD EXPERTS
• focus on: what entities there should be, how they should be
connected together, and what metadata they need to have.
• it isn’t far from there to JSON-LD, and the last steps can be left to
the experts, mostly.
• one difficult thing that will mostly be left for later is, figuring out
where to reuse or inherit from existing predicates, and where to
make truly new predicates.

12. EXPERIENCE API
STATEMENTS
THE KETTLE

13. PLACES FOR JSON-LD IN XAPI
• outside of statements, describing relationships between entities in statements
(verbs, activity types, extension usage types, etc). See the xAPI Vocabulary Primer.
• inside statements, in extensions!
• context extensions are about the statement itself (some specialized tracking
metadata, perhaps)
• activity extensions are about the activity (detailed course/course instance
metadata?)
• result extensions are… probably about a result blank node connected to the
statement, but maybe about the statement itself
• not settled, luckily doesn’t matter much for design of the extensions themselves

14. BREAKING GROUND
USING JSON-LD IN EXTENSIONS
• what is clear:
• if an object, the entire extension value should be standalone JSON-LD.
• if a primitive, the extension key should be treated as the predicate URI and the value should be
handled as a JSON-LD literal value.
• if an array, lift the above rules into the values (and don’t mix).
• what is not clear:
• how to incorporate JSON-LD into a Statement RDF model.
• should the extension key be a predicate to an object? MOST LIKELY OPTION
• (this would follow the practice adopted in Mozilla Open Badges)
• should the extension key be a (duplicate) @context and the values attach to the xAPI entity?
• something else?

15. OR, TASK SPLITTING THAT MIGHT WORK
POTENTIAL AREAS OF FOCUS
• what are the relationships among verbs for that could be useful
from a learning analytics perspective? good starting framing: what
would you sometimes like to roll up together?
• what entities and sets of metadata about them are useful to include
in xAPI Statements around what events? good starting framing: for
each event we pick, what metadata that might change do we really
really want the history of the values?
• what event-attached, rather than entity-attached, metadata is useful
to include around what events? good starting framing: what
additional entities contextualize events beyond the objects at the
time of happening? what metrics do we (wish we could) calculate?

16. HAVE FUN :)