Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

JSON-LD Prototype

Late september sketches of how JSON-LD lets us add context to badges. And how we might add extensions like endorsement and do some more advanced validation so that we know extensions have been added the right way.
by

Nate Otto

on 28 September 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of JSON-LD Prototype

{

"@context": "https://openbadges.org/1.1/context"
"uid": "f2c20",
"recipient": {
"type": "email",
"hashed": true,
"salt": "deadsea",
"identity": "sha256$c7ef86405ba71b85acd8e2e95166c4b111448089f2e1599f42fe1bba46e865c5"
}, . . .

Nate Otto, 27 Sept 2014
JSON-LD Prototype
{
"
@context
": {
"uid
": {"@id": "https://openbadges.org/1.1/standard#uid", "@type": "@id"},
. . .

"validation": {
"schema": "https://openbadges.org/1.1/schema"
}
}
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "Open Badges Assertion",
"description": "A document that describes an Open Badge instance, as issued to one earner",
"type": "object",
"id": "http://openbadges.org/1.1/schema/assertion",
"definitions": { . . .
{
"@context": {
"uid": {
"@id": "https://openbadges.org/1.1/standard#uid", "@type": "@id"
},
"recipient": {"@id": "https://openbadges.org/1.1/standard#recipient", "@type": "@id"},
"issuedOn": {"@id": "https://openbadges.org/1.1/standard#issueDate", "@type": "@id"},
"expires": {"@id": "https://openbadges.org/1.1/standard#expirationDate", "@type": "@id"},
"evidence": {"@id": "https://openbadges.org/1.1/standard#evidence", "@type": "@id"} . . .
Badge Objects contain a
@context
property that maps property names to the definitions of those properties.
Add Context to a
Badge Assertion

These IRIs (usually equivalent to URIs) correspond to where definitions of each term are available.
The context maps shorthand property names to IRIs
We can define new properties a similar way, by adding
context
for them. For an extension object:
What if we want to add additional properties?
JSON-schema is a way to describe the structure of documents in JSON, constraining what values their properties may take.
Maybe we add validation information to our contexts
This means the assertion's property
"uid"
is defined at
"https://openbadges.org/1.1/standard#uid"
and the value of that property in the assertion is of the type described there.
{

"@context": [
"https://openbadges.org/1.1/context",

{"newextension: "https://example.org/new-ext-info" }
],

"newextension": {
"@context": "http://example.org/new-ext-context"
"newProperty":"special value",
"otherProperty": 1239
},
"uid": "f2c20", . . .

There are some advantages to extending with an object, but maybe we could define a similar way, by adding
context
for them. I don't like this as much...
What about an extension
of just one property?
{

"@context": [
"https://openbadges.org/1.1/context",

{"newProperty: { "@id":"https://example.org/new-
property-definition", "@type": "@id" }
],
"newProperty":"special value",
"uid": "f2c20", . . .

This linked context doc defines "newProperty" and "otherProperty"
With extensions, many issuers can add the same type of new information to badges, and declare that they're doing this cooperatively by linking to the same
context
.
But how do we know they are using those new properties in the same way?
Or for an extension...
{
"
@context
": {
"newProperty
": {"@id": "http://example.org/newProp-definition", "@type": "@id"},
"otherProperty": {"@id": "http://schema.org/Number", "@type": "@id"},
. . .

"validation": {"schema": "https://example.org/new-ext-schema" }
}
}
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "New Extension",
"description": "A set of new properties to add to an Open Badge",
"type": "object",
"properties": {

"newProperty": { "type": "string" },
"otherProperty": { "type": "integer", "minimum": 42 }
}
}
These definitions and constraints would apply only within the extension object.
And you could see
if the issuer extended the badge correctly
by validating the extension part of the badge against the schema
{

"@context": [
"https://openbadges.org/1.1/context",

{"newextension: "https://example.org/new-ext-info" }
],

"newextension": {
"@context": "http://example.org/new-ext-context"
"newProperty":"special value",
"otherProperty": 12
},
"uid": "f2c20", . . .

Then we could see if a
property wasn't used right
Error: "otherProperty is outside the acceptable range, according to newextension's validation schema:
"otherProperty": { "type": "integer", "minimum": 42 }
When we know what to expect
in a badge, we can make more
educated decisions based on
what we might find...
And when issuers tell consumers what to expect in their badges, those badges become more usable.
We can start adding extra information to
grow our badges' value...

Endorsements
Location
Embedded evidence. . .
We can do some really cool stuff.
Full transcript