Here: this page tells you about how to repesent the internal state of other speakers (this includes beleifs, demands, ettc.)
http://wiki.opencog.org/w/Claims_and_contexts ---linas On Wed, Mar 15, 2017 at 11:07 AM, Linas Vepstas <[email protected]> wrote: > > > On Sat, Mar 11, 2017 at 10:25 PM, Alex <[email protected]> wrote: > >> Hi! >> >> There can be modalities (which are usually expressed as diamonds or boxes >> (operators) in modal logic): >> DUTY_TO_PERFORM_ACTION(agent, action, time horizone) - agent should >> perform action within time horizon >> BELIEF(agent, statement, time instant) - agent believes in statement at >> the time instant >> > > > Wasn't this discussed in some other thread, just recently? > EvaluationLinks are the standard way of representing knowledge in opencog. > See wiki for that. > > Also see wiki about how to represent beleifs .. there is some section > there that discuses this, I don't recall where, or what it said. > > We've had prior discussions on the mailing list about representing > beleifs; but we only had a minimal discussion about reasoning over them. > This is one area that should be clearified, and if new PLN rules are needed > to handle this, then now is a good time to figure that out. > > --linas > > >> >> Such modalities are important in robotics (e.g. AGI safety - what duties >> and permissions robots have) and in communication (modelling other agent >> believes, knowledge and reasoning styles). >> >> Important point is, that by introducing modalities we also introduce >> additional axioms/meta-rules that connect modal statements (statements >> under modal operator) with the nonmodal statements and with the statements >> of other modalities (modal conversion). Example list of such metarules are >> available in https://en.wikipedia.org/wiki/Modal_logic. Such metarules >> sometimes are debatable, e.g. rule in deontic logic: >> DUTY_TO_PERORM_ACTION(agent, action)->PERMISSION_TO_PERFORM_ACTION(agent, >> action) and such metarules sometimes lead to paradoxes (classical deontic >> logic is full of them), nevertheless, such metarules expresses additional >> knowledge about reality. And such metarules can be mined and used for >> constraining inference process (inference control)! >> >> I have two questions regarding expression of modalities in OpenCog?: >> *1) how we can express modalities in Scheme/atomspace?* >> -- *One solution is to introduce new link types*. Is such introduction >> possible? Maybe OpenCog have GenericLink for which the user form derivation >> and for the derivation the user can define syntax (how many Nodes and of >> what Type are allowed in the new Link) and semantics (what processes are >> done, what is output and strenght values of the output)? I have not heard >> about such option; >> --* Another solution is to use PredicateNode*, e.g. belief can be >> expressed: >> PredicateNode "agent_believe" >> ConceptNode "Erving" >> ConceptNode "Door is open" >> The *question is - can be use other Node, Link, result of >> SatisfyingSetLink etc. in place of the literal "agent_believes"?* Or we >> are bounded for using literal constants in the PredicateNode? If former is >> true, then the system is open for the arbitrary set of modalities and the >> system can generate new modalities! >> >> *2) how we can express metarules for modalities in OpenCog*?: >> My proposal is to use rules that accepts some patterns of predicates and >> that generates new predicates: >> rule_body(obligation_predicate_type_nodes)->rule_head(new_ >> permission_predicate_type_nodes) >> Again - the question is about flexibility of the system: is the system >> allows generation of new link types or new predicate then the system can >> mine/generate the relevant rules for the newly generate modalities! >> >> Of course, I am studying literature, experimenting, thinking about this, >> but maybe someone also has thought about those questions and has already >> something done - it would be nice to hear thoughts, proposals and >> experience! >> >> Thanks! >> >> -- >> You received this message because you are subscribed to the Google Groups >> "opencog" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/opencog. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/opencog/f70e8da1-1147-41e9-8aa6-c2acbab14ce6%40googlegroups.com >> <https://groups.google.com/d/msgid/opencog/f70e8da1-1147-41e9-8aa6-c2acbab14ce6%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAHrUA37MLx6xFrEmiko6OAoZJeeQJjupOZw_cNYXiKpHC-HpgA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
