Forum .LRN Q&A: Re: Request for Comment: Implementing Profiles in .LRN

Collapse
Posted by Alfred Essa on
John,

I agree. This is the approach we need to look at architecturally.  What do others think?

1. Pulling SOME base profile information (at least first name, last name, and possibly student ID) from external sources into dotLRN will be part of the external authentication work.

2. The user community page (where certain profile information should be displayed) is something that needs some work as well. Adding community contributions (other than just forum postings) along with profile info is badly needed to foster what this software is all about.

Collapse
Posted by John Norman on
Carl; I agree with point 1, for point 2 I think it depends on whether you are viewing dotLRN as a standalone product or part of a university enterprise system. We generally are thinking along the lines of the following post in the IMS enterprise spec discussion area (I hope I don't get into trouble for copying this)

"Hi all,

Below are some possible use case scenarios.

Use Case Scenarios:

1. Personal Profile/Person Objects

Typically, data about people is maintained in the Enterprise systems, and is passed to the Learning Management environment. When this personal profile data changes in the Enterprise system, it needs to be updated in the Learning Management system.
(IMS Enterprise Information Model Final Specification V1.1, July 1, 2002)

Personal profile information is often maintained in either Student Information System or HR system. Other systems, such as the Learning Management System, utilize personal profile information. System may have to:
• create profile information for a student, professor, or administrator.
• update profile information for a student, professor, or administrator.
• delete a profile information for a student, professor, or administrator.
• retrieve profile information for a student, professor or administrator.
• import or export lists of students, professors and administrators.

2. Enrollment/Group data

2.1.2. Group Management
Group management processes can include data from class creation and class scheduling, and the ongoing maintenance of that data. A source system creates and maintains group information, which needs to be shared with other systems that are involved with group management functions. The flow of group management information is not necessarily one way; some data may be updated by a target system and passed back to the source system.

2.1.3. Enrollment Management
Enrollment management encompasses the initial creation of Group membership and various changes to that data over time. Examples of enrollment management include learner enrollment in courses and instructor assignment to courses.
(IMS Enterprise Information Model Final Specification V1.1, July 1, 2002)

System may have to:
• import/export list of individuals enrolled in an academic unit or member of a group.
• add or delete an individual from a group.
• send and receive notification of a change in enrollment status or group membership.

3. Student Records Information
Student records information may include performance for a course, status in an academic course of study, assessment results, etc. The definition of what constitutes a student record is mostly likely beyond the scope of the current effort. A need exists to define a mechanism for management of a student record within an institution and for transferring student records between institution.

Systems with an institution may have to:
• add information to a student record.
• modify information in a student record.
• retrieve student records (i.e. for a set of students enrolled in a particular academic unit).
• transfer student records either in part or as a whole within an institution or to other institutions.
"

The point here is that the LMS system may not contain the master record for the student, but may want to show information from the master record and may capture information that needs to trigger an update to the master record. I can't remember where MIT is on its Student Record System offhand, we don't have one yet but will almost certainly be getting one soon and will need to interface.

John, I think of dotLRN as a single tool (with specific functions) that should fit well in the smorgasbord of tools we find in use at large institutions.

An improved community page in dotLRN (the tool) will be one of the key parts of its primary functions (community building). On the other hand a place to store profile information in OpenACS (that can be used internally and synced externally using emerging standards) will be key in making dotLRN fit in at the greater workshops of the world.

All I was trying to say is that we need to improve the community pages and at the same time think about how institutional data will be used for this e.g. a student may use a nickname in classes that he does not want stored in the institutional systems (maybe the community page could use a separate  profile).

In summary:

1. The external authentication work is the first piece of the integration puzzle.
2. Profiles looks like it might be the next piece.
3. Both solutions need to be general enough to be part of OpenACS (these problems are not unique to dotLRN).
4. We need to start thinking about a grade book/portfolio