Documentation prose edits for errors and clarity

[mackler]

What is the goal of this PR?

The goal of this PR is to make the documentation more readable and easily understandable.

What are the changes implemented in this PR?

The changes are mostly minor grammatical errors, with the rewording of some awkward sentences. Some changes might be considered stylistic, but for the most part the changed sentences are objectively more correctly written than before. All changes are to the descriptive prose. There are no changes to any code examples, except the type names used in the table containing subtyping definitions. There are no changes to formatting.

[vaticle-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• [x] This change is trivial and does not require a code or architecture review.

Code

• [ ] Packages, classes, and methods have a single domain of responsibility.
• [ ] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [ ] The code is canonical and the minimum required to achieve the goal.
• [ ] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [ ] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [ ] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [ ] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [ ] Any required build and release automations are updated and/or implemented.
• [ ] Any new components follows a consistent style with respect to the pre-existing codebase.
• [ ] The architecture intuitively reflects the application domain, and is easy to understand.
• [ ] The architecture has a well-defined hierarchy of encapsulated components.
• [ ] The architecture is extensible and scalable.

[izmalk]

Thank you for your contribution., but I need to warn you that we will soon release two new sections of the docs instead of the TypeDB section. At the time of their release, we will remove the TypeDB section from the docs. That can happen at the end of this week or sometime during the next one. We have been working on that release for about a month, as it changes the documentation structure quite significantly.

[mackler]

Thank you for your contribution., but I need to warn you that we will soon release two new sections of the docs instead of the TypeDB section. At the time of their release, we will remove the TypeDB section from the docs. That can happen at the end of this week or sometime during the next one. We have been working on that release for about a month, as it changes the documentation structure quite significantly.

I don't exactly understand what you mean by removing the TypeDB section from the docs. Isn't this whole repository TypeDB docs? What else is there?

Anyway, if the files that this PR changes will disappear then that would make the PR moot.

[izmalk]

I don't exactly understand what you mean by removing the TypeDB section from the docs. Isn't this whole repository TypeDB docs? What else is there?

Anyway, if the files that this PR changes will disappear then that would make the PR moot.

Right now, we have 4 Antora components - home, typedb, drivers, typeql. The TypeDB component is located here - https://github.com/vaticle/typedb-docs/tree/master/typedb-src We are preparing for a big update, with two brand new components to replace the typedb one. There are some delays, but we expecting it to be released soon. As for the PR, we can still use it for the TypeQL component: https://github.com/vaticle/typedb-docs/tree/master/typeql-src

I'd rather polish it (see comments) and merge it now, even if some of the fixes will be removed later with the TypeDB component. I just didn't want you to feel that we don't value your contribution.