Re: BA and Credentials/Badging Vocabulary

I want to share with this group some of the work that Nate Otto and the
Standards community have been undertaking so far, as further reference:

   - http://etherpad.badgealliance.org/ba-standard-defininitions We have
   been working on the definitions for Open Badges that will eventually form a
   context document
   - Slide deck that goes into a bit more detail on the code on our
   thinking of Open Badges with JSON-LD drafted by Nate Otto:
   http://prezi.com/i50_fyhtstrk/json-ld-prototype/

   - slide deck Nate put together to illustrate some ideas about the
   different options available to open badges as far as extensions go:
   https://docs.google.com/presentation/d/1dNvp9fab4IkTNr0k68JruYmPCA0F2Cbj4LFeflt1yFc/edit?usp=sharing
      - n.b. There are two different approaches (at least) to implementing
      extensions.

How do you advise we surface this work during TPAC?

Sunny


On Mon, Oct 20, 2014 at 11:17 AM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 20 October 2014 16:39, Manu Sporny <msporny@digitalbazaar.com> wrote:
>
>> There is an draft Agenda item for the Credentials CG at the upcoming W3C
>> TPAC meeting titled "Credentials Vocabulary (led by Badge Alliance?)".
>> There is also one for "Merge technical work - Open Badges and Identity
>> Credentials".
>>
>> The general idea here is to try and work toward the Badge Alliance's
>> specs where it makes sense to do so. BA has been busy exploring if they
>> can move toward JSON-LD[1], and it became clear to the folks at Digital
>> Bazaar and Accreditrust that it wouldn't be productive to create yet
>> another vocabulary that does more-or-less what the BA specs do wrt. the
>> data that goes into a badge.
>>
>> Namely, the Assertion specification lays out the vocabulary necessary to
>> do basic badging in the "Structures" section:
>>
>>
>> https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md#structures
>>
>
> Sounds good, if the data reaches a certain quality I could reuse this work.
>
> One example:
>
> "identity": "sha256$c7ef86405ba71b85acd8e2e95166c4b111448089f2e1599f42fe1bba46e865c5"
>
> It would be be more portable to use a URI here such as ni:///sha-256;
>
>
>
>
>>
>> We could convert the structures to a Linked Data vocabulary and a
>> JSON-LD Context. For example, the human-readable vocabulary could be
>> expressed like so (note the embedded RDFa in the page that is
>> machine-readable):
>>
>> https://w3id.org/commerce
>>
>> The document could also be content-negotiated to other formats by
>> machines to get something more machine-readable, like so:
>>
>> https://web-payments.org/vocabs/commerce.ttl
>>
>> The vocabulary could then be used in a JSON-LD context file, like so:
>>
>> https://w3id.org/openbadges/v1
>>
>> The general proposal is that the Credentials CG could create a first cut
>> of these documents and then hand them over to the BA for further
>> development, refinement, addition, etc. Or, the documents could be
>> placed into the Credentials CG and pushed toward "official standard"
>> status at W3C with BA being the primary maintainer/author of the
>> documents.
>>
>> Doing this would be a first solid step toward merging the work that the
>> BA is doing and the work that has been done in the Web Payments CG and
>> Credentials CG. Creating a shared vocabulary will enable both
>> communities to at least use a common language when describing
>> badges/credentials. Using JSON-LD would be a step toward using a common
>> syntax, and ensure that even if we just stop there, that the two
>> ecosystems would be largely interoperable (with the only big differences
>> being with how badges/credentials are digitally signed).
>>
>> -- manu
>>
>> [1]
>>
>> http://prezi.com/i50_fyhtstrk/json-ld-prototype/?utm_campaign=share&utm_medium=copy
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: High-Stakes Credentials and Web Login
>> http://manu.sporny.org/2014/identity-credentials/
>>
>>
>