A no-code repository for having discussions related to the general technical issues of openbadges.
We are reviving this issues-only repository for having conversations about new ideas for Open Badges development. While actionable tasks related to work on the specification can continue to live on the Specification Repository, the issues section of this repo can be used for triaging and discussing all possible future work.
Join the conversation on the Issues page!
From @thisandagain:
As an aside, would now be a good time to think about extending the badge schema? Two items that arose during my experiment were those of geolocation and language specification. For example:
{
"name": "MOOC GdP : fondamentaux des projets",
"description": "A démontré sa connaissance du cours “fondamentaux de la gestion de projet” du MOOC GdP. Voir gestiondeprojet.pm ou http://goo.gl/Hu3GA",
"image": "https://badge.unow.fr/badges/badge_classique_S1.png",
"criteria": "https://badge.unow.fr/badges/criteria/22/1b605d6937b8e527cff67d9eb0bd649d",
"issuer": "https://badge.unow.fr/api/v1/organizations/1-unow-mooc-badges.json",
"alignment": [],
"tags": []
}In this instance it would be great to append something like:
{
"language": "fr-fr",
"location": [someLat, someLong]
}This would allow us to easily localize search, and also provide better recommendations for pathways based on user language and locale preferences.
/cc @christi3k
When you're issued a badge, a single identity, usually an email, is the only identity you're allowed to associate with a badge.
Extend the assertion specification to allow multiple identities per badge.
Presumably, an issuing organization will only know one identity for the earner of the badge. They'll issue to that identity, maybe signing the badge. The signature will be based on a badge issued to a specific identity.
If a second service adds another identity to the badge (say, a backpack), then the badge signature becomes invalid.
When a secondary organization adds another identity to the assertion, they add a second signature, and clearly mark the ways they altered the original assertion. Multiple additions could be added this way, with a moderately complicated process of peeling each layer away and re-validating the badge.
I think it would be really great if badges could be baked into HTML pages, or even if multiple badges could be baked into a single HTML page.
This could be done via a <link> tag in the document header, e.g.:
<link rel="openbadges-assertion" href="badge.json">Or, in the case of multiple badges per page, it could be done via a data-assertion attribute on an <img> or <div> element. Or something else.
This has a number of benefits:
<link> tag or some kind of data- attribute arguably requires less technical expertise and server-side storage than baking a PNG.Note that this proposal is distinct from a HTML Microformat for Open Badges, which prescribes a way to encapsulate all the information about a badge/class/issuer in HTML. The proposal described here merely prescribes a way to associate a web page with one or more JSON assertions.
An alternative to this proposal might be to somehow merge it with #1, so that the same specification could be used to advertise the badge classes an issuer provides and associate issued badges with a web page. But that might be trying to kill too many birds with one stone.
On multiple occasions it has been brought up whether a badge could be issued to an organization or non-human entity. Some examples are as follows:
The hack solution based on existing standard is to just issue the org or book a badge via an email but might be worthy of a deeper discussion to explore alternatives.
I'm not sure if this discussion repo is still alive. If not, can someone please point me to the right place?
Similar to the discussion around learning pathways I am wondering whether the 2.0 standard could support stackable badges using the evidence fields? Has anyone tried this?
The top stack criteria for earning a badge would include links to the criteria the contained badges. The evidence URL's would include the earner's badge links - i.e.
{
"@context": "https://w3id.org/openbadges/v2",
"id": "https://example.org/beths-robotics-badge.json",
"narrative": "This student invented her own type of robot. This included: \n\n * Working robot arms\n * Working robot legs",
"evidence": [
{
"id": "public_badgeURL_1",
"name": "Robot Arms and Legs Badge"
"description": "A badge for building robot arms and legs"
"genre": "Robotics"
},
{
"id": "public_badge_URL_2",
"name": "Robot Body Badge",
"description": "A badge for building a robot torso and head."
}
As per discussion in OpenWorksGroup/openbadges-directory#1 (comment) think about badge class versioning:
via @kayaelle "There's really no way to prevent changing the badge class. There's been some discussion of baking the badge class into the badges. That would atleast timestamp the badge data. If the badge class was baked into a badge as well as contain a version - that could inform the directory and save some work. Granted - issuers may not always update their versions but I think a directory would give them incentive to do so. (maybe)."
How do you define and validate against an array of values? enum seems to imply that only value can be valid at a time.
What if you want to define an array of strings and more than one can be valid. For instance if we were to define age groupings something like:
"3-5", "6-11", "12-18", "19-40", "40-65", "65-122"
and want to allow multiple values, how to best define that?
@andrewhayward ? :)
Thnx
It is not yet clear to me how the evidence property of a badge is meant to be used. The specifications say that this can link to videos or other documents related to the performance by the recipient.
I was thinking that it could also be useful as a way of identifying whether the person claiming to have earned the badge is really the one who did the work. For instance, if a video was recorded of the recipient doing a test, then it can be a way of confirming their identity. On the other hand, making a video recording, photo or passport copy of the badge recipient public through the evidence URL, published with the badge, is a privacy issue. If the email of the badge recipient is hashed to protect their identity, doesn't a photo or video of the recipient on the evidence URL cancel out this privacy protection?
So that leaves me wondering what is the intended use of the evidence URL. Is it meant as evidence of the recipient identity, or evidence of the quality of work done?
If it is meant as evidence of identity, should further security measures be implemented on the page that the evidence URL refers to? For instance, maybe the visitor of the evidence URL can be asked to provide the email of the recipient, or some token that is given by the recipient through a different communication channel? What kind and level of privacy measures would be acceptable here from a usability and privacy perspective? What would be the risks of having no further protection here and directly providing a photo or video of the badge recipient?
An issuer-client (indexer is the most obvious, there's probably more) needs to be able to grab some key information about a badgeClass that goes beyond the base specification:
OBr provides a lot of the above in the /v2/program/[shortname] feed, an example (the Mozilla Summit Toronto badge):
"mozilla-summiteer-2013-toronto": {
"name": "Mozilla Summiteer 2013: Toronto",
"shortname": "mozilla-summiteer-2013-toronto",
"description": "The Mozilla Summiteer badge acknowledges attendance and participation at the Mozilla Summit 2013 in Toronto, Ontario.",
"prerequisites": [ ],
"image": "http://badger.openbadges.org/badge/image/mozilla-summiteer-2013-toronto.png",
"criteria": "The Summiteer badge is a special edition badge created to acknowledge attendance at the 2013 Mozilla Summit. It is earned by working and sharing among peers at any one of three Summit locales—Santa Clara, Toronto, Brussels—during the 2013 Mozilla Summit.\r\n\r\nThis badge was earned at the 2013 Mozilla Summit in Toronto, Ontario, Canada.",
"tags": [
"attendance"
],
"categories": [ ],
"ageRange": [ ],
"rubric": {
"items": [
{
"text": "Satisfies the following criteria:\nThe Summiteer badge is a special edition badge created to acknowledge attendance at the 2013 Mozilla Summit. It is earned by working and sharing among peers at any one of three Summit locales—Santa Clara, Toronto, Brussels—during the 2013 Mozilla Summit.\r\n\r\nThis badge was earned at the 2013 Mozilla Summit in Toronto, Ontario, Canada.",
"required": true
}
]
},
"program": "1e4f3689c245070f39febe7f39ad4ede40e44c0e"
},
We want to preserve criteria pages as html, so they can continue to look cool...so the standard should probably be either RDFa, microformat, or something new and shiny I've never heard of.
What are some user stories for Displayer API Wishlist features?
This is related to my previous suggestion of an email-verify-url IdentityType.
No matter how secure a badge identity is made, it's only as secure as the identity of the badges with which it is shared together. Suppose someone has one badge that reveals their identity on the evidence page, and has another badge with secured identity. If they publish them in the same collection on a displayer that validates their email, then everyone knows that the secure badge belongs to the same email address as the non secure one.
I don't see how this can be prevented with any technical solutions, as it's more of a usage issue I guess, but at least there should be a note of warning for this, and a recommendation to displayers and issuers to warn their users, as it might not be obvious to a badge recipient.
Per some discussions on the Standards call, we've discussed the need to expand the definition of the standard into something more significant and not purely technical.
I wrote up my thoughts on this here: https://medium.com/@timothyfcook/an-expanded-open-badges-standard-94f3b55b0262
I'm posting this now, as a WIP, so it's at least out there, rather than sitting on my machine. Feel free to ignore, or dig in and tell me it's all wrong before it gets too late!
This documentation describes a candidate for the Open Badger API (OBr), version 3. This version of the API takes lessons learned from both previous versions, uniting them into into a more rounded, general purpose suite.
[TO DO]
[TO DO] This is not complete.
name - the name of the issuer. Required when creating new issuers. Will be present in all relevant requests.shortname - the issuer's slug, as used in API requests. Not allowed when creating new issuers (inferred from URL).url - the issuer's URL.image - a URL pointing at a graphical representation of the issuer.strapline - a short, one-line description of the issuer.description - a longer description of the issuer. Required when creating new issuers. May contain HTML.location - the canonical location of the issuer in the API. Not allowed when creating new issuers (inferred). Will be present in all relevant requests.meta - a meta object.POST /v3/data/example-issuer
{
"name": "Example Issuer",
"strapline": "The best issuer in the world!",
"description": "Example Issuer is strategically involved in issuing cutting edge badges, using the badging paradigm to think outside the box for a win-win situation."
}
GET /v3/data/example-issuer
{
"name": "Example Issuer",
"shortname": "example-issuer",
"url": "http://example.org",
"image": "http://example.org/media/images/logo.png",
"strapline": "The best issuer in the world!",
"description": "Example Issuer is strategically involved in issuing cutting edge badges, using the badging paradigm to think outside the box for a win-win situation.",
"location": "/v3/data/example-issuer"
}
[TO DO] This is probably not complete.
name - the name of the program. Required when creating new programs. Will be present in all relevant requests.shortname - the program's slug, as used in API requests. Not allowed when creating new programs.url - the program's URL.image - a URL pointing at a graphical representation of the program.strapline - a short, one-line description of the program.description - a longer description of the program. Required when creating new programs. May contain HTML.location - the canonical location of the program in the API. Not allowed when creating new programs. Will be present in all relevant requests.issuer - an abbreviated Issuer object, describing the issuer associated with this program. Not allowed when creating new programs.meta - a Meta object.POST /v3/data/example-issuer/example-program
{
"name": "Example Program",
"strapline": "The best program ever!",
"description": "Example Issuer is running the Example Program to disrupt the core competencies of the badging space.",
}
GET /v3/data/example-issuer/example-program
{
"name": "Example Program",
"shortname": "example-program",
"url": "http://example.org/programs/example",
"image": "http://example.org/media/images/programs/example.png",
"strapline": "The best program ever!",
"description": "Example Issuer is running the Example Program to disrupt the core competencies of the badging space.",
"location": "/v3/data/example-issuer/example-program",
"issuer": {
"name": "Example Issuer",
"location": "/v3/data/example-issuer"
}
}
[TO DO] This is probably not complete.
name - the name of the badge. Required when creating new programs. Will be present in all relevant requests.shortname - the badge's slug, as used in API requests. Not allowed when creating new badges.url - the badge's URL.image - a URL pointing at a graphical representation of the badge. Required when creating new badges. Must be a PNG.strapline - a short, one-line description of the badge.description - a longer description of the badge. Required when creating new badges. May contain HTML.criteria - a description of what an earner should be able to do having been awarded this badge. May contain HTML.location - the canonical location of the badge in the API. Not allowed when creating new badges. Will be present in all relevant requests.issuer - an abbreviated Issuer object, describing the issuer associated with this badge. Not allowed when creating new badges.program - an abbreviated Program object, describing the program associated with this badge. Not allowed when creating new badges.meta - a Meta object.POST /v3/data/example-issuer/example-program/example-badge
{
"name": "Example Badge",
"url": "http://example.org/programs/example/badges/example",
"image": "http://example.org/media/images/badges/example.png",
"strapline": "A truly awesome badge",
"description": "Ensuring deferred success to take it to the next level."
}
GET /v3/data/example-issuer/example-program/example-badge
{
"name": "Example Badge",
"shortname": "example-badge",
"url": "http://example.org/programs/example/badges/example",
"image": "http://example.org/media/images/badges/example.png",
"strapline": "A truly awesome badge",
"description": "Ensuring deferred success to take it to the next level."
"criteria": "",
"location": "/v3/data/example-issuer/example-program/example-badge",
"issuer": {
"name": "Example Issuer",
"location": "/v3/data/example-issuer"
},
"program": {
"name": "Example Program",
"location": "/v3/data/example-issuer/example-program"
},
"meta": {...}
}
A namespaced JSON data blob, with optional schemas.
{
"csol": {
"tags": ["13-18", "S", "T", "online"],
"ageRange": ["0-13", "13-18"],
"type": "skill",
"activityType": "online"
},
"geo": {
"$schema": "http://json-schema.org/geo",
"latitude": 51.507222,
"longitude": -0.1275
}
}Every API request will have the following response parameters in common:
status - Status of the request. If the request is good, contains the literal string "ok". If the request is bad for any reason, contains the literal string "error".error - If the request is bad for any reason, contains details of the error:
message - A human readable message describing the error.code - A code representing the type of error.For paginatable requests, the following response parameters are also shared:
page - The page being returned.pages - The number of available pages.pageSize - The number of results being returned per page.total - The total number of results available.previous - URL pointing to previous page of results, if that page exists.next - URL pointing to next page of results, if that page exists.For paginatable requests, the following response headers are provided:
Link: <URL>; rel=previous (where a previous page exists).Link: <URL>; rel=next (where a next page exists)./v3/data/:issuerGET
Get information about an issuer.
Response Statuses:
200: OK - If the issuer is found.404: Not Found - If the issuer is not found.Response Parameters:
issuer - Issuer object.Example:
{
"status": "ok",
"issuer": {
"name": "Example Issuer",
"shortname": "example-issuer",
"url": "http://example.org",
"image": "http://example.org/media/images/logo.png",
"strapline": "The best issuer in the world!",
"description": "Example Issuer is strategically involved in issuing cutting edge badges, using the badging paradigm to think outside the box for a win-win situation.",
"location": "/v3/data/example-issuer"
}
}POST
Create a new issuer.
201: Created - If the issuer was successfully created.400: Bad Request - If the request body does not contain a valid Issuer object.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to create an issuer.409: Conflict - If the issuer already exists.PUT
Create or replace an issuer.
200: OK - If the issuer was successfully updated.201: Created - If the issuer was successfully created.400: Bad Request - If the request body does not contain a valid Issuer object.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to create an issuer.PATCH
Update an issuer.
200: OK - If the issuer was successfully updated.400: Bad Request - If the request body does not contain a valid Issuer patch.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to update this issuer.404: Not Found - If the requested issuer does not exist.DELETE
Delete an issuer.
200: OK - If the issuer was successfully deleted.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to delete this issuer.404: Not Found - If the requested issuer does not exist./v3/data/:issuer/:programGET
Get information about a program.
Response Statuses:
200: OK - If the program is found.404: Not Found - If the program is not found.Response Parameters:
program - Program object.Example:
{
"status": "ok",
"program": {
"name": "Example Program",
"shortname": "example-program",
"url": "http://example.org/programs/example",
"image": "http://example.org/media/images/programs/example.png",
"strapline": "The best program ever!",
"description": "Example Issuer is running the Example Program to disrupt the core competencies of the badging space.",
"location": "/v3/data/example-issuer/example-program",
"issuer": {
"name": "Example Issuer",
"location": "/v3/data/example-issuer"
}
}
}POST
Create a new program.
201: Created - If the program was successfully created.400: Bad Request - If the request body does not contain a valid Program object.401: Unauthorized** - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to create an program for this issuer.409: Conflict - If the program already exists.PUT
Create or replace a program.
200: OK - If the program was successfully updated.201: Created - If the program was successfully created.400: Bad Request - If the request body does not contain a valid Program object.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden** - If the requesting client is not authorised to create an program for this issuer.PATCH
Update a program.
200: OK - If the program was successfully updated.400: Bad Request - If the request body does not contain a valid Program patch.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to update this program.404: Not Found - If the requested program does not exist.DELETE
Delete an program.
200: OK - If the program was successfully deleted.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to delete this program.404: Not Found - If the requested program does not exist./v3/data/:issuer/:program/:badgeGET
Get information about a badge.
Response Statuses:
200: OK - If the badge is found.404: Not Found - If the badge is not found.Response Parameters:
badge - Badge object.Example:
{
"status": "ok",
"badge": {
"name": "Example Badge",
"shortname": "example-badge",
"url": "http://example.org/programs/example/badges/example",
"image": "http://example.org/media/images/badges/example.png",
"strapline": "A truly awesome badge",
"description": "Ensuring deferred success to take it to the next level.",
"criteria": "",
"location": "/v3/data/example-issuer/example-program/example-badge",
"issuer": {
"name": "Example Issuer",
"location": "/v3/data/example-issuer"
},
"program": {
"name": "Example Program",
"location": "/v3/data/example-issuer/example-program"
},
"meta": {...}
}
}POST
Create a new badge.
201: Created - If the badge was successfully created.400: Bad Request - If the request body does not contain a valid Badge object.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to create a badge for this program.409: Conflict - If the badge already exists.PUT
Create or replace a badge.
200: OK - If the badge was successfully updated.201: Created - If the badge was successfully created.400: Bad Request - If the request body does not contain a valid Badge object.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to create a badge for this program.PATCH
Update a badge.
200: OK - If the badge was successfully updated.400: Bad Request - If the request body does not contain a valid Badge patch.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to update this badge.404: Not Found - If the requested badge does not exist.DELETE
Delete an issuer.
200: OK - If the issuer was successfully deleted.401: Unauthorized - If the requesting client is not authenticated.403: Forbidden - If the requesting client is not authorised to delete this badge.404: Not Found - If the requested badge does not exist./v3/data/:issuer/:program/:badge/recommendationsGET
Get a list of recommended "next badges" based on the categories of another badge
/v3/data/:issuer/:program/:badge/claimcodesGET
Get a list of claim codes available for this badge
POST
Create new claim codes for this badge
/v3/data/:issuer/:program/:badge/claimcodes/randomPOST
...
/v3/data/:issuer/:program/:badge/userGET
...
POST
...
/v3/claimPOST
...
/v3/userGET
...
/v3/user/recommendationsGET
...
/v3/issuersGET (Paginatable)
Get information about existing issuers.
Request Parameters:
search - A query string to filter the returned results. "Likeness" is determined by generating a case-insensitive, unbounded regexp, and is compared against issuer name and description.limit - The number of issuers to return per page. Defaults to 10. Pass 0 to get all issuers.page - The page to return, based on limit. Defaults to 1.Response Statuses:
200: OK - If the request is good.404: Not Found - If the requested page is not available, due to being out of bounds.Response Parameters:
issuers - List of abbreviated (?) Issuer objects.Example:
{
"status": "ok",
"issuers": [
{
"name": "Example Issuer",
"location": "/v3/data/example-issuer"
}
],
"page": 1,
"pages": 1,
"pageSize": 10,
"total": 1
}/v3/issuers/:issuerGET
Get canonical URL for an issuer. Somewhat redundant, but serves as a parallel to equivalent program and badge options.
Response Statuses:
303: See Other - Redirect to /v3/data/:issuer, if the issuer exists.404: Not Found - If the issuer does not exist.Response Parameters:
location - If the issuer exists, the canonical URL for that issuer.Example:
{
"status": "ok",
"location": "/v3/data/example-issuer"
}/v3/programsGET (Paginatable)
Get information about existing programs.
Request Parameters:
search - A query string to filter the returned results. "Likeness" is determined by generating a case-insensitive, unbounded regexp, and is compared against program name and descriptionissuer - An issuer shortname to filter the returned results.limit - The number of programs to return per page. Defaults to 10. Pass 0 to get all badges.page - The page to return, based on limit.Response Statuses:
200: OK - If the request is good.404: Not Found - If the requested page is not available, either due to being out of bounds, or because the issuer does not exist.Response Parameters:
programs - List of abbreviated (?) Program objects.Example:
{
"status": "ok",
"programs": [
{
"name": "Example Program",
"location": "/v3/data/example-issuer/example-program"
}
],
"page": 1,
"pages": 1,
"pageSize": 10,
"total": 1
}/v3/programs/:programGET
Get canonical URL for a program.
Response Statuses:
300: Multiple Choices - If multiple programs matching the program are found.303: See Other - Redirect to /v3/data/:issuer/:program, if the program exists.404: Not Found - If the program does not exist.Response Parameters:
location - If the program exists and is unique, the canonical URL for that program.options - If the program exists but is not unique, an array of potential matches.Example:
{
"status": "ok",
"location": "/v3/data/example-issuer/example-program"
}/v3/badgesGET (Paginatable)
Get information about existing badges.
Request Parameters:
search - A query string to filter the returned results. "Likeness" is determined by generating a case-insensitive, unbounded regexp, and is compared against badge name and description.issuer - An issuer shortname to filter the returned results.program - A program shortname to filter the returned results.limit - The number of badges to return per page. Defaults to 10. Pass 0 to get all badges.page - The page to return, based on limit.Response Statuses:
200: OK - If the request is good.404: Not Found - If the requested page is not available, either due to being out of bounds, or because the issuer or program does not exist.Response Parameters:
badges - List of abbreviated (?) Badge objects.Example:
{
"status": "ok",
"badges": [
{
"name": "Example Badge",
"location": "/v3/data/example-issuer/example-program/example-badge"
}
],
"page": 1,
"pages": 1,
"pageSize": 10,
"total": 1
}/v3/badges/:badgeGET
Get canonical URL for a badge.
Response Statuses:
300: Multiple Choices - If multiple badges are found.303: See Other - Redirect to /v3/data/:issuer/:program/:badge, if the badge exists.404: Not Found - If the badge does not exist.Response Parameters:
location - If the badge exists and is unique, the canonical URL for that badge.options - If the badge exists and is not unique, an array of potential matches.Example:
{
"status": "ok",
"location": "/v3/data/example-issuer/example-program/example-badge"
}<link rel="openbadges-assertion" href="badge.json"> to expose machine-readable information about badges described on human-readable webpages. Related to #1.schema and content objects as properties.We created a few test JSON that are missing some of the fields that are marked as mandatory in the specifications (e.g. uid), but the validator at http://validator.openbadges.org/ considered them valid.
Are the specifications out of date or is the validator not validating accurately (or am I missing something, always a possibility)?
Before it becomes its own repo, let's use this thread to discuss the hopes/dreams for a Learning Pathways design.
As discussed with @ottonomy the goals here are to create a data model for expressing learning pathways that consist of a number of nodes and connections between those nodes.
We're working on a program that can take any set of learning data and dynamically generate a resource map with embedded pathways as an interactive .svg ...we may want to sync up the goals and data behind this project with this pathways endeavor so that we can have a way to beautifully express pathways once they are created.
Here is the current data model behind the maps. It's a bit rough and could likely use some refinement. Maybe we can merge the goals of the two projects, ideally I would love to see maps like this be able to fully express the wealth of Resources, Competencies, and Badges.
The outstanding questions for me is:
How do we add on to this existing map--full mock-up and current prototype--or alter it to express the significance of competencies?
Thoughts:
badgeClass or an opportunityInstance (a.k.a. learning resource) is created, it can be mapped to a specific competency. Any/all badges/resources that map to a competency can then be curated into an ordered pathway for that competency. e.g. if you want to gain the "Systems Thinking" competency, you should complete a,b,c, and then x,y,z learning resources that have associated badges. Originally I was thinking of the "pathways" in these maps as sub-topics, but to some degree, all sub-topic represent are competency areas within a larger topic area... ? e.g. it's not specific enough to say I have a "Food and Gardening" competency, but it could be specific enough to say I have a "Composting" competency. Composting in this case in a sub-topic, but also a competency.Perhaps in the structure of learning objects, competencies could supplant the role of the sub-topic?
Thread was originally started here: mozilla/openbadges-backpack#1003
A method for an issuer to advertise all of the badge classes they offer.
With what we have now, it's really hard to build a service that exposes all of the learning/badging opportunities that exist. @thisandagain built something awesome during MozFest that crawls our backpack surfaces all the badge classes we know about, but this only works for badges that have already been earned, and it can't take into account a world of federated backpacks.
If we specify a way for issuers to advertise all of their badges, we (and others!) can then build tools that exposes that data in interesting ways. I also believe this helps us get a little closer to figuring out badge pathways.
Still thinking about this part. Based on some conversations with @thisandagain, @andrewhayward and @toolness here's what I'm thinking
At the index of the issuer's origin (potentially on other pages as well, e.g. criteria page) there should be a <meta> or <link> tag with some pointer (HREF) to a file that has the index of all badges.
I am still researching to see whether <meta> or <link> would be better. Any comments on that would be appreciated.
This part could get controversial.
Straightfoward, the file could provide an array of badge classes in JSON format:
{
"issuer": {
"name": "An Example Badge Issuer",
"image": "https://example.org/logo.png",
"url": "https://example.org",
"email": "[email protected]",
},
"badges": [
{
"name": "Awesome Robotics Badge",
"description": "For doing awesome things with robots",
"image": "https://example.org/robotics-badge.png",
"criteria": "https://example.org/robotics-badge.html",
"tags": ["robots", "awesome"],
"issuer": "https://example.org/organization.json",
},
{
"name": "Rad Pizza Badge",
"description": "For making amazing pizza",
"image": "https://example.org/pizza-badge.png",
"criteria": "https://example.org/pizza-badge.html",
"tags": ["pizza", "cooking"],
"issuer": "https://example.org/organization.json",
}
]
}I've also been toying with the idea of providing the badge listing as an RSS/Atom feed. I'm not super experienced with that and I don't if there would be any strong benefits. I'm gonna try to get some RSS experts to contribute to this discussion.
One drawback I can see is that it would potentially increase issuer burden – it's pretty easy to generate the JSON feed, but an RSS feed would take more time and effort, potentially even requiring pulling in additional dependencies. It would also require additional dependencies on the consumer side as well to parse.
I really like being able to use existing standards where they make sense, though, and there are likely some positives that I don't know about.
Currently, the only possible IdentityType is "email", which can be hashed for protecting the identity of the recipient and the abuse of their email address.
I see two problems with this:
Since the issuer's server already has to be contacted to verify a digital badge anyway, we could also let the issuer's server verify the email address. So there could be an identity type "email_verify_url", on a secure server, to which the email is submitted as a get request, and then returns 1 if the email is correct, 0 if the email is incorrect, or a HTTP status '503 Service Unavailable' when an attack is suspected. The issuer can then put extra security measures on this, such as limiting the amount of requests that can be made for the same badge, per hour.
This proposal shows how additional metadata fields to add more information to a badge could be standardized in an open distributed fashion in keeping with the spirit of the Open Badges Infrastructure.
The 1.0 Open Badges Specifcation allows issuers to include additional metadata fields in the badgeClass JSON, saying "additional properties are allowed if they don't clash with existing properties." Issuers are encouraged to namepace their additions to minimize the risk of two issuers defining differently implemented properties that have the same name.
This type of freedom makes it impossible to determine how to interpret the additional metadata, and there is no way to tell if two different badges use the same understanding of an additional property that they have included.
For example, two issuers include a property named "location" in their badge. One provides a URI of a website where someone can sign up for an online course that issues the badge. The other provides a US street address and geolocation of a school that at one time offered a course that issued the badge.
Much of the usefulness of the additional properties, as currently allowed, is assumed to be internal to the issuer, because the implementation of those properties could be closed-source. But many badges might have use for providing more information in a common, machine-readable format.
Define an extensions array as a property of the badge class, issuer organization, and badge assertion JSON. This is an unordered list of extensionObjects, each of which follow a structure like the following example using JSON-schema (JSON-LD, a w3c-track similar structured data specification, is also under consideration):
{
"schema": {
"reference": "http://example.org/badgeExtension1v1.json",
"hash": "sha1$cf23df2207d99a74fbe169e3eba035e633b65d94"
},
"content": {
"extensionProperty": "some text"
}
}
The proposal also requires an extension definition file to be accessible at the schema.reference URL (JSON-schema). In this case, it would define that the extension content could (or must) have a property called extensionProperty whose content would be text. The issuer generates a sha1 hash of the json retrieved from that location and includes it in the referrer object following the format alg$hash. This allows applications dealing in extended badges to cache them and determine if schema have changed, or if schema referenced at different locations are identical.
Backwards Compatibility: The proposal is backwards compatible with the 1.0 assertion specification for the badgeClass. It is ambiguous if it is compatible with the assertion or the issuer organization, though the addition does not conflict with any existing property. If an application analyzing the extended badge does not know how to understand the extensions array, it should ignore and leave them intact.
Standardized extension formats allow multiple issuers to define additional metadata in common, so that badge consumers can better understand...
1. What the additional information means to the issuer in terms of what fields are available and/or required as well as the data types that could populate those fields.
2. Whether two different badges are using the same definition for an additional property as each other.
3. Whether a badge extension is properly formed according to its definition.
At some point soon we're going to need to define what makes a backpack. I'm sure @stenington knows a lot more about this than I do, but I'll make a start.
Right now, our backpack boils down to three things:
Obviously users and badges are first-order entities (duh), but do we want to specify collections at the same level? My gut feeling is yes, but would be good to get other people's thoughts on the matter.
So, from a Open Badges Backpack (OBb) specification point of view, this might be considered a reasonable start (RFC 2119 yadda yadda):
"Public" here depends on context, and doesn't necessarily mean 'available to the whole world'. Within a school, for example, making your badge "public" may well still restrict it to people within the confines of the school network.
Further to these basic requirements, we probably also want to go a bit further (to cover stuff like federation, @brianloveswords?), and say that an OBb must have a way of programmatically interfacing with data (an API):
Of course, all of these actions should (must?) be restricted by permissions of varying levels, yet to be discussed. The only required point here is the ability to push badges to a backpack, meaning a full-blown API is not actually necessary for standard compliance.
Anyway, thoughts?
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?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.