This is the first of a series of posts that illustrate 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 . “MPAI Metaverse Model Architecture” is 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:
- The metaverse will require a range of technologies that deal with data and their transformations, i.e., data coding.
- The metaverse is thus and excellent source of valuable standard projects.
- MPAI has already a few standards that respond to specific metaverse needs.
- 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:
- To sense data from U-Locations.
- To process the sensed data and produce Data from the sensed data and/or autonomously.
- To produce one or more M-Environments populated by Objects that can be either digitised or virtual, the latter with or without autonomy.
- 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:
- A Process is Program and Metadata that can be executed in the M-Instance to perform Actions on Items.
- An Action is a supported Functionality that is performed in an M-Instance.
- An Item is Data and Metadata supported by the M-Instance where the Item exists.
- Metadata adds information on a Process of an Item and may include Rights.
- 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.
- An Item may include Rights held by User and Rights that it may be possible to acquire on the Item.
- 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:
- Senses data from U-Location.
- Produces Items autonomously or by processing the sensed data.
- Hosts one or more M-Environments populated by Objects that can be either digitised or virtual, the latter with or without autonomy.
- 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.
- Identifies Processes and Items with one or more than one Identifier each of which uniquely refers to one Process or Item.
- 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.
- May make available information regarding its Capabilities.
- 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.
- Establishes Rules that human’s Users in the M-Instance shall comply with.
- May penalise a User for lack of compliance with the Rules.
MPAI-MMM – Architecture identifies the following types of Process (see Figure 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.
- 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.
- Service provides Functionalities.
- App is a Program executed on a Device.
Figure 1 – Relationship of Human-Device-User-Service-Persona
Figure 1 highlights a few basic aspects:
- A human is connected to one of its potentially many digital counterparts (Users).
- An object has one or more digital correspondents (Objects).
- A User can be rendered as a Persona (possibly more than one).
- Processes, in particular Users, can interact with one another.
Processes play an important role. Here are some features of a Process:
- Performs Actions on Items if it has the Rights to do that.
- 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.
- Can request another Process to perform Actions on Items by transmitting to it a Request-Action Item.
- 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.
- Can respond to the Process requesting an Action with a Response-Action Item (see Figure 2).
- 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).
- May perform, or to request other Processes to perform, Actions on Items even in the absence of Rights, if the Rules so allow.
- 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 MetaverseA and MetaverseB when ProcessA in MetaverseA requests ProcessB in MetaverseB to perform Action on an ItemA.1, the following (Note: RS=Resolution Service, CS=Conversion Service).
- ProcessA transmits Request-Action1 to RSA.
- RSA transmits Request-Action1 to RSB.
- RSB transmits Item1 to CS.
- CS produces and transmit Item2 containing Converted Data to RSB.
- RSB transmits the new Request-Action2 to ProcessB.
- Performs the Action specified in Request-Action2 using ItemA.2.
- Produces Response-Action2.
- Requests RSB to transmit to RSA Response-Action2 containing ItemA.3 (result of performing Request-ActionA.2).
- RSB transmits Response-Action2 to RSA.
- RSA transmits Item3 to CS.
- CS produces and transmits to RSA Item4, corresponding to ItemA.3 with converted Data.
- RSA produces and transmits to ProcessA a new Response-Action4 that references ItemA.4.
It should be noted that an M-Instance may allow Processes to communicate directly with Processes in other M-Instances without calling ResolutionServiceA.
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.