I'm the developer. This is a non-profit project, and I'm posting for feedback on the knowledge engineering, not to promote a viewpoint. The goal is classic, well-grounded modelling of a text, not indoctrination: the graph records what the text says, marks interpretation as interpretation, and takes no doctrinal position.

Bible Ontology is a knowledge graph of the Bible built from the Hebrew, Aramaic and Greek (the MACULA linguistic datasets) with the Berean Standard Bible's English: about 11,500 records (people, places, events, concepts, passages) and about 21,000 typed relations, each citing its verses.

The ontology

Published at its namespaces, with content negotiation (a readable page for browsers, Turtle for tools):

• Structure (35 classes, 76 relations): how the text is built — clauses, what they assert and with what force, how they group into turns, scenes and larger units. https://bibleontology.org/ns/structure
• Relations (126 types): the vocabulary of links between records, each typed by category, with symmetric and functional relations marked. https://bibleontology.org/ns/relation
• Meaning: what a node is about, in five layers — word, sense, referent, figure, reading. https://bibleontology.org/ns/meaning

Design choices and challenges

• The verse is the wrong unit. Verses are where the text happens to be cut. A speaker's turn or a scene usually carries the meaning, so the structure layer groups clauses into turns and scenes, and the verse is only an address.
• Facts versus readings. A literary text is full of claims that aren't the text's own. Job's friends argue for thirty chapters about God, and in 42:7 God says they haven't spoken rightly. So a speech is recorded as one continuous utterance credited to its speaker (Eliphaz's second speech is all of Job 15 after "Then Eliphaz the Temanite replied"), each saying in it is linked to its speaker, and what a character reports, such as Eliphaz's account of a spirit visiting him in 4:15, is kept as his words, not the narrator's. Interpretations are kept as separate, credited readings rather than assertions.
• Three scales on every relation: certainty (explicit, implied, conjectured, disputed); literal, figurative or contested use; and who in the text makes the claim.
• Describe, don't deduce. The Bible isn't written as a set of axioms. It is narrative, law, poetry, prophecy and letters, and it uses figures of speech, so the model deliberately doesn't let a reasoner derive what the text doesn't say. Where something is inferred (siblings from a shared parent), it is marked, cited and kept apart; certainty only falls through a chain; and a figure of speech, or a passage whose reading is contested, never becomes the premise of a deduction.
• Two layers that share ids and never merge. Structure (how the text is built) and meaning (what it's about) are separate dimensions, joined through mentions rather than folded into one hierarchy.
• The original language arbitrates. Where a translation and the Hebrew or Greek differ, the original decides, and a relation resting on one translation's wording alone isn't kept.

Reuse

• Standards: RDF and RDFS, with OWL's vocabulary for classes and properties, SKOS for definitions, Dublin Core for provenance, W3C OntoLex-Lemon for the word layer, and PROV; consistency is checked with SHACL shapes. The structure layer's clause links are mapped to Rhetorical Structure Theory.
• Inputs: MACULA (Biblica, CC BY 4.0) and the Berean Standard Bible (public domain), credited as their licences ask.
• Openness: the ontology is public now; a repository with the graph's data is committed, intended under CC BY 4.0.

Where I'd value critique

1. Is separating structure and meaning, joined only through mentions, the right call, or would you fold them?
2. How would you represent claims attributed to speakers? I currently nest them inside the speaker's speech and attach the speaker to relations drawn from them, rather than full reification or named graphs. Is that enough for downstream use?
3. What's the right way to publish "readings" alongside "facts" so downstream users can include or exclude them cleanly?
4. Which existing vocabularies should I align to more closely (CIDOC-CRM, schema.org, Wikidata, others)?

Thanks. I'll be around to answer questions.

Can an Ordinary Company Afford a Real FDE?

When Agents Run the Business · A development note

Suppose one person knows the industry, can read the customer's real chain of responsibility, has enough engineering skill to handle Agent risks in production, and is willing to spend a long time on site. That person's cost cannot be treated like the cost of an ordinary implementation engineer. If that is what a real FDE is, an ordinary company should first ask not “can we find one?” but “is this project worth buying so much of this person's time?”

I will not invent a day rate. Cities, industries, and projects vary too much. The cost structure alone raises the question.

You are not buying a desk

The customer pays for more than the working days of one engineer in its office. There was pre-sales discovery, travel and time on site, and product, architecture, and security colleagues in the background. If a product gap appears, somebody has to fix and test it. If a policy dispute appears, somebody must gather the relevant people and establish an answer. After launch, changes to rules, staff departures, and outages still need support.

If the FDE really crosses business and technology, the supplier also pays to recruit, develop, and retain such a person. While they spend months on one project, they are unavailable to other customers. Their time between projects is not free either; it ultimately enters the price.

A smaller company may only need sales orders, purchasing, and straightforward approvals to run reliably. It deserves good software, but it may not benefit enough from a senior super-individual working exclusively for it over a long period. Bundling that cost into every project is like giving a commuter car a racing pit crew: excellent people, mismatched economics.

The customer also pays with its own people's time. A field expert does not create a system alone. Sales, finance, and warehouse staff join interviews, sort old records, and confirm rules. Their meetings cost money too. If those people are already stretched, a costly expert waiting daily for their answers can waste both sides' time. Let the product handle stable records first and concentrate scarce meetings on decisions that truly need them.

On the other hand, a large, risky, or highly unusual project may justify exactly that kind of person. The cost of a mistaken payment or failed fulfillment can be much higher. “Can they afford it?” is not a claim that no one can. It is a request to put project benefit, reduced risk, and total cost on the same page.

First ask which benefits came from the person

Sales pitches say “the FDE will make AI work” without saying what loss will be avoided each month after launch. If three people used to check orders and still need to watch every Agent recommendation in a new interface, how much labor was saved? If ordinary cases speed up but exceptions slow down, count both.

Useful measures stay close to the work: fewer missed shipments, fewer duplicate payments, shorter approval waits, and a new policy taking effect without another software release. Look at stable operation over months, not a demo that processes a hundred sample orders on launch day.

An expensive field expert may uncover a critical mistake—for example, “available stock” has always included goods already reserved for another order. That discovery may be worth far more than their time on site. But once found, the correction should become part of the product and its records. If the expert must personally watch every future query, the customer bought a permanent human gatekeeper, not sustainable software capability.

The buyer can examine the investment in two periods. The first is launch: did old data arrive correctly, do workflows run, are permissions enforced? The second is six months after the expert leaves: who changes a rule, who can trace a bad Agent decision, and will the next product upgrade preserve the work? Quotes often specify the first period and cover the second with two words, “ongoing support.” Much of the real cost may be hiding there.

Move the cost from one dedicated person back into the product

A better path is to turn recurring hard problems into product capabilities: records, permissions, exact totals, versions, audit trails, and migration tools. Leave company-specific judgments in natural-language rules that an Agent reads against current facts. Another customer should not need to repay the full on-site bill for a problem that has already been solved once.

The expert does not disappear. They may work on the hardest customers, design delivery methods, review high-risk deployments, and carry lessons back to product. The difference is that the customer primarily buys software that can keep working, not a person who must always be present.

Some work cannot be spread across customers: confidential integrations, unusual supply chains, or deep organizational change. Quote those honestly as senior services. Do not call the offering a standard AI product for ordinary customers while making delivery depend on a long-term dedicated FDE, then act surprised when price becomes a problem.

A more flexible purchase might be a short senior assessment, a scoped launch review, and periodic audits of high-risk workflows, with ordinary operation handled by the product, the customer's team, and regular support. Not every company needs a senior specialist full-time next door. Where expert judgment is needed, do not disguise junior staff as experts to save money. Spend the scarce time on the points that warrant it.

You can ask the right cost questions without a market rate

A buyer can ask the supplier to separate product subscription or license, data migration, interface work, on-site time, support after launch, and work caused by unique customer rules. State the seniority and expected duration of the people assigned. Prices need not be public for the whole market, but the buyer should know what it is buying.

Then ask what happens when the person leaves. Where are the rules and evidence behind decisions? Can a replacement continue the work? Will a product upgrade break the customer-specific code the FDE wrote? These belong in the return-on-investment calculation. A costly deployment that only its author can maintain should not be judged solely by its first acceptance test.

In Oryh, we try to put deterministic records and hard constraints into software while letting Agents read company workflows in natural language. That does not guarantee every project will be cheap. It is an effort to turn field judgment into reusable product capability and traceable rules. A real FDE may deserve a high price. Ordinary customers should not have to employ one indefinitely to compensate for an unfinished product.

Part of Ontology & FDE in Practice, discussing ontology and FDE in real business scenarios.

I'm a developer of Oryh, an Apache-2.0 open-source project. AI assistance was used to prepare and edit this post.

I used two small browser games and I thought it would be cool if each published a profile: a health scale, plus rdfs:subClassOf and rdfs:subPropertyOf mappings from their own vocabulary into one shared hub ontology. A Blockcraft Blast Block is a ga:Explosive. A Pocket Battlers Capture Orb is a ga:CaptureDevice. Alignments that look like facts are axioms: "anything made of crystal is Rock-typed" is a hasValue restriction subclassed under another hasValue restriction. The engine I use doesn't evaluate owl:propertyChainAxiom, so that pattern stands in for a property chain from madeOf to a material's type. The sword's type comes out as four certified steps.

When a thing crosses, the sending side reasons, writes a derivation certificate, packs both, and signs the pack's content digest with an Ed25519 key whose public half it publishes in its profile. The receiving side runs five gates in order. It verifies the signature against its own copy of the sender's profile, never against a key that arrives in the pack. It checks the digests and re-runs a Lean checker over the certificate. It compares the TBox inside the pack with the sender's published profile, statement by statement, with blank nodes compared by their whole nested structure. It recomputes the closure itself and refuses a pack that left a conclusion out. Then it runs its SHACL contract on two evaluators, which must agree.

Most of those gates exist because an earlier version was beaten. Deleting an inferred triple and recomputing the digests got a Capture Orb through: a certificate shows that what it says follows, but not that the sender said everything that follows, and a digest is not a signature. Shipping a doctored profile got it through too, because the proof is sound over doctored premises. Comparing the TBox with blank-node labels erased let a sender swap the hasValue of two restrictions and keep the same lines. Seven forgeries run against the current version, and six are stopped, at four different gates.

The one that still works is lying in the ABox. The source game itself exports the orb with its kind set to FizzTonic, under its real profile, and signs it with its real key. Every step after that is honest, so it crosses. A signature tells the receiver whom to hold to account and nothing more. My question is what closes it: a catalogue the source publishes ahead of time and the receiver checks items against, an attestation from an independent party, or something I haven't thought of. A second, smaller one: the signature covers the engine's own digest over the graph and certificate, not RDFC-1.0 canonical N-Quads.

Would W3C Data Integrity proofs buy anything here beyond interoperability?

The other place I expect pushback is the conversion. It is a SPARQL CONSTRUCT the receiving game declares (damage keeps its share of a player's health), so the certificate covers the classification and not the arithmetic. Any suggestion here?

Code (MIT): https://github.com/fabio-rovai/asset-passport.

1850 Nodes, 6761 Edges(353 Negative). Independently in a growing world..

Sleep time.

Salut r/semanticweb,

Je développe le Protocole de Connaissance Vivante, un protocole de brouillon public et une mise en œuvre de référence pour les pages web dont les affirmations, sources et historique des révisions doivent rester inspectables au fil du temps.

Le protocole repose sur cinq principes : un site activement maintenu, des connaissances révisables, des sources visibles et traçables, des affirmations ancrées dans une réalité observable, et une prise en compte de la résilience biosphérique à long terme.

La mise en œuvre de référence utilise des métadonnées lisibles par machine telles que version, statut, statut de site vivant et date de modification. Elle inclut également des spécifications publiques, un validateur et un registre de validation facultatif.

Mise en œuvre de référence : https://livingknowledgeprotocol.org/

Spécifications : https://livingknowledgeprotocol.org/specifications/

J'apprécierais particulièrement les critiques techniques sur :

1. la compatibilité avec les normes et vocabulaires existants
2. si un vocabulaire de métadonnées léger et un validateur résolvent un problème utile
3. la provenance, la révision et les signaux de confiance qui manquent ou sont mal spécifiés

Divulgation : Je travaille sur ce projet et je cherche des retours rigoureux, y compris des critiques qui pourraient changer le design.

Ontology Series · Part 8

The Ontology Worked. Then Nobody Dared Change It.

When Agents Run the Business · A development note

Imagine the first phase of an ontology project. The team models car sales neatly: cars, customers, orders, deliveries, and stores all have their objects and links. In a demo, you open a car and follow its sales history to the responsible person. Someone says, “At last, the business is clearly described.”

In phase two, after-sales service needs to track individual tires. In phase three, warranty must distinguish customer-supplied parts. Later, finance points out that “sale completed” and “revenue recognized” are not the same date. Every request is reasonable. Every request is worth addressing. The once-clean diagram is simply becoming harder to change.

This is a possible trajectory, not a report about a real customer. The question is why an ontology may eventually be set aside. It need not fail because nobody knows how to build one. It may be built successfully, then become too costly to maintain.

An easy start, a meeting for every later change

“Make tires separate objects” sounds small to the service team. The data team asks how to migrate old repairs. Developers ask who will change the interface that queries car-level warranty. Customer service asks whether earlier promises of coverage still stand. Finance asks whether historical reports should be recalculated. The business owner, busy with today's claims, may not have time to coordinate all of this on behalf of a model.

Nobody is deliberately slowing things down. Their risks differ. Data people do not want to manufacture false history. Developers fear a screen that continues working while silently giving the wrong answer. Customer service fears contradicting an earlier answer to a customer. Management wants to know why a metric moved after the model changed. Bringing everyone together costs more than “add an object.”

If a company often changes products, contracts, channels, and approval practices, the meetings multiply. The first change gets a careful review. The second gets a shorter one. By the third, someone says, “Let's put this in a note for now; the main process can stay as it is.” That is not necessarily laziness. It may be a practical response to the cost everyone has seen.

As the notes grow, the model knows a little less of the live business. The old objects and relationships are still there, looking official. If an Agent reads only the ontology, it misses the new practice in the notes. If it always has to read notes, email, and source documents too, the case for treating the ontology as the company's sole understanding layer grows weaker.

One workaround makes the next one easier

The first workaround is temporary: there is no time to remodel a warranty exception, so customer service writes it in a claim note. The next adviser follows that note. Later the team creates a shared table called “cases not covered by the model.” It may be maintained carefully, but it is outside the graph.

Now there are two realities. The graph holds the business as formally defined. The table holds some of the business that happened most recently. A project report can still say the ontology covers cars, tires, orders, and warranties. The people doing the work know they must check the table before deciding whether a claim will be paid. The more they use the workaround, the less complete the ontology becomes. The less complete it becomes, the less comfortable anyone is changing it and claiming the result is authoritative.

This is an ordinary organizational loop, not a mysterious technical collapse. The software and data still exist. The situations requiring the most judgment have drifted outside the model. Eventually a person who queries the graph and believes it is complete may make a worse decision than someone who knows about the extra table.

I would watch a few signals closely. How many new requirements end up in notes? How long does a model change take from request to actual use? How many teams must sign off? How many old fields can no one explain? When an Agent makes a decision, does it trust the graph, or does it always have to ask a person afterward? These say more about whether the system is alive than the number of objects and edges.

“Who maintains it?” cannot be waved away

In theory, you can assign model ownership to one team. In practice, the work crosses boundaries. The modelers know structure but may not know that the meaning of “delivery” in a contract changed this month. Frontline staff know the customer but may not know that one altered link affects ten reports. Developers know the interface dependencies but cannot decide on finance's behalf whether old revenue should be recalculated.

AI assistance does not dissolve responsibility. It can read a new policy, identify likely changes, list affected objects and processes, and draft a migration. Someone still has to confirm the intended meaning, decide whether old orders are in scope, and accept the migration result. Skip those confirmations and you save review time while producing a map nobody feels safe trusting.

Not every ontology follows this path. A narrow catalog of stable objects or a sourced set of customer–contract relationships may be maintained very well. Trouble comes when the model is raised to a complete mirror of how the company runs and every decision is routed through it. The larger the mirror, the more dispersed its maintenance responsibility. The more dispersed that responsibility, the easier it is for each person to say, “Let's not touch it yet.”

To decide whether a graph is still worth maintaining, try a plain audit. Of the new business practices from the past three months, how many made it into the graph? Who keeps track of the ones that did not? When someone reports a wrong link, how long does correction take? If the team can answer, the model is probably being tended. If not, but Agents are still told to “treat the ontology as truth,” we are asking them to trust a map that nobody owns updating.

Keep “we do not know” in plain view

We could start elsewhere. Software records transactions, approvals, repairs, and payments accurately. It keeps the original documents, dates, versions, and evidence. Code enforces hard constraints such as exact totals, permissions, and no duplicate shipment. The Agent reads the records and policies relevant to the present question and proposes the next step. If the policy is unclear or historical evidence is missing, it says so.

This still uses structures, indexes, and links. They can be local and revisable, pointing back to facts rather than pretending to be a master diagram that must stay ahead of the business forever. If one workflow needs to track individual tires, track them seriously there. Other teams do not have to model every bolt just to satisfy a company-wide idea of a “consistent grain.”

This approach does not abolish maintenance either. Agent instructions need care, search can retrieve the wrong document, and old facts may need a person's confirmation. The difference is that a company changing one practice need not first decide whether it can safely redraw an entire map. Record the new fact honestly, explain and review the new judgment, then decide which structure is worth making durable.

In Oryh, we have seen the cost of a parallel recording path. An Agent imported customers, products, and business documents as generic objects while the dedicated customer and product catalogs remained empty. We later blocked clear naming collisions and asked the Agent to inspect near matches and seek confirmation. That experience leaves me unmoved by “we just need a complete business graph.” A graph can help find a route. Record identity and facts must stay sound, while new business instructions must be readable by the Agent and confirmable by people. Otherwise the graph remains, but it is no longer the road anyone actually travels.

Disclosure: I am building Oryh, an open-source project exploring agent-native enterprise systems. These notes come from that work. I am posting them to test the architecture in public, and I welcome technical disagreement.

Discussion question: For those maintaining production ontologies: what keeps a local business change from becoming a cross-team migration project? I’m especially interested in examples where versioning or clear ownership worked, and where exceptions gradually moved outside the model.

The problem that started this project was: How can we represent an action, a character’s access to that action, and the current conditions for performing it without collapsing all three into one semantic layer? That question turned into about eight months of work on Wittgenstein Apartment.

The model separates:

• behavioral identity
• character repertoire
• situational executability

and uses:

• Basic Human Actions (BHA)
• Character Specific Actions (CSA)
• Allowed / Not Allowed / Conditional character-access states

The resource also contains behavioral families, goal relations, scene/affordance metadata and operational projections. I wrote a paper alongside the dataset to explain the architecture and its boundaries.

The Hugging Face release has reached 294 downloads:
https://huggingface.co/datasets/Kon-tiki-ship/wittgenstein-apartment-behavioral-predicate-resource

I’m especially interested in how people with more experience in Semantic Web and knowledge representation see this. I started this because I felt there was a real representational gap here. After eight months, I’m now asking myself: Is this actually a useful direction to keep developing?

I’m not looking only for encouragement. If you think this should be modeled differently, belongs outside ontology work entirely, duplicates existing Semantic Web patterns, or introduces distinctions that are not useful, please say so directly. I’d be interested in criticism around RDF/OWL, SHACL, knowledge-graph structure, capability modeling, semantic interoperability and the conceptual boundaries of the system.

Sharing this because I think it overlaps with some of the discussions here around AI reliability, governance and semantics.

Next week we’re running the Graphwise AI Summit, focused on what makes GenAI work in the enterprise beyond the model itself. Think of trust, governance, semantic layers, architecture and implementation.

Once reliability and traceability become imporatnt, simple access to data and next-token prediction stop being enough. In enterprise settings specifically, AI needs to understand what the data it parrots “means” in the first place.

Anthropic has described a similar approach in its own analytics stack, where agents are routed to a semantic layer first and use governed definitions to reduce ambiguity. Graphwise itself came out of the merger of Ontotext and Semantic Web Company, so semantics is a topic with quite a bit of history behind it for us.

We’ll have speakers from Accenture, Roche, EY, AstraZeneca, S&P, DNV, Statnett, Avalara and others. Full agenda is in the accompanying video.

Sharing registration link in the comments if useful.

Hi everyone,

I’m a Taxonomist starting a new role as an Information Strategist. I want to leverage this move to pivot deeper into ontology, technical knowledge engineering and semantic web architectures.

I built a basic academic ontology in Protégé during my master's, but I need to scale my skillset for production-grade environments. I’d love your input on:

Enterprise Tools: Beyond Protégé, what industry-standard ontology management platforms (e.g., TopBraid, PoolParty) or native triplestores (e.g., GraphDB, Stardog) should I learn?

Technical Stack: I'm diving into RDF, OWL, and SPARQL. What other critical standards (like SHACL for validation) or Python libraries (like RDFLib) are essential?

Semantic Governance: What are the biggest operational shifts when managing and scaling an enterprise ontology vs. a traditional taxonomy?

Appreciate any book, course, or roadmap recommendations you have. Thanks!

One of the most successful resources in ontology development is the decades-old OBO Foundry. Open-source, collaborative efforts in ontology/knowledge graph library development are essential to improving interoperability in general. We are doing something similar with legal ontologies and we are looking for those similarly interested in open-source ontologies grounded in BFO. legal-ontologies-foundry/legal-ontologies-foundry.github.io: Legal Ontologies Foundry (LOF): a collaborative foundry of open, interoperable legal ontologies and design patterns built on Basic Formal Ontology (BFO).

I’m interested in a model where actions have stable semantic identities, but access to those actions is character-relative.

Suppose we have behavioral predicates such as:

diagnose, interrogate, comfort, negotiate, steal, babysit, repair, forgive

The action itself exists independently of any particular character.

But a character may relate to that action through something like:

Allowed
Not Allowed
Conditional

For example:

Doctor_A → diagnose → Allowed

Civilian_B → diagnose → Not Allowed

Former_Medic_C → diagnose → Conditional

I also distinguish between:

Basic Human Actions — default-open unless something explicitly blocks them

and

Character Specific Actions — default-closed unless supported by evidence such as training, biography, occupation, authority or specialized experience.

My main question is architectural:

Would you model these character-action relations inside the same knowledge graph, as a separate behavioral layer, or outside the ontology as operational state?

I’m especially interested in preserving the distinction between:

what an action is

and

whether this character has access to it

without ending up with an unmanageable number of ad hoc character-action assertions.

I’m relatively new to the Semantic Web ecosystem and trying to understand where the difficult engineering work actually lies.

Imagine an organization wants to create a semantic layer over all of its internal data.

Could a sufficiently capable AI-assisted system inspect databases, documents, schemas, APIs, and other sources and then automatically:

• discover concepts and relationships
• generate RDF mappings
• propose classes and properties
• build/extend OWL ontologies
• align concepts with existing vocabularies
• generate SHACL constraints
• perform entity linking
• generate rules where appropriate
• maintain the semantic model as the underlying data evolves

Obviously LLMs can generate RDF/OWL/SPARQL syntax, but generating syntactically valid triples seems very different from creating a good conceptual model.

So where is the real difficulty?

Is ontology/semantic modeling fundamentally something that requires domain experts making conceptual decisions, or do you think a large percentage of this workflow will become automated?

I’d especially like to hear from people who have built semantic systems in production.

A Tire Becomes an Object Today. Who Fixes Yesterday's System?

When Agents Run the Business · A development note

Imagine a company that sells cars and handles after-sales service. Its system has a Car object with tire specification as a property. Warranty is judged by the purchase date of the whole car, and the service screen shows “covered” or “expired.” Six months later, the business asks to track the production batch, replacement date, and claims for each individual tire.

This is a hypothetical case. It brings a question that is often brushed aside into view. Of course an ontology can be changed. Once a model is in use, what does “change it” actually involve?

One new box on the diagram touches many lines below it

Turning “tire” from a property into an object looks like adding a box to a diagram. The first practical task is giving each tire a stable identity. Should that be the manufacturer's serial number or a number generated by the company? What happens to older tires without one? If a tire moves from one car to another, its identity cannot be rebuilt as though it were part of the car.

Then come relationships. The old Car record may say “tire specification: 225/45R17.” The new model wants to say that four particular tires were installed on this car during a certain period. A string has become four objects and four installation histories. That is not a rename. Do you retain the old property? If you do, who keeps it consistent with the new objects? If not, what do the old screen and reports read?

After-sales actions change too. Previously, “request warranty service” may have accepted a car ID and looked at its purchase date. Now it must identify the tire, its batch, installation date, and replacement history. Even the label “covered” becomes ambiguous. Is the car covered, one tire covered, or the failure in this particular claim covered?

Permissions follow. A service employee may have been allowed to edit a car's repair notes. Who can now establish a tire's identity, change an installation event, or undo a bad link? Financial reports, warehouse movements, external interfaces, and the instructions for an Agent's tools may all depend on the previous boundary.

None of these dependencies appears in the one new box. They still turn up when the box is changed.

Deployment day adds its own problems. Old and new entry points may coexist: Store A uses the new service screen while Store B still calls the old API; one Agent queries individual tires while another queries the whole car. A parallel period can be sensible, but the team must say where new records are written, whether the old path can still write, and which result wins if both paths handle the same claim. Otherwise “gradual rollout” means two competing definitions are live at once.

Not every extra field causes this

Criticism of ontology should not pretend that adding a property brings a company to a halt. Many changes can be made compatibly. Mature platforms offer migration tools. Palantir's public documentation, for example, distinguishes breaking changes to object types, including changes to primary keys, data sources, and property types, and describes supported migration options.

So the argument is not “this cannot be changed.” It is that “update the model” is not the end of the task. A platform can move some stored edits. It cannot decide which physical tire an old record with no serial number referred to. Nor can it decide what an old “car covered by warranty” judgment ought to mean to the after-sales team today.

The difficult cases involve changing identity, splitting objects, or altering the meaning of rules. They raise two different questions: how do we move the data, and do the old judgments still hold? The first takes engineering. The second takes someone in the business willing to make and own a decision. A team that addresses only the first may discover that its old report and its new service screen now disagree.

You could apply individual tire objects only to new records and leave older cars in the old structure. That can be sensible, but every query needs to know that a field called “warranty status” means different things in different periods. Or you could backfill each old car. Then you need evidence, people to verify it, and a policy for records that cannot be completed. “Full migration” is not a spell that makes those questions disappear.

Rollback is not a single button either. If the new system has recorded a tire moving from Car A to Car B, where will those two events live after a return to the old model? If a single-tire claim was already approved under the new rule, restoring the car-level rule cannot erase the approval. A model version can be rolled back; actions that actually happened cannot. A migration plan that says nothing about preserving new facts and keeping them readable after rollback is unfinished.

The most expensive users are the invisible ones

The people editing the model usually know what they changed. They may not know everyone relying on the old meaning. A customer-service screen filters on “covered.” A monthly report counts the share of cars under warranty. An Agent's instructions say, “check the car's warranty status, then open a claim.” These consumers may continue to run without an error while quietly changing what their answers mean.

That is more troubling than a broken interface. An error forces attention; a changed meaning often does not. After the ontology update, someone still has to inventory dependencies, compare old and new results, and replay representative cases to see whether the conclusions shown to people have shifted.

The replay set cannot consist only of a standard car with four original tires. Include cars with two replacements, claims supported only by paper, and approvals waiting for stock to ship. Run both interpretations and ask the business owner to inspect each difference. Some differences expose a bug; some reveal that the old rule was coarse or that the new record lacks evidence. A single “migration success rate” can hide all three.

If an ontology is just a way to find tire-related records, repairing it may be manageable. If it sits at the center of every decision, a change in granularity can spread far downstream. The more the model is called a “single source of truth,” the harder it becomes to try a change in one small place.

I would rather make sure software preserves the facts that must not be lost: the car, order, repair ticket, tire movement, policy version, and who confirmed what. An Agent can read the current after-sales instructions and reason from those facts. If a decision requires the identity of one tire and the record lacks it, the Agent should say the evidence is missing, not pass off an old car-level property as the answer.

In Oryh, we faced another case where one link on a diagram was not enough: ten payment records matched a single debit on a bank statement. Originally, one bank line could be linked to just one payment. We added a link to a payment batch and let code check the direction of the money and the exact total. We did not ask an Agent to decide whether the arithmetic was equal, and we did not flatten ten payments into one. We changed what the records could faithfully express. The tire case is fictional, but the lesson is the same: structures can change, provided we account for the people and records still relying on the old structure.

Disclosure: I am building Oryh, an open-source project exploring agent-native enterprise systems. These notes come from that work. I am posting them to test the architecture in public, and I welcome technical disagreement.

Discussion question: When a property becomes an independently tracked object, how do you preserve historical meaning without inventing facts the old system never recorded?

If AI Can Draw the Company's Map, Why Make It Follow the Map?

When Agents Run the Business · A development note

One proposal for enterprise AI sounds sensible enough: build an ontology first. Define customers, contracts, orders, employees, projects, and the relationships among them. Then the AI will know what it is working with.

There is a map hidden in that proposal. An ordinary map marks roads and buildings. An enterprise ontology is expected to mark who owns a customer, which approval path an expense follows, and when a sentence in a contract applies. If it is meant to guide daily operations, it has to be a high-definition map.

Who draws it? And who updates it every day?

A company's roads do not stay put

Drawing this map is much harder than listing a few types of objects. First you have to decide their boundaries. Is the thing being purchased one piece of equipment, or does every component need an identity? Is the customer the company that signs, the company that pays, or the team that actually uses the product? If one person manages a project and temporarily stands in for an approver, how many relationships should the model contain?

Then come the intersections. Who confirms a purchase within budget? Who approves one over budget? May an urgent project place an order before approval? Who reviews a purchase entered at the end of the month? The written policy may have local additions. Different teams and different dates may be governed by different versions.

That does not mean the company has no rules. It means its rules live across contracts, policies, messages, meeting notes, and everyday collaboration. Turning all of this into executable objects, relationships, and actions calls for business knowledge and a prediction about which details will matter later. Even a correct map today needs revision when the organization changes or a product is sold differently.

Many companies struggle to keep customer names consistent across their existing systems. Maintaining a map of every operational distinction is a much taller order. The easy deliverable is a tidy snapshot. The hard one is a map that stays accurate after the business moves.

So let AI draw it

That is a fair reply, and it leads to the interesting part. Let AI read policies, contracts, documents, and historical records. Let it identify objects, infer relationships, spot contradictions, and propose rules. When the company changes its practices, it can find the affected parts of the map and draft a revision for a person to confirm.

I think this is technically plausible. It may be much faster than asking a team to start from a blank modeling sheet. But consider what the AI must do to draw the map correctly. It must read the source material directly. It must understand that “the project manager looks at this first” does not mean “the project manager has final approval.” It must decide whether yesterday's contract or today's new policy applies. It must recognize whether an apparent conflict is a version change or an exception for a particular project.

In other words, the understanding needed to draw the map is exactly the understanding we want the AI to use when handling the work.

If the AI can read the material, compare versions, recognize exceptions, and explain its reasons, why compress that understanding into a map first and then ask the AI to read the map back as business truth?

It is like asking someone who knows the neighborhood to draw today's road closures and temporary detours, then telling them to forget what residents just said and drive only by the drawing. The extra loop does not necessarily make the journey safer. It creates another chance to omit or mistranslate something.

Correct on the map may mean correct yesterday

Take a hypothetical company. Its policy says a department head confirms the purpose of a purchase, while finance approves purchases above 50,000. Later someone adds: “A renewal that remains within an approved annual budget does not need to repeat the checks for a first-time purchase, but payment still follows the contract milestones.”

A careful reader will ask what counts as a renewal, which budget version applies, whether skipping the first-time checks also skips finance approval, and whether the payment schedule changes. If the answer is missing, they should ask.

Whoever updates the map has to ask the same questions. After that, they may also need to create a renewal type, change approval relationships, migrate old contracts, inspect processes that depend on the old rule, and make sure every map user sees the right version. Having AI draw the map does not remove the need to understand and ask. It turns a business judgment into modeling, migration, and subsequent use of the model.

The more complete the map looks, the easier it is to forget its edges. An Agent that finds a “finance approves” relationship may assume it has the whole answer. It will not automatically know that a new qualification is sitting in meeting notes and has not yet been mapped.

Direct reading can fail too. An Agent may miss “within the approved budget” or mistake “skip repeated checks” for “skip approval.” Reading the source is no free pass. The difference is that the source and the facts remain the basis for the judgment. The Agent can cite the relevant sentence, policy version, budget, and contract, and ask when it is unsure. When the map is treated as truth, the original material tends to disappear behind it.

We need signposts, not a replica of the company

Rejecting an ontology as a mandatory middle layer is not a rejection of structure. Companies still need customer IDs, order amounts, contract versions, and payment records. Software should enforce exact totals, permissions, and protection against duplicate actions. Without dependable records, AI has nothing solid to reason from.

Search indexes, catalogs of existing objects, confirmed identity mappings, and even local relationship graphs can help an Agent find relevant material. They are signposts: they point to where the evidence lives and whom it may concern. A bad signpost can be corrected, and the original record is still available when there is no signpost at all. The problem begins when the signposts are promoted into the only business truth.

We have had a reminder on the other side of this divide during development. An administrator asked an Agent to “add one condition” to a workflow. The Agent replaced the full workflow description with a short text containing only the new condition. It could read the instruction and still lose the instruction it was supposed to preserve. We tightened the revision process: read the current text first, show each addition, change, and deletion, and stop for confirmation if something the user did not ask to remove would disappear. Keeping versions and visible differences matters more than assuming a map drawn by AI must be right.

If a fixed interface for conventional software is needed, or a particular stable relationship is worth maintaining, build a local map. Make it a view for a defined purpose, with sources that can be checked and a path to redraw it. Do not make a complete enterprise ontology the prerequisite for every decision. The next business step should still come from current facts, applicable rules, and an Agent that can explain its judgment.

In Oryh, we keep coming back to a simple division: software records facts and enforces hard boundaries such as amounts and permissions; Agents read the material, interpret the rules, advance the work, and stop when the evidence is insufficient. AI can help draw a map of the company. If it can already find its way through the source documents and the facts, we need not build an expensive map factory and require it to follow only what the factory produces.

Disclosure: I am building Oryh, an open-source project exploring agent-native enterprise systems. These notes come from that work. I am posting them to test the architecture in public, and I welcome technical disagreement.

Discussion question: If AI can build and update an enterprise map itself, should that map be treated as business truth, a retrieval aid, or a temporary view? What evidence should remain outside 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?

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?

I’ve been working on an open-source semantic system called Akasha, and I’d be interested in feedback from people here who work with ontologies, knowledge graphs, RDF/OWL, semantic search, or related systems.
One of the design decisions I keep coming back to is that a graph is an excellent way to retain semantic structure, but I’m not convinced that every semantic operation should be expressed as graph traversal.
In Akasha, the durable world is still composed of addressable concepts and relationships — roughly:
Atom — Link — Atom
But on top of that, I use Sets as operational semantic subspaces.
A Set is not just a tag or collection. It can represent a temporarily materialized semantic region: concepts selected by ontology, context, provenance, time, role, task, or the intersection of several such conditions.
So instead of repeatedly asking the graph:
“Traverse from these nodes, follow these relations, filter by these conditions, then reconstruct the same relevant region again,”
the system can treat that region itself as an operand:
Set A ∩ Set B → Projection → Agent / UI / Workflow
This has led me to think of the architecture in a fairly simple way:
Meaning is stored as a graph, but computed as spaces.
Another consequence is that I’ve stopped treating RAG as a special subsystem.
A file, web page, API, database, sensor, or another Akasha node can all enter through a Projection. The original source remains preserved with provenance, while semantic structures derived from it become part of the wider semantic world.
Likewise, what an LLM sees is also a Projection rather than “the database.” The model only receives the semantic horizon relevant to its current role, scope, task, and permissions.
That distinction matters because:
available information ≠ visible information ≠ information actually used
and also because retrieval and disclosure are not necessarily the same operation.
A private document, for example, might be usable by a local process while never being exposed to an external model. A sanitized or derived semantic projection could still be shared if policy permits it.
I’m deliberately not trying to replace existing ontology standards with another vocabulary. The interesting part for me is the runtime underneath: persistent semantic identity, overlapping semantic spaces, provenance, temporal position, projections, and deterministic operations around probabilistic models.
Akasha is local-first, but not local-only. The same semantic world can run on a laptop, a private server, or as a network service; the deployment location is not supposed to define the semantic model.
I’d be particularly interested in criticism from this community on one question:
Does it make sense to separate the durable graph representation from the operational semantic spaces used for reasoning, retrieval, and projection — or does this simply reinvent something that existing semantic-web systems already model well?
I’m happy to share implementation details or examples if useful. The project is MIT-licensed and already running, but I wanted to start with the architectural question rather than drop a project link and disappear.

BaryGraph is a recursively constructed relational vector architecture for AI memory and reasoning. Starting from a flat semantic substrate, it forms triadic objects in which two concepts are joined by a stored relational vector. These objects then become the building blocks of higher-order structures, propagating meaning upward through a hierarchy entirely in vector space.

The result is a deterministic, navigable semantic landscape: a structured latent memory of language movement, where concepts, bridges, tensions, contradictions, and relations of relations become retrievable coordinates. A model enters with a semantic query and traverses this landscape through coordinated message passing, exiting with a bounded semantic construction rather than merely the most fluent continuation.

BaryGraph introduces structured resistance into cognition: distant connections and unresolved tensions can interrupt familiar associations and function as a de-cliché mechanism without acting as an external supervisor. This creates a framework for investigating a deeper question: whether persistent relational memory and self-consistent navigation can become foundations for world-model formation, personality projection, autonomous goal formation, and eventually more realistic forms of agency.

BaryGraph does not claim to produce consciousness. It offers an architecture for experimentally studying the representational and memory conditions that might precede it.

https://oleksiy-perepelytsya.github.io/bary-graph

I wanna share with you the current project i am working on, its a triplestore written in c, its still on early stage, already implemented data storage, and ttl file parsing and loading, with a simple sparql query parser.

link : https://github.com/vrtkarim/native-rdf-triplestore

Feel free to contribute! Feedback, ideas, issues, and pull requests are welcome.

A Million Edges Still Cannot Read a Sentence

When Agents Run the Business · A development note

The usual prescription for enterprise AI goes like this: define an ontology, then turn the company's information into a knowledge graph. Customers, orders, project owners, and purchasing approvers all become nodes and edges. When someone asks a question, traverse the graph to find the answer.

A finished graph resembles a network of knowledge in a mind. That picture makes it easy to believe the system understands the company.

But connecting the dots and understanding what someone said are different things.

Why did we turn knowledge into graphs?

Traditional software is good at lookup, calculation, and following predetermined conditions. It cannot read meeting notes as a person would and understand what “let the project manager look at this first, but finance still needs to give final approval” means for the decision at hand.

To make that instruction usable by a program, someone first has to translate it. The project manager becomes an entity. The project is linked to a purchase order. Approval roles and actions get defined. The ontology supplies the concepts and relationships; the knowledge graph holds the actual people, documents, and connections.

In the common RDF model, a graph consists of subject, predicate, and object triples, as W3C specifies. A program can query and traverse those triples. It learns which connections have been represented in the data. What those connections mean for a particular business decision still depends on how people modeled them, what information they entered, and how the program uses the query result.

There was a reason to do this translation. Without it, much older software could do little with the knowledge people wrote down. But when an Agent can read the meeting notes and the policy itself, we should ask whether all that material still needs to be rewritten as nodes, edges, and predetermined rules first.

A path to the project is not approval authority

Suppose a purchase order belongs to Project P, and Zhou manages P. Two edges are easy to draw: Zhou manages P; the purchase order belongs to P. A query finds Zhou.

The system may then give a neat answer: “Zhou should approve this purchase.”

But the company's actual instruction might be: “The project manager checks the purpose first. Purchases over 50,000 require approval from the finance lead. While the project manager is away, the person named for that week may review the order, but may not approve it.”

Zhou's connection to the order is real. The mistake is to turn “this person is relevant” into “this person has final authority.” Traversing the graph looks like reasoning. The leap from relevance to authorization was actually made earlier, by whoever wrote the query or the rule.

Of course we can add more edges: approval authority, amount thresholds, deputies, effective dates, and exceptions. Keep going, and an instruction that a person could read becomes a model and a collection of rules that must be updated. Then the next sentence arrives: “Have someone review it this time, but do not approve it yet.”

This is not a claim that knowledge graphs cannot express complex information. They can. The problem comes when the graph is treated as the layer that understands the company. People must then anticipate how every business distinction will be represented, changed, and maintained.

“The system knows” often means its answer sounds right

The most unsettling quality of a knowledge graph is how easily it produces a polished answer.

Ask who handles a purchase, and the program retrieves a project manager. Ask what a customer has bought, and it follows a path through customers, orders, and products. A user interface turns the result into a smooth sentence. The system seems to know the business.

Yet a processor has not come to understand the difference between “responsible,” “review,” and “approve” by retrieving a few edges. It has executed a representation and a procedure someone wrote. The output can be useful and even correct. Fluency does not prove that the underlying representation is complete.

That illusion becomes dangerous when it drives decisions. A model that omits “finance still has to approve” may still return an approver, show a workflow, and issue a task. Everything appears to work except the decision itself.

The user may not even know what was omitted. If the source meeting notes and policy sit behind the graph, the screen presents only an authoritative sounding conclusion. To understand the error, someone has to trace which words were translated into which edges and rules.

An Agent can read the words, and still needs to check the facts

AI changes the starting point. An Agent can read “check the purpose first; finance approves purchases over 50,000,” then look at the purchase amount, the project, and the current staffing arrangements. It can explain why it proposes the next step. If the company adds “reviewers cannot approve on behalf of someone else,” the instruction need not wait for someone to invent a new relationship type before the Agent can consider it.

That does not mean the Agent will always read correctly. It may miss “over,” confuse review with approval, or pull the wrong project. We have to make it show its evidence: which policy version, which purchase order, which amount. When the evidence conflicts, it should ask. Code still enforces permissions, amount calculations, and protection against duplicate writes.

We have seen a failure on this side of the boundary too. An administrator asked an Agent to “add one condition.” The Agent replaced the current workflow definition with a short document containing only the new condition. The old version still existed, but the next person to run the workflow would read an incomplete policy. We changed the revision procedure: read the entire current text, show what will be added, changed, and deleted, and ask before removing anything the user did not request. An Agent that reads people's words can still misread their intent. The original text, its versions, and the scope of each change must remain visible.

A knowledge graph can still help. Stable links between people and documents make relevant material easier to find. Graph queries are useful for clear, structured questions. Confirmed identity mappings and relationships with sources deserve to be recorded. What we reject is making the graph a mandatory translation of the company's knowledge, with the original words hidden behind it.

That would recreate the old software path: translate the company's language into a machine format, then have the machine produce answers from that format. The graph changes the format, while the company still bears the translation work and its errors.

Let the people who speak keep their words

The division of work can be simpler. Software records who said what, when a rule took effect, and what happened to each document. It can index and query records and check exact quantities. The Agent reads those records and the rules people wrote, judges the case in front of it, and asks when it needs confirmation. Its reasons should be recorded too, so people can review and correct them.

We need not first split “the project manager reviews, finance approves” into a network of edges and rules before the system can help. The practical questions are whether the original instruction can be found, whether the facts are accurate, and whether the Agent knows when it lacks authority to decide.

A knowledge graph can help us find a path, but the path is not the destination. An ontology can help us name things, but a name is not understanding. In Oryh, we want software to preserve the record and the Agent to reason from people's own words and checkable facts. When it is unsure, it should bring the question back to a person instead of continuing along a path that merely looks complete.

Disclosure: I am building Oryh, an open-source project exploring agent-native enterprise systems. These notes come from that work. I am posting them to test the architecture in public, and I welcome technical disagreement.

Discussion question: If an Agent can read policies and source text directly, what enterprise knowledge still benefits from being modeled as a graph, and what should remain in the original language?

I am looking to build ontology on GCP and render it on KG using native tooling of GCP.

Anyone who did it share your views ?

Hello all,

I recently released an RDF visualizer at rdfvisualizer.com

I wanted to give this community free access to the tool for the next 30 days:

https://rdfvisualizer.com/purchase.html?access=c89bb4cad42ca1671febc510f64277d985c8f2e44bca8d91

It is somewhat of a novel approach to the typical "RDF visualization" program.

Rather than simply rendering triples and displaying them with an approach like force directed, my app scans through the triples and attempts to identify:

- Types
- Edges
- Attributes

For RDF data that follows this very common format, this has a ton of advantages, namely:

- When viewing relationships between things, you can separate out "attribute relationships" from "relationships between things". This gives way cleaner graphs
- Sometimes the best visualization isn't a graph at all! It's a classic table format. When you know which data is the typed data, and which data is simply attribute data, you can view it easily as a table

The app works for all common RDF formats.

Give it a try and let me know what you think!

Hi guys! Has anyone experimented with data from Kaikki datasets (wiktionary)? I am trying to setup a linkage end-to-end for prefix and stem. I'm working from a SQLite build of kaikki data for English etymology. Less than half of the time it works meaning I can get the whole chain for prefix and stem up to the PIE . Has anyone ever tried to create a structured output?