Definition
Functional Requirements
Syntax
Semantics
Conformance Testing
Performance Assessment
Definition
BKN-DAC (PGM-KDA): The Data Type exchanged between Basic Knowledge and Domain Access (Deliberative Domain Access) through the Dialogic Semantic Query Interface, implemented with the Model Context Protocol. It has two modes, told apart by Mode: Request (RQ), sent by Basic Knowledge, that asks for domain knowledge (grounding of terms, affordances, constraints, behavioural expectations), for the validation of the feasibility of Process Actions that Basic Knowledge is considering, or for the retention of semantic commitments; and Response (RS), sent by Domain Access. The exchanges of one dialogue are told apart by TurnIndex within the DialogID; Domain Access retains the commitments for the duration of the dialogue.
Functional Requirements
- Header: The Data shall have Header “PGM-KDA-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.
- 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 (QueryID, QueryTime).
- Correlation: A Response shall carry the identifier (RequestID) of the Request that it answers.
- Dialogue: The Data shall carry the DialogID of the dialogue (the Model Context Protocol session) and the TurnIndex of the exchange; a Response shall have the TurnIndex of its Request.
- Request: A Request shall state its Kind and may carry the question, the terms to be grounded, the Entities and the Space concerned, the Process Actions whose feasibility is to be validated, and the commitments to be retained or released.
- Response: A Response shall state the Outcome and may carry the Answer, the status of the commitments, the PA Status of each Process Action submitted with an overall result, the sources used and the failure of a source.
- Metadata: The Data shall include DataXMData and may include DescrMetadata.
Syntax
https://schemas.mpai.community/PGM1/V1.0/data/BKNDAC.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 BKN-DAC
| Label | Description |
| Header | Header of the Data Type, with the version. (required) |
| Mode | RQ for a Request, RS for a Response. 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) |
| QueryID | Identifier of this Request or Response. (required) |
| QueryTime | Time at which the Data was produced. (required) |
| DialogID | Identifier of the dialogue (the Model Context Protocol session) to which the exchange belongs. Semantic commitments are kept for the duration of the dialogue. (required) |
| TurnIndex | Ordinal position of the exchange in the dialogue, starting from 0. A Response has the TurnIndex of its Request. (required) |
| 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 |
| Kind | What Basic Knowledge asks for. One of: semantic_grounding, affordances, constraints, behavioural_expectations, feasibility, clarification, commitment. |
| Question | The question or goal of Basic Knowledge, in natural language. |
| Terms | Terms to be grounded in the domain. |
| – Text | Text. (required) |
| – Class | Class. |
| EntityIDs | Identifiers of the Entities and Items the Request concerns. |
| Space | The Space the Request concerns. |
| – SpaceID | Space ID. |
| – MLocation | M-Locations the capture is directed at. |
| ProcessActions | The Process Actions whose feasibility is to be validated, when Kind is feasibility. |
| – 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) |
| Commitments | Semantic commitments Domain Access is asked to retain. |
| – CommitmentID | Commitment ID. (required) |
| – Statement | A semantic commitment to be retained for the dialogue. (required) |
| ReleasedCommitmentIDs | Commitments Domain Access may stop retaining. |
Table 3 – Properties of the Response (Mode RS)
| Label | Description |
| RequestID | ID of the Request this Response answers. |
| Outcome | The outcome. One of: answered, partially_answered, not_answered. |
| Answer | The domain knowledge returned, as appropriate to the Kind of the Request. |
| – ObjectClasses | Object Classes. |
| –– Class | Class. (required) |
| –– Label | Label. |
| –– Confidence | Confidence, 0 to 1. |
| – Relations | Relations. |
| –– Subject | Subject. (required) |
| –– Predicate | Predicate. (required) |
| –– Object | Object. (required) |
| – Affordances | Request: whether the production of the affordances of the Space is required, optional or not_requested. Response: fulfilment of the production of the affordances of the Space (produced, partial, missing or not_requested). |
| –– EntityID | Identifier of the Entity concerned. |
| –– Class | Class. |
| –– Action | Action. (required) |
| – Constraints | Constraints, as strings. |
| – BehaviouralExpectations | Behavioural Expectations. |
| – Text | The answer in natural language. |
| CommitmentStatus | Status of the commitments of the dialogue. |
| – CommitmentID | Commitment ID. (required) |
| – Status | Status. One of: retained, released, conflicting. (required) |
| Feasibility | Result of the validation of the Process Actions of the Request. |
| – Steps | Outcome for each Process Action. (required) |
| –– Step | Index of the Process Action in the sequence. (required) |
| –– PAStatus | The PA Status of MMM-TEC V2.2 that the Process Action would receive. One of: Ack, Clash, FaultyReq, IncID, IncDQ, InsRights, InsValue, LocOOR, PostRef, QualNS. (required) |
| –– Reason | Reason (Response) or explanation (Correction). |
| – Overall | Overall. One of: feasible, partially_feasible, infeasible. (required) |
| SourcesUsed | The domain knowledge sources used. |
| Failure | Failure of a source of domain knowledge. |
| – Service | Name of the external service. (required) |
| – Request | Request. |
| – Nature | Nature. One of: transient, permanent. (required) |
Conformance Testing
Data conforms with BKN-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.
