Webinar: GraphQL Federation and Knowledge Graphs

GraphQL Federation is positioned as a practical way to turn a set of separate knowledge-graph services into one unified, queryable graph—without forcing clients to know where each piece of data lives. The core idea is to expose each backend (RDF graph database, annotation store, semantic similarity index, and more) through GraphQL, then use federation to stitch them together into a single schema and a single query language. The result is a “single view” over multiple services, where a client can ask for nested, cross-domain data in one request and receive a consistent response shape.

The session grounds that concept in Ontotext’s stack for knowledge graphs. It describes an RDF layer in GraphDB, plus supporting components such as MongoDB for storing text-analytics outputs (notably Web Annotation JSON-LD) and a semantic vector space index for similarity search. A semantic object service sits on top of RDF and other stores, abstracting RDF “in various flavors” behind GraphQL. From a lightweight object model (expressed in a YAML-like representation), the platform can generate GraphQL schemas, resolvers, and the query/mutation surface automatically—then transpile GraphQL queries into high-performance backend queries.

A key portion of the briefing focuses on GraphQL itself as used for knowledge graphs. GraphQL is treated as an API-level query language with strong typing: schemas define object types, properties, arguments for filtering (including complex boolean logic and regex-style matching), pagination, ordering, and mutation operations. The schema also supports interfaces, unions, variables, aliases, fragments, and inline fragments—features that matter when modeling RDF hierarchies such as Star Wars entities (films, characters, species, planets, people). Introspection is highlighted as a way to drive developer tooling: the schema can be queried so IDEs can offer autocomplete and validate query shapes before execution.

Federation then becomes the mechanism for joining isolated graph services. The knowledge graph is split into bounded contexts: one context handles text analytics and stores entity annotations in MongoDB as Web Annotation JSON-LD; another context hosts the Star Wars universe in GraphDB; a third context provides character similarity using a semantic vector space. Federation keys (for example, using a shared identifier like a character URI) define join points across contexts. Extension types let one service “add” fields from another service onto the same conceptual object, so requesting a character can automatically pull in properties from the Star Wars universe, while also attaching similarity-derived relationships.

A concrete example shows how an annotation query can be extended through federation: start with annotations that reference a character URI, then delegate to the similarity service to find similar characters, and finally extend those characters with RDF-backed details such as homeworld, film appearances, and roles. The client-facing query remains simple; the federation engine coordinates schema aggregation, query planning, delegation to each backend, and joining results. The session also notes that federation can handle more than joins—calculations can be federated too, where a field computed in one service depends on data retrieved from another.

Overall, the takeaway is an architecture pattern: model shared entities with stable keys, expose each bounded context through GraphQL, and let federation produce a single aggregated schema and query execution path. That approach supports independent development of services while still enabling one coherent knowledge-graph experience for application developers.