# Demographic model improvements

**URL:** <https://discourse.openehr.org/t/demographic-model-improvements/1645>\
**Category:** Entity/demographics\
**Created:** [17 June 2021 18:17 UTC](https://discourse.openehr.org/t/demographic-model-improvements/1645 "2021-06-17T18:17:36Z")\
**Posts on this page:** 1\
**Showing post:** 48

<div class="post-metadata">

**Author:** ![erik.sundvall](https://discourse.openehr.org/user_avatar/discourse.openehr.org/erik.sundvall/32/1961_2.png) [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)\
**Post date:** [19 March 2025 20:32 UTC](https://discourse.openehr.org/t/demographic-model-improvements/1645/48 "2025-03-19T20:32:28Z")

</div>

> [@thomas.beale](#):
>
> using GraphQL at Graphite. It definitely has limitations. For one thing, you can’t write a GraphQL query that has a WHERE clause equivalent containing anything other than the AND logical operator.

@thomas.beale, has Graphite investigetad if GQL (or Neo4J’s related [Cypher](https://neo4j.com/product/cypher-graph-query-language/)) has the same limitations? It seems to be partly another kind of tool/language. See GQL links in e.g. [EHRs with different system\_id in the same server? - #37 by erik.sundvall](https://discourse.openehr.org/t/ehrs-with-different-system-id-in-the-same-server/3535/37)

(Adding syntactic sugar shortcuts to GQL like AQL did to Xpaths would create what I tentatively would call AGQL 🙂 _- see Update March 31 below_)

_[ **Update March 20:** I found these two sources informative and full of context regarding GQL, Cypher and the standardisation process_  
_[GQL: The ISO standard for graphs has arrived | AWS Database Blog](https://aws.amazon.com/blogs/database/gql-the-iso-standard-for-graphs-has-arrived/)  
…and…  
 [Introduction to Graph Query Languages. From SPARQL to Gremlin.](https://graph.build/resources/graph-query-languages)]_

_[ **Update March 31:** Adding text for context from a previous not openly available post:  
GQL ([Graph Query Language - Wikipedia](https://en.wikipedia.org/wiki/Graph_Query_Language)) seems to finally have been made a standard now. If it is/becomes well supported by graph databases, then I was thinkning that perhaps some Archetype-based syntactic sugar on top of GQL (could be called AGQL) and simple preporocessing/translation of the query might do the trick without us having to reeinvent any new wheel or stretch AQL’s tree-focused view too far. With syntactic sugar I mean simplifications like AQL paths have done to xPath in the form of `.../attributename[at0123]/...`]_

Sorry for going off topic.

---

_[View the full topic](https://discourse.openehr.org/t/demographic-model-improvements/1645)._