Make course activities child activities discoverable

[lebrunthibault]

Feature Request

Is your feature request related to a problem or unsupported use case? Please describe.

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 (that excludes using the related_activities query parameter)

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 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]

Do you want to work on it through a Pull Request?
Yes, but first let's discuss it !

[t-fritsch]

Sorry to revive this closed issue but since it has been closed>reopened>put-on-roadmap>closed again I wonder : is this feature available ? I couldn't find documentation about it.

I'd like to get statements that have a specific context.contextActivities.parent.id and thought it could be possible by using the ?related_activities=true query parameter but it doesn't seem to work. The openapi (swagger) interface says it is "Not implemented", is it just an outdated annotation ?

thanks for your help

[wilbrdt]

Hey @t-fritsch! I'm sorry to say that the related_activities parameter is not implemented, and that there are no plans to implement it in the near future. But we would welcome any contribution to add it! 😃

[t-fritsch]

thanks for your reply @wilbrdt and sorry for the delay, I missed the notification 😬

I would have been happy to help but I'm unfortunately not a python developer (only TS/JS here), so this would require too much investment for now, I'll instead investigate for another LRS solution in the hope one has this feature implemented.