Open zven opened 5 months ago
Update:
Similar to this example from the OB 2.0 standard, we should save additional information the badge an its issuer. This is merely an addition to the URI we already store in a baked badge. In addition, we also need to export the competencies. Example:
"extensions:CategoryExtension": {
"type": [
"Extension",
"extensions:CategoryExtension"
],
"extensions:Category": "competency"
},
"extensions:CompetencyExtension": [
{
"type": [
"Extension",
"extensions:CompetencyExtension"
],
"extensions:category": "skill",
"extensions:description": "Analysieren von Texten, die illustriert werden sollen, Recherchieren und Überprüfen der Quellen.",
"extensions:escoID": "/esco/skill/bf425f64-93d1-41c0-ab2d-1d02d026204d",
"extensions:name": "für die Illustration vorgesehene Texte analysieren",
"extensions:studyLoad": 1
},
{
"type": [
"Extension",
"extensions:CompetencyExtension"
],
"extensions:category": "skill",
"extensions:description": "Verfassen schriftlicher Texte in altgriechischer Sprache.",
"extensions:escoID": "/esco/skill/877057bc-7be8-4d40-9bab-cda10eb4b999",
"extensions:name": "Altgriechisch schreiben",
"extensions:studyLoad": 121
},
{
"type": [
"Extension",
"extensions:CompetencyExtension"
],
"extensions:category": "skill",
"extensions:description": "Studieren von Original-Musikstücken, um sich mit Musiktheorie und -geschichte vertraut zu machen.",
"extensions:escoID": "/esco/skill/2fa41ec9-5a43-4976-b34d-8639596f67ba",
"extensions:name": "Musik studieren",
"extensions:studyLoad": 3600
}
],
This would include
@timber-they Could this potentially break the current internal and external verification processes that can be reached via the public assertion link (e.g. https://staging.openbadges.education/public/assertions/1f3NdjycRomus8y1_XVyxg)?
@zven it could break if we don't implement it properly. A bit of context: We use https://badgecheck.io/ for verifying our badges. This runs the Open Badges Validator. This verifies the badges based on the Open Badges 2.0 standard; so everything that is valid within this standard supposedly also gets reported as valid. This includes linked data (which is also validated and included in the report from the validator).
I think it's worth it to try out how hard it is to add the information in a valid way and periodically check if the created badges are still validated by badgecheck during the development process. But then I don't see why we shouldn't be able to link that data.
@timber-they Thanks for the input! Apart from the formal aspect, my main concern is atm that those validators compare the information that is stored as text in the baked badge with the information about the badge that is stored on our server. In case someone edit the information of a badge on the server (as is still possible at the moment), the information in the baked image would not match the one on the server.
This would be something we should explicitly test when implementing this ticket.
@zven that is a valid concern. I would however also not be sure how it should behave in my opinion. Like, it is also reasonable to say that it shouldn't be valid anymore if the information stored in it is not up to date anymore, right? But either way, we should know exactly how it behaves to document it properly. But as you said, I think it makes sense to test it when implementing it.
@timber-they Once you are done with https://github.com/mint-o-badges/badgr-server/issues/176, I see this ticket as a next task for you.
At the moment, when baging / exporting a badge, it stores mainly IDs / references to our server for its details (following the linked data model):
To create a more portable representation, it's also possible to additionally store the (now only linked) information in the badge as well as highlighted in the Open Badge Standard 2.0 under Linked Data with some examples.
Idea: Store the linked data as well in the badge to ensure higher portability and make sure the badge still contains information once our servers are not up and running anymore.