Skip to content

Knowing Markup

Knowing® is build upon a fine-tuned Large Language Model (LLM) that has learned how to read and write the Knowing Markup Language (KML). All communication between application and AI is made using KML.

This section explains how the KML works and can be used for creating a better understanding about how Knowing® operates. You don't need to know KML in order to use the app. It can also be useful for anyone wanting to contribute in further fine-tuning.

The Knowing Markup Language (KML) has been made open source, allowing users full freedom to use, modify, and distribute the language as long as they provide attribution to the original source. This aligns with an open-source model similar to the Creative Commons Attribution License (CC BY), which permits any kind of use, provided proper credit is given to the creators. This license ensures that KML can be widely adopted and adapted while acknowledging its origins.

Knowing Markup in a Prompt Call Knowing Markup Language can be viewed inside Knowing® when pressing Open-In icon after a Command call.

Knowing Markup Specification

1. Overview

Knowing Markup is a minimalistic, human-readable, and AI-friendly markup language designed to represent hierarchical tree structures and track node states within different Spaces. It supports multiple Spaces, cross-referencing nodes, and includes basic text formatting. State commands like [created], [updated], and [deleted] reflect changes in node states. This specification outlines the syntax and rules for creating and interpreting Knowing Markup documents. Knowing Markup is also used as a communication protocol between the Knowing® application and Large Language Models (LLMs), enabling structured interaction and knowledge exchange.

2. Motivation

Knowing Markup provides a way to work explicitly with structured data, unlike text formats where structure is implicit. By using hierarchical tree structures within defined Spaces, the relationships between data elements become clear, enabling efficient management of complex datasets. This makes data easier to comprehend, manipulate, reorganize, and track, and facilitates effective communication between humans and AI models.

3. Core Concept: Multidimensional Trees with Spaces

Knowing Markup organizes data into different Spaces, where each Space represents a hierarchical structure. A node can belong to multiple Spaces, allowing it to reflect different perspectives or attributes.

Spaces

There are three types of Spaces in KML:

  • CONCEPTUAL SPACE: Represents domains where multidimensional concepts reside. Nodes in this Space are connected via parent relationships.
  • ATTRIBUTE SPACE: Corresponds to single properties or qualities (e.g., color, size). Nodes in this Space represent specific values of attributes. Edges from nodes in CONCEPTUAL SPACE to nodes in ATTRIBUTE SPACE represent the "have" relationship. Between other nodes in ATTRIBUTE SPACE, edges represent IsA relationships.
  • ONTOLOGY SPACE: Represents ontological structures where concepts are organized based on "IsA" relationships.

Edges are implicitly defined by the type of Space:

  • In CONCEPTUAL SPACE, edges represent parent relationships.
  • In ATTRIBUTE SPACE:
    • Edges between nodes represent IsA relationships.
    • Edges from nodes in CONCEPTUAL SPACE to nodes in ATTRIBUTE SPACE represent the "have" relationship. In ONTOLOGY SPACE, edges represent IsA relationships.

4. Document Structure

A Knowing Markup document can contain multiple Spaces, each defined by a header.

4.1 Space Declaration

A new Space is introduced with a header:

---
- {space_type}
  Label: {name}

Example:

---
- CONCEPTUAL SPACE
  Label: Vehicles
4.2 Node Declaration

Nodes must have an ID: to uniquely identify them. Temporary IDs (new-1, new-2, etc.) are placeholders and replaced with permanent IDs by the system.

Example (temporary and permanent IDs):

- ID: new-1 [created]
  Label: New Node

After system response:

- ID: 12345 [created]
  Label: New Node
4.3 State Commands

Supported state commands include: - [created], [updated], [deleted], [read-only]

Rules: - Nodes with [deleted] are retained in structure but ignored in processing. - Nodes can exist in multiple spaces and can be deleted in one but retained in another. - [read-only] nodes cannot be modified.

4.4 Content

Content can be single-line or multiline (enclosed in backticks for multiline):

Content: This node's content.
Content: `
  This is detailed content.
`
4.5 Node Types and Extensions

Nodes in Knowing Markup can be extended to represent specific functionalities such as TEMPLATE, ARTICLE, FUNCTION, WORKFLOW, NOTE, and SPACE. These are extensions of concepts used for manipulating graph content and are not definitions within the graph structure.

Examples:

  • Template:
- TEMPLATE ID: template-1
  Label: Example Template
  - ID: template-1-field-1
    Label: Age
    Content: number
  • Article (with simplified Value):
- ARTICLE ID: article-1
  Use template: template-1
  - ID: template-1-field-1
    Value: 100 years
  • Function:
- FUNCTION ID: callMe
  Label: Example Function
  - ID: callMe-argument-1
    Label: Email-address
    Content: string
  • Workflow:
- WORKFLOW ID: 52
  Label: My Workflow
  - ID: 9876
    Label: Step 1
    Use function: callMe
    Content: `
      - Write a short poem about love in outer space
      - Use the function callMe and email the poem
    `
4.6 IDs

All nodes must have an ID. Temporary IDs (e.g., new-1) are used by the assistant and replaced with permanent IDs by the system. Once a permanent ID is assigned, the assistant must reference the permanent ID in future interactions.

4.7 References Between Spaces

Nodes in one space can reference nodes from another by using the - ID: [id] syntax. A node’s details (label, content, fields) are reused from its first appearance.

Example:

- CONCEPTUAL SPACE
  ID: cs-1
  Label: Vehicles
  - ID: mc-1
    Label: Car

- ATTRIBUTE SPACE
  ID: as-1
  Label: Colors
  - ID: sc-1
    Label: Blue
    - ID: mc-1
      Label: Car #Car is having a blue color

5. Communication Protocol

Knowing Markup can be part of a communication protocol between two systems (typically, a user and an AI model). The protocol consists of a request and a response, structured according to the Context.

Each request and response must begin with a line indicating the Context: command|workflow|conversation.

5.1 Context: command

In the command context, the request holds a prompt and data, and the response holds specific fields as described below:

Request
  • Prompt: A text-based prompt representing the user's question or command.
  • Data (Knowing Markup): An optional section containing Knowing Markup data that the user provides as context.
  • AttentionBranch (string): An optional field specifying which branch within the Knowing Markup data the model should focus on.
  • AttentionNode (string): An optional field specifying which node within the specified branch should receive the model's primary attention.
Response
  • Response: Specifies the type of response from the model. Possible values include:
  • data: The model provides data, both new and modified.
  • action: The model initiates an action, such as calling a function.
  • error: The model encountered an error or invalid input in the request.

  • no-data-available: The model cannot find relevant information in the provided data.

  • Data (Knowing Markup): If applicable, this section contains Knowing Markup data that is either new or modified.

  • Action: Specifies the function to be called, including the necessary parameters.
  • Error: Specifies any errors encountered during processing.
Example command context

Request:

Context: command
Prompt: "Retrieve the animal's diet."
Data:
---
- BRANCH ID: 1234
  Label: Animals
  - ID: 1
    Label: Lion
AttentionBranch: 1234
AttentionNode: 1

Response:

Context: command
Response: data
Data:
---
- BRANCH ID: 1234
  - ID: 1
    - ID: new-1 [created]
       Label: Eating
       Content: Lions primarily eat large mammals.

5.2 Context: workflow

In the workflow context, the request contains messages from the system about the current workflow status and instructions on what to do next. The response follows the same structure as a command or conversation, but with the addition of Workflow step: and the Response: value "Finished workflow" when applicable.

Request
  • Messages: A list of system-generated messages describing the current workflow status.
  • Instructions: A summary of what needs to be done at the current step of the workflow.
Response
  • Workflow step: Indicates the current step of the workflow.
  • Workflow status: finished, if flow has been completed
  • Response: Specifies the type of response from the model:
  • data: The model provides data related to the workflow step.
  • action: The model initiates an action, such as calling a function.
  • error: The model encountered an error during the workflow.
  • Message: A conversational-style message, similar to the conversation context, which can provide additional feedback or status updates related to the workflow.
Example workflow context

Request:

Context: workflow
Messages:
  - "Starting step 2 of the workflow."
Instructions: "Please complete the data entry for the next node."

Response:

Context: workflow
Workflow step: 2
Response: data
Message: "Data entry for the next node has been completed."
Data:
---
- ID: new-2 [created]
  Label: Next Node

If the workflow is completed:

Context: workflow
Workflow step: 5
Response: Finished workflow
Message: "The workflow is now complete."

5.3 Context: conversation

In the conversation context, the request includes a prompt, and the response contains a conversational message alongside the expected data or action.

Request
  • Prompt: A conversational query or input from the user.
  • Data (Knowing Markup): Optional data provided by the user as context for the conversation.
Response
  • Response: Specifies the type of response from the model:
  • data: The model provides data based on the user's prompt.
  • action: The model initiates an action, such as calling a function.
  • Message: The model's conversational reply to the prompt, providing a natural language response.
Example conversation context

Request:

Context: conversation
Prompt: "What is the lion's behavior in the wild?"

Response:

Context: conversation
Response: data
Message: "Lions are social animals that live in groups called prides. They hunt together and communicate through vocalizations."
Data:
---
- ID: new-3 [created]
  Label: Behavior
  Content: Lions exhibit social behavior, living in groups called prides.