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": "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
(and member of the Badge Alliance Standard Working Group)

On Thu Oct 30 2014 at 4:47:20 PM Nate Otto <nate@ottonomy.net> wrote:

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