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

IMO Just yet another reason why building around JSON-LD will allow us to
more easily integrate various other *social web* technologies!


-------- Forwarded Message --------
Subject:  We're adapting Open Badges to JSON-LD
Resent-Date:  Thu, 30 Oct 2014 23:58:40 +0000
Resent-From:  public-linked-json@w3.org
Date:  Thu, 30 Oct 2014 23:58:11 +0000
From:  Nate Otto <nate@ottonomy.net>
To:  public-linked-json@w3.org


Hi,

I'm working with a team representing the Badge Alliance
(http://badgealliance.org) 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:
https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md

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:
https://docs.google.com/presentation/d/1dWMU2gdnfjBPRJTCcCDOJrs0xSgCwNc-IOUdjq9gRmw/edit?usp=sharing


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": "http://extension.org/ext1context"
    "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": {
  "newProperty": { "@id": "http://iri.org/def", "@type": "@id" },
},
"http://openbadges.org/definitions/schemaValidation":
"http://extension.org/ext1schema"
 }

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*
concentricsky.com <http://concentricsky.com>
(and member of the Badge Alliance Standard Working Group)

Received on Friday, 31 October 2014 07:02:05 UTC