Skip to content

Instantly share code, notes, and snippets.

@kenwebb
Last active December 30, 2019 16:08
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kenwebb/989e54b928fe16513562a44970df4e54 to your computer and use it in GitHub Desktop.
Save kenwebb/989e54b928fe16513562a44970df4e54 to your computer and use it in GitHub Desktop.
Graph Query Language
<?xml version="1.0" encoding="UTF-8"?>
<!--Xholon Workbook http://www.primordion.com/Xholon/gwt/ MIT License, Copyright (C) Ken Webb, Mon Dec 30 2019 11:08:01 GMT-0500 (Eastern Standard Time)-->
<XholonWorkbook>
<Notes><![CDATA[
Xholon
------
Title: Graph Query Language
Description:
Url: http://www.primordion.com/Xholon/gwt/
InternalName: 989e54b928fe16513562a44970df4e54
Keywords:
My Notes
--------
December 30, 2019
This is a workbook about Graph Query Language (GQL), openCypher, and related stuff.
References
----------
() gql.today
() https://www.gqlstandards.org/home
() https://www.opencypher.org/
() https://s3.amazonaws.com/artifacts.opencypher.org/openCypher9.pdf
() https://www.opencypher.org/event/2019/03/06/ocim5/
() https://github.com/opencypher/openCypher
() https://www.slideshare.net/szarnyasg/compiling-opencypher-graph-queries-with-spark-catalyst
() http://graphdatamodeling.com/Index.htm
Graph Data Modeling - Visualize Structure and Meaning
a book by Thomas Frisendal
and other stuff
Prof. Peter Gärdenfors (Cognitive Science, conceptual spaces and cognitive semantics)
() https://en.wikipedia.org/wiki/Conceptual_space
() https://en.wikipedia.org/wiki/Peter_G%C3%A4rdenfors
() https://www.dataversity.net/knowledge-graphs-and-data-modeling/
Knowledge Graphs and Data Modeling, By Thomas Frisendal on November 4, 2019
() https://graphorum2019.dataversity.net/
Graph technology has been steadily growing over the years, but recently hit a critical mass.
Knowledge graphs, graph analytics, graph databases, graphs and AI are bringing new innovation and new practical applications to the marketplace.
This vendor-neutral, educational platform is the perfect venue if you want to understand what these new technologies can do for your organization.
() https://training.dataversity.net/courses/mdg1-overview-of-graphs-from-a-data-modeling-perspective
MDG1: Overview of Graphs from a Data Modeling Perspective
outline includes:
“Everything Looks Like a Graph”
Cognition And Perception
Conceptual Spaces
Spatial Cognition
Spatial Thinking is the Foundation of Abstract Thought
() https://www.dataversity.net/design-thinking-data-models/
() https://asistdl.onlinelibrary.wiley.com/doi/full/10.1002/bult.2010.1720360610
Constructions from dots and lines, Marko A. Rodriguez and Peter Neubauer, First published: 01 September 2010
() https://hackolade.com/
Agile visual data modeling, for NoSQL databases, REST APIs, and data formats
() https://s3.amazonaws.com/artifacts.opencypher.org/website/ocim5/slides/ocim5-GQL-Scope-and-Features-Digest.pdf
GQL Scope and Features, 2019
slide 6 - Example query
slide 7 - GQL Design Principles [3.9]
①New and independent property graph query language
Follow the tradition of existing languages like Cypher, PGQL and SQL/PGQSupport both standalone implementation or extension of existing SQL-based systems
②Declarative language
Emphasize what over how (in particular by using pattern matching)
③Composable language
Compose procedures from nested sub-procedures and statement sequences
④Compatible language
Ensure compatibility with established and widely used features of SQL and avoid idle variation to existing syntax
⑤Modern language
Introduce next-generation language features using established designs from existing languages where available
⑥Intuitive language
Follow consistent, "whiteboard-friendly", visual syntax (in particular by using "ascii-art" patterns)
slide 8
The GQL language is a composable declarative database language for querying and managing property graphs that is intended to be useable both as an independent language as well as in conjunction with SQL or other languages.
①Composable and closed under graphs and tables
②Declarative (i.e. independently implementable using different strategies)
③Covering the full spectrum of features of an industry-grade database query language
slide 17 - Why tabular operations in GQL?
slide 25 - Graph projection
() https://www.opencypher.org/articles/2019/09/12/SQL-and-now-GQL/
) https://www.opencypher.org/public/images/gql-schema.png
- includes a Math CT-like diagram based on:
CREATE GRAPH SocialNetwork {
(Person {name STRING, dob DATE}),
(City {name STRING}),
(Person)-[LivesIn]->(City),
(Person)-[Knows]->(Person)
}
() https://arxiv.org/pdf/1712.01550.pdf
G-CORE A Core for Future Graph ƒQuery Languages
We report on a community effort between industry and academia to shape the future of graph query languages.
We argue that existing graph database management systems should consider supporting a query language with two key characteristics.
First, it should be composable, meaning, that graphs are the input and the output of queries.
Second, the graph query language should treat paths as€ first-class citizens.
Our result is G-CORE, a powerful graph query language design that ful€lls these goals, and strikes a careful balancebetween path query expressivity and evaluation complexity
PREAMBLE G-CORE is a design by the LDBC Graph Qu‹ery Language Task Force, consisting of members from industry and academia,intending to bring the best of both worlds to graph practitioners.
1 INTRODUCTION
Graphs are the ultimate abstraction for many real world processes and today the computer infrastructure exists to collect, store and handle them as such.
There are several models for representing graphs.
Among the most popular is the property graph data model, which is a directed graph with labels on both nodes and edges, as well as〈property,value〉pairs associated with both.
1.1 Three Main Challenges
Composability.
ThŒe ability to plug and play is an essential step in standardization. Having the ability to plug outputs and inputs in a query language incentivizes its adoption (modularity, interoperability); simplify abstractions, users do not have to think about multiple data models during the query process; and increases its productivity, by facilitating reuse and decomposition of queries. Current query languages do not provide full composability because they output tables of values, nodes or edges.
Path as €rst-class citizens.
ThŒe notion of Path is fundamental for graph databases, because it introduces an intermediate abstraction level that allows to represents how elements in a graph are related. ThŒe facilities provided by a graph query language to manipulate paths (i.e. describe, search, €filter, count, annotate, return, etc.) increase the expressivity of the language. Particularly, the ability to return paths enables the user to post-process paths within the query languagerather that in an ad-hoc manner.
Capture the core of available languages.
Both the desirability of a standard query language and the dificulty of achieving this, is well-established. ThŒis is particularly true for graph data languages due to the diversity of models and the rich properties of the graph model. ThŒis motivates our approach to take the successful functionalities of current languages as a base from where to develop the next generation of languages.
7 CONCLUSIONS
We defend here two principles we think should be at the foundations of the future graph query languages:
composability, that is, having graphs and their mental model as departure and ending point and
treat the most popular featureof graphs, namely paths, as €first class citizens.
KSW paths could include Xholon bplex
]]></Notes>
<_-.XholonClass>
<!-- domain objects -->
<PhysicalSystem/>
<Block/>
<Brick/>
<!-- quantities -->
<Height superClass="Quantity"/>
</_-.XholonClass>
<xholonClassDetails>
<Block>
<port name="height" connector="Height"/>
</Block>
</xholonClassDetails>
<PhysicalSystem>
<Block>
<Height>0.1 m</Height>
</Block>
<Brick multiplicity="2"/>
</PhysicalSystem>
<Blockbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
var a = 123;
var b = 456;
var c = a * b;
if (console) {
console.log(c);
}
//# sourceURL=Blockbehavior.js
]]></Blockbehavior>
<Heightbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
var myHeight, testing;
var beh = {
postConfigure: function() {
testing = Math.floor(Math.random() * 10);
myHeight = this.cnode.parent();
},
act: function() {
myHeight.println(this.toString());
},
toString: function() {
return "testing:" + testing;
}
}
//# sourceURL=Heightbehavior.js
]]></Heightbehavior>
<Brickbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
$wnd.xh.Brickbehavior = function Brickbehavior() {}
$wnd.xh.Brickbehavior.prototype.postConfigure = function() {
this.brick = this.cnode.parent();
this.iam = " red brick";
};
$wnd.xh.Brickbehavior.prototype.act = function() {
this.brick.println("I am a" + this.iam);
};
//# sourceURL=Brickbehavior.js
]]></Brickbehavior>
<Brickbehavior implName="org.primordion.xholon.base.Behavior_gwtjs"><![CDATA[
console.log("I'm another brick behavior");
]]></Brickbehavior>
<SvgClient><Attribute_String roleName="svgUri"><![CDATA[data:image/svg+xml,
<svg width="100" height="50" xmlns="http://www.w3.org/2000/svg">
<g>
<title>Block</title>
<rect id="PhysicalSystem/Block" fill="#98FB98" height="50" width="50" x="25" y="0"/>
<g>
<title>Height</title>
<rect id="PhysicalSystem/Block/Height" fill="#6AB06A" height="50" width="10" x="80" y="0"/>
</g>
</g>
</svg>
]]></Attribute_String><Attribute_String roleName="setup">${MODELNAME_DEFAULT},${SVGURI_DEFAULT}</Attribute_String></SvgClient>
</XholonWorkbook>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment