Difference between revisions of "Content Invocation protocols"
(→ADAPT2 protocol for user authentication and activity invocation) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
A content invocation protocol allows two online learning systems to work together in supporting learners. With this protocol, a '''host system''', such as a learning portal, a learning management system, or a personalized learning interface) can activate an independent '''client system''' while also passing a range of important parameters to it, most importantly, information about the user and group who will work with the client system, and the user target. The target might indicate a specific activity that the client system will need to launch for the user, while the information about the user and group enables the client system to customize its interaction with the user. The information about the user and the target is also important to log the information about the user interaction with the tool. | A content invocation protocol allows two online learning systems to work together in supporting learners. With this protocol, a '''host system''', such as a learning portal, a learning management system, or a personalized learning interface) can activate an independent '''client system''' while also passing a range of important parameters to it, most importantly, information about the user and group who will work with the client system, and the user target. The target might indicate a specific activity that the client system will need to launch for the user, while the information about the user and group enables the client system to customize its interaction with the user. The information about the user and the target is also important to log the information about the user interaction with the tool. | ||
| − | When [[ADAPT2|ADAPT<sup>2</sup>]] was originally developed in 2002, it implemented its own content invocation protocol, since no other protocols | + | When [[ADAPT2|ADAPT<sup>2</sup>]] was originally developed in 2002, it implemented its own content invocation protocol, since no other protocols supported personalized invocation of external learning content at that time. As other protocols gradually evolved, an increasing volume of interactive learning objects that implemented these protocols was developed. To leverage this content, [[ADAPT2|ADAPT<sup>2</sup>]] components now support other content invocation protocols. |
== [[ADAPT2|ADAPT<sup>2</sup>]] protocol for user authentication and activity invocation == | == [[ADAPT2|ADAPT<sup>2</sup>]] protocol for user authentication and activity invocation == | ||
| Line 11: | Line 11: | ||
[[ADAPT2|ADAPT<sup>2</sup>]] content invocation protocol is the "native" protocol of [[ADAPT2|ADAPT<sup>2</sup>]] infrastructure. | [[ADAPT2|ADAPT<sup>2</sup>]] content invocation protocol is the "native" protocol of [[ADAPT2|ADAPT<sup>2</sup>]] infrastructure. | ||
This protocol is adopted by all [[ADAPT2|ADAPT<sup>2</sup>]] tools developed by our teams and by many content servers developers by our collaborators. | This protocol is adopted by all [[ADAPT2|ADAPT<sup>2</sup>]] tools developed by our teams and by many content servers developers by our collaborators. | ||
| − | It regulates how user and resource identities is transferred from application to application via the following HTTP parameters | + | It regulates how user and resource identities is transferred from application to application via the following HTTP parameters (see [[ADAPT2|ADAPT<sup>2</sup>]] [[CUMULATE protocol#Parameter Naming Conventions|Parameter Naming Conventions]]) |
* '''usr''' - user identifier, usually login (mandatory) | * '''usr''' - user identifier, usually login (mandatory) | ||
* '''grp''' - group identifier (mandatory), just like a user identifier, but for a group of users (class, research team) | * '''grp''' - group identifier (mandatory), just like a user identifier, but for a group of users (class, research team) | ||
| Line 18: | Line 18: | ||
* '''sub''' - if a resource is a collection of multiple resources/steps, then a sub-resource id is supplied to call a specific sub-resource or step (optional) | * '''sub''' - if a resource is a collection of multiple resources/steps, then a sub-resource id is supplied to call a specific sub-resource or step (optional) | ||
| − | [[ADAPT2|ADAPT<sup>2</sup>]] content invocation protocol is "stackable". It could be used by a learning portal to call a specific learning object for the user to work with, but can be also used to call a specific personalized service or shell to assist the user. By receiving information about the user, the service could call a specific learning content for this user, passing down the same parameters. | + | [[ADAPT2|ADAPT<sup>2</sup>]] content invocation protocol is "stackable". It could be used by a learning portal to call a specific learning object for the user to work with, but can be also used to call a specific personalized service or shell to assist the user. By receiving information about the user, the service could call a specific learning content for this user, passing down the same parameters. |
== Other Standard authentication and content invocation protocols supported by [[ADAPT2|ADAPT<sup>2</sup>]] == | == Other Standard authentication and content invocation protocols supported by [[ADAPT2|ADAPT<sup>2</sup>]] == | ||
* LTI protocol | * LTI protocol | ||
* SPLICE protocol | * SPLICE protocol | ||
Latest revision as of 00:50, 21 January 2025
This page describes the content invocation protocols supported by ADAPT2
Why Content Invocation?
A content invocation protocol allows two online learning systems to work together in supporting learners. With this protocol, a host system, such as a learning portal, a learning management system, or a personalized learning interface) can activate an independent client system while also passing a range of important parameters to it, most importantly, information about the user and group who will work with the client system, and the user target. The target might indicate a specific activity that the client system will need to launch for the user, while the information about the user and group enables the client system to customize its interaction with the user. The information about the user and the target is also important to log the information about the user interaction with the tool.
When ADAPT2 was originally developed in 2002, it implemented its own content invocation protocol, since no other protocols supported personalized invocation of external learning content at that time. As other protocols gradually evolved, an increasing volume of interactive learning objects that implemented these protocols was developed. To leverage this content, ADAPT2 components now support other content invocation protocols.
ADAPT2 protocol for user authentication and activity invocation
ADAPT2 content invocation protocol is the "native" protocol of ADAPT2 infrastructure. This protocol is adopted by all ADAPT2 tools developed by our teams and by many content servers developers by our collaborators. It regulates how user and resource identities is transferred from application to application via the following HTTP parameters (see ADAPT2 Parameter Naming Conventions)
- usr - user identifier, usually login (mandatory)
- grp - group identifier (mandatory), just like a user identifier, but for a group of users (class, research team)
- sid - session identifier (optional), usually 5 character string each application makes a choice whether and how to come up with this parameter (e.g. truncate | Apache Tomcat session id to last 5 characters)
- act - id of the resource (mandatory), each application maintains its own vocabulary of resource ids
- sub - if a resource is a collection of multiple resources/steps, then a sub-resource id is supplied to call a specific sub-resource or step (optional)
ADAPT2 content invocation protocol is "stackable". It could be used by a learning portal to call a specific learning object for the user to work with, but can be also used to call a specific personalized service or shell to assist the user. By receiving information about the user, the service could call a specific learning content for this user, passing down the same parameters.
Other Standard authentication and content invocation protocols supported by ADAPT2
- LTI protocol
- SPLICE protocol
