Graph Query Language: Difference between revisions

Revision as of 14:07, 13 November 2019

Revision as of 13:29, 22 November 2019

Line 20:

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 editionversion of the model described here. For example, Apache Tinkerpop<ref name="Tinkerpop">{{cite web|url=http://tinkerpop.apache.org/|title=Apache Tinkerpop|last=|first=|date=|website=|publisher=Apache Software Foundation|accessdate=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 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.