Graph Query Language: Difference between revisions

Revision as of 16:57, 13 December 2023

Revision as of 08:14, 5 January 2024

Line 30:

# 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 CommitteCommittee draft (CD) registered

# 2022-10-26 : 30.60 Close of comment period

# 2023-03-22 : 30.99 CD approved for registration as DIS

Line 45:

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.

Line 53:

== Implementations ==

Although the GQL Standard is not yet publicly available, 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|publisher=opencypher.org|access-date=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|publisher=opencypher.org|access-date=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 book|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|publisher=ACM|doi=10.1145/2815072|isbn=9781450339025|s2cid=32623848|access-date=November 10, 2019}}</ref>), and GSQL,<ref name="GSQL white paper"/> making it possible to traverse a graph iteratively to perform a class of graph algorithms, but GQL will not directly incorporate such features.<ref name="Wood Graph Query">{{cite journal|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.|journal=ACM SIGMOD Record|date=25 April 2012|volume=41|issue=1|pages=50–60|publisher=ACM|doi=10.1145/2206869.2206879|s2cid=13537601|access-date=October 25, 2019}}</ref><ref name="GQL foundations">{{cite journal|url=https://dl.acm.org/citation.cfm?id=3104031|title=''Foundations of Modern Query Languages for Graph Databases'', ACM Comput. Surv. 50, 5, DOI: 10.1145/3104031

Line 62 ⟶ 63:

|arxiv=1610.06264

|s2cid=13526884

|access-date=November 12, 2019}}</ref> 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 ===

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.

Line 129 ⟶ 130:

#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- organized catalog

#graph data sources to form a federated, heterogeneous catalog

#creating catalog entries for named queries (views)