We're adapting Open Badges to JSON-LD

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

} }