Re: We're adapting Open Badges to JSON-LD

Pardon the incomplete message. Apparently it's quite easy to send an
incomplete message if you hit "tab, enter" in Google Inbox.

Continuing from where I left off,

I was thinking something like this for the extension's context document:

{ "@context": {
  "newProperty": { "@id": "", "@type": "@id" },
"": ""

Is putting extra properties outside of the "@context" object in a linked
context document okay? I've never seen an example of that, but it doesn't
seem like it would fit inside the @context object either, because we're not
trying to create a new term-IRI mapping.

A second question:
Back in the extended badge, if an issuer adds an extension object with a
scoped @context inside, that internal context won't map the property that
actually contains the extension, so it will be a blank node. You can see on
slide 15 of the presentation I linked that I was playing around with a few
ideas to answer these questions. Declaring a mapping for the extension
property itself in the badge object's main context array, and declaring a
schema based on the IRI or type that it validates rather than assuming that
there would just be one schema validator per extension.

Thanks anyone for taking a look. I appreciate your time and all the many
years of discussion that has brought JSON-LD to this point.

*Nate Otto, Developer*
(and member of the Badge Alliance Standard Working Group)

On Thu Oct 30 2014 at 4:47:20 PM Nate Otto <> wrote:

> Hi,
> I'm working with a team representing the Badge Alliance (
> to update the Open Badges metadata
> specification to become JSON-LD. We have been collaborating with the W3C's
> Credentials Community Group since its formation and have been producing
> various JSON-LD prototypes since July.
> While most digital badges from gaming and social platforms like Foursquare
> are locked into the system that created them, Open Badges are portable
> because follow a standard data spec for attaching information about
> accomplishments to an image file. Earners can then take that image file
> wherever they want to display their accomplishments, and consumers can read
> the badge metadata embedded within it to learn in detail what the badge
> meant and verify its authenticity. Open Badges use JSON "baked" into PNG or
> SVG files and duplicated on issuer's servers for verification. Each badge
> is composed of an Assertion (which applies to one earner), a Badge Class
> (which describes the accomplishment and may be awarded to many earners) and
> an Issuer definition (which describes the person or organization awarding
> the badge). See the existing 1.0 specification here:
> We're pretty close to finalizing a proposal to add @context definitions to
> badges, but I hoped to get some feedback from people who have more
> experience working with JSON-LD.
> Here's a slide deck explaining the changes we hope to make:
> Particularly, I hope to get some feedback on our proposal for
> "extensions", which go beyond basic JSON-LD's ability to map new properties
> to IRIs that define them. We want to allow issuers to add new properties
> inside JSON objects { } that have their own @context property, scoped just
> to the new additions. One thing we wanted to make an optional addition to
> an extension like this would be the ability to specify a JSON-schema
> document that could define some acceptable data types, and regexes, and
> allow some degree of automated validation of whether two different issuers
> both implemented an extension to the satisfaction of the extension designer.
> So, extension designers may define a context document and a schema
> document, and many issuers may implement them in badges by adding a JSON
> object to a badge object like this:
>   "extension1": {
>     "@context": ""
>     "newProperty": "some value"
>   }
> Having a context document linked gives the extension designer a chance to
> link to the schema they'd like to use for validation, but I'm not
> experienced enough with JSON-LD to be sure of how I should connect context
> and schema without being sure to not cause problems.
> I was thinking something like this for the extension's context document:
> { "@context": {
> } }

Received on Thursday, 30 October 2014 23:58:39 UTC