Dear Matthew, Pat, and Mike, (01)
JFS>> I was thinking about Cyc and EDR, which had large ontologies
>> and couldn't recover their research expenses. (02)
MW> If it is really a research project then I don't see that it
> should have to recover its research expenses. (03)
It's true that many, if not most pure research projects fail
to produce a positive ROI. But Cyc and EDR were started by
consortiums as long-term investments that were much more than
one-shot research projects. The founding consortium for EDR
was the Japanese 5th Generation project, which was so big that
both the US and the EU started competitive consortiums. MCC
was the US consortium that founded Cyc among others. (04)
The Japanese, Europeans, and Americans all hoped to get a
multiplier effect on their ROI. EDR was finally terminated
after about 10 years, and Cyc has continued for 25 years.
The WordNet project, which started around the same time as
Cyc and EDR, was a much, much smaller project that had a much
bigger ROI than either Cyc or EDR. (05)
MW> Research projects are about reducing the risk of future
> actions, rather than a straight ROI, and you might well be
> able to argue that these projects have done that. (06)
There's a lot to be learned from Cyc and EDR. One thing we
should have learned is that we could fund a lot more projects
like WordNet with the money that went into Cyc or EDR. And
by the way, I liked Tim B-L's original goals for the SemWeb,
but my major criticism is that the funding agencies and
businesses dumped too many eggs into a single untested basket. (07)
JFS>> But the more ontologies you add to the hierarchy, the easier
>> it becomes to mix and match modules to create new ontologies. (08)
MW> Not if they use different upper ontologies. You can only mix
> and match ontologies that are consistent... (09)
I agree that you can't mix inconsistent ontologies, but it's not
necessary to have a single upper level. The beauty of the lattice
is that it can support an open-ended number of different R & D
projects at the upper, lower, and middle levels simultaneously. (010)
MW> ... and they are only consistent if they use the same upper
> ontology (ontological commitments, core relations an categories). (011)
That is false. Two low-level theories that have nothing in common
are *guaranteed* to be consistent. Similarly, two very general
theories can have an open-ended number of specializations, some
of which are consistent and some of which are inconsistent.
The lattice can support all of those combinations simultaneously. (012)
MW> I don't even want to impose my ideas on others (happy to
> persuade people of course), never mind them impose on me. (013)
I am very happy that we agree on that point. I believe that it
should be a *fundamental principle* for any ontology project we
develop or recommend. (014)
PC> ... you don't *need* an FO to build a domain ontology, but
> if the domain ontology is at all complicated an FO can help. (015)
I agree. That is why the lattice is designed to support a
multiplicity of upper levels simultaneously. (016)
PC> You do need an FO if multiple independently developed
> domain ontologies want to share data and interoperate
> automatically. (017)
That is false. You can make independently developed systems
with inconsistent or even undefined upper levels interoperate.
OntologyWorks does that all the time. The key point is that
you should *never* try to merge two total ontologies. Instead,
you only need to extract the parts that are necessary for the
task(s) on which interoperability is required. (018)
PC> ... there has been much fuzziness about what should or should
> not be in an "upper ontology". That is one of the reasons why
> I have suggested that focusing on the semantic primitives is
> a way of putting some boundary on the task. (019)
There's a better solution: remove *all* boundaries by supporting
a framework that allows an open-ended variety of upper levels. (020)
The beauty of the lattice of theories is that it provides a
theoretical foundation that shows how to extract common consistent
parts from independently developed, inconsistent ontologies. That
is not blue-sky ideology. OntologyWorks makes a profit doing that. (021)
What we are doing at VivoMind is different from OntologyWorks,
but we also successfully relate and merge independently developed
resources, both structured and unstructured. Please look at the
legacy re-engineering project summarized in slides 24 to 27
of the following talk: (022)
http://www.jfsowa.com/talks/pursue.pdf (023)
That project not only detected and merged consistent parts, it
also detected and reported bugs, inconsistencies, and what MSFT
calls "issues" in software that had been in operation for years.
We have also applied similar techniques to other projects, from
which we do indeed get a positive ROI. (024)
PC> ... with a comprehensive foundation ontology, I think it will
> be necessary to have a utility that will allow one to select out
> only those parts that are needed for a domain application, so
> as to minimize the complexity of the logical computations. (025)
OntologyWorks and VivoMind already have utilities that support
what you're asking for. But we don't require a "comprehensive
foundation ontology". We can support a multiplicity of upper
levels (as in a lattice) or no explicit ontology at all (as in
most legacy systems). We're making positive ROI from that today. (026)
MW> Having an upper ontology can significantly reduce the cost
> of developing domain ontologies because it reduces the number
> of mistakes you make. One of the things I often say about data
> modeling is that it isn't a matter of how much a data model
> costs to develop, but how many times you have to redevelop it
> before you get it right (enough). (027)
I agree with both of those sentences. But I would emphasize that
the fundamental principle above (which we both agreed to) implies
that we should support a multiplicity of potential upper levels
(as in a lattice). (028)
PC> I doubt that any serious discussions for such details will
> even begin until a funding source is identified that has enough
> money and is willing to consider a proposal with that goal. (029)
Neither OntologyWorks nor VivoMind received funding that remotely
approaches the levels you're asking for (or the far greater amounts
that were poured into Cyc, EDR, or the SemWeb). But we have built
profitable and *deployed* applications that do what you're still
hoping to accomplish at some indefinite time in the future. (030)
PC> The most expensive part is to build applications (including
> the natural language interface) that demonstrate the utility of
> the FO for interoperability. (031)
As I said before, Cyc and EDR have built big ontologies funded
by governments and businesses that bought the hype that a big
ontology was needed to solve their problems. But those big
ontologies didn't lead to successful applications. The
companies cited above have found a better way: solve those
problems with applications that make a profit, not a loss. (032)
As for NL interfaces, see the pursue.pdf slides, which show
how to support NL without using a big, expensive ontology. (033)
MW> Well contracts and agreements and organizations are found
> in industry as well, but generally not criminal law. (034)
Have you heard about Bernie Madoff? He's now in jail. (035)
MW> I would see law itself as a domain and possibly many other
> social concepts as domains, just as engineering is. (036)
There was a large project in Germany that tried to implement
and reason about an ontology for German law for motor vehicles.
They thought that would be a small, well-defined domain. But
they discovered that almost every case involved vehicles that
interacted with people, objects, and situations in every
imaginable domain. (037)
In the legal system, all the simple cases are settled out
of court. Any case that is complex enough to go to court
applies the laws to background knowledge that requires judges,
juries, and trials to untangle. (038)
MB> Meanwhile there are things which some people call "Domain"
> which are fundamental enough to be used by multiple domains;
> particularly law, financial accounting and economic activity. (039)
Indeed. Most interesting applications cross multiple domains.
Cyc does support multiple domains and contexts with their
microtheories, but a major limitation is that they don't have
a dynamic way of extracting, integrating, and using relevant
information from multiple, independently developed domains. (040)
Following is a paper that discusses those issues: (041)
http://www.jfsowa.com/pubs/lgames.pdf
Language games, a foundation for semantics and ontology (042)
This is a more theoretical paper that goes beyond the things
that we have already implemented at VivoMind, but the technology
we currently have can help to support them. (043)
For a discussion of future directions, I suggest the following
lectures on semantic technology: (044)
http://www.jfsowa.com/talks/semtech.pdf
Three lectures on semantic technology (045)
In summary, there are several points I've been trying to make
in this note: (046)
1. Much more is needed than yet another big ontology that
rivals Cyc or EDR. (047)
2. Smaller projects like WordNet and others have accomplished
a great deal with much less investment. (048)
3. Small businesses like OntologyWorks and VivoMind have already
implemented successful applications with methods that do not
require large ontologies like Cyc, EDR, or the proposed FO. (049)
4. Instead of a single big ontology, we should be working on
a framework for dynamically using and relating multiple
ontologies at every level -- upper, middle, and lower. (050)
5. A dynamic framework can include big ontologies as special
cases, but it can simultaneously support an open-ended number
of other approaches that are much less expensive. (051)
6. A dynamic framework can also includes the successful methods
developed by OntologyWorks, VivoMind, and others that can
and do support interoperability with legacy systems. (052)
John Sowa (053)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (054)
|