<-Storage Go to ToC Execution ->

1 Reference Model

Figure 1 depicts the Reference Model of Metadata.

Figure 1 - Reference Model of Metadata

Figure 1 – Reference Model of Metadata

Metadata specifies static properties of the components of MPAI-AIF – an AIM, a Composite AIM and its Sub-AIMs, a Module, the AI Framework – and how they interact with the Controller. Metadata is represented in JSON Schema. Table 1 lists the kinds of Metadata this chapter deals with. Two of them travel at run time and are specified elsewhere: Data Exchange Metadata by MPAI-PTF, the Trace as a Data Type of MPAI-AIF.

Table 1 – Kinds of Metadata

Metadata Describes Identified by Specification
AIM Metadata Schema The JSON Schema against which AIM Metadata and AIM Instance Metadata validate. Its Header AIM Metadata
AIM Metadata An AIM as a Standard specifies it: Function, Ports and, for a Composite AIM, its Sub-AIMs and Topology. The AIM type, e.g. MMC-EDP-V2.5 AIM Metadata
AIM Instance Metadata One AIM Instance: its Implementations, Relation, resources and the values the AIM Metadata leaves open. The AIM Instance Identifier, e.g. 1MMC-EDP-V2.5-I01 AIM Instance
AIF Metadata An AI Framework: its Implementer, API Profile, resources, services and time base. The Implementer ID and Version AIF Metadata
Data Exchange Metadata A Data Instance: its origin, authorised and legal use, security state and accuracy. Its identifier MPAI-PTF
Trace An event: its source and its time. Its Trace ID Trace

2 AIM Metadata and AIM Instance Metadata

AIM Metadata and AIM Instance Metadata validate against one schema, the AIM Metadata Schema. AIM Metadata describes the specification of an AIM; AIM Instance Metadata describes an Implementation, and declares only what the Implementation supports. The Metadata of a Module is the AIM Instance Metadata of the AIM the Controller runs.

The Metadata is authoritative: the Controller builds a Module from it, and no AIM, Port or Channel exists that the Metadata does not declare. The Metadata must therefore be truthful: an input declared required that the Module never supplies stops the AIM from running in continuous execution (Execution).

2.1 Fields

Table 2 – Fields of AIM Metadata and AIM Instance Metadata

Field Meaning
Header In AIM Metadata, the AIM type (e.g. MMC-EDP-V2.5). In AIM Instance Metadata, the AIM Metadata of which it is an instance.
Identifier Implementer ID, Implementation ID and AIM Name. In AIM Metadata the AIM Name is the AIM type; in AIM Instance Metadata it is the AIM Instance Identifier. On a Sub-AIM, also its Relation and, where the Relation is Private or Public, its Host (AI Modules).
APIProfile Basic or Secure (Zero Trust and Profiles).
Description The Function of the AIM.
ExternalPorts The Ports of the AIM (2.2).
SubAIMs Of a Composite AIM: the Identifiers of its Sub-AIMs.
Topology Of a Composite AIM: the connections between Ports (2.3).
InternalTypes Of a Composite AIM: the Data Types that flow between its Sub-AIMs, with the labels by which the Topology names them.
Execution Of a Composite AIM: Exchange or Continuous (Execution).
OnDegraded Of a Composite AIM: StopModule, StopAIM or Continue (Controller).
StorageControl Of a Composite AIM: the Sub-AIM that holds the central control of its Private Storage (Storage).
Record Of a Composite AIM: Always, where the Controller shall record its boundary from Start to Stop (Storage).
RestartLimit How many times the Controller restarts the AIM when it fails before leaving it DEAD.
Period, Deadline The interval at which the AIM runs; the time within which a run completes. A Controller that cannot honour them refuses the Module.
Implementations Where each Implementation is, and for which architecture, operating system and version.
ResourcePolicies The resources the AIM requires.
Documentation Where the AIM is documented.
DataXMData Declares that the AIM exchanges data accompanied by Data Exchange Metadata (4).
DescrMetadata Free-text descriptive Metadata.

2.2 Ports

Table 3 – Fields of a Port

Field Meaning
DataType The Data Type the Port carries, or a set of Data Types it accepts – a Basic and a full Object, for example.
Direction Input or Output.
PortNumber The ordinal among the Ports of the same Direction and Data Type of the AIM; omitted where the pair occurs once, and then 1.
Name A label for people. It is dropped when the Metadata is ingested and never routes data.
Input, Output On a Composite AIM, the group numbers that select which same-typed Input group of a Sub-AIM a flow feeds, and which external supply a group receives (AI Modules).
Depth, Overflow, MaxAge On an Input Port, its behaviour (Communication).
Transport On an Output Port, the transport of the Channel it writes; Controller where omitted.
AcceptedTransports On an Input Port, the transports it accepts.
IsOptional True where the Port need not be supplied for the AIM to run; required where omitted.
Technology, Protocol, IsRemote Hardware or Software; the low-level protocol of a hardware Port; whether the Port is remote.

2.3 Topology

Each line of a Topology connects an Output – the Port from which the upstream AIM sends – to an Input. Each end names the AIM that holds the Port – a Sub-AIM, with an AIM Number where several share an AIM Name, or the Composite AIM itself – and the Port, by a label of the Composite AIM – one of its ExternalPorts or InternalTypes, which gives the Data Type – and a Port Number where needed. The name a Sub-AIM gives its own Port is never read, and a Topology using a label the Composite AIM does not declare does not load. The Controller resolves the labels once, at load time, into Data Types and Port Numbers.

2.4 Instance of

AIM Instance Metadata is an instance of the AIM Metadata its Header names when:

  1. every Port of the AIM Instance Metadata is a Port of the AIM Metadata: the same Direction, and the Data Types of the AIM Metadata include those of the AIM Instance Metadata;
  2. an input both declare is optional in both or in neither, and an output the AIM Metadata requires is not optional in the AIM Instance Metadata;
  3. a Port of the AIM Metadata that the AIM Instance Metadata does not declare is optional in the AIM Metadata;
  4. every Sub-AIM of a Composite AIM Instance is a Sub-AIM of the AIM Metadata, a Composite AIM containing one, or a combination of Sub-AIMs of the AIM Metadata: two or more AIMs may be combined into one provided that it exposes the same interface – the Topology lines of the AIM Metadata crossing the border of the group they form.

The MPAI Store refuses AIM Instance Metadata that does not validate against the AIM Metadata Schema or is not an instance of its AIM Metadata.

3 AIF Metadata

AIF Metadata describes an AI Framework as its Implementer provides it: the Implementer identity and the Version; the API Profile, Basic or Secure; resource policies for computing, storage, the Controller and extensions; the services available – Communication and Trusted Services such as authentication, encryption and attestation; and the time base of the Controller, on which every Message and every Storage write is stamped.

4 Data Exchange Metadata

Data Exchange Metadata is a Data Type of MPAI-PTF. It accompanies a Data Instance and states its origin, its authorised, privacy-respecting and legal use, its security state and its accuracy: the evidence by which a receiving AIM or Process Instance decides whether it may process the data. The Qualifier of an Object states what the data is; the Data Exchange Metadata states what may be done with it.

An AIM whose Metadata declares DataXMData exchanges data accompanied by Data Exchange Metadata.

A Message that a Controller sends to another Controller through an External Port carries MPAI-PTF Data Exchange Metadata (DataXMData) identifying its Source and stating, in Security.Integrity, the SHA-256 hash of the Object, the KeyID of the sending Controller and its signature over the canonical form of the Message. The receiving Controller shall deliver the Message to its External Port only if it is signed, its KeyID is that of the Controller admitted on the link, the key is trusted, the hash matches and the signature verifies; otherwise it discards the Message and counts it. Messages on Channels within a Controller, and between a Controller and its AIM hosts, carry no Data Exchange Metadata: they are protected by the link the Trust Protocol admitted.

5 Type system

A Port carries an MPAI Data Type or a type of the type system of MPAI-AIF, which the following Backus-Naur Form specifies. Capitalised words such as NAME are tokens.

fifo_type :=
    | /* The empty type */
    | base_type NAME
recursive_type :=
    | recursive_base_type NAME
base_type :=
    | toplevel_base_type
    | recursive_base_type
    | ( base_type )
toplevel_base_type :=
    | array_type
    | toplevel_struct_type
    | toplevel_variant_type
array_type :=
    | recursive_base_type []
toplevel_struct_type :=
    | { one_or_more_fifo_types_struct }
one_or_more_fifo_types_struct :=
    | fifo_type
    | fifo_type ; one_or_more_fifo_types_struct
toplevel_variant_type :=
    | { one_or_more_fifo_types_variant }
one_or_more_fifo_types_variant :=
    | fifo_type | fifo_type
    | fifo_type | one_or_more_fifo_types_variant
recursive_base_type :=
    | signed_type
    | unsigned_type
    | float_type
    | struct_type
    | variant_type
signed_type :=
    | int8
    | int16
    | int32
    | int64
unsigned_type :=
    | uint8 | byte
    | uint16
    | uint32
    | uint64
float_type :=
    | float32
    | float64
struct_type :=
    | { one_or_more_recursive_types_struct }
one_or_more_recursive_types_struct :=
    | recursive_type
    | recursive_type ; one_or_more_recursive_types_struct
variant_type :=
    | { one_or_more_recursive_types_variant }
one_or_more_recursive_types_variant :=
    | recursive_type | recursive_type
    | recursive_type | one_or_more_recursive_types_variant

Valid types for FIFOs are those defined by the production fifo_type. Although this syntax allows types of fixed length, the general record type written to, or read from, a Port does not have a fixed length. If an AIM implemented in hardware receives data from an AIM implemented in software, the data format should be harmonised with the limitations of the hardware AIM.

A type definition gives an automated way of filling and transmitting buffers, for hardware and software Implementations alike. Data structures are turned into low-level memory buffers, filled by recursively traversing the definition (breadth-first). Sub-fields are laid down according to their type, in little-endian order. For instance, a definition for transmitting a video frame through a FIFO might be:

{int32 frameNumber; int16 x; int16 y; byte[] frame} frame_t

and the corresponding memory layout would be:

[32 bits: frameNumber | 16 bits: x | 16 bits: y | 32 bits: size(frame) | 8*size(frame) bits: frame]

Functions of the Basic API parse the content of raw memory buffers in a platform- and implementation-independent fashion.

6 Requirements

Table 4 – Requirements of Metadata

# Requirement
MET-1 AIM Metadata and AIM Instance Metadata shall validate against the AIM Metadata Schema.
MET-2 AIM Instance Metadata shall be an instance of the AIM Metadata its Header names.
MET-3 AIM Instance Metadata shall declare only what its Implementation supports.
MET-4 A Port shall be identified by Data Type and Port Number; a Port name shall not route data.
MET-5 A Topology shall name each end by a label its Composite AIM declares.
MET-6 An AI Framework shall declare its AIF Metadata, including its time base.

<-Storage Go to ToC Execution ->