4. Data attributes available
The CUD attribute set (CAS) comprises a list of attributes which are available by default to all registered users of CUD for all person records in CUD. Some attributes in the CAS are consolidated values from multiple sources, others are single values taken from a single source
Additional attributes, not included in the CAS are available on application. You must have a good reason for using additional attributes, access to which will be considered in consultation with the data owner.
The following table shows additional consolidated attributes:
The following table shows all attributes, their source and whether they are included in the CAS.
Please use the following email template to request access to additional attributes replacing elements in <> with your details:
SSO username/service principal nameis the name of the login which requires access to the additional attributes. In the CUD UI this will be an SSO username. For other interfaces this will be the kerberos service principal name granted which has already been granted access to CUD, normally in the form cud/<host fqdn>@OX.AC.UK
Additional attributes requestedis the list of name of the additional requested, taken from the complete list of attributes
ITSSshould be answered Y/N depending on whether you appear in the ITSS register
Reason for accessis required whether or not you are ITSS
In addition to attributes, CUD stores affiliations, which reflect the relationship of a person with the University.
CUD models an unlimited number of as affiliations with the following components:
- Status (coarse grained)
- Start date
- End date
- Date last updated
Primary data systems have different status codes and different codes/acronyms for units
Status codes are stored “as-is” and not decoded, is there is no status it is stored as “unknown”
Unit codes are stored as received from the primary data system, but an attempt is also made to map them to a common acronym and name, so a single affiliation (from University Card) is stored in different forms:
- MC@Computing Services
CUD exposes affiliations in the form current_affiliations for convenience. It lists units with which a person has a current affiliation from any source
- Status is not listed
- Start, end and last updated dates not exposed
- Easy to search
- Easy to consume
CUD also exposes affiliations in the form scoped_affiliation where additional data is required. This includes all data held for an affiliation
- For “flat” format (e.g. a CSV) the elements are concatenated with ; delimiters
- Where there are multiple affiliations this can become difficult to process!
- For “structured” formats elements are in a defined structure and so easier to process
- Scoped_affiliation includes past, current, and (potentially) future affiliations
Affiliations can be considered part of the CAS, since all registered CUD users are able to view them. In many cases start and end dates not specifically included in the CAS are available as a component of an affiliation.
CUD supports the following data formats on interfaces:
Person records can be constructed with as “flat” or “structured”:
- “Flat”: not very rich, lacks metadata, can be hard to interpret
- “Structured”: rich, includes metadata, easier to interpret but requires processing on the client-side
The following table shows which data formats and structures are supported on which interfaces.
- You are encouraged to use the CUD UI to view the different data formats and structures in order to determine which is best for a specific purpose.