[alicebot-developer] Conversation restrictions base on user id

[Kino Coursey]

I have something similar with the <gaurd> tag I added for CyN
http://www.cyc.com/doc/white_papers/Cyn_description.pdf
The difference is that the <guard> takes a general logical statement, so it
could trigger database lookups or logical inference. If it does not return
true, it backtracks to the next matching category. Using CyN (not yet
implemented but an easy fix), on the Cyc side each userid could have its own
microtheory detailing all the normal items and any logic that applies only
to that user. It could then control what information sources to use, how
much effort to extend, etc. Of course you still get regular AIML control.

The <guard> idea is not just limited to Cyc but to any thing you want to
hook up that can return true/false. It just wraps checking an external info
source and is experimental.

I believe program N has extended the set of contexts. The only issue is how
to set the variables/predicates based on userid. If you are doing things
with sensitive info you probably want a full or semi-full user security
model.

Hope you find it interesting,
Kino

-----Original Message-----
From: alicebot-developer-admin@list.alicebot.org
[mailto:alicebot-developer-admin@list.alicebot.org]On Behalf Of David
Sienkiewicz
Sent: Monday, November 15, 2004 12:21 PM
To: alicebot-developer@list.alicebot.org
Subject: [alicebot-developer] Conversation restrictions base on user id


I posted a question a few days ago or so I thought. It didn't show up. Oh
well.

As I'm working on developing a REXX-based program, I thought it would be
useful to develop a strategy that would restrict the bot's conversation
based on the userid of the person accessing the program. I see a need in
certain situations to prevent the bot from accidentally blabbing confidental
information all over the place. For example, let's say I have a Human
Resources benefits application, and I have many end-users, but I have one or
two administrators as well. It would be nice to be able to assign the
end-users the ability to inquiry on their own information, but not on anyone
elses. It would also be nice to allow administrator's the ability to monitor
any end-users data.  ...that's the best example I can think of at the
moment.

I thought that a combination of parameters set obtained from an "authorized"
user data base could be compared to a new keyword that could possibly be
added to <TOPIC> would perhaps be the most easiest way to accomodate the
situation. ...perhaps a "class of user" designation followed by a
"privledge" code of let's say, "read", "universal read", or "update".

The way I think it could work is that should the program see a mismatch
between the user data base and the topic, (and perhaps the category and
content), the program would select templates that would in effect steer the
conversation away from the confidental area, perhaps admonishing the user
for making such a query, and of course logging the security violation.

FWIW, I think this might be a practical feature that could be used ratchet
up the conversation in a realistic way to a new level of sophistication. The
bot would be making another choice of what it could discuss based on the
person it recognizes.

Dave S.


_______________________________________________
alicebot-developer mailing list
alicebot-developer@list.alicebot.org
http://list.alicebot.org/mailman/listinfo/alicebot-developer