Update README.md

README.md

@@ -71,7 +71,7 @@ Feedback, questions, corrections, and suggestions are welcome.
 
 ## Introduction
 
-The _property graph_ is an increasingly popular data model. Pattern construction and pattern matching are important tasks when dealing with property graphs. Given a property graph schema _S_, a property graph _G_ conforming to _S_, and a query pattern _P_ conforming to _S_, all expressed in language _L=_(_L<sub>S</sub>, L<sub>G</sub>, L<sub>P</sub>, L<sub>R</sub>_), _pattern matching_ is the process of finding, transforming, merging, and annotating subgraphs of _G_ that match _P_. The syntaxes of sublanguages _L<sub>S</sub>_, _L<sub>G</sub>_, _L<sub>P</sub>_, and _L<sub>R</sub>_ define what and how symbols may be combined to create well-formed schemas, graphs, patterns, and query results, respectively. A semantics of _L<sub>P</sub>_ is a mapping (_S, G, P_) → _R_: which subgraphs of _G_ match _P_ and how to transform, merge, and annotate them. Expressive pattern languages support topological constraints, property value constraints, negations, quantifications, aggregations, and path semantics. _Calculated properties_ may be defined for vertices, edges, and subgraphs, and constraints may be imposed on their evaluation result.
+The _property graph_ is an increasingly popular data model. Pattern construction and pattern matching are important tasks when dealing with property graphs. Given a property graph schema _S_, a property graph _G_ conforming to _S_, and a query pattern _P_ conforming to _S_, all expressed in language _L=_(_L<sub>S</sub>, L<sub>G</sub>, L<sub>P</sub>, L<sub>R</sub>_), _pattern matching_ is the process of finding, transforming, merging, and annotating subgraphs of _G_ that match _P_. The syntaxes of sublanguages _L<sub>S</sub>_, _L<sub>G</sub>_, _L<sub>P</sub>_, and _L<sub>R</sub>_ define what and how symbols can be combined to form well-formed schemas, graphs, patterns, and query results, respectively. A semantics of _L<sub>P</sub>_ is a mapping (_S, G, P_) → _R_: which subgraphs of _G_ match _P_ and how to transform, merge, and annotate them. Expressive pattern languages support topological constraints, property value constraints, negations, quantifications, aggregations, and path semantics. _Calculated properties_ may be defined for vertices, edges, and subgraphs, and constraints may be imposed on their evaluation result.
 
 Many query posers are professionals (e.g., researchers, analysts, or investigators) who construct patterns as part of their daily work (e.g., investigative analytics). Such domain experts would like to construct patterns with minimal effort, minimal trial and error, and in a manner that is coherent with the way they think. The ability to express patterns in a way that is aligned with their mental processes is crucial to the flow of their work and to the quality of the insights they can draw. Many domain experts will not use textual property graph query languages (e.g., [Gremlin](https://arxiv.org/abs/1508.03843), [GSQL](https://arxiv.org/abs/1901.08248), [Cypher](https://dl.acm.org/citation.cfm?id=3190657), [PGQL](https://dl.acm.org/citation.cfm?id=2960421), [G-CORE](https://arxiv.org/abs/1712.01550), and the proposed [GQL](https://gql.today/)) either because it can be too hard for someone with little or no programming or scripting skills, or because it requires them to spend too much time on the technicalities and distracts them from their line of inquiry. As a result, they are forced to use only a predefined set of query templates or work in concert with technical experts. Both solutions are far from satisfying.