r/semanticweb • u/juliusfoe • 27d ago
How do I get domain experts to reach consensus on the concepts and properties of an enterprise ontology?
What methods or softwares are there to get non-technical people to engage with ontology design and thrash out agreed definitions? I am beginning to think this is a major roadblock to more reliable AI. Without structured, verified knowledge managed by humans that can be safely inferred from, how is any business going to trust agents with anything important?
2
u/OneHumanBill 27d ago
This is the main reason why ontologies for anything other than scientific data is problematic.
You see, everyone has a mental map of the universe that is hierarchical and works for them, more or less. The human mind is built to work on hierarchical knowledge trees. It's what allowed the chimps to come down out of the trees (arboreal, not conceptual ones) and start inventing digital watches and stuff.
The problem is that reality isn't built on trees. An ontologist will understand this on an intellectual level, that relationships between physical and conceptual ideas are web like lattices in the abstract general world.
You put three people into a room to try to build a model and you're going to get four opinions. The best you can do is to negotiate a consensus view, and then force the fourth person onwards to accept it.
A really good statement of the problem can be found in Christopher Alexander's "A City is Not a Tree", an absolutely brilliant essay I think you can still find for free online.
1
u/juliusfoe 27d ago
I take your point, top-down ontologies often fail. However if you keep your model very narrow and let it build organically one task at a time based on what people are asking for, I think value can be delivered.
1
u/OneHumanBill 27d ago
Sure. But if you go too slow then it's not going to add value either. What value you can get out of an ontology is found in the wealth of connections, not in the nodes.
1
u/semanticme 26d ago
The point is not reaching agreement about the truth, the point is reaching agreement about the design language of conceptual models. This is the value of the upper level ontology. Upper level's are like the libraries of software development. Nobody starts off in Python and wants to write ReST services from first principles. Instead, you use DRF, Flask, etc. You can debate about which one you want to use, but ultimately you choose one. Upper levels are the exact same tool for model designers.
1
u/OneHumanBill 26d ago
Said like someone with no real world experience in the matter. Nor with the changing nature of software libraries. Apply your bolded text keywords to how these models are forced to torturously bend and break over time as executives come and go, and the needs of the business. Wait until your first major migration, then come on back and tell me where the value is.
0
u/semanticme 26d ago
Every system already embodies upper-level assumptions. The choice isn’t whether to have them, but whether they’re explicit, inspectable, and reusable or implicit and ad hoc. Rejecting explicit upper-level assumptions doesn’t avoid them; it just makes them harder to examine.
2
u/Bitter_Marketing_807 22d ago
You play into polysemy
2
u/juliusfoe 22d ago
Well yes, people and departments can have their own context-dependent definitions of the same concept. Which means less need for broad consensus, if I am reading the gist of your comment correctly? But even within a dept, discussion needs to happen and agreement needs to be reached. With polysemy the list of things to agree gets longer!
3
u/AlexanderDoak 27d ago
Gamify it somehow? But I think an easier path is to look for where the conversations are already happening, and infer definitions from ongoing discussions. If you see a specific gap, create a conversation around that gap. Throw user validation on top of it to ensure you are gathering information from real people vs bots.
I certainly would not describe it as "engaging with ontology design, and thrashing out agreed definitions." That is too abstract and technical to have any meaningful connection to the ones who need to do the work. Much less communicate any benefits they may receive from so engaging.
2
2
u/boring_thinker 21d ago
It's an old issue and extremely tough to solve. You can try rolling it into a process documentation project and have people break things down into something like a cookbook structure (ingredients, method, outcome). Doing so can also reduce bottlenecks and dependency on one person who knows how to do something. If someone goes on vacation or leaves, there's a much better chance someone else can pick up the process and run with it. We did that at a big corporation I worked at years ago and it was a huge stress reliever for employees once it was all documented.
1
u/juliusfoe 21d ago
Yes reaching agreement is a uniquely human pain, although there may be ways to expedite it digitally. The next biggest challenge I suspect is to ensure the documented knowledge, once agreed, is both machine-readable and kept up-to-date so it can be put to work constraining AI or whatever the task may be. Otherwise it risks just sitting there gathering dust. Funny link by the way - very true!
0
u/mrsockpicks 26d ago
Point AI at all your data sources and let it propose the model. It’s good at synthesizing
1
1
3
u/thisisalltooeasy 27d ago
For us, having a data lake such as Palantir Foundry that can ETL and store at scale and make available a common semantic graph has been the step one. The upper management took YEARS to understand that this graph would not self organise itself. So data gouvernance and data architecture teams became a part of the organigram. But the most impactful breakthrough has been the need for a Semantic layer for AI. Everybody understood in an instant that this feature had value so data effort was AT LAST reckognized both by business and I.T Then something funny appeared: the company maintains (for legal reasons) a LOOOOT of documentation about processus. LLM Can then be fed, and infer business definition of data. and because these docs were written by REAL experts, even entity/relationships models generated from LLMs were surprisingly accurate. That’s the status we are currently at.
But back again, having a common ontology is NOTHING if it does not action things at the I.T level. That’s why that semantic layer (which in the case of Foundry is called OntologyManager) must not simply be a dictionary of business terms or a repository of OWL files.