[Building Sakai] Question regarding names

[Ray Davis]

FWIW, this is the kind of approach the Gradebook and Sections teams were 
picturing when we abstracted "display name" and "sort name" in our 
integration APIs way back when.

Best,
Ray

On 4/12/10 8:11 AM, David Haines wrote:
> 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 <mailto: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>
>> [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 <mailto: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