CUD Interfaces

4.1. CUD attribute set

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

4.2. Complete list of attributes

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.

4.3. Requesting access to additional attributes

Please use the following email template to request access to additional attributes replacing elements in <> with your details:

• SSO username/service principal name is 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 requested is the list of name of the additional requested, taken from the complete list of attributes
• ITSS should be answered Y/N depending on whether you appear in the ITSS register
• Reason for access is required whether or not you are ITSS

4.4. Affiliations

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)
• Unit
• Source
• 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@EN
• MC@OUCS
• 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.