[Building Sakai] Question regarding names

Bristow, Paul PBristow at csu.edu.au
Mon Apr 12 06:12:09 PDT 2010


John,

I think in terms of storage this makes some sense. I presume any deployment can have from 1..n names - that n will not be defined for a deployment but for a user. We have 'complexities' with some systems assuming n > 1 which does not hold true for all our users. For your sorting option I guess we need to make sure the sorted field is the first field to be populated?

Equally there appears to occasionally be confusion over the correct ordering of names in different cultures. 

I'm not sure in what contexts you see the information being collected (or used) and might have an issue with your display names.

We have a  number of users who prefer not to use their official 'first' names. Some use a second (or other) name, some a contraction or derivation of their first name, there may be others. They can become quite heated about systems that insist on calling them a name to which they do not answer.

We have included a 'preferred name' where possible in our enterprise identity. I don't know if this is the same as your display name (we've had users use 'pet names' as portal display names with no link to preferred names) or if preferred name is a candidate default display name.

As far as not allowing users to overwrite...

Personally if it is necessary to stop users using distasteful, offensive, or otherwise inappropriate names I'd prefer to try policy before applying a technological lockdown.

If the issue is use of unmeaningful names to act anonymously where interactions are only identified by display name - this is a tougher issue. Do you see any way other users can link a display name back to some other identifier? Would this be something variable according to privacy options? Are there situations where anonymity is preferred - do we have alternate display names in these contexts? If so are they temporary or can they persist over a longer period?

Will a display name always be unique in a group or could there be duplicates? If so they won't be enough to unambiguously identify who did something anyway.

To get back to how the information is collected - I think if the name is user supplied at registration the user should always be able to override a default. We could hint a display name the same way we hint at site urls. If the user is self registered they're (assuming no delegated, federated, or otherwise automated proofing) effectively anonymous anyway so they are free to call themselves what they want.

If the user information is provisioned any rules for (default) display names should be applied in the integration according to an organisation's policies. Perhaps they could then be locked or any overwritten alias in a context could be resolvable back to an identity for that context.


Paul Bristow
Applications Architect
Division of Information Technology
Charles Sturt University

----------------------------------------------------
-----Original Message-----
From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of John Norman
Sent: Thursday, 8 April 2010 6:23 PM
To: i18n at collab.sakaiproject.org
Cc: sakai-dev Developers
Subject: [Building Sakai] Question regarding names

In Sakai 3 personal profile work the question of how to handle international names came up. I will summarise what I think I heard, but I have a worry that we may be trying to solve a problem that has been solved before so I am writing to tap your collective wisdom.

I *think* we concluded that the following would be sufficiently flexible and useful:
1. 'name' is required in Sakai
2. 'name' will be composed of an indefinite number of fields: name01, name02, ..., nameN - field labelling is a deployment option e.g. name 01 could be surname or family name or lastname according to local practice or it could be labelled as firstname, given name, etc.
3. one field will serve as displayname
4. displayname will be created by rules from the name fields, e.g. displayname = name02+name01 the default composition rule will also be a deployment configuration option
5. displayname can be overwritten (if allowed in the local deployment) by the user
6. for list sorting, the name fields can be given a 'sort importance' so if the local convention is to sort by familyname and familyname is the label for name02, then name02 will be given sort importance=1 and when the UI displays a sortable list, name02 will be a default field because of its sort importance. Where displayname is free-form, it will not normally be a primary sort field.
7. there will also be a link associated with a name field for help, e.g. if firstname and lastname are supplied by LDAP as read-only while displayname can be edited in Sakai, the first 2 fields will link to instructions for updating LDAP data and the displayname will link to Sakai help.

Does this make sense. Does anyone know where to look for a better idea?

TIA
John
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"


More information about the sakai-dev mailing list