# DONNA: a data model for enabling extensible and efficient metaverse applications

Georgios Bouloukakis, Ajay Kattepur

► To cite this version:

Georgios Bouloukakis, Ajay Kattepur. DONNA: a data model for enabling extensible and efficient metaverse applications. 2023 IEEE International Conference on Metaverse Computing, Networking and Applications (MetaCom), Jun 2023, Kyoto, Japan. 10.1109/MetaCom57706.2023.00143. hal-04122938

HAL Id: hal-04122938

https://inria.hal.science/hal-04122938

Submitted on 8 Jun 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# DONNA: A Data Model for Enabling Extensible and Efficient Metaverse Applications

Georgios Bouloukakis* & Ajay Kattepur†

*Télécom SudParis, Institut Polytechnique de Paris, France.

†Ericsson Research Artificial Intelligence, Bangalore, India.

georgios.bouloukakis@telecom-sudparis.eu, ajay.kattepur@ericsson.com

**Abstract**—The advent of *Metaverse* applications, that exploit extended reality technologies, has the potential to disrupt multiple industries including gaming, social networks, entertainment and travel. While there has been initial work on network, compute and synchronization features needed for the Metaverse, a comprehensive data model that captures the interactions between the physical and virtual worlds has not been evaluated extensively. Providing a formal data model would be crucial to ensure interoperability, model extensibility and applicability to multiple use cases. In this paper, we propose DONNA: A Data Model for Enabling Extensible and Efficient Metaverse Applications. DONNA provides a detailed data model of interactions between physical space, virtual spaces, sensors, devices, physical participants and avatars. Via the use of property graph schemas, we demonstrate the varied interactions between the physical and virtual worlds and the extensibility of the approach across multiple use cases. The data model is specifically demonstrated over a virtual museum visit use case to explain the nuances of sensing, dynamic property update and semantic interactions between physical and virtual objects.

**Index Terms**—Metaverse, Data Model, Property Graphs, Extensibility.

## I. INTRODUCTION

The term *Metaverse* was first used in Neil Stevenson's science fiction novel Snow Crash in 1992 and referred to a world where virtual and reality interact and create value [1] [2]. The Metaverse could mimic the real world or generate a new imaginary environment. The Metaverse typically has the following building blocks:

1) Environment: The real physical space is reproduced in digital form, and additional simulation information is added. In other words, the Metaverse world replicates the appearance of buildings or objects in the real world but has its own properties and functions.

2) Avatars: An avatar performs a social role suitable for a job and persona in Metaverse. The avatar should reflect the real persona and map emotions, sensory actions and reactions between the real-world and the Metaverse.

3) Devices: Head mounted devices that support virtual/augmented reality applications are a fundamental requirement of the Metaverse. In addition, physical and virtual sensors that capture observations and predict feature changes are necessary. Hardware specifications, resolution latency and update frequency are factors to consider within the devices.

4) Infrastructure: 5G technologies, Edge computing and intelligent resource allocation are important building

blocks to ensure low latency, scale and realistic rendering within the Metaverse.

A realistic way to reflect the real-world environment is to reproduce famous places (e.g., museums, Eiffel Tower) and places familiar to individuals (e.g., home, school) in the real world. Object generation modules create an avatar of any desired human shape (e.g., a celebrity, a family member) as an object of conversation. These aspects are to be sensed from the real world and mapped to the Metaverse in an efficient manner. Digital Twins [3] are a related area, where the physical objects are captured in real-time by the digital twin, to aid in simulation and analysis. While aspects such as synchronization [4] and use cases [1] have received some research interest, the semantic data model of the interaction between devices, sensors, avatars, physical spaces and the Metaverse have not been appropriately explored. Semantic interactions are crucial to ensure extensibility, interoperability and efficient Metaverse application development/deployment. This paper aims to fill that gap by employing property graph abstractions to describe the necessary interactions between elements in the Metaverse.

Our proposal is named DONNA: A Data Model for Enabling Extensible and Efficient Metaverse Applications. Through the use of knowledge property graphs [5], the following types of interactions are described formally: (i) physical spaces with static and dynamic properties (updated via sensor observations); (ii) sensors, actuators and virtual/augmented reality devices; (iii) synchronization features between physical space and Meta space; (iv) interactions between physical, virtual and avatars. The interactions are described over an exemplar use case involving virtual visits to the Louvre museum. The data models developed in this paper will be useful to Metaverse application developers to semantically annotate interactions between physical/virtual worlds.

The principal contributions of this paper are:

1) Generalizing the interactions between physical and virtual spaces, events and participants via property graph formalisms.

2) Systematic development of data models and interactions between spaces, devices, participants and events in the Metaverse environment.

3) Demonstrating the extensibility and effectiveness of DONNA over an exemplar museum visit use case.

The rest of the paper is organized as follows: §II presents the
<figure><img src="image_2.png" /><figcaption>Fig. 1: Louvre Floor Map.</figcaption></figure>

challenges of Metaverse use-cases. An overview of knowledge graph modeling is presented in §III. A description of the Metaverse ecosystem and concepts are presented in §IV. The semantic representation of the Metaverse entities including spaces, devices, participants and events are described in §V. Discussions on how the data models may be explored for Metaverse descriptions are provided in §VI. The state of art is presented in §VII followed by conclusions in §VIII.

## II. METAVERSE USE-CASES AND CHALLENGES

We describe a use case related to a virtual museum visit via the Metaverse and subsequent challenges.

### A. Virtual Museum visit use case

Consider the Louvre Museum in Paris, the most visited museum in the world. As seen in Figure 1¹, the Louvre museum has three sectors (Richlieu, Sully, Denon) and spans five floors with tens of rooms. It consists of sculptures and artifacts covering Greek, Roman, Egyptian, French, Mesopotamian, Asian and other historic civilizations. In addition, there are multiple priceless paintings from Renaissance masters. A virtual visitor to the Louvre museum would expect the following:

- An accurate depiction of the floor plan, sections and rooms within the physical museum.

- Accurate rendering of the sculptures, paintings and permanent exhibits within the museum.

- To experience the “real” museum visit conditions, the virtual visit participants may want to see the physically present crowd and employees in Louvre.

- In an alternate case, the virtual world participants may want exclusive access to meet and socialize within the Louvre premises.

- There may be temporary exhibits, events and author signings that must also be replicated in the Metaverse. These events or exhibits may be held periodically and may be exclusive to virtual participants.

- Changes in the environment (lighting, crowd) must be accurately mapped in the virtual world.

From the above descriptions, we see a need for accurate data modeling to describe the physical world, virtual world, participants, sensing updates and interactions.

### B. Challenges

The scenarios presented in the virtual museum tour use case bring out a common set of challenges that are to be addressed within the Metaverse:

1. **Semantic Mapping:** As there is tight coupling between the real-world and virtual world, it is crucial to have accurate semantic description of components. Physical objects, properties and features are to be described and mapped appropriately. Of particular importance is the mapping and synchronization of properties and features that can change, such as object location, temperature, lighting and occupancy levels.

2. **Standard Data Models:** Data schemas, properties and knowledge shared between elements of the physical/virtual world must be accurately captured.

3. **Interactions:** In the physical world, interaction of the physical participants with objects or other participants occur via the senses. In the virtual world, haptic feedback, avatar observations and interactions are to be captured to create a seamless experience.

4. **Synchronization:** Virtual/augmented devices and sensor readings are to be synchronized in real-time to create an accurate Metaverse representation. This process involves high capacity 5G connectivity, compute capacity and intelligent synchronization algorithms. Having an accurate semantic and data model ensures that the appropriate data is captures and relayed over the network.

5. **Intelligent Rendering:** Advances in augmented, virtual and mixed reality technologies are integrated with positioning, localization and prediction algorithms to provide superior quality of experience to users.

## III. KNOWLEDGE GRAPHS

In this section we provide an overview of property graphs, formal semantics of property schema and instances and relevant graph database technologies.

### A. Property Graphs

A property graph [5] is a type of graph model where relationships not only are connections but also carry a name (type) and some properties. Generally, the property graph data model consists of three elements: (i) *Nodes*: the entities in the graph. Nodes can be tagged with zero to many text labels representing their type. Nodes are also called vertices. (ii) *Edges*: the directed links between nodes. Edges are also called relationships. The “from node” of a relationship is called the source node. The “to node” is called the target node. Each edge has a type. While edges are directed, they can be navigated and queried in either direction. (iii) *Properties*: the key-value pairs associated with a node or with an edge. A key requirement for working with any data model is the ability to reference nodes, properties and relationships (edges). In the case of property graphs, internally, nodes and edges have identifiers. Referencing is done by using text strings—node labels, relationship types, and property names.

### B. Property Graph Model

A Graph Database Model [6] is a model where data structures for the schema are modeled as graphs, the data manipulation is expressed by graph queries and appropriate integrity constraints are defined over the graph structure. A property graph is a directed labelled graph with the characteristic that

<footnote n="1">¹https://www.louvre.fr/en/visit/map-entrances-directions</footnote>
each node or edge could maintain a set of property-value
pairs. From a data model, a node represents an entity, an
edge represents relationship between entities and a property
represents a feature of the node/edge. Assuming that $\mathcal{L}$ is a
set of labels (for nodes and edges), $\mathcal{P}$ is a set of property
names, $\mathcal{V}$ is a set of atomic values:

**Definition 1: Property Graph.** A property graph is a tuple
$G = (N, E, \rho, \lambda, \sigma)$ where:
$- N$ is a finite set of nodes;

- $E$ is a finite set of edges such that $E$ has no elements in common with $N$;

- $\rho: E \to N \times N$ is a function that associates each edge with a pair of nodes;

- $\lambda: (N \cup E) \to (\mathcal{L})^+$ is a function that associates a node/edge with a set of labels from $\mathcal{L}$ (for a set $X$, $(X)^+$ is the set of all finite subsets of $X$);

- $\sigma: (N \cup E) \times P \to (\mathcal{V})^+$ is a function that associates nodes/edges with a property value from $\mathcal{V}$.

Given two nodes $n_1, n_2 \in N$ and an edge $e \in E$ such that $\rho(e) = (n_1, n_2)$, $n_1$ is referred to as the source node and $n_2$ is referred to as the target node of $e$. Given a property $\sigma(o, p) = \{v_1, \dots, v_n\}$, $o$ is the property owner, $p$ is the property name and $v_i$ is the property value.

Integrity constraints are rules that define the set of consistent database states or changes of state. A data schema is a data modeling feature that allows to describe the structure of the data and enforce its consistency. In this sense, a graph schema allows to define the graph structure by specifying the types of nodes, the types of edges, and the properties for such types. Informally, a property graph schema defines the node types, the edge types, and the properties for such types (including the corresponding datatypes).

**Definition 2: Property Graph Schema.** With $T$ is a finite set of datatypes (e.g., String, Integer), a property graph schema is a tuple $S = (T_N, T_E, \beta, \delta)$ where:

- $T_N \subset \mathcal{L}$ is a finite set of labels representing node types;

- $T_E \subset \mathcal{L}$ is a finite set of labels representing edge types;

- $\beta: (T_N \cup T_E) \times P \to T$ is a function that defines the properties for nodes and edge datatypes;

- $\delta: (T_N, T_E) \to (T_E)^+$ is a function that defines the edge types allowed between a pair of node types.

The notion of schema-instance consistency implies that an
instance property graph satisfies the structural restrictions
established by a given property graph schema.

### C. Graph Technologies

To define property graph schemas, query operators and
storing mechanisms, graphs databases can be exploited. Graph
databases are popular in the industry as they can quickly and
easily store as well as query complex data, allowing for faster
and more accurate results. In addition, graph databases are
designed to handle data relationships more efficiently, and
can support more powerful and complex queries. Popular
graph databases are Neo4j<fnref n="2" />, Amazon Neptune<fnref n="3" />, Microsoft

<figure><img src="image_3.png" /><figcaption>Fig. 2: The Metaverse Ecosystem.</figcaption></figure>

Azure Cosmos DB<fnref n="4" />, and OrientDB<fnref n="5" />. To manipulate stored
data, a query language must be used. GraphQL<fnref n="6" /> offers a
powerful way to query data and can be used to quickly build
powerful Application Programming Interfaces (APIs). NGSI-
LD [7] (Next Generation Service Interface for Linked Data) is
a standardized way of modeling and accessing property graph
data in the Linked Data format. It provides a unified way to
represent and query data from different sources, and provides
an API for data access. The main difference between GraphQL
and NGSI-LD is that GraphQL is designed to provide a query
language for data access and manipulation, while NGSI-LD is
designed to provide a unified data model and access interface
for environments enhanced with connected devices in the
Internet of Things (IoT) domain.

## IV. THE METAVERSE ECOSYSTEM

By taking into consideration the use cases and challenges
presented in §II, this section presents a high-level overview
of the *Metaverse ecosystem* that includes physical and virtual
entities, their interactions and synchronization requirements.
The *Metaverse ecosystem* will be exploited in §V, to create
the Metaverse semantic representation.

As depicted in Figure 2, a *Physical Space* represents a real
entity type (e.g., a museum building) that is used to instantiate
an actual space (e.g., the Louvre museum). A physical space
may host a *Physical Occupant* that also represents a real entity
used to create instances of occupants (e.g., visitors). Both
entities and their instances must be digitally transformed in
the Metaverse.

In the Metaverse, a *Meta Space* is an entity type that can be
initially instantiated by relying on a *Physical Space* instance
(e.g., the Louvre museum). *Meta Space* instances that are
created using a specific *Physical Space* instance must include
*Virtual Occupant* instances that correspond to the *Physical
Space Occupants*. For example, the Louvre museum can be
used to create multiple *Meta Space* instances. Apart from
the static properties (floors, rooms, objects, etc.), dynamic
properties (physical occupants, space conditions, etc.) must be
identically presented in each *Meta Space* instance. Moreover,
both *Meta Space* and *Virtual Occupant* instances must be syn-
chronized with the *Physical Space* and *Physical Occupant
instances*. To achieve such synchronization, it is essential to
sense the environments/person dynamic properties using IoT
devices and efficiently transmit them to all corresponding Meta

<footnote n="4">⁴https://azure.microsoft.com/en-us/services/cosmos-db/</footnote>

<footnote n="5">⁵https://orientdb.com/</footnote>

<footnote n="6">⁶https://graphql.org/</footnote>

<footnote n="2">²https://neo4j.com/</footnote>

<footnote n="3">³https://aws.amazon.com/neptune/</footnote>
<caption>TABLE I: A data schema for Physical spaces.</caption>

$$
\begin{align*}
T_N &= \{\text{Space, Observation, Building, Floor, Room, Window, Door}\} \\
T_E &= \{\text{has-spaces, has_dynamicProp, has_floors, hasRooms, has-doors, has_wins}\}
\end{align*}
$$

$$
\begin{align*}
\beta (\text{Space, name}) &= \text{val} \\
\beta (\text{Space, address}) &= \text{val} \\
\beta (\text{Observation, measurementType}) &= \text{val} \\
\beta (\text{Observation, measurement}) &= \text{val} \\
\beta (\text{Observation, description}) &= \text{val} \\
\beta (\text{Building, category}) &= \text{val} \\
\beta (\text{Building, desc}) &= \text{val} \\
\beta (\text{Floor, RelPosition}) &= \text{val} \\
\beta (\text{Floor, desc}) &= \text{val} \\
\beta (\text{Room, RelPosition}) &= \text{val} \\
\beta (\text{Room, desc}) &= \text{val} \\
\beta (\text{Window, RelPosition}) &= \text{val} \\
\beta (\text{Door, RelPosition}) &= \text{val} \\
\delta (\text{Space, Space}) &= \{\text{has-spaces}\} \\
\delta (\text{Space, Observation}) &= \{\text{has_dynamicProp}\} \\
\delta (\text{Building, Floor}) &= \{\text{has_floors}\} \\
\delta (\text{Floor, Room}) &= \{\text{hasRooms}\} \\
\delta (\text{Room, Window}) &= \{\text{has_wins}\} \\
\delta (\text{Room, Door}) &= \{\text{has_doors}\}
\end{align*}
$$

Space instances. For example, crowd and employees in Louvre or lighting conditions must be accurately captured from IoT devices, transmitted and accurately mapped in the Metaverse.

Finally, apart from virtual occupants, we define the *Meta Occupant* in Figure 2 as an entity that can instantiated using Extended Reality (XR) devices. Again, XR device actuation commands must be synchronized with Meta Occupant behavior. Note that the occupancy of Meta Occupants can be different at each Meta Space of the physical space instance. For example, different meta spaces of Louvre can be instantiated from different groups of meta occupants. Therefore, a *Virtual Occupant* corresponds to an actual physical occupant (e.g., an on-site visitor of Louvre), while a *Meta Occupant* is always instantiated by an off-site visitor using an XR device.

V. THE METAVERSE SEMANTIC REPRESENTATION

The DONNA data modeling involves the interaction between three components: (i) the physical spaces, properties and physical participants (ii) devices that include sensors, XR devices and other Metaverse interactions (iii) the virtual Meta Space, virtual participants and Meta objects. In this section, we provide detailed descriptions of the property schemas and their interactions.

A. *The Physical Space and Person*

Figure 3a and Table I present the data schema for physical spaces within the Metaverse ecosystem. Spaces have *properties* which include unique identifiers. Spaces such as smart buildings can have multiple floors, rooms, doors and windows, each with relative positions and descriptions (materials, size). The spaces may be described using sensor observations or static knowledge (blueprint, maps). As further described in Table I, the property graph schema may be formally described with node types $T_N$, edge types $T_E$, properties $\beta$ and edge constraints on nodes $\delta$. This property graph schema may be instantiated into a graph dependent on specific deployment domains. Of particular interest are *dynamic properties* that

are to be periodically monitored and synchronized onto the
Metaverse.

B. Devices

Of critical importance are the devices that sense, update and interact with the physical and Metaverse worlds. Figure 3b describes the data schemas for the devices. Devices such as *sensor* are producers of observations and have the edge interaction property *providesobs*. Similarly, the *actuator* devices used to make changes in the environment have the property *requiresobs*. The XR devices act as both producers and consumers of data. We also have *virtual sensors* that can combine physical sensor readings or provide virtual sensing within the Metaverse.

C. *The Meta Space and Person*

As seen in Figure 3c, the data schema for the *Space* and *MetaSpace* observation and synchronization consists of the following entities:

- The physical *Space* instantiates a *Meta Space* and keeps in synchronization with changes.

- Sensors observe the physical space and update the *PhysicalObs*. These changes are updated in the *Meta Space*.

- Additionally, the *Meta Space* has *VirtualObs* that are updated (e.g., changes in the number of participants, topology in the Metaverse) and has to be rendered appropriately. The virtual observations may be computed or learned (for instance with Machine Learning) from the physical sensors.

As seen in Figure 3d, the data schema for the *Person*, *MetaPerson* and *VirtualPerson* observation and synchronization consists of the following entities:

- The physical *Person* instantiates the *Virtual Person* and keeps in synchronization with changes.

- Additionally, the *Meta Space* has other participants, which we refer to as *Meta Persons* (accessing the Metaverse via XR devices). Interactions and events from the Meta person's space should also be instantiated. Movements and sensing done by the XR devices are recreated in the meta person's avatar.

As seen in Figure 3e, the physical person interacts with the physical world space. In synchrony, this virtual representation also interacts with the Metaspace. Other virtual participants (MetaPerson) can interact and modify the Metaspace. The formal data schemas have been omitted for brevity<fnref n="7" />.

D. *Property Graph: Louvre museum use case*

Figure 4 instantiates a property graph for measuring the occupancy in the Louvre museum use case. Buildings and rooms have sensors such as cameras that periodically capture images. These images are processed by a *VirtualSensor* with image processing or machine learning algorithms to extract occupancy. The occupancy levels are then dynamically instantiated within the Metaverse to provide an accurate real-time rendering of the Louvre premises. A MetaBuilding is

<footnote n="7">⁷An expanded version of the schema can be accessed here:
https://github.com/SAMSGBLab/metaverse--donna</footnote>
<figure><img src="image_4.png" /><figcaption>Fig. 3: DONNA Data Schemas for the Metaverse.</figcaption></figure>

instantiated (multiple Metaverse buildings can be similarly created) that contains virtual occupancy readings of virtual participants. This Metaspace can also be synchronized with the physical participant occupancy. Note that temporary events or changes in crowd distribution are captured and rendered dynamically using this data model. Thus, visitors of the Louvre Metaverse can choose multiple modes: (i) visit an exact replica of the Louvre museum including physical participants (ii) create a cordoned off area any only meet virtual participants with the Louvre background (iii) a combination of the cases. It is crucial to have all the data models, semantic representations and features to be well represented in creating large-scale extensible Metaverse applications.

## VI. DISCUSSION

This section discusses ongoing and future exploitation of the DONNA data models for enabling extensible and efficient Metaverse applications.

**Portability.** Defining Metaverse data models such as DONNA, facilitates the deployment of Metaverse applications across real spaces. In particular, property graph-based data models are supported from existing state-of-the-art technologies such as graph databases (e.g., Neo4j), query languages (e.g., GraphQL) as well as IoT-enhanced data models and APIs (e.g., NGSI-LD)<fnref n="8" />. In addition, model-driven Metaverse applications can be designed and implemented using generic properties such as the space type (e.g., museum), static/dynamic properties (e.g., occupancy), and profiles of occupants (e.g., personnel of museum). This may result to the vast deployment of Metaverse applications across smart spaces.

**Intelligent data processing.** Defining generic properties of smart spaces (occupancy, location, etc.) and decoupling them from real IoT devices, enhances the use of data processing and learning techniques in nodes available in the computing

continuum. The Metaverse ecosystem may require to simultaneously process a vast amount of data only for a single smart space. For example, to estimate the occupancy of the Louvre museum requires to process data coming from on-site IoT devices, as well as from XR devices used to instantiate Metaspace instances. Supporting efficient and rapid processing may require to rely on advanced learning methodologies such as federated learning (using learned models of many IoT devices) or on swarm intelligence approaches where processing must be simultaneously spitted to available nodes and autonomously coordinated. Note that the DONNA data model can enable the development of middleware systems with native intelligent processing mechanisms, agnostic to application developers.

**Superior synchronization.** The Metaverse ecosystem requires the deployment of a vast amount of Metaspace instances for just a single real space, as well as accurate synchronization between the real space and Metaspaces. For example, the Louvre museum may require to deploy in the Computing Continuum millions of Metaspaces that must be synchronized with the actual Louvre museum using its dynamic properties (e.g., occupancy). The DONNA data model helps to reduce the data load that must be synchronized due to the semantic representation. For instance, based on the spatial knowledge representation and virtual participant locations, Metaverse resources can be allocated intelligently. This enables only particular location, users' or events properties to be updated, thus limiting data bandwidth, compute resources and synchronization overheads.

## VII. RELATED WORK

Synchronizing the physical and virtual worlds dynamically has received some attention in prior art. In [4], the resource allocation problem for synchronizing physical work with digital twin representation is targeted. In [8], the synergy between the IoT and the Metaverse is explored. The paper highlights four very important technologies: AI, high-speed data communications, mobile edge computing and digital twins. In [9], a novel

<footnote n="8">⁸Our ongoing work includes the implementation of the IoT-based DONNA data model using NGSI-LD.</footnote>
<figure><img src="image_5.png" /><figcaption>Fig. 4: Property Graph for Measuring Occupancy in Louvre.</figcaption></figure>

edge continual learning framework is proposed to accurately model the evolving affinity between a Physical Twin (PT) and its corresponding Cyber Twin (CT) while maintaining their utmost synchronization. These synchronization features would benefit from the data models proposed in our paper.

Another aspect to consider is the efficient network, compute and sensing infrastructure needed to operate the Metaverse at scale. In [10], a general architecture of the Metaverse and its major components are described. A mentioned challenge in this space is that the networking infrastructure must be semantic-aware and goal-oriented, to better improve edge intelligence. In [11], the requirements of real-time combination of distributed live sources and stored digital assets towards distributed caching, computation, and communication is studied. The role of 5G within Metaverse in studied in [12] that includes: (i) immersive experience due to fusion of data reliably from multiple sensorsdevices; (ii) low latency reaction times allowing for millisecond based synchronization and feedback; and (iii) mobility and reliability as a result of 5G coverage.

Development of semantic representation, ontologies and a common data model for the Metaverse is at a nascent stage. [13] provides a high level ontology view of hardware, software and device components within the Metaverse. However, the granular data models, properties and interactions have not been adequately explored. In [14] the integration of an ontology-based semantic backend is demonstrated within a Metaverse-like realistic digital environment.

The proposed DONNA data model provides a generic, extensible property graph representation that covers physical space, physical participants, Meta spaces, Meta participants and IoT/XR devices. These models may be applied and extended across multiple use cases, that is not seen in prior art. Moreover, the generic nature of property graphs allow instantiation across multiple spaces and applications.

VIII. CONCLUSION

With the burgeoning of Metaverse applications across domains, it is critical to specify data models to ensure interoperability and extensibility of interactions between the physical world, Metaverse, participants, devices and events. In this paper, we propose DONNA: A Data Model for Enabling Extensible and Efficient Metaverse Applications. Via the generic model of property graphs, detailed models on physical spaces,

devices, meta-spaces, physical participants, virtual participants and property changes are provided. The extensibility of the formalism is demonstrated over a virtual visit to the Louvre museum over the Metaverse. The data models developed in this paper will be useful to Metaverse application developers to semantically annotate interactions and efficiently synchronize between physical/virtual worlds.

In future, the data models would be exploited to improve efficiency of data update and sensing for Metaverse applications.

REFERENCES

[1] S.-M. Park and Y.-G. Kim, "A metaverse: Taxonomy, components, applications, and open challenges," *IEEE Access*, vol. 10, pp. 4209–4251, 2022.

[2] Congressional-Research-Service, "The metaverse: Concepts and issues for congress," vol. R47224, 2022.

[3] T. B. Tuli, L. Kohl, S. A. Chala, M. Manns, and F. Ansari, "Knowledge-based digital twin for predicting interactions in human-robot collaboration," in *Intl. Conf. on Emerging Technologies and Factory Automation (ETFA)*, 2021, pp. 1–8.

[4] Y. Han, D. T. Niyato, C. Leung, C. Miao, and D. I. Kim, "A dynamic resource allocation framework for synchronizing metaverse with iot service and data," *IEEE Intl. Conf. on Com.*, pp. 1196–1201, 2021.

[5] A. Hogan, E. Blomqvist, and C. et al, "Knowledge graphs," *ACM Comput. Surv.*, vol. 54, no. 4, 2021.

[6] R. Angles, "The property graph database model," in *Alberto Mendezon Workshop on Foundations of Data Management*, 2018.

[7] G. Privat, "Guidelines for modelling with ngsi-Id," *ETSI White Paper*, no. 42, 2021.

[8] K. Li and et al., "When internet of things meets metaverse: Convergence of physical and cyber worlds," 2022. [Online]. Available: https://arxiv.org/abs/2208.13501

[9] O. Hashash, C. Chaccour, and W. Saad, "Edge continual learning for dynamic digital twins over wireless networks," in *Intl. Wksp. on Signal Processing Advances in Wireless Communication*, 2022, pp. 1–5.

[10] W. Y. B. Lim, Z. Xiong, D. Niyato, X. Cao, C. Miao, S. Sun, and Q. Yang, "Realizing the metaverse with edge intelligence: A match made in heaven," *IEEE Wireless Communications*, pp. 1–9, 2022.

[11] Y. Cai, J. Llorca, A. M. Tulino, and A. F. Molisch, "Compute- and data-intensive networks: The key to the metaverse," in *1st International Conference on 6G Networking (6GNet)*, 2022, pp. 1–8.

[12] J. N. Njoku, C. Ifeanyi Nwakanma, and D.-S. Kim, "The role of 5g wireless communication system in the metaverse," in *27th Asia Pacific Conference on Communications (APCC)*, 2022, pp. 290–294.

[13] Abu-Salih, "Metaontology: Toward developing an ontology for the metaverse," *Front Big Data*, 2022.

[14] A. Kanak, and et. al., "Bimverse: Towards a semantic interpretation of buildings in the city and cities in the universe," in *Intl. Conf. on Systems, Man, and Cybernetics (SMC)*, 2022, pp. 1072–1077.