Define content and structure of Results Entity

[cliftonc]

Exchanged between LA and LMS

• Existing standards?

[cliftonc]

@hhaarsma @mcginkel any chance of moving this forward over coming days? I think best to tackle this with #16 at the same time? Let me know if I can assist. Once we have the entity I think defining the API based on it should be fairly trivial - happy to do that step in OpenAPI if you can assist with the entity definition.

[mcginkel]

Results. Actually Results and Progress for an individual

Results: Archived result in (part of) the product. Progress: Notification that progress was made on (part of) the product.

The main reason to exchange this between LA and LMS is to provide a "Status overview" in the LMS on activities in the LA. Mainly to give the teacher/mentor insight how the student is progressing and if there is a need navigate to the rigth place in the LA to get the results and progress in context.

Scale

• Atomic If the product is small (?atomic) the status and result could be for the whole product. (example: product to take a specific test or assignment). The LA can send Result messages like "Student xx, has reached 34% of progress in product EAN of LA x" or "Student xx, has completed the assignment of product EAN of LA x, result: B".
• MultiStep If the product consists of multiple steps (like a complete Learning Method that takes 10 months to finish), the progress and result is more granular. The method is probably divided into Chapter, paragraphs with exercises and theory. In this situation the progress/results are many notifications

Progress Progress is expressed in percentage of the complete process (45% means 45% of the product is done/visited etc)

Result A tricky one. If we make this too complicated, no one will even try. If we skip it we miss the opportunity to provide an overview in the LMS with navigation directly in the LA analisys. Suggestion: So we need a simple model, that displays what the LA wants, enough to trigger the teacher that the result needs analisys or that all is fine. We do not need models to calculate a "total" or "average" acurately in the LMS. We do need value and a scale to interpret the value and decide how to visualise.

Progres, Result or Both. We will use the same message type. It can contain Progres, result or both.

Granularity A message can contain the information of multiple steps. In that way the LA can buffer the notifications

push or pull Both models are possible. The LA can inform the LMS that new data is available for a student for a product or the LA sends the updates

[mcginkel]

I need to add more on steps and giving progress on parts.

[hhaarsma]

Should we compare this with the result structure in UWLR: https://viewer.edustandaard.nl/uwlr-2-2-1/bericht/992a380b-4693-48d6-9da3-8b84e042e132/Resultaatstructuur In UWLR also school information and test structure information is included in the message. But I think this should be made more generic, with Content information instead of Test information.

[niesink]

I think on that same subject a comparison to the generic results data model used in AMIGO may also be relevant, though it is currently mainly focused on (test)results, not progress. The latest public version can be found here: https://www.edustandaard.nl/standaard_afspraken/amigo/amigo-0-9/ This is the newest version I could find:

[mcginkel]

I think that both the UWLR and Amigo are far to complex for this purpose. Lets discuss