You are here

A guide to the standards library

Standard identifier: 
Standard Type: 
Guidance Documents
Approved: Recommended
Date of Standard: 
Monday, 10 August 2015
Courses and qualifications
Learning interaction
Policies, business change and strategy
Premises and facilities
Resources (including HR and procurement)
Party (including organisation and person)
Target audience: 
Data modellers
ICT procurers
System developers or programmers

This guidance explains the background to the terminology used in the standards, how the standards seek to be universally suitable for work in the Education, Skills and Children's Services (ESCS) sector and the definitions of the different categories used to describe the standards, including the different status designations assigned to them.

Terminology is sector-neutral

The ISB Business Data Architecture can be applied across each sector of ESCS, ie: children’s services; schools; further education (FE); higher education (HE).

Each ESCS sector has unique terminology, so a standard that defines a common piece of information will inevitably use terminology that is not ‘native’ to every sector. In order to avoid an appearance of being tied to any one sector, ISB standards in these cases will use sector-neutral terminology ie terminology that is not in use in any sector.

The advantage of using sector-neutral terminology is that data collected in one sector can be used in another. The disadvantage is that each sector must become accustomed to the common terminology used for data transfer and know how to interpret the data for use. For example:

• the ‘person’ standard

Different sectors use the words ‘pupil’, ‘learner’, ‘student’ or ‘child’ in relation to the people they deal with.

In the ISB standards you will find a standard for ‘role’ and a standard for ‘person’, but no standard for ‘pupil’ etc. You will need to use the standard for ‘role’ and the role type ‘learner’, which is the generic term adopted by ISB standards for any person engaged in or intending to engage in or having recently engaged in learning, training or study in any sector. For example:

• the ‘organisation’ standard

Different sectors use the words ‘school’, ‘college’ and ‘university’ to define the role of an organisation that provides learning, training or study.

In the ISB standards you will find a standard for ‘role’ and a standard for ‘organisation’ but no standard for ‘school’ etc. You will need to use the standard for ‘role’ and the role type ‘learning opportunity provider’, which is the generic term adopted by ISB standards for any organisation (or person) that delivers opportunities for learning, training or study. For example:

• the ‘party’ standard

Sometimes, a role can be carried out by both an organisation and person. For example, both can be parties to a contract.

Within the ISB standards, the term ‘party’ is used when information and activities can be carried out by either a person or an organisation. Where a role can only be performed by a person, then the standards refer to ‘person’. Where the role can only be performed by an organisation, then the standards refer to ‘organisation’.

A single form of information

ISB standards seek global optimisation to achieve the greatest benefits in total across ESCS. They are different from many other standards which define data for a specific process or type of system and in which the structure and content of such standards are optimised to that purpose. Whilst optimising the purpose, these standards lead to sub-optimal enterprises because every process or application requires its own unique optimised standards. Systems that participate in more than one process must support many different customised data exchanges.

ISB standards, on the other hand, seek to be process independent so that each piece of data is transferred in exactly the same form no matter what the purpose or context. In order for ISB standards to achieve this, each ISB standard must be:
• modular (ISB standards are small logically-related pieces of information that must be exchanged together with each other, but may be sent in combination with many different standards in different contexts)
• structured in such a way that it connects to other information, and the connections can work in any receiving system without significant overhead (ISB standards specify the way that one unit or ‘entity’ of data can be identified so that other standards can contain the necessary data to point to related data). For example, each name of a person must carry a pointer to the person named

This means that, for example, there is no ISB standard to cover:
• all the data needed to handle application for, and enrolment on, a course of learning/training/study - instead, the full set of data needed for this can be built from assembling the (modular) standards: ‘party’, ‘party relationship’, ‘party relationship role’ and ‘enrolment’
• all the data needed to handle application for and employment of a member of the workforce - instead, the full set of data needed for this can be built from assembling the (modular) standards:  ‘party’, ‘party relationship’, ‘party relationship role’ and ‘post fulfilment’

The benefit of this approach is that three modular building-block standards are common between the two business processes in these examples, showing the generality and re-usability of the standards.

Important information held in ‘party’,’ party relationship’ and ‘party relationship role’ (such as a person’s name, date of birth, gender etc), does not have to be defined twice, once for use in the context of learning and once again in the context of employment.

How to search for standards

When searching for standards, readers need to understand and use the common terminology, as described above.

For example, you should start from a point like the ‘enrolment’ standard and follow all of its links to pick up the necessary related standards of ‘party’, ‘party relationship’ and ‘party relationship role’.

ISB standards have a managed lifecycle and as each standard moves through its lifecycle it is allocated
• a decision status
• a standard type
• a subject filter

Each standard contains details giving the date of the standard, the Decision relating to that standard, its Type and Subject Category.


The ‘Decision’ field gives the status of the standard:
• ‘approved’ means that the standard is approved by the ISB

There are 2 stages for approved standards:

• ‘approved: recommended’ is used where trials are encouraged

• ‘approved: adopted’ is used where adoption is strongly advocated, usually after implementation experience and possible refinement in the light of experience

• ‘future’ means that the standard will be developed in due course

• ‘rejected’ means that the standard was considered and rejected by the ISB - reasons for rejection are included in the details of the proposal

• ‘deprecated’ means that an approved standard has been retired and/or replaced by a new standard - new systems should not be built using these standards as use of the deprecated standards should be phased out from any system that uses them

• ‘under consideration’ means that the standard will be presented to the ISB once further work has been completed

Standard type

Standard types describe what sort of standard is listed. There are five standard types:

Business data standards (BDSs)

These standards relate to specific areas of the data model describing the data that underpins ESCS business. They are defined in response to a business need and captured in a business case. As they are developed, every effort is made to ensure that the BDS is capable of supporting all the ESCS business needs for the same data. BDSs define information semantics and structure in a logical way that ensures that any binding to an encoding (such as XML or CSV) will always convey the same meaning.

Controlled vocabularies

These support the BDSs and can take the form of flat controlled lists which provide a set of approved formatting and values to be used across the ESCS. They might also be hierarchical thesauri which contain relationships between terms, or authority files which relate specifically to names, subjects and series and can contain cross references. Once approved, all of these types are independent ISB standards in their own right.

Guidance documents

These are issued to support ISB standards. Documents may include:
• notes of guidance for the stakeholder to understand how the standard has been constructed
• notes of guidance for the supplier on how they might implement the standard
• notes of guidance to the user on how to capture the data using the new standard

Technical data standards

These standards specify an encoding schema (or ‘binding’) for data exchange. Technical data standards will conform to ESCS ISB business data standards (BDS).

Aggregated Data Standards (ADS)

Like Business Data Standards, these standards relate to specific areas of the data model, describing the data that underpins ESCS business. Unlike Business Data Standards, they use aggregated data. Aggregated data is data that is the result of manipulation of one or more atomic data items, either via explicit formula or implicitly, for example via surveying opinions. It is used for a specific purpose and requires rules to define how to aggregate atomic data. An example is ‘Total Sales’. This will be built up from individual sales and any rules of what atomic records are included / excluded must accompany the entity / attributes.

Business data standards subject categories

The subject categories attempt to group those standards and controlled lists in a particular information domain of the business data architecture.
 The filter:
• allows users to limit their search by topic area
• allows users to select the topic area that best matches their needs

Users can either:
• use the search filters to narrow down the results that are displayed or leave all the filters unchecked to see the entire list
• see the alphabetical list of standards and filter, or use the search option