VOCABULARY STONE SOUP

RUSSELL DUHON@FUGU13

CTO, SALTBOX

OTHER THAN STONE

INGREDIENTS,

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-vlehttps://github.com/jiscdev/analytics-udd

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

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/

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/

JSON-LDTHE STONE

—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" }}

WANT TO THINK OF IT AS JSON?

GO AHEAD.

WANT TO THINK OF IT AS RDF?

GO AHEAD.

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.

BUT WE DON’T NEED TO BEWE’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.

EXPERIENCE API STATEMENTS

THE KETTLE

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

BREAKING GROUNDUSING 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?

OR, TASK SPLITTING THAT MIGHT WORKPOTENTIAL 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?

HAVE FUN :)