Re: SUO: OpenCyc Motion Open for Discussions
[ Sorry if this eventually shows up twice, but I sent it about a day
ago and it never showed up on the list, at least not in my mailbox. It
seems there's still something amiss with the list server. ]
Cathy,
At 13:53 2003-04-11, Cathy Legg wrote:
>Hi Randall,
>
>On Thu, 10 Apr 2003, Randall R Schulz wrote:
>
> > >The Cyc microtheories are organized into a partial ordering via
> > >implies, which is how you were describing the lattice of theories in
> > >your message to Radu.
> >
> > "Implies?" Do you mean material implication? What exactly does this
> > mean? That (#$genlMt #$lower #$upper) says that the conjunction of the
> > formulas in #$lower implies the conjunction of those in #$upper? That
> > the conjunction of the formulas in #$lower implies the disjunction of
> > those in #$upper (as if #$genlMt was a sequent: #$lower |- #$upper)?
> > One of these in the opposite direction, from #$upper to #$lower? None
> > of these seems sensible to me.
> >
> > I really don't get how #$genlMt is associated with implication. Could
> > you explain?
>
>If (genltMt SPEC GENL), then from SPEC Cyc can see (i.e. know about,
>use in inference) all of the assertions in GENL, *as well as* whatever
>assertions are explicitly made in SPEC. It is as though the assertions in
>GENL (both those made explicitly and those which it in turn inherits from
>its genlMts) Are virtually asserted in SPEC, ...
I know that much, but you said "The Cyc microtheories are organized
into a partial ordering via implies, ..." It is that statement
specifically I was asking about.
>... thus making it true in some yes, maybe virtual) sense that SPEC
>implies GENL but not vice versa.
I cannot think of any way in which this is true, unless you're
attempting to paraphrase what John Sowa wrote earlier in describing the
lattice of theories concept.
But regardless of my failure to understand your use of "implies" here,
your description is far from an adequate formal specification of how
the microtheory structure and mechanisms behave in Cyc.
> > (Maybe if we iterate this process enough, I'll get my answer to "what
> > are the semantics of CycL?" question.)
>
>This question was actually discussed some last year if I recall. Bill
>Anderson pointed out then that crafting a formal semantics for CycL is
>non-trivial given that the inference engine implements resource
>constraints (e.g. number of backchains, time-cutoffs etc.) These have
>recently become even more sophisticated due to a new inference harness.
That's the problem. And it's a big problem. I'm glad you're
acknowledging it. It implies, quite strongly, that a Cyc knowledge base
is only useful (only meaningful, in fact) when used in conjunction with
the Cyc inference mechanisms.
There's no way to know what a given set of CycL formulas means without
adding them to a Cyc system and then submitting queries to which you
expect that content to be relevant. Furthermore, in most realistic
cases (i.e., non-trivial attempts at knowledge engineering) it's not
possible to insulate one's own CycL content from other contents of the
Cyc knowledge base precisely because of the microtheory structure.
Consequently it is very difficult to get predictable results.
This property renders Cyc a huge monolithic system. I find it unruly,
if not unmanageable.
>If one wants to ascertain the semantics of any given constant, however,
>one looks at the #$comment (often quite extensive for core constants), and
>the rules asserted on it. And also *uses* it, and sees what it can do.
I'm afraid I don't accept ad hoc English descriptions as formal
semantic (proof-theoretic or model-theoretic, say) specifications.
Empiricism is a completely backward way to define a constructed formal
system. That we do so as much as we do is a major contributor to the
fragility, unreliability and unpredictability of current computing systems.
As I said before, saying "what Cyc does with it" doesn't cut it as an
IEEE specification for an ontology or an ontology specification language.
>Regards,
>Cathy.
Randall Schulz
H&S Information Systems