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

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

>
> { "@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.
>

That's fine -- the information outside of the context will be ignored by
context processors.
We use this trick with the Open Annotation context to also include the
ontology definition:
  http://www.w3.org/ns/oa.jsonld

But see below...


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

We have this pattern in the IIIF context, and declare a generic property in
the main context to allow the extensions to all fit into one slot that can
be processed or easily ignored.  The documentation is here:
http://iiif.io/api/annex/services/

The advantage of the approach is that you don't have to extend the context
in the badge with the additional top level properties, everything just
lives in the same place.  The disadvantage is that if you have a lot of
extensions, it's harder to find the one that you're after.  Also note the
issue with compaction/expansion of contexts below the root node (they'll
disappear, and you'll be left with just the URIs in the JSON)

The issue with only one validator I think comes from the way you're
recording the schema, if I understand correctly.
In the slide deck, you have the badgeListUrl definition as the key in the
json object which is in turn the value of schemaValidation.
You could instead do something like:

{
  "validators": [
    {
       "extension": "http://extension.org/defs/badgeListUrl",
       "schema": "http://extension.org/schema/badgeListUrl",
       "validator": [
           "http://my.validator.net/badgeListUrl",
           "http://your.validator.net/badgeListUrl"
       ]
   }
}

HTH,

Rob


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305