> On Nov 22, 2012, at 10:24 AM, Peter Yim wrote:
The basic question is "Why aren't practitioners
> David Eddy wrote: Because they're really, really, really HARD, aside
from the fact that management has no idea what all the handwaving is about much
> less what any potential value might be.
+1, and my two pence worth on this, from the perspective of a long-term
data modeller/ontologist/business analyst who is not a computer scientist or
John Sowa has often pointed out that the majority of OWL ontologies in use
are basically just class/subclass and/or whole/part hierarchies with possibly
one or two other constraints. We’ve built a couple of dozen like that.
In the content/media industries it is now commonplace for standards and
organizations to rely on complex sets of controlled vocabularies, usually
involving hierarchies. Anyone who needs to know that Belgium is a part of Europe
when using ISO territory codes has those requirements. Yesterday I was
with a modeller from a large media organization who has developed an extensible
seven-dimensional matrix of rights management categories containing hundreds of
terms and permutations, guaranteed to grow and develop substantially on a
regular basis and needing to map to complex vocabularies and schemas in other
internal and external systems. I am sure this scenario is not uncommon for many
members of ontolog (on this point I don’t entirely agree with David about large
businesses not caring any more about their “naming conventions” – I think that
This modeller had a quite rich and complex ontology, but it was in an Excel
spreadsheet and he didn’t call it an ontology (actually he was doing so by the
end of our meeting after I had pointed out to him what it was). What he needs is
ways of managing and using it that are as familiar as updating a spreadsheet and
ontology independent of procedural rules.
In our own work we build all our ontologies in Excel and then parse them
out into RDF/OWL, XML or whatever is needed. I used to think we would use some
“proper” tools like Protege eventually, but we’ve never found one remotely as
flexible, fast and powerful as Excel for data creation and management functions.
We have a problem though, because Excel doesn’t give us the persistence and
audit capabilities of a database so it’s inadequate for ongoing maintenance of a
multi-user ontology (though as David suggests, hardly anyone is using those
I’m not talking here about ontologies and systems which are used for
deducing and discovering new facts from disparate data sets or masses of messy
data, as Watson does, as I don’t know anything about those. I’m talking about
knocking the basic and increasing complex type vocabularies of medium or large
organizations into shape, and allowing them to be reasoned over and transformed
in effective and extensible ways independent of procedural code. If an ontology
is regarded as a structured data dictionary that can be integrated into your
everyday systems using tools and languages that you are familiar with to store
your controlled vocabularies in a way that also give you some good reasoning
power, extensibility and interoperability, then it has potential takers. It
might in some hands be taken on to all kinds of delightful hand-wavingy things,
but that’s where some tools would be helpful. As an analyst I am regularly able
to persuade potential clients that an ontology can be really useful to them, and
then they go and spoil it all by asking how they can implement it.
John S’s checklist of questions looks a good place to start.
Chief Data Architect
164/180 Union Street
London SE1 0LH
+(0)20 8579 8655
Sent: Thursday, November 22, 2012 5:17 PM
Subject: Re: [ontolog-forum] doing standards [was - Re: Webby
On Nov 22, 2012, at 10:24 AM, Peter Yim wrote:
The basic question is "Why aren't practitioners
Because they're really, really, really HARD, aside from the fact that
management has no idea what all the handwaving is about much less what any
potential value might be.
Plus the little detail of there being no foundation. So ontologies
are very much ivory towers in the clouds, particularly in commercial IT.
Science/bio/pharma may very well be a different story since Mother nature has
been carving the hierarchy for a few million years. In commercial systems
the concept of ordered hierarchies & languages is at best a distant
It has been my direct, commercial experience with Fortune 500 organizations
that very few (approaching none) have anything approaching something simple as
"naming standards" (conventions—3 ring binders on the shelf, yes. Enforced
no.). Obviously some systems have naming conventions, but that was
typically driven by a single motivated individual & is not carried over to
the next systems(s).
Please to acknowledge the scale here... a Fortune 500 scale organization
will have something like 1,000 to 5,000+ IBM mainframe applications. This
is not counting client/server, web, *nix, iSeries, etc. Pretty much every
one of those applications will have uniquely opaque language.
I would argue that if the organization does not have the discipline to
control its language something as pie-in-the-sky as ontologies is a castle in
The reasoning/experience is that if they're as big & important as they
are without naming standards, why bother.
It is my assumption the same thinking & non-action carries over to the
much more complex ontology domain.
If the ontology consultant (that's singular) could show up on Monday &
create something substantive in a week or two, AND get easy-to-use &
understand results into the hands of the grunts, things would likely be
different. Requiring the grunts—the data entry/programmer/analyst folks
doing the work—to learn yet another collection of technical languages is not a
route to adoption.
Does anything in the ontology domain deliver something that's as
easy-to-use & mindlessly useful as a spellchecker? Protege may be a
wonderful product, but it's not even remotely close to being an end-user
Community Wiki: http://ontolog.cim3.net/wiki/