Oracle AI Agent Memory<\/a>\u00a0provides a durable memory layer for AI agents. It stores scoped memories, retrieves relevant context for later turns, and helps applications separate what the agent is allowed to\u00a0remember\u00a0from how memories are ranked.\u00a0\u00a0<\/p>\nHybrid search expands that retrieval model so an agent can recall by semantic meaning and by exact text in the same workflow, while memory governance\u00a0remains\u00a0tied to scope and application policy.\u00a0
\u00a0
The setup has four main components:\u00a0<\/p>\n
`OracleAgentMemory`\u00a0is the durable memory layer. It stores memories, applies scope, and exposes search.\u00a0<\/p>\n
`OracleDBEmbedder`\u00a0connects retrieval to Oracle-backed embedding\u00a0behavior\u00a0used by the memory store.\u00a0<\/p>\n
`SearchStrategy.HYBRID`\u00a0tells the memory layer to combine semantic and exact-text retrieval signals.\u00a0<\/p>\n
`SearchIndexSyncMode`\u00a0controls when the managed search index is refreshed after memories are written.\u00a0<\/p>\n
Start by installing the\u00a0oracleagentmemory\u00a0package in the notebook or application environment. The hybrid-search API is configured in application code; the database schema and index setup are handled through the Oracle-backed memory store.\u00a0\u00a0<\/p>\n
This makes Oracle AI Database agent memory a practical pattern for applications that need durable memories, scoped retrieval, and database-managed search.<\/p>\n
“`bash
\npip install oracleagentmemory==26.6.0
\n“` \u00a0<\/p>\n
The core imports for a hybrid-search configuration look like this:\u00a0<\/p>\n
“`python
\nfrom oracleagentmemory.apis.searchscope import SearchScope
\nfrom oracleagentmemory.core import (
\n MemoryExtractionConfig,
\n OracleAgentMemory,
\n SchemaPolicy,
\n SearchIndexSyncMode,
\n SearchStrategy,
\n)
\nfrom oracleagentmemory.core.embedders import OracleDBEmbedder
\n“` <\/p>\n
Why vector memory is not always enough\u00a0<\/p>\n
Agent memory is not only a semantic archive of\u00a0previous\u00a0conversations. In enterprise systems, memory records often include short strings that carry operational meaning.\u00a0\u00a0<\/p>\n
A single identifier can point to the correct incident, invoice, customer, model, file, run, or database error. If retrieval treats that identifier like ordinary prose, the agent can return a memory that is semantically related but operationally wrong.\u00a0<\/p>\n
Vector search helps when users paraphrase. It is especially useful when a user asks about a topic without repeating the exact words stored in memory.\u00a0\u00a0<\/p>\n
But vector similarity is\u00a0not the same as\u00a0exactness. A short token can be diluted by the rest of the sentence, especially when the surrounding context is broad or when several memories are about similar workflows.<\/p>\n
Where exact text matters\u00a0<\/p>\n
Exact text matters whenever a memory must point to a specific object rather than a general topic. Common examples include:\u00a0<\/p>\n
Issue IDs and ticket references used in engineering and support workflows.\u00a0<\/p>\n
Invoice, order, contract, and purchase-order numbers used in business workflows.\u00a0<\/p>\n
Database, application, and integration error codes used in troubleshooting.\u00a0<\/p>\n
Customer aliases, account IDs, and tenant names used for scoped recall.\u00a0<\/p>\n
Product SKUs, model numbers, filenames, branch names, and run IDs used by operational agents.\u00a0<\/p>\n
These values are small, but they often carry more authority than nearby prose. A robust agent memory layer should preserve that literal signal while still supporting semantic lookup and exact-match retrieval.<\/p>\n
Types of\u00a0search\u00a0<\/p>\n
Vector searchKeyword search\u00a0Hybrid search\u00a0Finds by meaning and paraphrase\u00a0Finds by exact text (literal identifiers)\u00a0Combines semantic\u00a0and exact-text signals in one ranked retrieval path\u00a0Example query: \u201cWhat blocked the renewal?\u201d\u00a0Example query: \u201cINV-48291\u201d\u00a0Example queries: \u201cINV-48291\u201d and \u201cWhat blocked the renewal?\u201d\u00a0Table\u00a01:\u00a0Conceptual\u00a0search-mode comparison\u00a0<\/p>\n
The differences become clearer when you compare what each mode\u00a0optimizes\u00a0for.\u00a0<\/p>\n
The following comparison explains the retrieval modes conceptually. The companion notebook executes the hybrid configuration and evaluates it across exact, semantic, and mixed queries; it is not a benchmark of three separately executed strategies.\u00a0<\/p>\n
Mode\u00a0Best atWeak spotAgent memory fitVector searchParaphrase, semantic similarity, concept recall\u00a0Short identifiers may be\u00a0low-signal\u00a0Good for natural-language recall\u00a0Keyword searchLiteral identifiers, error codes, aliases, filenames\u00a0Brittle when wording changes\u00a0Good when exact strings matter\u00a0Hybrid searchNatural language plus exact handles\u00a0Requires database embedding and managed index setup\u00a0Strong fit when both semantic and exact-text retrieval matter\u00a0Table\u00a02: Search mode comparison\u00a0<\/p>\n
Use hybrid search when:\u00a0<\/p>\n
Users ask in natural language but refer to exact business objects.\u00a0<\/p>\n
Memories include identifiers, aliases, filenames, error codes, or transaction IDs.\u00a0<\/p>\n
Several memories are semantically similar, but one exact token should decide the result.\u00a0<\/p>\n
The agent needs scoped retrieval across user, agent, tenant, or thread boundaries.\u00a0<\/p>\n
How Oracle AI Agent Memory supports hybrid retrieval for agent memory\u00a0<\/p>\n
Oracle AI Agent Memory exposes hybrid retrieval as a memory-store configuration. The application supplies an Oracle-backed embedder, selects\u00a0`SearchStrategy.HYBRID`, and chooses an index synchronization mode. The result is one memory layer that can retrieve by meaning and exact text over the same stored memories, while still respecting user, agent, and thread scope.\u00a0
\u00a0
`OracleDBEmbedder`\u00a0is important because hybrid search relies on the database-managed embedding and index path.\u00a0`SearchStrategy.HYBRID`\u00a0selects the hybrid retrieval backend.\u00a0`SearchIndexSyncMode`\u00a0defines when new or updated memory content becomes searchable through the managed index. Together, these settings make retrieval\u00a0behavior\u00a0explicit in application code rather than hiding it behind an ad hoc query pipeline.\u00a0<\/p>\n
The configuration below shows the\u00a0minimum\u00a0pattern: choose an Oracle-backed embedder, set\u00a0`SearchStrategy.HYBRID`, and choose how the search index should refresh:<\/p>\n
“`python
\ndb_embedder = OracleDBEmbedder(
\n connection=connection,
\n model=CONFIG[“ORACLE_DB_EMBEDDING_MODEL”],
\n embedding_dimension=CONFIG[“ORACLE_DB_EMBEDDING_DIMENSION”],
\n)
\nmemory = OracleAgentMemory(
\n connection=connection,
\n embedder=db_embedder,
\n memory_extraction_config=MemoryExtractionConfig(
\n extract_memories=False
\n ),
\n schema_policy=SchemaPolicy.CREATE_IF_NECESSARY,
\n search_strategy=SearchStrategy.HYBRID,
\n search_index_sync=SearchIndexSyncMode.ON_COMMIT,
\n memory_store_id=”hybrid_blog”,
\n)
\n“` <\/p>\n
Memory extraction is disabled because the example inserts controlled durable memories directly and focuses specifically on retrieval\u00a0behavior.\u00a0<\/p>\n
In a typical workflow, the agent writes durable memories with user, agent, or thread scope. Later, search requests use\u00a0`SearchScope`\u00a0to restrict eligible records before ranking happens. That separation matters: scope decides what the agent is allowed to remember, while hybrid search decides how eligible memories are ranked.<\/p>\n
Hybrid retrieval flow\u00a0<\/p>\n
In an agent workflow, hybrid search is most useful when it sits between memory scoping and context assembly:<\/p>\n
![\"Flowchart](\"https:\/\/www.europesays.com\/ai\/wp-content\/uploads\/2026\/08\/Container-538x1024.png\")
Figure\u00a01.\u00a0Scoped hybrid retrieval flow<\/p>\n
`SearchScope`\u00a0and hybrid search are complementary. Scope\u00a0determines\u00a0which records are eligible for retrieval; hybrid search ranks only those eligible records. In the notebook, each evaluation query uses the same generated finance-user and support-agent scope, and retrieval is restricted to durable memory records by passing\u00a0`record_types=[\u201cmemory\u201d]`.\u00a0\u00a0<\/p>\n
This flow is the reason hybrid search fits agent memory well. The application first narrows the memory universe with scope. Hybrid retrieval then combines semantic and exact-text signals only over eligible records. The final output is not just a matching row; it is a ranked context package the agent can use in the next step.\u00a0<\/p>\n
“`python
\nuser_id = “finance_user_123”
\nagent_id = “support_finance_agent” <\/p>\n
scope = SearchScope(user_id=user_id, agent_id=agent_id) <\/p>\n
memory.add_memory(
\n content=(
\n “Northstar Renewals has a renewal blocker: invoice INV-48291 ”
\n “failed reconciliation after ORA-27102 during month-end processing.”
\n ),
\n user_id=user_id,
\n agent_id=agent_id,
\n) <\/p>\n
async def search_memory(query, scope, max_results=5):
\n return await memory.search_async(
\n query=query,
\n scope=scope,
\n max_results=max_results,
\n record_types=[“memory”],
\n ) <\/p>\n
exact_results = await search_memory(“INV-48291”, scope) <\/p>\n
semantic_results = await search_memory(
\n “What blocked the Northstar renewal?”,
\n scope,
\n)
\n “` <\/p>\n
Both calls use the same `SearchScope`, hybrid strategy, and managed hybrid index. Only the query style changes.\u00a0<\/p>\n
For example, a user might ask \u201cINV-48291\u201d or \u201cWhat blocked the renewal?\u201d over the same scoped memories.\u00a0\u00a0<\/p>\n
A vector-only search may understand the renewal-blocker question but underweight the exact invoice or error code. A keyword-only search may find INV-48291 or ORA-27102 but miss a paraphrased question such as \u201cWhat blocked the renewal?\u201d\u00a0\u00a0<\/p>\n
Hybrid search gives both signals a chance to influence ranking, so the agent can retrieve the Northstar Renewals memory with the exact invoice ID, the ORA-27102 error code, and the natural-language explanation.\u00a0<\/p>\n
Testing hybrid retrieval with deliberately similar memories\u00a0<\/p>\n
The companion notebook does not test hybrid retrieval against a single obvious memory. It creates a deliberately similar set of\u00a0memories,\u00a0so the retrieval path\u00a0has to\u00a0choose between records that share overlapping business, invoice, customer, renewal, and error-code vocabulary.\u00a0<\/p>\n
The notebook stores five durable memories:\u00a0<\/p>\n
A target renewal-blocker memory for Northstar Renewals,\u00a0containing\u00a0invoice INV-48291, Oracle error ORA-27102, and the failed reconciliation that blocked the renewal.\u00a0<\/p>\n
A\u00a0neighboring\u00a0invoice memory for Northstar Renewals,\u00a0containing\u00a0invoice INV-48290, which is marked as paid and does not require follow-up.\u00a0<\/p>\n
A different customer renewal-delay memory for Milan Office Supplies, where the delay is caused by an approval workflow rather than reconciliation.\u00a0<\/p>\n
A general ORA-27102 troubleshooting memory that explains the database error without tying it to the Northstar invoice.\u00a0<\/p>\n
A Northstar customer-alias memory that maps Northstar Renewals to its enterprise account name.\u00a0<\/p>\n
This setup makes the demonstration more realistic. The expected result must outrank memories that are partially similar, such as another Northstar invoice, another renewal delay, or another ORA-27102-related record. That is the\u00a0behavior\u00a0an enterprise agent memory system needs: not just finding something\u00a0related but\u00a0retrieving the memory that preserves the right operational detail.\u00a0<\/p>\n
Evaluating exact, semantic, and mixed queries\u00a0<\/p>\n
The notebook then evaluates the same hybrid-search configuration across five query scenarios. Each query uses the same\u00a0`SearchScope`, the same\u00a0`SearchStrategy.HYBRID`\u00a0configuration, and the same managed hybrid index. Only the query wording changes.\u00a0<\/p>\n
The five query categories are:\u00a0<\/p>\n
Exact invoice identifier: a query for INV-48291.\u00a0<\/p>\n
Exact Oracle error code: a query for ORA-27102.\u00a0<\/p>\n
Semantic renewal-blocker question: a natural-language question about what blocked the Northstar renewal.\u00a0<\/p>\n
Semantic customer question: a natural-language question about the Milan customer renewal delay.\u00a0<\/p>\n
Mixed customer and invoice question: a question that combines customer context with invoice reconciliation.\u00a0<\/p>\n
The validation checks whether the expected memory appears as the top-ranked result.\u00a0
\u00a0<\/p>\n
Query type\u00a0Expected memory\u00a0RankValidationExact invoice ID\u00a0Renewal blocker\u00a01PASS\u00a0Exact error code\u00a0Error reference\u00a01PASS\u00a0Semantic renewal question\u00a0Renewal blocker\u00a01PASS\u00a0Semantic customer question\u00a0Milan renewal\u00a01PASS\u00a0Mixed customer and invoice question\u00a0Renewal blocker\u00a01PASS\u00a0Table\u00a03: Evaluation results table\u00a0<\/p>\n
This is a controlled functional evaluation, not a statistical benchmark comparing vector, keyword, and hybrid search. The purpose is to show that one hybrid-search configuration can retrieve the expected durable memory across exact, semantic, and mixed query styles.<\/p>\n
Reading the notebook results\u00a0<\/p>\n
The results show that exact identifiers remained useful retrieval signals. The invoice query returned the renewal-blocker memory, while the ORA-27102 query returned the general error-reference memory. This matters because both the target renewal memory and the general troubleshooting memory\u00a0contain\u00a0the same error code, but they serve different user intents.\u00a0<\/p>\n
The semantic queries also returned the intended memories without requiring the user to repeat the exact stored wording. For example, the renewal-blocker question retrieved the Northstar renewal memory, while the Milan customer question retrieved the separate Milan renewal-delay memory.\u00a0<\/p>\n
The mixed query is the most representative enterprise case. It combines business context with an implied operational object: the user asks which invoice failed reconciliation for Northstar. The expected result is the memory\u00a0containing\u00a0INV-48291, ORA-27102, and the failed reconciliation context.\u00a0<\/p>\n
The notebook also displays distance values for the ranked results. In this result set, smaller distance values\u00a0indicate\u00a0stronger matches. However, distance should be treated as a retrieval signal for inspection, not as a universal accuracy score. The more important validation is whether the expected memory was returned at rank one for each query.\u00a0<\/p>\n
How hybrid search improves enterprise agent accuracy\u00a0<\/p>\n
Hybrid search improves retrieval accuracy because it matches how enterprise memory is\u00a0actually written. A memory record rarely\u00a0contains\u00a0only natural-language explanation or only an identifier. It usually\u00a0contains\u00a0both: a named handle plus the context that explains why the handle matters.\u00a0<\/p>\n
Higher precision for identifier-driven questions because exact strings can influence ranking.\u00a0<\/p>\n
Better recall for paraphrased questions because semantic search still finds related memory records.\u00a0<\/p>\n
More useful context packages because the agent can retrieve both the handle and the surrounding explanation.\u00a0<\/p>\n
Lower risk of plausible but wrong recall when several memories are semantically similar.\u00a0<\/p>\n
Developers can inspect the ranked memories, metadata, and distances to verify whether the expected operational context was retrieved.\u00a0<\/p>\n
This is especially useful for support agents, finance assistants, operations copilots, developer agents, and workflow agents that must remember prior decisions, tool outputs, system errors, or customer-specific context.\u00a0
\u00a0
The practical benefit is not only better search quality; it is better agent\u00a0behavior.\u00a0<\/p>\n
Better retrieval can improve grounding, but the model still needs normal validation and application controls.\u00a0Hybrid search gives the retrieval layer a stronger chance of selecting the memory that a human operator would have recognized\u00a0immediately.\u00a0<\/p>\n
Production notes: schema and index setup\u00a0<\/p>\n
For production, treat hybrid search as part of the memory-store design, not as a last-minute query\u00a0option. The schema should be owned by a dedicated application user with the right privileges, tablespace quota, and deployment controls. Memory scope should also match the application boundary, such as user, agent, tenant, or thread.\u00a0<\/p>\n
`SchemaPolicy.CREATE_IF_NECESSARY` is useful during first-time setup or when upgrading a schema so it can support hybrid search. For a large existing memory store, the first hybrid index build may take time because Oracle needs to prepare the managed search structures over stored memory content. Treat that step as a planned migration rather than a normal application startup task.\u00a0<\/p>\n
After the schema and index are ready, production applications may prefer `SchemaPolicy.REQUIRE_EXISTING`. That lets startup\u00a0validate\u00a0the expected schema instead of creating or\u00a0modifying\u00a0database objects.\u00a0<\/p>\n
`SearchIndexSyncMode` is a freshness and operations\u00a0tradeoff:\u00a0<\/p>\n
`ON_COMMIT` is best for notebooks, demos, and interactive applications because newly committed memories become searchable\u00a0immediately.\u00a0<\/p>\n
\u00a0`MANUAL` is useful for bulk loads, backfills, and migrations where teams want to ingest many records first and refresh the index on a controlled schedule.\u00a0<\/p>\n
`AUTO` delegates background maintenance to Oracle-managed\u00a0behavior, which can fit production workloads where some freshness lag is acceptable. `AUTO` is supported for `SearchStrategy.HYBRID`; keyword-only search does not support `AUTO`.\u00a0<\/p>\n
The database-resident embedding model is also part of the production contract. The same model and embedding dimension should be used by `OracleDBEmbedder` and the managed hybrid index so query embeddings and indexed memory vectors\u00a0remain\u00a0compatible.\u00a0<\/p>\n
Before publishing an agent that depends on durable memory, test the retrieval path with representative records. Include exact-identifier queries, semantic queries, mixed queries, scoped retrieval checks, and index freshness checks after writes. If the application has many similar records, include distractor memories in the test set so the expected result\u00a0has to\u00a0outrank nearby alternatives.\u00a0<\/p>\n
Teams can also pair hybrid retrieval with custom memory extraction when they need more predictable stored facts. Extraction controls what gets remembered; scope controls which records are eligible; hybrid search controls how eligible memories are ranked.\u00a0<\/p>\n
Conclusion\u00a0\u00a0<\/p>\n
AI agent memory needs more than semantic similarity. Vector search helps agents remember by meaning, but enterprise workflows often depend on exact strings such as invoice numbers, error codes, customer aliases, file names, and transaction IDs. Keyword search helps with those strings, but it can be brittle when users ask in natural language.\u00a0<\/p>\n
Hybrid search gives the memory layer a practical middle ground. It preserves literal identifiers while still supporting semantic recall, so an agent can retrieve both the named object and the context that explains why it matters.\u00a0<\/p>\n
In the companion notebook, one `SearchStrategy.HYBRID` configuration retrieves the expected durable memory across exact, semantic, and mixed query styles. The deliberately similar memory set makes the demo more realistic: the target memory\u00a0has to\u00a0outrank records that overlap on customer, invoice, renewal, or error-code vocabulary.\u00a0<\/p>\n
For Oracle AI Agent Memory, `SearchStrategy.HYBRID`, `OracleDBEmbedder`, `SearchScope`, and `SearchIndexSyncMode`\u00a0provide the core application controls for this pattern. Together, they help developers build memory systems that are scoped, durable, searchable by meaning, and precise when exact text matters.\u00a0<\/p>\n
Run the companion notebook to configure Oracle AI Agent Memory hybrid search, load the deliberately similar memory set, and inspect the ranked results for exact, semantic, and mixed queries.\u00a0<\/p>\n
Frequently Asked Questions\u00a0<\/p>\n
What is Oracle AI Agent Memory?\u00a0Oracle AI Agent Memory is a durable memory layer for AI agents. It lets applications store memories, retrieve relevant context later, and use scope controls such as user, agent, and thread scope so the agent searches only eligible memories before ranking results.\u00a0
\u00a0
Why use hybrid search for agent memory?\u00a0Hybrid search is useful for agent memory because many memories\u00a0contain\u00a0both meaning and exact text. Vector search helps with paraphrased questions, while keyword search helps with identifiers such as issue IDs, SKUs, invoice numbers, aliases, and error codes. Hybrid search combines both signals so the agent can retrieve the right memory and the surrounding context.\u00a0
\u00a0
Is vector search still useful for agent memory?\u00a0Yes. Vector search\u00a0remains\u00a0essential for paraphrase, concept recall, and long natural-language memories. Hybrid search adds exact-text strength instead of replacing vector search.\u00a0<\/p>\n
How do I build hybrid retrieval for agent memory?\u00a0Configure\u00a0OracleAgentMemory with `OracleDBEmbedder`, set\u00a0`SearchStrategy.HYBRID`, choose\u00a0`SearchIndexSyncMode`, store scoped memories, then test exact, semantic, and mixed queries.<\/p>\n
When should I use keyword-only search?\u00a0Use keyword-only search when retrieval is\u00a0almost entirely\u00a0literal text matching and embeddings are unnecessary. Many agent memory workloads need both exact strings and semantic context, which makes hybrid search a better default.\u00a0<\/p>\n
What is the difference between scoped retrieval and hybrid search?\u00a0Scoped retrieval controls which memories are eligible to be searched. Hybrid search controls how those eligible memories are ranked using both semantic and exact-text signals.\u00a0
\u00a0
Why does hybrid search require\u00a0`OracleDBEmbedder`?\u00a0The hybrid path uses Oracle-managed indexing and database-side embedding metadata.\u00a0`OracleDBEmbedder`\u00a0keeps the application embedder aligned with the database-backed retrieval path.\u00a0
\u00a0
Which\u00a0`SearchIndexSyncMode`\u00a0should I start with?\u00a0For notebooks and interactive demos,\u00a0`ON_COMMIT`\u00a0is the simplest starting point. For bulk ingestion,\u00a0`MANUAL`\u00a0gives more control.\u00a0`AUTO`\u00a0is useful when Oracle-managed hybrid index maintenance fits the workload.\u00a0
\u00a0
What should I test before publishing an agent memory workflow?\u00a0Test exact-identifier queries, semantic queries, scoped retrieval, index freshness after writes, and\u00a0behavior\u00a0when multiple similar memories exist. The strongest demos show both exact and natural-language retrieval over the same records.\u00a0<\/p>\n
Resources\u00a0\u00a0<\/p>\n","protected":false},"excerpt":{"rendered":"Use\u00a0Oracle AI Agent Memory hybrid search when persistent AI agent memory needs both semantic similarity and exact text…\n","protected":false},"author":2,"featured_media":130365,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[405,25,7537,1789,6580,7342],"class_list":["post-130364","post","type-post","status-publish","format-standard","has-post-thumbnail","category-agentic-ai","tag-ai-agents","tag-artificial-intelligence","tag-artificial-intelligence-agents","tag-database","tag-developers","tag-oracle-ai"],"_links":{"self":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/130364","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/comments?post=130364"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/130364\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media\/130365"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media?parent=130364"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/categories?post=130364"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/tags?post=130364"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}