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

We invite the community's comments for implementing user profiles in .LRN. The following document outlines a possible conceptual approach:

Profiles RFC

We don't want to proceed too far with the "Photobook Proposal" until we have had the opportunity to think through how profiles should be implemented in .LRN. We welcome your feedback.

Posted by Jun Yamog on
Hi Al,

Can a user have 2 or more extended profiles at one time?  Probably not, but I am just making sure.

What happens on if a user is student and becomes a faculty or other extended profile.  What happens on the older extended profiles.  Are they discarded or kept for historical purposes?

Posted by Alfred Essa on

Good questions. There are definitely instances in which a user belongs to more than constituency simultaneously (e.g. faculty, staff). It can also be argued that students are simultaneously students and alumni. It would be nice if there were a way to accomodate that. But I think for purposes of simplification we can live with one extended profile per user corresponding to their primary constituency. When a status changes (e.g. student graduates and becomes an alum), then we would have some procedure to move relevant overlapping attributes.

Posted by Jun Yamog on
Hi Al,

Having 2 or more extended profiles should be ok and can be done.  Its just a matter of having 1 (base profile) to many (extended profile) mapping.

When the user moves from one extended profile to another we would not care what his/her old attributes are?  For example a student has hair color attribute, he/she graduates and alumni does not have hair color attribute.  We discard this info?  So there is no need for us to know what hair color a particular alumni had when he/she was a student?

Posted by Malte Sussdorff on
I'd say depending on where a user signs up or what status he has he could fill out an extended profile. When a status is changed, only the information of the current profile, or the profile the viewer has access to will be displayed (e.g. if a student is working as a teaching assistant he'd be a student as well as a member of staff. If a student wants to find out about him, he'd only see the student details, if it is a staff member it would see the staff details and if the viewer is both, he'd see both information).

How about internationlisation of these profiles? Let's assume you ask "What is your haircolour" in the faculty, but the german department wants to know "Was ist Deine Haarfarbe ?". Are these two different questions or are they the same ?

Talking about different questions. Will there be a set of fixed questions the departments could choose from? Or can every department come up with their own questions as well. If the latter is the case, what happens if department A is asking "Do you like apples" and department B is asking "Do you like apples as well?".
These questions are the same with regards to the likely answer. But how do you make the correlation.

Last but not least, if you detect (by whatever means) that a question is identical to a question the user already has answered, should this answer be displayed for him, should he be able to change it and if he changes it should it only be changed for this profile or for all profiles where the question comes up.

Displaying of information. To what degree can a user decide what information should be displayed to whom? Not that it would really matter technically, but it might complicate the UI considerably :).

Two questions:

Would grades and evaluations be subject to integration into a "Student Profile"?

Can someone give me an update/timeline on Complex Survey?

Posted by Jarkko Laine on
I would also be interested in the evaluation features. An institute at my home university in Finland is willing to test dotLRN but what they most urgently need is a replacement for their old "essay handler", which means that students or groups of many students return their assignments through dotLRN and then get grades and feedback for their works. The system should also provide the lecturers means of keeping account of grades of (possibly) multiple assignments per student per class.

I read about features that I thought would correspond to these from dotLRN documentation but they were quite general and I didn't quite find an example of how this functionality is used in practise.

Posted by Malte Sussdorff on
For my class I did a terrible hack on ACES, which might actually still work with dotLRN (read: the method used). I used the file storage, added general comment facility to the page where you could view details about a file and added the rating system from Lars / AD to it. Completely ugly, but it worked for me.

Other then that I think some people are working on adding grading functionality to the survey module (though I'd prefer it to be seperate, so you can grade files as well). I think the idea is to add it to the curriculum module as well. And last but not least we have a testing module running for one of our clients, which probably needs some cleanup before beeing useful and only supports something like "passed" and "not passed".

But I would refrain from storing this information with the user profiles as talked about here, because we'd have more grades per user and role. It would be different if every class used it's own user profile (which you can think about), but I'd say keeping it seperate is a better way. And makes it easier to intergrate with SCORM (at least the way I envision handling the user profiles 😊).

Posted by Dave Bauer on
Malte, do you have any links to SCORM standards we can refer to for grading?
I have seen some nice grading features in an ACES system (, which stored evaluation info on tests, projects, assignments, and attendance. There is not yet anything like it in dotLRN (just yet).

Obviously evaluation is essential to learning and we need to get general infrastructure for this into dotLRN. Malte, considering SCORM it might be best if grading/evaluation was an independent project (independent of User Profiles), but I just wanted to mention it to see if we could somehow slip it in here (sometimes User Profiles can play an important part of evaluation as well -> participation).

Jarkko, although it is probably quite early for them make sure to remind your home institute about the main advantage of open source: user driven development. We (MIT Sloan and Heidelberg) are looking forward to other institutional partners jumping aboard and having a general evaluation package built would be a delightful way to join us (smile).

Posted by Malte Sussdorff on
Okay, SCORM only defines the way the grading information should pass between the LMS (dotLRN) and the SCO's (learning objects). For grading itself they direct to the IMS standards.

The latest SCORM definition can be found at but be warned. It is HUGE :).

Posted by Alfred Essa on

Grades and evaluations would not be part of the student profile as it is intended here. It's definite worth doing and thinking about. Terminologically, I would make that part of a student's "Portfolio".

Posted by Janine Ohmer on
A few thoughts:

Adding to the information we collect about a user is a common thing to do in OpenACS, so I think the Base Profile probably belongs there.

It seems to me that a student who is looking up info on their TA would like to see their staff profile, not their student profile.  So what I would suggest is allowing multiple profiles and displaying them all when a user goes to look at another user's profile.

This could get really tricky, though - what if a student TAs for more than one department and has different office location and hours for each? Then we'd want them to have two Staff profiles as well as a Student profile.  I think for the purposes of getting the thing done quickly one profile per user is probably good enough for now, but it should be written with having multiple, even unlimited profiles in mind for later implementation.

There are really two possible restrictions on each field in a profile - is the user required to enter it, and can they keep it private (which means only admins can see it)?  The admin UI for specifying the list of attributes in each profile will need to allow the admin to mark fields as mandatory and/or suppressable.

A really spiffy search facility would let you choose which types of profile to search, and then let you specify values to search for in particular fields.  But, and this is a big but, this is where having the profiles split between OpenACS and dotLRN is a problem.  dotLRN can reach down into the base profile in OpenACS and include it in a sophisticated search, but OpenACS will need it's own profile search facility for the times when dotLRN is not installed.  I don't like this, since it's duplicate code, but I don't see a good way around it at the moment.

Ok, that's all I can think of - time to go walk the dog. :)

Being able to have more than one profile per user seems essential to this RFC.

I would be very interested in the permissions that would be involved in the Profiles Package as proposed. Will it be possible to give specific people rights on specific kinds of profiles?

Would it be possible to use the package to implement a faculty and staff directory that could be kept up to date by a central office or departmental offices?

If this is the case, another thing that would interest me is if an export mechanism is planned (could it be used to export certain profiles for printing-> CMS for a directory publication process?)

Posted by Rafael Calvo on
I would like dotLRN to eventually be an Adaptive Learning Environment (or what I prefer to call a Intelligent LMS). An ILMS would change the way it presents its courses based on the information it has about the student. The student profile is then a key issue here.

Maybe the scope Al is looking at at this stage is smaller, but I think this issue should be looked at, it could give dotLRN a huge competitive difference with every other LMS. I think that the architecture of this user-profile package will have a huge impact on how we (at least in my group) can progress on this.

The base - extended - local architecture is a first step. I think that "courses" will also want to extend the user model. For example, if I have a course on OpenACS, I could first ask (or formally assess) if the student knows about PLSQL, TCL and other requirements. If he does, Those "modules" (or learning objects) could be skipped.

Another example (or use case), if a student finds it easier to learn by listening to video (and it is available) how do we highlight it over the text, so he uses it. If he prefers text (e.g. he is not native speaker and finds hard to understand spoken English), how do we use that to improve his learning experience?

Another example, if a profesor wants to motivate students to participate in the bboards, and he finds that some topics are more interesting to some groups than others, how can we customize the course to highlight those subtopics?

A lot of the student model can be "learned", by gathering information about what he reads and does in the ILMS. This is where the automatic document classification system -that I posted about a few days ago- comes in.

An introduction to adaptive learning environments is in:

Posted by Malte Sussdorff on
Hello Rafael,

I'd not use user profiles as requested in this case to ask for the students knowledge. Have him give the sources of his knowledge and make a judgement based on this. Within an university this is easy, as you could see which classes he has already visited and what grade he got there (so here we are touching the sequencing that SCORM 1.3 is so big about, especially if we look how good a student succeeded in an objective (e.g. learn PL/SQL)).

If you ask for  the bboards, you could have a linking structure within dotLRN like Sharenet does. Say we have a special portlet "interesting things" for a class and the professor has admin priviliges. Now her surfs the website and as he has priviliges in at least one of these portlets, he'd see a link at the button saying "add to favourites portlet". If he has more than one, then he gets to a second page allowing him to select where to add this one to. Using quicklinks with the object_id you could link to any content you want.

But wouldn't it be a good idea to have a more general approach maybe using Workflow and AI methods. My idea here would be that the workflow module supports knowledge flows. Say, if the student has read about TCL and read about PL/SQL, suggest him to read up on OpenACS. As it might be tedious to generate all this links manually, using artificial intelligence methods you could train your AI system by feeding it the learning flow of students (plainly: what objects did a student look at and for how long) along with the ideas of the professor how it should work. Taking in account the results of how the students scored you could create "best learning flows" for certain student types. How could you agregate these student types? If you have enough data on the students themself already you could probably use statistical methods. But if students come fresh to the learning organization the LO probably does not have enough information for grouping the students together in learning types. So an introductionary psychological test might be in order. But I'm heading of the topic here 😊.

Though I'm not sure Al has thought about this, it should be fairly easy to achieve the permissioning on top of it. It is just an issue of how you make the UI, so you could not only decide who get's to view what part of your profile, but also who is able to edit it. Maybe use the one we have with Wimpy Point. Talking about it, is a permissioning system, telling who get's to view what profile, part of this RFC? If not, it better should be, at least in most countries of the world.
I dislike to further divert the attention from Al's original post, which was about implementing user profiles in dotLRN. But the subject of LMSs has been brought up and since Polyxena has sort of kidnapped this concept for the Curriculum project I ought to explain what it means to us. When we use the concept of LMS (learning management system) we refer to branched sequencing of learning activities in a course or curriculum, nothing more and nothing less. And this has nothing (directly) to do with user profiles.

However, the Curriculum package that is to offer a full-fledged LMS, meaning a fully IMS-compliant simple sequencing architecture, has something to do with the grading functionality being developed for Survey, as Malte points out. This "something" is that Curriculum might want to get hold of the grading data offered by Survey (or a separate grading service, as Malte prefers), using service contracts. However, this just makes Curriculum a grading service client among others, not a grading service provider.

And Al is saying that even grades are not part of his current discussion of student profiles, so...

I posted this because I worry that if we start to call dotLRN as a whole an LMS, as opposed to its current definition as a course management system (CMS?!), people will be quite confused. Especially when trying to get an idea of what the Curriculum project is all about. At least now you all know what we mean by LMS in our texts: we use the concept to describe a learning-sequencing engine, not an entire vertical application for administration of education. I’m not saying our definition is objectively correct, though.

Before I lay out my thoughts on this thread, let me first apologize to the community for being MIA for so long. My family and I have been through a pretty unbelievable string of calamaties recently and they have kept me preoccupied. As the chair of the User Advisory Board (which I haven't had time to announce or form yet), it was certainly not my intention to check out for so long. I am slowly catching up on both private emails and public posts and, assuming nothing else horrendous happens, should be back up to speed within a few weeks.

Now, a few points...

On the subject of how all-encompassing the profiles should be, I think there's a balance to be struck. On the one hand, focus is important if we want to get things built. I think Al's decision to leave off grades, etc., and to make even the core profile functionality somewhat modular, is a good approach. On the other hand, though, we want to keep an eye toward future growth and integration. It would be worth looking at the IMS "Learner Information Packaging Information Model Specification" (though you have to worry about any standard that was created by an organization that could think up such a hideously convoluted name):

Much of this specification is concerned with the larger problem of tracking transcripts, CV's, etc. However, if it turns out that what we need for profiles is a subset of the info in the spec, then we should look at the data structure of the XML schema and think about ways to make future compatibility easier.

Regarding UI, permissions, etc., I'm envisioning 3 components. The first component is the underlying data structure, i.e., what are all the fields that can be included in a profile. We want to make this flexible in the sense that people can add new fields as-needed but construct it so that it discourages the creation of overlapping or redundant fields. (Use of a standards-based schema would help in this regard.)

The second component I see is a profile builder, in which an admin (for a class? for a site?) could essentially construct a form by choosing from the fields available in the schema, deciding whether they are mandatory or optional, and deciding whether users have the right to hide each field from public viewing. (Saving the profile form as a template would also be big plus here, as would the ability for the site-wide admin to allow or disallow class/community admins to customize the templates provided.) The third component would generate the actual profile input page for the learners and create the individual's acutal profile.

On the topic of the term "LMS," it has very specific usage in the industry which is different then pretty much everyone here is using it. An LMS is generally meant to be something like an online registrar, displaying course catalogs, enabling registration for courses, and tracking results. (In a self-paced environment, the LMS will also launch courses and enable those courses to store and retrieve relevant info about the learner, e.g., where s/he last left off in the course, whether she took the pre-test, etc. This last piece is specifically what SCORM and AICC were both designed to facilitate.) If it doesn't have a course catalog, self-service course registration, some kind of transcript functionality, and some level of SCORM and/or AICC compliance, it ain't what anyone outside of the dotLRN community would call an LMS. As far as I know, nobody within the community has articulated immediate plans to build a real LMS into dotLRN (which is a big problem).

Regarding the adaptive learning stuff, I've been working with adaptive learning quite a bit in the last six months and I honestly have to advise that the community goes into this slowly. The hardest part of adaptive learning is coming up with a decent instructional design methodology and a set of course-writing tricks that make it possible to produce adaptive content that is acutally useful to the learner at reasonable time and cost. It's hard problem, and I don't have a lot of faith that the solution to it is likely to come from a standards body like the IMS. I may have some implementation examples that I'll be able to share with the community six or nine months down the road, but really, we have more fundamental problems to lick first. This is not to discourage Polyxena in any way, shape, or form, from experimenting and leading the charge. Adaptive learning is an important area of online learning where innovation would be welcome. I just don't think that that implementing adaptive learning should be high on the *community's* list of short-term needs.

Posted by Rafael Calvo on
Welcome back Michael, we missed you 😊

Regarding the IMS leaner specification, I agree with you and the user profile should try to use as much (if not all) of it and be designed so when this standard is extended the same happens with the user-profile. How about making the "base profile" the same?

Regarding the LMS definition, we obviously have a bit of a variance there 😉, I have never worried to much about nailing a proper one, but now I see that it might be more important than I thought, because people need in order to define scopes. That should probably be another thread, but I agree with the "registrar" definition, but I normally include the content management and teh assessment tools, and sometimes even the student portals. Otherwise wouln't we putting WebCT and Blackboard (dotLRN main competitors) out of scope?
We have not looked at a course catalog, but someone (Ernie) in my group will be looking at learning objects catalog, so it should be similar, but with another granularity.

Regarding the adaptive learning issue, I agree that is not a short term project (for dotlrn-1-1) but is something that we should have in the long term scope. As you know I am looking to dotLRN as platform for research, not only development, and adaptive learning environments is a great topic, but of course with enormous difficulties.

Michael, whether you are actually saying this or not, I get the feeling that you are saying: "Curriculum is not so important that it is worth implementing right away; nevertheless it is so important that it demands several months of further research." This conclusion actually makes sense if we presuppose (1) that the users and promoters of dotLRN have displayed no interest in Curriculum's functionalities and (2) that the technical solution of these functionalities will affect the very foundation of the groupware, because it demands a dotLRN that is an LMS.

Both of these presuppositions, and thereby the conclusion derived from them, are wrong. In fact, there is a clearly confirmed interest in implementing branched sequencing of learning activities; and the implementation of this service, though not a piece of cake, will not affect any core service of OpenACS. Hence, I believe you're overestimating the technical influence of Curriculum on OpenACS and dotLRN, while underestimating its importance to the users. I'm quite sure that by claiming (following IMS terminology) that we are developing an LMS (alternatively LTS, learning technology system, in IMS talk), we have tricked you and others into this belief. If that is the case, it's our fault.

You're absolutely right when you say that IMS specifications are not likely to provide us with any sort of guidance to usability. Even IMS agree with that. As the IMS Simple Sequencing Specification makes perfectly clear: "The nature of the control and communication interfaces, and the mechanisms for mediating interactions between the a learner and a LTS, are not part of this Specification. In addition, issues such as look and feel, presentation style, and placement of navigation controls are not defined by this Specification." These are matters that the community and other vendors will be able to develop to their liking as soon as the basic structure is implemented. And I have great confidence that six or nine months down the road, you'll bring the implementation to new levels of perfection. You’re certainly the community’s expert in this field.

I'm kind of curious to know where your skepticism toward IMS comes from. I don't know what it is you expect IMS to solve for you, which they have failed to do, that has made you disappointed in them. Their Simple Sequencing Specification certainly provides us with the architectural blueprint we seek for our purposes. And as even NATO's ADL SCORM turn to IMS for standards, I can picture us doing the same. Whether or not IMS is a complete and satisfying authority for turning dotLRN into an LMS (as the industry defines the term) I have not the slightest idea, and will gladly leave that analysis to those who are actually working on such a task.

At any rate, the implementation of Curriculum does not affect the question of user profiles.

Staffan, I'm moving the discussion of adaptive learning (including my reply to your post) over to this thread:

That way we can continue without cluttering up Al's request for comment here.

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