Update getting-started-with-persistence.md

Author: carlspring

docs/developer-guide/getting-started-with-persistence.md

@@ -5,23 +5,23 @@
 This page contains explanations and code samples for developers who need to store their entities into the database. 
 
 The Strongbox project uses [JanusGraph](https://janusgraph.org/) as its internal persistent storage through the 
-corresponding [Gremlin](https://tinkerpop.apache.org/gremlin.html) implementation and [spring-data-neo4j](https://spring.io/projects/spring-data-neo4j#overview) middle tier. Also we use `JTA` for transaction management and `spring-tx` implementation module from Spring technology stack.
+corresponding [Gremlin](https://tinkerpop.apache.org/gremlin.html) implementation and [spring-data-neo4j](https://spring.io/projects/spring-data-neo4j#overview) middle tier. Also we use `JTA` for transaction management and the `spring-tx` implementation module from the Spring technology stack.
 
 ## Persistence stack
 
-We using following technology stack to deal with persistence:
+We're using the following technology stack to deal with persistence:
 
- - Embedded Cassandra as direct storage (`CassandraDaemon` allows to have the Cassandra instance inside same JVM as the application)
- - JanusGraph as Graph DBMS (it is not directly a data storage, it just allows you to have access to data in the form of a graph)
- - [Apache TinkerPop](http://tinkerpop.apache.org/docs/current/reference/)  as a set of tools to interact with the database
- - [spring-data-neo4j](https://github.com/spring-projects/spring-data-neo4j) to manage transactions in Spring with `Neo4jTransactionManager` and implement custom Cypher queries with Spring Data repositories (by custom queries means `@org.springframework.data.neo4j.annotation.Query` annotation)
- - [cypher-for-gremlin](https://github.com/opencypher/cypher-for-gremlin) which translates Cypher queries into Gremlin traversals (it has some issues which prevents us to use it for `neo4j-ogm` CRUD operations, these issues will be explained below)
+ - Embedded Cassandra as direct storage (`CassandraDaemon` allows us to have the Cassandra instance inside the same JVM as the application)
+ - JanusGraph as our graph DBMS (it is not directly a data storage, it just allows you to have access to data in the form of a graph)
+ - [Apache TinkerPop](http://tinkerpop.apache.org/docs/current/reference/) as a set of tools to interact with the database
+ - [spring-data-neo4j](https://github.com/spring-projects/spring-data-neo4j) to manage transactions in Spring with `Neo4jTransactionManager` and implement custom Cypher queries with Spring Data repositories (by custom queries via the `@org.springframework.data.neo4j.annotation.Query` annotation)
+ - [cypher-for-gremlin](https://github.com/opencypher/cypher-for-gremlin) which translates Cypher queries into Gremlin traversals (it has some issues which prevent us from using it for `neo4j-ogm` CRUD operations, these issues will be explained below)
  - [neo4j-ogm](https://github.com/neo4j/neo4j-ogm) to map Java POJOs into Vertices and Edges of Graph
- - we also use custom `EntityTraversalAdapters`, which implements anonimous Gremlin traversals for CRUD operations under `neo4j-ogm` entities.
+ - We also use custom `EntityTraversalAdapters`, which implement anonimous Gremlin traversals for CRUD operations under `neo4j-ogm` entities.
 
 # Vertices and Edges
 
-Unlike a Relational DBMS, Graph DBMS have vertices and edges, not rows and tables. So in terms of Graph every persistent entity should be stored as Vertex or Edge. An example of a vertex might be `Artifact` or `AritfactCoordinates` and the relation between them would be an edge. It should be noted that, unlike RDBMS, object relations are represented by separate edge instead of just foreign key column in table. In addition to vertices, persistence objects can also be an edges, as an example the `ArtifactDependency` would be an edge between `ArtifactCoordinates` vertices.
+Unlike a relational DBMS, Graph DBMS have vertices and edges, not rows and tables. So, in terms of Graph, every persistent entity should be stored as vertex or edge. An example of a vertex might be `Artifact` or `AritfactCoordinates` and the relation between them would be an edge. It should be noted that, unlike RDBMS, object relations are represented by a separate edge, instead of just a foreign key column in a table. In addition to vertices, persistence objects can also be edges -- for example, the `ArtifactDependency` would be an edge between `ArtifactCoordinates` vertices.
 
 ## Gremlin Server
 
@@ -30,7 +30,7 @@ Unlike a Relational DBMS, Graph DBMS have vertices and edges, not rows and table
 
 ## Adding Dependencies
 
-Let's assume that you, as a Strongbox developer, need to create a new module or write some persistence code in an 
+Let's assume that you, as a Strongbox developer, need to create a new module, or write some persistence code in an 
 existing module that does not contain any persistence dependencies yet. (Otherwise you will already have the proper 
 `<dependencies/>` section in your `pom.xml`, similar to the one in the example below). You will need to add the 
 following code snippet to your module's `pom.xml` under the `<dependencies>` section:
@@ -54,9 +54,9 @@ package. For the sake of the example, let's pick `PetEntity` as the name of your
 
 If you want to store that entity properly you need to adopt the following rules:
 
-* Create the interface for your entity with all getters and setters that required to interact with the entity, according to the `JavaBeans` coding convention. This interface should extend `org.carlspring.strongbox.data.domain.DomainObject`. The need for an interface is due to hide the implementation specific details depending on underlying database, such as inheritance strategy.
-* Create the entity class which implements the above interface and have the `org.carlspring.strongbox.data.domain.DomainEntity` as the superclass.
-* Declare entity class with `@NodeEntity` or `@RelationshipEntity`
+* Create the interface for your entity with all the getters and setters that are required to interact with the entity, according to the `JavaBeans` coding convention. This interface should extend `org.carlspring.strongbox.data.domain.DomainObject`. We need an interface in order to hide the implementation-specific details that depend on the underlying database, such as inheritance strategy.
+* Create the entity class which implements the above interface and extend to `org.carlspring.strongbox.data.domain.DomainEntity`.
+* Declare an entity class with `@NodeEntity` or `@RelationshipEntity`.
 * Define a default empty constructor, this would need to create entity instance from `neo4j-ogm` internals.
 
 The complete source code example that follows all requirements should look something like this: