Minutes of Meeting #12

Minutes: Craig Thompson

Orlando, Florida
December 11-12, 2000

co-chairs:  Frank McCabe, James Odell, Craig Thompson

OMG Agent WG homepage:
OMG document:  agent/00-12-01



Cochair Election

Roger Burkhart (Deere) nominated Frank McCabe, Jim Odell and Craig Thompson as co-chairs of the Agent SIG.  Paul Kogut (LMCO) seconded.  White ballot passed.  So McCabe, Odell and Thompson are now co-chairs

FIPA Liaison Report, Francis McCabe, Fujitsu

In the beginning, FIPA was more concerned with plumbing and how agents related to agent systems and to infrastructure.  Now FIPA is moving its targets more to semantic topics including its abstract architecture, negotiation, conversations, ... including ontologies.  Discussed a few things in this area Also see FIPA Abstract Architecture Overview, Frank McCabe

JSR related to Java Agent Services, Francis McCabe, Fujitsu

See  This is a community creating a Java spec for the FIPA abstract architecture.  There are already some Java implementations of FIPA - Nortel FIPA OS, Celt Jade, and British Telecom Zeus.  The JSR will not immediately construct a Java FIPA toolkit.  The initial capabilities are message transport and directory search (model related to LDAP).

UML Models for DAML Ontologies, Paul Kogut and Bill Holmes

See agent/00-12-02.ppt,,

This is a DARPA program started in August 2000 and will run to 2002 or beyond.  Adding semantics to XML, RDF, RDF Schema to create a more semantic web.  Includes Tim Berners Lee.  The European Union IST program is involved - see  DAML is developing the language, tools for checking ontologies and annotating webpages, even ontology translation, trial applications in govt and commercial.

DAML sits on XML, RDF (adds relationships), RDF Schema (adds classes and subclasses).  Precessors of DAML are SHOE, OIL, others.  Some issues are:  closed world assumption, non-monotonic vs monotonic.  Circa October there was an initial DAML spec and examples plus discussions and formal specs.  Adding rules and reasoning in 2001.

Three projects working on UML and DAML in some way.  UBOT is exporting UML/XMI converted to DAML.  Stanford OntoAgents. Missed the third.

Starting with UML models, Kogut can extend an existing ontology.  Can translate the UML model to DAML.  Working on developing UML profile for DAML.  Want to go bi-directional, forwards from UML to DAML and back from DAML to UML diagrams. UML to DAML is easier, DAML to UML is harder.

Appears to be overlap with OMG Agent UML effort.  Interest in combining forces.  See Next Steps discussion.

Agent UML, James Odell

See agent/00-12-03

See previous meetings' minutes for some context on Agent UML.

Some possible UML extensions for social structure:  role, group, environment, ...

Role:  Discussed all sorts of meanings of the word role.  Is class and role the same level of abstration?  Can roles have instances?  Can roles have attributes?  Can only agents have roles, not objects?  Are roles views of entities?  The notion of a class playing a role - a rake, hoe, ... playing the role of a line item on an invoice.  Examples are brokers, retailers, generals, privates, ... all have roles or interaction patterns.  Is it tied to the notion of encapsulation, legal entities, contracts, legal entities that can say yes or no?  Linguistic nominalization is relevant.  Roles on teams as forwards in soccer.

Group:  is composed of roles, as in a soccer team.  The team has an obligation to win. ...

We just flat ran out of time - we covered just 2 or 3 of 20 foils Jim had prepared.  Everyone is interested in this area.  See Next Steps discussion.

Management of Event Domains, Tom Urquhart

See agent/00-12-04

Why we requested this presentation:  some in Agent SIG are interested in domains and policy management for agents.  So we wanted to see how the OMG Event Domain Management spec approached the problem.

Background on notification service:  OMG Event Service was a low level means of providing asynchronous computing.  OMG Notification Service added filtering and content based routing, QoS on events and event channels, and structured event types.  Supports push and pull models as well as proxies.  Both are publish and subscribe.  Semantics is at least once.  Java supports queue-based.  A structured push/pull sends structured events as opposed to just any.  Sequenced push/pull send many events together.  In Telcom applications, you get complexes of events - really a partitioned, federated collection of notification service instances.  Limitation of notification service:  lots of low level things to do to set up these federations but these are provided for you by the idea of Managed Event Domains in the new spec.  The new spec provides warnings on Diamonds and Cycles (at installation, not run time) -- common situations in graphs of channel subgraphs.  Also handles propagation of subscription information.

Event domains contain channels that may or may not be federated or might just be collected together.  Supports typed logs.  Simpler to federate channels into one operation, connect client in one operation.  API creates event domains, and adds and deletes connections, and raises exceptions.

The messaging service is another asynchrnonous messaging capability, not directly related at present.  The event-notification-domain family of specs does not provide an API for queuing.

Next step is interoperability with Java Messaging Service (purely client side) that supports queuing.  EJB 2.0 will contain a messaging bean.  Also relevant is CORBA SOAP that can message across the firewall.  Q: do you prefer SOAP over HTTP tunneling?  A: need both.

Q:  How are Event domains related to Security domains.  Not really sure but probably group one kind of domain in the other.

Overview of Agent Mobility, Niranjan Suri, UWFlorida

See agent/00-12-05

This talk was invited to provide depth in a specific area, one of possibly several needed to support the full range of potential agent capabilities.  Agent SIG is considering a focused effort in this area.

User directed or autonomous agents.  Primitives are

Mobile computation and code gives weak mobility.  Mobile computation and state is process migration.  Strong mobility is all three, the most general.

IBM Aglets provides weak mobility - lots of changes in code.  Strong mobility can be as simple and seamless as inserting Go(Destination) into the code, e.g., Java.  Agents in client and server environments, moving agent can lower latency, reduce network bandwidth, and disconnected operation - esp in mobile phones and going thru tunnels for instance.  Can unload currently unused services.  A universal server is a barebones server where all capabilities are downloaded.  Generally supports dynamic and flexible systems.

Agent mobility paradigms:

Architecture - components needed: Languages:  Java, TCL, C/C++, Lisp, Telescript.  Java has several advantages.

Java has no state capture, no resource control or accounting, ...  Other issues:  finding an agent (chasing it around), agent anonymity, ...

Some applications:  info retrieval as in Dartmouth.  Monitoring.  Remote control.  Active mail - send executable content as email.


Commercial Systems Nomad system - Java-based agent systems often rely on JDK, assume agents are safe, rely on code signing.  Nomad goal is to build secure execution environments where you can run untrusted or partially trusted code.  Core component is Aroma clean-room implementation.  No AWT/Swing support, proof of concept.  But can control resource usage.  State capture is full VM state or individual thread state.  Talking to Sun which is interested in the resouce QoS capabilities and maybe more for a JSR.

FIPA Abstract Architecture Overview, Frank McCabe

See agent/00-12-06

FIPA abstract architecture is an architecture for interoperability, not really an agent system architecture, more a gateway architecture aimed at end to end interoperoperability between agents and agent systems.  Abstract .NE. concrete architecture - does not specify specific comm layer or directory service.  Not doing brokerage or ontology.  This is the core, what would be in every agent platform.  Goal is to model systems in distributed systems like Java or CORBA.  Also wanted to facilitate reuse in existing systems, more in principles than lower level.

Note:  in early 2000, FIPA introduced a new process - preliminary, experimental and standard specs.  The older specs were mostly grandfathered in as experimental - e.g., including agent platform and ACL .  FIPA sees CORBA as one platform, Java another.  A concrete architecture might use LDAP as a directory service.  Also, expect standard way to use LDAP so concrete architectures too.

Some things were hard to do at the abstract level:  management and lifecycle of agents, security, mobility.  Some things need more work:  gateways, domains, policies.  Conversation policy as a subclass of policy - constraints on who you can talk to and what you can say, like interaction policy.  FIPA mobility was not grandfathered.  Nor was ontology spec, which Frank things needs updating and there is substantial interest in FIPA to do this.

The FIPA abstract architecture

Next Steps and Next Meeting, Craig Thompson

Agent SIG is newly formed from Agent WG, which had completed a green paper and a roadmap.  So what are the concrete next steps of Agent SIG?  Yes, we are interested in eventual RFPs but there are not a lot of agent vendors out there or participating so our work is likely to be anticipatory.  We need to do the following: We did not discuss the second topic much (we still need to) but mainly focused on the first.  We decided the following efforts are worth focusing on at the next OMG Agent SIG meeting (Irvine, February 26-March 2 2001): The above choices should not preclude other topic areas - others are invited to propose and champion mini workshops and working groups in other roadmap areas.

The agenda for the Irvine meeting will reflect the above focal areas.