Finalize Topic Collection Schema #35
Comments
|
Currently proposed additions are:
|
|
Some thoughts that come to mind reviewing the Topic schema:
Topics are clearly related to curricula but I don't think we've laid out the exact relationship/use cases anywhere. |
|
Domain: There is nothing to say that a new domain could not be added at any point in the future, those are just the current values. I would actually suggest that we might even want to reduce the domains considerably. The grouping seems a bit arbitrary to me. Skills: The skills referenced in the Now scope are the self-assessment values provided. If an apprentice has self assessed to possess a skill then resources for that skill should not be recommended. They can still be used, and added to a curriculum but they are not recommended. This is not part of the Topic microservice. This does imply that we have a self assessment collection somewhere. That is likely a collection we missed, and it is tightly linked to curriculum, so I propose that we add those endpoints to the curriculum API. Note that the curriculum API will also have a resource review collection, and we may want to add ratings to the resource model, and find a way to update resource ratings out-of-band. I would also suggest that you evaluate the resource type list. I think that list has way to many values, and we need to reel it in to the values that have meaning in our context. This will require that the scraping script be updated. We may also want to consider scraping some resources from the Odin Project. You can review the Oden Project Roadmap items in this document, and the Odin Full-Stack Path and then propose an approach for adding those resources (add new domains? - use existing domains - and add a new skill level of "Apprentice Candidate" for Odin resources?) |
|
More clarification on the Domain attribute. Think of it like this, the list of valid values has a very low volatility. Because of the way the API and UI are built, adding a new valid value, and updating the corresponding list in the enums collection, is the only change required. The API only needs to change if there is specific logic tied to the new value, and the UI will get the new valid value added to select lists with no code changes. |
|
Thinking about the resource type field, it seems to me that rather than using fine-grained classifications such as video/video series/film or article/book/document, it might be more useful to have a few different properties describing important characteristics of the resource. For example:
The free/paid distinction is already captured in another property, and the characteristic of length which separates "video" from "video series" and "film" or "article" from "book" can be captured in the duration property. |
|
I like the thinking - the primary value of the "resource type" attribute is to match it to a learning style. Some people hate watching YouTube, others hate "step-by-step tutorials". Maybe we just call it that - learningStyle. Then if we wanted we could make it a list of styles that are suited to the resource??? Data design in general, a list of strings is better than a list of booleans. |
|
There would still be at least two dimensions there, since a step-by-step tutorial can take the form of an article or a video, for example. I suppose you could do something like learningStyle:
formats: ["video", "text"]
resourceTypes: ["explanations", "tests"]Have to decide on better names but you get the idea Oh, and video/image could just be "visual", at least for learning style. For resource types that distinction matters |
|
There seems to be some overlap with the proposed "level" and the existing "isGeneralistSkill" properties. Since the former already includes "generalist" as an option, the latter could be replaced with it. Edit: I see "level" was proposed to be part of "outcomes". What was the idea behind this property again? |
|
I like the resourceTypes list, and here is my proposal on language. I think some clarification is justified.
If we do this, then I don't think we need the format attribute. If a person has a learning style of "video lecture" and the resource has a learning style of "video lecture" then I think we captured the format, or at least supported the requirement, without having to create a new attribute and logic related to both type and format. I think it's best to avoid creating things that might require a matrix of functions, or a matrix decision tree. Some times they are needed and important but you should really think about is the complexity required to meet the requirements or are we trying to perfectly capture information that is not needed by any feature but adds both maintenance burden and increases the "technical interest rate" of a piece of code. |
|
The person learning styles feature has a cup-cake, birthday-cake, wedding-cake implementation. person:
learningStyles:
exclude: [list of styles]and later on we can do more with "include", "and or" logic or others, this is just a starter |
|
Hi @michquinn . Checking in with you on how to contribute to this issue. |
|
Hi, @GrahamPaasch. There's no formal process really that I'm aware of, so if you have any suggestions for the schema, I'd be interested in hearing your thoughts 🙂 I hope that answers your question |
|
@FlatBallFlyer Just to make sure I'm understanding correctly. There seem to be some conflicting/overlapping suggestions so I'm trying to harmonize them The proposed property topic:
skills:
- name: Provisioning Cloud Infrastructure
description: Use Terraform to provision infrastructure with a cloud provider
level: Resident
domain: Specialist-SRE
- name: Clean Code
description: …
level: Generalist
domain: GeneralistResources then reference these skills topic:
resources:
- name: Terraform in 100 seconds
type: Explanatory Video
skills:
- Provisioning Cloud Infrastructure
- name: Getting started with Terraform
type: Instructional Text # you wanted to name this learningStyle here as well?
skills:
- Provisioning Cloud InfrastructureDoes that look more or less like what you had in mind? |
|
More or less, I was thinking a slug name (short, no white space) and the list can be discussed with a PR |
|
@michquinn Regarding learningStyles, @FlatBallFlyer and I just finished an indepth discussion of this concept. I am not convinced of the evidence that supports catering to learning styles as an effective learning strategy. What convinces me most is evidence from the top of the evidence-based medicine food pyramid, meta-analyses and systematic reviews. These can be found on sites like PubMed and typically come with a DOI string identifier. A lot of important progress has been made recently in regard to accessing these resources due to the creation of Sci-Hub. Accessing these papers are now as simple as pasting the DOI string into a Telegram conversation with a Sci-Hub bot. As most of these studies are funded in part or in whole by tax dollars, it is ethical for people to access them for free, since the payment has already been collected. What is unethical is the extortion of these resources for personal financial gain, and syphoning benefits away from the public, the researchers, and the research subjects. Here is a ChatGPT analysis of my claims. I agree with including a resource filtering feature, and with assigning tags to the resources, but I disagree that learningStyles is an effective tag. Instead, I advocate for a tag called "learningStrategies", which classifies resources as a type of educational strategy, from a list of strategies with the highest backing evidence, ideally with the backing evidence included somehow, such as by including the DOI, which is simply an identifier. The DOI string is outside the scope of a discussion about the ethics of methods for accessing scientific research. According to my research using ChatGPT, here are the 13 learning strategies with the highest level of backing evidence to prove their efficacy:
The implementation looks like this: topic:
resources:
- name: Terraform in 100 seconds
type: Explanatory Video
skills:
- Provisioning Cloud Infrastructure
- learningStrategy:
"Dual Coding": "10.1037/0033-295X.87.3.245"
- name: Getting started with Terraform
type: Instructional Text
skills:
- Provisioning Cloud InfrastructureAnd it is not necessarily incomplatible with an implemenation of a learningStyles filtering mechanism. |
|
Something I'm more excited about however, would be "resumeGoal". This key would contain a value of what you could honestly put onto your resume, and back it up, after you consumed the resources. It would be a bullet point string and could be used for automatic resume completion delivered as a reward for acheiving specific milestones on MentorHub. For example, of the many qualifications listed in this job post there are at least these two that appear to be easy to achieve via participation on MentorHub:
Therefore, these might be good resumeGoal bullet points to assign to learning resources. Once the prerequisite learning resources have been completed, the learner can honestly state and back up in an interview that they have these skills, and even describe the exact means through which the skills were gained. It could look like this: resumeGoal:
- servicesExecutionBulletPoint: "A thorough understanding of the best practices for services execution via the Services Execution Manual"
prerequisites:
- name: Services Execution Manual
type: TextBook
...
- mentoringBulletPoint: "Strong coaching and mentoring skills via the mentorship of 5 Agile Institute mentees over 6 months, leading to a 50% increase in their salary through career advancement."
prerequisites:
- name: Agile Institute Mentoring
type: Agile Institute volunteer work
... |
|
There's a lot to digest here so I may come back later with more questions but to start with is there a master list somewhere of those learning strategies? I see you've listed 13 of them (and that's quite a few already!), I just don't have a clear sense of which ones we'll be limiting ourselves to and why. I like the idea of resumeGoals as well. The idea of learning styles or strategies was Mike's, as was the matching of people with resources. That's not to dismiss it at all, but rather so I can give you a sense of what my initial thoughts were when I proposed changes to the resourceTypes property/attribute. My purpose in introducing the Likewise for |
|
I like the idea, but you are getting ahead of the game. This scope here is to capture information about different Topics of interest.
|
|
@GrahamPaasch I've finally read your comments more closely, I really like the resumeGoal:
- name: "Services Execution"
description: "A thorough understanding of the best practices for services execution via the Services Execution Manual"
prerequisites:
- name: Services Execution Manual
type: TextBookAnother matter is whether we would consider consumption of a resource as sufficient proof of having met that goal or if an assessment or functioning work sample is necessary Types are still undecided. It was brought to my attention by @FlatBallFlyer that my broad approach of categories like If we are to take your approach of associating a learning strategy with each resource, it does require that anyone categorizing resources understand those strategies (whether we would want to filter by such strategies from the UI or just leave it to the software to suggest resources on the basis of said categories is another question). It would also seem to me that if it is non-trivial to determine which learning strategies fit a given resource, that the property should be optional or otherwise have an "undetermined" option so resources can still be added when it is uncertain how to classify them. |
|
While I was trying to search for existing categorizations that we might use as inspiration (particularly published linked data vocabularies), I came across a standard from the IEEE. Unfortunately, it appears to be paywalled: https://ieeexplore.ieee.org/document/9262118/definitions There is a Wikipedia article which gives an overview, however: https://en.wikipedia.org/wiki/Learning_object_metadata EDIT: Other resources |
|
That structure looks great. Regarding sufficient proof of having met a
goal, I advocate for an assessment and/or a portfolio example. Also, a
certification would be a great qualifier.
I'm not sure how important it is to classify resources by "type", unless
it's a paid/free classification type. The most important thing to include
with a resource in my opinion is how to access the resource, such as a link
to the website or file storage location. Also, an ETA for how long it takes
to complete. I'm not sure how meaningful the "type" classifications would
actually be in the end, and as I wrote before I'd like to avoid playing to
biases and validating toxic preferences.
It might make sense to label resources as duplicate information, for
example The Odin Project and freeCodeCamp are very similar resources, and
could allow a user frustrated with The Odin Project to click a filter
button that says something like "I don't like this resource, show me
another!" at some point in the future. As far as "type", The Odin Project
and freeCodeCamp in my opinion are the same "type", and as far as internet
learning resources go I don't think there are meaningfully different types
of resources. Everything is going to be a mix of text/audio/visual/typing.
Even if you're reading an ebook it's going to have exercises, examples, and
links in it that take you to information of different "types".
Regarding learning strategies, those are separate from resources in a way.
For example, whenever I see practice questions in the AWS Cloud
Practitioner materials I screenshot them and put them in ANKI. Then when I
do the ANKI deck then I am doing a "Spaced Repetition" learning strategy,
using materials from whatever resource I can find that contains practice
questions. The "type" of the resource isn't as relevant to me as whether or
not it contains practice questions. It's really important that people who
want to learn are using effective learning strategies, and it's more
important that they use effective learning strategies than it is that they
think they're using effective learning strategies.
I'm very skeptical that resources are of meaningfully different "types".
Most things online are a form of dual coded information. I would say that a
live dance class is a different "type" of learning resource than a video
series on dance, but only if there is active physical intervention. Being
physically touched by an instructor or other dancers gives a different type
of input than does listening or reading. Even if you have a dance partner
to learn with, being touched by a skilled and physically intelligent
teacher can be more helpful than reading 1000 books.
Can you let me know in a brief and succinct way what our goal is here? I
know we're trying to finalize the topic collection schema, but to what
ends? What are we trying to do here to capture information about different
"topics of interest" that has not already been captured in EngineerKit?
- Define Skills - related to career alignment and in the future to be
referenced in goals. *(For this, I think "resumeGoals")*
- Define resources - for gaining those skills, with information that
empowers mentors to make good assignments *(Why not 1-to1 from
EngineerKit?)*
- Future use of this data will be closely aligned to curriculum. *(Just
link to EngineerKit?)*
- DJR process will help build goals that match to skills. *(Right, so we
do need to pin down which skills and which goals, is that what we're doing
here?)*
…On Tue, Jan 30, 2024 at 6:46 PM Michael Quinn ***@***.***> wrote:
While I was trying to search for existing categorizations that we might
use as inspiration (particularly published linked data vocabularies), I
came across a standard from the IEEE. Unfortunately, it appears to be
paywalled: https://ieeexplore.ieee.org/document/9262118/definitions
There is a Wikipedia article which gives an overview, however:
https://en.wikipedia.org/wiki/Learning_object_metadata
—
Reply to this email directly, view it on GitHub
<#35 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIC7GY5IYGOCVEGJH32JUQDYRGH5ZAVCNFSM6AAAAABB7PDV3WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJYGE3DCMZZGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
|
I think this is what we're looking for: mentorHubProjectSchema:
UserProfile:
- UserID: Unique identifier for each user
- Name: Full name of the user
- Email: Email address for communication
- Role: Role of the user (Apprentice, Mentor, Engineer, etc.)
- CareerStage: Current stage in career progression
- LearningStylePreferences: Describes user's preferred learning styles
- MentorID: ID of the assigned mentor (if applicable)
SkillsAndCompetencies:
- SkillID: Unique identifier for each skill
- SkillName: Name of the skill
- Description: Brief description of the skill
- DifficultyLevel: Difficulty level of the skill
- RelatedCareerStage: Career stage where this skill is relevant
LearningResources:
- ResourceID: Unique identifier for each learning resource
- Title: Title of the resource
- Type: Type of the resource (Video, Article, etc.)
- Topic: Topic or subject area of the resource
- AssociatedSkills: Skills related to the resource
- Duration: Estimated time to complete the resource
- Format: Format of the resource (Online/Offline)
- AccessibilityOptions: Available accessibility options (e.g., subtitles)
MentorshipSessions:
- SessionID: Unique identifier for each session
- MentorID: ID of the mentor conducting the session
- ApprenticeID: ID of the apprentice attending the session
- Date: Date of the session
- Duration: Length of the session
- FocusArea: Main focus or topic of the session
- Feedback: Feedback provided during the session
- FollowUpActions: Actions or steps to be taken following the session
CareerProgressionAndCertifications:
- UserID: ID of the user
- CareerStage: Current career stage of the user
- Achievements: Notable achievements of the user
- Certifications: Certifications awarded to the user
- DateAchieved: Date when the certification or achievement was awarded
- MentorFeedback: Feedback from mentors on career progression
ProjectWorkExperience:
- ProjectID: Unique identifier for each project
- UserID: ID of the user who worked on the project
- Title: Project title
- Description: Brief description of the project
- SkillsApplied: Skills applied in the project
- MentorID: Mentor associated with the project
- Outcome: Outcome or result of the project
- Duration: Duration of the project
FeedbackAndReviews:
- ReviewID: Unique identifier for each review
- UserID: ID of the user being reviewed
- ReviewerID: ID of the person providing the review
- Date: Date of the review
- Content: Content of the review
- Ratings: Ratings given in the review
# This schema is designed to be flexible and scalable, aligning with the goals and structure of the Agile Learning Institute's mentorHub. Feedback and suggestions for improvements are welcome.https://chat.openai.com/share/db7fe120-fd91-4c28-85bf-d95114b19a6d |
|
But that's based on our discussions, as I said I think we need to capatilize on AI and base our decision making on "knowing unknowns" by prompting AI to provide proposals backed up by the best possible scientific evidence: Via ChatGPT: User Profile
Skills and Competencies
Learning Resources
Mentorship Sessions
Career Progression and Certifications
Project/Work Experience
Feedback and Reviews
Overall Schema Considerations
By redesigning the schema with these changes, the mentorHub project can be more closely aligned with current evidence-based practices in education and professional development. This approach ensures that the platform remains effective, relevant, and capable of delivering high-quality learning experiences. |
|
This: mentorHubProjectSchema:
UserProfile:
- UserID: Unique identifier for each user
- Name: Full name of the user
- Email: Email address for communication
- Role: Role of the user (Apprentice, Mentor, Engineer, etc.)
- CareerStage: Current stage in career progression
- CareerAspirations: Specific long-term career goals of the user
- LearningGoals: Short-term and long-term learning objectives
SkillsAndCompetencies:
- SkillID: Unique identifier for each skill
- SkillName: Name of the skill
- Description: Brief description of the skill
- BloomTaxonomyLevel: Categorization based on Bloom's Taxonomy (remembering, understanding, applying, analyzing, evaluating, creating)
- RelatedCareerStage: Career stage where this skill is relevant
LearningResources:
- ResourceID: Unique identifier for each learning resource
- Title: Title of the resource
- Topic: Topic or subject area of the resource
- AssociatedSkills: Skills related to the resource
- Duration: Estimated time to complete the resource
- Format: Format of the resource (Online/Offline)
- AccessibilityOptions: Available accessibility options (e.g., subtitles)
- EvidenceBasedRating: Rating based on the evidence supporting their efficacy
MentorshipSessions:
- SessionID: Unique identifier for each session
- MentorID: ID of the mentor conducting the session
- ApprenticeID: ID of the apprentice attending the session
- Date: Date of the session
- Duration: Length of the session
- FocusArea: Main focus or topic of the session
- Feedback: Structured feedback based on SMART criteria
- FollowUpActions: Actions or steps to be taken following the session
CareerProgressionAndCertifications:
- UserID: ID of the user
- CareerStage: Current career stage of the user
- Achievements: Notable achievements of the user
- Certifications: Competency-based certifications awarded to the user
- DateAchieved: Date when the certification or achievement was awarded
- MentorFeedback: Feedback from mentors on career https://chat.openai.com/share/db7fe120-fd91-4c28-85bf-d95114b19a6d |
|
These comments are well beyond the scope of this issue. This issue is limited to the Topic domain, may of your collection names are off, and there is a lot of work to go. If you want to move some of this content onto other issues we can consider them there. This issue should address only Topics, Resources, and Skills. Many of these schema's already exists as drafts, with open issues. Please limit discussion here to the scope of the issue. |
We're in agreement here (including your addition of certification which I neglected to add)
I'm going to push back on this pretty strongly. There are many reasons a user may want to filter by media type. Just a few off the top of my head:
Besides the fact that unlike other categorizations, describing a resource as "video" or "text" is straightforward, taking away this categorization removes the ability for apprentices (or anyone else) to filter content with no apparent benefit. You are making an assumption here that these divisions are unimportant, and imposing that assumption on users by removing their ability to see this information and choose whether to make use of it.
If strategies aren't an inherent part of resources then they need not be included as a property thereof
Except that you could potentially ask questions and interact with the instructor, allowing them to modify their teaching on the spot, whereas a video series is recorded and no longer going to change. But then that is the difference between studying vs being taught actively.
Well, I'm of the opinion that resources are a top-level category, topics I'm less sure of. Ultimately, though, we want to describe the resources that form the basis of a curriculum (curricula will likely include a couple of other, basic items but resources are a critical part). The way curricula are currently set up, there is a "Now" scope consisting of the items (resources grouped by topic) which an apprentice is to focus on during the week. Besides describing properties of the resources themselves (such as duration/time to complete), some sort of structure is useful to help mentors and apprentices alike decide on which resources to add in a single "sprint" and which to work on next. It occurs to me that the current template primarily consists of courses (e.g. EngineerKit and the Odin Project) divided into modules, with each module containing resources organized into groups (corresponding to the topics of this schema). There is also at least one attempt at creating a new course, "SRE" |
|
MentorshipSessions are encounters, and there are encounter plans and encounters. Additional information to be added to the person collection (what you called a user profile) will include goals and other aspects, but we are building this one step at a time. Your continued insistence that there is no such thing as a learning style has always bugged me and I couldn't find the right words. You're failing to account for people who have different learning abilities, I'm confident that people who suffer from dyslexia will perform better when they're giving video or audio content. I'm convinced that people who suffer from significant ADHD will perform better when you give them tutorials than when you give them lectures. People who deal with performance anxiety are likely to perform better with lectures than they are with tutorials. Resource ratings will be provided by apprentices when they complete the resource they'll be given an opportunity for a brief writing that does not need to be covered within the scope of this issue The only reason that we have for capturing skills is to help us set goals and document accomplishments. A skill should be a referencable, specific, technical, example of putting something into practice. Skills can be the generalist level "having the ability to discuss" a topic or at the specialist level "experience implementing X tool to solve Y problem." The language used for skills is the language of job requirements and resumes. You'll need to explain to me the value of using blooms taxonomy in this case. IMHO it provides a significant cognitive load (explain it to users) - and gains us little to no real value because of the difficulty in capture and maintaining that data. |
|
I do wonder if for the categories that are difficult to iron out (such as granularity of types) that we might not be better served by leaving those as optional, and then staff can go in and add tags and adjust them as they see fit. That is:
|
|
Guys, I think we're doing this all wrong. If we have this kind of detail to discuss, you should create a branch make the changes to the schema files and submit a pull request. These will be much easier topics to discuss when we have a concrete design asset. |
|
You should see a PR from me by this weekend |
|
Here's a PR I made. While it does make sense to have the schema enforce data integrity at some level, I think a more flexible and adaptable schema will serve this project a lot better in the end, as what is valuable to learn in technology varies quite a bit from year to year. I think the EngineerKit Modules belong as part of data feed to an invoked schema, rather than hard coded within the schema. Similar with resource types. Although it allows for mistakes and inconsistencies in the data, I think it's worth the risk in order to be able to use the schema flexibly and creatively, which will matter a lot as things change. I believe that AI will totally reshape most things over the coming years. https://github.com/agile-learning-institute/mentorHub-mongodb/tree/issue35_topicsschema_proposal I think this issue can be closed, as further discussions are better suited to occur alongside visible schema change proposals via commits. |
|
There are no PR's open on the repo - show me your proposed schema and I'll review it then. I suggest you review the standard WorkFlow before we go any further. I would point you to the Architecture Principles - Separation of Concerns for our standards on where data quality enforcement occurs. You only get one chance to ensure data quality in a solution like this, and that is to enforce data constraints when it is captured. I don't have time to read a lengthily ChatGPT transcript. I can not comment on your ideas until I see how they impact the schema's in this repo. The issue will remain open until the schema is finalized. EngineerKit is seed data, not an integration source. We also have resources related to Odin that will need to be in the system. |
Uh oh!
There was an error while loading. Please reload this page.
Review use cases for the Topic data structure and planning documents, then finalize the Schema for the Topic collection.
Clarification Added 2/1/24
This is the Curriculum template we are currently using. The topic and related collections should accommodate this information. This shows both EK and Odin resources. Things are organized to allow sections to be visibly collapsed to make the large amount of content more consumable. Google Curriculum Template
The text was updated successfully, but these errors were encountered: