*Attendees*

Scott Cantor, OSU
Mike Grady, U. Illinois
Tom Barton, U. Chicago
Grace Agnew, Rutgers
Fred Beshears, UC-Berkeley-IMS
Renee Frost, Internet2 Jeanette Fielden, Internet2
Steve Olshansky, Internet2

*Discussion*

Tom Barton's eduCourse Object Structure draft located at:

http://middleware.internet2.edu/courseID/docs/draft-barton-courseID-object-structure-00.html was discussed. It describes two primary object types, course and section. These are tied together with offerings, which give information about instantiating a course. For cross-listing courses there is not a single global definition of what that is, so the description is flexible to accommodate at least four different approaches and combinations of approaches.

The courses themselves can be cross-listed.
An offering can represent more than one course.
Offerings can be cross-listed.
A section can instantiate more than one offering

Time, such as semester or quarter is represented by the session ID. Consensus is the document represents a good base to build on.

Grace described the IMS Learner Information Packet (LIP). The LIP defines learning activity primarily with regard to entities such as students. Course is one learning activity. The title is incorporated in a short description the course itself is used as the explicit unique reference. It's an attempt to formulate the information found in some of the other IMS specs in a way that is structured around the learner.

Fred explained that the IMS enterprise specification is being extended with respect to how a student information system communicates roster data to a course management system. The way IMS approaches that is by adding three entities, person, membership and group. Group is used to represent courses, sections, sessions etc. Groups can contain other groups as well as persons. Currently IMS has a published enterprise specification, which deals with XML data not behaviors. The new effort underway is to specify with web services a mechanism for updating person membership. In the context of the enterprise specification the person is a very simplified entity. The LIP is for more long-term storage while the enterprise specification is concerned with just the roster. Blackboard, WebCT, PeopleSoft, SCT are or will be using the IMS Enterprise specification for co-coordinating roster information between different systems.

Currently the specification just stipulates a file format, but is moving towards defining behaviors. IMS is collaborating with OKI on this. OKI has defined a Service Interface Definition (SID) and implemented it in Java. IMS is focusing on how one specifies behaviors with web services that. The abstract frameworks define behaviors in a generic way and the java or web services represent a specific implementation of how to do that behavior.

It was agreed that it was more critical to define use cases to determine what pieces of the standards are relevant and if there are use cases requiring a schema rather than focus on defining a schema.

Global versus local identifiers: There are separate technical and business issues. The technical issue is authentication and authorization of a student, for example an OSU student taking a distance course at Berkeley. How does the student access the materials remotely, and who manages the process? The information might be maintained at both institutions. The business issue is: does the student get credit at his home institution for the remote course? The desire is to focus on the technical issue. Are global unique course ID's needed, or could a locally unique identifier suffice? Does a local identifier become a defacto global identifier when the institution name, course name, and other information is incorporated? A use case could focus on a course being team taught by instructors at two different institutions and how students at each campus would be authorized to access course resources.

Shibboleth is trying to focus on carrying attributes of users at the point of access. Course ID could focus on the problem of how to represent a particular users role in a particular course that may actually mean an offering rather than a course, which would be within the scope of Shibboleth. Roster manipulation and roster lookup would be more the domain of the enterprise spec or the schema. If the focus is not on entitlement style statements, then LIP spec might be the place to start. How would the status of the course offering be incorporated? It could be gathered through meta-directory processes and provisioned in several locations including an LDAP directory as a polymorphic representation of the information. For example if a student is enrolled in econ 101, there'll be attribute that lists the courses that student is taking, and the course identifier there may include econ 101 as well as an indication of the term and section. Any application requesting that information for authorization etc. could do so.

LIP may be the correct standard to review, but the use cases need to be defined first and then derive the requirements from them and see if the data model defined by LIP would meet those requirements.

Fred shared that IMS and ISO/SC36 are discussing a proposal to have SC36 standardize the LIP. http://jtc1sc36.org/

There was a brief discussion of the value of including competencies in the data model since there is pressure to start creating competencies based curricula and assessing courses for learning outcomes. Competencies and outcomes are also being assessed for mapping courses between institutions for equivalency. Fred brought up the growth of e-portfolios, where a student's projects/works are stored as part of the transcript. IMS has an e-portfolio group that is approaching e-portfolios as a profile of three IMS specs, LIP, meta-data, and the content packaging.

It was agreed that developing use cases is the most important issue for present.

[AI] Scott will draft a couple of uses cases starting from the existing scenarios, and send to the list for discussion.