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

Posted by John Norman on
FWIW I have the following thoughts.
1. Many systems around a campus will want to maintain information about users. From the user point of view it would be nice to maintain this once and once only (I imagine publication lists, research interests, etc.). dotLRN should consider interfacing to other information stores for this information (e.g. LDAP)
2. I imagine this profile in terms of an XML document where person can have a collection of roles (student, staff, etc.) and within each role can have a set of attributes. The person will also have general attributes. The document can be read for attributes in a particular role by combination of general and role attributes. (i.e. you don't need to limit to one extended role)
3. In the UK there is a lot of emphasis on 'lifelong learning' and some thought to interfacing outside the organisation may be appropriate.
4. Lastly I see 2 distinct related 'modules' (a) gradebook, which is a place for storing marks or other outcomes of evaluation and other progress indicators a subset of which will be the exam results that count towards the final qualification and (b) portfolio, which is a place for storing work that represents output during the course 'of enduring value' (in current dSpace parlance). For a student, this may be project work of which they are proud, for faculty it may be publications or course materials.
Posted by Alfred Essa on

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

Hi John,

some comments:

1a) Though it would be really nice if students would only have to maintain the data once, how do you solve the problem of one department asking "Have you ever been on a sailing boat" vs. another "Have you ever been on a sailing vessel".
1b) We should think about storing general user data that you can usually find on an LDAP server in an LDAP server (or similar things). And this in not only something dotLRN should consider, but all of OpenACS. Now there is just a tiny culprit. Yet another system to keep running. So definitely don't make it default, just optional.

2) What is the benefit of XML document vs. using OpenACS party/permissioning system? If your main reason was portability then I'd much prefer generating the XML information when needed.

3) Definitly true. I'm not sure whether there are already mutually agreed upon DTD's out there, but this would be a good idea for using XML. Especially as it could be imported into statistical software to run analysis on the (student) data. The best thing to do would be to provide an administration interface to generate the DTD's on the fly.

Posted by John Norman on
1a) I'm not sure I understand the question - I've probably missed something
1b) From our point of view the second system may be run by someone else e.g. the Central Computing Service, but the Course Support software (dotLRN) will probably be run by us as we offer close pedagogical support as well as IT support.

2) I'm not technical enough to answer, but my mention of XML was to illustrate how I think about the problem not necessarily to suggest it is a necessary or sufficient solution

3) I don't think there is anything established yet (or likely to be in the near future) so something flexible will be essential

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.

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