Federated Graph Query

The query planner parses a single SPARQL or Cypher query and splits it into sub-queries routed to specific data sources. The engine analyzes ontology mappings and schema registries to determine which triplestore or property graph holds each fragment of the answer.

• Uses cost-based optimization to minimize cross-source joins
• Handles heterogeneous graph models (RDF at Site A, LPG at Site B)
• Pushes filters to sources to reduce data transfer

Example: A query for 'all pumps with bearing failures in the last 90 days' may pull asset hierarchies from an ISA-95 ontology in Germany and maintenance logs from a labeled property graph in Mexico.

When a query spans databases that cannot be physically joined, the federation layer executes bind joins or hash joins in memory. It retrieves partial result sets from each source and correlates them using shared identifiers like equipment serial numbers or batch IDs.

• Implements adaptive join strategies based on cardinality estimates
• Uses entity resolution to match records when identifiers differ across sites
• Minimizes data movement by shipping join keys, not full records

This enables queries like correlating supplier material lots with in-field failure rates without ever exposing proprietary supplier data to the manufacturer.

Different factories often use incompatible ontologies and taxonomies. The mediation layer translates queries and results between vocabularies using declarative SHACL shapes and OWL equivalence mappings.

• Maps 'pumpFailure' in one ontology to 'rotatingEquipmentAnomaly' in another
• Applies unit conversion (psi to bar, Fahrenheit to Celsius) transparently
• Validates results against data quality constraints before aggregation

Without this layer, a query written against the corporate ISA-95 model would fail against a site using a custom AutomationML schema.

The federation coordinator collects sub-query responses, merges them into a unified result set, and applies any remaining filters, aggregations, or sort operations that could not be pushed to individual sources.

• Handles streaming results for large datasets without materializing entire result sets
• Deduplicates records using entity resolution when the same asset appears in multiple sources
• Preserves provenance metadata so users can trace each fact to its source database

Example: Aggregating mean-time-between-failure calculations across five plants requires merging partial statistics, not raw maintenance records.

Each participating graph database enforces its own row-level security and access control policies. The federation layer authenticates to each source with scoped credentials and never bypasses local governance.

• Integrates with OAuth2 and mutual TLS for source authentication
• Respects data residency requirements by querying data in-place
• Audits every cross-source access for compliance reporting

This architecture satisfies sovereign AI infrastructure mandates where raw production data must remain within national borders while still enabling global analytics.

Federated queries can target specific temporal knowledge graph snapshots, enabling historical analysis across distributed sources. The coordinator aligns timestamps from different time zones and handles schema versioning across independently evolving databases.

• Queries can specify 'as of' timestamps for point-in-time analysis
• Handles schema drift when one site upgrades its ontology before others
• Supports bitemporal queries tracking both valid time and transaction time

This is critical for root cause analysis where engineers need to reconstruct the exact state of a multi-site production line at the moment a quality deviation occurred.