John, (01)
We are talking about nearly disjoint subjects. (02)
you wrote: (03)
> EB> Bounding computational complexity is the big rationale for
> > Description Logic and all of its variants, and the key criterion
> > for admissibility of extensions and variants in the DAML->OWL
> > program, and many related Semantic Web activities.
>
> I disagree with the first line. As I said before, the original
> DLs were derived from work by Ron Brachman (1979) and his thesis
> adviser Bill Woods (1975). The main motivation for Bill's work
> was not computational complexity, but the need for finding a
> more rigorous logical foundation, (04)
than what? Chen's E-R approach to modeling? It makes sense to me that
DLs came out of the 1970s information analysis community, along with
frame-based logics. I saw DLs become big in the Agents community, which
needed 'conceptual schemas' for purposes other than database design.
But DL's modern academic claim to fame is the computationally bounded
behavior of tableaux reasoners. (05)
> EB> The methodology part for OWL and friends is only beginning
> > to emerge, and I don't think it was a target of the DAML->OWL
> > program. Methodology development based on the "common upper
> > ontology" approach is probably the dominant form in FOL land,
> > although I don't doubt there are others. And I understand
> > "compiler-based methods" to refer to logic programming, a la
> > Prolog, JESS and Jena, which is certainly knowledge engineering,
> > but entirely different from "ontology development" a la OWL or
> > CLIF in my view.
>
> OWL is a tool. And creating a design and development methodology
> for a particular tool is, in my opinion, bass-ackwards. (06)
Well, we need an ontology for "tool", because you and I have different
definitions of the term. OWL is, as it claims on its face to be, a
"language". Languages have expressiveness, and the need to capture
knowledge with a certain limited expressiveness is the underpinning of a
kind of methodology. In other words, when all you have is a hammer, you
need a set of best practices for turning your world into nails. (07)
There may be many other methodologies for analyzing the problem space,
but once you have the knowledge, there is a need for a methodology for
rendering the knowledge into a form suitable for reasoners. And that is
what I was talking about. (08)
From what follows, I conclude that you were talking about approaches to
analysis of the problem space. And in that, I completely agree. One
should not start analysis of a problem space by asking how it resembles
a nail. (And I have long regarded a whole set of methodologies in the
RDB and O-O design world as "how to view the world through the keyhole
of my technology concepts". Even worse was the O-O arrogance that their
program design concepts are THE natural modeling concepts.) (09)
> The work
> on methodologies began in 1945 with the flow-charts by Goldstein
> and von Neumann. ...
>
> In the 1980s and '90s, John Zachman developed a very broad framework
> for Information System Architecture (ISA) that encompassed everything
> in an enterprise. (010)
You will not be pleased to know that I think of the Zachman Framework as
a useful insight into "systems analysis" IN ITS TIME, but the discipline
has clearly moved on. The concerns identified in Zachman's columns are
valid, but the useful views of an enterprise don't fit conveniently in
his pigeonholes -- they combine aspects from more than one of the
concerns, and the tier structure is no longer meaningful (if it ever
was). That is not to say there aren't tiers, but everyone draws
meaningless layer cake diagrams, and none of them matches Zachman or
each other, even though the presenters go to pains to explain how they
do. (The primary function of layer cake diagrams is to show that OUR
activity is related to, but importantly different from, THEIR activity,
and should be funded AS WELL.) (011)
Having thus declared myself an infidel, I will take refuge in my own
ivory tower. ;-) (012)
> The Unified Modeling Language (UML) consists of multiple diagrams
> for representing various aspects of a project in a way that is
> independent of any particular tool. (013)
And now UML v2 has a language for every software modeling purpose under
the sun, but it still can be used to model concepts (instead of
software) only by extension of the concepts in the documented language.
And it still betrays its "object-oriented" prejudices in many ways. I
use it all the time -- it is the only language the communities I deal
with can read. But when I use it to draw OWL/DL models, people say
"I've never seen UML used like that." (014)
> EB> Actually, the people who do that are building "ontologies" for
> > Vampire or Otter or some other FOL reasoner. And their mode of
> > expression is some FOL language in the CLIF/KIF family.
>
> No! Vampire and Otter are just two more tools. (015)
Yes. But my point was that these people are not doing logic programming
(which appeared to be what you understood from your earlier response);
they are creating FOL knowledge representations ("ontologies" by
anyone's definition) for use by FOL reasoners. And the unbounded
computational complexity of FOL (the subject of discussion, you may
recall) often bites them. (016)
> The Semantic Web should encompass at least as much as Zachman
> considered more than 20 years ago. (017)
I have no idea what that means. Modeling the concerns of an enteprise
for the purpose of developing supporting software is an entirely
different program of work from modeling the referential knowledge of a
domain of publications. Those of us engaged in the former are looking
at the "places in the Zachman framework" (if you must) in which the
Semantic Web _technologies_ might be usefully applied. (Think of it as
"cross-disciplinary fertilization".) (018)
> EB> And all of this engineering is "programming", in the sense that
> > it is building a software machine to solve a set of problems.
>
> The ontology has to be as broad as Zachman's ISA. (019)
interpreted as needed to make sense in the problem space, of course.
Sure, or What nonsense, take your pick. (020)
> EB> The main contribution of the DAML research was to find maximal
> > combinations of the published extensions that produced in toto
> > a still computationally bounded algorithm.
>
> You're talking about algorithms for teeny-tiny problems. (021)
We are talking about knowing what kind of reasoning we can do in a
problem space, with all kinds of constraints, yes. Just like we design
computer chips to do a certain kind of reasoning with all kinds of
expressiveness constraints. But then engineers develop solutions of
real enterprise problems using those carefully understood tiny things,
and they land airplanes safely in zero visibility. (022)
> Just
> designing a single airplane involves an enormous number of very
> different kinds of problems. And an enterprise for designing
> and building airplanes (which was one of Zachman's major examples)
> is far, far larger. And the whole world is even bigger. (023)
Yes, but so what? (024)
Boeing was building 6 aircraft a day during World War II without the
benefit of any of the technologies we are talking about here. There are
lots of big problems out there, and analysis turns the big ones into
many more little ones, and we are finally getting technologies to solve
some of the little ones at the level humans understand them, instead of
one or two levels of engineering further down. (025)
> EB> But what does occur in practice is the reasoner running for an
> > hour without a result, and there being no way to know whether it
> > would find a result in 6 more minutes, or 6 more days, or never.
>
> Oh piffle! For over 60 years, programmers have successfully debugged
> programs that got hung up in loops, and they didn't need somebody
> to restrict their language so that they can't write loops. (026)
But that is when the program was erroneous. What if the program was
correct? That is what bounding computational complexity is about --
knowing how long it will take a correct program to execute all the loops
it must execute to get the intended result. (027)
In my youth, I worked on operations research software that regularly
generated enormous search spaces and pruned them and generated another
set in its search for near optimal solutions. And you learn to do
bounding estimators, lest the search space explosions exceed the
computational resources. Seen solely from the outside, it is my
impression that FOL reasoners have similar behaviors, and explosion is a
very practical consideration in getting solutions. (028)
> EB> As ugly as it may be, the OWL effort is making a lot more people
> > aware of what can be done, and of course, encountering problems
> > like these.
>
> Absolutely not! People are using OWL as a very primitive kind of
> logic-programming language. (029)
Perhaps, but my point was that, primarily because of OWL, there is a lot
more government and industry interest in the use of reasoning
technologies than there was 10 years ago. They may have to crawl before
they can walk, but it is better than lying in their crib admiring their
Zachman Framework mobile. (030)
> At VivoMind (and many other companies
> that know what they're doing), we download whatever RDF and OWL
> we get into Prolog, which gives us an industrial-strength language
> that runs circles around OWL in both performance and ease of use. (031)
Excuse my ignorance, but how does a language run circles around another
language? Do you mean your Prolog engine, running your interpretation
of OWL ontologies into Prolog, runs circles around every tableaux
reasoner that accepts OWL? I assume you have been looking at some of
the benchmark results. Have you really been able to do consistency
analyses of the major biomedical ontologies? (032)
> A methodology for a single tool such as OWL is a major step backwards
> from UML, from Zachman's ISA, and even from the pre-computer systems
> and procedures methodologies of the 1950s. (033)
I read: A methodology for capturing knowledge in OWL is a major step
backwards from a methodology for capturing knowledge in UML, and from a
methodology for capturing knowledge in the languages defined by the
Zachman Framework (of which there are none). Surely this is not what
you mean, because it is utter nonsense. (034)
As you see, John, this email leaves me very confused. I am very
encouraged by the existence of OWL and CLIF and supporting tooling, and
by the movement of the information analysis community in the direction
of formally interpretable models, and by the growing use of these
technologies in industry and government. And I think that understanding
the advantages and weaknesses of these technologies is important in
getting and maintaining credibility in those circles. And I believe
that that the practical aspects of expressiveness and computational
complexity are issues in that area. (035)
And I don't see the relevance of the Zachman framework to this
discussion. But then my "Oh Lord, Zachman again" reaction is nearly
knee-jerk these days. (036)
-Ed (037)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (038)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (039)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (040)
|