CourseID Conference Call October 27, 2003

*Attendees*
Tom Barton, U. Chicago
Keith Hazelton, U. Wisconsin
Grace Agnew, Rutgers
Karen Rosenberg, Cal State Hayward
Mark Jones UT-HSCH
Barry Ribbeck, UT-HSCH
David Banz, U. Alaska
Mike Grady, U. Illinois
Jeanette Fielden, Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2

*Discussion*

For the first CourseID deliverable the goal is just to nail down how we identify course offerings in a manner that is unique.

Barry and Mark talked about the use case Barry mailed to the list: Course Management System provisioning via Shib authX user Application: Blackboard.
The use case is for a Shibbolized version of Blackboard. Users authenticate through Shib and are authorized via manual mechanisms. Blackboard provides a mechanism, via a configuration option, where you can instantiate the user login if they’re not in the Blackboard database. If this is the first visit for the user and they can authenticate, then Blackboard will provision a user account. No course assignment is done through that mechanism. The upgraded Blackboard will have a Shib front-end function but the back end will have to be provisioned manually before courses are released to students.

With the just in time model attributes, CourseID information, would be queried and that would match or be mapped to the Blackboard system and place people in the course at first login. This would need to be checked at every subsequent login to see if they were already in the course. At the end of course users will need to be de-provisioned. A specific unique ID for that course offering in Blackboard is needed. An entitlement will need to be added to a student’s entry with specific course info that could be the CourseID from Blackboard.

It was agreed that there is a need for both CourseID and role information. The CourseID will be an attribute and role a yet to be determined entitlement. The CourseID needs to be unique but can be used in a manner defined locally. One can have different roles in different courses. Role might be packaged in an open URL that pulls the CourseID and the role together and gives access based on permissions, role and CourseID combined. The person exists separately with multiple roles. In a model the course would be an entity, the person would be an entity, and the role is related to the person not the course. The role is relative to a course. This would also support multiple roles for a single course such as instructor, student, and teaching assistant. OpenURL information is available www.sfxit.com/openurl.

Since the University of Texas knows which institution it will work with, there could be an out of band exchange of initial information on courses. The two could collaborate to come up with unique course identifier that needs to be asserted to access the course offering. When the assertion is received the identifier would be compared against the metadata store to determine what course it corresponds to in Blackboard locally.

The use case will need to convey three things: I’m entitled to this particular course offering section, in this role, and here’s the persistent identifier for me so that when I come back I can come right in.

There is typically a time factor, a duration, even with asynchronous courses. There may be no start date but a stop date that’s X amount of time after the start. There are sessions that don’t fall into fall, spring, and summer. In the entity relationship diagram, there is a box labeled session but it’s not restricted to semester, quarter, etc. The point of session is to quantify the instantiation of an offering to help distinguish it from other offerings of the course. Open Digital Rights Language (ODRL) has metadata, aimed at pay per view, and an attribute for time frame, i.e. access expires X amount of time after the clock is started by the first access of the item.

To phrase it terms of the draft it would be: URN:mace:courseID:utexas-houston:ConcreteOfferingofCourse. It could be given any local identifier, without sub-elements for section and session. It can be left to the local institution to make it unique.

In the entity relationship diagram there is an Offering ID for each offering. The Offering ID might be a compound of session id and course id. The proposal can be refined to say offering identifier and discuss different forms it might take. This would fit with possible future use of CourseID at the abstract level. The id needs to be specific at least to the offering level. Resolving the offering ID would tell you that the course is Fall 2003 course starting, ending.

There was general agreement that this is the form to use and course:session:section will be replaced with offering:section throughout the proposal. It can be acknowledged that in many places the local interpretation of offering might be course:section.

While the beginning use cases all pair the course identifier with role there can be cases down the role where a course identifier would not need an associated role. Cases might include course equivalencies and degree auditing. Keeping role and course identifier separate would not preclude those cases.

What kind of assertion structure should be used to convey the identifier the course offering and what role they are asserting?
[AI] Tom and Keith will ask on the Shibboleth design call about how a role assertion might be structured and handled.

Recommending a naming standard for course offerings would be the first deliverable for the group. This would also be an object which support for in Shibboleth would be needed.

The agenda for the next call will be vetting the draft document and discussion how to engage key stakeholders.