Fix typos (#164)

Author: prrao87

docs/namespaces.mdx

@@ -35,13 +35,13 @@ directory:
 ```
 
 As a user of LanceDB, you might never notice namespaces at first, because LanceDB exposes the single-level
-hierarchy shown above, with hte data being stored in the `data/` directory`, wher the root namespace
-is implicit. In alternative setups, you could have multiple namespaces that we won't covere here,
-but you can more about them in the [namespace documentation](https://lance.org/format/namespace/) for the Lance format.
+hierarchy shown above, with the data stored in the `data/` directory, where the root namespace
+is implicit. In alternative setups, you could have multiple namespaces that we won't cover here,
+but you can learn more about them in the [namespace documentation](https://lance.org/format/namespace/) for the Lance format.
 
 ## Best-practice guidance
 
-- Use the default, single-level root namespace in LanceDB for locally stored, single applications or early-stage projects.
+- Use the default, single-level root namespace in LanceDB for locally stored, single-application, or early-stage projects.
 - For remote storage locations, introduce explicit namespaces when multiple teams, environments, or domains share the same catalog.
 - Treat namespace paths as stable identifiers (for example `"prod/search"`, `"staging/recs"`).
 - Avoid hard-coding object-store table paths in application code -- instead, prefer catalog identifiers + namespaces.

docs/tables/namespaces.mdx

@@ -13,9 +13,9 @@ import {
     RsNamespaceTableOps,
 } from '/snippets/connection.mdx';
 
-As described in the [Namespaces and Catalog Model](/namespaces) section, "namespaces" are LanceDB's means to generalize catalog specs, providing developers a clean way to manage hierarchical organization of tables in the catalog. The SDKs treat `namespace` as a path and can use it for table resolution when you use LanceDB outside the root namespace.
+As described in the [Namespaces and Catalog Model](/namespaces) section, namespaces are LanceDB's way of generalizing catalog specs, providing developers a clean way to manage hierarchical organization of tables in the catalog. The SDKs treat `namespace` as a path and can use it for table resolution when you use LanceDB outside the root namespace.
 
-As your table organization needs grow with time and your projects become more complex, you can use namespaces to organize your tables in a way that reflects your business domains, teams, or environments.
+As your table organization needs grow over time and your projects become more complex, you can use namespaces to organize your tables in a way that reflects your business domains, teams, or environments.
 
 ## Table operations with namespace paths
 
@@ -27,9 +27,9 @@ Let's imagine a scenario where your table management needs have evolved, and you
         └── users   (table)
 ```
 
-Below, we show how you would express table operations on that namespace. Each item in the namespace
+Below, we show how you would express table operations within that namespace. Each item in the namespace
 list (`["prod", "search"]`) represents a level in the namespace hierarchy, and the table name is
-specified when you create, open or drop it.
+specified when you create, open, or drop it.
 
 <CodeGroup>
     <CodeBlock filename="Python" language="Python" icon="python">