Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discriminating between multiple alignments #45

Open
GerbenKD opened this issue Oct 26, 2023 · 12 comments
Open

Discriminating between multiple alignments #45

GerbenKD opened this issue Oct 26, 2023 · 12 comments

Comments

@GerbenKD
Copy link

I would like to be able to align a learning resource to multiple learning objectives. Clearly I can use multiple lrmi:teaches properties. However, there are cases where these learning objectives are for different educational levels. But, how would you discriminate this? If I add lrmi:educationalLevel properties, these are on the resource and the information to which learning objective these belong is lost. Is this something that I can tackle with LRMI, or do I need to do some extension myself?

@philbarker
Copy link
Collaborator

I don't think we have come across this use case before, at least not in the way you phrase it. It does resonate though, I taught a course offered to final year undergrads and MSc students, the learning objectives (and assessments) were slightly different for the two groups. In that case the course catalogue listed two separate courses (which happened to be scheduled together), so that might be one modelling option.

Would it work for you to add the information about educational level to the description of the learning objective? That's closer to what I have seen, but not quite what you describe.

Or you could use the an AlignmentObject as an extension point, it does exist as a way of reifying the alignment between a learning resource and something else.

(If you are able to tell us more about what you are doing, we are always interested in learning how LRMI is used. You can use this form to provide as much/little information as you wish.)

@jmarks
Copy link

jmarks commented Oct 27, 2023 via email

@stuartasutton
Copy link
Collaborator

stuartasutton commented Oct 27, 2023

My sense of the cases stated by @philbarker and @GerbenKD is one in which the learning resource description and description of the circumstances in which the learning resource is contextualized are conflated. The most reliable modeling solution seems to me to be separate and relate the two descriptions; i.e., Context==contextualizes==>LearningResource. Thus, in @philbarker's example there would be a LearningResource instance contextualized via two Context instances, one for Upper Division students and one for MSc students. The Context instances would bundle and carry the applicable learning objectives, assessments, level etc.

This basically means that immutable attributes of the learning resource are separated from contextual variability rendering the learning resource description reusable. I do NOT think that AlignmentObject is useful beyond being able to particularize the naming of the predicate associating the LearningResource to a Context...(but this may have been what Phil is suggesting). Such use of AlignmentObject does not, it seems to me, negate the need to point to some resource defining the particular context.

By the way, this same resource/context modeling issues exists with competency definitions.

@philbarker
Copy link
Collaborator

@stuartasutton I was thinking; for example:

<Course> :educationalAlignment 
    [ :alignmentType :teaches;
      ex:inContext <UpperDivision> ;
      :targetUrl <LO1>, <LO2> ] ,
    [ :alignmentType :teaches;
      ex:inContext <Masters> ;
      :targetUrl <LO1>, <LO2>, <LO3> ] .

I think it works if you don't want to say too much more about the course in the two contexts; if you do have more to say then the cleaner approach of creating different descriptions for the two contexts would be necessary.

@GerbenKD
Copy link
Author

GerbenKD commented Nov 3, 2023

Thanks for the great answers @stuartasutton, @philbarker :) Meaning to reply earlier, so apologies for not doing that.

I'm wondering whether I'm overcomplicating matters, so let me briefly describe what we are doing. We are working on aligning educational web resources to different international curriculums. Currently, we have a very rigid tree structure (subject->grade->topic->LO->resource) in a database. We are moving this to a knowledge graph, with SKOS vocabularies for the curriculum concepts and LRMI to align the web resources to these vocabularies.
In this scenario it does occur that a web resource can align to different <LO, grade>, or <LO, topic> pairs (or a combination). Hence my question in the OP.

I like the suggestion of the Context instances, are there existing properties/schemas that I could use?
However, it does seem quite a complex solution to something that doesn't appear very complex at first glance (at least to me). So I do wonder whether I'm overlooking some other way to handle this issue.

@philbarker
Copy link
Collaborator

@GerbenKD now you put it like that, I see similarities with @jmarks reply.

If you consider the subject->grade->topic->LO hierarchy to be the "curriculum" or "learning standards framework" (nomenclature varies from country to country) then it would quite normal to have something like:

Applied Maths:

  • grade 11
    • Differential Equations
      1 Apply differential equations to calculate projectile trajectories. (<AM.11.DE1>)

Physics

  • grade 12
    • Classical Mechanics
      1 Calculate projectile trajectories using equations of motion in differential form. (<PH.12.CM1>)

<learningResource> :teaches <AM.11.DE1>, <PH.12.CM1>

Hope that makes sense.

@GerbenKD
Copy link
Author

GerbenKD commented Nov 3, 2023

@philbarker it does make sense. But would you then forego adding <lr> :about <classical mechanics> etc.? And leave that all with the modelling of the curriculum/framework?

We would like to get rid of the rigid hierarchy we had. For example, filtering on Classical Mechanics should give resources for all grades and learning objectives that are applicable. Classical Mechanics should conceptually be the same Topic for every grade (or subject) right?

@philbarker
Copy link
Collaborator

You certainly could add <lr> :about <classical mechanics> as well, I would encourage that especially if you have SEO among your aims.

Classical Mechanics should conceptually be the same Topic for every grade (or subject) right?

That is true conceptually, but in practice the learning resources for the same topic can be very different depending on grade and subject; different subjects might treat the same topic in different ways. One aspect of that is what we are discussing here, a topic may appear at different levels of the curriculum in different subjects. If you are trying to map in such a way as to be curriculum independent I think you probably need less precision in order to be more accurate: for this example <lr> :educationalLevel <grade11>, <grade12> would be more accurate than being more precise. Or, you are back to the option of putting the context somewhere else.

@GerbenKD
Copy link
Author

GerbenKD commented Nov 6, 2023

Thanks again!

Considering the contextualization option. The context instances should also be LearningResources, so I imagine it would look something like the sample below? Does that makes sense? And is there existing vocabulary I could use for the ex:contextualizedAs and ex:contextualizes properties? Or maybe a property I could extend?

<lr> ex:contextualizedAs <ContextA>, <ContextB> .
<ContextA> ex:contextualizes <lr> .
<ContextB> ex:contextualizes <lr> .

<lr> a :LearningResource .
<ContextA> a :LearningResource .
<ContextB> a :LearningResource .

<ContextA> :teaches <LoA> ;
	:about <TopicA>, <TopicB> ;
	:educationalSubject <SubjectA> ;
	:educationalLevel <Grade10> .

<ContextB> :teaches <LoB> ;
		... .

@philbarker
Copy link
Collaborator

@GerbenKD sorry you didn't get a reply sooner. I guess it makes sense. "Context" as a learning resource makes sense in terms of being in accord with the expected domain of the properties you want to use, but would probably need a some explaining to make sense in terms of the natural understanding of the word. I think that would probably work itself out as you develop concrete examples. Maybe you'll find "context"/"contextualizes" aren't quite the right words when you have a set of examples.

I don't myself know of an existing vocabulary, but again that might become apparent through examples. One possibility is that schema:EducationEvent is relevant; but while it has the right properties it is not a learning resource (b/c it is an event) so it really depends on what the "contextualizations" really are.

@GerbenKD
Copy link
Author

Thanks for the reply @philbarker! I will continue as I suggested. You're right that probably a better word will come up when working out a number of examples. I'll add to this thread if I come up with something that we are happy with, if that is appreciated.

@stuartasutton
Copy link
Collaborator

While it appears that the issue here has been somewhat resolved, I think that the matter raised--separation of a learning resource from its context(s) is worthy of careful thought and further discussion by this or some other group as its impact on both learning resources and competencies is significant. There is an inverse relationship between the richness of a description and the shareability/reusability of that description in contexts other than the one in which it was (richly) defined. This inverse relationship was recognized and clearly articulated early in the competency description space by Claude Ostyn in the abandoned IEEE work on Simple Reusable Competency Map back in 2007 and in the seemingly unused European CEN Workshop Agreement InLoc–ELM Information Model for Learning Outcomes and Competencies. The linked data muddle that the conflation of resource and context creates is not widely apparent in supposedly shareable/reusable data due to the current destination of such data in closed world systems. As hosting this data in open linked graph data stores becomes more common, the conflation muddle will present a serious problem not only with LRMI but also with CASE-LD, ASN, CTDL-ASN, the new IEEE 14844.20.3, and the emergent IEEE P2881.

It is not likely that it will be a totally pleasant discussion given previous investments, but grappling with the consequences of this inverse relationship is important

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants