tilmann,
i created profile-provider to allow presentation of profile information about a user, in the community-member page for example, without knowing intimate details about who is providing profile data. that way we can make the community-member page a lot better by just having it defer presentation of package specific data, say forums or dotlrn, to that package. right now all that data is either very generic, from the acs_objects table, or we have to stick knowledge of the application in the community-member page which is very bad.
so all this is well and good except it's not being used anywhere yet and therefore the contract itself has not been developed. right now it only has a few operations that are probably broken, that is they probably need to have different set of arguments, and probably more operations are needed.
dotlrn user types are profiled_groups (not regular groups). profiled_groups are simply groups that are associated with an implementation of the profile-provider contract. so "professors," "students," "admins," etc all implement the profile-provider contract, they are just not doing anything with it right now.
user-profile is only an extension of the membership_rel so that we know which rels have a profile-provider associated with them.
it would be nice to start using this so it can be finished and used appropriately or determine whether this stuff is useless and needs to be pulled out.
if it turns out that this is the proper way to do this it should probably go in the OpenACS core.
