Graph Personality

Description

Two graph traditions have spent twenty years disagreeing. At the level of the algebra they were describing the same object the whole time.

The dispute, and why it dissolves

Property-graph systems give you nodes with labels and property bags, edges with their own identity and type, and a pattern-matching language: (a:Person)-[:WORKS_AT]->(b:Company). RDF systems give you subjects, predicates and objects, URIs as identity, ontologies for schema, and a triple-pattern language: ?p :worksAt ?c.

The two camps have argued about this for a long time, and choosing between them has real consequences — for tooling, for interoperability, for who you can hire. But look at what each is actually storing. A property-graph edge is a triple of source, type and target, with side structures for properties. An RDF statement is a triple of subject, predicate and object. They are the same shape. Composition, transposition, reachability, restriction and projection behave identically over both.

What genuinely differs is vocabulary, identity model, schema discipline and query surface. Those are surfaces. So the Graph personality provides both of them, over one substrate.

Two languages, one engine

JCQL is the property-graph surface: pattern matching, variable-length paths, WHERE, RETURN — the idiom a Cypher user already has in their fingers.

JSPARQL is the RDF surface: triple patterns, OPTIONAL, UNION, FILTER, and the SELECT/CONSTRUCT/ASK/DESCRIBE forms.

Both compile to identical algebraic plans against the same clans — a nodes clan, an edges clan, property clans and a type clan, with an RDF-star triple view derivable on demand. You can write one query in JCQL and the next in JSPARQL against the same data in the same session. Nobody has to convert, nobody has to choose at database-creation time, and a team that contains both kinds of thinker does not have to settle the argument before it can start work.

Positions taken, and stated plainly

A merger of two models has to decide things. These are the decisions:

• Edges always have first-class identity — as they do in property graphs — and that identity is surfaced through RDF-star on the SPARQL side rather than through reification.

• Property bags are the canonical store, with the triple view materialised when asked for. This is the cheaper direction to travel.

• Schemaless by default, with an optional schema layer over it. You are not required to build an ontology before you can record a fact.

• Both identity models are supported. Nodes have opaque internal identifiers; URIs are an optional naming layer over them, so linked-data work is available without the engine being RDF-only.

• Inference is deliberately limited at this version: transitive subClassOf and subPropertyOf. Real, useful, and honestly bounded.

What the algebra actually gives you

Graph databases build dedicated traversal engines because their storage model does not natively express reachability. In the Algebra of Data it falls out:

Compose the edge relation with itself and you have two-hop reachability — friends of friends, without a traversal API. Compose repeatedly for transitive closure. Transpose the relation and every traversal runs backwards: who reports to whom becomes who is reported to by whom, in one operation, with no reverse index to maintain. Restrict by another relation to confine a traversal to a subgraph. Project to pull the columns you want out of the result.

And the result is an ordinary clan. Not a path object or a graph cursor — a clan, which joins directly against the relational tables, documents, time series and cubes held in the same database. Graph results stop being a separate world you have to marshal out of.

What this is not

Being direct about the boundaries, because a graph buyer will find them anyway.

JCQL and JSPARQL are derivatives — idioms sufficient for real work, not certified implementations of Cypher or SPARQL. Standards compliance is a later goal, not a present claim. There are no federated SPARQL endpoints in this version. There is no full OWL-DL reasoning, only the RDFS subset named above. And there is no distributed graph processing: this is a single-machine database, so cluster-scale graph algorithms are not on offer.

If you need a certified SPARQL endpoint serving a public linked-data estate, that is a different product. If you need to model, query and think in graph terms on your own machine — alongside all your other data — this is built for that.

Native, and yours

Part of a native macOS application in Swift. No graph server, no JVM, no cluster to size. The graph lives in a .jdb package on your own disk, next to everything else you keep there.