Content deleted Content added
No edit summary |
→ISO stages: wikitable |
||
| (149 intermediate revisions by 57 users not shown) | |||
Line 1:
{{Short description|Query language for property graphs}}
{{Multiple issues|
{{Overly detailed|date=March 2020}}
{{Self-published|date=March 2020}}
{{missing information|the language itself: syntax, examples ([https://cloud.google.com/spanner/docs/reference/standard-sql/graph-query-statements google cloud documentation] might help)|date=July 2025}}
}}
{{distinguish|text=[[GraphQL]] for querying APIs}}
{{infobox programming language
| name = GQL (Graph Query Language)
| paradigm = [[Declarative programming|Declarative]]
| family = [[Query language]]
| released = {{Start date and age|April 12, 2024|df=yes}}
| developer = [[ISO/IEC JTC 1/SC 32|ISO/IEC JTC 1 (Joint Technical Committee 1) / SC 32 (Subcommittee 32)]] / WG 3 (Working Group 3)
| website = {{URL|https://www.iso.org/standard/76120.html}}
| latest_release_version = {{URL|https://www.iso.org/standard/76120.html|ISO/IEC 39075:2024}}
| latest_release_date = {{Start date and age|April 12, 2024|df=yes}}
| influenced_by = [[SQL]], [[Cypher (query language)|Cypher]], [[TigerGraph|GSQL]]
}}
'''GQL''' ('''Graph Query Language''') is a [[Technical_standard|standardized]] [[query language]] for [[property graphs]] first described in ISO/IEC 39075, released in April 2024 by [[ISO/IEC]].
== History ==
The GQL project is the culmination of converging initiatives dating back to 2016, particularly a private proposal from [[Neo4j]] to other [[database]] vendors in July 2016,<ref name="Creating standard">{{cite web|url=https://s3.amazonaws.com/artifacts.opencypher.org/website/materials/DM32.2/DM32.2-2018-00144.Creating+an+Open+Industry+Standard+for+a+Declarative+Property+Graph+Query+Language.pdf|title=''Creating an Open Industry Standard for a Declarative Property Graph Query Language''|last1=Green|first1=Alastair|date=July 2016|publisher=opencypher.org|access-date=November 12, 2019}}</ref> and a proposal from [[Oracle_Corporation|Oracle]] technical staff within the ISO/IEC JTC 1 standards process later that year.<ref name="Towards NWIP">{{cite web|url=https://s3.amazonaws.com/artifacts.opencypher.org/website/materials/DM32.2/DM32.2-2018-00128r1.Working+towards+a+GQL+NWIP.pdf|title=''Working towards a New Work Item for GQL, to complement SQL PGQ'', ANSI INCITS DM32.2 submission ''DM32.2-2018-00128r1''|last1=Green|first1=Alastair|date=July 2018|publisher=opencypher.org|access-date=November 12, 2019}}</ref>
=== 2019 GQL project proposal ===
In September 2019 a proposal for a project to create a new standard [[Graph_(discrete_mathematics)|graph]] query language (ISO/IEC 39075 Information Technology — Database Languages — GQL)<ref name="39075 GQL">{{cite web|title=ISO/IEC 39075 Information Technology — Database Languages — GQL|url=https://www.iso.org/standard/76120.html|access-date=January 7, 2022|publisher=ISO}}</ref> was approved by a vote of national standards bodies which are members of ISO/IEC Joint Technical Committee 1([https://jtc1info.org/page-3/ ISO/IEC JTC 1]). JTC 1 is responsible for international Information Technology standards. GQL is intended to be a declarative database query language, like [[SQL]].
The 2019 GQL project proposal states:
{{blockquote|text="Using graph as a fundamental representation for [[data modeling]] is an emerging approach in [[data management]]. In this approach, the [[data set]] is modeled as a graph, representing each data entity as a [[Vertex_(graph_theory)|vertex]] (also called a node) of the graph and each relationship between two entities as an [[Glossary_of_graph_theory#edge|edge]] between corresponding vertices. The graph data model has been drawing attention for its unique advantages.
Firstly, the graph model can be a natural fit for data sets that have hierarchical, complex, or even arbitrary structures. Such structures can be easily encoded into the graph model as edges. This can be more convenient than the relational model, which requires the [[Database normalization|normalization]] of the data set into a set of [[Table_(database)|tables]] with fixed [[Row_(database)|row]] types.
Secondly, the graph model enables efficient execution of expensive queries or data analytic functions that need to observe multi-hop relationships among data entities, such as [[Reachability analysis|reachability queries]], [[Shortest path problem|shortest or cheapest path queries]], or [[centrality]] analysis. There are two graph models in current use: the [[Resource Description Framework]] (RDF) model and the Property Graph model. The RDF model has been standardized by W3C in a number of specifications. The Property Graph model, on the other hand, has a multitude of implementations in [[graph database]]s, [[graph algorithms]], and graph processing facilities. However, a common, standardized query language for property graphs (like SQL for relational database systems) is missing. GQL is proposed to fill this void."<ref name="39075 GQL NWIP">{{cite web|url=https://isotc.iso.org/livelink/livelink?func=ll&objId=20911483&objAction=Open&viewType=1|title=SC32 WG3 N282 "SC32 N3002 Draft NWIP Form4 Information Technology – Database Languages - GQL"|publisher=ISO|access-date=December 9, 2019}}</ref>}}
====
The GQL standard, ISO/IEC 39075:2024 Information technology – Database languages – GQL, was officially published by ISO on
12 April 2024.<ref>{{cite web |title=ISO/IEC 39075:2024 Information technology — Database languages — GQL |url=https://www.iso.org/standard/76120.html |website=ISO |access-date=25 May 2024}}</ref>
=== GQL project organisation ===
The GQL project is led by [https://de.linkedin.com/in/stefan-plantikow-49896637 Stefan Plantikow] (who was the first lead engineer of [[Neo4j]]'s [[Cypher (query language)|Cypher]] for [[Apache Spark]] project) and [https://www.linkedin.com/in/stephencannan Stephen Cannan] (Technical Corrigenda editor of SQL). They are also the editors of the initial early working drafts of the GQL specification.<ref name="GQL EWD v2.2">{{cite web|url=https://isotc.iso.org/livelink/livelink?func=ll&objId=20836584&objAction=Open|title=''GQL Early Working Draft v2.2''.|last1=Eds. Plantikow|first1=Stefan|last2=Cannan|first2=Stephen|date=October 2019|publisher=ISO|access-date=November 9, 2019}}</ref>
As originally motivated,<ref name="Towards NWIP"/> the GQL project aims to complement the work of creating an implementable normative natural-language specification with supportive community efforts that enable contributions from those who are unable or uninterested in taking part in the formal process of defining a JTC 1 International Standard.<ref name="community">{{cite web|url=https://www.gqlstandards.org/|title=''GQL Standard''|access-date=November 12, 2019}}</ref><ref name="GCU 3">{{cite web|url=https://www.gqlstandards.org/community-updates|title=''GQL Community Updates''|access-date=November 12, 2019}}</ref> In July 2019 the [[Linked Data Benchmark Council]] (LDBC) agreed to become the umbrella organization for the efforts of community technical working groups. The Existing Languages and the Property Graph Schema working groups formed in late 2018 and early 2019 respectively. A working group to define formal [[denotational semantics]] for GQL was proposed at the third GQL Community Update in October 2019.<ref name="FSWG">{{cite web|url=https://drive.google.com/open?id=15DAUAORu477FF-DooTH2ol0SZhx2ARtr|title=''Formal Semantics Working Group''|last=Libkin|first=Leonid|access-date=November 12, 2019}}</ref>
=== ISO/IEC JTC 1/SC 32 WG3 ===
Seven national standards bodies (those of the United States, China, Korea, the Netherlands, the United Kingdom, Denmark and Sweden) have nominated national subject-matter experts to work on the project, which is conducted by Working Group 3 (Database Languages) of ISO/IEC JTC 1's Subcommittee 32 (Data Management and Interchange), usually abbreviated as '''ISO/IEC JTC 1/SC 32 WG3''', or just '''WG3''' for short. WG3 (and its direct predecessor committees within JTC 1) has been responsible for the SQL standard since 1987.<ref name="SC32 and WG3 history">{{cite web|url=https://jtc1info.org/sd_2-history_of_jtc1/jtc1-subcommittees/sc-32/|title=JTC 1/SC 32 Data Management and Interchange|publisher=ISO/IEC JTC1|access-date=October 6, 2019}}</ref><ref name="1987 scope of SQL">{{cite web|url=https://isotc.iso.org/livelink/livelink?func=ll&objId=19733701&objAction=Open|title=''Scope from the original standard, ISO 9075-1987, Database Language SQL''|publisher=ISO/IEC JTC1|access-date=November 9, 2019}}</ref>
=== ISO stages ===
{{srn}}
{| class="wikitable static-row-numbers"
! date !! ISO stages<ref>{{cite web | url=https://www.iso.org/standard/76120.html | title=Iso/Iec 39075:2024 }}</ref>
|-
| 2019-09-10 || 10.99 New project approved
|-
| 2019-09-10 || 20.00 New project registered in TC/SC work programme
|-
| 2021-11-22 || 30.00 Committee draft (CD) registered
|-
| 2021-11-23 || 30.20 CD study initiated
|-
| 2022-02-25 || 30.60 Close of comment period
|-
| 2022-08-29 || 30.92 CD referred back to Working Group
|-
| 2022-08-29 || 30.00 Committee draft (CD) registered
|-
| 2022-08-30 || 30.20 CD study initiated
|-
| 2022-10-26 || 30.60 Close of comment period
|-
| 2023-03-22 || 30.99 CD approved for registration as [[Draft International Standard|DIS]]
|-
| 2023-03-24 || 40.00 DIS registered
|-
| 2023-05-24 || 40.20 DIS ballot initiated: 12 weeks
|-
| 2023-08-17 || 40.60 Close of voting
|-
| 2023-11-28 || 40.99 Full report circulated: DIS approved for registration as FDIS
|-
| 2023-12-11 || 50.00 Final text received or FDIS registered for formal approval
|-
| 2024-01-26 || 50.20 Proof sent to secretariat or FDIS ballot initiated: 8 weeks
|-
| 2024-03-23 || 50.60 Close of voting. Proof returned by secretariat
|-
| 2024-03-23 || 60.00 International Standard under publication
|-
| 2024-04-12 || 60.60 International Standard published
|}
== GQL property graph data model ==
GQL is a query language specifically for property graphs. A property graph closely resembles a [[conceptual data model]], as expressed in an [[entity–relationship model]] or in a [[Unified Modeling Language|UML]] [[class diagram]] (although it does not include n-ary relationships linking more than two entities). Entities are modelled as nodes, and relationships as edges, in a graph. Property graphs are ''multigraphs'': there can be many edges between the same pair of nodes. GQL graphs can be ''mixed'': they can contain directed edges, where one of the endpoint nodes of an edge is the tail (or source) and the other node is the head (or target or destination), but they can also contain undirected (bidirectional or reflexive) edges.
Nodes and edges, collectively known as elements, have attributes. Those attributes may be data values, or labels (tags). Values of properties cannot be elements of graphs, nor can they be whole graphs: these restrictions intentionally force a clean separation between the topology of a graph, and the attributes carrying data values in the context of a graph topology. The property graph data model therefore deliberately prevents nesting of graphs, or treating nodes in one graph as edges in another. Each property graph may have a set of labels and a set of properties that are associated with the graph as a whole.
Current graph database products and projects often support a limited version of the model described here. For example, Apache Tinkerpop<ref name="Tinkerpop">{{cite web|url=http://tinkerpop.apache.org/|title=Apache Tinkerpop|publisher=Apache Software Foundation|access-date=November 11, 2019}}</ref> forces each node and each edge to have a single label; Cypher allows nodes to have zero to many labels, but relationships only have a single label (called a reltype). Neo4j's database supports undocumented graph-wide properties, Tinkerpop has graph values which play the same role, and also supports "metaproperties" or properties on properties. Oracle's PGQL supports zero to many labels on nodes and on edges, whereas SQL/PGQ supports one to many labels for each kind of element. The [[NGSI-LD]] information model specified by [[ETSI]] is an attempt at formally specifying property graphs, with node and relationship (edge) types that may play the role of labels in previously mentioned models ''and'' support semantic referencing by inheriting classes defined in shared [[Ontology (information science)|ontologies]].
The GQL project will define a standard data model, which is likely to be the superset of these variants, and at least the first version of GQL is likely to permit vendors to decide on the cardinalities of labels in each implementation, as does SQL/PGQ, and to choose whether to support undirected relationships.
Additional aspects of the ERM or UML models (like generalization or subtyping, or entity or relationship cardinalities) may be captured by GQL schemas or types that describe possible instances of the general data model.
== Implementations ==
The first in-memory graph database that can interpret GQL is available.<ref name="GQL Parser">{{cite web|url=https://github.com/OlofMorra/GQL-parser|title=GQL Parser|last=|first=|date=|website=[[GitHub]]|publisher=|accessdate=January 18, 2021}}</ref><ref name="First GQL research implementation from Olof Morra at TU Eindhoven!">{{cite web|url=https://www.linkedin.com/pulse/first-gql-research-implementation-from-olof-morra-tu-eindhoven-green/?trackingId=B4cNxk7uqZEPZgsZh2%2FWHw%3D%3D|title=First GQL research implementation from Olof Morra at TU Eindhoven!|publisher=Alastair Green|accessdate=January 18, 2021}}</ref> Aside from the implementation, one can also find a formalization and read the syntax of the specific subset of GQL.<ref name="A Semantics of GQL; a New Query Language for Property Graphs Formalized">{{cite web|url=https://github.com/OlofMorra/GQL-parser/blob/main/src/main/resources/report/A%20Semantics%20of%20GQL;%20a%20New%20Query%20Language%20forProperty%20Graphs%20Formalized.pdf|title=A Semantics of GQL; a New Query Language for Property Graphs Formalized|last=|first=|date=|website=|publisher=Olof Morra|accessdate=January 18, 2021}}</ref>
==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
|last= |display-authors=etal|date=September 2017| |issue=5 |pages=68:1–40 |publisher=ACM| |arxiv=1610.06264 |s2cid=13526884 |access-date=November === SQL/PGQ Property Graph Query ===
Prior work by WG3 and SC32 mirror bodies, particularly in [[International Committee for Information Technology Standards|INCITS]] Data Management (formerly INCITS DM32), has helped to define a new planned Part 16 of the SQL Standard, which allows a read-only graph query to be called inside a SQL SELECT statement, matching a graph pattern using syntax which is very close to Cypher, PGQL and G-CORE, and returning a table of data values as the result. SQL/PGQ also contains DDL to allow SQL tables to be mapped to a graph view schema object with nodes and edges associated to sets of labels and set of data properties.<ref name="SQL Part 16 PGQ">{{cite web|title=ISO/IEC 9075-16 Information technology — Database languages SQL — Part 16: SQL Property Graph Queries (SQL/PGQ)|url=https://www.iso.org/standard/79473.html?browse=tc|access-date=January 7, 2022|publisher=ISO}}</ref><ref name="W3C Berlin SQL and GQL">{{cite web|url=https://www.w3.org/Data/events/data-ws-2019/assets/slides/KeithWHare-2.pdf|title=''SQL and GQL'', W3C Workshop on Web Standardization for Graph Data. Creating Bridges: RDF, Property Graph and SQL.|last=Hare|first=Keith|display-authors=etal|date=March 2019|publisher=W3C|access-date=October 6, 2019}}</ref><ref name="LDBC SQL/PGQ">{{cite web|url=https://ldbcouncil.org/event/twelfth-tuc-meeting/attachments/106233859/111706119.pdf|title=''Property graph extensions for the SQL standard''. LDBC 12th TUC.|last=Trigonakis|first=Vasileios|date=July 2019|publisher=LBDC|access-date=January 7, 2022}}</ref> The GQL project coordinates closely with the SQL/PGQ "project split" of (extension to) ISO 9075 SQL, and the technical working groups in the U.S. (INCITS DM32) and at the international level (SC32/WG3) have several expert contributors who work on both projects.<ref name="W3C Berlin SQL and GQL"/> The GQL project proposal mandates close alignment of SQL/PGQ and GQL, indicating that GQL will in general be a superset of SQL/PGQ.
More details about the pattern matching language can be found in the paper "Graph Pattern Matching in GQL and SQL/PGQ"<ref>{{cite arXiv|last1=Deutsch|first1=Alin|last2=Francis|first2=Nadime|last3=Green|first3=Alastair|last4=Hare|first4=Keith|last5=Li|first5=Bei|last6=Libkin|first6=Leonid|last7=Lindaaker|first7=Tobias|last8=Marsault|first8=Victor|last9=Martens|first9=Wim|last10=Michels|first10=Jan|last11=Murlak|first11=Filip|display-authors=10|date=2021-12-12|title=Graph Pattern Matching in GQL and SQL/PGQ|class=cs.DB|eprint=2112.06217}}</ref>
<ref>{{Cite book |last1=Deutsch |first1=Alin |last2=Francis |first2=Nadime |last3=Green |first3=Alastair |last4=Hare |first4=Keith |last5=Li |first5=Bei |last6=Libkin |first6=Leonid |last7=Lindaaker |first7=Tobias |last8=Marsault |first8=Victor |last9=Martens |first9=Wim |last10=Michels |first10=Jan |last11=Murlak |first11=Filip |last12=Plantikow |first12=Stefan |last13=Selmer |first13=Petra |last14=van Rest |first14=Oskar |last15=Voigt |first15=Hannes |title=Proceedings of the 2022 International Conference on Management of Data |chapter=Graph Pattern Matching in GQL and SQL/PGQ |date=2022-06-11 |chapter-url=https://doi.org/10.1145/3514221.3526057 |series=SIGMOD '22 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=2246–2258 |doi=10.1145/3514221.3526057 |isbn=978-1-4503-9249-5|s2cid=245124268 |url=https://www.research.ed.ac.uk/en/publications/f391e0a9-cb61-4e88-a553-2842d0a40258 }}</ref>
=== Cypher ===
Cypher<ref name="Cypher">{{cite book|url=https://dl.acm.org/citation.cfm?id=3190657|title= Proceedings of the 2018 International Conference on Management of Data|last=Francis|first=Nadime|chapter= Cypher: An Evolving Query Language for Property Graphs|date=27 May 2018|pages=1433–1445|display-authors=etal|publisher=ACM|doi=10.1145/3183713.3190657|isbn=9781450347037|s2cid=13919896|access-date=October 25, 2019}}</ref> is a language originally designed by Andrés Taylor and colleagues at Neo4j Inc., and first implemented by that company in 2011. Since 2015 it has been made available as an open source language description<ref name="Cypher 9">{{cite web|url=https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf|title=''Cypher Query Language Reference (Version 9)'' |display-authors=etal|publisher=opencypher.org|access-date=November 10, 2019}}</ref> with grammar tooling, a [[Java virtual machine|JVM]] front-end that parses Cypher queries, and a Technology Compatibility Kit (TCK) of over 2000 test scenarios, using [[Cucumber (software)|Cucumber]] for implementation language portability.<ref name="Cypher Resources">{{cite web|url=http://www.opencypher.org/resources|title=''openCypher Resources''|display-authors=etal|publisher=ACM|access-date=November 10, 2019}}</ref> The TCK reflects the language description and an enhancement for temporal datatypes and functions documented in a Cypher Improvement Proposal.<ref name="Date-Time CIP">{{cite web|url=https://github.com/thobe/openCypher/blob/date-time/cip/1.accepted/CIP2015-08-06-date-time.adoc|title=''CIP2015-08-06 - Date and Time''|date=15 May 2019|publisher=opencypher.org|access-date=October 25, 2019}}</ref>
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.
====Querying with visual path patterns====
Cypher uses compact fixed- and variable-length patterns which combine visual representations of node and relationship (edge) topologies, with label existence and property value predicates. (These patterns are usually referred to as "[[ASCII
For example, a pattern {{code|MATCH (p:Person)-[:LIVES_IN]->(c:City)}} will generate a two-column output table. The first column named {{code|p}} will contain references to nodes with a label {{code|Person}} . The second column named {{code|c}} will contain references to nodes with a label {{code|City}} , denoting the city where the person lives.
The binding variables {{code|p}} and {{code|c}} can then be dereferenced to obtain access to property values associated with the elements referred to by a variable. The example query might be terminated with a {{code|RETURN}}, resulting in a complete query like this:
<
RETURN p.first_name, p.last_name, c.name, c.state</
This would result in a final four-column table listing the names of the residents of the cities stored in the graph. Pattern-based queries are able to express joins, by combining multiple patterns which use the same binding variable to express a natural join using the {{code|MATCH}} clause:
<
RETURN p.first_name, p.last_name, c.name, c.state</
This query would return the residential ___location only of EU nationals.
An outer join can be expressed by {{code|MATCH ... OPTIONAL MATCH}} :
<
RETURN p.first_name, p.last_name, c.name, c.state, ec.name</
This query would return the city of residence of each person in the graph with residential information, and, if an EU national, which country they come from.
Queries are therefore able to first project a sub-graph of the graph input into the query, and then extract the data values associated with that subgraph. Data values can also be processed by functions, including aggregation functions, leading to the projection of computed values which render the information held in the projected graph in various ways. Following the lead of G-CORE and Morpheus, GQL aims to project the sub-graphs defined by matching patterns (and graphs then computed over those sub-graphs) as new graphs to be returned by a query.
Patterns of this kind have become pervasive in property graph query languages, and are the basis for the advanced pattern sub-language being defined in SQL/PGQ, which is likely to become a subset of the GQL language. Cypher also uses patterns for insertion and modification clauses ( {{code|CREATE}} and {{code|MERGE}} ), and proposals have been made in the GQL project for collecting node and edge patterns to describe graph types.
====Cypher 9 and Cypher 10====
The current version of Cypher (including the temporal extension) is referred to as Cypher 9. Prior to the GQL project it was planned to create a new version, Cypher 10 ['''REF HEADING BELOW'''], that would incorporate features like schema and composable graph queries and views. The first designs for Cypher 10, including graph construction and projection, were implemented in the Cypher for Apache Spark project starting in 2016.<ref name="CAPS Morpheus">{{cite web|url=https://github.com/opencypher/morpheus
=== PGQL ===
PGQL<ref name="PGQL Grades">{{cite
is a language designed and implemented by Oracle Inc., but made available as an open source specification,<ref name="PGQL spec">{{cite web|url=http://pgql-lang.org/|title=PGQL
=== G-CORE===
G-CORE is a research language designed by a group of academic and industrial researchers and language designers which draws on features of Cypher, PGQL and [[SPARQL]].<ref name="G-CORE">{{cite
=== GSQL ===
GSQL<ref name="GSQL white paper">{{cite web|url=https://info.tigergraph.com/gsql|title=''GSQL: An SQL-Inspired Graph Query Language''|
Vertexes and edges
GSQL also supports the concept of Multigraphs
<ref name="GSQL multigraphs">{{cite web|url=https://docs-legacy.tigergraph.com/tigergraph-platform-overview/multigraph-overview|title=''Multigraphs'', TigerGraph Online Documentation|date=June 2019|access-date=January 7, 2022}}</ref>
which allow subsets of a graph to have role-based access control. Multigraphs are important for enterprise-scale graphs that need fine-grain access control for different users.
=== Morpheus: multiple graphs and composable graph queries in Apache Spark ===
The opencypher Morpheus project<ref name="CAPS Morpheus"/> implements Cypher for Apache Spark users. Commencing in 2016, this project originally ran alongside three related efforts, in which Morpheus designers also took part: SQL/PGQ, G-CORE and design of Cypher extensions for querying and constructing multiple graphs.<ref name="MGCQ CIP">{{cite web|url=https://github.com/boggle/openCypher/blob/CIP2017-06-18-multiple-graphs/cip/1.accepted/CIP2017-06-18-multiple-graphs.adoc|title=''CIP2017-06-18 Querying and constructing multiple graphs''|last1=Taylor|first1=Andrés|last2=Plantikow|first2=Stefan|last3=Selmer|first3=Petra|date=2017–2018|publisher=opencypher.org|access-date=November 12, 2019}}</ref> The Morpheus project acted as a testbed for extensions to Cypher (known as "Cypher 10") in the two areas of graph DDL and query language extensions.
Graph DDL features include<ref name="CAPS oCIM V">{{cite web|url=https://s3.amazonaws.com/artifacts.opencypher.org/website/ocim5/slides/ocim5+-+CAPS+%2B+GraphDDL.pdf|title=''Multiple graphs and composable queries in Cypher for Apache Spark''. openCypher Implementers Meeting V, Berlin.|last=Kiessling|first=Max|date=2019|publisher=opencypher.org|access-date=November 9, 2019}}</ref>
#definition of property graph views over [[Java Database Connectivity|JDBC]]-connected SQL tables and Spark DataFrames<ref name="EXTENDS element type">{{cite web|url=https://github.com/tobias-johansson/graphddl-example-ldbc/|title=''graphddl-example-ldbc: A cypher-for-apache-spark example showing the use of SqlPropertyGraphSource and GraphDDL to provide a property graph view of a SQL dataset''.|last=Johanssen|first=Tobias|website=[[GitHub]]|display-authors=etal|date=2019|access-date=November 9, 2019}}</ref>
#definition of graph schemas or types defined by assembling node type and edge type patterns, with subtyping<ref name="EXTENDS element type"/>
#constraining the content of a graph by a closed or fixed schema
#creating catalog entries for multiple named graphs in a hierarchically
#graph data sources to form a federated, heterogeneous catalog
#creating catalog entries for named queries (views)
Line 100 ⟶ 187:
#projection of graphs computed from the results of pattern matches on multiple input graphs
#support for tables (Spark DataFrames) as inputs to queries ("driving tables")
#views which accept named or projected graphs as parameters.
These features have been proposed as inputs to the standardization of property graph query languages in the GQL project.
== See also ==
* [[Graph Modeling Language]] (GML)
* [[GraphQL]]
* [[Cypher (query language)]]
*[[Graph database]]
*[[Graph (abstract data type)]]
*[[Graph traversal]]
* [[Regular path query]]
== References ==
<!-- Inline citations added to your article will automatically display here. See en.wikipedia.org/wiki/WP:REFB for instructions on how to add citations. -->
{{reflist}}
== External links ==
* [https://www.gqlstandards.org GQL Standard] (Official website)
{{ISO standards}}
{{List of IEC standards}}
[[Category:Computer languages]]
[[Category:Query languages]]
[[Category:ISO/IEC standards]]
| |||