Wait, so you built a system that can do database querries in plain language? Can it, in principal, work in SQL as well as it does is Cypher? It's an incredible public service as is, but seems like it has pretty broad enterprise applications if I'm understanding correctly.
Thanks, and yes, you're understanding it correctly. The natural language interface translates queries into Cypher against a Neo4j graph database, but the underlying principle isn't locked to any one query language. An LLM can generate SQL just as fluently; the magic is really in how well you've modelled the data underneath.
The reason we went with a graph is that parliamentary data is inherently relational. MPs sit on committees, vote on bills, reference each other in debate, belong to parties that shift positions over time. A graph captures all of that natively, and critically, it gives you traversal which is the ability to walk across those relationships in real time.
“Show me every MP who sat on the Finance committee and voted against their own party’s bill” is a traversal problem. In SQL that’s a pile of joins. In a graph, you’re just following edges.
You’re right that the pattern has broad enterprise applications and any domain with complex, interconnected data would benefit from this approach. That’s not lost on us. But the civic use case came first, and honestly it’s the one that keeps the lights on at 2am(4am?).
Making parliamentary data legible to the public felt like the right place to start.
Wow, well done. And thank you for making it a public service first. Hopefully, it takes as enterprise software in the future. I know I'm looking forward to not spending 5 - 10 hours a week trying to write querries and sort csv tables to find an answer that I know is 'somewhere' in a database.
Wait, so you built a system that can do database querries in plain language? Can it, in principal, work in SQL as well as it does is Cypher? It's an incredible public service as is, but seems like it has pretty broad enterprise applications if I'm understanding correctly.
Thanks, and yes, you're understanding it correctly. The natural language interface translates queries into Cypher against a Neo4j graph database, but the underlying principle isn't locked to any one query language. An LLM can generate SQL just as fluently; the magic is really in how well you've modelled the data underneath.
The reason we went with a graph is that parliamentary data is inherently relational. MPs sit on committees, vote on bills, reference each other in debate, belong to parties that shift positions over time. A graph captures all of that natively, and critically, it gives you traversal which is the ability to walk across those relationships in real time.
“Show me every MP who sat on the Finance committee and voted against their own party’s bill” is a traversal problem. In SQL that’s a pile of joins. In a graph, you’re just following edges.
You’re right that the pattern has broad enterprise applications and any domain with complex, interconnected data would benefit from this approach. That’s not lost on us. But the civic use case came first, and honestly it’s the one that keeps the lights on at 2am(4am?).
Making parliamentary data legible to the public felt like the right place to start.
That’s an interesting way to eliminate the problems inherent in the current LLM systems.
Wow, well done. And thank you for making it a public service first. Hopefully, it takes as enterprise software in the future. I know I'm looking forward to not spending 5 - 10 hours a week trying to write querries and sort csv tables to find an answer that I know is 'somewhere' in a database.
That Prime Minister mix-up example hits close. I asked a standard AI about the current Speaker and got the wrong name with zero doubt.
Gordie skips that by querying the real data graph instead. Smart move for accountability.
The feds took a similar tack. Their AI register now publishes details on every government system to build trust.
Details at https://open.canada.ca/data/en/dataset/fcbc0200-79ba-4fa4-94a6-00e32facea6b