1EdTech / openbadges-discussion

A no-code repository for having discussions related to the general technical issues of openbadges.
10 stars 3 forks source link

Learning Pathways Specification #24

Open timothyfcook opened 8 years ago

timothyfcook commented 8 years ago

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:

Perhaps in the structure of learning objects, competencies could supplant the role of the sub-topic?

ottonomy commented 8 years ago

A basic LearningPathway, created by the issuer of some badges to share some badges they published and how they fit together.

{
  "context": ["https://w3id.org/openbadges/v1", "https://w3id.org/openbadges/v1/pathways"],
  "id": "http://omsi.org/examplePathway1",
  "name": "OMSI Exploration Pathway",
  "description": "A collection of badges earned while hanging out at OMSI. That's cool!",
  "pathwaySteps": [
    {
      "id": "https://omsi.org/examplePathway/steps/1",
      "type": "PathwayStep",
      "name": "Step 1",
      "description": "This is the first step in an enjoyable stage of your lifelong learning journey.",
      "badge": "https://omsi.org/badges/badge1"
    {
      "id": "https://omsi.org/examplePathway/steps/2",
      "type": "PathwayStep",
      "name": "Step 2",
      "description": "Welcome to Step 2. Have you completed it?",
      "badge": "https://omsi.org/badges/badge2"
    }
  ],
  "issuer": {
    "id": "http://omsi.org/id",
    "name": "OMSI",
    "description": "A science museum in Oregon. So interactive!",
    "url": "http://omsi.org"
  }
}

A badge recipient republishing a pathwayEmbedding a processed representation of a badge in a pathway (note, this is not exactly a to-spec badge, as it combines some information from all three separately hosted badge objects)

{
  "@context": ["https://w3id.org/openbadges/v1", "https://w3id.org/openbadges/v1/pathways"],
  "id": "http://recipient.com/myCustomPathway1",
  "type": "LearningPathway",
  "name": "OMSI Exploration Pathway",
  "description": "A collection of badges earned while hanging out at OMSI. That's cool!",
  "alignment" {
    "url": "http://omsi.org/examplePathway1",
    "description": "Aligns to OMSI's exploration pathway"
  },
  "recipient": {
    "type": "schema:Person",
    "name": "Nate",
    "identity": "nate@ottonomy.net",
    "id": "http://ottonomy.net",
    "image": "http://ottonomy.net/mugshot.jpg"
  },
  "pathwaySteps": [
    {
      "id": "https://omsi.org/examplePathway/steps/1",
      "type": "PathwayStep",
      "name": "Step 1",
      "description": "This is the first step in an enjoyable stage of your lifelong learning journey.",
      "earnedBadgeInstance": [{"recipient": "nate@ottonomy.net", "is_valid": true, "version": "v1.0", "errors": [], "json": {"issuedOn": "2014-09-05T21:45:09+00:00", "uid": "4613", "type": "Assertion", "evidence": "https://app.achievery.com/earned/4613", "badge": {"type": "BadgeClass", "id": "https://app.achievery.com/badge-class/1716", "name": "DPD Project Contributor", "description": "Awarded for team members on the DPD project that studied badge system design from 2012-2014.", "image": "https://images.achievery.com/badgeImages/DPDContributorBadge_1716_1.png", "criteria": "https://app.achievery.com/badge/1716", "tags": ["Higher Education", "Writing"], "issuer": {"type": "Issuer", "id": "https://app.achievery.com/issuer/2515", "name": "Design Principles Documentation Project", "url": "https://app.achievery.com/passport/id/2515", "image": "https://images.achievery.com/organization/badger-icon-transparent.png"}}, "@context": "https://w3id.org/openbadges/v1", "recipient": {"recipient": "nate@ottonomy.net", "type": "email"}, "id": "https://app.achievery.com/badge-assertion/4613"}, "instance": {"issuedOn": "2014-09-05T21:45:09.000Z", "uid": "4613", "verify": {"url": "https://app.achievery.com/badge-assertion/4613", "type": "hosted"}, "recipient": {"salt": "2zjIsSSl12PiZJkiq4Hq33ImLFhHMBHBrSzDyc9DiOtGVg8P7VDVPNa2QgAXHQQ9", "type": "email", "hashed": true, "identity": "sha256$1a29bbe7d65355ce7647793396041c7bebbe333e677222c5ca116f5cc038b9ef"}, "evidence": "https://app.achievery.com/earned/4613", "badge": "https://app.achievery.com/badge-class/1716"}, "instance_url": "https://app.achievery.com/badge-assertion/4613", "badge": {"description": "Awarded for team members on the DPD project that studied badge system design from 2012-2014.", "tags": ["Higher Education", "Writing"], "image": "https://images.achievery.com/badgeImages/DPDContributorBadge_1716_1.png", "criteria": "https://app.achievery.com/badge/1716", "issuer": "https://app.achievery.com/issuer/2515", "alignment": [{"url": "http://dpdproject.info", "name": "DPD Project Website", "description": "The homepage for the DPD Project showcases design principles for using digital badges for learning, related research literature, analysis of common challenges, and badge system design tools developed by the team."}], "name": "DPD Project Contributor"}, "badge_url": "https://app.achievery.com/badge-class/1716", "issuer": {"url": "https://app.achievery.com/passport/id/2515", "image": "https://images.achievery.com/organization/badger-icon-transparent.png", "name": "Design Principles Documentation Project"}, "issuer_url": "https://app.achievery.com/issuer/2515"}]
    },
    {
      "id": "https://omsi.org/examplePathway/steps/2",
      "type": "PathwayStep",
      "name": "Step 2",
      "description": "Welcome to Step 2. Have you completed it?"
    }
  ]
}

A badge aligning to a step on a badge pathway:

{
  "@context": "https://w3id.org/openbadges/v1",
  "type": "BadgeClass",
  "id": "https://omsi.org/badges/badge1",
  "name": "Awesome Learning Badge 1",
  "description": "For doing awesome learning things.",
  "image": "https://omsi.org/learning-badge1.png",
  "criteria": "https://omsi.org/learning-badge1.html",
  "issuer": "http://omsi.org/id",
  "alignment": [
    { "name": "OMSI Pathway step 1",
      "url": "https://omsi.org/examplePathway/steps/1",
      "description": "This is the first step in an enjoyable stage of your lifelong learning journey."
    }
  ]
}
timothyfcook commented 8 years ago

So, I feel like there is a big decision to made here about whether or not the steps on the pathways represent an abstract "competency" or if pathways only exist when they reference specific badges or resources.

If it's the prior, then (very similar to badges), there might be 2 expressions of pathway documents. Possibly a pathwayClass and a pathwayAssertion ?

A pathwayAssertion I think would be similar to your first example in which a pathway's steps are referencing specific badges that align to those steps. As you note at the end, an individual badgeClass could also contain this alignment information. Learning resources, more generically, could also align with pathway steps.

The pathwayClass on the other hand could be the abstract representation of a pathway as a set of learning outcomes/competencies. e.g. "Step 1" could be "Functions in Python", but any number of badges or learning resources could align to that step. Each step or competency could have it's own JSON-LD @context that points to a definition of the competency

The competency as an element, might also require its own specification in this framework : )

jgoodell2 commented 8 years ago

Sorry I didn't make the badges call to discuss this.

CEDS has a logical model for learning pathway (or competency pathway) associated with badges (achievements). It is not expressed in JSON, but could be. It builds on the structure of other standards and defacto standards for educational frameworks (inLOC, ASN, SIFA, RDCEO, etc.) The approach leaves the educational framework as the place for defining each competency (or step) and the relationships between nodes. It uses an item association object to define the connections between nodes in the learning pathway. E.g. LearningObjective1 "precedes" LearningObjective2. (See https://ceds.ed.gov/CEDSElementDetails.aspx?TermxTopicId=25320) An achievement (badge) may be associated with the completion of one or more learning objectives defined as nodes in one or more frameworks. CEDS defines "Competency Set" entity as a way of defining multiple competencies are required to earn a badge.

There is more to discuss about recommended pathways vs. required pathways vs. individualized pathways (planned), individualized pathways (actual). My current thinking is that the pathway is separate from the badge--there may be multiple possible paths to an achievement.

jim

timothyfcook commented 8 years ago

@jgoodell2 our project is also using what you call an "item association object", we use before_this and after_this

jgoodell2 commented 8 years ago

@timothyfcook I see that in your project it is important to keep the connection/pathway information out of the node, and to have context so a "connector" can be part of a pathway and distinguished from other pathways. I.e. "before_this" may apply to one pathway but not another for a given node.

timothyfcook commented 8 years ago

Yeah, we are working on maturing the data model soon to allow nodes to be part of multiple pathways.

ottonomy commented 8 years ago

@timothyfcook To your comment above, I don't think we need to decide on the points you referenced above and that we can go both ways on each decision. A linked data model is pretty flexible, so the question is how much flexibility in consumer applications do we want to force on implementers from the outset. My suggestion would be to build toward a few well-defined use cases, and use a linked data data model that will require no changes to be flexible to different use cases in the future. We can start with a basic core vocabulary and a couple key use cases that expand on the core in the first year.

As far as what one "step" on a LearningPathway is, I think that a step can be whatever it wants to describe itself as. Some steps may represent competencies, some may represent experiences, requirements, or other things. I might say the PathwayStep class should have an id (URL/IRI), name, and description, but maybe it also claims to be a node of additional types and has additional properties relevant to those types.

The LearningStandardItem class that @jgoodell2 linked to would be a possible class to use -- just give your node an id, name, and description, and then add the LearningStandardItem type and the rest of the properties that it requires/supports. It looks like the CEDS data model isn't defined by them using linked data technologies, it seems, but it does have a formal vocabulary identified by IRIs, so we could probably create a context file that aligns to the current IRIs for this module. Take a look at those properties and see if they look like what you would want to use to describe a LearningStandardItem.

A step defining a competency that doesn't have a badge or learning opportunity associated with it, for example:

{
'id': "http://competencysystem.com/competency21",
"type": ["Competency", "PathwayStep"],
"name": "Weightlifting Safety, Bro",
"description": "do you even lift safely?"
"...":"..."
}
timothyfcook commented 8 years ago

The loose structure and use of different types seems like it could work. In that case, however, it might be useful to accompany it with a whitepaper/thought-piece about the relationships between different learning elements.

In a way, the pathway spec is a way to graph different types of learning elements: a competency graph, a credential graph, a resource graph. I could see employing all 3 types within a single pathway/graph, but it is tricky since these elements also have a nesting relationship (i.e. learning opportunities result in badges which map to competencies).

I've started another post trying to wrestle further with the relationship between these three elements: https://medium.com/sprout-stories/quantum-mechanics-of-learning-742f9ba70cc2

Obviously, as the author of a generally-usable standard spec, the Badge Alliance might not want to dictate how data structures should be used, but it might be beneficial to situate the publishing of a pathways data spec with deep discussions on how it is best employed and the foundational questions concerning its use.

jgoodell2 commented 8 years ago

Well done @timothyfcook. I agree with your post that the pathway/graph could be applied to each of competencies, opportunities(learning experiences/resources), and credentials. Each could have a planned pathway (map) and an actual pathway (e.g. as captured by xAPI). The standards for the different kinds of nodes should be informed by existing standards, e.g. inLOC/ASN protocol/etc for competencies, LRMI/Schema.org/DCMI for learning resources, Open Badges/eTranscripts/digital certificates/etc for credentials.

A questions to consider is what kind of element drives the decision-making? Does an adult learner start with a sequence of stackable credentials supporting a career latter (the credentials graph), and that drives the sequence of desired competencies (competencies graph), and that drives the planned sequence of learning activities (resources graph)? Or does it start with learning opportunities, such as a sequence of courses, or does it start with the sequence of competencies for subjects in which prerequisites build to more advanced learning? It may be that there are one or two best starting models depending on the subject matter, context, and learning goals.

timothyfcook commented 8 years ago

Exactly. Likewise, the big outstanding question for me still is how the 3 graphs interact.

The obvious graph that could drive the others would be the Competency Graph ... it defines what ought to be learned, and then learners and educators can aim towards that with related credentials and learning resources.

It's all a bit muddy.

I like the idea of creating a "Learning Graph Specification" and/or a "Learning Pathways Specification" that works for all 3 atomic types of learning elements (competencies, credentials, and opportunities), and one that works for all kinds of credentials (open badges, eTranscripts, etc.) and all kinds of learning opportunities (digital resources, in-person courses, human mentors, etc.)