A functional operation model

<- Defintions    Go to ToC        Processes –>

Table of Contents of Chapter 3 – A functional operation model

3.1         Introduction 3.2         M-Instances 3.3         Registration 3.4         Processes

3.5         Actions 3.6         Items 3.7         Data Types

 

3.1        Introduction

This Chapter illustrates the operation of Metaverse Instances or Environments by means of a walkthrough. The following should be noted:

1. The walkthrough defines and illustrates all the terms used in this Technical Report as they are introduced.
2. To the extent possible, the definition of a Term (indicated in bold with a capital first letter) is provided when it is introduced.
3. If a definition is slow in coming up because of the complexity of the walkthrough and the number of Terms introduced, the reader may rely on the common meaning of the term or access the definition in one of Table 1.
4. The walkthrough uses verbs called Actions, i.e., operations affecting an Item, i.e., Data and Metadata identified and recognised by a Metaverse Instance (M-Instance) using Data Types.
5. If a noun is defined, the corresponding verb may be introduced without engaging in an additional definition and vice-versa.
6. An Action may start from a Metaverse Location called M-Location, i.e., an identified delimited portion of a Metaverse Environment (M-Environment), i.e., a delimited portion of an M-Instance, and may start:
   • From an M-Location and affect an M-Location in the same or different M-Instance.
   • From an M-Location and affect a U-Location, i.e., an identifiable delimited portion of a U-Environment, a delimited portion of the Universe, i.e., the real world.
   • From a U-Location and affect an M-Location.

Accordingly, some Actions will be prefixed by MM-, MU-, or UM-.

3.2        M-Instances

Figure 1 depicts some of the main elements at the basis of this Technical Report.

Figure 1 – An example of Metaverse Scenarios addressed by this Technical Report

The humans and objects in the U-Environments on the right-hand side of Figure 1 may be connected to one or more Metaverse Services through Devices that UM-Capture scenes with their Sensors and MU-Render Entities, i.e., Item that can be perceived, though their Actuators. Metaverse Services, implemented using centralised or decentralised architectures, generate the M-Instances on the left-hand side of Figure 1. Light blue Users or Objects indicates that they are generated by the M-Instance. Green Users or Objects indicates that they are digital twins of humans or objects. Green User are rendered either as Personae, i.e., Models representing humans that are UM-Animated by the movements of a human or be MM-Animated by an autonomous agent.

Direct Interoperability of two M-Instances is achieved when M-Instance #1 can use the Data from and as intended by M-Instance #2. Mediated Interoperability is achieved when one or both M-Instances request a Conversion Service to translate data from M-Instance #2 and vice-versa. Mediated Interoperability may not achieve the same result of Direct Interoperability if the data syntax and semantics of M-Instance #1 does not match M-Instance #2’s or if the delay created by the Conversion Service negatively affects the user experience.

Therefore, an M-Instance is populated by Users and Objects potentially having a Device-enabled relationship with a U-Environment or else synthetically generated by an M-Instance. The Functionalities provided by an M-Instance enable its Users to achieve 1) their goals, 2) within the constraints of the Metaverse Service and Device capabilities, and 3) respecting the Rules under which Users operate in the M-Instance.

3.3        Registration

A human wishing to have its User(s) participate in an M-Instance/M-Environment may be asked to Register:

1. The human may be requested to provide a subset of their User Data that may include:
   • Personal Profile, i.e., Data about the human represented by the User.
   • Persona(e).
   • One or more Wallet, i.e., a container of Currency units.
   • Activity Data, i.e., the record of the Actions of a User.
   • Social Graph, i.e., the network of connections of a User with Items, M-Locations, U-Locations, and Services.
2. Account is an Item with the following characteristics:
   • It unequivocally associates a Registered human with the subset of the Items they provide.
   • A human may have more than one Account in one or more M-Instances/M-Environments.
   • A User exists after a human Registers with an M-Instance/Environment.
   • A User has certain Rights to Act in the M-Instance/M-Environment which is associated with the Account.
   • An M-Instance/Environment may allow a human to have more than one User per Account.
   • Different Users of an Account may have different Rights.

Note that some User Data may be kept private and that the laws of the jurisdiction under which the M-Instance/M-Environment operates may prescribe that it may not request certain User Data or handle it with special care.

The Rules of an M-Instance/M-Environment express:

1. The terms and conditions under which a User exists in an M-Instance/M-Environment and operates either there or in another M-Instance/M-Environment.
2. The obligations undertaken by the Registering human represented by the User.

A human Registered with an M-Instance/M-Environment may be able to join another M-Instance/M-Environment if they are Interoperable and the Rules enable that Functionality. Rules may prevent a human Registered with an M-Instance/M-Environment from interacting with another M-Instance/M-Environment.

Data entering an M-Instance, e.g., through the Action of UM-Importing (e.g., from a device external to the M-Instance) may include Metadata and the Rights granted to a Process to perform Actions on the Data.

Rights is an Item expressing the ability to perform an Action on an Item.

• Rights include the User, the Actions, and the Items the User can perform Actions on.
• The Rules of some M-Instances/M-Environments may forfeit Rights enforcement on some Actions performed on some Items by some Users.

Identifier is an Item uniquely associated to a particular Item. An Item may be Identified by more than one Identifier. The following hierarchical structure allows for Identification of an Item at an M-Location, in a M-Environment of an M-Instance:

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

3.4        Processes

A Process performs Actions on Items, and Data and Metadata inside an M-Instance to the extent allowed by the Rights held by the Process in the M-Instance and/or in other M-Instances to the extent allowed by the Rights the Process holds in those other M-Instances. Actions are defined in Table 1 and specified in Chapter 4.

MPAI-MMM assumes that Processes are executed in M-Instances. A Process #1 interacts with a Process #2 by using a request-response protocol where:

1. Process #1 MM-Sends a Request-Action Item to Process #2 requesting:
   • To perform an Action on one or more Item, provided as InItems that include InRights to perform Actions on the InItems. The InItems are located at a Service or at M- or U- Locations provided as InLocations.
   • To provide the requested OutItems that include OutRights to perform Actions on the OutItems. The OutItems are located at a Service or at M- or U- Locations provided as OutLocations.
2. Process #2
   • Executes Request if there are sufficient InRights.
   • Responds with a Response-Action Item:
     • Success: OutItem is provided.
     • Error: e.g., no Rights, no such IDs, etc.

This Technical Report identifies four types of Process:

1. Device is a Process having either or both the capabilities to:
   • UM-Capture, i.e., to acquire a scene at a U-Location as Media.
   • MM-Send Data and Metadata from the Device to a User who then:
     • Identifies, i.e., gives an Identifier to and produces an Item.
     • MM-Embeds, i.e., places an Entity at an M-Location with a Spatial Attitude, i.e., with a Position and Orientation and enables the MU-Rendering of the Entity.

4. App is an application-specific Program executed on a Device.
5. User is a Process representing a human who has an Account with an M-Instance/Environment. A User can be:
   • UM-Rendered as an Object representing a human.
   • MM-Embedded at an M-Location with a Spatial Attitude as a Persona
     • UM-Animated by a Stream UM-Rendered from a U-Location.
     • MM-Animated by an autonomous agent.
6. Service is a Process offering functionalities necessary for the proper functioning of an M-Instance/Environment, e.g., Discovery of an Entity or Process.

It should be noted that an M-Instance can be implemented to only execute a subset of the Actions on a subset of the Items defined by this Technical Report. An M-Instance can also implement more Functionalities requiring more Actions on more Items, either proprietary or belonging to future versions of this Technical Report. This case has obviously an impact on Interoperability.

3.5        Actions

A Process can request that another Process perform Actions on Items or Data & Metadata as follows:

• UM-Import Data and Metadata.
• Identify, e.g., by the following steps:
  • A Device MM-Sends Data and Metadata to a Service.
  • A Service MM-Sends the ID of the Entity that includes the MM-Sent Data and Metadata.
    • Data can be an Animation Stream coming from a human via a Device. The Device adds Metadata, e.g., Device ID and Rights to Act on the animation Stream, depending on the rights exercised or acquired by the Device when UM-Capturing the human.
    • The Metadata provided by the Device can be MM-Sent to a Service to Identify an Item or MM-Sent to the Service to modify the Metadata of an existing Item.

Note that the Identify Action is required to make Data and Metadata Actionable in an M-Instance/Environment.

• Hidee., make the Identifier of an Item unavailable.
• Change, i.e., modify its Rights.
• MU-Export, i.e., store as Item or Data at an Address.
• Authenticate, i.e., the User requests a Service to provide evidence that an Entity is what it states it is.
• Post to a Marketplace an Asset, i.e., an Item that can be Transacted.
• Transact an Asset.

A User can request that a Service perform the Action to:

1. Discover Items by adding to the Request-Discover Item the DiscoverIn Item providing information about the Items and/or Processes to be searched. The User receives a Response-Discover Item with a DiscoverOut Item providing information about the Items found.
2. Inform about an Item by adding to the Request-Inform Item an InformIn Item providing information about the Item for which information is sought. The User receives a Response-Inform Item with a InformOut Item providing information about the requested Item.
3. Interpret Item by adding to the Request-Interpret Item an InterpretIn Item providing information about the Item for which interpretation is requested. The User receives a Response-Interpret Item with a InterpretOut Item providing the requested Interpretation.

The currently defined Actions performed on Entities are:

1. Author, i.e., a User calls an Authoring Tool Service with an accompanying request to obtain Rights to Act on the Authored Entity.
2. MM-Add, i.e., a User requests that an Entity be added to an M-Location with a Spatial Attitude. The original [M-InstanceID] [M-EnvironmentID] [EntityID] Identifier is changed to [M-InstanceID] [M-EnvironmentID] [M-LocationID] [EntityID].
3. MM-Enable, i.e., a Process can request that an Entity MM-Added at an M-Location be MU-Rendered.
4. MM-Enable, i.e., the User requests that a Process be allowed to MM-Capture an Entity that is MM-Added at an M-Location.
5. MM-Capture, i.e., the User requests that an Entity MM-Embedded at an M-Location be MM-Sent to a Process.
6. MM-Embed, i.e., the Composite Action of MM-Adding and MM-Enabling in one stroke.
7. UM-Animate, i.e., a User requests that a Process change the features of an Entity with a Stream obtained through the following process:
   • UM-Capture an animation stream extracted from a scene at a U-Location.
   • UM-Send the animation stream and Metadata to a User.
   • Identify the Stream to make the Stream Entity usable in the M-Instance.
8. MM-Disable, i.e., a User requests that the MM-Enabling of the Entity be stopped.

A Device can:

1. UM-Render a scene at a U-Location to an M-Location, i.e.:
   • UM-Capture, i.e., acquire a scene as Media from at a U-Location.
   • MM-Send Data and Device-provided Metadata.
   • Identify an Entity from Data and Metadata.
   • MM-Embed the Entity at an M-Location with a Spatial Attitude.
2. MU-Render an Entity Embedded at an M-Location to a U-Location, i.e.:
   • MM-Send, i.e., stream to a Device an Entity that is MM-Embedded at an M-Location.
   • MU-Actuate, i.e., present the Entity as Media with a Spatial Attitude to a U-Location.

The Composite Action Track enables a User to request Services to:

1. MM-Embed a Persona at an M-Locationwith a Spatial Attitude.
2. UM-Animate the Persona MM-Embedded at an M-Location.
3. MU-Render selected Entities at the M-Location to a U-Location with a Spatial Attitude.

The full list of Actions is provided below organised by the type of Item the Action is executed on.

1.      Actions on Entities: 1.1.   Authenticate 1.2.   Author 1.3.   Identify 1.4.   Inform 1.5.   Interpret 1.6.   MM-Add 1.7.   MM-Animate 1.8.   MM-Capture 1.9.   MM-Embed 1.10.                   MM-Disable 1.11.                   MM-Enable 1.12.                   MM-Send 1.13.                   MU-Actuate 1.14.                   MU-Render 1.15.                   Track

2.      Actions on Assets: 2.1.   Post 2.2.   Transact 3.      Actions on Data from the Universe: 3.1.   UM-Animate 3.2.   UM-Capture 3.3.   UM-Import 3.4.   UM-Render 4.      Generic Actions on Items: 4.1.   Change 4.2.   Destroy 4.3.   Discover 4.4.   MU-Export 4.5.   Register

3.6        Items

An Item can belong to one of five 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 features.
3. Items that have space and time attributes.
4. Items that are finance related, called Assets.
5. Items that are generic data structures.

Items already defined above will not be defined again below.

Entity: is the first type of Item characterised by the fact that it can be MM-Captured by a User. This Technical Report identifies the following types of Entity:

5. Event: the set of Entities that are MM-Embedded at an M-Location from Start Time until End Time.
6. 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.
7. Object: An Entity that is either virtually created or is the representation of an object including its features. This Technical Report currently considers the following Object types: Audio, Visual, and Haptic.
8. Model: An Object that can be UM-Animated by a Stream or a MM-Animated by a Process.
   • Speech Model: An Object Model whose Object type is Audio, specifically Speech.
   • Avatar Model: An Object Model where the Object type is Visual.
   • Haptic Model: An Object Model where the Object type is Haptic.
   • Persona: An Object Model that may include an Avatar Model, a Speech Model, and a Haptic Model. The Persona can be perceived visually and/or audibly and/or haptically. Note that a User may appear simultaneously, for instance as:
     • The same or a different Persona UM-Animated by the same Stream at different M-Locations.
     • The same or a different Persona where one Persona is UM-Animated by a real-time Stream and the other is UM-Animated by a recorded Stream.
     • The same or a different Persona, one UM-Animated by a Stream and the other UM-Animated by an autonomous Process.
9. Scene: a dynamic composition of Objects described by Time and Spatial Attitudes.

The second type of Item can cause an Entity to change its perceptible features, i.e.:

1. Interaction: The Action made by a User on an Entity at a specific Time.
2. Stream: A continuous flow of:
   • Data from a Device to a User, or
   • Data from an Entity at an M-Location to a Device.

The third type of Item has space and time attributes:

1. M-Instance: an implementation of metaverse specifications identified by [M-InstanceID].
2. M-Environment: A portion of an M-Instance identified by [M-InstanceID] [M-EnvironmentID].
3. M-Location: An identifiable delimited portion of an M-Environment identified by [M-InstanceID] [M-EnvironmentID] [M-LocationID].
4. U-Environment: An identifiable portion of the Universe.
5. U-Location: An identifiable delimited portion of a U-Environment.
6. Map: An Item containing information connecting U-Locations, M-Locations, and optionally Metadata.

The fourth type of Item is Finance-related:

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 list of Transactions executed on an Asset starting from the first and including the last.
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.

The fifth type of Item is non-perceptible, i.e.:

1. Account: An Item issued by an M-Instance/M-Environment that uniquely identifies a human who is Registered with the M-Instance/M-Environment.
2. Activity Data.
3. All Request-Action Item.
4. All Response-Action Item.
5. Message: Application-specific Data or Item Sent by a Source to a Destination.
6. Personal Profile.
7. Social Graph.

3.7        Data Types

Actions and Items may use several Data Types. Some Data Types may relate to a Metaverse Instance or the Universe; a U-/M- prefix may be added as needed. Data Types are currently defined as follow for the specific case on M-Instances/Environments/Locations:

1. Address: A URL.
2. Amount: A number expressing a Value in a Currency.
3. Coordinates: A set of numbers representing a Position in an M-Environment using a coordinate system.
4. Currency: A medium of exchange enabling Transactions in an M-Instance.
5. Personal Status: the representation of the information internal to a User characterising their behaviour.
   • Cognitive State: the representation of a User’s Personal Status that reflects the way it understands the environment, such as “Confused”, “Dubious”, “Convinced”.
   • Emotion: the representation of a User’s Personal Status that results from its interaction with an environment, such as “Angry”, “Sad”, “Determined”.
   • Social Attitude: the representation of a User’s Personal Status related to the way the User intends to position vis-à-vis an environment, e.g., “Respectful”, “Confrontational”, “Soothing”.
6. Point: A point in an M-Environment identified by the set of local Coordinates.
7. Spatial Attitude: The Position and Orientation of an Entity, and their velocities and accelerations.
   • Position: the coordinates of an Object with respect to a set of coordinates in an M-Environment.
   • Orientation: The set of the 3 roll, pitch, yaw angles indicating the rotation around the principal axis (x) of an Object, its y axis having an angle of 90˚ counterclockwise (right-to-left) with the x axis and its z axis (pointing up toward the viewer viewing from above).
   • Point of View: The Spatial Attitude of a Persona Perceiving the M-Environment.
8. Time: the measure of time.

<- Defintions    Go to ToC   Processes –>