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

On 31 October 2014 00:58, Nate Otto <nate@ottonomy.net> wrote:

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

I am working on a community system where users receive a sort of 'karma'
(what we call marks) over time.  I am interested in reusing this work to
create the idea of discrete badges such that users can 'level up' after
achieving certain goals, and have a permanent badge on the web to point to
the achievement.  Am I along the right lines of what open badges might hope
to achieve?

I have looked at the presentation and it looks good, I would be interested
to see the @context document when it's complete, or near to complete.

I think most of the terms you use are appropriate for my use case, tho we
like to use URIs to name entities for the sake of scaling, so would
probably make a few tweaks, if that's OK ...


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