<-References      Go to ToC      Processes ->

(Informative)

MPAI-MMM, in the following also called MMM, indicates the combined MMM-ARC and MMM-TEC Technical Specifications for M-Instance interoperability. It defines a metaverse instance (M-Instance) as a platform offering a subset or all of the following functions:

  1. Senses Data from a M-Instance of the Universe, i.e., the real world.
  2. Transforms the sensed Data into processed Data.
  3. Produces one or more M-Environments (i.e., subsets of an M-Instance) populated by Objects that can be one of the following:
    1. Digitised – sensed from the Universe – possibly animated by activities in the Universe.
    2. Virtual – imported or internally generated – possibly autonomous or driven by activities in the Universe.
    3. Mixed.
  4. Acts on Objects from the M-Instance or potentially from other M-Instances on its initiative, or driven by the actions of humans or machines in the Universe.
  5. Affects U- and/or M-Environments using Objects in ways that are:
    1. Consistent with the goals set for the M-Instance.
    2. Within the Capabilities of the M-Instance (M-Capabilities).
    3. According to the Rules of the M-Instance.
    4. Respecting applicable laws and regulations.

The functionalities of an M-Instance are provided by a set of Processes performing Actions on Items (i.e., instances of MMM-specified Data Types that have been  Identified in the M-Instance) with various degrees of autonomy and interaction. An implementation may merge some MMM-specified Processes into one or split an MMM-specified Process into more than one process provided that the resulting system behaves as specified by MMM.

Some Processes exercise their activities strictly inside the M-Instance, while others have various degrees of interaction with Data sensed from or actuated in the Universe. Processes 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. A User (but other types of Process as well) may be rendered as a Persona, i.e., a static or dynamic avatar.

Processes perform their activities by communicating with other Processes or by performing Actions on Items. Examples of Items are Asset, 3D Model, Audio Object, Audio-Visual Scene, etc. MMM specifies the Functional Requirements of some 30 Actions, i.e., Functionalities that are performed by Processes, and some 60 Items.

A Process holds a list of Process Actions, each of which expresses the Action that the Process has performed or may perform on certain Items at certain M-or U-Locations (areas of the virtual and real world, respectively) during certain Times.

For convenience, prefixes are added to Action names:

  1. MM indicates Actions performed inside the M-Instance, e.g., MM-Animate is the Action that uses a stream to animate a 3D Model with a Spatial Attitude (defined as Position, Orientation, and their velocities and accelerations).
  2. MU indicates Actions in the M-Instance influencing the Universe, e.g.,  MU-Actuate is the Action of a Device rendering one of its Items to a U-Location as Media with a Spatial Attitude.
  3. UM indicates Actions in the Universe influencing the M-Instance, e.g., UM-Embed is the Action of placing an Item produced by Identifying a scene, UM-Capture.d at a U-Location, at an M-Location with a Spatial Attitude.

Some Actions, such as UM-Embed, are Composite Actions, i.e., combinations of Basic Actions.

Rights are a basic notion underpinning the operation of the MMM and are defined as the list of combinations of Process Action and Level. Process Action is an Item including Action, the Items on which it can be performed, the M-Locations or U-Locations where it can be performed and the Times during which it can be performed. Levels indicate that the Rights are Internal, i.e., assigned by the M-Instance at Registration time, Acquired, i.e., obtained by initiative of the Process, or Granted to the Process by another Process. The way an M-Instance verifies the compliance of a Process to its Rights in not specified. An M-Instance can decide to verify the Activity Data (the log of all performed Process Actions) based on claims by another Process, to make random verifications or to not make any verification at all.

A Process can request another Process to perform an Action on its behalf by using the Inter-Process Protocol. If the requested Process is in another M-Instance, it will use the Inter-M-Instance Protocol to request a Resolution Service of its M-Instance to establish a communication with another Resolution Service in the other M-Instance. The Backus Naur form of the MMM-Script enables efficient communication between Processes.

Figure 1 gives a summary view of these basic MMM notions.

Figure 1 – Inter-Process/M-Instance Communication

To be admitted to an M-Instance, a human may be requested to provide a subset of their Personal Profile and to Transact a Value (i.e., an Amount in a Currency). The M-Instance then grants certain Rights to identified Processes of the Registered human, including the import of Personae (i.e., their avatars) for their Users.

The fast development of certain technology areas is one of the issues that has prevented the development of standards for metaverse interoperability. MMM deals with this issue by providing the JSON syntax and semantics for all Items. When needed, the JSON syntax references Qualifiers, MPAI-defined Data Types that provide additional information to the Data Type in the form of:

  1. Sub-Type (e.g., the colour space of a Visual Data Type).
  2. Format (e.g., the compression or the file/streaming format of Speech).
  3. Attributes (e.g., the Binaural Cues of an Audio Object).

An M-Instance or a Client receiving a Visual Object can understand whether it has the required technology to process that Visual Object, or else it should rely on a Conversion Service to obtain a version of the Object suitable to the M-Instance or Client.

A M-Instance can be a costly undertaking if all technologies required by the MMM Technical Specification need to be implemented even for M-Instances of a limited scope. MMM-Profiles are introduced to facilitate the take-off of the metaverse. A Profile only includes a subset of Actions and Items that are expected to be needed by a sizeable number of applications. MMM defines four Profiles:

  1. Baseline Profile enables a human equipped with a Device supporting the Baseline Profile that enables basic applications such as lecture, meeting, and hang-out.
  2. Finance Profile enables a human equipped with a Device supporting the Finance Profile to perform trading activities.
  3. Management Profile includes the functionalities of the Baseline and Finance Profiles and enables a controlled ecosystem with more advanced functionalities.
  4. High Profile enables all the functionalities of the Management Profile with a few additional functionalities of its own.

MPAI  did develop some use cases in the two MPAI-MMM Technical Reports published in 2022. They were used to develop the MMM-ARC and MMM-TEC Technical Specifications. MMM includes several Verification Use Cases  that use MMM-Script to verify that the currently specified Actions and Items enable full support of those identified Use Cases.

 

<-References    Go to ToC    Processes ->