Gregory Szorc's blog

Case Needs Course Data in LDAP

Have you ever stopped to think about what could happen if Case's course offerings and course enrollment information were stored in its LDAP server?

Here is a short list:

• The list of offered courses would be easily available to all
  • Anybody could write a course search tool
  • Services could automatically provision resources for each course. For example, the Case Wiki could automatically create course pages for every course. The Case Blog system could create group blogs for every course. Oracle Calendar could create groups for each course. The list goes on and on.
  • Applications needing this information would only need to access LDAP, not worry about parsing ISIS output. Which is easier? Likewise, if someone needed this information, it is much easier to query LDAP than to parse ISIS output.
• Your course enrollment would be easily accessible to services
  • Your Oracle Calendar would automatically subscribe to group calendars of courses to which you are enrolled
  • You will be automatically subscribed to a group blog for your course
  • An online course evaluation system could easily see what courses you should be able to review
  • Services can limit availability to persons enrolled in a specific course. E.g. discussion boards, wikis, software downloads, etc
• Editing your course enrollment would be much simpler. An application that interfaces with LDAP is much easier to write than one that interfaces with ISIS. Change the course registration procedure so that changes to your course enrollment are stored in LDAP and picked up by ISIS, not the other way around. Once this is done, SOLAR becomes obsolete. The student body rejoices.
• Access to course information wouldn't be limited to a very select few and thus would eliminate many bottlenecks when obtaining the information. The list of courses offered by Case isn't a secret. Why then can't we publish this list in a format that is easily readable by computers? For those who need course enrollment information, going through the LDAP is much easier than going through the Registrar and parsing whatever awful format in which the information they return is in.

I'm sure I'm missing a lot of potential uses. Feel free to add a comment to my post and list your ideas.

You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/2666 .

Be careful with the "automatically create a $FOO for every course" route. We tried that with Blackboard at first and it didn't work too well.

Problem 1: what do you use to identify courses? Subject+number is mostly stable across semesters (though there are occasional renamings like CMPS 131 -> ENGR 131). But each subject+number has one or more CRNs, which are the entities that enrollment applies to, and which are not stable across semesters for most courses.

Problem 2: cross-listings are identified in the course database only in freeform text fields or not at all. Each logical "section" of a course - i.e., the metting of a class in a certain room at a certain time - has a different CRN identifier under each of the subject+number listings of the course, and each of those CRNs has an independent enrollment list. So you create unnecessary duplicate $FOOs for cross-listings.

Problem 3: when there are multiple sections of a course, they may want to share a $FOO, or they may not. You might handle this by creating one $FOO for each section, one for each instructor (each instructor might want all their sections to share a $FOO, without sharing with the sections belonging to other instructors), and one for the whole course; then people can use the $FOOs they want and leave the rest unused. All these extra, unused $FOOs cluttering up your data store may or may not be a problem. Teaching the users that it's normal for some of their $FOOs to be used and others not would definitely be a hassle.

So our current solution with Blackboard is to not create anything automatically, but to let instructors create a Blackboard site and load in the enrollment from any of their courses. When the next semester rolls around, they have the choice of replacing the enrollment of their old site or creating a new site.

ISIS data is automatically loaded into an Oracle database updated several times per day, so the parsing problem is pretty much a non-issue for ITS projects.

All that said, my job would certainly be easier with course data in LDAP, since then I could get data about people, courses, and enrollment all from one place.

London-born rapper Sway is to be honoured at the BET Hip-Hop awards in the US...

Colombia's vice president is "baffled" by Kate Moss's success following cocaine allegations...

epxoctnh vgoyjp lhqkzgda jsmyc flctrami rusqch bkwirsg