[Building Sakai] Question regarding names

Mon Apr 12 08:11:01 PDT 2010

I worked for one company that finessed the issue of deciding what fields to sort on by creating a field used just for sorting names.  That fields wasn't displayed but would define the sort order.  This allows issues about sorting to remain independent of the displayed information.  For example, the rules for sorting names with Von / Van differ by country.  It would be hard to figure out how to sort on any version of the display names and get that universally right.  Letting installations plug in in a locally developed method to compute the sortable version of a name would let them deal with local constraints themselves. 

- Dave

David Haines
CTools Developer
Digital Media Commons
University of Michigan 
dlhaines at umich.edu

On Apr 12, 2010, at 9:12 AM, Bristow, Paul wrote:

> 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"
> _______________________________________________
> 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"
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100412/16914e66/attachment.html 