So many times the discussion circled around the ‘true’ model of something, the ‘correct’ way to model a topic.
Young Wittgenstein wrote the Tractatus to define once and for all the relationship between language and reality, to show the borders of science, ending it with the great proposition No. 7：”Whereof one cannot speak, thereof one must be silent.“
I loved the sound of this (sounds better in german ;) when I was 20, even though even then I thought this in equal parts grandiose and useless: why speak, if you can only speak about well-known, well defined topics? What a useless … use … of language.
After the war he worked as teacher in primary schools and, luckily, was flexible enough to notice that pupils used language without knowing much about the topics at hand, and thereby *created* and *evolved* their understanding of the world and *the language they used* in one go.
That leads me to a feature i like most about RDF: using public identifiers and supporting namespaces. The creators of a ‘web scale’ knowledge representation system just *had* to accept that people would model the same (or partly varying, overlapping, intersecting) topics in different, possibly quite different ways. So the idea to describe the relationship between different ontologies, to integrate and work with knowledge graphs structured in quite diferent ways is in many way built into the DNS of the Resource Description Format.
Looking into business applications: do we really want to search for the ‘one’ model of our business? In my experience, the shop floor has a rather different model of ‘our business’ than management. And controlling, and legal, too, have quite different models of it.
And I would say they *all are ‘right’ or ‘true’*, in the sense of being *useful for their users*.
You could say the same for things like direct and indirect sales, where products and rules might be different enough to warrant two different ontologies.
And then we will need different enabling ontologies, ontologies enabling processes that span these different domains, taking into account the different entrprise models they have, ontologies enabling reporting over all topics.
Which triggers another topic that keeps nagging me: our models are transient, even if we don’t like to hear that. Some might live for weeks, e.g. to support some ETL (extract-transform-load) task, some live for years, modelling stable aspects of our business, and, maybe, something like a top level enterprise ontology might be used for a decade or more.
And additionally：most of these ontologies will change in their lifetime, sometimes substantially so.
And how do we model these life cycles, their changes, the ‘dying’ of one ontology, ‘birth’ of a new one (is it actually new, is it related to some other ontology, which now goes out of service?)
I just spoke to someone from the electrical industry, he is still searching for an ontology building tool that he can give to his domain experts. Thinking about managing the change of ontologies in an enterprise scale ’ecosytem of ontologies’ seems to be years away, maybe even light years ;)
A thought inducing workshop. Thanks to Panos Alexopoulos and the connected data london team!