Rich,
How can we possibly understand what you are saying here, if we don’t greatly share common semantics and a common ontology?
Thanks,
Leo
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Rich Cooper
Sent: Sunday, February 19, 2012 12:05 PM
To: '[ontolog-forum] '
Subject: Re: [ontolog-forum] What goes into a Lexicon?
Dear Matthew, David and John,
Matthew wrote:
It is really rather easy to create an ontology of names, what they represent, and who uses them in what context.
The problem isn’t in ease of creation, but in consistent use by multiple people. On this list, we have consistently found that people vehemently
disagree on the “proper” way to model concepts with ontologies. Our history of finding agreement indicates that it is very difficult to construct ontologies that many people agree on. Only very, very simple things such as Dublin Core have found widespread
usage.
By contrast, David’s example of the policy number, which one would expect to be well understood within the insurance business, by his stated
experience, isn’t so well understood. The problem is with the observers of any ontology; we don’t all see the same meaning in a given rendering of concepts.
After a lot of thought, and from years of discussion with well qualified people on this list, I have come to the conclusion that ontology
is simply one way of rendering reality. Ontologies have not in general satisfied large groups of observers because every observer has a unique, distinct, and very complex model of those simple concepts which we throw around with variant lexicons.
The problem is that we don’t all have the same experience. It is our individual differences in experience that leads us to think in different
sequences with different observations of the same phenomenon. I don’t see how that problem can be solved by monolithic ontological terms.
Instead, problem reduction methods such as top down structured programming, and packaging methods such as object oriented programming and
client server architectures have made dramatically effective inroads toward constructing large software systems that mostly work as intended.
I suggest that ontologists should take the same viewpoint because it has worked so well there. Instead of insisting on a singular meaning,
a singular ontology, a singular way of doing things, we should be more open to pluralities of ontology as just another art form that is juggled differently by each observer. In Chairman Mao Zedong’s terms, let a million ontologies flourish.
Singular ontology just hasn’t worked out and it looks like it never will.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
Dear David,
Of course.
As always I revert to my favorite, oft-repeated example... a life insurance company that found 70 different names for the core business concept (term?) "policy number." In a business environment
where product lines are bought & sold, systems are custom built by different teams & packages are bought, the reality is there will be many (illogical) names for the same thingy.
MW: it all depends what you build you ontology to do. If what you want it to do is allow you to bring together lots of
different names for the same thing, then there is no particular difficulty in that. It’s just that ontologists don’t tend to call those different names terms, but the common meaning they share. You just have to get over that, and adopt the local usage and
carry on. It is really rather easy to create an ontology of names, what they represent, and who uses them in what context.
Regards
Matthew West
Information Junction
Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west
matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/
This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City, Hertfordshire, SG6 3JE.
At one point I entertained delusions that ontologies would help with this issue (one conceptual label = many physical labels). Obviously I no longer hope in that direction.