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

Thanks, Rob -- This is indeed quite helpful. It's good to see
well-developed examples in different contexts.

My first revised thoughts were to set and use an @id of the extension as
the hook for validation. But it strikes me after looking at your link to
external services that this is the wrong way to use @id. (Maybe instead a
type array would be more appropriate):

*Extension as it appears in a badge object:*
{
  "extension:someExtension": {
    "@context": "http://extension.org/context/extension1"
    "@type": [ "extension", "*http://extension.org/defs/extension1
<http://extension.org/defs/extension1>*" ],
    "newProperty": "some value"
}

*Extension context with validation info:*
{
  "@context": {
    "obi": "http://openbadges.org/definitions#",
    "newProperty": "http://extension.org/defs/newProperty"
  },
  "obi:validation": [
    {
      "obi:validatesType": "*http://extension.org/defs/extension1
<http://extension.org/defs/extension1>*",
      "obi:validationSchema": "http://extension.org/schema/extension1"
    }
  ]
}


*Some notes and questions:*

* You mentioned you use one property name to contain all external services
http://iiif.io/api/annex/services/ (it looks like "service"). If a single
object has multiple extensions, does that service value become an array? I
wasn't thinking we would require implementers to use any particular
property name for extensions, but it certainly is one option, with the
drawback you mentioned of not quickly being able to access the one
extension you're interested in.

* I think an alternate method would be using compact IRIs for extensions
(with the option of creating a custom IRI). If we set a prefix in the main
OBI context:
"ext": "http://openbadges.org/extensions#"
then we could just say extensions must live in properties either mapped to
an IRI by another method or a compact IRI within the "extension" prefix,
like "extension:badgeListUrl"

* On @context getting squashed on expansion, I imagine some consumers may
need to inspect the original JSON before expansion for other reasons, but
grabbing a link to the context would be one reason to do so.

* On "@id", we're not imagining issuers would publish the actual extension
objects independent of the badge objects they extend. So I don't think
there would be an appropriate IRI to use in an "@id" property within an
extension. Am I right above in thinking that using an @id here, say to
identify the extension spec being used, would be a misuse of @id?

* You used prefixes for properties in the oa context
http://www.w3.org/ns/oa.jsonld -- Did I do it right above? I imagine in
many cases people would not be looking at JSON-LD expanded versions of
these context objects, but would rather be looking at them as basic JSON.
It doesn't seem like it would make much difference whether or not these
properties had an IRI mapping, but no harm in creating it anyway!
So, pardon another long message, but here are 4 files that incorporate your
feedback and try out another approach:

* You used a "validators" array, maybe indicating web services that would
validate this particular extension, though I may be misinterpreting you. We
weren't planning to go that far, aiming mostly on making a JSON-schema
available if validation via schema was desired.



So pardon another long message to the list, but for those who are
interested, here are four new prototypes that flesh out a revised version
of this connection to validation. I'd love it if some of you would take a
look:

* A sample extended badge object (in this case an Issuer definition):
https://gist.github.com/ottonomy/b8ddcae109078f631bf5
* Core JSON-LD context file for the Open Badges standard:
https://gist.github.com/ottonomy/c293b451dfe18e6d20b6
* A sample extension context file matching the extension referenced in the
Issuer definition: https://gist.github.com/ottonomy/6a07131dd2e2d48897b8
* A sample JSON-schema referenced in the extension context:
https://gist.github.com/ottonomy/074f1db3379c5da56a99


Thanks for your feedback, Rob. Anyone else who has thoughts, please feel
free to jump in. We'd like to use this update to the Open Badges standard
to build a good foundation for the future (and not make any silly
mistakes). :)

*Nate Otto, Developer*
concentricsky.com

On Fri, Oct 31, 2014 at 8:42 AM, Robert Sanderson <azaroth42@gmail.com>
wrote:

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