Graph Query Language: Difference between revisions

Content deleted Content added
q
Line 26:
 
==Extending existing graph query languages==
The GQL project draws on multiple sources or inputs, notably existing industrial languages and a new section of the SQL standard. In preparatory discussions within WG3 surveys of the history<ref name="GQLs history">{{cite web|url=https://s3.amazonaws.com/artifacts.opencypher.org/website/materials/DM32.2/DM32.2-2018-00085R1-recent_history_of_property_graph_query_languages.pdf|title=''An overview of the recent history of Graph Query Languages''|last=Lindaaker|first=Tobias|date=May 2018|website=|publisher=opencypher.org|accessdate=October 6, 2019}}</ref> and comparative content of some of these inputs<ref name="Summary Chart">{{cite web|url=https://s3.amazonaws.com/artifacts.opencypher.org/website/materials/DM32.2/DM32.2-2018-00086r1-summary-chart-of-cypher-pgql-gcore.pdf|title=''Summary Chart of Cypher, PGQL, and G-Core''|last=Plantikow|first=Stefan|date=May 2018|website=|publisher=opencypher.org|accessdate=November 3, 2019}}</ref> were presented. GQL will be a declarative language with its own distinct syntax, playing a similar role to SQL in the building of a database application. Other graph query languages have been defined which offer direct procedural features such as branching and looping (Apache Tinkerpop's Gremlin<ref name="Gremlin 2015">{{cite web|url=https://dl.acm.org/citation.cfm?id=2815073|title=''The Gremlin graph traversal machine and language (invited talk). In Proceedings of the 15th Symposium on Database Programming Languages (DBPL 2015). ACM, New York, NY, USA, 1-10. DOI: 10.1145/2815072.2815073''|last=Rodriguez|first=Marko A.|date=2015|website=|publisher=ACM|accessdate=November 10, 2019}}</ref>, GSQL<ref name="GSQL white paper"/>, and, themaking abilityit possible to traverse a graph iteratively['''REF TINKERPOP,to GREMLIN''']perform a class of graph algorithms, but GQL will not directly incorporate such features. <ref name="Wood Graph Query">{{cite web|url=https://dl.acm.org/ft_gateway.cfm?id=2206879&ftid=1212198&dwn=1&CFID=106456621&CFTOKEN=92daacebb1744396-220C1ECA-F98C-4552-03541423FDE04D18|title=''Query languages for graph databases. '', SIGMOD Rec. 41, 1 (April 2012), 50-60. DOI: 10.1145/2206869.2206879.|last=Wood|first=Peter T.|date=|website=|publisher=ACM|accessdate=October 25, 2019}}</ref>['''REF MARCELO''']. However, GQL is envisaged as a specific case of a more general class of graph languages, which will share a graph type system and a calling interface for procedures that process graphs.
=== SQL/PGQ Property Graph Query ===
Line 36:
Cypher allows creation, reading, updating and deleting of graph elements, and is a language that can therefore be used for analytics engines and transactional databases.
 
===The central role of visual path patterns===
Cypher uses compact fixed- and variable-length patterns which combine node and relationship (edge) topology representations with label existence and property value predicates. By matching such a pattern against graph data elements, a query can extract references to nodes, relationships and paths of interest. Those references are emitted as a "binding table" where column names are bound to a multiset of graph elements. The name of a column becomes the name of a "binding variable", whose value is a specific graph element reference for each row of the table.
 
Cypher uses compact fixed- and variable-length patterns which combine visual representations of node and relationship (edge) topology representationstopologies, with label existence and property value predicates. (These patterns are usually referred to as "ASCII Art" patterns, and arose originally as a way of commenting programs which used a lower-level graph API.[<ref name="GQLs history"/>) By matching such a pattern against graph data elements, a query can extract references to nodes, relationships and paths of interest. Those references are emitted as a "binding table" where column names are bound to a multiset of graph elements. The name of a column becomes the name of a "binding variable", whose value is a specific graph element reference for each row of the table.
 
For example, a pattern &nbsp;{{code|MATCH (p:Person}-[LIVES_IN]->(c:City)}}&nbsp; will generate a two-column output table. The first column named &nbsp;{{code|p}}&nbsp; will contain references to nodes with a label &nbsp;{{code|Person}}&nbsp;. The second column named &nbsp;{{code|c}}&nbsp; will contain references to nodes with a label &nbsp;{{code|City}}&nbsp;, denoting the city where the person lives.