Content deleted Content added
Fix binding variable, Gremlin ref |
Fix binding variable, Gremlin ref, PGDM |
||
Line 7:
The GQL project is led by Stefan Plantikow (who was the first lead engineer of Neo4j's Cypher for Apache Spark project) and Stephen Cannan (Technical Corrigenda editor of SQL). They are also the editors of the initial early working drafts<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''.|last=Eds. Plantikow|first=Stefan|last2=Cannan|first2=Stephen|date=November 2019|website=|publisher=ISO|accessdate=November 9, 2019}}</ref> of the GQL specification.
==The property graph data model==
A property graph closely resembles a conceptual data model expressed in an Entity Relationship model or in a UML class diagram. Entities or concepts are modelled as nodes, and relationships as edges, in a graph. 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. 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 edition of the model described here. For example, Apache Tinkerpop<ref naem="Tinkerpop"> 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. 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.
The property graph data model therefore deliberately prevents nesting of graphs, or treating nodes in one graph as edges in another. Additional aspects of the ERM or UML models (like generalization or subtyping, or entity or relationship cardinalities) may be captured by schemas or types that describe possible instances of the general data model.
==Managed alongside SQL by JTC 1/SC32 Working Group 3 (WG3) ==
| |||