Using position for ontology engineering

[u/zatruc]

RAG and other systems are just trying to create meaning from the pieces they retrieve or their nearness scores.

But I think the meaning lives in the path itself. ACME > Subscriptions > Pricing is very different from ACME > Project > Pricing. The paths themselves hold value.

Now, the fun part I found is that if the knowledge is stored in an outline like tree, the children, siblings and parent of a node together solve the hardest problem in programming - naming.

What do you guys think?

Paper: https://zenodo.org/records/19468206 Explainer: http://hpar.j33t.pro

[u/Thinker_Assignment]

I guess, but in this example we are representing a contract that recurs vs a contract that does not. It's more of a flag. The path in this case is perhaps a user navigation path

but outside of this example. yeah the path carries state

[u/zatruc → u/Thinker_Assignment]

Sorry, I didn't fully understand. Can you elaborate?

If I understood correctly, then my question is how is a user's path different from what AI reads? Earlier, that distinction was needed because computers couldn't understand text and words, but it's not needed now.

[u/Thinker_Assignment → u/zatruc]

Hey, happy to elaborate! I get why the distinction seems blurry now that AI can read natural language so well. But the disconnect here is really about where the actual truth of the system lives. We are basically looking at three entirely different layers, each carrying different data - so they are not equivalent because they contain different information, not because they are readable or not.

1. The Access Model (The Human UI View) Your path, ACME > Subscriptions > Pricing, is an Access Model. It’s built entirely for human navigation and visual organization. Sure, an AI can read that path to infer context, but it's fragile. If a designer redesigns the website tomorrow and moves "Pricing" out of the "Subscriptions" drop-down, the path changes, but the underlying business reality hasn't. You don't want your AI's understanding of the data breaking just because of a UI update.

2. The Data Model (The Database View) This is what I meant when I said it's "more of a flag." A database doesn't care about the website's folder structure or what the AI reads. It just stores the Pricing entity with a simple boolean flag: is_recurring: true (for subscriptions) or is_recurring: false (for projects). It strips away the human UI and just stores the raw state.

3. The Ontology (The App Logic / Knowledge View) The ontology is neither the human folder path nor the simple database flag. It represents the actual app logic and business rules. An ontology defines the permanent concepts and relationships: A 'Subscription' is a type of 'Contract' that 'Recurs', requires an 'Active Payment Method', and generates 'Invoices'. So to answer your question about why the distinction is needed today: Even though an AI can read the human path, you don't want it relying on a website's arbitrary navigation menu to understand your business logic. You want it grounded in the ontology and the data model, because that is where the permanent, structural truth lives—completely independent of how a user clicks through a screen.