classic-KQML, KQML-94, and ACL.
Sankar <sankar@fcrao1.phast.umass.edu>
Date: Tue, 30 May 1995 10:06:55 -0400
From: Sankar <sankar@fcrao1.phast.umass.edu>
Message-id: <199505301406.KAA12228@fcrao1.phast.umass.edu>
To: mustafa@hpdce.stanford.edu
CC: vishal@cs.stanford.edu, kqml@cs.umbc.edu
In-reply-to: Mustafa Syed's message of Tue, 30 May 95 1:07:55 PDT <199505300804.EAA11590@fcrao1.phast.umass.edu>
Subject: classic-KQML, KQML-94, and ACL.
Sender: owner-kqml@cs.umbc.edu
Precedence: bulk
OK. I am forwarding a note I sent to Omar a while ago (and to this
list). Please refer to point 12 in Mike's note. Please note that there
are about 15 problems that he brings up. Also, please note that we
have brought this problem for public discussion several times, while
at the same time trying to adhere as much as possible to the
"official" KQML 94 standard.
Sankar
-----
Date: Tue, 14 Feb 1995 19:57:04 -0500
From: Sankar <sankar@fcrao1.phast.umass.edu>
To: ozz@leland.Stanford.EDU
CC: kqml-developers@cs.umbc.edu
In-reply-to: Omar Ahmed Tawakol's message of Tue, 14 Feb 1995 16:12:35 -0800 <199502150012.QAA26523@elaine27.Stanford.EDU>
Subject: kqml classic
Cc: 75024.571@compuserve.com
Sender: owner-kqml-developers@cs.umbc.edu
Precedence: bulk
Omar,
I have attached a note from Mike Webb, one of my collaborators for
your purusal.
You may think that we are pushing for KQML current because that is the
"current" standard. That is one of the reasons. You seem to
think that we want to work with real users - not developers. You used
the word user to refer to us - when I used the word user, I meant
users of KQML based applications - not developers - we are all
developers - not users in my definition. That is also another good
reason.
Maybe you also think that we are afraid of losing momentum gained at
OMG for standardization of KQML (through a commercial, vendor
dominated process - the real buyers of this technology, if it has a
chance of succeding in the market place). Well, you are right.
But there are technical reasons for what we said. In our evaluation,
KQML classic does not address the problem it attempts to solve. In the
middle of the long note from Mike Webb you will find what he feels
about KQML classic.
Additionally, Mike Webb's note refers to some of we want addressed
immediately. At Pal Alto the group that you and I were part of came up
with a list that had atleast 20 major items in addition to Mike's
list. KQML classic vs. KQML current is one of those. So, there is a
need to hit the important ones (prioratize, prioratize,...). In our
opinion, the KQML classic vs. KQML current is not the most important
issue. Just doing what Mike Webb wants to happen will take a while.
Hope this helps clarify things.
Sankar
P.S: SLOTH is our implementation of Scheme.
-------
Here are some thoughts about KQML in general. Most of this
is rehash.
1. Need to specify standard error codes for KQML. Without
this, there will be no agreement between any two KQML
implementations on the semantics of particular KQML error
codes. I would further suggest that the error :code be
generalized from <number> to <word> to use symbolic KQML
error codes. We currently use:
kqml-unknown-error
kqml-duplicate-sentence
kqml-contradictory-sentence
kqml-no-delete-authorization
kqml-no-insert-authorization
kqml-no-comprende
kqml-undeniable-performative
kqml-broken-arg-list
2. Desparately need semantics/syntax for the content of tell
when :language is KQML.
Using Sloth's relationship syntax, this would be
something like:
((<object> <slot-name>) <value>) ; Slot accessor
(<symbol> <value>) ; Symbol binding
(<symbol> <property-name> <value>) ; Symbol property
In Sloth, I can apply set! to the first two and putprop
to the third (length seems to be a sufficient
differentiator). In CLOS, I can mangle these lists
into appropriate arguments to setf (et al.). If I
remeber Prolog-ish syntax, the slot/prop name can
be sucked out as the relation and applied to the value
and object/symbol. Relatively simple list mungery
gets this syntax into a useable form for lots of
different (KQML implementation) languages.
Using a relation-like (Prologish) syntax could be
something like:
(<slot-name> <object> <value>) ; Slot accessor
(<property-name> <symbol> <value>) ; Symbol property
???????????????????????????????? ; Symbol binding
The problem with these is that there is no good way to
differentiate between slot accessors and symbol
properties and no way at all to do direct symbol
bindings without introducing a bunch of keywords.
A mechanism for aggregating a bunch of these together
in a single tell would also be useful (but somewhat
difficult for the Sloth relationship syntax if a simple
list is used - we toss in a throwaway symbol at the
begining of a relationship to do this in Sloth (you
can think of it as "and")).
2a. Standard ontologies in a standard syntax are essential
so that KQML (facilitators) can talk about addressees,
languages, performatives, ontologies. Addressees (agents)
have capabilities. They support a particular set of
languages and ontologies. They can talk to specific types
(and/or individual) addressees. They may have restrictions
on their implementations of specific performatives, or
performatives in general. Etc. Without standardized
tell/untell syntax and standard ontologies (and ontology
syntax), facilitation is restricted to overly homogenous
KQML networks because there is no way for two heterogenous
KQML networks to share capability information. As it
stands now, different KQML implementations can only
reliably exchange very rudimentary information (i.e. the
values of :ontology, :language, :sender, :receiver).
Some useful common ontology concepts are:
- Address spaces. Specific addressees. Sub-net vs
internet structures. Transport types. Node roles.
Users (i.e. people) as addressees vs agents as
addressees.
- Languages. What languages does a given agent
understand? What restrictions apply (e.g. :content
length limit).
- Ontologies. What ontologies are available? What
is the schema for an ontology?
- Agent capabilities. Blackboards. Facilitation.
Translation...
2b. Addressees need to be <list> | <word> instead of just
<word>. My primary interest here is that while <word> is
sufficient within a sub-net, many sub-nets connected by an
internet (in the generic IP sense, not the ex-ARPAnet
sense) greatly increase the number of accessible addressees.
This means it is quite likely that no local node knows
anything at all about the desired addressee. On the other
hand, there may be local nodes that can send the packet to
an internet router... I propose that list addressees of
the form:
(<internet-name> <address-expr>)
be allowed. The <internet-name> is the <word> for a given
internet and <address-expr> is an <expression> (ala the
content of the transport-address performative) for routing
the packet within the internet. For example:
(internet-mail "mjw@crystaliz.com")
Any given sub-net has (at least) one bridge to each
internet. The bridge node may be different for each
internet connected to the sub-net. I want to avoid the
need to have every node "know" something about every other
node in the universe. In the current KQML definition, at
the very least, each internet bridge has to advertise that
it can send to the entire set of nodes in the internet to
each of the other nodes in the bridge's sub-net. With
millions of Internet addresses (in the ex-ARPAnet sense) in
the world, the current model (addressee as simply <word>)
won't work: we'd need millions of symbols for addressees in
each agent to be able to do a routing chore already handled
by The Internet.
3. The database performatives are really too application
specific. My main complaint here is that it is too easy to
subvert the intent of these using the evaluate performative
with exactly the same content. These should be relagated to
specific ontologies or content languages.
4. Multi-response performatives are a kludge to get around
lack of capability in a specific content language (KIF).
It would be much better to do this by defining procedural
semantics for KQML itself (especially e.g. list manipulators,
cond) or by having this functionality in the content language.
Spreading this stuff out over many performatives will badly
break TPS. Adding procedural semantics to KQML would:
- Satisfy the requirement to manipulate responses (e.g.
breaking a single large response into multiple smaller
responses).
- Add the capability to cluster KQML performatives to
contain short transactions (ala progn in Lisp).
- Provide the capability to write adaptive queries (i.e.
future actions are determined by intermediate results).
- Give us a common, Turing complete agent language so
that more complex queries (than can be achieved with
KQML today) can be universally processed by any KQML
implementation.
IMO: A somewhat better way to handle these problems
would be to specify a simple universal content language.
In practice, this would need to be a superset of KQML,
but keeping the Turing complete language divorced from
the KQML protocol greatly simplifies things like trying
to hook KQML into CORBA. For example, KQML (i.e. the
existing performatives) can be implemented as an object
adapter that can talk to any number of CORBA scripting
component object adapters (one of which presumably would
be for the universal agent language). It seems to me
that notification semantics, object semantics and rule
semantics are necessary features of this common language.
5. Effector performatives are too application specific. They
assume that any KQML system can synthesize new knowledge.
Better to leave this to ontologies/content languages.
6. Semantics of ask family require backward chaining. Does
this make them ontology bait? My concern here is particularly
for OMGoid KQML implementations. It may also be a problem for
virtually any generic programming language used as content
or implementation language (i.e. Lisp, C, C++, STEP Part 22,
... don't usually provide tools for finding out what all the
symbols are to be able to backward chain). On the other hand,
things like Prolog, SQL, Sloth (given the rules system), ...
can accomplish enough backward chaining to actually do the ask
family. On the flip side, doing asks when the content
language is KQML and ontology is { addressees, ontologies,
languages, performatives } is massively useful in
facilitation... The real underlying problem is that I have
never really understood what the semantics of the ask family
should be.
7. Name conflicts with implementation languages. All KQML
symbols should begin with kqml- to prevent name conflicts in
implementation languages with a KQML-like syntax (e.g. Lisp).
We currently have name conflicts for error and delete.
8. Need to add something like a :secure-key (optional) parameter
to most performatives to provide secure access. I can envision
using this to contain:
A. <t> or <nil>. If <t>, the receipient should use the
'standard' encryption/decryption key(s) associated with
the addressee. The use of <nil> (default) implies no
security action.
B. Any <word>. For example, friday-key. This way,
addressees can have multiple encryption/decryption keys
C. A sting containing an encrypted Kerberos-style access
cookie.
D. A keyword driven list to combine B and C. For example:
(:named-key friday-key :access-cookie "abcdefabcdef").
Alternatively, two new performative parameters could
be introduced to all performatives (:secure-key and
:access-cookie).
9. The current advertise model is too bandwidth intensive. Nodes
will spend too much time receiving ads for things they aren't
interested in and cluttering up the net with info others could
care less about. On the flip side, it might take an agent
weeks to send all its junk mail to every user/node on The
Internet (and then The Internet user community would probably
descend on that site en-mass and obliterate it). Need a more
peer-to-peer friendly approach. Agents might "advertise" the
fact that they need some particular information. Nodes that
have such information "reply" with something advertise-like.
We've called this "brag" before - but the key idea is that adds
should be solicited. Another possibility is to set up
blackboard agents ala "the classifieds". People needing a
service can post "want ads". People providing a service can
leave their service ad.
10. It seems likely to me that in addition to the current pipe
and break, it would be useful to have fork and kill
performatives. Is this a service that it is OK for users to
request of an agent, or should this be an implicit service
of some agents (who then use pipe/break to redirect)? The
hazard of fork and kill is that this winds up being rather
virus-like. The problem of pipe/break is that it seems to
have semantics that are too global (i.e. I'm going away now;
use this agent instead), rather than my desired semantics of
managing state for a response to a particular query.
11. Need to specify semantics of the facilitation performatives.
I have the requirement that the -all flavors need to be able
to pick apart a request into its constituents and do the
query decomposistion and answer-recomposistion. Is this the
intended semantics? If not, we need more performatives.
12. Need to reconcile required parameters with embeded
performatives. For example, subscribe takes a performative
as its :content. Which :sender, :receiver, :ontology, ...
are the "right" ones to use? The ones in the subscribe, or
the embeded performative?
- Stanford (Mike G)wants to "solve" this problem by sucking some of
the parameters out into a "wrapper". This won't help.
Think about forward. Forward really needs the addressees
(:sender, :receiver) right in the performative or else it's
too hard to figure out when to stop recursing. It also
seems like excessive overkill to wrap each layer of
recursive forward in a kqml-package just to do the
performative wrapping in other cases. Is forward now a
special case of the wrapper? What about embeded
performatives in general? Both subscribe (or pick any
performative where an embeded performative is a reasonable
expectation) and its embeded performative might need the
:reply-with, :force, ... parameters. Do these come out into
the wrapper too? If not, which ones do I use when there is
overlap? What happens if the embeded performative contains
an embeded performative (recurse this question ad-nauseum)?
By the time the wrapper approach has been taken to its
logical and necessary conclusion, you've sucked essentially
all the parameters out of the performatives and put them in
a wrapper. In this case, what's the point of the distinction
between wrapper and performative? Oh, by the way, guess
what guys: you've just re-invented your original problem
(i.e. how do you resolve overlap between parameters in
nested wrappers?)! In addition you've horribly mangling a
simple syntax along the way! Scientific Principles - pifle.
Aspirants to Chordata.
- The only approach that will work is to specify semantics
(FORMAL SEMANTICS - if you want Scientific Principles (of
course damn few people in this buisness have read Stoy...))
for KQML. We've come accross several people now that had
the initial reaction to the KQML spec that a conformant
implementation didn't need to do anything (mjw, jjm, Jim
from OSF/RI)! By specifing:
o Minimal acceptable/expected behaviors for each
performative.
o Analysis of optional vs required vs bogus parameters
(e.g. :ontology in forward seems absurd; :language
seems silly too, if :content is always a performative).
o Specification of defaults values and expected
behaviors for these defaults for the parameters. The
Stanford proposal is easily handled by having:
a. Embeded performatives inherit values for omitted
(required) parameters.
b. Omitted parameters default to reasonable values
(i.e. lack of :sender/:receiver means "the current
agent" should fill the omitted role). A reasonable
default for :langauge is KQML. Don't know what a
reasonable default for :ontology is yet (probably
the ontology that describes { ontologies,
addressees, languages, performatives, ... }).
o Standard error codes.
o KQML-level support so that agents can self-describe
themselves in KQML (rather than in some non-universal
content language) to other KQML systems. I.e. what
are the semantics and syntax of tell when :langages is
KQML? What is the syntax of the common ontology
descriptions. What are the details of the ontologies
that KQML systems need to know about (addressees,
languages, ontologies, performatives, ...).
mjw
_______________________________________________________________________
Send mail to majordomo@cs.umbc.edu to subscribe/unsubscribe to the kqml-developers
mailing list. Send a message with the body "help" for more information.
Archives are at http://www.cs.umbc.edu/kqml/mail/
_______________________________________________________________________
Send mail to majordomo@cs.umbc.edu to subscribe/unsubscribe to the kqml
mailing list. Send a message with the body "help" for more information.
Archives are at http://www.cs.umbc.edu/kqml/mail/