A Survey of Industry Data Models and Reference Data Libraries
10 Government information model
10.1 UK Information Exchange Standard (IES)
This standard will become publicly available soon, and will probably be hosted by the UK Government Defence Science and Technology Laboratory.
10.1.1 Defining organization
The UK Information Exchange Standard is defined by the UK Government.
10.1.2 Objectives and scope
Under “background” the introduction to the IES says:
Across the UK Government there are many separate knowledge stores, including multiple stores within each organisation; and this will remain the case for many years. Many of the knowledge stores contain similar information about the real world but, for numerous technical and business reasons, there is no standardised way of representing such content – this is usually because different terminologies, formats and/or schemas are used for each of these stores.
Analysts across the police, defence and national security community need comprehensive access to the information distributed across these many knowledge stores so that they can concentrate their efforts on analysis and exploitation tasks without having to broker between different internal formats and schemas. Being able to exchange and share information effectively and efficiently is therefore imperative and needs to be achieved without the need for collaborating organisations to:
- develop numerous and bespoke bilateral interchange mechanisms;
- make costly and highly disruptive changes to their individual knowledge stores.
The Information Exchange Standard (IES) was developed in order to enable that collaboration.
The scope of the model encompassed many of the activities carried out by government including:
- maintenance of law and order;
- purchasing and finance;
- maintenance of relationships with other governments.
10.1.3 Structure of the model
The top structure of the IES model is broadly based upon the ISO 15926 and Boro models, both of which are 4D. The nature of the top structure is within the scope of the “Top Level Ontologies” report and is not discussed here.
Of importance here is the broad scope of the IES model, and the way in which it is organised. The IES model contains the following principal types of object:
entity: a tangible thing like a person, a device, location, etc.
state: and entity at moment in time or for a period of time (e.g. a moment in a person's life, a phase of a project, etc.)
event: an activity or incident, involving one of more participating entities, that occurred/started at a specific point in time - e.g. a meeting or a telephone call.
There are relationships between objects, and particular relationships which describe the way in which entities and states participate in events.
The model is divided into parts within the topics of entity, event and relationship, as follows:
entity (including state😞
person: identification, characteristics, nationality, place of birth, religion, etc.
communications account: how people and organizations communicate by telephone, e-mail, VOIP etc.
asset: something of value that a person or organization may have, such as a vehicle, land, money, a document, rights, a payment artefact (see below)
amount of money: money in different currencies
identity document: document such as a birth certificate, passport, visa, driving licence and identity card, with information about the issuer and the period of validity
organisation: types of organisation, such as commercial organisations, not-for-profit organisations, government organisations, and their places of registration
vehicle: make, registration number, where registered, where usually parked, etc.
posts and roles: how people relate to organisations
ticket: entertainment and travel tickets, the issuer and in the case of a travel ticket the journey that it is for
communications device: telephone, radio handset, network, cellular base station, etc.
financial account: account identification, account holder, account provider, account type
on-line: information on-line such as a website, social media site, social media post, comment, and cookie, along with information about the publisher, creator and hosting
location: to different levels of precision - mapping coordinates, postal address, cell phone base station, geographic region
document: book or report with author and publisher
data object: data base, schema and data that are held within or according to them
communications identifier range: telephone number range, IP address range, domain name and its registration
communications identifier: individual telephone number, IP address, e-mail address, radio call sign and its registration
payment artefact: bank card, travel card, store card and its issuer
assessment: finding out whether something it true, and asserting a degree of confidence
authorisation: gaining approval for an activity, which includes the request, the grant and the warrant document that records the authorisation and the roles played by people and organisations
observation: observing something
agreement: negotiating, ratifying and executing a treaty, trade agreement, non-disclosure agreement, rental agreement. etc. and the roles played by people and organisations
business: opening and closing accounts, and transferring money between accounts
attendance: being at a meeting, and checking-in for travel
communication: exchange of information between parties by telecommunication or attendance at a conference, with information about the medium and communications account
lifecycle: creating, modifying and destroying objects
on-line event: logging on, logging off, and creating content, within information about the device used and the on-line account
criminal: criminal activity such as stalking, forgery, and terrorism, with information about the perpetrator and victim
law enforcement: arrest, prosecution and incarceration, with roles such as witness, arresting officer, prosecutor, and incarcerating organisation
operational: reconnaissance, surveillance and arrest, with roles such as lead investigator and documents such as arrest warrant
political: policy announcements, elections, changes of government and summits, with their participants
trade: offer for sale, withdraw from sale, request quotation, purchase, deliver, transfer money, with information about what is traded, between whom, and how money transfers were made
movement: check-in and travel, with information about the from and to, means of travel, tickets and identify documents used
travel booking: the reservation, booking agent and payment
familial: parent, sibling, cousin, etc.
interest: likes, dislikes, loves, hates
lifecycle relationships: creator, destroyer, modifier
mutual understanding: party to an agreement, negotiator, signatory, in disagreement
operational: between assets, such as part of and stored in, and between people and assets, such as maintains and owns, and between people and locations, such as works at, socialises at, worships at, stays at
professional: employed by, managed by, contracted to, is teacher of, works with, etc.
social: influenced by, know associate of, friend of, etc.
topological: near to, next to
The documentation of the IES is in UML and admirably clear. For each of the topics listed above, there is a separate UML diagram. Objects are shown in more than one diagram because entities are involved in events and are linked by relationships. A typical UML diagram is reproduced as Figure 32.
Figure 32 - UML model for a financial account
The UML classes are colour coded for clarity, with entities in yellow, relationships in grey, and information content, such as text strings, in blue. The red link is to members of the powerclass which are a library of account types held as reference data.
An equivalent to the UML model is provided in RDF schema. This enables implementation of the model for government data exchange using TURTLE, N3, XML and JSON.
10.1.5 Maintenance and usage
The IES standard is actively maintained. Version 4.2 was released on 2nd September 2020. Version 1.0 was released on 3rd June 2015, and there has been a succession of revisions since then.
The IES standard is used by Government departments and agencies within the UK for the exchange of data, and particularly by the legal community and Home Office for data concerning warrants. The standard is also used for inter-government exchange by Australia, Canada, NZ, UK, and USA.
10.2 US Department of Defense Architecture Framework (DoDAF)
10.2.1 Defining organization
The US Department of Defense.
10.2.2 Objectives and scope
The introduction to DoDAF says:
“The Department of Defense Architecture Framework (DoDAF), Version 2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries.”
DoDAF is concerned with the development of IT systems, and not just the data models that support them. DoDAF is a comprehensive methodology that defines “viewpoints”. The DoDAF introduction says:
“Each viewpoint has a particular purpose, and usually presents one or combinations of the following:
- Broad summary information about the whole enterprise (e.g., high-level operational concepts).
- Narrowly focused information for a specialist purpose (e.g., system interface definitions).
- Information about how aspects of the enterprise are connected (e.g., how business or operational activities are supported by a system, or how program management brings together the different aspects of network enabled capability).”
Types of viewpoint include:
all: describes the overarching aspects of architecture context that relate to all viewpoints;
capability: articulates the capability requirements, the delivery timing, and the deployed capability;
data and information: articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services;
operational: includes the operational scenarios, activities, and requirements that support capabilities;
project: describes the relationships between operational and capability requirements and the various projects being implemented;
services: the design for solutions articulating the performers, activities, services, and their Exchanges, providing for or supporting operational and capability functions;
standards: articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational e, system engineering processes, and systems and services;
systems: is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.
The definitions of the viewpoints require models of different types. The data and information viewpoint has data models. The operational viewpoint has activity models. There are levels of detail within viewpoints. The operational viewpoint has levels:
- OV-1 High-Level Operational Concept Graphic
- OV-2 Operational Resource Flow Description
- OV-2 Operational Resource Flow Internal Description
- OV-3 Operational Resource Flow Matrix
- OV-4 Organizational Relationships Chart
- OV-5 Operational Activity Model
- OV-6a Operational Rules Model
- OV-6b Operational State Transition Description
- OV-6c Operational Event-Trace Description
The data and information viewpoint has levels:
- DIV-1 Conceptual Data Model
- DIV-2 Logical Data Model
- DIV-3 Physical Data Model
The DoDAF Meta Model (DM2), https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_dm2/, sits alongside the viewpoints of DoDAF. The relationship between the two is not precise. The introduction to DM2 says that its purposes are:
- Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes.
- Specify the semantics and format for federated EA data exchange between: architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) and with other authoritative data sources.
Support discovery and understandability of EA data:
- Discovery of EA data using DM2 categories of information;
- Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases).
- Provide a basis for semantic precision in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.
A mapping is maintained between data and information viewpoint models and DM2. This is available at https://dodcio.defense.gov/Library/DoD-Architecture-Framework/dodaf20_mapping/.
10.2.3 Structure of the model
10.2.3.1 DoDAF Meta-model (DM2)
The DoDAF meta-model supports the data and information viewpoint models in DoDAF. As stated in the previous section, a mapping is maintained between the data and information viewpoint models and the meta-model. This mapping is also referred to as the “DoDAF - DM3 Data Dictionary”, and is discussed further in the next section.
The meta-model has three levels, just as for a data and information viewpoint. The levels are as follows:
conceptual data model (CDM)
The introduction to the conceptual data model says:
“The CDM defines concepts involving high-level data constructs from which Architectural Descriptions are created, enabling executives and managers at all levels to understand the data basis of Architectural Description.”
The concepts in the model include:
- resource, which can be performer, data or materiel;
- guidance, such as standards and agreements.
The concepts are an extension of those in the IDEAS data model, which is described in the Top Level Ontologies report. The DoDAF website has the diagram shown in Figure 1.
Figure 1 - Conceptual data model for the DoDAF meta-model
Logical data model (LDM)
The introduction to the logical data model says:
“For ease of understanding; the DM2 LDM is presented in groups of semantically related concepts into clusters. These clusters are categorized as Principle Architectural Constructs and Supporting Architectural Constructs. The Principle Architectural Constructs are the fundamental building blocks necessary to describe an enterprise's internal and external behavior and structure.”
The principal data groups within the logical data model are:
- resource flows;
- information and data;
- organizational structure.
The data groups are documented using the SYSML dialect of UML. They are extensions of the IDEAS foundation data model. An example is shown in Figure 2.
Figure 2 - The DM2 LDM Resource data group
Physical Exchange Specification (PES)
The physical exchange specification consists of XML schemas. These are not in the public domain.
10.2.3.2 DM2 data dictionary
The DM2 data dictionary is a spreadsheet that defines 510 terms. For each term, the following are supplied:
- sources, giving definitions elsewhere;
- rationale for the definition, and comments about further work;
- uses of the term in DM2 submodels (as a matrix);
- relevance of the term to DoDAF viewpoint models (as a matrix).
10.2.3.3 Example DoDAF application
The DoDAF application models are in the public domain. However the methodology is illustrated by a publicly available UK search and rescue model, which can be found on the Dassault Systèmes website https://docs.nomagic.com/display/UAFP190/DoDAF+2.1 .
The example begins with the high level all viewpoint graphic shown in Figure 3.
Figure 3 - Example DoDAF "all" viewpoint summary graphic
There are numerous models within the operational viewpoint, such as that shown in Figure 4.
Figure 4 - Example operational activity flows
The data and information view point has layers - conceptual, logical and physical, which are shown in Figure 5, Figure 6 and Figure 7.
Figure 5 - Example DoDAF conceptual data model
Figure 6 - Example DoDAF logical data model
Figure 7 - Example DoDAF physical data model
The DoDAF system design methodology comprehensive and well explained but complicated. The best examples seem to be on the Dassault Systèmes website.
The DoDAF meta-model is also well explained and documented in UML, but seems to add little to the IDEAS Top Level Ontology.
The DoDAF meta-model data dictionary is useful, but is only person interpretable. Therefore it is limited in its ability to link the various parts of the DoDAF architecture.
10.2.5 Maintenance and usage
DoDAF Version 2.02, including the meta-model version DM2, was released in August 2010.
DoDAF is used as the basis for systems development within the US Department of Defense.