Suggestion to Experiment with Extending the BadgeClass

[kayaelle]

I'd like to propose a suggestion on extending the BadgeClass to allow for additional data. Here's an example of how to do this:

{
  "name": "Awesome Robotics Badge",
  "description": "For doing awesome things with robots that people think is pretty great.",
  "image": "https://example.org/robotics-badge.png",
  "criteria": "https://example.org/robotics-badge.html",
  "tags": ["robots","awesome"],
  "issuer": "https://example.org/organization.json",
  "alignment": [
    {
      "name": "CCSS.ELA-Literacy.RST.11-12.3",
      "url": "http://www.corestandards.org/ELA-Literacy/RST/11-12/3",
      "description": "Follow precisely a complex multistep procedure when carrying out experiments, taking measurements, or performing technical tasks; analyze the specific results based on explanations in the text."
    },
    {
      "name": "CCSS.ELA-Literacy.RST.11-12.9",
      "url": "http://www.corestandards.org/ELA-Literacy/RST/11-12/9",
      "description": " Synthesize information from a range of sources (e.g., texts, experiments, simulations) into a coherent understanding of a process, phenomenon, or concept, resolving conflicting information when possible."
    }
  ],
  "badgeClassExtensions": [
    {
      "badgeSpecification": {
        "reference": "http://url-to-spec",
        "version": "0.5"
      },
      "age": "K-12",
      "categories": ["Education","Technology"],
      "location": {
        "url": "http://online-course",
        "streetAddress": "123 test rd",
        "city": "providence",
        "stateProvince": "RI",
        "zipPostal": "02903"
      }
    },
    {
      "badgeSpecification": {
        "reference": "http://url-to-spec2",
        "version": "0.7"
      },
      "cost": "50.00"
    }
  ]
}

The badgeClassExtensions property could allow for a single or multiple specs to be referenced. The specs properties would only be an extension of the defined BadgeClass in the Assertion spec which would continue to be the common properties that all badges continue to use.

Ideally the community would adopt specs based on their industry in which they can define their needed properties and decision making process. Can envision some specs being more formal than others. Backpacks could decide which specs they use.

The above example doesn't have true spec properties included nor does it explain how the spec reference would be provided programatically (vs just a url with text explaining the property definitions). It's an example of how the BadgeClass could be extended to allow for more data, flexibility while maintaining a standard for all open badges.

Not suggesting at this point that the Assertion spec be changed to allow this just yet. Thinking that after some discussion here, broadening the discussion to the overall community, thinking through guidelines spec definitions and then creating a spec leaning with feedback from the learning community. Then test the waters to see if there's adoption, iterate on the spec and continue discussion on the data that can connect open badges.

Thoughts?

[threeqube]

@kayaelle I'd also recommend posting this in the dev channel inviting conversation.

[andrewhayward]

@kayaelle - I had similar thoughts when thinking about v3 of the OpenBadger API in #3.

:+1:

[kayaelle]

Will do @threeqube. @andrewhayward :metal:

[threeqube]

:+1:

[xmatthewx]

:+1: :+1:

[mihi-tr]

I do agree: Extensibility is a good idea. Since your example contains links to badge specifications - these would define the extensions? (This sure starts to look a bit like JSON-LD)

[kayaelle]

@mihi-tr exactly. Thanks for mentioning JSON-LD. This is my first look at it.

[cmcavoy]

I like the idea @kayaelle I think we should play around with it and get some more examples circulating. For sure am on board with some form of extension.

[jgoodell2]

Re-posted from Google group...

(Kerri, Thank you for raising this important and timely topic. "Additional data could allow for the community to be able to connect our badges and provide more information on the opportunities that the badges represent." )

The alignment property can be used to handle some of the kinds of extensions proposed, e.g. "age". In the example it looks like "age" is the age range for which the badge is intended rather than the age of the person at the time they are awarded the badge, but either one could be handled with "alignment" to an external vocabulary. LRMI and the Learning Registry use educationalAlignment in this way, not only for alignment to a learning standard, but also for alignment to things not specified in LRMI like "grade level". (LRMI has additional properties in its alignment object, see http://www.lrmi.net/the-specification/alignment-object)

The Common Education Data Standards (ceds.ed.gov) has the common data vocabulary to support this kind of extension using the existing alignment property in the BadgeClass. CEDS version 4, set to be released next week includes definitions for elements that define age ranges (minimum and maximum) and grade levels intended for learning activities/resources. The web site provides unique machine readable URIs and human-readable definitions for data elements and option sets (when applicable) so both the value and the contextual meaning is defined.

See this post in the LRMI group as an example for tagging grade level(s) with CEDS defined terms: https://groups.google.com/forum/#!topic/lrmi/WSLyufKGMtI

CEDS has elements and option sets defined related to a learner's achievement that are already aligned with the OpenBadges spec, and others like "Grade Level When Assessed" that might be applicable in some cases. The standards have many other data elements that may be useful to standardize metadata extensions for badges.

FInally, the standards are a community driven process so the badges community could suggest additional elements/options for adoption in future versions of CEDS.

[kayaelle]

@jgoodell2 CEDS is a great example of existing data references that can be used to extend the BadgeClass. Can you elaborate more on your suggestion that the alignment property could be used to to handle the extension? Maybe provide an example of what that might look like?

[jgoodell2]

Kayaelle;

Someone else may be able to give better examples based on better understanding of the badges spec, but here is my attempt to add some aligned properties based on your extension example. It looks like you want to include information about a virtual course/activity by which the robotics badge is earned. CEDS has elements for "Course Applicable Education Level" and a "Virtual Indicator". I included examples for each.

I don't know if the mechanics of badging systems would allow the system to look up the definition of the terms or if the CEDS definition should be included in the definition property (as in my 12th grade and Virtual Indicator examples). I think this works without the CEDS element definitions, i.e. the important thing is that organizations use a common vocabulary for comparability, each option value as a unique URIs. However, the Learning Registry group has begun a discussion about prototyping and encouraging important reference points, like CEDS, to return machine readable URIs(JSON?) with the detailed element-context+term definitions for look-up.

f.y.i. LRMI and the Learning Registry include additional properties in their specification of alignment object:

alignmentType: e.g. "EducationLevel" (see other types at https://ceds.ed.gov/CEDSElementDetails.aspx?TermxTopicId=21320 ) educationalFramework: e.g. "Common Education Data Standards v4"

Here goes:

{ "name": "Awesome Robotics Badge", "description": "For doing awesome things with robots that people think is pretty great.", "image": "https://example.org/robotics-badge.png", "criteria": "https://example.org/robotics-badge.html", "tags": ["robots","awesome"], "issuer": "https://example.org/organization.json", "alignment": [ { "name": "CCSS.ELA-Literacy.RST.11-12.3", "url": "http://www.corestandards.org/ELA-Literacy/RST/11-12/3", "description": "Follow precisely a complex multistep procedure when carrying out experiments, taking measurements, or performing technical tasks; analyze the specific results based on explanations in the text." }, { "name": "CCSS.ELA-Literacy.RST.11-12.9", "url": "http://www.corestandards.org/ELA-Literacy/RST/11-12/9", "description": " Synthesize information from a range of sources (e.g., texts, experiments, simulations) into a coherent understanding of a process, phenomenon, or concept, resolving conflicting information when possible." } { "name": "Eleventh grade", "url": "https://ceds.ed.gov/CEDSElementDetails.aspx?TermId=6267#11", "description": "Eleventh grade" }, { "name": "Twelfth grade", "url": "https://ceds.ed.gov/CEDSElementDetails.aspx?TermId=6267#12", "description": "The education level, grade level or primary instructional level at which a course is intended." } { "name": "Virtual indicator", "url": "https://ceds.ed.gov/CEDSElementDetails.aspx?TermId=6167#Yes", "description": "Indicates a school, institution, program, or class/section focuses primarily on instruction in which students and teachers are separated by time and/or location and interact through the use of computers and/or telecommunications technologies." } ] }

[kayaelle]

Hi @jgoodell2 - thanks for laying it out. I get what you mean.

The alignment could be a good place to reference specs generally but it is a very generic property that although intended to reference Educational Standards could also be used for any url reference. This makes it difficult for the backpack and badge displayers to recognize what the intention of the url is. Also, even if CEDS is referenced, we'll still need a way to add the data for the fields that are being referenced. I'd like to think that once we can land on a way to implement the extension that using those standards for badges that recognize learning is a great place to start.

Issue #4 contains a discussion about add LRMI data to the criteria. I also think this is a good idea. I've been thinking about it as supplemental data and not necessarily an extension of the badge data. This is because (I'm assuming here), that it is more work for backpack and displayer code to have to parse criteria urls or every badge. But it could be done. One way to make it more efficient would be do change the criteria property to be an array that references a standard. Something like:

"criteria": {"reference": "https://ceds.ed.gov/CEDSElementDetails.aspx?TermId=6267#11", "https://example.org/robotics-badge.html"}

In this way, when parsing the criteria page, you know what data you are looking for because there's a reference to a standard. This may be worth exploring as part of this discussion.

[iamjessklein]

:+1:

[cmcavoy]

I finally found some words to describe some bits that were haunting me in this thread, from the JSON specification site,

JSON is not extensible because it does not need to be. JSON is not a document markup language, so it is not necessary to define new tags or attributes to represent data in it.

Later in the same doc,

XML’s one-of-a-kind open structure allows you to add other state-of-the-art elements when needed. This means that you can always adapt your system to embrace industry-specific vocabulary.

Not ready to have a strong opinion, but if you take those quotes at face value, a lot of the discussion here reads like limitations of JSON rather than limitations of the OpenBadges specification. A point to ponder: do we actually need to make a more extensible version of the badge-spec in XML? And keep the JSON version light?

[kayaelle]

Heya @cmcavoy - Can you explain more about what you mean by keeping the JSON version light and a more extensible version of the badge-spec in XML?

[mihi-tr]

As said - this starts to read quite a bit like LinkedData/RDF @kayaelle @cmcavoy it might be worth toying with badge specs as RDF for more complex systems.

[kayaelle]

@mihi-tr Can you join us on the tech panel call tomorrow for a discussion? https://v.mozilla.com/flex.html?roomdirect.html&key=6XNQmYDkgJAN

[mihi-tr]

@kayaelle possibly, when is it?

[kayaelle]

Sorry about that - 2pm ET. The etherpad for the call is: https://openbadges.etherpad.mozilla.org/TechPanelFeb19

[mihi-tr]

@kayaelle will try to be there.

[cmcavoy]

Mr. @andrewhayward pointed out JSON-schema yesterday. Seems like a good compromise, adding a bunch of the features I thought were only available in XML to JSON. Worth investigating for sure.

[ottonomy]

Kerri,

Thanks for your proposal and the presentation yesterday. I think this has some very interesting possibilities.

Also, I think we should consider how we might want to eventually handle endorsement (of a badgeClass) and whether it would be possible to kill two (or three) birds with one stone. Is there a way to use this to ensure that an issuing platform (like Achievery) has the authority to issue specific badges on behalf of an organization?` (Issue #10)

I think both external platform authorization and signed endorsements could live in a format pretty close to this. In a rush and I don't know that much about signing, but imagine:

"badgeSpecification": {
        "reference": "http://openbadges.org/class-endorsement-spec.json",
        "version": "0.1"
      },
      "key": "http://biguniversity.edu/public-key.key",
      "signature": {
      "alg": "sha256", 
      "payload": "http://this-badge-class.com/json",
      "jws": "eyJhbGciOiJSUzI1NiJ9.eyJ1aWQiOiJhYmMtMTIzNCIsInJlY2lwaWVudCI6eyJ0eXBlIjoiZW1haWwiLCJoYXNoZWQiOnRydWUsInNhbHQiOiJkZWFkc2VhIiwiaWQiOiJzaGEyNTYkYzdlZjg2NDA1YmE3MWI4NWFjZDhlMmU5NTE2NmM0YjExMTQ0ODA4OWYyZTE1OTlmNDJmZTFiYmE0NmU4NjVjNSJ9LCJpbWFnZSI6Imh0dHBzOi8vZXhhbXBsZS5vcmcvYmV0aHMtcm9ib3QtYmFkZ2UucG5nIiwiZXZpZGVuY2UiOiJodHRwczovL2V4YW1wbGUub3JnL2JldGhzLXJvYm90LXdvcmsuaHRtbCIsImlzc3VlZE9uIjoxMzU5MjE3OTEwLCJiYWRnZSI6Imh0dHBzOi8vZXhhbXBsZS5vcmcvcm9ib3RpY3MtYmFkZ2UuanNvbiIsInZlcmlmeSI6eyJ0eXBlIjoic2lnbmVkIiwidXJsIjoiaHR0cHM6Ly9leGFtcGxlLm9yZy9wdWJsaWNLZXkucGVtIn19.Liv4CLviFH20_6RciUWf-jrUvMAecxT4KZ_gLHAeT_chrsCvBEE1uwgtwiarIs9acFfMi0FJzrGye6mhdHf3Kjv_6P7BsG3RPkYgK6-5i9uZv4QAIlvfNclWAoWUt4j0_Kip2ftzzWwc5old01nJRtudZHxo5eGosSPlztGRE9G_g_cTj32tz3fG92E2azPmbt7026G91rq80Mi-9c4bZm2EgrcwNBjO0p1mbKYXLIAAkOMuJZ_8S4Go8S0Sg3xC6ZCn03zWuXCP6bdY_jJx2BpmvqC3H55xWIU8p5c9RxI8YifPMmJq8ZQhjld0pl-L8kHolJx7KGfTjQSegANUPg"
      }
    }

[timothyfcook]

Moving to archive. Extensions are real!