Go to PGM-AUA V1.0 Data Types

Definition
Functional Requirements
Syntax
Semantics
Conformance Testing
Performance Assessment

Definition

AUC-DAC (PGM-UCD) is the Data Type that A‑User Control and Domain Access exchange. It has two modes: the Request (RQ), sent by A‑User Control to Domain Access, and the Response (RS), sent by Domain Access to A‑User Control. The Request sets a goal that Domain Access attempts: it is binding as to the goal and the constraints it imposes and advisory as to the conclusion. Every Request is answered by a Response that reports the goal Domain Access understood, the outcome reached and, if the goal was not achieved as requested, the reason.

Functional Requirements

  1. Header and Mode: The Data shall have Header “PGM-UCD-V1.0” and Mode equal to RQ for a Request and to RS for a Response; the properties that belong to the other mode shall not be present.
  2. Identification: The Data shall carry the identifiers of the M‑Instance, of the U‑Environment and of the session, and a unique identifier and a time (AUCDACID, AUCDACTime).
  3. Correlation: A Response shall carry the identifier (RequestID) of the Request that it answers; a Request that continues an exchange shall carry, in Exchange, the identifier of the Response to which it follows.
  4. Instruction: A Request shall state the Instruction (PED, GLA, PKQ, GII, PRF, PCE, CME or AFR) under which A‑User Control issues it.
  5. Storage: A Request may state what Domain Access may write to and read from the Private Storage of the Module, under the rules set by A‑User Control; the Response reports the outcome of the writes in StorageOutcome.
  6. Process Action outcome: A Request may convey the outcome of a Process Action performed by A‑User Control, so that Domain Access operates knowing the current state of the M‑Instance.
  7. Outcome and Reason: A Response shall state the goal as it was understood (GoalUnderstood, where the type has it) and the Outcome (achieved, achieved_differently or not_achieved); when the Outcome is not achieved, the Response shall carry a Reason.
  8. Domain: A Request shall state the domain context and may request domain operations at operation level and the sources that may be used.
  9. Feasibility: A Request may ask for the validation of the feasibility of Process Actions; the Response gives, for each step, the PA Status that the Process Action would receive, and an overall result.
  10. Metadata: The Data shall include DataXMData and may include DescrMetadata.

Syntax

https://schemas.mpai.community/PGM1/V1.0/data/AUCDAC.json

Semantics

Table 1 gives the properties common to the two modes, Table 2 those of the Request and Table 3 those of the Response.

Table 1 – Properties common to the Request and the Response of AUC-DAC

Label Description
Header Header of the Data Type, with the version. (required)
Mode RQ for a Request (A-User Control to the AIM), RS for a Response (the AIM to A-User Control). One of: RQ, RS. (required)
MInstance Identifier of the M-Instance. (required)
UEnvironment Identifier of the U-Environment. (required)
SessionID Identifier of the A-User session. (required)
AUCDACID Identifier of this Request or Response. (required)
AUCDACTime Time at which the Request or the Response was produced. (required)
DomainContext Request: The domain in which interpretation must occur. Response: The domain context used.
– DomainType Type of domain (e.g., physical, intellectual, interactional). (required)
– DomainInstance Specific domain instance. (required)
– OntologyRef Reference to the ontology.
– ConstraintSet Reference to the applicable constraints.
– InteractionMode Interaction context applied.
DataXMData Data Exchange Metadata of MPAI-PTF: provenance, authorisation, security and confidence of the Data.
DescrMetadata Descriptive metadata (plain text, at most 2048 characters).

Table 2 – Properties of the Request (Mode RQ)

Label Description
Instruction The Instruction under which AUC issues the Request. One of: PED, GLA, PKQ, GII, PRF, PCE, CME, AFR. (required)
Exchange Exchange. (required)
– Phase Whether the Request starts an exchange (new) or continues one (continuation). One of: new, continuation. (required)
– ResponseID ID of the Response to which a continuation Request follows.
Storage What the AIM may write to and read from the Private Storage of the Module, under the rules set by AUC.
– Write Data that the AIM may write, with the rules that apply.
–– Category Category of the data. (required)
–– Readers AIMs that may read the datum.
–– Time Longest time the datum is kept: module, session or persistent. One of: module, session, persistent.
– Read Categories of data that may be read.
ProcessActionOutcome Outcome of a Process Action performed by AUC in the M-Instance, conveyed so that the AIM operates knowing the current M-Instance state.
– PAStatus PA Status of the Process Action: Ack or the reason of the refusal (Clash, FaultyReq, IncID, IncDQ, InsRights, InsValue, LocOOR, PostRef, QualNS).
– Complements The Complements received with the Process Action Response.
– Constraint Resulting constraint on the Goal.
Goal Binding as to the objective and the constraints. (required)
– Objective The objective to pursue. (required)
– Constraints Constraints, as strings.
Operations The domain operations requested, at operation level.
– ResolveAmbiguities Request: whether the production of the resolution of ambiguities is required, optional or not_requested. Response: fulfilment of the production of the resolution of ambiguities (produced, partial, missing or not_requested). One of: required, optional, not_requested.
– ApplyConstraints Request: whether the production of the application of the constraints is required, optional or not_requested. Response: fulfilment of the production of the application of the constraints (produced, partial, missing or not_requested). One of: required, optional, not_requested.
– SemanticEnrichment Request: whether the production of the semantic enrichment is required, optional or not_requested. Response: fulfilment of the production of the semantic enrichment (produced, partial, missing or not_requested). One of: required, optional, not_requested.
– CrossModalResolution Request: whether the production of the cross-modal resolution is required, optional or not_requested. Response: fulfilment of the production of the cross-modal resolution (produced, partial, missing or not_requested). One of: required, optional, not_requested.
Serving Whether Domain Access serves capture-level grounding, reasoning-level semantics or both. One of: capture, reasoning, both.
Feasibility Validation of the feasibility of Process Actions that are being considered (used under the PRF and PCE Instructions).
– ProcessActions The Process Action statements, in the syntax of MMM-TEC V2.2. (required)
–– Step Index of the Process Action in the sequence. (required)
–– Statement A Process Action statement conforming with the grammar of MMM-TEC V2.2. (required)
– SceneContext Scene and focus the Process Actions refer to.
–– SceneID Identifier of the scene.
–– UserFocus Identifier of the entity the User focuses on.
Sources External domain knowledge sources that Domain Access may use.
– ExternalAllowed Whether external domain knowledge sources may be used.
– Allowed The Process Actions that may be proposed or used.

Table 3 – Properties of the Response (Mode RS)

Label Description
RequestID ID of the Request this Response answers. (required)
Outcome The outcome reached. One of: achieved, achieved_differently, not_achieved. (required)
Reason Structured reason, required when Outcome is not ‘achieved’.
– Code Code of the reason. One of: none, service_unavailable, constraint_conflict, insufficient_context, deadline_exceeded, not_permitted. (required)
– Description Description of the reason.
StorageOutcome Outcome of the writes instructed by the Request.
– Category Category of the data. (required)
– Result Result of the operation. One of: written, not_authorised, not_attempted. (required)
GoalUnderstood The goal as the AIM understood it. (required)
– Objective The objective to pursue. (required)
– Constraints Constraints, as strings.
Fulfilment Fulfilment of the requested operations.
– ResolveAmbiguities Request: whether the production of the resolution of ambiguities is required, optional or not_requested. Response: fulfilment of the production of the resolution of ambiguities (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested.
– ApplyConstraints Request: whether the production of the application of the constraints is required, optional or not_requested. Response: fulfilment of the production of the application of the constraints (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested.
– SemanticEnrichment Request: whether the production of the semantic enrichment is required, optional or not_requested. Response: fulfilment of the production of the semantic enrichment (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested.
– CrossModalResolution Request: whether the production of the cross-modal resolution is required, optional or not_requested. Response: fulfilment of the production of the cross-modal resolution (produced, partial, missing or not_requested). One of: produced, partial, missing, not_requested.
FeasibilityResult Outcome of the feasibility validation, expressed with the PA Status vocabulary of MMM-TEC V2.2.
– Steps Outcome for each Process Action. (required)
–– Step Index of the Process Action in the sequence. (required)
–– PAStatus Ack: the Process Action can be performed. Otherwise the PA Status it would receive. One of: Ack, Clash, FaultyReq, IncID, IncDQ, InsRights, InsValue, LocOOR, PostRef, QualNS. (required)
–– Detail Detail on the result.
– Result Result of the operation. One of: feasible, not_feasible, deferred. (required)
ServiceFailures Failures of external domain knowledge sources.
– Service Name of the external service. (required)
– RequestID Identifier of the Request that the Response answers.
– Kind Kind of source or of failure. One of: transient, permanent. (required)

Conformance Testing

Data conforms with AUC-DAC if it validates against the schema of Section 3 and, if the Mode is RQ, contains the properties required for a Request and none of those of a Response, and vice versa. If a schema contains references to other schemas, conformance of data for the primary schema implies that any data referencing a secondary schema shall also validate against the relevant schema.

Performance Assessment

Not part of this specification.

Go to PGM-AUA V1.0 Data Types