JSON-LD Prototype

But how do we know they are using those new properties in the same way?

Maybe we add validation information to our contexts

Then we could see if a

property wasn't used right

JSON-schema is a way to describe the structure of documents in JSON, constraining what values their properties may take.

{

"@context": {

"uid": {"@id": "https://openbadges.org/1.1/standard#uid", "@type": "@id"},

. . .

"validation": {

"schema": "https://openbadges.org/1.1/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", . . .

{

"$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": { . . .

When we know what to expect

in a badge, we can make more

educated decisions based on

what we might find...

Error: "otherProperty is outside the acceptable range, according to newextension's validation schema:

"otherProperty": { "type": "integer", "minimum": 42 }

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

}

}

And when issuers tell consumers what to expect in their badges, those badges become more usable.

{

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

}

}

We can start adding extra information to

grow our badges' value...

• Endorsements
• Location
• Embedded evidence. . .

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

The context maps shorthand property names to IRIs

We can do some really cool stuff.

These IRIs (usually equivalent to URIs) correspond to where definitions of each term are available.

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.

{

"@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"} . . .

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.

What if we want to add additional properties?

We can define new properties a similar way, by adding context for them. For an extension object:

Add Context to a

Badge Assertion

{

"@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", . . .

What about an extension

of just one property?

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...

{

"@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"

Badge Objects contain a @context property that maps property names to the definitions of those properties.

{

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

"uid": "f2c20",

"recipient": {

"type": "email",

"hashed": true,

"salt": "deadsea",

"identity": "sha256$c7ef86405ba71b85acd8e2e95166c4b111448089f2e1599f42fe1bba46e865c5"

}, . . .

JSON-LD Prototype

Nate Otto, 27 Sept 2014