How to make course activities child activities discoverable ?

[lebrunthibault]

Goal

As a Learning Record Consumer, I want to be able to

• request Ralph with an activity id IRI and get a list of children activities of this parent activity.
• request this list in a performant way that executes in constant time

Existing situation

The only thing Ralph can do to adress this issue is return statements that match an activity (using an activity id IRI)
This solution will only look into the “object” part of the statement and match statement.object.objectType == “Activity” && statement.object.id == activity_id
This approach does not handle hierarchical activity relations (e.g. a question in a quizz belonging to a course) that is specified in statement.context.contextActivities
complexity: On

Describe the solution you'd like
There are different ways to handle this case. My favorite would be to use the Activity Profile Resource that serves as a scratchpad key value store for activity metadata.

Using this resource would allow us to store the list of children activities into the profile activity (by activity id and profile id) and query the list by doing a GET on /xAPI/activity/profile?activity=<courseId>&profileId=<profileId>

We can either:

• POST activity metadata (including a list of its children activities) into /xAPI/activity/profile from outside of ralph : e.g. from the LMS ..?
• have each POST on /xAPI/statement check if the object is an activity (AND optionally check the parent activity is a course id) and then :
  • internally update the activity profile representation (would this be compliant ?) or
  • make a POST on /xAPI/activty/profile to keep the LRS semantics : this would be my preferred solution

This solution seems right when we consider the example given in the xapi blog

This resource could be implemented following the related #379

Describe alternatives you've considered

Using related_activities=true

The LRS spec defines a boolean parameter related_activities that extends the match to context.contextActivities : Apply the Activity filter broadly. Include Statements for which the Object, any of the context Activities, or any of those properties in a contained SubStatement match the Activity parameter
This solution is slow and executes in 0n

Using activities resource

Ralph could maintain an internal canonical activity definition for the course exposed as an activity resource. Every time a statement is pushed that relates to the course we add the activity to the inner activity list.
The list could be exposed in the moreInfo irl or extensions property
Complexity is constant.
Question : Would this update to the canonical activity definition be fully compliant ? see spec. LRSQL does indeed seem to update the definition.
Question : the spec does not specify if we would need to return the full course activity definition in existing statements ?
NB : populating the activity resource means the resource would be returned when querying statements with format=canonical with the list of children activities. Is this behavior what we want ?

LRSQL does not register activities resources by looking up context.contextActivities. This is not specificed in the spec from what I understand, we might still be able to do it.

This solution could be applied to all statements and activities, creating activity resources every time new activities appear in statements (considering activities and related activities) or just do this for courses. The latter might be less generic and less spec compliant.

Using a metadata provider

Too complicated surely but we could also make the course id an IRL that would be hosted outside ralph (e.g. by an LMS) and store a list of activities.
The activity metadata would be fetched directly from the metadata provider or possibly in the activities resource
Problems:

• the metadata provider would need to host data
• ralph would not control it

Discovery, Documentation, Adoption, Migration Strategy
Users will be able to GET the /xAPI/activity/profile?activity_id=<activity_id> and get the activitiy definition enriched by the list of its children activities of type :

children_activities: List[ActivityDefinition]

What do you think ? :)

[lebrunthibault]

After discussions with amazing people from ADL here are some insights about how we can answer our question : How to list all learning activities related to a course ?

Using the Experience Index (TLA level 3, quite a comprehensive, maybe future, solution)

• check the IEEE P2881 Standard for Learning Metadata and the IEEE 1484.20.3 Standard for Shareable Competency Definitions
• Set Up an Experience Index (LRS for learning resources - new name for activities) where all the metadata for each learning resource (course, activity, event) is stored.
• make warren query both the XI and the LRS

How to exploit xAPI statements to link an activity to its course

• use pertinent activity (object) identifiers. We can either use a unique course ID for each course “instance” / “offering” (called a Learning Event in IEEE P2881) or a course id for the course in general (called a Learning Resource in P2881 and in LRMI).
• Choosing between learning event ids or learning resource ids strikes a balance between granularity (learning event ids) and aggregation (learning resource ids) : how does this relate to our case ..?
• If we use course "offering" ids we can trace back to the learning resource using P2881 metadata (Experience Index). Or we trace back by using comprehensive identifiers and / or through context activities (we could use the general course id as a parent to the course “offering” id in context.contextActivities).

Build the activity list from statements or use a course catalog ?

• Registration : make it possible to connect the learner with a particular set of activities (used in profile patterns) -> Although frequently a unique registration will be used for one Actor assigned to one Activity, this cannot be assumed (from the spec) . Tracing any registration should provide all activities within that course by their ids.
• use metadata : the best way is still to relate the activities together using metadata
  We could use CMI5 : it's better if the course structure and rules are already be known. Cmi5 is a profile of xAPI that sets up all of the rules around this in a way similar (but simpler) than the SCORM imsmanifest. NB : does this relate to the notion of course package as defined by xapi ? In this case we would need to import course packages / course catalogs.
• final thought : it's better to don’t compute the list from statements : It is not recommended that xAPI Statements try to rebuild a course structure from Statements.

TLDR :
recommended solutions are :

• setup and use an experience index, TLA level 3 (long)
• use course structure metadata directly with Cmi5 profile