Raw

Jim Hendler asks a question that's currently close to my heart: So where are the agents? :

We have RDF and OWL which provide a KR language that is certainly capable enough for many agent applications. We have tens of thousands of ontologies that make domain engineering easier. We have many large Web providers that make access to their systems available through some sort of service interface or in easily wrappable ways. We have XML described databases, as well as SPARQL endpoints making data query for agents more accessible.



What we don’t seem to have is agent-based systems in any serious way!

As is usually the case, I don't think there's a single answer. Definition for an agent? One might be - a system which acts autonomously on your behalf. By this definition, many of the web systems we use on a daily basis are agents. In Jim's post, he mentions other characteristics traditionally associated with agents: a knowledge representation language; a system for interoperable communications. Implicit is the notion that the agents will carry out some kind of activity.

Web systems have all these aspects: they have knowledge representation, only it's usually domain-specific, and tends to be locally defined (through internal objects, SQL schema and the like). The interoperable communications are over the protocol of the web, HTTP (usually through a semantically narrow tube like HTML or RSS). The activity is implemented internally using the programming language of choice.

But as Seth Ladd suggests, this definition involves a major lowering of expectations:

I don’t need an agent that can continually run Google queries and let me know if something new was found. That’s not an agent, that’s a cron job, and that’s a simple task.

Ok, this is an expansion in the definition. The kind of agents found in traditional agent frameworks don't do much more than simple tasks individually, but in combination they will hopefully do something Seth would call useful. There's a nice symmetry here with Tim Berners-Lee's talk of fractal ontologies. Components can themselves be composed of parts of varying sizes and the system as a whole appear the same shape from a high level or zoomed in. But although the current web can be viewed as an agent framework in itself, it's severely sub-optimal. At best systems like Pipes are the exception, not the rule.

~

So anyway, here's why this stuff is close to my heart. I've probably mentioned most of this here before, but still... There was a requirement for simple agent-style communications between subsystems in my dayjob work. In the first prototype we used JADE, which is a nice agent framework, only we found it fragile and rather heavyweight for what was required. Out of the box it uses relatively obscure knowledge representation languages and protocols.

I'd played with agent systems before, but not for a long time, and I'd forgotten how cool (and intuitive) the general paradigm is. The obvious answer for the dayjob app to me was to use the agent paradigm, but in a framework based on the current state of the art in the different areas: RESTful HTTP-based communication; RDF/OWL based knowledge representation; behaviours defined in a scripting language.

Another member of the team and I put in proposals for JADE's replacement. I made a simple HTTP-based prototype, they sketched out a J2EE-based solution (the rest of the system is generally J2EE based). My approach stalled because of the question of async messaging, something that doesn't come free with servlets, but with J2EE the answer comes with JMS.

Although my approach wasn't taken up for the application (probably the right decision in retrospect), it did allow me to spend paid time to make a start on figuring out how to build HTTP+RDF agents. (Pretty convenient given my shoestring, hand-to-mouth lifestyle).

Since then I've continued working on the problem when I get a free minute, and am aiming to have something useful running in about 3 months (right now it's a hodge-podge in my own svn repository, I'll move it to somewhere like sourceforge when it's mature enough to do stuff). There have been quite a issues large & small I hadn't anticipated, but I'm dealing with such things as they arise (like the async aspect, which for now I've covered with with Quartz). Project working title: "Agency". I'm got web-style distributability of systems as a high priority, but agent mobility is way down the list of nice-to-haves. Architectural philosophy based on the Three 'U's : URIs, URIs, URIs.

My typical agent will be comprised of (access from) a HTTP server, a HTTP client, an RDF model and local behaviours. It's largely irrelevant whether it runs on the server or a desktop. I've opted to build the framework parts in Java (familiarity & good libs), with the aim of using arbitrary scripting languages through BSF for application code (the behaviours) - I'll probably start with Python.

The idea is that an agent can operate solely through HTTP interfaces, but if a bunch of agents are in the same VM more direct comms will be used. The intention is for each agent to only cover a very small amount of functionality (e.g. Seth's cron job), and generally be as encapsulated as possible - although it seems likely the use of a blackboard(s) will simplify some aspects. There will be a cost involved in having a lot of components and their interconnection. But I'm hoping this will be offset (and more) by the architectural simplification, and the advantages of selectively bringing data to be processed close to the code that will do the processing (every agent instance will operate on its own local RDF model).

Although I am intending to create useful apps with this, a big part of my motivation is that from the outside these agents should be indistinguishable from current web systems. In effect I'll have a web-in-microcosm to play with...

So anyhow, I'm really pleased Jim's asking about agents, it's kind of validation that I'm looking in a area that needs looking at.

@en