*Discussion*

Dirk talked about OKI-IMS. IMS (http://www.imsglobal.org) is an organization involved in setting and defining specifications for e-learning. It is a membership organization, with voting rights for a contributing membership. A development member has access to information but no voting rights. U. Wisconsin is a contributing member and Dirk is their representative. Other academic members include MIT, the CIC, Michigan, and the University of California. Among vendor members are WebCT, Blackboard, Click2Learn, Microsoft, Cisco, Oracle, etc. Currently there are about 50 member's total.

The specifications (http://www.imsglobal.org/specifications.cfm) have been primarily XML based data models. Two specifications of interest are the Enterprise and Metadata specifications.

Where have these standards been applied? The enterprise standard is one that gets used primarily between student information systems and e-learning systems. That standard defines person data and ways of moving data both directions. The content packaging standard, together with the metadata is used to define how you move content, web pages, graphics etc. in and out of these systems. QTI - question test interoperability that is meant for question banks or assessments is also under the content standard.

OKI defines API's, which will be called open service interface definitions (OSID), and currently all are java bindings. OKI is not a formal specification body, but is viewed as an entity that can contribute specifications to IMS and has been working closely with them to that effect. The area of interest is the enterprise specification, which in OKI is the class administration API. The class administration API version 0.1 is available at: http://sourceforge.net/projects/okiproject

Scope of courseID work: The driver is providing access to standardized information inter-institutionally in support of particular scenarios and use cases that are narrow enough in scope with sufficient context to be achievable. In order to support a particular scenario, agreement is needed on identifiers, identifier discoverability, and relationship to class information, (student and instructor etc). An example might be supporting course based access control through Shibboleth that works with an IMS compliant student system. Course based access control is along the lines of asserting in a Shibboleth attribute that the bearer is entitled to access a certain set of materials. Access would be for read and/or write privileges depending on the role and for a defined period of time, for example a semester. The focus should be on the structures that are useful inter-institutionally, and avoid manually entering and maintaining netid lists.

Standardization is needed even for the case of exchanges between a small group of institutions to ensure the expressions are globally unique to avoid later collisions. You want to avoid the situation where the instructor is calling the IT department at the remote institution since that's not a scalable/tractable process. The University of Florida system requires that any course created must be equivalent across all members of the system. Defining a practice to follow would be of value.

The scenarios are a good starting point and will have to be refined into use cases. Real world inter-institutional examples from the Shibboleth space would be extremely helpful for creating generic scenarios. We can compare them against what IMS-OKI is doing to see how it fits with existing standards and technologies, to avoid a model that commonly deployed systems can't interoperate with. The IMS work on naming can be leveraged as well.
[AI] Keith will follow up on the IMS work on naming and talk to Dirk about where things affect each other.

[AI] Everyone should review Tom's document http://middleware.internet2.edu/courseID/docs/draft-barton-courseID-object-structure-00.html for the next call.

[AI] Art will talk to the GSU person that handles the electronic and course reserves for the library about how it's set up and will try to get a description/scenario from that.

Scenario/use case discussion will continue on the next call Monday August 4, 2003.