Most applications (apps) built for business these days are built to be accessed online rather than in a special downloadable application like we had to do in the old days.

This makes it MUCH easier to keep everyone up-to-date with the current version AND eliminates any workstation provisioning, at least for the core functionality.

SOME apps still need to live on a persons desktop or other local device.

Very little of the actual TELSTAR System has been built at the current time. There HAVE been previous operational iterations of a much smaller system that I have created, but would be of limited help to us currently. Plus, it's all older technology.

That said, virtually the ENTIRE TS has been "designed" and currently being modeled in an operational fashion through a series of Knowledgebases, each containing planned functionality, operational prototyping, primarily through text or UML diagramming, some just now beginning to have screens designed for them.

In addition, MOST of the KBs are being used as full-fledged applications to help me to continue to build out the TELSTAR system, basically, the system is being used to build itself in a recursive kind of fashion, AND actually being implemented to help with our ATOMVA/HKU project, specifically with the first version of the TELSTAR Knowledgebase and an earlier version of the TELSTAR Document Processor for the manual.

The current "entry" into the TELSTAR System is the TELSTAR Application Knowledgebase.

All other parts (knowledgebases) of the TELSTAR System can be accessed via links from that KB, including what will be the "real" TELSTAR application home screens called "Mission Control" of which has it's own KB.

A note on my spelling of "knowledgebase". The most commonly used spelling of knowledgebase these days are to spell the concept with two words, "Knowledge" and "base", therefore we have "knowledge base" as the currently "correct" spelling. But back in the old days, the one-word spelling of "knowledgebase" was much more common, as was the even-more-common hyphenated version, "knowledge-base". The one-word spelling is also the most similar to that of the word "database", which incidentally is NEVER spelled "data base". So for historical purposes, and common sense logic, and a bit of personal stubbornness from having used it for over 30 years, I have chosen to keep with the one word spelling, so please do not try to correct me on it. It was deliberately chosen to be spelled that way within the TELSTAR universe. It should also be noted that just like "DB" is often used as a shorthand of writing "database", I use KB as the shorthand for "knowledgebase".

A note on my use of capitalization. While not grammatically-correct, I often capitalize the first letter of a word as an easy way to give it emphases while typing quickly instead of taking the typing to select it and hit "bold", or adding asterisks before and after the word when writing in markdown. Anything presented to the public would have the capital changed out for bold or italics.

One type to store information on a topic, or "Informational KB" such as to hold information on a programming language such as "PHP" or "Python", or say for a specific branch of mathematics, like "Discreet Mathematics", or more humanities-oriented such as "World History" or business-oriented such as "Project Management Theory and Techniques" or "Design Concepts". I do have a KB for all of those and many, many, others.

The other type of KB is that of an "Application KB". Within that category of KBs are "Module KBs" and "System Design KBs". All very similar but each addressing different aspects of the TELSTAR system. These KBs consist of both information on what a specific application, module, or system is, how they work, or are supposed to work, how they are built, what they are built with, their interfaces with other applications, or what Modules they might use, as will has containing textual or screen operation prototyping of their operation.

An individual KB is made up of several "vaults", each containing one "aspect" of a topic, if used for general knowledge, or "aspect" of a functionality if an application KB.

Each vault contains TWO types of information, located in TWO different "buckets/directories/groupings".

The primary vault bucket is an "informational bucket" if you will, containing all "indexed" textual information. It consists of two parts, "structured metadata" (information ABOUT the entry), and "free-form content" (the information PRESENTED by the entry).

Internal Unique ID (if implemented as a hierarchical flat-file system) / Primary Key Value (if implemented as a row in a database table).

Title (primary look-up value)

Open Text / Description (NOT content, only ABOUT the content)

Creation Timestamp

Most Recent Update Timestamp

Presentation Configuration JSON or YAML entry

Plain Text (rare)

Markdown markup language (most common)

reStructured Text (most useful features)

Pure HTML, CSS, and JavaScript (all that for a single entry, if you want!)

AsciDoc (Another really cool option)

The secondary vault bucket, is the "assets bucket" and can contain literally anything you want that's related to your entries, including other files such as spreadsheets, data dumps, illustrations and diagrams, even other applications. In other words, ANYTHING you might normally keep in a normal filesystem on your computer. In fact, the assets bucket IS a special assigned folder/directory that is linked to your vault.

Currently I have consolidated into 7 vaults for each KB:

1 "SHARED Vault" that is shared across ALL Application AND Informational KBs.

6 Topic/Application-specific Vaults

5 Common to ALL KBs:

REFERENCE Vault: Used for look-up type information.

RESEARCH Vault: Used primarily to store information as it is learned prior to being located in one of the other vaults.

RESOURCES Vault: Used to contain, or provide locations to, content, tools, or anything else that can be used to contribute to the informational knowledge or running of the application.

DEVELOPMENT Vault:

For an Informational KB, this is where you would put code used in learning how to use a language, or lists of information to help you remember a timeline in history, and things that help you "develop" your understanding of the knowledge contained in the KB.

For an Application/Module/System KB, this is where both your "ideas" on the application are created, including what you want it to do, how you want it to work, "Features" that you want developed, detail on how they work, and even directly linking to code stored in the DEVELOPMENT vault's Assets Bucket!

LMS Vault:

Content that you develop on the topic to be linked directly to TELSTAR's "Learning Management System" for use in your own learning and review OR as testing for a full course and school curriculum!

1 "Catch-all Vault" for anything that doesn't lend itself to being placed into any of the other vaults.

All Individual KBs, each made up of 7 (or more) individual vaults into a KB Vault Group (I know, I just introduced you to the term now, but I use is all over in my design). In other words, each Topic/Application KB is made up of a Vault Group.

And currently I am operating several "Master" KBs made up of individual hierarchically grouped KBs. They are as follows:

Within the Projects KB is the TELSTAR Systems "Hybrid" Application/Module/Systems KB.

Note that EACH lowest-level item below is an individual KB.

AUD_100 - Sound Theory

AUD_200 - Professional Audio

CS_110 - Computer Science Concepts

CS_111 - Compilers

CS_112 - Operating systems

CS_121 - HARDWARE > Microprocessors

CS_122 - HARDWARE > Main Boards

CS_123 - HARDWARE > Hard & Solid State Drives

CS_124 - HARDWARE > Networking Devices

CS_150 - Conceptual Artificial Intelligence

DS_121 - Information Science

DS_122 - Ontologies and Taxonomies

DS_123 - Hierarchical Data Management

DS_124 - DB Design & Operation

DS_131 - Big Data

GUI_180 - Design Theory

GUI_181 - Design Reference

GUI_182 - Typography

GUI_183 - Tools & Applications

GUI_184 - 3D Concepts & Design

GUI_190 - (Advanced) Website Design

NC_151 - Network Systems Design

NC_152 - Network Security

OS_171 - Web Browser Modification

OS_172 - Code Editors & IDEs

OS_173 - Graphics Editors

OS_174 - Productivity Tools

SE_131.1 - Language Design

SE_131.2 - Discreet Mathematics

SE_132.1 - SYSTEMS Modeling & Design

SE_132.2 - SOFTWARE Modeling & Design

Subsection: Software "Design Patterns"

Subsection: "Object-Oriented" Programming (OOP)

SE_133.1 - C

SE_133.2 - C++

SE_133.3 - HTML & CSS

SE_133.4 - JavaScript

SE_133.5 - PHP

SE_133.6 - Python

SE_133.7 - Ruby

SE_133.8 - Rust

SE_133.11 - XML

SE_133.12 - JSON & YAML

SE_133.21 - Markdown

SE_133.22 - Ascidoc

SE_133.23 - reStructuredText

SE_134.01 - C & C++ Frameworks

SE_134.02 - CSS Frameworks

SE_134.11 - JavaScript Framework: Alpine

SE_134.12 - JavaScript Framework: Svelte

SE_134.13 - JavaScript Framework: Vue

SE_134.14 - JavaScript Framework: Next

SE_134.20 - PHP Framework: All Others

SE_134.21 - PHP Framework: Laravel

SE_134.22 - PHP Framework: Livewire

SE_134.23 - PHP Framework: Filament

SE_134.24 - PHP Framework: Symphony

SE_134.25 - PHP Framework: WordPress

SE_134.31 - Python Framework: Django

SE_134.32 - Python Framework: Flask

SE_135.01 - C & C++ Libraries

SE_135.02 - CSS Packages

SE_135.11 - JS Libraries

SE_135.12 - JS Packages

SE_135.21 - PHP Libraries

SE_135.22 - PHP Packages

SE_135.31 - PY Libraries

SE_135.32 - PY Packages

SE_136.10 - APPLED SE - Application Construction

SE_136.20 - APPLED SE - Applied Programming

SE_136.30 - APPLED SE - Development Tools

SE_136.40 - APPLED SE - Integrated Development Environments

SE_136.41 - APPLED SE - PhpStorm IDE

SE_136.42 - APPLED SE - VS Code IDE

SE_136.50 - APPLED SE - Skills & Techniques

SE_136.60 - APPLED SE - Software Development

SE_137.10 - General DevOps

SE_137.20 - Cloud Computing

SE_137.21 - Amazon Web Services

SE_137.22 - Oracle Cloud

SE_137.23 - MS Azure

Way to detailed to list, describe, or understand here.