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.

Jun,

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.

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 :).

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.

Malte, do you have any links to SCORM standards we can refer to for grading?

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 http://www.adlnet.org/index.cfm?fuseaction=rcdetails&libid=496&cfid=362887&cftoken=94304883 but be warned. It is HUGE :).

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. :)

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:
http://www.stemnet.nf.ca/~elmurphy/emurphy/ale.html

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.

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):

http://www.imsproject.org/profiles/lipinfo01.html

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.

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.

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.

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.

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.

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