CourseID Conference Call August 18th, 2003

*Attendees*
Scott Cantor, OSU
Tom Barton, U. Chicago
Grace Agnew, Rutgers
Steve Carmody, Brown
Keith Hazelton, U. Wisconsin
Fred Beshears, UC-Berkeley/IMS
David Bantz, U. Alaska
Jeanette Fielden, Internet2
Steve Olshansky, Internet2

*Discussion*
Penn state and WebAssign are upgrading to 1.1. Penn State will be sending an entitlement value to WebAssign that will be used to dynamically create new user accounts. There is a conference call around Blackboard in September that will also discuss entitlements.

Grace has not yet received a response from SIRSE and will contact Endeavor.
Endeavor has reading lists that go from a learning management site to a course reserves module. They are also marketing a direct WebCT interface.

IMS has a reading lists working group (http://imsglobal.org/rliCharter.pdf). The specification is not yet public but Fred will check on availability of a copy of the spec for review.

Use Cases for Course Identifying Attributes in Shibboleth discussion:
http://usfs2.us.ohio-state.edu/MACE/draft-cantor-courseid-usecase-00.html

Grace suggested that some specific examples would provide a compelling case for using Shibboleth instead of relying on a course management system (CMS). Her concern was that since both the CMS and Shibboleth will pull from the enrollment system that it was not clear what the advantages of using Shibboleth would be.

Steve Carmody provided a couple of examples that the enrollment system would not cover. Roles such as teaching assistant, webmaster etc. would not appear in the enrollment system. If they are handled outside the CMS system Shibboleth could play a role. A second example is: Brown has three kinds of students, those registered for credit, students auditing a class (registered but no credit), and students sitting in on a class(not registered but instructor authorized). The third category of student does not appear in the enrollment or class roster systems. A third example would be a student registering from another university that is not listed in the campus system.

Grace offered the additional example of being able to offer access to the resource on a per use basis, which would allow universities to preserve access to expensive, low use resources that they may not be able to afford under the current IP address blanket access methods. Another example might be interacting with library e-reserve systems.

The initial emphasis in creating a course identifier should be on the syntax and its uniqueness and not on articulation and business relationships involving how the identifier might be used. Flexibility and scalability for business and trust issues should be a consideration in the design created. If two entities used the identifiers they could negotiate independently how to map those to each other's institution.

There was discussion of URN's and DOI's. A URN might incorporate a DOI number. A possible strawman proposal might include a couple of different proposals for uniqueness. One might be URN:MACE:domain.ed:course:DOI . This could offer uniqueness without a third party agent. Each school can then name it's own courses and they could negotiate separately that URN:bar maps to URN:foo. IMS has a paper on DOI vs. URN that should be reviewed.

Grace will write a couple of scenarios based on Scott's use case to help illustrate where Shibboleth could be effectively utilized over a CMS. One will describe the Brown/Rutgers scenario, another will describe being able to access resources based on enrollment.

Fred has sent an email to the list with information on IMS and identifiers. The Digital Repository and Interoperability subgroup is looking at OpenURL and DOI. A handbook that discusses URN's is located at: (http://www.imsglobal.org/implementationhandbook/imsrid_handv1p0.html).
One digital library whitepaper discusses the need to be precise and consistent in how terms like identifier vs. locater vs. resolving service are defined and used. The paper is located at: http://www.imsglobal.org/DLims_white_paper_publicdraft_1.pdf.

It was agreed that building on IMS specifications would be preferable and the scenarios that courseID is intended to support should be carefully defined. The intent is not to come up with the complete Aristotelian typology. Two levels, course, the abstract catalog description, and session, a course instantiation with a start and stop time, are needed. Attributes such as credit hours, quarter, semester, class type, course site, etc are beyond the initial scope of work and will not be defined at this time though future extensibility of attributes should be enabled.