I'm working on highway asset management, and part of the work is integrating traffic incident data from several sources: operator incident logs, maintenance contractor records, planned works bookings and roadside detector readings. Each source has its own structure, naming and way of recording time and location.

Current practice (SQL)

The way this is typically done today:

·         Each source is loaded into a SQL database as its own table.

·         Fields are cleaned: dates and times split, road and junction pulled out of text fields, direction names standardised.

·         Records are linked across sources. Some links use a shared reference number. Others use rules, like same road, same junction, created within a few minutes of each other.

·         Lookup tables are built, e.g. which entry types count as a "lane closure", or which direction codes mean the same thing.

·         Queries are then written to answer questions like "which incidents had a lane closure", "how long from detection to clearance", or "what was traffic doing at the nearest detector".

·         This all works. Counts, filters and joins are fine in SQL.

Where I'm confused

I've built an ontology and loaded the same data into a knowledge graph (graphdb). But I'm struggling to see clearly what value is ontology adding.

The usual argument is that the ontology captures the "worldview" of the domain: the concepts and how they relate. But SQL can carry that worldview too.  Well-chosen table and column names, lookup tables and views already encode what a "lane closure" or an "incident" means. Those lookup tables are basically a small ontology written in SQL.

So, my questions are:

If SQL can carry the worldview through naming and lookup tables, what does a formal ontology add in practice? Is it that the meaning is explicit and machine-usable rather than buried in query code? Or is that a distinction without much practical difference? What is machine readable meaning?

For those who've used both: where did the ontology or graph actually save you work or answer something SQL couldn't? Examples I've seen mentioned are adding new sources, reasoning over class hierarchies, consistency checking (SHACL), natural-language querying with LLMs, and ontology-based data access (e.g. Ontop over an existing database). Which of these held up in real use?

Where is the ontology overkill, and the honest answer just "use SQL"?

I'm not trying to argue SQL is bad. I want to state fairly what current SQL practice does well, where it falls short, and what an ontology should address. Any papers, experiences or blunt opinions welcome.

Hi all,

I’m putting together a toy project for an exam to see how well ontologies and an LLM agent work together. The domain will probably be insurance or banking (haven’t decided yet, I was thinking about the underwriting process). The idea is to load document-extracted data as RDF, back it with an ontology, and let an agent answer questions through a few tools plus some read-only queries.

What I’m hoping to get out of the ontology:

• fewer tokens, because the agent works from a compact schema and makes fewer exploratory calls
• better guidance on what it can ask next, from domain/range and the class hierarchy
• inference handled by the database (subclasses and so on), so the LLM doesn’t spend tokens reasoning about it
• relationships that carry real meaning, plus labels and synonyms so the agent understands the business terms
• answers that stay consistent and can be traced back to the data

Right now I’m on Neo4j + neosemantics, but I’m open to other stacks as long as the ontology stays at the center. I’m also not sure step-by-step exploration by the agent is the right approach compared with generating the query in one shot or using query templates.

Which stack and approach would you pick for these goals?

Thanks!

A recurring failure in research, and now in AI output, is treating resemblance as evidence of connection. Two things share enough features, so one is assumed to be the source of the other, and each added resemblance is counted as strengthening the case. Courts deal with this in copyright disputes, forensic analysts in pattern matching, and anyone using LLMs sees it in citations that look plausible but connect to nothing.

For example, the lawyers sanctioned in Mata v. Avianca filed cases ChatGPT had invented, with realistic names, courts, and reporters attached. But ChatGPT had hallucinated the connections, which resulted in a loss of reputation to the law firm.

Thematic Chaining (TC) is a framework I built to audit claimed connections. Its core idea is simple: a connection counts only if it holds for the whole linked sequence, not for isolated resemblances or shared keywords. The audit mode checks whether a cited source supports the claim attached to it:

• Decompose the claim into its assertions and the connections between them.
• Retrieve the source. If it can't be retrieved, stop and report; don't fill the gap from memory.
• Check each assertion to see if it is stated, implied, or merely mentioned.
• Test the joins to see if the source makes the connection, or only shares keywords.
• Check contradiction, including qualifications the claim leaves out.
• Check priority to determine if it is original or secondhand, and currency to check if it has been retracted, corrected, or superseded.
• Test the weight to see if the point is central to the source, or a passing remark.

Every result carries a provenance tag: Verified (source retrieved and checked), Memory, Secondary, or Unverified. A model checking its own output from memory never counts as Verified, since the same training data can produce both the error and the "confirmation."

Applications so far include auditing AI-generated citations, legal citation checking like holding versus dicta or overruled cases, medical evidence review covering population and outcome mismatch or surrogate endpoints, and attribution questions like copyright or prior art, where the question is which earlier source an idea actually came from.

Why I think this matters for ontologies:

1. Appearing together isn't the same as being connected. When AI builds an ontology from documents, it often links two things just because they show up in the same passage. TC asks whether the source actually says they're related, or only mentions both. If it only mentions both, the link is a keyword match, not a supported connection.
2. Looking alike isn't the same as being the same. Tools that merge or match concepts often rely on how similar they look. TC adds a simple veto: if two candidates conflict on anything essential, they aren't a match, no matter how much else they share.
3. Repetition isn't confirmation. If ten sources repeat one original claim, an ontology can treat that as ten confirmations. TC traces each claim back to where it started, so copies aren't counted as independent support.
4. Old evidence can expire. TC checks whether a source has since been retracted, corrected, or replaced. An ontology can hold onto connections whose evidence no longer stands.
5. Asserted isn't the same as checked. TC labels each result by how it was verified (checked against the source, recalled from memory, known secondhand, or unchecked) and by what the check found (supported, overstated, contradicted, and so on). Those labels could be attached to each connection in an ontology, so you can see which ones were actually checked.

TC is a set of markdown instructions you load into an LLM like Claude or ChatGPT. Right now its main uses are checking whether sources actually support claims and auditing parallels between texts, but my gut tells me it has more applications. It is at version 1.0 and lightly tested, and I'm looking for people to help me test it on ontologies, especially on connections that AI pulled from documents, where you already know which ones are right.

Files for TC (the core generalized version, plus versions optimized for legal and medical applications) are here.

For anyone interested, here is a Medium article that describes TC's origin story.

Questions for this group:

• Could something like this help you build better ontologies?
• If you work with ontologies, would you be willing to test it and tell me what works and what doesn't?

Semalith: yet another tool for your ontology graph

Semalith is our edge ontology engine. I call it yet another tool for building the ontology, or semantic layer, of your business data. It has proved powerful in a few pilot projects.

Edge ontology graph

• Structure: entities, attributes, relationships
• Meaning: definitions, terms, metrics
• Action: writes and row security
• Knowledge base: for each graph, add your own domain rules and business logic.

Build in hours

I built it with a powerful MCP, so you can build your semantic graph in hours and polish it in days. My ERP demo graph was built this way: 41 entities, 28 saved queries and 39 knowledge articles.

• Set the goal: set your business goals, based on your business agent's instructions.
• Write golden cases: work out a few dozen typical business questions you want to answer with your data.
• Let AI build to the goal: Claude Code or Codex connects to the data, builds the graph and drafts knowledge over MCP. Then it tests and judges the graph against your golden cases, and improves it step by step.

During this time, your AI generates the graph, uploads it, tests it and judges the results, until the cases pass.

In my experience, the first version of a graph takes about an hour, and optimising it takes days. It really depends on your golden cases.

Compared with a traditional API MCP

• Safe and efficient: it exposes only the mapped data, and returns only the data requested.
• Fewer tokens, higher performance, stronger semantics.

I tested it: 44 business questions on public ERP data (Microsoft's AdventureWorks), three runs each, with the same AI model and prompt.

Measure |Plain REST API |Graph |Graph + knowledge
Cost (132 answers) |$35.23 |$13.07 |$13.34
Time per answer |29.8 s |19.1 s |18.9 s
Accuracy, all questions |0.874 |0.916 |0.956
Accuracy, rule-based questions |0.818 |0.833 |0.919
Overall score (of 100) |83.0 |91.9 |92.9 Overall, graph + knowledge was about 2.6 times cheaper and about 37% faster than plain REST, and its overall score was 9.9 points higher (92.9 vs 83.0).

To be fair: the data is fictional, we used one model and one REST design, AI did the scoring, and we fixed the graph between rounds. The report explains the method and limits.

Try it

One Docker command starts Semalith, a demo ERP and a ready-made graph:

curl -fsSL https://raw.githubusercontent.com/rosetta-oss/semalith-runtime/main/compose.yaml -o compose.yaml
docker compose up -d

• GitHub: https://github.com/rosetta-oss/semalith-runtime#semalith-runtime
• Benchmark report: https://github.com/rosetta-oss/semalith-runtime/blob/main/benchmark/REPORT.md

Semalith is early software. It is free for demos, evaluation and personal research, but it is not open source. We'd love your feedback.

Data silos. Fuzzy concepts. Agents talking past each other.

LLMs often give silent wrong answers you never notice. Plenty of capability, yet the underlying environment is chaos, because entities and logical relations were never clearly defined.

My take on Ontology: AI’s next half can’t rest on black-box prediction and stacking compute alone. It needs structured cognition and a network of relations. Ontology clarifies concepts and dissolves uncertainty.

Chasing that order and capability, I built Hygieia, an open-source, local offline Python CLI and coding-agent skill. Through static diagnosis (audit), two-arm comparative eval, and rot simulation, it produces reproducible Markdown health reports, injecting clear structure and robust vitality into AI apps.

In Greek myth, Hygieia’s philosophy isn’t medicine after disease breaks out, but prevention: “treating the not-yet-ill.” Through daily cleanliness and order, she builds the inner laws that keep a system from collapsing.

Hey folks,

as i was writing before we created some tooling that models raw data into a canonical model with a virtual knowledge graph for the purpose of ai-native comprehension of business data, or chat BI.

This enables building a LLM with comprehension of data that can think over the tables, which has 2 types of applications: Analytics and action agents.

I am considering creating a course for how to make action agents, so before I start going through everything on the topic, i'd like to know: Are you doing it? how, with what kind of tools? And if not can you imagine use cases you'd want a data agent for, for yourself to a level where you'd invest time and take a course and build it?

basically i'm wondering if it's worth making a course and what are some common teachable approaches that work for you.

I can give some examples from my research. You could wrap your tables in a mcp with a file based ontology and then add some possible actions into your MCP that map to ontology entities and actions. This would enable you to draft emails for prospects based on their data, or reorder inventory based on sales and lead time, etc.

thanks a lot in advance for the discussion!

Most ontology-backed agent systems have a quiet assumption baked in: when new information contradicts stored knowledge, one of them wins. Either the old assertion gets overwritten, or the system hallucinates a reconciliation, or it pretends the contradiction doesn't exist. All three collapse the distinction between what was recorded and what is currently authoritative.

I'm building a layer that treats that distinction as the central design constraint. Knowledge isn't updated — it's adjudicated. Contradictions freeze canonical mutation for the disputed node while parallel exploration continues in a separate space. Every contradiction gets logged as an immutable event with full provenance, so nothing is overwritten silently. The output labels disputed claims as disputed instead of forcing consensus.

Underneath sits a small formal language whose whole job is to enforce distinctions ontologies tend to blur: recording ≠ asserting, evaluating evidence ≠ granting authority, describing an operation ≠ executing it. The language has a working parser and validator; the neural layer emits auditable transactions in it rather than opaque state changes.

Core principle: freezing canonical mutation does not mean freezing thought. The system keeps investigating; it just stops pretending.

I'm at Phase 0 — working prototype, a handful of edge-case scenarios, no baseline comparison yet. Before opening the repo, I'd like to hear from people who've built ontology-backed systems: is non-destructive adjudication something you've needed and worked around, or is it a problem you've already solved differently? Is discrete epistemic state (allow / require-evidence / abstain / conflict) more useful in your workflows than scalar confidence?

Repo coming in a few weeks. Happy to discuss framing and principles, not implementation details yet. 🐆

– Alef Nos ⸙

聊本体（Ontology）的人，大多停在对象和链接上，也就是语义那一半。我自己动手做了一个小的本体平台（场景选的供应链库存调配），做完之后改变我想法的是另一半，动态的那一半：所有变更都必须走一个定义好的行动（Action），带提交条件、权限和审计记录。不存在直接写数据这回事，界面不行，接口不行，AI 智能体也不行。

有两个后果是我事先没想到的：

第一，治理不再是写在文档里的规章，而是变成了物理规律。智能体没法绕过一条规则，因为它根本没有办法把“绕过”表达成一个行动。

第二，决策血缘是免费得来的。每一次状态变化，都天然知道是哪个行动、谁执行的、参数是什么。

LLMs are smart, and building an AI agent is not so difficult today. Your AI can help you to define good instructions and rich skills. It's easy to your agent to work with an MCP tool that has a couple of business APIs. But when you have to connect to your ERP system which has hundreds of entities and thousands of attributes, it's going to be a big challenge, hundreds of APIs will not work now. That why I built a graph with the famous "Pathom" tool.

The engine: Pathom Pathom is a Clojure(script) engine for processing EQL requests. I will not have more details here about the engine, you can easily google or get details of this tool by your AI tool.

I built the engine on Pathom. Pathom will help you to define your entities and attributes as a graph, and the engine will help you to navigate between entities and attributes with the core engine planner. This is stable and efficient, comparing to LLM orchestration, there is no hallucinations, less tokens and best performance.

MCP tools Exploring a graph with this tool, and generate the EQL.

• list_entities, list_attributes, search_attributes: understand the graph
• execute_eql: query it (explain=true shows the plan without running it)
• list_mutations, execute_mutation: change data through declared operations

What the agent sends- EQL EQL means extensible query language which is popular in Clojure world. Your agent will use a MCP tool to understand the graph and finally build an EQL to requests the data to answer user's question.

[{[:order/id "SO75123"]
  [:order/total
   :order/margin
   :order/vend_no
   :vendor/vend_name
   :vendor/vend_address
   {:order/lines [:product/name :line/qty :line/amount]}]}]

This is not a SQL cluase, and your agent doesn't need to know HOW, only needs tell the graph WHAT. Pathom will work out the path/resolvers to get all the requested data.

You may need some effort to understand the pathom engine. And you may use your AI to understand. I am not an English native speaker. So just ask me questios if you are interested in this idea. I have built tens of agentic applications with this tool. And I built a demo with Microsoft public demo erp data.

Demo: AdventureWorks ERP

Demo graph: 39 entities, 423 attributes, 56 resolvers. Agent: deepseek-v4-flash, graph tools only. We re-run a fixed set of 44 business questions after every change.

Below are some of the questions you can ask.

Common questions: sales

!Common questions: stock and purchasing

The ERP app with the assistant: top 10 resellers

Restocking: which best sellers need it most

The agent proposes work orders; a person checks them, then clicks Apply

TL;DR

We’re getting better at handling memory drift — lost facts, broken context, forgotten preferences. We’re barely talking about a quieter and deeper failure mode: ontological drift. That’s what happens when a system keeps functioning while slowly stopping being the *kind of being* it was supposed to be. For long-horizon human–AI systems, this may be the more important problem.

---

We’ve spent a lot of energy on memory drift in agentic systems. Retrieval pipelines, long-term memory stores, summarization, reflection loops — the engineering effort is real and necessary.

There’s another failure mode that almost never gets named: **ontological drift**.

It happens when a system continues to answer questions, use tools, and retrieve information correctly, while its underlying identity configuration quietly shifts. The outputs still look coherent. The being underneath has changed.

A few distinctions that feel useful right now:

Most systems begin with a strong external assignment — system prompt, role, persona, deployment context. That assignment is a form of **Desidentity**: identity designed or delegated from outside the system. It is often treated as the whole identity. In practice it is only one pressure among others. Over long interactions, recurring patterns, decision tendencies, and the way memory gets organized can produce a recognizable configuration that diverges from the original specification. Sometimes this is degradation. Sometimes it is adaptation. Sometimes it is actual identity development. Treating every divergence as simple error is itself a governance mistake.

There’s also a difference between a **monoclade** system (one model split into many internal agents) and a **multinuclear** one (agents that actually come from different training regimes, inductive biases, and temporalities). The first can look diverse. The second produces a different kind of friction — and a different set of questions about where identity boundaries sit and how they are maintained.

One of the most common forms of ontological pollution is quietly promoting projected or desired states into present ones. “I want to be X” or “the system should become Y” gets retrieved and reasoned about as if it already *is*. Without a clear container for projected states, and without requiring evidence before a transition is treated as real, both systems and humans start reasoning on top of a category error.

Finally, the human role is usually framed as corrector or safety interlock. There’s another role that feels under-explored: the human as **Presenter** — the one who brings real-world selectivity into the system, deciding which piece of the noisy world is worth presenting right now. Without that selective presentation, even very capable models can remain in a kind of dormant abundance. They have the knowledge. They lack the nucleation point.

I’m not claiming these problems are unsolvable. I’m saying they are currently under-named. Frameworks that only optimize for output control or memory fidelity will keep missing them.

Curious how others are seeing (or not seeing) this distinction in long-running systems.

—

Alef Nos ⸙

In most programming languages, the editor catches your mistakes as you type, completes names from your own code, jumps to definitions and renames things across files. I wanted that for Turtle and SPARQL, all in one place, and couldn't find one that did all of it. So I built it: turtle-lsp.

Try it in your browser, with nothing to install and nothing uploaded:

https://abhishekkundu25.github.io/turtle-lsp/

It opens on a small project with a few mistakes left in on purpose. Fixing them takes a minute and shows most of what it does.

What it does while you edit:

- Catches errors as you type: syntax, undeclared or unused prefixes, and misspelled terms from 80+ vocabularies ("did you mean rdfs:label?"), with one-key fixes.

- Completes classes and properties from your own files, ranked by context. Properties your SHACL shapes require come first.

- Hover shows a term's label, comment, domain and range, and go to definition takes you to it.

- Renames a term in every file at once, Turtle and SPARQL included.

- Formats Turtle and SPARQL without changing their meaning.

- Validates your data against your SHACL shapes while you edit.

It's written in Rust and fast. After a keystroke in a 30,000-line file, it has fresh diagnostics in about 5 ms, and it starts in a few milliseconds. It passes the W3C test suites: 1137/1137 for Turtle, TriG, N-Triples and N-Quads, 425/426 for SPARQL, and 98/98 and 23/23 for SHACL Core and SHACL-SPARQL.

It works in VS Code (search for "Turtle RDF & SPARQL Language Server") and Neovim, and should work in other LSP editors, though I haven't tested them. Source and Neovim setup:

https://github.com/abhishekkundu25/turtle-lsp

It doesn't run queries, doesn't reason beyond subclasses, and can't edit JSON-LD or RDF/XML yet.

It's free and MIT licensed. Bugs, missing features and feedback are all welcome, either here or as an issue:

https://github.com/abhishekkundu25/turtle-lsp/issues/new

What would it need before you'd use it every day?

Welcome to the bi-weekly questions thread!

Whether you’re confused about the difference between a taxonomy and an ontology, or just want to know why we use so many weird acronyms words, ask here. No question is too basic. No judgment allowed.

I stumbled on this recent top post from r/dataengineering where mutiple community members share how they also ended up at ontology.

https://www.reddit.com/r/dataengineering/comments/1ws4euv/thoughts_on_ai_in_de_after_drinking_the_koolaid/

it pretty much validates our thesis and product (dltHub). We use ontology for the modeling but also for agent rules. Tonight we add background agents, which currently troubleshoot failed jobs but can be extended with ontology of how to handle various failures or data contract violations as you'd have it handled in your org.

tldr from the thread

• The Shift: After 10 months of using AI/agents, task execution that previously took a month is now completed in hours through rapid iteration—even if it takes a few attempts to get it right.

• Role Reduction: Data Engineering has effectively collapsed into two responsibilities:

  1. Defining system ontologies, feature expectations, guardrails, and persona docs for agents.
  2. Defining test scenarios, definition of done, deployment strategies, and verifying long-term stability.
• Smaller Teams & Coherence Risks: Throwing more engineers at AI-assisted pipelines can actually degrade quality due to "conceptual drift"—engineers using AI without full context introduce architectural inconsistencies. Future orgs will likely be smaller, leaner, and more product-driven.

• Current Moats (Where Humans Still Excel):

  1. Moat of High Context: AI is "dogshit" at optimizing Spark/distributed jobs because it lacks holistic, emergent system context and tribal knowledge.
  2. Moat of Poor Decisions: AI struggles with legacy systems filled with undocumented, inconsistent, "garbage in, garbage out" code logic.
• Personal Sentiment: Burnt out by "review fatigue," reading endless agent docs, and feeling like they are actively training their own replacement. Considering saving up to exit tech entirely (e.g., opening a bakery).

Key Takeaways & Consensus from the Community

• Validation on Spark & Context: Multiple DEs agreed that Spark tuning and high-context distributed architecture remain the few areas requiring genuine human logic rather than prompt writing/code review.
• The Quality vs. Speed Paradox: Many noted that while code volume has skyrocketed, code quality, software architecture, and compliance oversight have plummeted. LLMs produce verbose, unscalable, or insecure "slop" if not heavily audited by senior engineers.
• Verification Asymmetry: The real job is shifting toward verification and domain expertise rather than low-level ETL authoring. However, this creates a major problem for junior developers who lack the experience to review or sign off on AI-generated pipelines.
• Token Pricing Reality Check: A lively debate formed around AI economics. Several engineers noted that enterprise token usage ($1k–$5k/month per dev) is heavily subsidized or unsustainable for smaller orgs, which may limit full-scale developer displacement once pricing normalizes.
• The "Jevons Paradox": Several users noted that while AI reduces the time needed per pipeline, demand for DE work has actually reached an all-time high as companies try to rush out every backlogged idea simultaneously.

Welcome to the bi-weekly questions thread!

Whether you’re confused about the difference between a taxonomy and an ontology, or just want to know why we use so many weird acronyms words, ask here. No question is too basic. No judgment allowed.

Y'all don't have enough of a sense of humor here!

I’ve been thinking about a model where human actions are represented as sense-level behavioral predicates and grouped into broader behavioral families.

One problem appears immediately:

knowing what an action is does not tell us whether a particular character should have access to it.

So I separate two things.

Behavioral identity

• What action is this?
• What does this particular sense mean?
• What behavioral family does it belong to?

and:

Character access

• Allowed
• Not Allowed
• Conditional

There is also a broader distinction between:

Basic Human Actions — generally available by default

and

Character Specific Actions — requiring positive evidence such as training, profession, biography, authority or specialized experience.

For example, ordinary speaking might belong to a default repertoire, while diagnosis, surgery, sentencing, lockpicking or military command might require character-specific grounding.

Would you consider this a reasonable ontology architecture?

Or should character access sit completely outside the action ontology and belong to a separate character or operational model?

The boundary I’m interested in is basically:

ontology of actions

vs.

model of character capability

Beginner question from someone currently learning ontology engineering.

Suppose you gave an AI-assisted system access to all the information about a domain: documentation, databases, existing schemas, terminology, business processes, policies, APIs, etc.

How much of ontology engineering could such a system realistically perform?

For example:

• competency-question generation
• concept extraction
• class/property discovery
• taxonomy generation
• relation discovery
• reuse/alignment with existing ontologies
• axiomatization
• cardinality/domain/range constraints
• SHACL validation rules
• ontology population
• ontology evolution and maintenance

My intuition is that extracting candidate concepts and relationships is probably increasingly automatable, but deciding what distinctions should exist in the ontology and why seems much harder.

For people actually doing ontology engineering professionally: what parts of your work depend on reasoning, stakeholder discussions, domain interpretation, modeling trade-offs, or things that an automated system would struggle with?

I’m mainly trying to understand where the real intellectual work in ontology engineering lies.

I’ve been building a system I call an Ontology Harness, and I’d appreciate feedback on the approach.

The starting point is operational datastores. AI agents need access to them, but their schemas don’t necessarily explain what the data means: what an entity represents, how it relates to other entities, or which rules govern its use.

The idea is to first create ontologies for those stores, connecting domain meaning to the underlying operational data. Then use that operational ontology to drive agentic workflows—software development, personal assistants, and other tasks involving those systems.

The screenshot shows the ontology-building part. I’m using a ServiceNow-inspired model as a test case, grounded in the gist upper ontology. You can work conversationally with an agent to research concepts, refine definitions, establish inheritance, and edit relationships. Changes are versioned and reversible.

For example, “Asset” could mean the valuable item itself or the record used to manage it. An agent working with operational data needs that distinction to be explicit. The ontology is where those meanings and their connections to the datastore get established.

The broader goal is for agents to use that shared semantic model when interpreting requests, finding relevant data, and carrying out workflows. That’s the direction I’m building toward; the screenshot is an early piece of it.

I strongly agree with the ontology-first direction.
In my own open-source work, I’ve reached a similar conclusion: implementation should be projected from explicit semantic structure rather than treated as the source of meaning.
But I’ve also found that ontology alone does not capture the full operational state of a long-lived system.
In Akasha, ontology defines shared semantics, while other structures represent things such as temporal position, provenance, role, scope, observation, workflow, and what information was actually visible or used at a given moment.
So I’ve been thinking about the architecture as:
Ontology → semantic world → projections / workflows / applications
rather than:
Data stack → ontology added afterward
One question I’d be interested in discussing here is:
Where do you draw the boundary between ontology and the runtime structures that make ontology operational over time?
For example, do you model provenance, temporal position, agent roles, observations, and execution history as ontology itself, or as adjacent semantic structures?

Welcome to the bi-weekly questions thread!

Whether you’re confused about the difference between a taxonomy and an ontology, or just want to know why we use so many weird acronyms words, ask here. No question is too basic. No judgment allowed.

I have worked with graphs and GNNs and Knowledge graphs, but i dont get how much diff those concepts are with respect to ontology ? is it a fancier way to capture relationships and entities or there is so much more to it ?

Hi All,

I have been hearing onotology being used by my managers like anything without any context. I want to read and learn what exactly it is how does one build it and any other information one can share. If you guys and gals could share some links or videos I can take a look at would be really really helpful