Monday, November 15, 2004

What future for FIPA?

A discussion is going on on the FIPA lists about what future that body should adopt for itself. There has been a vote to de-incorporate (if that's a word) from Switzerland, due to the high fees of doing business there. The FIPA board has been soliciting opinions as to what to do next. Below is a message I posted to the FIPA list, which, since it is moderated may not be accepted (because, to my knowledge, HP is no longer a paid-up FIPA member).

I'm not clear that I should really participate in this discussion, since I'm not sure that HP is a FIPA member any longer. Still, for as long as such a hard-to-ignore discussion keeps depositing itself in my mailbox...
It would seem to me that asking where should FIPA re-incorporate itself, or which parent organization it should join, is in danger of putting the cart before the horse. Surely there first needs to be a period of re-evaluation: what is FIPA really for? What are the success criteria? And has FIPA had as significant an impact it originally hoped? If not (and I would say that it hasn't), why not?
I was involved in the early days of FIPA, and one of the things that was explicitly and deliberately ruled "out of court" was a discussion of what an agent was. It was easy to see why that decision was made - the endless discussions of "by that definition, would a thermostat be an agent?" on software-agents list were seen as counter-productive to achieving practical progress. That decision was interpreted as meaning that anything is, or could be, an agent. This then effectively lead to FIPA's mission being congruent with "standardising distributed programming", which was far too broad to be useful. The recent discussion on this list about what an agent is means that this issue is still alive. FIPA cannot hope to settle the question of what defines an agent; indeed there probably isn't an answer. But it might make more progress in its work if it were to say "for the purposes of this effort, we circumscribe the kinds of agents we are talking about as ...".
Moreover, the original decision to "standardise" _applications_ of agents, as well as agent component technologies (such as the ACL), historically lead to a further dilution of effort (at least in the period to FIPA97, which was when I was most involved). However, while it is perhaps hard to see that the standards documents for agent applications have been directly beneficial to those industries, many useful discussions have taken place among the partipants. Perhaps that indicates one element of a future role for FIPA - as a body that fosters discussion and collaboration among researchers, rather than a standards body per se. Either way, some slimming-down of FIPA's activities might lead to greater energy going into the remaining projects.
Any discussion of the future of FIPA should also recognise that the world today is very different than that of 1995 (which I think is when FIPA started). Today, many of the infrastructure issues with which FIPA concerns itself are perceived very differently. XML is ubiquitous. HTTP is probably the most commonly utilised communications protocol. Architectures layering on top this foundation, such as web services, cover much of the same ground as the core FIPA specs. Moreover, the increasing use of semantic web technologies - RDF, OWL, SWRL etc - means that even the encoding issues covered by FIPA's SL are being overtaken. For example, how much more data is there available to agents in RDF or OWL, compared to data published in SL0?
I can't pretend to have answers to these questions, nor really any idea of whether and how such discussion should precede any decision made by the board. But it seems to me that a decision about OMG-FIPA vs IEEE-FIPA or whatever is rather crucially dependent on what kind of FIPA is desired by the members.