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.