On this submit we present the way to construct a semantic layer on AWS utilizing Stardog’s Semantic AI Software over Amazon Aurora and Amazon Redshift, and the way to run a Strands Brokers agent on Amazon Bedrock AgentCore that queries the layer to reply buyer 360 questions throughout each sources with out extract, remodel, and cargo (ETL). The identical Stardog deployment works behind AWS computes (Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), and AWS Lambda). We use AgentCore right here as a result of it bundles inbound auth, internet hosting, and power credentials into one managed service.
Enterprise analytics has been chasing the identical objective for twenty years: shrink the time between a enterprise query and a reliable reply. Scheduled experiences gave strategy to dashboards, then dashboards gave strategy to self-service enterprise intelligence (BI). Even self-service trusted a knowledge engineer having already constructed the precise mannequin for the precise query, and the human analyst remained the bottleneck for every thing outdoors the ready dataset. Generative AI brokers are the subsequent step. As an alternative of visualizing knowledge, they purpose over it. They plan, write queries, consider outcomes, refine, and iterate towards the corporate’s reside knowledge on demand. Agentic analytics is the time period for this shift: an autonomous agent at each enterprise person’s elbow, doing the analyst’s work with out ready within the request queue.
The onerous half is not the muse mannequin (FM). Basis fashions obtainable on Amazon Bedrock can already plan multi-step workflows, purpose about schemas, and produce SQL properly sufficient to behave as a junior analyst would. The onerous half sits beneath: the info the mannequin causes over. Enterprise knowledge is scattered throughout techniques that outline the identical issues in a different way. The “buyer” in your buyer relationship administration (CRM) system is just not the identical file because the “buyer” in your billing system. “Income” calculated by the North American crew isn’t the identical quantity the European crew would produce. An AI agent given direct entry to this fragmented knowledge will write technically legitimate queries that return improper, conflicting, or unexplainable solutions. Confidence erodes the primary time two brokers return two completely different numbers for a similar query.
On AWS, that knowledge sits throughout a well-recognized combine. Operational information reside in Amazon Aurora and different Amazon Relational Database Service (Amazon RDS) engines. Analytics historical past lives in Amazon Redshift. Unstructured knowledge lives in Amazon Easy Storage Service (Amazon S3), queried by Amazon Athena, and more and more in open desk codecs comparable to Apache Iceberg, on Amazon S3 Tables, a functionality of Amazon S3, which Athena, Amazon EMR, and Amazon Redshift can all learn. Every layer is purpose-built for what it shops and most enterprises will preserve that form. The problem helps an AI agent purpose throughout all of them directly with the identical fluency a senior human analyst would deliver to the identical query.
Basis fashions deliver the language and the AWS knowledge utility brings the details. The acquainted strategy to join them right this moment is Retrieval Augmented Technology (RAG): index coverage paperwork, manuals, and help tickets into Amazon Bedrock Information Bases and pull matching passages into the mannequin’s context at question time. RAG works properly when the reply lives in textual content the search can discover. It really works much less properly for analytical questions the place the reply will depend on becoming a member of reside information throughout techniques, making use of a enterprise rule constantly, and honoring row- or column-level entry insurance policies.
What sits between language and details, and is normally lacking for these analytical questions, is enterprise context and enterprise metrics. Take a typical retail instance: a shared definition of what a buyer is, how an order hyperlinks to at least one, what counts as a large spender or a high-risk account, which system owns which truth, and the way the numbers the enterprise experiences are computed. The identical hole reveals up in different domains (claims and insurance policies in insurance coverage, sufferers and encounters in healthcare, elements and shipments in provide chain) beneath completely different names. A semantic layer captures that context as soon as and lets each agent and power reuse it. With it, an AI agent can compose solutions from many sources and stand behind the numbers it returns. A semantic layer doesn’t substitute RAG. It enhances it. Most manufacturing techniques want each, reachable by the identical agent.
A semantic layer is an ontology-driven view of your enterprise knowledge. The ontology captures the ideas, relationships, attributes and guidelines that matter to your online business. Mappings declare how these ideas are mapped from rows in every reside supply. The agent queries the layer. The layer interprets every question into SQL towards the underlying techniques at runtime. Knowledge stays the place it’s. That means is captured as soon as and reused.
When that semantic layer is applied as Stardog does it (an ontology, steady identifiers for each entity, and guidelines that derive new details, and constraints that validate the info towards the ontology) the result’s a data graph. The info is linked as a graph of enterprise entities fairly than rows in tables, each entity has a steady URL-style distinctive identifier known as an IRI, and queries traverse these connections in a W3C-defined, standards-based question language known as SPARQL. Two extra phrases come up repeatedly in the remainder of the submit:
- A named graph is a labeled subset of the graph, recognized by an IRI of its personal. Stardog makes use of named graphs because the unit of entry management. The identical question produces completely different outcomes for various roles relying on which named graphs every position is allowed to learn.
- A digital graph is a named graph whose contents aren’t saved in Stardog in any respect. They reside in an exterior system (Aurora, Amazon Redshift, Athena) and Stardog fetches the rows on demand utilizing the mappings. Federation on this submit is applied as a set of digital graphs, one per supply.
The Stardog glossary defines every of those phrases, and the Stardog Getting Began sequence places them in context.
By the tip of this submit you’ll know:
- How a semantic layer matches alongside RAG, and when to select every.
- Tips on how to federate Stardog throughout Amazon Aurora and Amazon Redshift, with notes on extending to Amazon Athena and different AWS knowledge sources.
- Why we advocate AgentCore Runtime, Gateway, and Id for operating the agent in manufacturing.
- Two integration paths from the agent to Stardog: a direct SPARQL instrument, and the Stardog Cloud Mannequin Context Protocol (MCP) server as a Gateway instrument goal.
- Tradeoffs on governance, deployment, and what’s usually obtainable (GA) versus beta right this moment.
Three layers an agent wants
An AI agent that offers dependable, business-context-aware solutions will depend on three issues working collectively. Each solves an issue the others can’t.
1. Mannequin layer. A basis mannequin that may plan and write. Amazon Bedrock supplies a single API to a number of mannequin households. We use Anthropic Claude Sonnet 4.6. The mannequin is aware of language, it doesn’t know your online business.
2. That means layer. A semantic layer that offers the mannequin reliable, ruled entry to the info behind your online business questions. The ontology declares the ideas and the principles that derive new details from them, and the federation pulls reside rows from every supply at question time. The layer does the work: it figures out which knowledge is related, rewrites the SPARQL question into SQL for every supply, and joins the rows on shared identifiers. The mannequin has a narrower job. It reads the person’s query, calls the layer when it wants knowledge, and writes the reply in plain English. The precise reasoning over knowledge, like making use of the Big_Spender rule throughout the federated sources, stays inside Stardog fairly than contained in the immediate. We use Stardog’s federated data graph over Aurora and Amazon Redshift for this.
3. Agent runtime layer. The compute that hosts the agent, terminates inbound requests, manages instrument credentials, and supplies the operational floor for safety and governance. On AWS you could have a spectrum of decisions: managed runtimes like Amazon Bedrock AgentCore at one finish, and self-managed choices like Amazon ECS, Amazon EKS, or AWS Lambda on the different. The best alternative will depend on how a lot of the agent operations you wish to personal. We use Amazon Bedrock AgentCore on this submit as a result of it’s the most prescriptive of the choices for manufacturing brokers on AWS.
Of the three, the which means layer is the hole this submit is about, and the remainder of the walkthrough builds it. The agent runtime layer is the one most groups underestimate: how does the agent get known as, how does it authenticate, the place does its credential to the semantic layer reside, and the way does it scale. AgentCore packages solutions to these questions into one managed service, which is why we use it right here.
Instance use case: A buyer 360 agent throughout Aurora and Amazon Redshift
We selected buyer 360 (C360) for the remainder of this walkthrough as a result of it surfaces each hole an AI agent runs into the second it tries to do actual analytical work, and it lets us present how the semantic layer closes every one in a couple of hundred traces of mappings and guidelines. In a typical retail setup, buyer profile, tackle, bank card, and rewards info sit in an operational database. Orders, merchandise, classes, and distributors reside in a knowledge warehouse for analytics. All sides is well-tuned for what it does. Neither aspect, by itself, can reply a query concerning the buyer as an entire. An agent that tries to reply “who’re our most useful prospects, and what are they shopping for?” has to reconcile two databases, two schemas, two definitions of “buyer”, and a derived thought (“most useful”) that lives in no person’s column. C360 makes these gaps concrete.
The C360 agent runs for the analytics crew. It accepts a query in plain English from a gross sales lead, a marketer, or a fraud analyst. It writes the queries, runs them throughout the corporate’s knowledge, and replies with a brief narrative reply plus the supporting numbers. The person doesn’t see SQL or SPARQL, and the agent doesn’t see the info it’s not allowed to see.
A person asks the C360 agent, in plain English: “Who’re our high spenders in Wisconsin?” Buyer profile and tackle reside in Aurora. Order totals reside in Amazon Redshift. The agent has to hitch them on a steady buyer identifier, and that be a part of is one in all three issues a semantic layer provides:
1. Joins throughout techniques by shared which means. The semantic layer maps buyer information from each Aurora and Amazon Redshift to a typical buyer identification utilizing shared enterprise keys. This lets the be a part of be expressed by the semantic mannequin fairly than a bodily integration pipeline. With out it, that be a part of typically requires a maintained pipeline that materializes a 3rd copy of the info and have to be stored in sync every time both supply adjustments.
2. Derived details as guidelines, not queries. A definition like “large spender” can reside within the ontology as a rule fairly than being re-expressed in each question, and each question that mentions it will get the identical reply. With out it, that definition will get duplicated throughout dashboards, notebooks, and experiences. When the brink adjustments, the copies drift aside and the identical query begins returning completely different solutions.
3. Graph-level entry management. Named graph safety controls entry on the graph stage, so completely different roles see completely different subsets of the enterprise data graph. For extra fine-grained safety, you possibly can designate delicate properties comparable to :ssn and :cardNumber as protected properties. Customers with permission see the precise values, whereas others see masked values by default. With this strategy, completely different roles can run the identical question whereas the data graph enforces constant safety insurance policies throughout each utility that accesses it.
We took Stardog’s C360 Information Package, which initially masses native CSVs, and tailored it to federate throughout Aurora PostgreSQL (buyer aspect) and Amazon Redshift (buy aspect). The equipment ships an ontology, pattern knowledge, and ready-made queries. You should utilize it as the place to begin to your personal work.
The info mannequin the agent doesn’t see
Beneath the agent, the C360 knowledge is break up throughout two AWS databases. Aurora holds the operational, customer-facing tables. Amazon Redshift holds the analytics truth desk and product dimensions.
Aurora PostgreSQL (operational)
| Desk | Key columns |
buyer |
cid, first_name, last_name, e mail, ssn, cellphone, location |
tackle |
id, metropolis, state, zip, street_name |
credit_card |
id, cid, card_num, card_type |
rewards_account |
id, cid, account_id, create_date |
Amazon Redshift (analytics)
| Desk | Key columns |
buy |
id, cid, pid, date, amount, worth, card |
product |
id, title, model, worth, dept |
class |
id, dept_name, father or mother |
vendor |
id, vendor_name, trade |
The shared identifier throughout the 2 databases is the integer cid. It seems as a major key within the buyer desk on Aurora and as a non-foreign-key column within the buy desk on Amazon Redshift. There’s no SQL constraint linking them. There can’t be: they reside in numerous engines. Solutions that be a part of prospects to their orders should reconcile that integer at question time, each time, with out ETL.
That is what the semantic layer absorbs. The ontology declares one idea, :Buyer, and one steady identification for it: an IRI of the shape urn:stardog:demos:c360:buyer:{cid}. Each the Aurora buyer mapping and the Amazon Redshift buy mapping mint that very same IRI from their respective cid values. The agent sees one buyer entity with a profile, addresses, playing cards, rewards accounts, and orders. The warehouses see their very own rows, unchanged. The mappings mint the identical buyer IRI from the cid in each databases. Stardog makes use of that shared identification to hitch the federated outcomes with out requiring the underlying databases to find out about each other.
Reference structure
Determine 1. Key level: knowledge stays in Aurora and Amazon Redshift. Solely queries stream by the semantic layer.
That is the advisable manufacturing structure. The proof of idea (POC) for this submit used Path A with the agent operating as a standalone script.
The diagram reveals two flows.
Inbound. A consumer (an utility, one other agent, or Stardog Studio) calls the agent by AgentCore Gateway. Gateway validates the inbound JSON Net Token (JWT) and routes the decision to AgentCore Runtime, which hosts the Strands agent. The agent invokes Claude Sonnet 4.6 on Amazon Bedrock for planning and reply composition.
Outbound to the semantic layer. Two paths are proven.
- Path A (right this moment, orange dashed): The Strands agent calls a
query_kgSPARQL instrument that talks to Stardog straight. Use this whenever you don’t but have Voicebox API entry (described later on this submit). - Path B (Stardog Cloud MCP, when API entry is accessible, blue): AgentCore Gateway has the Stardog Cloud MCP server registered as an MCP goal. Gateway pulls the Stardog token from AgentCore Id and forwards the decision. The agent doesn’t contact the credential.
Stardog itself federates to the warehouses at question time over Java Database Connectivity (JDBC). SPARQL is rewritten to SQL per supply. Outcomes are joined inside Stardog on shared IRIs. There isn’t any ETL job and no third copy of the info.
Construct the semantic layer
Three items make the federation work. The ontology declares the ideas (:Buyer, :Order, :Product) and the relationships between them. The mappings declare how rows in every datastore change into situations of these ideas. Reasoning guidelines derive new details from the info already in scope. Stardog Designer is the authoring floor for all three.
The ontology
Determine 2. The C360 mannequin in Stardog Designer. Ideas like Buyer, Order, Product, and Tackle seem as coloured nodes linked by labeled relationships (bought, card holder, has tackle, in class). The lighter-shaded nodes across the edges (Large Spender, Giant Order, 2022 Orderer, the Sports activities Class shopper) are derived courses inferred by reasoning guidelines within the mannequin fairly than columns in any supply.
The C360 ontology is authored in Stardog Designer, a no-code visible modeling and mapping instrument. The modeler creates ideas (:Buyer, :Order, :Product), connects them with relationships (:purchasedBy hyperlinks an :Order again to a :Buyer), and declares fields like :ssn and :cardNumber as delicate properties. No OWL or RDF is written by hand. The total C360 mannequin defines roughly ten courses and thirty properties. Designer also can generate a beginning mannequin from present supply metadata comparable to desk schemas, FHIR definitions, use case description and competency questions, which is a sooner path than writing the mannequin from scratch.
Portability is a key benefit of Designer which makes use of Turtle, the W3C customary serialization for RDF to persist fashions. This standards-based strategy helps forestall vendor lock-in and helps interoperability with the broader RDF community:
- Import ontologies straight from instruments like Protégé.
- Export knowledge to companies comparable to Amazon Neptune.
- Carry out round-trip workflows throughout different RDF suitable utilities.
The ontology grows over time because the questions it must reply get extra particular. Most groups begin with a small use case and competency questions used to construct a mannequin after which it’s prolonged incrementally.
Beneath the hood: what Designer generates. The portion of the mannequin the federation rests on is small (prefix declarations elided for brevity).
:Buyer a owl:Class .
:purchasedBy a owl:ObjectProperty ;
so:domainIncludes :Order ;
so:rangeIncludes :Buyer .
:ssn a owl:DatatypeProperty, m:SensitiveProperty ;
so:domainIncludes :Buyer .The factors value noticing: each idea will get a steady identifier, the connection from :Order to :Buyer is asserted as soon as and reused in all places, and :ssn is classed as m:SensitiveProperty (from Stardog’s metadata vocabulary) within the mannequin itself fairly than in a downstream coverage file. The total ontology is within the C360 Information Package.
The mappings (federation constructing block)
Determine 3. The mapping editor in Stardog Designer. The Buyer supply on the precise is sure to the Buyer idea on the left. The id column is ready because the Main Identifier, which is what produces the steady IRI used in all places else. Beneath the identifier, relationships like Has Loyalty Program Standing and Interacts With hyperlink the client to different ideas in the identical mannequin.
In Designer, mappings are authored visually. The modeler maps the Aurora buyer desk to the :Buyer idea and tells Designer that id is the entity key. Designer does the identical on the Amazon Redshift aspect: map the buy desk, mark cid because the buyer key. (In database phrases, cid in :buy references id in :Buyer.) The identical map-and-mark-the-key stream works for each warehouses. The mappings keep impartial, however they line up as a result of the IRI produced from the values within the cid in :Buy is similar IRI as produced for the values of id in :buyer.
The architectural property to know is the IRI template. It’s what lets the agent reply cross-warehouse questions with out ETL. Each mappings produce the identical identifier for a similar buyer. A buyer with cid=42 turns into urn:stardog:demos:c360:buyer:42 whether or not the row got here from the Aurora buyer desk or the Amazon Redshift buy desk. The agent sees one entity. The warehouses are unchanged. No SQL JOIN ever crosses the 2 warehouses. The “be a part of” is the IRI settlement.
Beneath the hood: what Designer generates. When Designer saves a mapping, it emits Stardog Mapping Syntax (SMS), a superset of the W3C R2RML customary that makes use of a SPARQL-like syntax. Stardog reads R2RML straight and might export SMS again to R2RML, so mappings port both course. The 2 excerpts that carry the federation constructing block appear like this:
# Aurora buyer mapping (excerpt)
BIND(TEMPLATE("urn:stardog:demos:c360:buyer:{cid}") AS ?iri)
# Redshift order mapping (excerpt)
BIND(TEMPLATE("urn:stardog:demos:c360:buyer:{cid}") AS ?cust_iri)The total mapping information for each C360 desk are within the equipment.
The next diagram traces a query from the agent all the way down to the info sources and again. The center band is the semantic layer. Nothing in it shops rows. The rows reside in Aurora and Amazon Redshift. Stardog makes use of the ontology and the mappings to determine which SQL to run the place, then joins the end result units on the shared IRI earlier than handing them again.
Determine 4. The question stream from the C360 agent to Aurora and Amazon Redshift and again. SPARQL is rewritten to SQL per supply. Outcome units are joined inside Stardog on the shared buyer IRI.
Reasoning over the graph
Stardog helps OWL reasoning and user-defined guidelines written in Stardog Rule Syntax (SRS) or SWRL. Reasoning is the method of inferring new details from present knowledge utilizing the schema. The equipment defines derived courses comparable to Big_Spender (a buyer who has positioned at the least one order above a threshold) and Large_Order. With reasoning enabled at question time, asking “what number of large spenders by state?” works with out precomputing or materializing these details. The principles are outlined as soon as within the semantic mannequin and evaluated over reside knowledge when the question runs.
Encoding enterprise definitions as soon as, as an alternative of re-implementing them in SQL queries, dashboards and prompts, is among the hardest elements of shifting past RAG.
Govern entry with named-graph safety
Buyer 360 knowledge is regulated. Two necessities present up early.
1. Some customers (HR, fraud) have to see personally identifiable info (PII) like a Social Safety quantity (SSN) and full card quantity. Most customers (advertising and marketing, analytics) should not.
2. The management shouldn’t require adjustments within the underlying warehouses.
Stardog’s mechanism for that is named-graph safety. A named graph is a labeled subset of the info. Named-graph safety gates reads towards every named graph on a per-user foundation. Every digital graph within the federation has its personal named-graph IRI. We break up the Aurora mapping into two digital graphs.
aurora_c360_safe: Buyer profile minus PII (every thing besides:ssnand:cardNumber).aurora_c360_pii: Solely the PII triples, keyed to the identical buyer IRI.
The Amazon Redshift mapping is one graph, redshift_c360. We then create two roles.
hr_user: Learn on all three digital graphs.marketing_user: Learn onaurora_c360_safeandredshift_c360solely.
When marketing_user runs a SPARQL question that asks for ?c :ssn ?ssn, Stardog’s planner treats aurora_c360_pii as if it didn’t exist for that person. The JDBC pushdown for the SSN column doesn’t occur. No application-level filter, no warehouse-side change, no likelihood of leaking the worth by a misconfigured BI instrument. Similar SPARQL question, two roles, two completely different end result units.
For row-level filters (a US-East analyst solely sees east-coast prospects, for instance) the identical named-graph mechanism scales: break up the supply into extra digital graphs alongside the row dimension, then grant per-graph reads. That is repetition of the PII sample, not a brand new characteristic.
Stardog additionally helps tagging particular person properties as delicate on the ontology, with the tag driving column-level masking at question time. That is value evaluating as a substitute for the previous named-graph break up. It matches finest when delicate fields are scattered throughout many entities and you’ll fairly mark them within the ontology than partition the info. See Stardog’s fine-grained safety docs for the configuration steps.
Run the agent and name Stardog from it
Strands Brokers is a small framework for constructing brokers. A brief Python script wires Claude Sonnet 4.6 (on Amazon Bedrock) to a instrument that runs SPARQL towards Stardog. A abstract of the ontology is loaded into the agent’s system immediate. The mannequin writes SPARQL, the instrument returns rows, the mannequin summarizes the outcomes.
That code is transportable. The identical agent can run as a Python script on a laptop computer, in a container on Amazon ECS or Amazon EKS, behind an Software Load Balancer, or as an AWS Lambda perform. For manufacturing we advocate deploying it on Amazon Bedrock AgentCore as a result of it bundles the operational scaffolding into one managed service.
- AgentCore Runtime hosts the agent and handles concurrency and session state.
- AgentCore Gateway is the inbound floor that validates the JWT out of your identification supplier (IdP) and routes the decision to Runtime.
- AgentCore Id holds the Stardog token as a credential supplier, so the credential doesn’t reside within the agent code.
Should you choose a unique runtime, the identical constructing blocks nonetheless want a house: a internet hosting layer, an inbound authenticator, and a credential vault. The combination patterns that comply with don’t change. What adjustments is which AWS service holds each bit.
The combination to Stardog is the place deployments differ. Two paths are value understanding. Default to Path A except you have already got Voicebox API entry.
Path A: Direct SPARQL instrument. A small Python instrument wraps the pystardog consumer and is uncovered to the agent by Strands’ instrument decorator. The agent writes SPARQL, the instrument runs it, the instrument returns rows. This works on Stardog situations you possibly can attain over HTTPS, together with Stardog Cloud’s Free tier. We used this path within the POC as a result of it requires no particular enablement on the Stardog account.
Path B: Stardog Cloud MCP server as a Gateway instrument goal. Stardog publishes an official MCP server, stardog-union/stardog-cloud-mcp, that exposes Voicebox (Stardog’s natural-language question layer) as three instruments: voicebox_ask, voicebox_generate_query, and voicebox_settings. Voicebox runs its personal ontology-aware natural-language-to-SPARQL pipeline and returns the reasoning chain and provenance with every reply. AgentCore Gateway can register this MCP server as a instrument goal, which implies the agent inside Runtime sees Voicebox as a instrument with no glue code, and AgentCore Id injects the token on the Gateway hop.
The MCP server’s native mode is steady. Distant mode is in beta. Path B additionally requires a Voicebox API token, which is gated to particular accounts. Contact Stardog in case your portal doesn’t present “Handle API Keys.”
Choose Path A whenever you don’t but have API entry or whenever you need full management over SPARQL era. Choose Path B when you could have API entry and need Voicebox’s reasoning chain and provenance for no extra value.
We advocate enabling Amazon Bedrock immediate caching for manufacturing deployments. The agent reuses the identical giant system immediate, the C360 ontology abstract, on each name. Amazon Bedrock immediate caching retains the cached portion of that immediate heat throughout calls, which reduces input-token value on repeat invocations. In Stardog deployments, immediate caching can scale back per-query input-token value when the identical ontology context is reused throughout requests. Caching is configured per request. Verify your agent framework’s BedrockModel parameters for the way to expose the cache level.
Pattern queries and verification
To substantiate the federation behaved as designed, we ran three classes of questions towards the reside deployment.
Aurora-only. “Record ten prospects and their state.” Supply knowledge is in Aurora. Stardog points one SQL question towards the Aurora buyer and tackle tables and returns the rows. The Amazon Redshift digital graph is just not touched.
Amazon Redshift-only. “Prime ten merchandise by items offered.” Supply knowledge is in Amazon Redshift. Stardog points a single grouped aggregation towards the buy desk and returns the totals. Aurora isn’t touched.
Federated. “Prime ten buyer spenders, with their state.” This wants Aurora prospects and addresses joined with Amazon Redshift orders on the shared buyer IRI. The precise SPARQL the agent runs:
PREFIX :
SELECT ?cust ?fname ?lname ?state (SUM(?worth * ?qty) AS ?spend)
WHERE {
GRAPH {
?cust a :Buyer ;
:firstName ?fname ;
:lastName ?lname ;
:tackle ?a .
?a :state ?state .
}
GRAPH {
?o :purchasedBy ?cust ;
:purchasePrice ?worth ;
:amount ?qty .
}
}
GROUP BY ?cust ?fname ?lname ?state
ORDER BY DESC(?spend)
LIMIT 10 Stardog points a SQL question to every supply (one towards the Aurora buyer and tackle tables, one which aggregates Amazon Redshift buy by cid), receives each end result units, and joins them on the ?cust variable, that’s, the IRI mapped from cid on both sides. The highest end result for our seed knowledge was Carolyn Inworth, $502,529 in whole spend throughout her purchases. The identical question towards the identical knowledge returns the identical quantity on each run.
We then ran the reasoning case: “what number of large spenders are there per state?” with reasoning enabled. Stardog utilized the Big_Spender rule throughout the federated graph at question time and returned counts per state with out precomputing or materializing the derived class.
For governance we ran the identical SPARQL question twice, as soon as as hr_user and as soon as as marketing_user. The HR position noticed the SSN worth sure. The advertising and marketing position bought again the identical row form with an empty ?ssn binding, with no change to the question textual content and no warehouse-side filter.
Extending the semantic layer throughout AWS knowledge sources and past
Stardog’s digital graph mechanism is just not particular to Aurora or Amazon Redshift. So as to add a brand new supply or lengthen the ontology, the modeler works in Stardog Designer, the identical authoring floor used for the preliminary C360 mannequin. Designer generates the SMS mapping. When the modeler marks the identical entity key (for instance, cid for the client idea), the IRI template matches and the brand new supply turns into a part of the federated semantic layer with out altering the ontology or present queries. On AWS this consists of Amazon Athena (knowledge lake on Amazon S3) and Amazon RDS engines that ship a JDBC driver. Off AWS this consists of Snowflake, Google BigQuery, MongoDB, and SAP HANA. The total checklist is in Stardog’s supported knowledge sources web page.
The architectural property to protect as you add sources is the IRI template. So long as the brand new mappings mint IRIs that match present ones for a similar logical entity, the brand new supply can take part naturally within the present federated graph. Stardog calls this “cooperation with out coordination”: every crew owns its supply and its mappings, and the graph composes.
Stardog Cloud in comparison with self-managed on Amazon EKS
Stardog runs in two shapes on AWS, and the selection is operational, not practical.
Stardog Cloud (SaaS). Stardog operates the SOC 2 compliant service with 99.9 p.c service stage agreements (SLAs). You deliver knowledge sources and credentials. Free, Necessities, and Enterprise tiers exist. Use this whenever you wish to skip operations, when your knowledge sources are reachable from Stardog Cloud (over the general public web, or by AWS PrivateLink for Enterprise), and when the Stardog-managed replace cadence works for you. We used Stardog Cloud for the work behind this submit.
Self-managed on Amazon EKS. Stardog ships container photographs and Helm charts. You run the cluster, handle upgrades, and deal with backup. Use this when it is advisable preserve knowledge aircraft visitors inside your digital personal cloud (VPC), whenever you wish to management the model cadence, when compliance requires a particular deployment posture, or when the info sources are themselves solely reachable from inside your VPC.
Egress issues both manner. Stardog Cloud connects to Aurora and Amazon Redshift over JDBC, so the safety teams on these knowledge sources should enable inbound connections from Stardog Cloud’s egress IP vary. Stardog publishes the present set of egress IPs of their documentation. Allowlist these CIDRs on every knowledge supply safety group and the federation works. See Enable-listing digital graph calls from Stardog Cloud for the present values and the configuration steps.
Conclusion
Dependable agentic analytics wants three issues working collectively: a basis mannequin that may plan and generate queries, a semantic layer that gives a ruled enterprise view throughout reside enterprise knowledge, and a manufacturing runtime that hosts the agent and manages safety. Amazon Bedrock, Stardog, and Amazon Bedrock AgentCore every play a type of roles.
The important thing architectural thought is that the agent talks to the semantic layer, not on to the underlying databases. As knowledge sources and schemas evolve, the ontology and mappings take in these adjustments, permitting brokers to proceed reasoning over steady enterprise ideas fairly than bodily tables and columns.
The place to begin
Most groups that get this working begin with one workflow fairly than a large rollout.
A sensible sequence:
1. Choose one workflow that will get answered slowly right this moment as a result of the info spans two or three techniques. Narrower is healthier.
2. Write three to 5 competency questions the workflow wants answered. These are the queries the semantic layer has to help on day one.
3. Bootstrap the ontology out of your supply schemas in Designer, then refine it towards the competency questions till every one returns a wise reply.
4. Rise up the federation as digital graphs over the reside sources. No ETL, no third copy.
5. Wire the agent to the layer by Path A or Path B, relying in your Voicebox API entry.
The Stardog C360 Information Package is a helpful start line. It’s the identical equipment this submit adapts.
Additional studying
Concerning the authors
