December 11-12, 2000
co-chairs: Frank McCabe, James Odell, Craig Thompson
OMG Agent WG homepage: http://www.objs.com/agent
OMG document: agent/00-12-01
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 www.cordis.lu/ist. 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.
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.
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.
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
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:
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.
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
The agenda for the Irvine meeting will reflect the above focal areas.