MPAI Metaverse Model (MPAI-MMM) – Technologies (MMM-TEC) standard specifies technologies that enable a human to:

  1. Sense the Universe, i.e., the physical world.
  2. Create Items in an M-Instance.
  3. Perform actions in the M-Instance:
    1. Using their own or other Items to which they have Rights.
    2. Complying with the applicable M-Instance Rules.
  4. Actuate actions in the Universe based on the current M-Instance situation.
  5. Perform actions in other M-Instances.

An M-Instance is a virtual space populated by Processes performing the speech acts – called Actions – specified by the MPAI Metaverse Model – Technologies (MMM-TEC) standard – on Processes and Items.

  • A Process is a program executed in an M‑Instance. User is a Process operating under the authority of a human. If driven by a human, it is called an H-User. If it has a degree of autonomy, it is called an A-User.
  • An Item represents a perceptible or abstract object in an M-Instance referenced by a unique Identifier.

Process1 can request Process2 to perform an Action on its behalf – because it may not be equipped with the necessary Capabilities or does not hold the necessary Rights or is prohibited by the Rules – by issuing a Process Action (PA). A PA is represented by the verb of the intended Action, followed by a set of one of the Nil, At, From, Of, or To prepositions each applied to an Item or a Process. For instance, to place its visible avatar at a position with an orientation, Process1 will say

MM-Add Nil Avatar, With SpatialAttitude, With PerceptStatus=1 With Requested Rights (Status=Model).

A Right is represented a deontic verb – May, May Not, or Must – followed by a Process Action. A Rule is represented by Process (identified by an ID or by Metadata) followed by a Right.

In general, mutual trust must be established between two Processes before they can interact. After this has been achieved by applying the Process Instance Trust Framework (MPAI-PTF) standard, they can interact and add Data Exchange Metadata to the payload to signal the legal and secure state and the Actions that the receiving Process is authorised to perform.

A PA may trigger other PAs. A typical case is when the requested Process can only be activated by performing a Transaction. MMM-TEC introduces a set of Items, such as Asset, an Item enabling the expression of capabilities, provenance, and economic metadata; Service Pricing Model, an Item supporting many service types; and Licence enabling various expressions of Rights granting to support the operation of virtual economies, .

A particularly important PA is Resolve, the mechanism that enables a Process in an M-Instance to establish a multi-M-Instance session with the participation of Processes located in different M-Instances.

Currently, MMM-TEC specifies some 100 Items. Some are univocally specified by MMM-TEC, but for the others MPAI specifies a Qualifier, i.e., a data type organised in SubTypes, Formats, and Attributes. For instance, the Machine Learning Qualifier has

  • SubTypes: MLModel, NNModel
  • Formats: Extension, Framework, Exchange
  • Attributes: Manifest, Regulation, Certification, Validity .

MPAI-MMM is currently at Version 2.2. Reference software is available for the preceding Version 2.0. Currently, two different implementations are being developed. One uses the graphical environment generated by Unity and the other uses Open Simulation. A Process in the former will be able to interact with a Process In the latter. In a separate project, MPAI is developing an A-User Architecture standard.

Technical Specification: The MPAI Metaverse Model (MPAI-MMM) – Technologies (MMM-TEC) standard specifies the technologies enabling a metaverse instance (M-Instance) – an Information and Communication Technologies (ICT) platform implementing the MMM-TEC specification – to interoperate with conforming and independently designed clients and M-Instances.

Short introduction – Long Introduction

A metaverse instance (M-Instance) is an Information and Communications Technology (ICT) system – an assembly of hardware, software, networks, and data system – populated by Processes performing, or requesting other Processes to perform, Actions on Items (representing various things) or other Processes.

An important type of Process is a User representing a human either directly (called an H-User) or indirectly and automatically (called an A-User). A human subscribed to a metaverse instance (M-Instance) can deploy Users there. Users may optionally be rendered as Personae, possibly human-like avatars.

A Process can influence a part of an M-Instance, called an M-Environment, by performing a Process Action, defined as:

  • One of the 29 Actions specified by the MMM-TEC V2.1 standard
  • Followed by a set of constructs, each composed of a sequence of
    • Complements: Nil (before a direct object), At, From, To, and With
    • Processes or Items
  • Followed by an If Event, a logical combination of Process Actions followed by At

Examples of Actions performed by a User:

  • To MM-Add an Item, i.e., to place it somewhere in an M-Instance
  • To MM-Move an Item, i.e., to displace it
  • To MM-Capture data from the real world
  • To MU-Actuate an Item to the real world, i.e., to render an Item in the real world
  • To Identify data, or to convert data into an Identified Item

A Process performs a Process Action if it:

  • Can perform it, i.e., it has the necessary Capabilities, and
  • Is entitled to perform it, i.e., it has the necessary Rights, where Rights are expressed by a Deontic Expression (May, May Not, Must) followed by a set of Process Actions, each preceded by At Time and If Event, and by one of the adjectives Internal, Acquired, or Granted. For example, a User may speak in a specific place, and
  • Is allowed to perform it by the Rules in force in the M-Environment, expressed by a Deontic Expression followed by a set of Process Actions, each preceded by At Time and If. For example, in a private space, a User must be granted appropriate Rights to perform any Process Action.

Internal Rights are obtained at registration Time (e.g., visitor Rights); Acquired Rights are typically obtained through Transactions (e.g., by buying a ticket to a concert); and Granted Rights are given by another Process (e.g., my friend’s User gives my User the Rights to enter his space).

A Process1 that is unable to perform a Process Action may request another Process2 to perform it on Process1’s behalf. Table 1 provides links to the specification of the general Process Action in such cases.

Table 1 – MMM-TEC V2.1 Process Actions

Authenticate Author Convert Discover Execute Hide
Identify Inform Interpret MM-Add MM-Animate MM-Move
MM-Send Modify MU-Actuate MU-Add MU-Animate MU-Move
MU-Send Post Property Change Register Resolve Rights Change
Transact UM-Capture UM-Send Validate

 

Short introduction – Long Introduction

Figure 1 depicts two interoperating M-Instances with the main elements standardised by the MMM-TEC standard.

Figure 1 – Main elements of an M-Instance

The main feature of an M-Instance is to be populated by Processes with the following attributes. (Links lead to specifications of the linked terms.)

  1. May be imported (UM-Send) by a human Registering with the M-Instance. To Register, a human
    1. Requests the opening of an Account of a certain class.
    2. May be requested to provide a Personal Profile and perform a Transaction.
    3. Obtains a set of Rights that Processes may exercise.
  2. Can operate with various degrees of autonomy and interactivity under the responsibility of the M-Instance Manager, of Third-Party Service Providers, or of humans who reside in the Universe, i.e., the real world.
  3. Can perform Actions on Items and/or Processes if permitted by the Rules of the M-Instance, where the name of an Action may begin with:
    1. MM: to indicate Actions performed inside the M-Instance, e.g., MM-Animate using a stream or a command to animate a 3D Model Object with a Spatial Attitude (defined in terms of Position, Orientation, and their velocities and accelerations).
    2. MU: to indicate Actions originated in the M-Instance but influencing the real-life Universe, e.g., MU-Add to place a physical object (R-Item) at a U-Location with a Spatial Attitude or to MU-Move it from a U-Location to another U-Location along a Trajectory.
    3. UM: to indicate Actions originated in the real-life Universe and influencing the M-Instance, e.g., UM-Capture to acquire Data by capturing a scene or an object at a U-Location using a Qualifier.
  4. Can perform Process Actions if the Process requests another Process. A Process Action is expressed by: a deontic verb – Action; a set of Complements (Nil/At/From/To/With); an ItemID/Item or ProcessID); and  If – Event where:
    1. Deontic verbs are May, May Not, and Must corresponding to Permission, Prohibition, or Obligation.
    2. The Complements (e.g., Nil, At, From, To With, etc.) are applied to:
      1. Items – i.e., Data that has been Identified in, and thus has been recognised by, the relevant M-Instance. This is the instance on which the Process Action is performed or which is required for the Action to be performed, such as an Asset, Audio Object, or Audio-Visual Scene. The relevant location is an M-Location and/or a U-Location.
      2. The Process on which the Action is performed.
    3. Items – i.e., Data Type instances Identified in the M-Instance.
    4. Event – i.e., a Process Action or its logic combination, e.g., to indicate that two Process Actions or at least one, and a Time at which the execution of a Process Action will take place.
  5. May hold Rights on Items or Processes, i.e., may perform the set of Process Actions that are listed as Rights. The notion of Rights may also be applied to an Item to signal which Processes may perform which Processes Actions on it. Rights have Levels, indicating that a specific set of Rights may be:
    1. Internal, e.g., assigned by the M-Instance at Registration time according to the M-Instance Rules and Account type.
    2. Acquired, e.g., obtained through the Process’s own initiative.
    3. Granted to the Process or Item by another Process.
  6. May request another Process to perform certain Process Actions using the Inter-Process Protocol. Such proxy action may be needed if the first Process lacks the necessary technology or Rights. Payment may be involved: a Value (i.e., an Amount in a Currency) may be transferred to the proxy’s Wallet.
  7. May respond, if requested, with Complements (Nil/At/From/To/With); Item or ProcessID; and  PA Status, where:
    1. The first two elements convey the result of the executed Process Action Request, and
    2. PA Status reflects success or failure in executing the Process Action Request.
  8. May expose its capabilities (Capabilities). These may also be used to declare the capabilities of an M-Instance.
  9. May be characterised as:
    1. Services providing specific functionalities, such as content authoring.
    2. Devices connecting the Universe to the M-Instance and the M-Instance to the Universe.
    3. Apps running on Devices.
    4. Users representing and acting on behalf of human entities residing in the real-life Universe and possibly rendered as a Persona, i.e., an avatar.

An M-Instance is managed by an M-Instance Manager. At creation time, the M-Instance Manager has Rights covering the M-Instance. The Manager may decide to define certain subsets inside the M-Instance, called M-Environments, on which it has Rights and to attach some Rights to them.