You are currently viewing Technical Report – MPAI Metaverse Model – Functionality Profiles

Technical Report – MPAI Metaverse Model – Functionality Profiles

  • Post author:
  • Post category:MPAI


MPAI has developed a roadmap for Metaverse interoperability. The published Technical Report – MPAI Metaverse Model – Functionalities [1] claims that, as standards for a market as vast as the one expected for the Metaverse are difficult to develop, functional profiles should be developed. The published draft Technical Report – MPAI Metaverse Model – Functionality Profiles [2] develops a Metaverse functional operation model, applies it to 7 Use Cases and proposes 4 initial functionality profiles. This document is a concise summary of [2].


1       Introduction

2       A functional operation model

3       Actions

4       Items

5       Data Types

6       Use cases

6.1        AR Tourist Guide

6.2        Virtual Dance

7       Initial functionality profiles

8       Conclusions

9       References

1        Introduction

The MPAI Metaverse Model (MPAI-MMM) aims to provide Technical Reports and Technical Specifications that apply to as many kinds of Metaverse instances as possible and enable varied Metaverse implementations to interoperate.

At present, achieving interoperability is difficult because:

  1. There is no common understanding of what a Metaverse is or should be, in detail.
  2. There is an abundance of existing and potential Metaverse Use Cases.
  3. Some independently designed Metaverse implementations are very successful.
  4. Some important technologies enabling more advanced and even unforeseen forms of the Metaverse may be uncovered in the next several years.

MPAI has developed a roadmap to deal with this challenging situation. The first milestone of the roadmap is based on the idea of collecting the functionalities that potential Users expect the Metaverse to provide, instead of trying to define what the Metaverse is. The first Technical Report of this roadmap [1] includes definitions, makes assumptions for the MPAI-MMM project, identified sources that can generate functionalities, develops an organised list of commented functionalities, and analyses the main enabling technologies. Reference [3] provides a summary of [1].

Potential Metaverse Users with different needs might require different technologies to support these needs. Therefore, an approach that tried to achieve the goal of making every M-Instance be able to interoperate with every other M-Instance would force implementers to take technologies on board that are useless for their needs and potentially costly.

Reference [1] posits that Metaverse standardisation should be based on the notion of Profiles[1] and Levels[2] successfully adopted by digital media standardisation. A Metaverse Standard that includes Profiles and Levels would enable Metaverse developers to use only the technologies they need that are offered by whatever profile is most suitable to them.

The notion of profile can mitigate the impact of having many disparate Metaverse Users with diverse requirements. Unfortunately, that notion cannot be currently implemented because some key technologies are not yet available and at this time it is unclear which technologies, existing or otherwise, will eventually be adopted. To cope with this situation, [2] only targets Functionality Profiles, i.e., profiles that are defined by the functionalities they offer, not by technologies implementing them. Functionality Profiles are not meant to fully address the interoperability problem, but rather to allow a technology-independent definition of profiles based on the functional value they provide rather than on the “influence” of specific technologies.

2        A functional operation model

A Metaverse instance – called M-Instance – is composed of interacting Processes within and without the M-Instance. An M-Instance interoperates with another M-Instance to the extent its Processes interoperate.

MPAI has identified 3 classes of Process:

  1. Users: Processes that represent humans using data from the real world (U-Locations) or autonomous agents (both need not be human-like).
  2. Devices: Processes interconnecting U-Locations to M-Locations and vice-versa.
  3. Services: Processes providing Functionalities.

A Process performs or requests another Process to perform Actions on Items. Item is data with attached metadata possibly including Rightss enabling a Process to perform Actions on. Rights express the ability to perform an Action on an Item.

The names of some Actions are prefixed depending on where Action is performed:

  1. MM- if the interAction takes place in Metaverse.
  2. UM- if the interAction is between Universe to Metaverse (Universe is the real world).
  3. MU- if the interAction is between Metaverse to Universe.

An interAction of Process #1 with Process #2 unfolds as follows:

  1. Process #1 requests Process #2 to performs Actions on Items.
  2. Process #2 executes the request if Process #1 has Rightss to call Process #2.
  3. Process #2 responds to Process #1’s request.

Note that Processes and Items need not be in the same M-Instance. However, the possibility of having Actions performed on Items may be more limited if they are not in the same M-Instance.

Figure 1 depicts a Metaverse configuration with interacting Processes.

Figure 1- A Metaverse configuration

Devices connect humans and objects in a U-Location (a location in the real world – called Universe) to one or more Metaverse Service generating M-Instances as depicted in Figure 2.

Figure 2 – The relationship between the real world (Universe) and M-Instances

A Device UM-Captures scenes with its Sensors and MU-Render Entities (i.e., Item that can be perceived) though their Actuators.

To enable its User(s) to perform Actions in an M-Instance, a human may be asked to Register and provide a subset of their User data, e.g., Persona(e) and ID(s) of Wallet. The M-Instance provides an Account that univocally associates a Registered human with their Items with the following features:

  1. A human may have more than one Account in more than one M-Instance.
  2. A User has Rightss to act in the M-Instance associated with the human’s Account.
  3. A human may have more than one Account and more than one User per Account.
  4. A User exists after a human Registers with an M-Instance.
  5. Different Users of an Account may have different Rightss.

The Rules of an M-Instance express the obligations undertaken by the Registering human represented by the User and the terms and conditions under which a User exists in an M-Instance and operates either there or in another M-Instance. Depending on the Rules, a User of a human Registered on an M-Instance may or may not interact with another M-Instance and Rightss enforcement on some Actions performed on some Items may be forfeited.

Data entering an M-Instance, e.g., by Reading or MM-Capturing may include metadata and the Rightss granted to a Process to perform Actions on the data.

Items bear an Identifier is uniquely associated to that Item. However, an Item may bear more than one identifier. It is assumed that identifiers have the following structure:

[M-InstanceID] [ItemID]; [M-InstanceID] [M-LocationID] [ItemID].

3        Actions

A User can call a Process to perform Actions on Entities. An Entity can be:

  1. Authored, i.e., the User calls an Authoring Tool Service with an accompanying request to obtain Rights to act on the authored Entity.
  2. MM-Added, i.e., the User requests that an Entity be added to an M-Location with a Spatial Attitude.
  3. MM-Enabled, i.e., the User requests that a Process be allowed to MM-Capture an Entity that is MM-Added at an M-Location.
  4. MM-Embedded, i.e., MM-Added and MM-Enabled in one stroke.
  5. MM-Captured, i.e., the User requests that an Entity MM-Embedded at an M-Location be MM-Sent to a Process.
  6. UM-Animated, i.e., the User requests that a Process change the features of an Entity using a Stream of data.
  7. MM-Disabled, i.e., the User requests that the MM-Enabling of the Entity be stopped.
  8. Authenticated, i.e., the User calls a Service to make sure that an Item is what it claims to be.
  9. Interpreted, i.e., the User calls a Service to obtain an interpretation of Items in an M-Instance, e.g., translate a Speech Object MM-Embedded at an M-Location into a specific language.
  10. Informed, i.e., the User calls a Service to obtain data about an Item.

An example of composite Action, i.e., an Action that involves a plurality of Actions and a plurality of Items is Track that enables a User to request Services to:

  1. MM-Add a Persona at an M-Location with a Spatial Attitude.
  2. UM-Animate the Persona MM-Added at an M-Location.
  3. MU-Render specified Entities at the M-Location to a U-Location with Spatial Attitudes.

So far, the following Actions have been identified:


Of course, the Actions identified are not intended to be the only ones that will be needed by all M-Instances.

A Process requests another Process to perform an Action sending the following payload.

SourceUser (ID=UserID) ∨ Device (ID=DeviceID) ∨ Service (ID=ServiceID)
DestinationUser (ID=UserID) ∨ Device (ID=DeviceID) ∨ Service (ID=ServiceID)
InItemItem (ID=ItemID)
InLocationsM-LocationID ∨ U-LocationID ∨ Service (ID=ServiceID)
OutLocationsM-LocationID ∨ U-LocationID ∨ Device (ID=DeviceID) ∨ Service (ID=ServiceID)
OutRightsRights (ID=RightsID)

The requested Process will respond by sending the following payload:

SuccessOutItemItem (ID=ItemID)
RightsMissing or incomplete
UnsupportedItem not supported
MismatchItem type mismatch
User DataFaulty
WalletInsufficient Value
ClashEntity clashes with another Entity
M-LocationOut of range
U-LocationOut of range

4        Items

An Item can be:

  1. Created: from data and metadata. Metadata may include Rights.
  2. Changed: its Rightss are modified.
  3. Discovered by calling an appropriate Service.
  4. Written, i.e., stored.
  5. Posted as an Asset (i.e., an Item that can be the object of a Transaction to a Marketplace) to a marketplace.
  6. Transacted as an Asset.

An Item can belong to one of six categories:

  1. Items characterised by the fact that they can be MM-Captured by a User.
  2. Items that can cause an Entity to change its perceptible features.
  3. Items that have space and time attributes.
  4. Items that are finance related.
  5. Items that are non-perceptible.
  6. Items that are Process-related.

Entities are Items that can be perceived. Here are some relevant Items.

  1. Event: the set of Entities that are MM-Embedded at an M-Location from Start Time until End Time.
  2. Experience: An Event as a User MM-Captured it and the User’s Interactions with the Entities belonging to the Entity that spawned the Event.
  3. Object: the representation of an object and its features. Currently, only the following object types are considered: Audio, Visual, and Haptic.
  4. Model: An Object that can be UM-Animated by a Stream or a Process. A Persona is the Model of a human.
  5. Scene: a dynamic composition of Objects described by Times and Spatial Attitudes.

The finance-related Items are:

  1. Asset: An Item that may be the object of a Transaction and is embedded at an M-Location or Posted to a Service.
  2. Ledger: the list of Transactions executed on Assets.
  3. Provenance: the Ledger of an Asset.
  4. Transaction: Item representing the changed state of the Accounts and the Rights of a seller User and a buyer User on an Asset and optionally of the Service facilitating/enabling the Transaction.
  5. Value: An Amount expressed in a Currency.
  6. Wallet: A container of Currency units.

So far, the following Items have been identified:

2Activity Data12M-Instance22Request-Discover32Service
3App13M-Location23Request-Inform33Social Graph
8Identifier18Personal Profile28Response-Interpret38User Data

Of course, more Items will be identified as more application domains will be taken into consideration.

Each Item is specified by the following table. It should be noted that, in line with the assumptions made by the MPAI Metaverse roadmap and the current focus on functionalities, the formats of the Item Data are not specified.

PurposeA functional description of the Item.
DataIn general, the Item data format(s) is(are) not provided.
Acted on Metadata
ItemIDID of the Item.
UserIDID of the User who holds Rights on the Item with ItemID.
WalletIDID of the Wallet held by User with UserID
InRightsIDID of the Rights the User with UserID has on the Item with ItemID.
OutRightsIDID of the Rights a User may acquire on the Item with ItemID.
AuthorIDID of the User who Authored the Item with ItemID.
AuthorToolIDID of the Service who provided the AuthorTool.
ParentItemIDID of the Item that spawned the Item.
ServiceIDID of the Service that is Called.
ServiceWalletIDID of the Wallet of a Service.
ActedOnItemIDID of the Item that was Acted on.
TargetUserIDID of the User to be affected by the Action.
TargetWalletIDID of the Wallet of the User to be affected by the Action.
UserDataIDID of a User Data.
PersonaIDID of a User’s Persona.
PersonalDataIDID of a User’s Personal Data.
ActivityDataIDID of a User’s Activity Data.
DescrMdataAny additional descriptive Metadata of the Item.

5        Data Types

Data Types are data that are referenced in Actions or in Items. Currently, the following data types have been identified.

  1. Address
  2. Amount
  3. Coordinates
  4. Currency
  5. Personal status
    1. Cognitive state
    2. Emotion
    3. Social attitude
  6. Point
  7. Spatial attitude
    1. position
    2. orientation
  8. Time

6        Use cases

So far 7 Use Cases have been developed to verify the completeness of Actions, Items and data types specified. Use cases are also a tool that facilitates the development of functionality profiles.

To cope with the fact that Use Cases may involve several locations and Items, a notation has been developed exemplified by the following:

  1. Useri MM-Embeds Persona1, Personai.2, etc.
  2. Useri Calls Process1, Processi.2, etc.
  3. Useri MM-Embeds Personaj, at M-Locationi.1, M-Locationi.2, etc.
  4. Useri MU-Renders Entityj at U-Locationi.1, U-Locationi.2, etc.
  5. Useri MM-Sends object2 to Userj.

The following is to be noted:

Note1A = Audio, A-V = Audio-Visual, A-V-H = Audio-Visual-Haptic, SA=Spatial Attitude.
Note2If a Composite Action is listed, its Basic Actions are not listed, unless they are independently used by the Use Case.

Here only two of the seven Use Cases of [2] will be presented.

6.1       AR Tourist Guide

6.1.1      Description

This Use Case describes a human who intends to develop a tourist application through an App that alerts the holder of a smart phone where the App is installed and lets them view Entities and talk to autonomous agents residing at M-Locations:

  1. User1
    1. Buys M-Location1 (parcel) in an M-Environment.
    2. Creates Entity1 (landscape suitable for a virtual path through n sub-M-Locations).
    3. Embeds Entity1 (landscape) on M-Location1.1 (parcel).
    4. Sells Entity1 (landscape) and M-Location1.1 (parcel) to a User2.
  2. User2
    1. Authors Entity1 to Entity2.n for the M-Locations.
    2. Embeds the Entities at M-Location1 to M-Location2.n.
    3. Sells the result to User3.
  3. human4
    1. Develops
      1. Map recording the pairs M-Locationi – U-Location2.i
      2. App alerting a human5 holding the Device with the App installed that a key U-Location has been reached.
    2. Sells Map and App to human3.
  4. User3 MM-Embeds one or more autonomous Personae at M-Location1 to M-Location2.n.
  5. When human5 gets close to a key U-Location:
    • App prompts Device to Request User3 to MU-Render the Entityi MM-Embedded at M-Location2.i to the key U-Location2.i.
    • human5 interacts with MU-Rendered Entityi that may include an MM-Animated Persona2.i.

6.1.2      Workflow

Table 1 – AR Tourist Guide workflow.

User1TransactsM-Location1.1(Parcel in an M-Environment)
AuthorsEntity1.1(A landscape for the parcel)
TransactsEntity1.1User2 (landscape)
TransactsM-Location1.1User2 (parcel)
User2AuthorsEntity2.1 to Entity2.nPromotion material for U-Locations.
MM-EmbedsEntity2.1 to Entity2.nM-Location2.1 to Location 2.n
TransactsEntity1.1User4 (landscape)
TransactsM-Location1.1User4 (parcel)
TransactsEntity2.1 to Entity2.nUser4
sellsMap and AppTo human4
User4MM-EmbedsPersona4.1-Persona4.nM-Location2.1 to Location 2.n w/ SA
MM-AnimatesPersona4.1-Persona4.nM-Location2.1 to M-Location2.n
human5downloadsApp(To Device)
approachesU-Location2.i(App’s key point)
Device5.1MM-SendMessage5.1User4 (Persona4.i)
human5interacts(W/ MU-Rendered Entity4.i and Persona4.i)

6.1.3      Actions, Items, and Data Types

ActionsItemsData Types
MM-SendMapSpatial Attitude
MU-RenderM-LocationSpatial Attitude

6.2       Virtual Dance

6.2.1      Description

  1. User2 (dance teacher)
    • Teaches dance at a virtual classroom.
    • Works at M-Location1 where its digital twin Persona2.1 is Audio-Visually MM-Embedded.
    • MM-Embeds and MM-Animates Persona2 (A-V) (another of its Personae) at M-Location2.2 as virtual secretary to attends to students coming to learn dance.
  2. User1 (dance student #1):
    • MM-Embeds its Persona1 (A-V) at Location1.1 (its “home”).
    • Audio-Visual-Haptically MM-Embeds Persona1 (A-V-H) at Location1.2 close to Location2.2.
    • Sends Object1 (A) to Persona2.2 (greets virtual secretary).
  3. Virtual secretary:
    • Sends Object1 (A) to dance students #1 (reciprocates greeting).
    • Send Object2 (A) to call regular dance teacher’s Persona2.1.
  4. Dance teacher MM-Embeds (A-V-H) Persona1 at Location2.3 (classroom) where it dances with Persona1.1 (dance student #1).
  5. While Persona1 (student #1) and Persona2.1 (teacher) dance, User3 (dance student #2):
    • MM-Embeds (A-V) Persona1 (its digital twin) at Location3.1 (its “home”).
    • MM-Embeds (A-V-H) Persona1 to Location3.2 (close to Location2.2 where the secretary is located).
  6. After a while, User2 (dance teacher):
    • MM-Embeds (A-V-H) Persona1 at Location2.4, (close to Location3.2 of dance student #2).
    • MM-Disables Persona1 from Location2.3 where it was dancing with Persona1.1 (student #1).
    • MM-Embeds (A-V-H) and MM-Animates an autonomous Persona3 replacing Persona2.1 from Location2.3 so that student #1 can continue practising dance.
    • Dances with Persona1 (student #2).

6.2.2      Workflow

Table 2 – Virtual Dance workflow.

User2 (Teacher)TracksPersona2.1 (AV)M-Location2.1
MM-EmbedsPersona2.2 (AV)M-Location2.2 w/ SA
MM-AnimatesPersona2.2 (AV)M-Location2.2
User1 (Student)TracksPersona1.1 (AV)M-Location1.1
TransactsValue1.1(Lesson fees)
MM-EmbedsPersona1.1 (AVH)M-Location1.2 w/ SA
MM-SendsObject1.1 (A)Persona2.2 (greetings)
User2 (Persona2.2)MM-SendsObject2.1 (A)Persona1.1 (greetings)
MM-SendsObject2.2 (A)Persona2.1 (alert)
User2 (Persona2.1)MM-EmbedsPersona2.1M-Location2.3 w/ SA
MM-EmbedsObject2.3 (A)M-Location2.4 (music)
User3 (Student)TracksPersona3.1 (AV)M-Location3.1
TransactsValue3.1(Lesson fees)
MM-EmbedsPersona3.1 (AVH)M-Location3.2 w/ SA
User2 (Teacher)MM-DisablesPersona2.1M-Location2.3
MM-EmbedsPersona2.3M-Location2.4 w/ SA
Persona3.1 (dance)

6.2.3      Actions, Items, and Data Types

ActionsItemsData Types
MM-AnimatePersona (AV)Amount
MM-EmbedObject (A)Spatial Attitude
MM-SendPersona (AVH)Value

7       Initial functionality profiles

The structure of the Metaverse functionality profiles derived from the above includes hierarchical profiles and one independent profile. Profiles may have levels. As depicted in Figure 2, the currently identified profiles are baseline, management, finance, and high. The currently identified levels for baseline, management, and high profiles are audio only, audio-visual, and audio-visual-haptic.

Figure 3 – the currently identified Functionality Profiles

As an example, the baseline functionality profile enables a human equipped with a Device to allow their Users to:

  1. Author Entities, e.g., object models.
  2. Sense a scene at a U-Location:
    • UM-Capture a scene.
    • UM-Send data.
  3. MM-Embed Personae and objects:
    • MM-Add Persona and object.
    • UM-Animate a Persona, with a stream (UM-Animate) or using a Process (MM-Animate).
  4. MU-Render an Entity at an M-Location to a U-Location.
  5. MM-Capture Entities at an M-Location
  6. MM-Disable an Entity.

This Profile supports baseline lecture, meeting, and hang-out Use Cases. TransActions and User management are not supported.

Table 3 lists the Actions, Entities, and Data Types of the Baseline Functionality Profile.

Table 3 – Actions, Entities, and Data Types of the Baseline Functionality Profile

Data TypesAddressCoordinatesOrientationPosition
 Spatial Attitude

The identified four profiles serve well the needs conveyed by the identified functionalities. As more functionalities will be added, the number of profiles and potentially of levels, is likely to increase.

8       Conclusions

Reference [2] demonstrates the feasibility of the first two milestones of the proposed MPAI roadmap to Metaverse interoperability. Currently, four functionality profiles supporting the selected functionalities have been identified and specified. As more basic Metaverse elements are added, however, more functional profiles are likely to be found necessary. Functionality profiles can be extended and restructured as more Functionalities will be added.

The next step of the MPAI roadmap to Metaverse interoperability is the development of Technical Specification – MPAI Metaverse Model (MPAI-MMM) – Metaverse Architecture.

9        References

  1. MPAI; Technical Report – MPAI Metaverse Model – Functionalities (MPAI-MMM); January 2023;
  2. MPAI; Technical Report – MPAI Metaverse Model – Functionality Profiles (MPAI-MMM); March 2023;
  3. MPAI; A roadmap to Metaverse Interoperability; February 2023; FGMV-I-012

[1] A Profile is sets of one or more base standards and, if applicable, chosen classes, subsets, options, and parameters of those standards that are necessary for accomplishing a particular function.

[2] A Level is a subdivision of a Profile indicating the completeness of the User experience.