CourseID Conference Call August 30, 2004

*Attendees*
Scott Cantor, OSU
Keith Hazelton, U Wisconsin
Fred Breshears, UC – Berkeley
Michael Kruckenberg, Tufts
Barry Ribbeck, UT-HSCH
Grace Agnew, Rutgers
Bob Morgan, U. Washington
Jeanette Fielden, Internet2
Renee Frost, Internet2

*Discussion*

The revised unique course offering identifier draft can be found at: http://arch.doit.wisc.edu/keith/i2/drafts/draft-courseid-offering-unique-id-00.htm

The latest draft builds on the courseID structure and is more compact than previous versions. The draft suggests that URN’s are used to assign identifiers. Language can be added to stating that URI’s are reasonable method and MACE URN’s are another good method and all other ways are suspect.

The first scenario concerns two systems that are dynamically provisioning the course management system. How it works with multiple incoming flows requires caution. A local batch system might populate the course with a secondary system also doing provisioning. The system information that comes in an automatic feed from the student information system (SIS) may see members provided by the secondary system that it doesn’t think should be in there. The SIS would disable accounts that came in other ways because it thinks it is authoritative. Those accounts need to be flagged in some way so they will be left alone. The sentence: (membership in a course offering and/or section by including the appropriate courseid identifier as a value of the eduCourseOffering attribute. To assert one of the IMS roletypes relative to a course offering, a value of the form roleType@OfferingIdentifier would be assigned to eduCourseMember attribute. ) can be deleted or the eduCourse draft can be incorporated more in the document. The document is an appropriate place to discuss LDAP and SAML oriented methods of looking at the attribute value.

In the eduCourse data model: is there dynamic provisioning of a user into a CMS for an offering or is it not specified? The identifier can be associated with either depending on the needs of the situation. The more general the identifier is the closer it is to the IMS notion of a group.

There is an untested assertion underneath, that there are certain types of groups that have significance within higher education, and are more than just a group/list of members. Course enrollment is an important notion. Once people start thinking about how they run their courses there are all sorts of other subgroups that are significant within the context of a course.

How do you determine if level of granularity is adequate? The course offering/section was selected as a logical place that access rights and policy would apply. The rationale is that at the section level it would be possible to have different professors offering different materials. The capabilities could be extended through a local application. There is also a recursive relation on section so it can be extended to essentially create a group. The intent with granularity is flexibility.

Is there really a need to be this granular? Could just the courseID and groups suffice? In a database sense it could be enough but from a semantic perspective being in a course is not the same as being on a list. EduCourse members could be mapped into a member of group if needed.

Can the first scenario be extended to a more specific scenario where the role of instructor is not tied just to the offering but to a specific meeting/lecture within the offering? A course management system will have a primary instructor who can add N number of secondary instructors, with titles such as guest lecturer. It can be handled in two different ways. At the local level you can say it’s critical to acknowledge who is teaching each offering. Or you can say there are members with specific roles and titles based on those roles.

There is the IMS Learning design specification, which is a more fine-grained discussion of design activities for a course and different roles for the activities. It specifies what those roles are allowed to do with respect to resources associated with the course.

When designing a course are specifying roles, activities, and resources part of a pedagogy and teaching function for a course or part of the LDAP administration?

In general, it’s a matter of what tools are available and what is possible with the infrastructure you have. It helps to involve both vendors in the learning management systems environment and the infrastructure team to create coherency so it’s not painful for users to cross between different services and applications. The Signet working group is addressing ways to manage privileges.