<-References Go to ToC Processes ->

(Informative)

This chapter introduces some of the basic design and operation principles on which the MMM-TEC specification is based. It is informative, but it it highly recommended to review it, as it includes elements that are important for proper understanding of the MMM-TEC specification.

A metaverse instance (M-Instance) is an Information and Communication Technologies (ICT) platform implementing the MMM-TEC specification. Its main feature is to be populated by Processes that:

  1. May be imported (UM-Sent) by a human Registering with the M-Instance. The human
    1. Requests to open 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.
    4. May need to have their Processes Certified to be allowed to import Processes..
  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 Process Actions – either on their initiative, or driven by the actions of humans or machines in the Universe that is expressed by: ProcessID – Action – set of Complements (Nil/At/From/To/With) – Item or ProcessID) At Time where:
    1. 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.
    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. Time the Process Action is performed.
  4. 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 the 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.
  5. May request another Process to perform the Process Actions in case the Process cannot (does not have the technology) or may not (does not have the Rights) to perform the Process Actions. The requested Process response is Complements  (Nil/At/From/To/With) – Item or ProcessID and PA Status, where:
    1. The first part conveys the result of the executed Process Action Request, and
    2. PA Status reflect success or failure in the Process Action Request execution.
  6. May expose its capabilities (P-Capabilities). A companion data type is M-Capabilities for M-Instances.
  7. 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.
  8. May request another Process to perform Process Actions on its behalf by using the Inter-Process Protocol, possibly after Transacting a Value (i.e., an Amount in a Currency) to a Wallet.

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. These are some of the functions that may be relevant to an M-Instance implementation and may be retained by an M-Instance Manager, e.g.:

  1. Management of the M-Instance.
  2. Establishment of M-Instance Rules.
  3. Installation and maintenance of Services.
  4. Definition of  Account Types.
  5. Monitoring of Process Actions
  6. Sanctions to infringers.
  7. Resolution of  conflicts.
  8. Certification of Processes and Data Types.

MMM-TEC defines an Event as a logical combination of Process Actions and a Rule as deontic expressions (Permission, Prohibition, or Obligation) to perform a Process Action. The deontic expression may depend on Time.

MMM-TEC does not specify how an M-Instance verifies that a Process’s Process Actions are compliant with the Process’s Rights or the M-Instance Rules. An M-Instance may decide to verify the full set of Activity Data (the log of Process Actions performed),  to make verifications based on claims by another Process, to make random verifications, or to not make any verification at all. Therefore, MMM-TEC does not specify how an M-Instance Manager can sanction non-complying Processes.

In some cases, an M-Instance could be wastefully too costly as an undertaking if all the MMM-TEC-specified technologies were mandatorily to be implemented, even if the particular M-Instance had limited scope. MMM-TEC specifies Profiles to facilitate the implementations of conforming M-Instances that are unduly burdened by the requirements of other application domains.

A Profile includes only a subset of the Actions and Items that are expected to be needed and are shared by a sizeable number of applications. MMM-TEC defines four Profiles (see Figure 1):

  1. Baseline Profile enables basic applications such as lecture, meeting, and hang-out.
  2. Finance Profile enables trading activities.
  3. Management Profile 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.

Figure 1 – MMM-TEC V2.0 Profiles

MPAI developed and used some use cases in the two MPAI-MMM Technical Reports published in 2023 and developed to facilitate the MMM-ARC and MMM-TEC Technical Specifications. However, the Verification Use Cases have been included in MMM-TEC V2.0 to verify that the currently specified Actions and Items support those Use Cases.

Figure 2 gives a summary view of some of the basic MMM-TEC elements.

Figure 2 – Main elements of an M-Instance

The fast development of certain technology areas is one of the issues that has so far prevented the development of metaverse standards. MMM-TEC deals with this issue by providing JSON Schemas and semantics for all Items. A JSON Schema may reference Qualifiers, MPAI-defined Data Types that provide additional information to the Data in the form of:

  1. Sub-Type (e.g., which colour space is used in a Visual Data Type).
  2. Format (e.g., which compression or file/streaming format is used in a Speech Data Type).
  3. Attributes (e.g., which Binaural Cues are used in an Audio Data Type).

For instance, a Process receiving an Object can understand from the Qualifier referenced in the Object’s JSON data whether it has the required technology to process it, or else it has to Convert it to obtain a version of the Object matching its P-Capabilities. This approach helps prolong the life of the MMM-TEC specification as in many cases only the Qualifier specification will need to be updated and not the MMM-TEC specification.

<-References Go to ToC Processes ->