docs(blog-announce): polish for blog release

Signed-off-by: Alex C-G <alexcg@outlook.com>

Author: alexcg1

blog/01-announcement.md

@@ -2,14 +2,14 @@
 
 DocArray has had a good run so far: Since being spun out of Jina ten months ago, the project has seen 141 releases, integrated six external storage backends, attracted contributors from five companies, and collected 1.4k GitHub stars.
 
-And yet we feel like we have to bring some big changes to the library in order to make it what we want it to be: the go-to solution for modelling, sending, and storing multi-modal data, with a particular soft spot for ML and neural search applications.
+And yet we feel like we have to bring some big changes to the library to make it what we want it to be: the go-to solution for modelling, sending, and storing multi-modal data, with a particular soft spot for ML and neural search applications.
 
 The purpose of this post is to outline the technical reasons for this transition, from the perspective of us, the maintainers.
 You might also be interested in a slightly different perspective, the one of Han Xiao, CEO of Jina AI and originator of DocArray. You can find his blog post [here](https://jina.ai/news/donate-docarray-lf-for-inclusive-standard-multimodal-data-model/).
 
-If you are interested in the progress of the rewrite itself, you can follow along on our [public roadmap](https://github.com/docarray/docarray/issues/780).
+If you're interested in the progress of the rewrite itself, you can follow along on our [public roadmap](https://github.com/docarray/docarray/issues/780).
 
-So, without further ado, let's delve into what the plans are for this v2 of DocArray, followed by some explanations of why we think that this is the right move.
+So, without further ado, let's delve into the plans for this v2 of DocArray, followed by some explanations of why we think that this is the right move.
 
 # The What
 
@@ -137,22 +137,22 @@ But there is a flip side to this: What does DocArray offer that differentiates i
 
 ## The Why: Data Modelling Perspective
 
-In the current DocArray, every `Document` has a fixed schema: It as a `text`, an `embedding`, a `tensor`, a `uri`, ...
-This setup is fine for simple use cases, but is not flexible enough for advanced scenarios:
+In the current DocArray, every `Document` has a fixed schema: It has a `text`, an `embedding`, a `tensor`, a `uri`, ...
+This setup is fine for simple use cases, but isn't flexible enough for advanced scenarios:
 
 - How can you store multiple embeddings for a **hybrid search use case**?
 - How do you model deeply nested data?
 - How do you store multiple data modalities in one object?
 
-All of these scenarios can only be solved by a solution that gives all the flexibility to the user, and ad dataclass-like API offers just that.
+All of these scenarios can only be solved by a solution that gives all the flexibility to the user, and a dataclass-like API offers just that.
 
 ## The Why: ML and Training Perspective
 
 `DocumentArray` is fundamentally a row-based data structure: Every Document is one unit (row), that can be manipulated, shuffled around, etc. This is a great property to have in an information retrieval or neural search setting, where tasks like ranking require row-based data access.
 
 For other use cases like training an ML model, however, a column-based data structure is preferable: When you train your model, you want it to take in all data of a given mini-batch at once, as one big tensor; you don't want to first stack a bunch of tiny tensors before your forward pass.
 
-Therefore, we will be introducing a mode for selectively enabling column-based behaviour on certain fields of your data model ("stacked mode"):
+Therefore, we will introduce a mode to selectively enable column-based behaviour on certain fields of your data model ("stacked mode"):
 
 ```python
 from docarray import Document, DocumentArray
@@ -179,45 +179,47 @@ with da.stacked('tensor'):
 
 This will make DocArray much more suitable for ML training and inference, and even for use inside of ML models.
 
-## The Why: Document Store / Vector DB perspective
+## The Why: Document Store/Vector database perspective
 
 In the current DocArray, every `DocumentArray` can be mapped to a storage backend `da = DocumentArray(storage='annlite', ...)`.
-This offers a lot of convenience for simple use cases, but the conflation of the array concept and the DB concept lead to a number of problems:
+This offers a lot of convenience for simple use cases, but the conflation of the array concept and the database concept lead to a number of problems:
 
-- It is not always clear what data is on disk, and what data is in memory
-- Not all in-place operations on a DocumentArray are automatically reflected in the associated DB, while others are. This is due to the fact that some operations load data into memory before the manipulation happens, and means that a deep understanding of DocArray is necessary to know what is going on
-- Supporting list-like operations on a DB-like object carries overhead with little benefit
-- It is difficult to expose all the power and flexibility of various vector DBs through the `DocumentArray` API
+- It's not always clear what data is on disk, and what data is in memory.
+- Not all in-place operations on a DocumentArray are automatically reflected in the associated database, while others are. This is because some operations load data into memory before the manipulation happens, and means that a deep understanding of DocArray is necessary to know what's going on.
+- Supporting list-like operations on a database-like object carries overhead with little benefit.
+- It's difficult to expose all the power and flexibility of various vector databases through the `DocumentArray` API.
 
-All of the problems above currently make it difficult to use vector DBs through DocArray in production.
-Disentangling the concepts of `DocumentArray` and `DocumentStore` will give more transparency to the user, and more flexibility to the contributors, while directly solving most of the above.
+All of the problems above currently make it difficult to use vector databases through DocArray in production.
+Disentangling the concepts of `DocumentArray` and `DocumentStore` will give more transparency to the user, and more flexibility to contributors, while directly solving most of the above issues.
 
 ## The Why: Web Application Perspective
 
-Currently it is possible to use DocArray in combination with FastAPI and other web frameworks, as it already provides a translation to pydantic.
-However, this integration is not without friction:
+Currently it's possible to use DocArray in combination with FastAPI and other web frameworks, as it already provides a translation to pydantic.
+However, this integration is not without friction, since:
 
-- Since currently every Document follows the same schema, as Document payload cannot be customized
-- This means that one is forced to create payload with (potentially many) empty and unused fields
-- While at the same time, there is no natural way to add new fields
-- Sending requests from programming languages other than Python requires the user to needlessly recreate the Document's structure
+- Currently every Document follows the same schema, as Document payload cannot be customized.
+- This means that you're forced to create a payload with (potentially many) empty and unused fields.
+- At the same time, there is no natural way to add new fields.
+- Sending requests from programming languages other than Python requires you to needlessly recreate the Document's structure.
 
 By switching to a dataclass-first approach with pydantic as a fundamental building block, we are able to ease all of these pains:
 
-- Fields are completely customizable
-- Every `Document` is also a pydantic model, enabling amazing support for FastAPI and other tools
-- Creating payloads from other programming languages is as easy as creating a dictionary with the same fields as the dataclass - same workflow as with normal pydantic
+- Fields are completely customizable.
+- Every `Document` is also a pydantic model, enabling amazing support for FastAPI and other tools.
+- Creating payloads from other programming languages is as easy as creating a dictionary with the same fields as the dataclass - the same workflow as normal pydantic.
 
 ## The Why: Microservices Perspective
 
-In the land of cloud-nativeness and microservices, the concerns from "normal" web development also apply, but are often exacerbated due to the many network calls that occur, and other technologies such as protobuf and gRPC entering the game.
+In the land of cloud-nativeness and microservices, the concerns from "normal" web development also apply, but are often exacerbated due to the many network calls that occur, and other technologies such as Protobuf and gRPC entering the game.
 
-With this in mind, DocArray v2 can offer the following improvements
+With this in mind, DocArray v2 will offer the following improvements
 
-- Creating valid protobuf definitions from outside of Python will be as simple as doing the same for JSON: Just specify a mapping that includes the keys that you defined in the Document dataclass interface
-- It is no longer necessary to re-create the predefined Document structure in your Protobuf definitions
-- For every microservice, the Document schema can function as requirement or contract about the input and output data of that particular microservice
+- Creating valid Protobuf definitions from outside of Python will be as simple as doing the same for JSON: Just specify a mapping that includes the keys that you defined in the Document dataclass interface.
+- It's no longer necessary to re-create the predefined Document structure in your Protobuf definitions.
+- For every microservice, the Document schema can function as requirement or contract about the input and output data of that particular microservice.
 
-Currently, a DocArray-based microservice architecture will usually rely on `Document` being the unified input and output for all microservices. So there might be concern here: Won't this new, more flexible structure create a huge mess where microservices cannot rely on anything?
-We argue the opposite! In complex real-life settings, it is often the case that input and output Documents heavily rely on the `.chunks` field to represent nested data. Therefore, it is already unclear what exact data model can be expected.
-The shift to a dataclass-first approach allows you to make all of these (nested) data models explicit instead of implicit, leading to _more_ interoperability between microservices, not less.
+Currently, a DocArray-based microservice architecture usually relies on `Document` being the unified input and output for all microservices. So there might be concern here: Won't this new, more flexible structure create a huge mess where microservices cannot rely on anything?
+
+We argue the opposite! In complex real-life settings, input and output Documents often heavily rely on the `.chunks` field to represent nested data. Therefore, the exact data model that you can expect is already unclear.
+
+The shift to a dataclass-first approach lets you make all of these (nested) data models explicit instead of implicit, leading to _more_ interoperability between microservices, not less.