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

Thanks for the reply, Melvin

Glad you think this presentation looks good. I linked to a draft context in
my previous email ( https://gist.github.com/ottonomy/c293b451dfe18e6d20b6
), but it isn't complete, as the IRIs don't yet map to any real definition.
Those will be created in the next couple weeks, and I'll share again when
we make this version of the Open Badges standard official.

It sounds like your karma idea is very close to what Open Badges already
make possible. Many digital badge systems allow the creation of
achievements and connecting them to profiles within one application. Open
Badges make those achievements portable. Issuers embed metadata following
the Open Badges standard inside a PNG or SVG image, and deliver that image
file to the achievement earner (also hosting a verification copy of the
data at an address specified in the badge "assertion"). Then earners can
take that image anywhere, and software that knows how to extract Open
Badges metadata, validate, and analyze it can see what achievement it
recognizes. Earners can combine achievements from many issuers into one
portfolio, as long as all of those issuers follow the metadata
specification.

In your case, you would probably keep internal records of each user's
current karma and issue them badged achievements whenever they met certain
thresholds, as permanent records of their accomplishment. If you choose to
use Open Badges, accomplishments from your system will be able to be
understood by the growing number of other systems being built to understand
Open Badges, and your users will be able to store them in Open Badge
repositories like the Mozilla "Backpack."

There are already a couple thousand issuers creating Open Badges, and we
hope the new version of the specification that brings it in-line with
JSON-LD will enable the badges that are already out in the wild to be more
useful. I'm not quite sure what you mean by "we like to use URIs to name
entities", because the idea of adapting the existing standard to JSON-LD is
to map the standardized terms to IRIs. It may take one more version, but we
can eventually have an "@id" for each independently hosted Badge Object.

If you think the Open Badges spec doesn't quite serve your needs and want
to put a little more information into your credentials, consider starting
from this foundation. The "extensions" method we are proposing with 1.1
allows multiple issuers to add information in the same fashion as one
another so it can be easily understood by consumers, but if you want to add
other properties that aren't intended to be externally useful, the Open
Badges specification allows that as well.

Cheers!

*Nate Otto, Developer*
concentricsky.com

On Wed Nov 05 2014 at 1:38:10 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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