The proposed approach aims to set the basis for the development of a comprehensive technical standard for the representation and exchange of mining-related information, that can be used:

• By ICGLR and for exchange between member states and ICGLR, and respectively with 3rd parties
• By member states, to allow interoperability between systems at the national level
• By other parties, that collect, process, or distribute mining-related information

The approach follows internationally recognized standardization rules as set out in the ISO/IEC Directives (Part 1: procedures for technical work; Part 2: principles and rules for drafting) and the corresponding CEN-CENELEC Internal Regulations (Part 2: common rules for standardization work; Part 3: structure and drafting rules).

The development of the semantic standard considers the following principles:

• The data model follows an ontological approach, describing entities and their attributes, and the relationships between them.
• Each entity includes attributes and other entities. An entity is a data structure that on its own has attributes, and can be seen as an independent data structure that can be included by other entities, in the present or in the future (for example, the Export Certificate is an entity, under whose structure we find attributes such as Serial Number, Issuing Country, and we find references to entities — for example Exporter and Importer are entities of type Business Entity).
• Each attribute has a Data Type, which clearly defines the format of the data. All data types must take value, as much as possible, from a list of specified Primitive Types, that are defined in ISO 15000-5:2014, Annex B.
• Each attribute or sub-entity has at least the following information: Cardinality, Name, Description, Semantic Data Type. They may also have Usage information and Rules to be applied, if they are necessary to either provide instructions on how to establish the value of the attribute or restrict the way it is used, such as for example in terms of format, values, or size of the set of characters.

Model Extension and Derivation #

The standard representation done for ICGLR could be further used by each member country, or for any other country if the data model is made available to them, for any purpose of interest, provided that at least one of the following is applied:

• Mapping: The national mining data is technically mapped to the ICGLR data model for the purpose of interoperability with the ICGLR Regional Minerals Database.
• Extension: The ICGLR data model is Extended by the country, through the addition of new Entities and Attributes, but without altering in any way the main semantic data set defined by the ICGLR data model. Thus the ICGLR data model is seen as the “Core Model” that could be further extended.
• Derivation: The ICGLR data model is Derived by the country, through additions and documented exceptions that need to be applied in the context of the internal data acquisition, processing and exchange in the country. Such exceptions might challenge or compromise the native interoperability with the main data model and should be technically treated whenever the data needs to be exchanged with a system that is fully compatible with ICGLR data model.
• Usage Specifications: The country might develop Usage Specifications that impose additional rules on the data formatting, data size or the values that can be taken by certain attributes. This process of adapting the Core Model to the specificity of the country is a normality, required from the perspective of adhering to the specific regulatory requirements active in the country. Such Usage Specifications should not break the compatibility with the Core Model.

The semantic representation of the Core Model is not dependent on the technology of implementation. The Regional Minerals Database might choose an SQL-based data representation. The APIs might use a JSON representation or a JSON-LD that carries information on the context and relations between entities. In case of lack of direct technical real-time connection between the systems that exchange data, the technical format of choice could be XML, based on a custom-defined schema.

Any format used should also allow the semantic validation through a Validator component that checks the compatibility of the exchanged data set with the semantic model at the level of its application.