#Three Query Languages

Choosing a graph database usually means choosing a query language. Pick a triplestore and you get SPARQL. Pick a property graph database and you get Cypher. If both teams exist in your organization, you end up running two databases, two stacks, and two migration paths.

WWKG runs all three — SPARQL, Cypher, and GQL — against the same data, in the same engine, with a single optimizer.

#What you could not do before

In every other graph database:

• The query language is fixed. You choose the product, you get its language. Switching later means migrating everything.
• Result formats are tied to the language. SPARQL returns bindings. Cypher returns graph values. You cannot cross the streams.
• Existing client libraries work only with the language they were built for. A Neo4j driver cannot talk to a triplestore.
• Different teams with different language preferences need different products — doubling infrastructure, maintenance, and training.

Organizations work around this by standardizing on one language and forcing everyone to adopt it, or by accepting the cost of running parallel platforms. Neither is a good outcome.

#What WWKG enables

SPARQL, Cypher, and GQL as equal peers. Each language is a first-class citizen, not an afterthought or a compatibility shim. SPARQL follows the W3C 1.2 specification. Cypher follows the openCypher standard. GQL follows the ISO standard. Existing queries, clients, and tools work without modification.

Any language, any format. The query language and the result format are independent choices. Send a Cypher query and request SPARQL Results JSON — you get W3C-standard bindings. Send a SPARQL query and request Cypher-style graph values — nodes with labels and properties come back in the shape a Neo4j driver expects. Send any query and request CSV — you get a flat export.

This means existing client libraries from one ecosystem can query WWKG using a different language and still get results in the format they understand.

Version control from any language. WWKG’s branching, history, and diff capabilities are accessible from all three languages. For SPARQL, branch selection and temporal queries can be expressed directly in the query syntax. For Cypher and GQL, the same capabilities are available through HTTP headers and URL parameters — no query changes required. An existing Cypher application gains version control by adding a single HTTP header.

10+ result formats. SPARQL Results JSON, SPARQL Results XML, Turtle, TriG, N-Triples, N-Quads, JSON-LD, CSV, TSV, Cypher JSON, GQL JSON — all available regardless of which language you used to query.

#A concrete scenario

A bank’s data governance team uses SPARQL for standards-based regulatory reporting. The application development team uses Cypher for building customer-facing features. The data science team wants CSV exports for their notebooks.

In most organizations, that is three separate graph databases. In WWKG, it is one graph, three interfaces, and any result format each team prefers. The governance team queries in SPARQL and gets W3C bindings. The dev team queries in Cypher and gets graph values. The data scientists query in either and get CSV. All three hit the same data.

#What makes this different

For over a decade, the graph world has been divided: RDF triplestores for the standards and semantic technology community, property graph databases for application developers. Each side has strengths the other lacks — RDF has formal reasoning and global interoperability; property graphs have intuitive modeling and fast traversal. Every product forced you to choose one and live with what the other side had that you could not use.

Others have announced visions for unifying these two worlds. In practice, they translate one model into the other — losing features in one direction — or run two separate engines behind a shared API.

WWKG does neither. All three languages compile to one shared representation, processed by a single optimizer and executor. There is no translation layer, no dual engine, and no second-class language.

The real payoff is that the strengths of each paradigm flow to the other. Cypher and GQL users gain standards-based inference automatically — query for Persons and Doctors are included, because the ontology says so, without writing SPARQL or learning a rule language. SPARQL users gain the traversal patterns property graph users expect. Every language shares branching, encryption, version control, and vector search. To our knowledge, WWKG is the first graph database to make formal inference available natively through property graph query languages.

The independence of query language and result format reinforces this. In every other graph database, the format is a fixed consequence of the language. WWKG treats them as two orthogonal choices — because they are.

#Next steps

Continue with the Querying guide for hands-on examples. Related features: Reasoning and Validation, Branching and Merge Workflows, and Vector Search for Graph Workloads.