Belongs to the 2009-03/Leap2A specification > predicates
Some information is not really to do with portfolio practice, particularly in the PDP sense but is there to identify and give basic factual information about and contact details of, the portfolio holder, for possible use in CVs, presentations and indeed portfolios. To keep this conceptually separate, this is represented by the separate persondata element.
This information is placed only in an entry of type person. There is a parallel structure for organizational data within an entry of type organization. Student, staff, employee, etc. ids dependent on role are properly held in the activity entry they relate to.
This element is for non-relational data about a person - that person's literal attributes if you like - and belongs within a person-type entry. The most important reason for this is to ensure that information about a person is listed exactly once, rather than duplicated.
Within the person entry, any number of leap:persondata elements can appear. For example:
<leap:persondata leap:field="legal_given_name" leap:label="First name">Andrew</leap:persondata> <leap:persondata leap:field="legal_given_name" leap:label="Middle name">Simon</leap:persondata> <leap:persondata leap:field="legal_family_name">Grant</leap:persondata> <leap:persondata leap:field="preferred_given_name" leap:label="Name used">Simon</leap:persondata> <leap:persondata leap:field="email">someone@example.org</leap:persondata> <leap:persondata leap:field="mobile">+447710031657</leap:persondata> <leap:persondata leap:field="country" leap:countrycode="GBR">UK</leap:persondata> <leap:persondata leap:field="website">http://www.simongrant.org/home.html</leap:persondata> <leap:persondata leap:field="website" label="Blog">http://blogs.cetis.ac.uk/asimong/</leap:persondata> <leap:persondata leap:field="website">http://en-gb.facebook.com/people/Simon-Grant/616865170</leap:persondata> <leap:persondata leap:field="website">http://www.linkedin.com/in/asimong</leap:persondata> <leap:persondata leap:field="website">http://www.slideshare.net/asimong</leap:persondata> <leap:persondata leap:field="id" leap:service="skype">asimong</leap:persondata> <leap:persondata leap:field="id" leap:service="miap_uln">1234512345</leap:persondata> <leap:persondata leap:field="id" leap:service="http://www.bolton.ac.uk/">12345</leap:persondata>
There is one mandatory attribute and there are three optional attributes.
Each persondata element has a mandatory leap:field attribute to distinguish what the field means. The values of the leap:field attribute should normally be taken from the list below. Otherwise, for extension purposes, the value of the leap:field attribute can be a URI, identifying a non-Leap2A predicate.
Where needed, this attribute gives the service associated with the information in the field. The attribute is required if the field is "id". The attribute value may be one of the abbreviations given below for service providers that are currently in frequent use, or if the service is not listed here, it could be a URI or URL of a service provider. A service provider can be on the web, such as Google, but can also be a service that could be offline, such as MIAP, or UCAS, or an educational institution providing educational services. The value of the service attribute could also, in principle, be an internal reference to an organization, but there is no practice yet built up. In all cases where a URL is given as the attribute value, it is suggested that the one used should be the shortest that is completely associated with that id and no other id.
As elsewhere, label is an optional attribute intended to hold the version of the field name given in the originating system. However, it is mandatory where the field is "other".
This is optional, but specifically only for the "country" field, as in addresses, and no other fields.
As persondata element always have an order of occurrence in the XML, the order in which they occur is taken to be the order for display. Thus there is no need for the attribute "display_order" - indeed it could introduce confusion. If the family name is first for this person, it is recommended that, as well as including the "family_name_first" field with value "yes", family name fields are shown before the corresponding given name fields.
M is the allowed multiplicity within a single person entry.
| field | M | Attributes needed | Format | Notes | ||
|---|---|---|---|---|---|---|
full name | 0..1 | text | This is equivalent to a concatenated subset of prefix, legal given names, preferred given name, legal family name, preferred family name, suffix (given and family reversed if family name first) | . | ||
legal family name | 0..1 | text | . | |||
legal given name | 0..* | text | It is not important how these are split, except to provide a default preferred name. The order in the XML should be the same as the order in legal documents. | . | ||
preferred family name | 0..1 | text | If not present, assume legal family name is preferred | . | ||
preferred given name | 0..1 | text | Name treated as single name. If not present, assume first legal given name is preferred. | . | ||
family name first | 0..1 | Following MIAP: "yes" or "no": default = "no". | Because the default is "no", this field will not be needed for most European/American and many other names. | . | ||
name prefix | 0..1 | text | serves as honorific "title" | . | ||
name suffix | 0..1 | text | Everything after the main name parts | . | ||
country | 0..* | countrycode (optional) | Text. But, as in addresses, with an optional attribute of leap:countrycode following SIF(UK): 3-letter ISO 3166-1 code. | This may be nationality, but as the details of nationality, citizenship etc. are highly complex, it is better thought of as association with a country. More significant country connections should be listed in the XML before less significant ones. | . | |
dob | 0..1 | W3C Complete date, e.g. 1989-03-20 | If more precise format is used, any time part should be treated as insignificant. | . | ||
gender | 0..1 | Following MIAP:
"0 = not known, 1 = male, 2 = female, 9 = not specified. | . | |||
website | 0..* | URL | Any URL associated with the holder, including profiles. The order in the XML should reflect the order of importance or significance given to the URLs by the holder. | . | ||
id | 0..* | service | string | A service ID through which other people can access information about or communicate with the holder (including, e.g. IM and VOIP). | . | |
openid | 0..* | Specifically, the openid service which extends across many service providers | . | |||
|
| 0..* | e-mail: rfc2822 | If there are multiple e-mail addresses given, the preferred or default one should come first in the XML. | . | ||
homephone | 0..* | recommended format: full international, starting with + (+44 for UK) | If an exporting system attempts to replace a leading "0" in an unchecked field with "+44", the number should first be checked as a plausible UK number. | . | ||
workphone | 0..* | recommended format: full international, starting with + (+44 for UK) | . | |||
mobile | 0..* | recommended format: full international, starting with + (+44 for UK) | . | |||
minicom | 0..* | recommended format: full international, starting with + (+44 for UK) | Included because of SIF(UK) having it. | . | ||
fax | 0..* | recommended format: full international, starting with + (+44 for UK) | Surprisingly, several people still record this information. | . | ||
other | 0..* | label; your own (optional) | use the label to indicate what the field is about | Obviously, do not use this for information which could go in an existing field. You can add an attribute with your own namespace to specify for yourself. | . |
These are the ones specified for this version.
| abbreviation | service | notes |
|---|---|---|
| aim | http://www.aim.com/ | |
| icq | http://www.icq.com/ | IM etc. |
| jabber | http://www.jabber.org/ | IM |
| miap_uln | http://www.miap.gov.uk/products/uln/ | The UK MIAP Unique Learner Number |
| msn | http://www.msn.com/ | IM, VoIP, etc. |
| skype | http://www.skype.com/ | VoIP; IM |
| http://twitter.com/ | The currently fashionable micro-blogging service | |
| yahoo | http://www.yahoo.com | several services |
See leap:spatial in the 2009-03/Leap2A literals page, as addresses are applicable to events and other things as well as to people.
This part of the specification has been designed with several related things in mind, including:
