Content Invocation protocols - Revision history

Cskamil at 16:35, 28 January 2025

2025-01-28T16:35:19Z

← Older revision		Revision as of 16:35, 28 January 2025
Line 45:		Line 45:

	=== LTI protocol ===		=== LTI protocol ===
	More detailed information can be find here: [https://cssplice.org/lti/index.html]		More detailed information can be find here: [https://cssplice.org/lti/index.html SPLICE LTI Tutorials]
	=== SPLICE protocol ===		=== SPLICE protocol ===
	More information about SPLICE Protocol can be found here: [https://docs.google.com/document/d/1X6Vx6Em67t8Vp4Vecnmc-7OblVewJJKDFIJUrvRAvdc/edit?tab=t.0#heading=h.vxcmu24ix9zg]		More information about SPLICE Protocol can be found here: [https://docs.google.com/document/d/1X6Vx6Em67t8Vp4Vecnmc-7OblVewJJKDFIJUrvRAvdc/edit?tab=t.0#heading=h.vxcmu24ix9zg SPLICE Protocol Description]

Cskamil at 16:31, 28 January 2025

2025-01-28T16:31:18Z

← Older revision		Revision as of 16:31, 28 January 2025
Line 45:		Line 45:

	=== LTI protocol ===		=== LTI protocol ===
			More detailed information can be find here: [https://cssplice.org/lti/index.html]
	=== SPLICE protocol ===		=== SPLICE protocol ===
			More information about SPLICE Protocol can be found here: [https://docs.google.com/document/d/1X6Vx6Em67t8Vp4Vecnmc-7OblVewJJKDFIJUrvRAvdc/edit?tab=t.0#heading=h.vxcmu24ix9zg]

Cskamil at 16:25, 28 January 2025

2025-01-28T16:25:59Z

← Older revision		Revision as of 16:25, 28 January 2025
Line 28:		Line 28:
	'''Request URL Format''':		'''Request URL Format''':
	<pre>		<pre>
	http~~(s)~~://<content_url>?app=<application_id> &act=<learning_object> &sub=<learning_object_step> &usr=<user> &gpr=<group> &sid=<session_id> &svc=<service_parameters> & cid=<course_id>		http\|https://<content_url>?app=<application_id> &act=<learning_object> &sub=<learning_object_step> &usr=<user> &gpr=<group> &sid=<session_id> &svc=<service_parameters> & cid=<course_id>
	</pre>		</pre>

Line 43:		Line 43:

	== 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
	* SPLICE protocol		=== LTI protocol ===
			=== SPLICE protocol ===

Cskamil at 16:17, 28 January 2025

2025-01-28T16:17:09Z

@@ Line 12: / Line 12: @@
 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 (see [[ADAPT2|ADAPT<sup>2</sup>]] [[CUMULATE protocol#Parameter Naming Conventions|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)
@@ Line 17: / Line 18: @@
 *  '''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|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>]] ==
 * LTI protocol
 * SPLICE protocol

Peterb: /* ADAPT2 protocol for user authentication and activity invocation */

2025-01-21T00:50:20Z

ADAPT2 protocol for user authentication and activity invocation

← Older revision		Revision as of 00:50, 21 January 2025
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 (see [[CUMULATE protocol#Parameter Naming Conventions\|Parameter Naming Conventions]]		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

Peterb at 00:49, 21 January 2025

2025-01-21T00:49:43Z

← Older revision		Revision as of 00:49, 21 January 2025
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 ~~supporting~~ invocation of learning content		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 [[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)

Peterb at 00:40, 21 January 2025

2025-01-21T00:40:54Z

← Older revision		Revision as of 00:40, 21 January 2025
Line 1:		Line 1:
	This page describes the content invocation protocols supported by [[ADAPT2\|ADAPT<sup>2</sup>]]		This page describes the content invocation protocols supported by [[ADAPT2\|ADAPT<sup>2</sup>]]

	== Why Content Invocation ==		== 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 ~~are~~ 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.

	== [[ADAPT2\|ADAPT<sup>2</sup>]] protocol for user authentication and activity invocation =		When [[ADAPT2\|ADAPT<sup>2</sup>]] was originally developed in 2002, it implemented its own content invocation protocol, since no other protocols supporting invocation of learning content

			== [[ADAPT2\|ADAPT<sup>2</sup>]] protocol for user authentication and activity invocation ==

	[[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. It regulates how user and resource identities is transferred from application to application via the following HTTP parameters		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
	* '''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 14:		Line 17:
	* '''act''' - id of the resource (mandatory), each application maintains its own vocabulary of resource ids		* '''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)		* '''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.

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

Peterb: /* Why Content Invocation */

2025-01-21T00:30:57Z

Why Content Invocation

← Older revision		Revision as of 00:30, 21 January 2025
Line 3:		Line 3:
	== Why Content Invocation ==		== 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 ~~and launch~~ an independent ''client system''		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 are also important to log the information about the user interaction with the tool.

	== [[ADAPT2\|ADAPT<sup>2</sup>]] protocol for user authentication and activity invocation =		== [[ADAPT2\|ADAPT<sup>2</sup>]] protocol for user authentication and activity invocation =

Peterb at 00:18, 21 January 2025

2025-01-21T00:18:55Z

← Older revision		Revision as of 00:18, 21 January 2025
Line 1:		Line 1:
	~~= Protocol for user authentication and activity~~ invocation =		This page describes the content invocation protocols supported by [[ADAPT2\|ADAPT<sup>2</sup>]]

	This protocol is adopted ~~not only by CUMULATE but~~ by ~~most of the~~ [[ADAPT2\|ADAPT<sup>2</sup>]] tools. It regulates how user and resource identities is transferred from application to application via the following HTTP parameters		== 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 and launch an independent ''client system''

			== [[ADAPT2\|ADAPT<sup>2</sup>]] protocol for user authentication and activity invocation =

			[[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. It regulates how user and resource identities is transferred from application to application via the following HTTP parameters
	* '''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)
	* '''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 [http://en.wikipedia.org/wiki/Apache_Tomcat \| Apache Tomcat] session id to last 5 characters)		* '''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 [http://en.wikipedia.org/wiki/Apache_Tomcat \| Apache Tomcat] session id to last 5 characters)
	* '''act''' - id of the resource (mandatory), each application maintains its own vocabulary of resource ids		* '''act''' - id of the resource (mandatory), each application maintains its own vocabulary of resource ids
	* '''sub''' - if resource is a collection of multiple resources/steps, then a sub-resource id is supplied (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)

			== Other Standard authentication and content invocation protocols supported by [[ADAPT2\|ADAPT<sup>2</sup>]] ==
			* LTI protocol
			* SPLICE protocol

Peterb: Created page with "= Protocol for user authentication and activity invocation = This protocol is adopted not only by CUMULATE but by most of the ADAPT² tools. It regulates..."

2025-01-20T23:54:12Z

Created page with "= Protocol for user authentication and activity invocation = This protocol is adopted not only by CUMULATE but by most of the ADAPT<sup>2</sup> tools. It regulates..."

New page

= Protocol for user authentication and activity invocation =

This protocol is adopted not only by CUMULATE but by most of the [[ADAPT2|ADAPT<sup>2</sup>]] tools. It regulates how user and resource identities is transferred from application to application via the following HTTP parameters
* '''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 [http://en.wikipedia.org/wiki/Apache_Tomcat | 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 resource is a collection of multiple resources/steps, then a sub-resource id is supplied (optional)