“Confusion” and “names” go together rather too easily. How might we take forward the representation of names in specifications and standards?

In June I noticed some RS3G work on defining person metadata, which I took an interest in, having grappled with this for Leap2A. Then last month I discovered somewhat to my surprise that I was a co-author of the rather oddly titled “Conformance Guidelines – The Path to a pan-European Asset (final draft) By example of the natural person” from SEMIC, the Semantic Interoperability Centre Europe. This document also deals with the representation of names, though differently.

In subsequent discussion, I have been drawn in to the peculiarities of Spanish surnames (they officially must have exactly two) and how other naming systems in the world are sometimes radically different from the EU passport convention of just “surname” and “given names”, echoed by UK birth certificates, driving licences, etc. Wikipedia has an article on Arabic names, for example. One thing is clear: it is not easy, and it matters to people how their name is rendered.

The RS3G idea refers to CETIS’s HEAR work, which in turn was based on some fields from MIAP (now the Learning Records Service) Common Data Definitions. However, CDDs look like they have been quietly superseded, and what looks like the current GovTalk version of name schemas is now at the Cabinet Office site. In particular, CDDs dealt with name order by having a boolean field to show if the family name was first, to cope with e.g. some Chinese practice. This does not seem to be in the GovTalk version, and indeed doesn’t seem to have caught on more widely either. Instead, people seem to be relying on a full name field to represent the ordering of the structured name fields. Strangely, GovTalk keeps titles and suffixes with their own separate fields, rather as they are in vCard.

Most people seem to agree these days that one or more full name fields are useful, giving the name as complete as someone wants it. This full name is not necessarily a full legal name. It may have parts at the beginning or end, e.g. titles or qualifiers, and these may or may not have legal standing. Thinking of the Arabic example, it may have a full rendition of a name that will not fit in to the patterns familiar to us. It may or may not be unique.

For use in the UK or the EU, there is likely to be one field for given names or forenames, and one field for family name or surname. Obviously, this tallies with usage in birth certificates, driving licences, passports and other official documents. This may suffice where it is the official legal name is all that is required, but it leaves many questions unanswered, and for a fuller picture we need to go beyond the common ground.

The reality looks to me more like this. In our dealings with different people and different bodies, we typically have identifiers, unique to that body or to those people, and we also have names that we are known as (by people) in those contexts. These may or may not overlap, and I suspect that it is the overlap which often causes problems.

My own case is a very common case in point. When asked to give my “name”, I will usually say “Simon” or “Simon Grant” if it might appear likely that there is another Simon in the context. However, I have learned not to put my name on airline reservation forms like this, as I get questioned. They want my official name, to tie in with my passport, where my Given Names field is “Andrew Simon”. The airline is interested, not in what I am called by my friends, but in my official identity, so they can check against the passport, which in turn can be checked against police records, etc. But it’s curious, isn’t it – I could probably pass my ticket on to anyone called Andrew Grant and they would be able to fly with it, but not anyone with a different name. Perhaps they should really ask for my passport number, though that is not as easy to check at a glance. At least some people get it right: on-line purchase forms ask for my name “as on the card”, which is clear, and in other contexts the practice of context-specific names is well-established: I think of stage names, noms-de-plume, and other professional names.

The most reasonable view seems to me that every name field in a specification or standard should be at least have an explanation of the context for that name, and be adequate for representing appropriate name information for everyone whose data is to be transferred using that spec or standard. If a standard or specification deals with transferring information about people who are all likely to have EU passports, it is reasonable to specify “Surname” and “Given names” as two fields, as on a passport. If the use cases of a different spec all involve Spanish citizens, then it is reasonable to have two fields, one for the first surname and another for the second surname. It would not, however, be reasonable for such a spec to have those fields as mandatory if it was going to be used for information about people of Arabic birth.

This discussion underlines my reservations about vCard and related specs, and is vital to setting an agenda for reviving the discussions about future specifications for names.

In Leap2A, what we have done is roughly to follow MIAP’s Common Data Definitions, as mentioned above. At least that gives the option of noting whether a name is a legal name or a preferred name. But, while it may suffice for the time being, it does not look good in the long term, and I hope that whenever Leap2A next changes, in a couple of years perhaps, we will move on to something more universal.

Achievement information documents, e.g. degree certificates and transcripts, also need names. We are just finalising the draft of the EuroLMAI (European Learner Mobility Achievement Information) European Standard, which should be highly influential on technical solutions adopted for the UK HEAR (Higher Education Achievement Report). I would like to see a better approach to names for these standards. What?

Given that the scope of EuroLMAI is Europe (perhaps the EU and a little beyond) it does seem reasonable to have one field for given names and one for surname, or pair of surnames in the Spanish case, as on the standard passport or other official identity documents. But what is most important after that? Two things seem to me to be vital. First, and most important, the name by which the student appears or appeared in the institutional student records. Is this always the same as the “official” legal name? If you print out a certificate for someone of Arab birth, what is more appropriate for the name printed on the certificate? I would have thought, a name as complete as the learner wants it to be. This would point towards a full name, like the UK govtalk Person Requested Name, as long as this was agreed with the student.

The second thing that might well be useful, though less important, would be the name that the student was actually known by to teaching staff and to peers. This would be closer to the “nickname” concept in other specifications. This would be particularly useful if it was not the same as the official name(s), when seeking feedback from staff and from peers, or when following up to check things after graduation.

So perhaps a wider range of potentially useful name information could be represented in four fields. Leaving any of these out from a specification or standard seems to me to risk being unable adequately to cover the use cases of this kind of achievement document.

1. Official (passport) Given names
2. Official (passport) Surname(s)
3. Full formatted name as shown on certificates
4. Personal name known by in face-to-face interactions

These can only be represented by vCard with a strain. Surname is OK, but a single field of all given names seems different from a vcard “Given”. Full formatted name could be vCard’s “FN”, though vCard’s FN is presumably meant for the main name on a “business” card, which might well not be the same. Is the personal name indicated above the same as vCard’s “NICKNAME” or not? I don’t know. Unfortunately, there is only slightly less strain fitting these into the UK GovTalk fields.

Where do we go from here? Call me “confused”…

Addendum, 2010-08-31

By happy coincidence, Paul Heald of Sigma Systems distributed a very interesting document yesterday to various people including Scott Wilson and other colleagues. It is called “Student Identity Defined: A Comparison of the Data Elements of Four Higher-Education Standards” revised August 30th 2010. It does indeed suggest that the discussion is ready to be taken forward to another level. And I find it is helping, gradually, to relieve my confusion.