Design

Data model

---
title: Vetting Preferences Entity Relationships
---
erDiagram
    Property 1--0+ PropertyTenant : prefers
    PropertyTenant {
        integer id PK
        uuid property_id FK
        integer tenant_id FK
        json info
    }
    PropertyTenant 0+--1 TenantType : "is prefered"
    TenantType {
        integer id PK
        string type_id FK
        string name
        string defaultLabel
        json config
    }
    TenantType 1+--1 PreferenceType : "belongs to"
    PreferenceType {
        string id PK
        string label
        CURI answered_by FK
        json config
    }
    PreferenceType 1--1 "SeekerProfile->Property" : "is answered by"

Dialogue Manager

The dialogue manager manages the inputs between the users and a form/task.

The following simple flow can express its operation:

---
title: Dialogue Manager
---
flowchart TD
    S([Start])
    S-->T{Any Incomplete Tasks?}
    T-->|yes|NT[Choose incomplete Task]
    T-->|no|D([Done])
    NT-->P{Pre-condition Met?}
    DB-->|reads|P
    P-->|yes|A[Mark Active]
    A-->RT{Remaining incomplete tasks?}
    P-->|no|I[Mark Inactive]
    I-->RT
    RT-->|yes|NT
    RT-->|no|AT{Any Active Tasks?}
    AT-->|yes|CA[Choose An Active Task]
    AT-->|NO|D
    CA-->DO[Mark others incomplete]
    DO-->ET[[Execute Task]]
    ET-->|writes|DB
    ET-->MC[Mark Task Complete]
    MC-->T
    DB[(State)]

Tasks

There are two kinds of tasks in a dialogue: inform (or tell) and request (or ask).

Inform Task

The inform task is used to provide information to the user. This can be instructions, notices or warnings.

Request Task

The request task is used to ask the user for information. And is usually paired with a form component. Upon completion, the user's response updates the dialogue state.

Special Tasks

In some cases, the dialogue may need to account for some edge cases, save progress, or terminate early. Special tasks handle these. The usual set is:

Terminate the dialogue with an optional message.
Update the dialogue state.
Query some external data.
Mutate some external data.

Pre-conditions

The pre-condition is a set of conditions that must be met before the task can be executed. The easiest way to think of it is like a query run over the dialogue state. When the query has at least one match, the pre-condition is met.

Patterns & Unification

A set of patterns represents queries; these patterns can be in the form of a triple (e.g. subject, predicate, object) or the shape of the data you expect (e.g. a JSON object). You can use these patterns to perform the same queries you could with SQL. This is possible due to the existence of logic variables and unification.

A logic variable is a string starting with a ? and a name, e.g. ?id, ?type, etc. When a logic variable is encountered, the possible values for that variable are updated. From then on, whenever that variable appears, it must be one, some, or none of those values.

bahulneel/design.md