In part I of this series of posts, we have highlighted the basic elements that enable operation of an M-Instance, especially Processes, Items, Actions and Data Type. In particular, Processes can take the shape of a User (a representative of a human in an M-Instance), a Device (to enable the connection of an M-Instance with the real world, called Universe), and a Service.
We are now going to identify the functional requirements of an initial list of Actions that enable a Process to do useful things in an M-Instance.
Functional requirements | Actions |
To Register with an M-Instance or M-Environment. This Action may only be performed by a human or a legal entity, not by a User | Register (human) |
To transmit a Request-Action to a Process. The Request-Action should contain: the Action, the Items involved in the Action, the location where the necessary input Items are located, the location where the produced output Items are located, and the Rights that the requesting Process wishes to hold to be able to perform Actions on the Items produced. | Request (Request-Action) |
To transmit a Response-Action to a Process. The Response-Action should contain the output Items or an error message. | Respond (Response-Action) |
To enable a User to increase or diminish the Rights of a Process, e.g., because new Rights have been acquired or because a User has not complied with the Rules, we need the Action | Change (Rights of a Process) |
To confirm that the speech or the face of a human or an object imported into an M-Instance is from a specific human or U-Location (place in the real world), we need the Action. Note: The User requesting Authentication may also request Rights to use the information received, e.g., to publish it. | Authenticate (Item). |
To disable access to certain Item no longer accessible by all Processes (assuming that Rights have not been irrevocably granted to a Process) we need the Action Note: The Item may be made accessible again depending on the Rights of the User Hiding the Item. | Hide (Item). |
To create an Item out of Data and Metadata. For instance, a Device may capture Media as Data subject to certain Rights for use in an M-Instance. Create converts them to an Item usable in the M-Instance because an M-Instance can only Act on Items. | Identify (Item) |
To create a new Item by modifying an original Item with new or partially new Data and Metadata. For instance, a User with Rights on an Item may wish clone and then modify the components of an existing Item. | Modify (Item) |
To author an Item by calling a Service and providing it with Data and Metadata. Note: An M-Instance can provide a Service, internal or external to the M-Instance, that Users can call to create Items for use in the M-Instance. | Author (Item) |
To find Items by giving a description of the Items. Comments: An M-Instance can provide a Service that Users can call to find Items or Processes they need. Alternatively, the M-Instance may allow a User to Call an external Service to find Items of interest also outside of the M-Instance. | Discover (Item) |
To inform about an Item. A User may wish to know more about an Item, starting from its Metadata but potentially including other information the a Service has collected on the Item. | Inform (Item) |
To interpret an Item. For instance, a User may need the translation of an utterance produced by an avatar, recognise the face of an avatar, have its own message expressed in sign language into a speech segment. | Interpret (Item) |
To display an Asset. For instance, a User may wish to manifest its intention to surrender (part of) its Rights on an Asset. This can be done by placing the Asset at an M-Location that other Users can see or by posting it to a marketplace. | Post (Asset) |
To make a Transaction of an object. A User may like to surrender (part of) the Rights to an Asset to another User, possibly recognising the facilitation role of a Service in the Transaction. At the end of the Transaction the parties making the Transaction have different Rights on the Asset and the status of their Wallets may have changed. | Transact (Asset) |
To place an Entity (an Item that can be perceived) at an M-Location in such a way that other Users may not perceive it. This may be useful when the User needs to add more Entities to the M-Location without showing the preparations. | MM-Add (Entity) |
To make an Entity perceptible that was not until that moment, e.g., because the User did not want to show the Entity is not at a given time. | MM-Enable (Entity) |
To stop making an Entity perceptible, e.g., because the User does not want to show the setting of an event when the event is over. | MM-Disable (Entity) |
To transmit an Item to a Process. This is done, e.g., when a Device sends Data and Metadata coming from the Universe to a Service that Identifies the Item created from Data and Metadata, when a Uses captures an Entity at an M-Location (i.e., it asks the Service to MM-Send the Entity) or when a User transmits an Entity to a Device for rendering in the Universe. | MM-Send (Item or Data and Metadata) |
To activate a Contract. i.e., a Program and its Metadata stored on a Device and activated by an external entity, e.g., a User, or another activated Contract. Of course, Contracts may be Executed by an underlying Blockchain. | Execute (Contract) |
To animate a Model, i.e., an Object in the M-Instance representing an object at a U-Location with its features ready to be animated using a Process that is an autonomous agent. | MM-Animate (Item) |
To animate a Model using a Process that receives a Stream from a U-Location and animates the Model. The Process may be provided by the M-Instance, the human, or a third-party. | UM-Animate |
To present Media (i.e., Data and Metadata representing perceptible information) available at a Device to a U-Location as an Entity with an associated Spatial Attitude (i.e., Position and Orientation). For instance, a User may request that a Device present the Media is has received as an Entity from the M-Instance via an MM-Send Action. | MU-Actuate (Media) |
To present an Entity that is at an M-Location to a U-Location as an Entity with an associated Spatial Attitude. This operation is performed in two steps: MM-Send the Entity to a Device and MU-Actuate the Media from the Device. | MU-Render (Entity) |
To capture a scene at a U-Location as Media. A User may ask a Device to capture a scene at a U-Location as Media. | UM-Capture (scene) |
To transmit Data and Metadata to a Process. A User may ask a Device to transmit the Data corresponding to the Media and Device Metadata. | UM-Send (Data and Metadata) |
To present a scene that is at a U-Location to an M-Location as an Entity with an associated Spatial Attitude. This operation is performed in three steps: the Device captures the scene that is at the U-Location as Media (UM-Capture), then it UM-Sends the Data and Device Metadata to a Service that Identifies the Entity and MM-Embeds it at the M-Location. | UM-Render (scene) |
To store an Item at an Address, i.e., to an Item to a Device or to store an Item at an Address. | MU-Send (Item) |
To place a Model at an M-Location, animate it with a Stream, and present the animated Model at a U-Location with an associated Spatial Attitude. In other terms, the round trip real-virtual-real is established. | Track (Model) |
To verify that a Process has Rights to make an Action on an Item, to preserve the integrity of M-Instance operation. | Validate (Process) |
To convert an Item of a Request-Action or Response-Action to another Data Format. As for other Services, Convert can be a Service offered by the M-Instance or available outside of the M-Instance. | Convert (Item) |
To transmit a Request-Action to a Resolution Service to enable a ProcessA in M-InstanceA to communicate with ProcessB in a different M-InstanceB. As for other Services, Resolution can be a Service offered by the M-Instance or available outside of the M-Instance. | Request (Request-Action) |
To transmit a Response-Action to a Resolution Service that has sent a Request-Action. | Respond (Response-Action) |
Of course, more Actions can be identified but those introduced above have been tested to cover a significantly large number of use cases in a variety of application domains.
To know more about the MPAI Metaverse Model Architecture and the Call for Technologies, join the online presentations at 8 and 15 UTC on 23 June. Register here for the first and here for the second presentation.