An Introduction to the MPAI Metaverse Model Architecture – Part I

This is the first of a series of posts that illustrate the Call for Technologies: MPAI Metaverse Model – Architecture, a document inviting interested parties to submit comments to and proposals for Use Cases and Functional Requirements: MPAI Metaverse Model – Architecture. The goal is to facilitate the task of those who wish to contribute to the first “Metaverse Architecture” standard ever attempted by a standards body.

Before starting, let’s clarify why is MPAI, a standards body developing standards for AI-based data coding, engaged in the “metaverse”? The answer is manifold:

1. The metaverse will require a range of technologies that deal with data and their transformations, i.e., data coding.
2. The metaverse is thus and excellent source of valuable standard projects.
3. MPAI has already a few standards that respond to specific metaverse needs.
4. The metaverse is thus also an excellent technology integration platform.

Note that the word metaverse is used here to mean the “metaverse notion” while Metaverse Instance (M-Instance) indicated a “specific implementation” of the MPAI Metaverse Model Architecture (in the following: MPAI-MMM). An M-Instance is considered as a set of Processes providing some or all the following functions:

1. To sense data from U-Locations.
2. To process the sensed data and produce Data from the sensed data and/or autonomously.
3. To produce one or more M-Environments populated by Objects that can be either digitised or virtual, the latter with or without autonomy.
4. To process Objects from the M-Instance or potentially from other M-Instances to affect U- and/or M-Environments using Object in ways that are:
   • Consistent with the goals set for the M-Instance.
   • Effected within:
     • The capabilities of the M-Instance
     • The Rules set for the M-Instance.

The above gives the opportunity to highlight the convention that word beginning with a capital letter are defined here while those beginning with a small letter have the normal meaning of the context.

Some terms are more important than others, so let’s report a few of them here:

1. A Process is Program and Metadata that can be executed in the M-Instance to perform Actions on Items.
2. An Action is a supported Functionality that is performed in an M-Instance.
3. An Item is Data and Metadata supported by the M-Instance where the Item exists.
4. Metadata adds information on a Process of an Item and may include Rights.
5. Rights define:
   • The ability of a Process to perform Actions on Items.
   • The possibility that an Item be subjected to an Action by a Process.
6. An Item may include Rights held by User and Rights that it may be possible to acquire on the Item.
7. Data Types are data referenced by Actions and Items.

We are now able to list the first Functionalities of an M-Instance:

An M-Instance is a set of Processes providing some or all the following functions:

1. Senses data from U-Location.
2. Produces Items autonomously or by processing the sensed data.
3. Hosts one or more M-Environments populated by Objects that can be either digitised or virtual, the latter with or without autonomy.
4. Processes Objects from the M-Instance or potentially from other M-Instances to affect U- and/or M-Environments using Objects in ways that are:
   • Consistent with the goals set for the M-Instance.
   • Effected within the capabilities and Rules of the M-Instance, and in accordance with applicable laws and regulations.
5. Identifies Processes and Items with one or more than one Identifier each of which uniquely refers to one Process or Item.
6. May contain one or more M-Environments each of which:
   • Includes an Identifier.
   • May include M-Locations with space and time attributes.
   • May require a Registration specific to the M-Environment.
7. May make available information regarding its Capabilities.
8. May require Registration for use:
   • A human can request to deploy one or more Users and one or more Personae in an M-Instance.
   • An M-Instance may request a subset of the Personal Profile of the Registering human.
9. Establishes Rules that human’s Users in the M-Instance shall comply with.
10. May penalise a User for lack of compliance with the Rules.

MPAI-MMM – Architecture identifies the following types of Process (see Figure 1):

1. User represents a human rendered as:
   • A Model (Persona) animated by a stream generated by the human or by an autonomous agent. A User may be rendered by one or more Personae.
   • An Object rendering the human.
2. Device connects User with a human or a U-Location:
   • From the Universe to an M-Instance: captures a scene as Media and Provides Media as Data and Metadata:
   • From an M-Instance to the Universe: receives an Entity and renders it as Media with a Spatial Attitude.
3. Service provides Functionalities.
4. App is a Program executed on a Device.

Figure 1 – Relationship of Human-Device-User-Service-Persona

Figure 1 highlights a few basic aspects:

1. A human is connected to one of its potentially many digital counterparts (Users).
2. An object has one or more digital correspondents (Objects).
3. A User can be rendered as a Persona (possibly more than one).
4. Processes, in particular Users, can interact with one another.

Processes play an important role. Here are some features of a Process:

1. Performs Actions on Items if it has the Rights to do that.
2. Can make available information about its Capabilities.
   • The Actions it can Perform.
   • The Items on which Actions can be performed.
   • The time during which they can be performed.
   • The M-Locations where they can be performed.
3. Can request another Process to perform Actions on Items by transmitting to it a Request-Action Item.
4. Can be requested to perform an Action and it does so if:
   • The requesting Process has the Rights required to perform that request, e.g., it has made a Transaction to acquire the Rights, the Rights is part of the set of Rights assigned at Registration time, etc.
   • The requested Process has the Rights to perform the requested Action on the Item.
5. Can respond to the Process requesting an Action with a Response-Action Item (see Figure 2).
6. Uses a supported format:
   • To request another Process to perform Actions on Items (Request-Action).
   • To respond to another Process that has requested an Action (Respond-Action).
7. May perform, or to request other Processes to perform, Actions on Items even in the absence of Rights, if the Rules so allow.
8. May need to be certified by the M-Instance Manager for use in an M-Instance.

Figure 2 – Processes requesting Action and responding to request

An M-Instance is typically administered by a single Manager that makes decisions about the technologies that fit the best with the entity’s needs. Two independent Managers need not make the same technology choices. The following workflow enables interoperability between Metaverse_A and Metaverse_B when Process_A in Metaverse_A requests Process_B in Metaverse_B to perform Action on an Item_A.1, the following (Note: RS=Resolution Service, CS=Conversion Service).

1. Process_A transmits Request-Action₁ to R­S_A.
2. RS_A transmits Request-Action₁ to RS_B.
3. RS_B transmits Item₁ to CS.
4. CS produces and transmit Item₂ containing Converted Data to RS_B.
5. RS_B transmits the new Request-Action₂ to Process_B.
6. Process_B
   • Performs the Action specified in Request-Action₂ using Item_A.2.
   • Produces Response-Action₂.
   • Requests RS_B to transmit to RS_A Response-Action₂ containing Item_A.3 (result of performing Request-Action_A.2).
   • RS_B transmits Response-Action₂ to RS_A.
   • RS_A transmits Item₃ to CS.
   • CS produces and transmits to RS_A Item₄, corresponding to Item_A.3 with converted Data.
   • RS_A produces and transmits to Process_A a new Response-Action₄ that references Item_A.4.

It should be noted that an M-Instance may allow Processes to communicate directly with Processes in other M-Instances without calling ResolutionService_A.

Given the above, what is then the scope of the MPAI-MMM Architecture Call for Technologies?

To make comments on, add functionalities to, or propose new elements to the MPAI Metaverse Model Architecture.

Join the online presentation on 23 June at 08 and 15 UTC. Register here for the first or here for the second presentation.