Yes No Type

Go to 5. Common Information Types

The Yes No Type is a reusable Enumeration used to represent a three-state response in which the value may be Yes, No, or Unknown.

The Yes No Type represents a controlled value selected from the set Unknown, Yes, or No.

Yes No Type is not equivalent to a simple Boolean value because it explicitly permits an Unknown state in addition to Yes and No.

The Unknown value represents the absence of a determined Yes or No value. It does not imply either Yes or No.

[DTE4] identifies the conceptual type as:

Yes No Type

The conceptual representation identifies Yes No Type as a controlled semantic value space rather than arbitrary text or an unconstrained numeric value.

[DTE4] identifies the following values:

The allowed values define the conceptual value space of Yes No Type.

Yes No Type provides a reusable representation for information that requires an explicit affirmative, negative, or undetermined value.

The type is independent of the Information Model class or attribute that uses it.

An attribute using Yes No Type therefore conveys two distinct pieces of information:

• the semantic question or condition represented by the attribute; and
• the controlled response value defined by Yes No Type.

For example, an attribute may ask whether a capability, condition, property, or relationship exists. The attribute defines what is being evaluated, while Yes No Type constrains the response to Unknown, Yes, or No.

Known uses of Yes No Type SHALL be recorded as the corresponding [DTE4] model elements are reviewed.

The conceptual model defines Yes No Type as an Enumeration.

The available PostgreSQL mapping realizes the type using a reusable database domain based on text.

CREATE DOMAIN YES_NO_TYPE AS TEXT;

The database representation does not, by itself, enforce or redefine the conceptual value space.

A conforming physical realization must preserve the semantic distinctions among:

• Unknown;
• Yes; and
• No.

The available mappings establish:

Yes No Type
    |
    +-- Kind: Enumeration
    |
    +-- Conceptual values:
    |     +-- Unknown
    |     +-- Yes
    |     +-- No
    |
    +-- PostgreSQL domain: yes_no_type
            |
            +-- PostgreSQL base representation: TEXT

The PostgreSQL TEXT realization is an implementation representation. It does not make Yes No Type an unconstrained text type.

Another implementation may use a different physical representation provided that the three conceptual values remain distinguishable.

The current source mappings do not establish:

• whether Unknown is the default value;
• whether an absent or NULL value is semantically distinct from Unknown;
• whether physical realizations must use the literal strings Unknown, Yes, and No;
• whether alternate encodings such as integers are permitted; or
• whether case sensitivity applies to textual realizations.

These questions should not be resolved solely from the PostgreSQL TEXT realization.

In particular, DIDO-TE should preserve the distinction between:

• an explicit Unknown value; and
• the absence of a value,

unless a deliberate model refinement establishes that they are equivalent.

• [DTE4] DIDO Reference Data Model, Yes No Type Enumeration.
• [DTE4] relational mapping, PostgreSQL domain yes_no_type.

• Preserve Yes No Type as the conceptual type name.
• Preserve the [DTE4] conceptual values Unknown, Yes, and No.
• Do not reduce Yes No Type to a two-state Boolean type.
• Do not infer that Unknown and NULL are equivalent unless that relationship is explicitly established.
• Include a Classification section on every Common Information Type page.
• Include an Allowed Values section for every Enumeration.
• Record known Information Model attributes that use Yes No Type as they are identified.
• Treat the PostgreSQL TEXT domain as a physical realization, not as the conceptual definition of the type.
• Document any change to the value space explicitly as a DIDO-TE model refinement.