Tom Barton, University of Chicago

EduCourse
http://middleware.internet2.edu/courseid/docs/draft-internet2-courseID-eduCourse-01.html. There is a need for a model to identify relationships to a course in a standard way so course relationships can be shared across institutions. One proposed model is eduCourse. In this model, Course is the abstract description in a course catalog. Offering is a temporal, such as fall semester, instance of a course. Section is an instance of an offering, such as a lab or a lecture. Member represents a person connected to a section in one of several capacities.

The attributes of the object classes are intentionally vague. The intent is not to exactly specify what should be there but to sketch it. Attributes are not constrained to use in an LDAP directory.

There are two uses of the term eduCourse. One is as an adjective, eduCourse Offering, an instance of the object class. The other is a prefix or suffix to refer to an aspect of the model, eduCourseoffering. This is an attribute whose values are identifiers of eduCourse offering or section objects. The values are URIs. For using URI’s, the IMS specification is 32 characters for URI, so there is an issue with needing longer strings.

There are two different scenarios that are representative. One is that there may be sub-groups of the class that are identified for the term, projects, teams etc. The other is different instructors for a session, guest lecturers etc.

The roleType is the member’s function within an offering or section. The values of roleType are from the IMS Membership Management Services Information Model,

Q: Directory enabled applications understanding this would be complex. Is there a practical use for this Practical use of this?
A: This is relational data. It could be the best context, rather than LDAP, to deal with such data. For each section you could have 8 groups, one for each of the IMS roleTypes.

Keith Hazelton, University of Wisconsin
Globally Unique Identifiers for Course Offerings
http://arch.doit.wisc.edu/keith/i2/drafts/draft-courseid-offering-unique-id-01.htm
The draft is focused on identifiers for course offerings. The value for eduCourse offerings and sections need to be URI’s. Section 3 outlines the proposed solution.

“Any properly constructed Universal Resource Identifier (URI) will have the property of global uniqueness. The CourseID WG recommends that URIs be used as identifiers for course offerings (and sections within them, if these need to be given distinct identity). This recommendation specifically includes both the familiar URLs as well as URNs and Digital Object Identifiers (DOIs) in their proposed URI format. This recommendation achieves uniqueness of identifiers and a defined syntax while placing minimal constraints on creators of such identifiers.”

CourseID is not a position to tell the learning community how to build these things. Active discussions are going on internationally in organizations such as CETIS (http://www.cetis.ac.uk/ ) that also participate in the IMS.

Brendan Bellina, Notre Dame
EduPerson Domain Survey
The eduPerson domain survey sent out last fall, received 23 responses from national and international institutions. The survey results were complied into a white paper located at: http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-localdomainperson-01.html

There were some interesting discoveries in the responses. Authentication is what most people are using eduPerson for, with about half using it for authorization as well. It is not clear why others are either stalling out using it for authorization or choosing to do something else for authorization.

Privacy is a hot topic. More than half have some kind of privacy attribute set up.

Most often these attributes indicate whether an entry is visible publicly, visible only to affiliates of the institution, or not visible at all. In some cases only specific attributes, such as phone, address, and email address, are restricted, in other cases all attributes are restricted. How the attribute is implemented, or if self-service of the attribute by the user was enabled was not asked, but would make good follow-up questions.

Part of goal of survey was to see if anything was so common it should be added to eduPerson. There was not anything identifiable as needing to be added. The eduPerson affiliation is being used heavily.

In conducting a follow-up survey to gain more information on how implementation is being accomplished there is a desire to expand the size of the respondent pool in addition to getting more detailed information.

There are plans for another document that contains information about what people are actually using in their global object classes, and possibly guidelines recommended by MACE-dir on what people should consider in standing up a directory.

Bob Morgan, University of Washington
Abstract Information Models
The interest is in how attributes could be used in attribute assertions in the Shibboleth context and the directory context. Scoped attributes are attributes with the @ sign contained in them. The scope is an XML attribute on the SAML attribute valued element.

Shibboleth relies on the XML-based SAML standard for attribute assertions. There are two attribute types Shibboleth supports: simple, a plain string, and scoped, which includes a Scope attribute in the XML assertion. The @ sign is used as the relationship delimiter. This means there can be two different representations of the same data, based on the schema being transmitted.