>From an outside point of view and going back to the original post by Patrick Cassidy:
I think knowledge actually only gets exploited for purposes. Necessity is the mother of invention. Its luxurious to have time to think about why this or that element or assembly process may work best, but you never really know what works together until you're solving a problem or expressing exact relationships. The real world always has odds and ends that don't fit within in a design scheme unless the whole design subtly changes or the miscellaneous bits are ignored.
If a module wonderland or supermarket was available to pick and choose the bake-off competition prize winning modules upon request, a truly global system would not only need to be conscientious about linguistics rules as John Sowa requested, but why not register geographic locations and knowledge domain particulars as well? There are too many strong feelings about meanings and interpretations on the front lines, more just plain facts and dispassionate machine derived connections need to be generated and pinned down too. There is all the time in the world to complete this sort of a record keeping system.
Last, regarding the "aggregates of modules whose combined performance is known"...Idea and information exchange is a two way street. Evolving complex data collections and the ontologies to understand them are only the beginning - more tools are needed on the receiving side. If my husband is showing off the new living room speakers, I only want to find worthy, fat recordings. If my kids are bored in geosystems class - get their attention and participation with the coolest maps and models, they don't know how to query large databases to put together their own maps. The interpreting side needs to define performance requirements too, only certain kinds of modules fit through the gates to plug in and play. All of humanity has only barely started to have such unlimited access and we are already sick of retrieving so many results and only spending time with the top 3 or 10 potentially losing better options too far below.
The English alphabet only has 26 modules with endless combinations, maybe there should be a limitation of 10 or 100 communication modules to interact with databases like Cyc. To best serve the most people, ultra streamlined multi-purpose modules should be initially comprised of the blue ribbon winners from a selection of languages, localities, and knowledge domains. There is plenty of time to fill in the blanks and work backwards to fine tune which data and ontologies are permanently stored, sent forth out into the world, and received for specific purposes.
Debbie MacPherson
Specifier, WDG Architecture
Projects Director, Accuracy&Aesthetics
On 3/21/07, Cassidy, Patrick J. <
pcassidy@xxxxxxxxx> wrote:Pat,
Re: Pat Hayes note (full text at bottom)
[PH]
> Pat, can you elaborate slightly on this :
>
[PC]
> >"... a much smaller set of basic concepts whose meanings are quite
> >well defined, and which serve to provide the basis for combinatorial
> description of all the more complex concepts."
>
Good questions. I was planning on writing something in more detail
before presenting the proposal to the ONTACWG, but this thread brought
the subject up before I actually put together a coherent description of
what I think might work. The following may answer part of your
question, if I have left out parts, do ask some more.
The kinds of definitions of restrictions that you present for
'allValuesFrom' are indeed part of the structural axioms that will have
to be part of a useful system. Both SUMO and Cyc have their own
versions that can be plugged into a FOL reasoner to get the kinds of
type restrictions on relations that are really helpful for spotting and
reducing logical errors. The convenience of starting with OWL is that
there are some built-in axioms of that kind that can help keep the
logic consistent even before the necessary switch to a FOL
representation. At this point I do not know which implementation of FOL
will prove easiest to work with, and all suggestions are welcome. I
like the Ontology Works IODE system, but that is far too expensive for
a public collaborative project. The SigmaKEE/Vampire looks useful,
though I have not done some experiments that I want to do to be sure it
has all that is needed. What FOL reasoner do you think will be
suitable for a collaborative project by people who don't have a lot of
time for dealing with the problems of flaky half-complete research
programs? A JAVA-based prover might be nice, if it's efficient enough
(anyone have experience with JTP?).
The heart of the issue of whether a "conceptual defining vocabulary"
(or "foundation ontology", FO) makes sense is:
(1) as you say, just what would constitute a "combinatorial
description"?
(2) figuring out what has to be in the base vocabulary, and how to
recognize it. The borderline may be a little fuzzy.
(3) What should we maintain in addition to the FO?
* * *
(1) combinatorial descriptions
The ontology will have a hierarchy, relations, functions, restrictions,
and other axioms. When someone wants to use the FO to specify the
meaning of a new concept, I imagine the process as being similar to
what is already done in SUMO, but with a determined effort to use the
existing elements of the FO, like this (we assume that the structural
relations, if not built in to the implementing system, are themselves
axiomatized in the FO).
(alternative suggestions welcome):
(1.1) for a new class:
(1.1.1) insertion in the hierarchy under the proper subsuming class
(1.1.2) add the new class to the range or domain of existing
relations, if appropriate
(1.1.3) create new relations that apply to that class (see 1.2
below)
(1.1.4) create new axioms (see 1.3 below) that describe the
implications of an entity being an instance of that class
(1.1.5) not sure if anything else is necessary here - any others?
(1.2) for a new relation (or function):
(1.2.1) defining the domain and range (or generally argument
restrictions for multiple arity relations)
(1.2.1.1) here it depends on whether your formalism permits a
'domainSubclass' or 'argGenls' to specify that an argument must be a
subclass of some class - in FOL we should be able to axiomatize such
restrictions. If not (e.g. in OWL), it may be necessary to create a
metaclass to serve as an argument restriction for relations having
classes as arguments.
(1.2.2) create the axioms that describe the implications of some
entity having that relation to another entity. Every relation should
have at least one implication to avoid being an empty symbol. I
provide a simple example below (A1).
(1.3) for a new axiom
write it as one would any FOL axiom.
(1.4) Now, the issue is whether all of the terms in the relations and
axioms that provide the meaning for the classes and relations are
already in the FO. If so, I would say that we have 'specified' the
meaning of the new term - to the degree of detail that we think
necessary - using the base concepts of the FO.
Then, I would anticipate that if I want to interoperate with another
system that also uses the FO but does not already have this new concept
in their system, I can transmit the definition. That system should
then be able to arrive at the same inferences from the same data. I
would consider that a level of interoperability that would be highly
desirable. Now, of course, there may be some things different in the
actual instance knowledge base of one interoperating system and a
second. Then the first system might arrive at some inferences that the
second system does not, but those inferences should be in addition to
the ones that the second system arrives at, and will not be
contradictory, unless the data itself is contradictory in the two
systems. Even after both systems exchange all the logical definitions
they use, a difference in the data input will not allow any guarantee
of *identical* inferences, but there should be no *contradictory*
inferences. But I think this method is as close as we can get to the
ideal.
(1.5) But if, in order to create the axioms that define the new classes
or relations, it is necessary to create other new classes or relations,
then the question will be: can the meaning of the newly needed class or
relation be 'specified' using the above process and using only terms
already in the FO? If so, we add that definition or relation along
with the first definition, and again we have specified the meaning of
the new term(s) using the FO, though the first newly added term is
defined in a recursive fashion. Importantly, FO itself needs no
supplementation. That will probably happen a lot, it seems to be the
rule rather than the exception for tests I do with the English defining
vocabulary. To truly define one specialized concept without fudging
may require several new concepts, but with the recursive use of
pre-defined concepts, the size of the ultimate FO may not grow very
fast.
I don't have any quantitative feeling yet for how many supplementary
new concepts will need to be defined in order to define one new
specialized term. One would suppose that it would decrease as the size
of one's local set of definitions increases, and I recall that Cyc
assumed something similar as the trajectory for how its base would
increase. Stats from Cyc history could be instructive here.
(2) How do we know when we really do need to add a new 'primitive'
concept to the FO?
I have three criteria at present, and more may be needed:
(2.1) If the only thing you can say about a class you want to define
is that there are certain subclasses (not themselves defined) or
certain instances, then this seems to be an undefined primitive that
might be useful (if anyone else wants it) in the FO. I have noticed
that ontologies are often built with the leaves being fairly specific
types ("crippled newsboy") that (SHAZAM!) the ontologist assumes
everyone will know, and will stand in for the instances of that type,
to give it meaning. If that class is not added to the primitives, it
will stand as an undefined class meaning nothing more than its parent.
(2.2) If you try to specify the meaning of a new concept, and you
need to add more than one class (or one class and a relation), but the
additional class or relation cannot have its meaning specified without
referring to the first new class (i.e. one can only specify the meaning
of one new thing by referring to another undefinable new thing), then
the related new concepts probably have primitive elements of meaning
and need to be included in the FO as new primitive concepts.
(2.3) If you create a new class and can only specify that it is
disjoint with some other class, then the new class is probably a
primitive.
(2.4
) these are my current tentative thoughts - other thoughts are
surely needed.
(3) What should we maintain in addition to the FO and its alternative
component modules?
I would want to also maintain a library of any self-consistent
extension modules that were defined using the FO, as units that can be
reused and be consistent with the FO. It might also be worthwhile,
once they are created, to maintain small self-consistent units that are
consistent with the FO but only use a very small part of it for
specialized applications. The reasoning of such systems should also be
consistent with those using a larger subset of the same extension.
Naturally, I would want to reuse as much as possible of elements
already existing elsewhere. There are doubtless many resources that
can be helpful, but I can only include them as I have time to search
for and evaluate them. If anyone else thinks that this approach is
worth a try, additional effort would increase the chances of something
useful resulting.
(A1)Sample 'specification of the meaning of a relation'
This is just one axiom, one might want to describe more detail
(where is the child before birth?), as the application requires.
This formalism used braces {x y z} to invert the order of the first
two arguments in
a KIF relation (y x z)
Rel: isTheBirthMotherOf
English def: The birth mother of a person is a woman who has given
birth to that person"
{{?Mother isTheBirthMotherOf ?Child}
impliesThat
(ThereExists {((exactly one) ?Event) and
((exactly one) ?Date) and ((atLeast one) ?Location)}
suchThat
{{?Event isa BirthEvent} and
{?Event occurredOn ?Date} and
{?Event occurredAt ?Location} and
{?Mother is (The Mother in ?Event)} and
{?Child is (The Baby in ?Event)} and
{(The BirthDate of ?Child) is ?Date} and
{(The BirthPlace of ?Child) is ?Location}})}
NOTE that all of the terms (such as the 'The' function and BirthEvent
and its case roles Baby and Mother) have to have been previously
defined.
Pat
Patrick Cassidy
CNTR-MITRE
260 Industrial Way West
Eatontown NJ 07724
Eatontown: 732-578-6340
Cell: 908-565-4053
pcassidy@xxxxxxxxx
> -----Original Message-----
> From: Pat Hayes [mailto:phayes@xxxxxxx]
> Sent: Wednesday, March 21, 2007 11:35 AM
> To: Cassidy, Patrick J.
> Cc: [ontolog-forum]
> Subject: Re: [ontolog-forum] Ontology and methodology
>
> Pat, since your idea seems to be getting some momentum, I will stop
> carping and try to be more constructive. But first, can you elaborate
> slightly on this :
>
> >"... a much smaller set of basic concepts whose meanings are quite
> >well defined, and which serve to provide the basis for combinatorial
> description of all the more complex concepts."
>
> I want to understand what you mean here absolutely clearly. What
> exactly is a "combinatorial description"?
>
> Do you really mean to have concept-combinators of some kind? Can you
> sketch what they might be like, or give some examples? Or say roughly
> how many of them you think will be needed?
>
> For a possible example, when we translated description logics into
> Common Logic, we found that the DL primitives could mostly be treated
> as relational combinators, which in CL can be functions on relations,
> so that for example the OWL restriction 'allValuesFrom' is a function
> from a unary and a binary relation to a unary relation, with the
> defining axiom
>
> (forall (c p x)(iff ((allValuesFrom p c) x)(forall (y)(if (p
> x y)(c y))) ))
>
> and OWL-DL then can be rendered as a smallish collection of these
> functions (more or less), but of course one can imagine others also
> being useful.
>
> Is this the kind of thing you have in mind? Or have I completely
> misunderstood you?
>
> Pat Hayes
> --
> ---------------------------------------------------------------------
> IHMC (850)434 8903 or (650)494 3973 home
> 40 South Alcaniz St. (850)202 4416 office
> Pensacola (850)202 4440 fax
> FL 32502 (850)291 0667 cell
> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
>
>
_________________________________________________________________
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
--
*************************************************
Deborah MacPherson
www.accuracyandaesthetics.com
www.deborahmacpherson.com
The content of this email may contain private
confidential information. Do not forward, copy,
share, or otherwise distribute without explicit
written permission from all correspondents.
**************************************************
_________________________________________________________________
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 (01)
|