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

Short introduction – Long Introduction

A metaverse instance (M-Instance) as an ICT system populated by Processes performing or requesting other Processes to perform Actions on Items (representing a variety of things) or other Processes.

An important type of Process is a User representing a human either directly (called an H-User) or indirectly (called an A-User). A human subscribed to an M-Instance can deploy Users in that M-Instance that may or may not also be rendered as Personae, possibly human-like avatars.

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

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

Examples of Action performed by a User are:

  • MM-Add an Item, i.e., place it somewhere in an M-Instance.
  • MM-Move an Item, i.e., displace it.
  • MM-Capture data from the real world.
  • MM-Actuate Item to the real world
  • Identify data, 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
  • May 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 is not allowed to perform any Process Action without being Granted appropriate Rights.

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 Rights to enter his space).

A Process unable to perform a Process Action may request another Process to perform it on its behalf. Table 1 provides links to the specification of the general Process Action, i.e., when the Action results from the request to another Process.

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 MMM-TEC.

Figure 1 – Main elements of an M-Instance

The main feature of an M-Instance is to be populated by Processes that (links are to the specification of the term):

  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 their Personal Profile and perform a Transaction.
    3. Obtains set of Rights that their Processes may exercise.
  2. Operate with various degrees of autonomy and interactivity under the responsibility of the M-Instance Manager, Third-Party Service Providers, or humans who reside in the Universe, i.e., the real world.
  3. Perform Actions on Items and/or Processes if permitted by the Rule 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 as Position, Orientation, and their velocities and accelerations).
    2. MU: to indicate Actions originated in the M-Instance but influencing the 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 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. Perform Process Actions if the Process requests another Process. A Process Action is expressed by: deontic verb – Action – set of Complements (Nil/At/From/To/With) – ItemID/Item or ProcessID) –  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 recognised by, the M-Instance on which the Process Action is performed or is required for the Action to be performed, such as Asset, Audio Object, Audio-Visual Scene, and where (M-Location and/or U-Location).
      2. 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 a logic combination thereof and Time whose performance triggers the execution of a Process Action.
  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 is:
    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 by initiative of the Process.
    3. Granted to the Process or Item  by a Process.
  6. May request another Process to perform the Process Actions using the Inter-Process Protocol, possibly after Transacting a Value (i.e., an Amount in a Currency) to a Wallet, in case the Process cannot (does not have the technology) or may not (does not have the Rights) to perform the Process Actions.
  7. May respond, if requested, with Complements  (Nil/At/From/To/With) – Item or ProcessID – PA Status, where:
    1. The first part conveys 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) that may also be used to expose 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 Universe and possibly rendered as a Persona, i.e., an avatar.

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