There is no common definition of the word metaverse. MPAI characterises the word Metaverse Instance (M-Instance) as a system that captures data from the real world (in the following, called Universe), processes it, and combines it with internally generated data to create virtual environments that users can interact with.
Examples of M-Instances are plentiful. So far, their developers have made technology decisions that best responded to their needs, often without considering the choices that other developers might have made for similar purposes. Recently, however, many have expressed concerns that “walled gardens” do not fully exploit the opportunities offered by current and expected technologies and have called for M-Instances to be “interoperable”.
MPAI has studied the issue of M-Instance interoperability. What can be called direct interoperability is the most desirable and effective but metaverse technologies are still rapidly evolving. Mediated interoperability is a solution that lets M-Instance implementers make their own technology decisions assigning to a conversion service the task of converting data from one format to another. The practical use of mediated interoperability is limited because the data semantics of different M-Instances may greatly vary. As indicated in Figure 1, dataA.1 of M-InstanceA may be converted to dataB.1 and dataB.2 but a part of dataA.1 may not be converted at all.
Figure 1 – Data conversion between M-Instances
If technology standardisation is too early and data conversion not a solution, a standard for the functional requirements of data can provide a form of interoperability. After publishing two Technical Reports on Functionalities and Functionality Profiles, MPAI is now publishing MPAI-Metaverse Model (MPAI-MMM) – Architecture Technical Specification. M-Instances can interoperate if they:
- Rely on the same Operation Model.
- Use:
- The same Profile specified by MPAI-MMM – Architecture, and
- Either the same Technologies, or
- Independent Technologies while accessing appropriate Conversion Services.
The above numbered list is contained in the first normative chapter of the standard – Scope. The next chapter – Terms and Definitions – collecting a large number (about 100) of specified Terms is also normative.
The next chapter – Functional Requirements –is informative. It contains thoroughly revised and integrated Functionalities of the Technical Report and provides the basic elements on which the next (normative) chapter – M-Instance Operation – is based. The main elements of this chapter are:
- The definition of an M-Instance as a set of Processes performing Actions on Items at Locations and Times.
- Specifies the minimum metadata format of Processes, Actions, and Items (metadata are extensible to cope with specific cases).
- Specifies the protocol whereby a Process can request another Process – potentially in another M-Instance – to perform Action on Items.
- Specifies four types of Process: Device, User, Service, and App.
- Renders Users as Personae.
Figure 1 graphically represents the last two points: Devices are Processes connecting the real world with the M-Instance, Users are Processes representing and acting on behalf of a registered human, and Apps are Processes running on a Device. Personae are rendered Users.
Figure 2 – Universe, Metaverse, Human, Device, User, Persona, App
The following (normative) chapter identifies the Actions, Items, and Data Types provides their Functional Requirements.
The following (informative) chapter uses the MPAI Metaverse Use Case Description Language to describe nine Use Cases:
| 1. Virtual Lecture
2. Virtual Meeting 3. Hybrid working 4. eSports Tournament 5. Virtual performance |
6. AR Tourist Guide
7. Virtual Dance 8. Virtual Car Showroom. 9. Drive a Connected Autonomous Vehicle.
|
All relevant elements of the M-Instance Operation Model, and Actions, Items, and Data Types have been used. The nine Use Cases do not need more elements than those specified in the MPAI-MMM – Architecture standard.
The last (normative) chapter – Functional Profiles – revisits and extends the four profiles of different complexity identified as examples in the Functionality Profiles Technical Report. The Baseline Profile supports basic forms of lecture, meeting, and hang-out, the Finance Profile enables a User to post assets and make transactions, the Management Profile adds the management of registration and rights to the Baseline Profile, and the High Profile supports all currently identified Functionalities.
The MPAI-MMM – Architecture Working Draft (html, pdf) is published with a request for Community Comments. See video recordings (YouTube, WimTV) of the presentation made on 1st September 2023. Send to the MPAI Secretariat by 2023/09/21T23:59 UTC. MPAI will use the Comments received to develop the final draft planned to be published at the 36th General Assembly (29 September 2023).
