IMS Final Release

LISMembershipContainer JSON Binding
in the application/vnd.ims.lis.v2.membershipcontainer+json format

Final Release
Media Type application/vnd.ims.lis.v2.membershipcontainer+json
RDF Type http://purl.imsglobal.org/vocab/lis/v2/mm#LISMembershipContainer
JSON-LD http://purl.imsglobal.org/ctx/lis/v2/MembershipContainer

Date Issued: 24 May 2016
Latest version: http://www.imsglobal.org/lti

Abstract

A MembershipContainer defines the endpoint to which clients GET the list of Memberships associated with a a given organization, such as a course. This specification document describes a media type suitable for the response from a GET request. The response is based on the W3C Linked Data Platform recommendations.

Table of Contents

1. Introduction

The items within a MembershipContainer are paginated in accordance with the W3C Linked Data Platform recommendations. Figure 1 shows one page of items. It is the responsibility of the server to determine the maximum number of items that will be returned in each page. In this example, the number of items is artificially limited to just two items. In a typical, real-world case the number of items per page will be larger. Notice that the payload gives the URI for the next page. If there is no next page, the nextPage property will not be present.

{
  "@context" : [
    "http://purl.imsglobal.org/ctx/lis/v2/MembershipContainer",
    {
      "liss" : "http://purl.imsglobal.org/vocab/lis/v2/status#",
      "lism" : "http://purl.imsglobal.org/vocab/lis/v2/membership#"
    }
  ],
  "@type" : "Page",
  "@id" : "http://lms.example.com/sections/2923/memberships/?rlid=49566-rkk96",
  "nextPage" : "http://lms.example.com/sections/2923/memberships/?rlid=49566-rkk96&p=2",
  "differences" : "http://lms.example.com/sections/2923/memberships/?x=1422554502",
  "pageOf" : {
    "@type" : "LISMembershipContainer",
    "membershipSubject" : {
      "@type" : "Context",
      "contextId" : "2923-abc",
      "membership" : [
        {
          "status" : "liss:Active",
          "member" : {
            "@type" : "LISPerson",
            "sourcedId" : "school.edu:user",
            "userId" : "0ae836b9-7fc9-4060-006f-27b2066ac545",
            "email" : "user@school.edu",
            "familyName" : "Public",
            "name" : "Jane Q. Public",
            "image" : "http://...",
            "givenName" : "Jane"
          },
          "message" : [
            {
              "message_type" : "basic-lti-launch-request",
              "lis_result_sourcedid" : "83873872987329873264783687634",
              "ext" : {
                "user_username" : "jpublic"
              },
              "custom" : {
                "country" : "Canada",
                "user_mobile" : "123-456-7890"
              }
            }
          ],
          "role" : [
            "lism:Instructor"
          ]
        }
      ]
    }
  }
}

Figure 1.  Example JSON document containing a LISMembershipContainer object

1.1 How To Read this Document

This specification defines the structure of a JSON document using a graphical notation. In this notatation, an object is represented by a box that branches out to other boxes corresponding to the properties of that object, as shown in Figure 2.

Figure 2.  Representation of a JSON object

Each box representing a property specifies the name and type of the property , as shown in Figure 3.

Figure 3.  Graphical notation for a property

If a property is optional, its box will be decorated with a circle that contains a question mark, as shown in Figure 3.

If a property can have multiple values, then its box in the graphical notation is decorated with a circle that contains a plus sign (+) as shown in Figure 4. In this example, the membership property may reference more than one Membership object. Ordinarily, these values are encapsulated within a JSON array, but if it turns out that only one value is present, then the square brackets for the array are optional.

Figure 4.  Example of a repeatable property

An object within a JSON-LD document may have one of four possible representations:

  1. The object may be identified by a fully-qualified URI reference.
  2. The object may be identified by a Compact URI reference, known as a CURIE [CURIE-syntax], that can be expanded to a fully qualified URI
  3. The object may be identified by a simple name that is mapped to a fully-qualified URI. This mapping is defined by the JSON-LD context.
  4. The object may be embedded within the document.

When an object is to be identified by a fully-qualified URI or a CURIE, the box representing the object will be decorated with the #uri hash tag, as shown in null.

Figure 5.  Property whose value is a URI reference

When an object or enumerable value is to be identified by a simple name, the box representing the corresponding property will be decorated with the #sn hash tag, as shown in Figure 6.

Figure 6.  Property whose value is a simple name reference for an individual object or enumerable value

1.2 Reserved Terms

The JSON-LD standard reserves a handful of property names and tokens that have special meaning. These names and tokens, described below, begin with the '@' symbol.

@context
Used to reference (by URI or by value) a context which declares the simple names that appear throughout a JSON document.
@id
Used to uniquely identify things that are being described in the JSON document. The value of an @id property is either a fully-qualified URI, a CURIE, or a simple name that expands to a fully-qualified URI by virtue of the rules defined in the JSON-LD Context.

The @id property may identify a so-called blank node by using a CURIE with an underscore as the prefix. The binding of a JSON-LD document MAY include identifiers for blank nodes, but these identifiers are not required.

@type
Used to set the data type of an object or property value.

JSON-LD specifies four other reserved terms (@value, @language, @container, @list). Ordinarily, these terms are not used in the JSON binding for LISMembershipContainer objects. However, implementations that extend this specification by including additional properties may utilize these reserved terms in accordance with the rules defined by [JSON-LD-syntax].

1.3 The JSON-LD Context

In JSON-LD, a context is used to map simple names that appear in a JSON document to URI values for properties or data types in a formal vocabulary (typically an RDF ontology). For example, the standard context [LIS-v2-MembershipContainer] for a LISMembershipContainer contains the following rewrite rules (among others):

  {
    "@context" = {
      "ldp" : "http://www.w3.org/ns/ldp#",
      "membershipSubject" : "ldp:membershipSubject",
      ...
    }
  }

A context may specify that the values of certain object properties must be rendered as URI references. The following snippet presents an example of such a rule.

  {
    "@context" = {
      ...
      "status" : {
        "@id" : "org:status",
        "@type" : "@id"
      }
      ...
  }

This rule is an example of type coercion. For more details about the syntax of a JSON-LD context, see [JSON-LD-syntax].

2. The LISMembershipContainer Media Type

The following list defines the necessary and sufficient conditions for a document to conform to the application/vnd.ims.lis.v2.membershipcontainer+json media type.

  1. The document MUST be a valid JSON document, in accordance with [RFC4627].
  2. The document MUST contain either a single top-level JSON object, or an array of top-level JSON objects. The first object encountered (either the single top-level object or the first element of the array) is called the root object.
  3. The root object must have a @type property whose value is "LISMembershipContainer".
  4. Every top-level object MUST have a @context property that references one or more JSON-LD contexts (either by URI or by value).
  5. Collectively, the set of contexts imported by the root object MUST contain all of the terms found in the standard context [LIS-v2-MembershipContainer]. In particular, the set of imported contexts must contain all the simple names that appear in the standard context, and those simple names must resolve to the same values that appear in the standard context. This requirement may be satisfied by ensuring that the root object imports the standard context explicitly, or by importing a collection of other contexts that contain equivalent terms.
  6. The set of contexts imported by the root object MAY include additional terms that do not appear in the standard context [LIS-v2-MembershipContainer].
  7. Duplicate mappings for names among the imported contexts MUST be overwritten on a last-defined-overrides basis.
  8. If the JSON-LD context coerces a property to a URI reference, then values of that property MUST be expressed as a fully-qualified URI reference, or a CURIE or a simple name declared by the context.
  9. A collection property is any property whose maximum cardinality is greater than 1. Except for the @context property, a non-empty collection MUST always be represented as a JSON array whose values are enclosed in square brackets. Whereas, in general, the JSON-LD syntax specification allows a collection containing a single value to omit the square brackets, the application/vnd.ims.lis.v2.membershipcontainer+json media type requires square brackets for all non-empty collections other than the @context property.
  10. An empty collection property may be represented either by an empty array (i.e. square brackets containing no elements), or by omitting the property altogether.
  11. Like all other properties, the @id property of a given object is mandatory if the minimum cardinality of that property, as defined by this specification, is greater than zero. The @id property is optional for all other objects (even if it is not explicitly listed in the set of properties for an object). Conforming implementations SHOULD include the @id property for all addressable objects.
  12. If the @id property is mandatory, then the value MUST NOT treat the object as a blank node. In this case, the @id value MUST NOT be a CURIE with an underscore as the prefix.
  13. Every top-level object MUST contain a @type property and a @context property.
  14. An embedded object MUST contain a @type property if the object value is a subtype of the declared range of the property.
  15. Values for properties named in the standard context [LIS-v2-MembershipContainer], MUST not utilize the String Internationalization or Typed Value syntax as described in [JSON-LD-syntax].
  16. If the context does not coerce the value of an object property to a URI reference, then the object must be rendered as an embedded object.
  17. The properties of embedded objects must respect the cardinality constraints specified in the section titled JSON Data Bindings.

3. JSON Data Bindings

Figure 7 presents a complete graphical representation of the JSON binding for a LISMembershipContainer object. The subsections following this figure provide details about each object that appears in the JSON binding for a LISMembershipContainer object.

Figure 7.  Complete JSON representation of LISMembershipContainer

3.1 Agent

An agent (eg. person, group, software or physical artifact).
Figure 8.  Agent
Direct Known Subtypes:
Person, LISPerson
Property Mult Description Type
@id 0..1 The URI that identifies this Agent instance. xs:anyURI
Table 1.  Agent properties

3.2 Context

A learning context, such as a Course Section.
{
  "@type" : "Context",
  "contextId" : "2923-abc",
  "membership" : [ ... ]
}
Figure 9.  Context
Property Mult Description Type
@id 0..1 The URI that identifies this Context instance. xs:anyURI
contextId 1 A unique string provided by the tool consumer to identify the context (as passed in the context_id launch parameter). xs:normalizedString
membership * A membership entity that records the role of some Agent within this Organization. Membership
name 0..1 The organization's assigned name. xs:string
Table 2.  Context properties

3.3 LISMembershipContainer

A container that holds a collection of Membership resources.
{
  "@type" : "LISMembershipContainer",
  "membershipSubject" : { ... }
}
Figure 10.  LISMembershipContainer
Property Mult Description Type
@context 1..*

This value specifies one or more JSON-LD contexts, either by reference or by value. When multiple contexts are specified, they must be encapsulated within an array.

For most implementations, the value will be the single URI for the standard context associated with the application/vnd.ims.lis.v2.membershipcontainer+json media type. In this case, the value will be

"http://purl.imsglobal.org/ctx/lis/v2/MembershipContainer"
JSON-LD Context
@type 1 A simple name identifying the object's type. The standard context [LIS-v2-MembershipContainer] defines the following simple names that are applicable:
  • LISMembershipContainer

Implementations may use a custom JSON-LD context which defines simple names for additional types that are subtypes of LISMembershipContainer.

owl:Class
(Simple Name reference)
@id 0..1 The URI that identifies this LISMembershipContainer instance. xs:anyURI
membershipSubject 0..1 Indicates which resource is the subject for the members of the container. Context
Table 3.  LISMembershipContainer properties

3.4 LISPerson

A container for all the information about a single person.
{
  "@type" : "LISPerson",
  "sourcedId" : "school.edu:user",
  "userId" : "0ae836b9-7fc9-4060-006f-27b2066ac545",
  "email" : "user@school.edu",
  "familyName" : "Public",
  "name" : "Jane Q. Public",
  "image" : "http://...",
  "givenName" : "Jane"
}
Figure 11.  LISPerson
Property Mult Description Type
@id 0..1 The URI that identifies this LISPerson instance. xs:anyURI
sourcedId 0..1 A unique identifier for the person as provisioned by an external system such as an SIS. xs:normalizedString
userId 1 A unique identifier for the person. xs:normalizedString
email 0..1 The primary email address for the person. xs:string
familyName 0..1 The person's assigned family name. xs:string
name 0..1 The person's assigned full name (typically their first name followed by their family name separated with a space). xs:string
image 0..1 A URL to an image for the person. xs:anyURI
givenName 0..1 The person's assigned first name. xs:string
Table 4.  LISPerson properties

3.5 LISStatus

Possible status values for LIS entities.
Figure 12.  LISStatus

LISStatus instances are enumerable, and they must be referenced by a simple name. The default vocabulary of simple names for instances of the LISStatus class are listed in Table 5.

Simple Name URI / Description
Active
http://purl.imsglobal.org/vocab/lis/v2/status#Active
Deleted
http://purl.imsglobal.org/vocab/lis/v2/status#Deleted
Inactive
http://purl.imsglobal.org/vocab/lis/v2/status#Inactive
Table 5.  Known simple names for LISStatus objects

3.6 Membership

Indicates the nature of an Agent's membership within an Organization.
{
  "status" : "liss:Active",
  "member" : { ... },
  "message" : [ ... ],
  "role" : [ ... ]
}
Figure 13.  Membership
Property Mult Description Type
@id 0..1 The URI that identifies this Membership instance. xs:anyURI
status 0..1 The current status of a membership which applies to all roles. LISStatus
(Simple Name reference)
member 1 Indicates the Person (or other Agent including Organization) involved in the Membership relationship. Agent
message * A copy of any parameters which would be included in a message initiated by the person and whose value includes data specific to them. Any custom parameters are included in an element named "custom" and have the "custom_" prefix removed from their name. Similarly any extension parameters are placed in an element named "ext" and the "ext_" prefix is removed from their name. PropertyMap
role 1..* Indicates the Role that the Agent plays in a Membership relationship with an Organization. Role
(URI reference)
Table 6.  Membership properties

3.7 Organization

A collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it and can act as an Agent. Organizations are often decomposable into hierarchical structures.
Figure 14.  Organization
Direct Known Subtypes:
Context
Property Mult Description Type
@id 0..1 The URI that identifies this Organization instance. xs:anyURI
membership * A membership entity that records the role of some Agent within this Organization. Membership
name 0..1 The organization's assigned name. xs:string
Table 7.  Organization properties

3.8 Person

A container for all the information about a single person.
Figure 15.  Person
Direct Known Subtypes:
LISPerson
Property Mult Description Type
@id 0..1 The URI that identifies this Person instance. xs:anyURI
familyName 0..1 The person's assigned family name. xs:string
givenName 0..1 The person's assigned first name. xs:string
image 0..1 A URL to an image for the person. xs:anyURI
name 0..1 The person's assigned full name (typically their first name followed by their family name separated with a space). xs:string
Table 8.  Person properties

3.9 PropertyMap

An abstract class whose properties are defined by the Tool Provider and stored in the Tool Consumer. When represented in JSON-LD, the PropertyMap object typically appears as a plain-old JSON object (though it may have a custom JSON-LD context that defines the semantics for the custom properties). It is a best practice for the values in a PropertyMap to be strings. This best practice may be revised if the development community expresses a desire to support other data types in a PropertyMap.
{
  "message_type" : "basic-lti-launch-request",
  "lis_result_sourcedid" : "83873872987329873264783687634",
  "ext" : { ... },
  "custom" : { ... }
}
Figure 16.  PropertyMap

4. References

[CURIE-syntax]
Mark Birbeck, Shane McCarron. CURIE Syntax 1.0. W3C Working Group Note. 16 December 2010.
[JSON-LD-syntax]
Manu Sporny, Dave Longley, Gregg Kellogg, Markus Lanthaler, Mark Birbeck. Json-LD Syntax 1.0. 12 July 2012. W3C Working Draft.
[RFC4627]
D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). Internet RFC 4627. July 2006.

About this Document

Title: LISMembershipContainer JSON Binding in the application/vnd.ims.lis.v2.membershipcontainer+json format
Editor:Stephen Vickers (IMS Global)
Version: 2.0
Version Date: 24 May 2016
Release: Final Release
Status: IMS Final Release
Purpose: This document is made available for review and comment by the public community at large.

List of Contributors

The following list of individuals contributed to the authoring of this document:

Vikas GuptaPearsonPadraig O'hiceadhaHoughton Mifflin Harcourt
Viktor HaagD2LCharles SeveranceUniversity of Michigan
Brad HumphreyInstructureJohn TibbettsVitalsource
Greg McFallPearsonClaude VervoortCengage
Bracken MosbackerInstructureStephen VickersIMS Global Learning Consortium