Re: SUO Architecture
Bob,
I'd like to follow up on your comments. My thoughts are
below
At 04:03 PM 6/3/2000 -0700, Robert Spillers wrote:
Some miscellaneous responses to
previous comments:
Bill Andersen wrote:
- I have never quite understood (sorry, Bob) what Bob means
by
- an "API to a top-level ontology". Given that the
"ontology" is
- just a collection of axioms/frames, any API, such as the ones
- Mike described, would be as much an API for an application- or
- middle-level ontology as it would for the upper-level.
Bill, I agree that any useful API must apply to middle level
(domain/sub-domain) ontologies and application level ontologies as well
as the upper level. My point was that such an API should be
developed as part of the architecture so that a well founded API is
readily available to anyone who wishes to use it. Developers should
not be dependent on tool vendors - of course, if tool vendors have
more useful approaches the market will sort that out.
But what would such an API consist of? Would it be like OKBC, which
makes commitments to a specific frame ontology? Would it be simply
ask(statement) and tell(statement), or something different? Would
the API force a specific commitment in the ontology, or would they be
independent. I believe they should be independent.
Adam Pease wrote:
- Bob,
- I'd like to insert a note of caution here. The
notion of an
- architecture implies that there is another level of abstraction that
we can
- place upon the ontology, much the same as software architecture
uses
- packages or classes as a level of abstraction above code. While
I'm sure
- that we will have "modules" in the ontology in which we
keep related axioms
- (along the lines of CVS-based management that I was suggesting
earlier),
- the boundaries of modules will be more for the convenience of
development
- than any essential semantic property of the ontology.
-
Adam - yes, I do consider architecture a level of abstraction placed
on the ontologies (upper, middle and application). It can also be
modeled within the ontology. Any standard is a level of abstraction
placed upon the artifact it standardizes and the architecture for
ontology is a major part of its standard.
Specifically what would this architecture say? We might have a
microtheory/context structure like Cyc. That would mean that we'd
have a hierarchy of dependent content. That architecture would have
specific semantic impact on the ontology. We might also envision a
structure that has no semantic impact that is simply an arbitrary
delineation of "modules" or related content in the ontology
grouped for convenience of communication or collaboration. The file
based package structure in Ontolingua has aspects of both of these.
I'm a big fan of formal architecture using UML in object oriented
software design. Because of that orientation, I'd like to find a
parallel in knowledge engineering that has similar advantages in terms of
encapsulation, information hiding and the overall management of
complexity. I haven't yet found a parallel.
Could you say more about what you envision as the entities and the
relations in the architecture? Would they imply a semantic
commitment in the ontology?
- I'd also suggest that we not think of the ontology as
having an
- API. While we will have tools which use the ontology that
themselves have
- APIs, the ontology per se should be agnostic as to the mechanisms
used to
- manipulate it so long as those mechanisms do not violate its
semantics.
- To state this another way, I believe that the language
we use to express
- the ontology should have defined semantics that require a particular
type
- of nonmonotonicity, that is completely separate from issues of
versioning
- which is the province of the toolset we use to manage
collaborative
- development of the ontology, which may be unconcerned with the
content of SUO.
See my comment on APIs above. I am agnostic about the logical
notation as long as it is full FOL. The better known versions (KIF,
CGs, Cyc-L, FOPC, etc.) are completely translatable to each other.
Each has some engineering advantage that should be considered, but in all
significant ways they are the same. I know that Mike Genesereth,
John Sowa and Doug Lenat have, in the past, considered methods of making
KIF, CGs and Cyc-L completely transparent to each other (I think by using
FOPC as an interlingua) and have stated that there is no problem - except
someone needs to do the work. If a tool vendor wishes to use
something less than FOL, they can - but they must accept whatever
market consequences result - perhaps none, perhaps significant ones (good
or bad).
I'd agree that KIF, CGs, CycL and some generic notion of FOPC would all
be fine but that's distinct from discussion about an API. There
could be many different APIs which manipulate statements in those
languages. Some, such as OKBC, would have implications for the
ontology, others such as a minimalist ask/tell, would not.
I'm hoping that my characterization of OKBC in this space is accurate and
I'd invite comment from Richard Fikes as to how he sees this issue.
In my earlier note about
architecture I said that the API must "support both standard
functionality and new
functionality required by future applications. Information access
and update must be provided not only for first-order knowledge, but also
for higher-order, modal, non-monotonic, probabilistic and fuzzy
inferences." (e.g. see Bill Andersen's comments on
the possible need for higher order abstractions to account for model
changes)
This will require some serious effort and should not be left to vendors.
That consideration would bias me toward having a minimalist API that
makes no commitments for the ontology, and therefore does not constrain
it.
- To address another of your points, I'd agree that the
focus of the SUO
- is not on domain ontologies, and that those ontologies will require
expert
- input. The distinction though about what constitutes a domain
ontology as
- distinct from the SUO will be difficult to make, and worthy only of
general
- guidelines.
-
I agree that the distinction may be difficult to make but it is a
necessary one. We want to have clear, easy and standard methods
that allow domain ontologies to connect to the upper level.
Part of the architecture will require conformant domain ontologies to
provide the same methods to sub-domain and/or application
ontologies. This is another reason that the API and versioning
mechanism are a part of the architecture and apply to all conformant
ontologies.
Here also, I don't see this as being an issue in the domain of
APIs. For one ontology to make use of another, and inherit content
from it there needn't be any API. Ontologies in Ontolingua and Cyc
are cases in point. The API one uses to communicate with a KB
storing the ontologies is irrelevant.
Maybe we have some "semantic mismatch" with regard to the
meaning of "API". I think of an API being like the OpenGL
API or the API that is provided as a set of java methods for the SAX XML
parser. The API may be strictly functional or it may have side
effects but, much like SAX, it makes a particular commitment as to the
syntax defined, which in its case is XML, but it makes no commitments as
to the semantic content of whatever DTDs are used.
Adam
Bob
-----------------
Adam Pease
Teknowledge
(650) 424-0500 x571