GLN Data Model Solution Standard (2024)

Figure 41 Data model dimensions

GLN Data Model Solution Standard (1)

4.1.1 Abstract data model

A Unified Modeling Language (UML) class diagram expresses the GLN data model at an abstract level, defining it in a way that is independent of the data format/syntax (e.g., XML vs JSON vs JSON-LD), relevant classes, properties/attributes and code lists and can be used to describe organisations/parties and physical locations. The UML class diagram defines the available terms but does not attempt to specify which are mandatory, conditional, optional or any cardinality constraints. See Figure 5‑1 UML Class Diagram.

Figure 42 Abstract data model

GLN Data Model Solution Standard (2)

An abstract data model defines data classes, attributes/properties, code lists / enumerations. An abstract data model:

includes definitions (and examples of usage)

specifies expected data types for values

supports hierarchical data structures and hierarchies of locations and organisations/parties

supports re-use of the data model at any level in the location or organisation/party

concerned with unambiguous semantic interpretation, not validation

often documented in UML class diagrams

4.1.2 Validation

One or more validation layers that are used to express constraints on the data model about which properties/attributes are mandatory/conditional, which are repeatable, cardinality constraints etc. Note that there might be multiple validation layers (e.g., a core global multi-sector validation layer and additional regional or sector-specific validation layers). Depending on the chosen data format, validation rules can be expressed using XSD, JSON Schema or Shape Constraint Language (SHACL).

It is worth noting that there will be different validation constraints where there are different regulatory requirements, country of use, different sector use and the different application use.

Figure 43 Validation data model

GLN Data Model Solution Standard (3)

A validation schema checks that:

mandatory data is present.

An example can be seen in Figure 4‑3 where the “locality (city)” field is a mandatory field and cannot be left blank, if this is used in webform the submission of the date would take place until all mandatory fields have been completed.

data is correctly formatted.

An example can be seen in Figure 4‑3 where a “country code” is required and this field definition must comply to an agreed format, in this instance ISO 3166.

Validation schema checks need to comply with the six types of cardinality constraints. Cardinality validation may be more restrictive than noted in section 5 to meet the needs of specific applications.

Mandatory one [1..1]: The attribute is mandatory. It cannot be repeated.

Mandatory many limited [1..n]: The attribute is mandatory. It can be repeated up to n times.

Mandatory many unlimited [1..*]: The attribute is mandatory. It can be repeated any number of times.

Optional one [0..1]: The attribute is optional. It cannot be repeated.

Optional many limited [0..n]: The attribute is optional. It can be repeated up to n times.

Optional many unlimited [0..*]: The attribute is optional. It can be repeated any number of times.

Figure 44 An example of a conceptual validation

GLN Data Model Solution Standard (4)

4.1.3 Layering

Layering of the data model and extensibility (represented by the onion model) as seen in Figure 4‑6, showing a global, multi-sector core as well as outer layers that may have different levels of maturity or may have narrower scope (e.g., region-specific, sector-specific) as seen in Figure 4‑7.

Figure 45 Layering data model

GLN Data Model Solution Standard (5)

Figure 46 Data model layers

GLN Data Model Solution Standard (6)

A layered 'onion' model defines core data and supports extensions by industry sector and/or geographic region and are typically implemented via use of multiple namespaces.

Figure 47 Data model scope elements

GLN Data Model Solution Standard (7)

4.1.4 Logical connections

There are some logical connections and intersections of these three independent dimensions as shown in the following three illustrations: Figure 4‑8, Figure 4‑9, and Figure 4‑10.

The validation schema reference the abstract data model and also depend on the contents of the layering. The schema can also go beyond what is defined in the abstract data model by adding validation constraints (e.g., mandatory properties, cardinality constraints etc).

Figure 48 Connections between abstract data model and validation example

GLN Data Model Solution Standard (8)

Since there can be multiple validation layers (e.g., core, global, multi-sector vs other validation layers for outer layers of the onion model), it is possible to be flexible about validating at each layer of the onion, even if for example, different regional or sector-specific layers have different requirements. Multiple validation layers are one way to support the onion model, to check that the data is correctly validated.

Figure 49 Connections between validation and layering example

GLN Data Model Solution Standard (9)

Use of multiple namespaces is the other way to support the flexibility of the onion model. It is expected to have a namespace for the core global multi-sector aspect of the data model. Anything outside of that (defined in the outer layers of the onion model) can be defined within its own namespace, so that there is no conflict between different definitions in the outer layers and no ambiguity about where a particular class, property/attribute or code list is defined. Each region or sector defining its own 'extensions' to the global multi-sector core can do so within their own namespace and can make cross-references to the global multi-sector core but express how it is extending that in its own way, for its own needs (which might be to meet the needs of some specific legislation in a particular region or sector). It is not a problem for the data to make use of multiple namespaces. XML and JSON-LD support this natively. JSON does not - but JSON-LD context resources can be used to hide some of the namespace complexity from anyone who wants to consume the JSON-LD data as if it is just JSON, while preserving support for multiple namespaces for those who need those details.

Figure 410 Connections between abstract data model and layering example

GLN Data Model Solution Standard (10)

GLN Data Model Solution Standard (2024)
Top Articles
Latest Posts
Article information

Author: Roderick King

Last Updated:

Views: 6166

Rating: 4 / 5 (71 voted)

Reviews: 94% of readers found this page helpful

Author information

Name: Roderick King

Birthday: 1997-10-09

Address: 3782 Madge Knoll, East Dudley, MA 63913

Phone: +2521695290067

Job: Customer Sales Coordinator

Hobby: Gunsmithing, Embroidery, Parkour, Kitesurfing, Rock climbing, Sand art, Beekeeping

Introduction: My name is Roderick King, I am a cute, splendid, excited, perfect, gentle, funny, vivacious person who loves writing and wants to share my knowledge and understanding with you.