Re: SUO: OpenCyc Motion Open for Discussions
At 03:53 PM 4/11/2003 -0500, 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, thus making it true in some
>(yes, maybe virtual) sense that SPEC implies GENL but not vice versa.
>
>> (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.
Hi Cathy,
I recall this discussion from last year and I've been thinking about it again since reading this note.
I just looked up some of the notes related to last year's discussions (around April 9). Bill Andersen also appears to have suggested that we should leave the door open for declaring the formal semantics of CycL as something independent of inference engine behaviour and Pierluigi Miraglia, of Cycorp, appears to have agreed. (http://grouper.ieee.org/groups/suo/email/msg08287.html)
I'm beginning to think that this, i.e., distinguishing formal semantics from inference engine behaviour, is quite reasonable.. Consider an analogous problem. Suppose I want to find the whereabouts of all my second cousins. I hire a detective agency and it claims that it can do the job and will guarantee complete success if I give them 50 years and 50 million dollars. I baulk and they then offer me several lower priced deals that each involve constraining the effort, e.g., limiting the number of archival resources implemented, the number of detectives they'll use, the seniority of the detectives, the number of countries in which they'll look, etc. If I agree to a bargain-priced cousin-finder deal, I don't think that I've effectively changed the meaning of 'second cousin'.
Can't we say something similar about the formal CycL semantics, i.e., the formal semantics of CycL is the formal semantics of CycL regardless of how effective or ineffective a given piece of inference engine code is in generating output that is in accord with the semantics? As Bill Andersen noted last year, "... it [formal semantics of CycL, independent of inference engine behaviour] would create an open standard to which others could build implementations."
best,
Mike Pool
>
>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.
>
>Regards,
>Cathy.
>
>--------------------------------------------------------------------------
>Cathy Legg, Phd Cycorp, Inc.
>Ontologist 3721 Executive Center Dr., ste 100
>www.cyc.com Austin, TX 78731-1615
>
> download OpenCyc at http://www.opencyc.org
>--------------------------------------------------------------------------
>