RE: SUO: RE: RE: Missing ingredient
Murray:
I will follow-up on this, as I am able. Thanks for the references.
You are indeed correct that I have focussed on one use for a formalized
ontology, that of semantic interoperability, rather than on increasing the
power of intra-database inferencing. One reason is that that is what I think
the "semantic web" must be all about (although I know almost nothing about
the semantic web). Another is that in the business world, that's where I see
the greatest need. Bad information ends up on decision-makers' desktops in
large part because the information comes from different databases. Those
databases grew up in substantial independence of one another, and in the
last decade or so (the decade of "data warehouses"), we have made tremendous
strides in our ability to bring data from different databases together.
Management, realizing that process is at least trying to give them a
cross-departmental, cross-functional view of their company as a whole, keeps
asking for more and more.
But it's the technical problem that's being solved, the problem of bringing
together bits and bytes, DATA, not INFORMATION. The realization that these
different databases usually instantiate slightly different understandings of
the basic concepts of the business (customer, supplier, product,
organization, employee, receipt, release, order, invoice, payment, etc, etc)
is just beginning to dawn on businesses. And they don't know what to do
about it.
As a business consultant, I can't talk to them in the language used in this
forum. I just do my best to talk about concepts, differences in meaning of
those concepts, and then relate THAT talk to specific examples of reports or
screen scrapings that mix apples and oranges, to the detriment of the
decision makers.
Semantics within a single database / information system is a matter of data
structures + program code, just like Nikolas Wurth said several decades ago.
Stable semantics best expressed in data structures, volatile semantics in
code. Transfer of both to metadata best of all. (I'm writing a series, at
datawarehouse.com, on just that topic.) Point being, I think we can get
along for now, in single database /info systemenvironments, without
introducing formal ontologies. Supertypes in the database schemas are a good
enough substitute for now.
All, of course, IMHO.
-----Original Message-----
From: Murray Altheim [mailto:m.altheim@open.ac.uk]
Sent: Wednesday, October 22, 2003 10:55 AM
To: Tom Johnston
Cc: West, Matthew R SITI-ITPSIE; jim.s3; standard-upper-ontology
Subject: Re: SUO: RE: RE: Missing ingredient
Tom Johnston wrote:
> No need to continue this thread. If the goal here is not to increase the
> semantic interoperability of databases, as you say, then I am in the wrong
> forum.
>
> Thanks for your reply.
>
> Tom Johnston
Tom,
The way I look at this, from an interoperability standpoint, is
that if you're not trying to build an inference engine *within*
the database, but rather trying to identify components of the
database as according to a known ontology/taxonomy/vocabulary,
then have components of those things need to be a form that
they can be canonically identified. In Topic Maps we call the
solution to this "PSIs", or Published Subject Identifiers, which
are simply URIs that have been made public within a community,
and are considered stable for the purposes stated.
To be able to map between sets of PSIs is something Topic Maps
are very good at. I look at all of the upper ontologies as
perhaps providing sets of PSIs that enable both statements of
interoperability to be made between components in different
systems (e.g., I could claim that
http://purl.org/ceryle/psi/authoring/#Thing
is semantically identical to
http://www.cyc.com/cycdoc/vocab/fundamental-vocab.html#Thing
and be done with defining, for the purposes of interoperability.
Same with databases. And any reasoning that can be done upon
those ontology/taxonomy/vocabulary components can be done upon
the database components identified as having the same subject.
I think that perhaps we're just mixing up design of an ontology
system with specific application of it. I don't *quite* understand
yet how you would design the ontology system from the bottom up,
using the database components as the model, unless there was an
upper framework of some sort to enable reasoning, *if* you want
reasoning. If not, then just a set of PSIs would do.
I think that upper ontologies will have an enormous effect on
interoperability of all kinds of systems, and getting it right
will keep us from making some bad reasoning errors, like assuming
that if you know somebody named Osama you must be a terrorist.
Given the tight tie-in between databases and reasoning, it seems
like a very important task.
My 2p, anyway.
Murray
......................................................................
Murray Altheim http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK .
Monkeys use thoughts to control robotic arm
http://www.sfgate.com/cgi-bin/article.cgi?file=/c/a/2003/10/13/MN2018.DTL
Bush uses media expertly to push apocalyptic view
http://truthout.org/docs_03/091403J.shtml