<-Architecture and Operation Go to ToC Items->
| 1. General | 2. App | 3. Device | 4. Service | 5. User |
1 General
Process is an instance of a Program running on the computing platform underpinning an M-Instance or on a device connected to it. A Process may perform an MPAI-specified Process Action or request other Processes to perform Process Actions using the Inter-Process Protocol. If the Items received have incompatible Qualifiers, a Process may request a Conversion Service to convert the Item so that its has a Qualifier compatible with the Process.
Four types of Processes are specified in the following: App, Device, Service, and User. This characterisation has the scope of facilitating the reading of this Technical Specification as all types of Processes are simply Processes. A Process may be defined as performing all the Functions listed in the following.
2 App
| Functions | An instance of an application-specific Program executed on a Device. |
| Functional Requirements | An App may need to be Certified to operate in a given M-Instance. |
3 Device
| Functions | A Device may: 1. UM-Capture Data from a U-Location. 2. Additionally, UM-Send Data and Metadata to a User. and/or 1. MU-Actuate an Item at a U-Location. 2. The Device may MU-Actuate after it has “MM-Sent an Item from an M-Location to the Device”. |
| Functional Requirements | To connect and interoperate with an M-Instance, a Device may need to expose its Process Capabilities to the M-Instance. |
4 Service
| Purpose | A Process that provides specific Functionalities to other Processes. |
| Functional Requirements | A Service may be: 1. One of the natively-supported Services of an M-Instance. 2. Hosted by the M-Instance but provided by a third party. |
Services are often specific of an M-Instance. Table 1 names and defines the role of Services that are specified by MPAI (in bold) and some Services of general use referenced by the Verification Use Cases.
Table 1 – A list of Services referenced in the Verification Use Cases
| Service | Description |
| Activity | Keeps track of Processes starting a session. |
| Authentication | Support User requests for Item Authentication |
| Author | Enables Users to acquire or develop Items. |
| Communication | Enables communication between Processes. |
| Conversion | Converts Data of Items to a different format based on provided Qualifier. |
| Discovery | Supports Users looking for Items of Processes with given characteristics. |
| Execution | Executes a Program. |
| ExIm | Manages input from and output to the Universe. |
| Identification | Identifies Data and Metadata as Items. |
| Information | Supports Users looking for information about Items. |
| Interpretation | Supports users requesting Interpretation of an Item. |
| Location | Manages positioning and motion of Items. |
| Parcel | Offers Parcels of M-Instance land to Users. |
| Post | Posts Items on which a User holds Rights. |
| Register | Enables humans to Register with an M-Instance. |
| Rights | Manages the Rights of Processes. |
| Transact | Enables Users to perform Transactions. |
5 User
| Functions | A Process representing a Registered human. |
| Functional Requirements | 1. A User may perform the following functions: 1.1. Act as the interface of the human with the M-Instance. 1.2. Render the User as a Persona UM-Animated by a Stream or by an autonomous agent. 2. Animation results from an MM-/UM-Anim Action and enabled by a Program run by the User. 3. The Animation Program may be part of the Processes registered by a human or provided by the M-Instance. 4. An M-Instance may not require Registration. |
<-Architecture and Operation Go to ToC Items->
