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/ > msgid/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/CAHrUA36r01Q%3DKbXsJE3%2BS2KbpfQ3oZ5WD%2B-XY_dfPP6PCPhdEw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
