Metaverse is a widely used term that conveys a still nebulous notion encompassing new forms of communication expected to create new jobs, opportunities, and experiences with transformational impacts on virtually all sectors of human interaction. A “metaverse” can be considered as a communication and interaction system supporting digital environments containing digital objects. A simple example of this definition is an audioconference system where human participants are represented by audio objects that a server mixes and distributes to all participants.
In general, a metaverse instance is viewed as a more complex communication environment with several additional features, such as synchronous and persistent experiences and virtual reality features such as avatars that may or may not be controlled by humans and objects of the real world.
Communication implies an agreement – a standard – between communicating parties. MPAI defines Metaverse Interoperability as the ability of metaverse instance #1 to use data from and as intended by a metaverse instance #2.
At present, achieving the interoperability defined above is difficult because:
- There is no common understanding of what a metaverse is or should be, in detail.
- There is an abundance of existing and potential metaverse use cases.
- Some independently designed metaverse implementations are very successful.
- Some important technologies enabling more advanced and even unforeseen forms of the metaverse may be uncovered in the next several years.
The MPAI Metaverse Model (MPAI-MMM) project has been established to deal with this unusually challenging situation by providing Technical Reports and Technical Specifications that can be applied to as many kinds of metaverse instances as possible and enable varied metaverse implementations to interoperate. The MPAI roadmap to metaverse interoperability identifies 6 milestones for each of which MPAI plans on publishing a Technical Report or Specification.
The first milestone reached by the project is based on the idea of collecting the functionalities that potential metaverse users expect a metaverse instance to provide, rather than trying to define what the metaverse is. The first Technical Report [1] includes definitions, assumptions guiding the MPAI-MMM project, potential sources of functionalities, an organised list of commented functionalities, and an analysis of some of the main technology areas underpinning the development of the metaverse.
Potential metaverse users with different needs might require different technologies to support such 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 of no use to them and potentially costly.
Reference [1] addresses this difficulty. It proposes that metaverse standardisation be based on the notion of Profiles and Levels[1] successfully adopted by digital media standardisation for three decades. A metaverse standard that includes Profiles and Levels would enable metaverse developers to use only the technologies they need that are offered by the profile that is most suitable to them.
The notion of profile can mitigate the impact of having many disparate metaverse users with diverse requirements. Unfortunately, the implementation of that notion is not currently possible because some key technologies are not yet available and at this time it is unclear which technologies, existing or otherwise, will eventually be adopted [2]. This Technical Report, published as the second milestone, copes with this situation by considering Functionality Profiles, i.e., profiles that are defined by the functionalities they offer, not by the 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.
The structure of this Technical Report is the following:
| Chapter 2 | Extends the metaverse-relevant definitions of [1]. |
| Chapter 3 | Develops a functional operation model of a metaverse instance based on Sources requesting Destinations to perform Actions on Items both containing Data Types. |
| Chapter 4 | Specifies the payloads of the Actions that Sources request Destinations to perform on Items and of the responses provided by Destinations to such requests. |
| Chapter 6 | Specifies the Metadata of the Items without specifying the Formats of the Data. |
| Chapter 7 | Specifies the Data Types used by requests and responses. |
| Chapter 8 | Verifies the methodology developed by this Technical Report by applying it to some relevant Use Cases. |
| Chapter 9 | Provides a first set of Functionality Profiles and Levels. |
This Technical Report – MPAI Metaverse Model (MPAI-MMM) – Functionality Profiles has been developed by the Requirements Standing Committee. MPAI may decide to develop new versions of this document.
MPAI plans on releasing more documents of the MPAI-MMM project when reaching a milestone. The plan for the new milestones is as follows:
- Architecture: Functional blocks, metaverse API, and the Items exchanged by the blocks.
- Data Formats: Functional requirements of Items exchanged between functional blocks.
- Technology landscape: Table of Contents of the Metaverse Technology Specifications as envisaged in [2].
- MPAI Technologies: Mapping of MPAI Technologies relevant to the metaverse to the said Table of Contents.
MPAI expects that, by reaching milestone #4 it will be possible to implement non-interoperable metaverse instances and by reaching milestone #5 it will be possible to implement metaverse instances that rely on mediated interoperability, e.g., by accessing a format conversion service. Milestone #5 will provide a list of all technologies whose specification is required to achieve direct interoperability. Milestone #6 will document the MPAI contributions to the metaverse technology specification.
[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. A Level is a subdivision of a Profile indicating the completeness of the user experience.
