thoughts from FOSDEM, status

[Scott Wheeler]

Ok, so it's been three weeks since FOSDEM, but I've been meaning to send out
an update of sorts since then (and no, Sevtap, I really didn't forget that I
said I'd do a follow up -- I'm just disorganized).

There were a few interesting things that came from my FOSDEM talk --

*) Mindshare is growing a bit, in a way that I'm mostly happy with. Most
people aren't really sure what it is that we're working on, but they know
that it's supposed to be cool. That's a good thing, since I think explaining
some of the ideas is a bit tough when you can't sit people down for an hour
and go through the details, and "it's supposed to be cool" is probably better
than random misinformation.

*) The talk was very well attended given that it was just a "KDE development
room" talk rather than one on the main schedule. There were 100 chairs in
the room and most were full with a fair number of people standing.

*) The questions phase went for over half an hour -- there were a lot of
questions about RDF and things related to semantic webs and how this is
similar or different. This is part of why I'm reading up on such things at
the moment.

*) One of the more interesting questions was from Sevtap -- and I thought it's
something that K?vin would find interesting given his research in multi-agent
systems. K?vin and I talked a bit about this right after FOSDEM, but it's
worth repeating here:

Essentially Sevtap's question (and feel free to correct me) was along the
lines of, "Why not move the query logic into applications rather than a
central place?" Essentially querying the applications as "agents" and
having them return things as such.

I'm not sure that it's a practical approach, but it's certainly an interesting
way of looking at the problem, so it's worth thinking about. Practically
speaking there's the problem that the applications not running all of the
time, but K?vin kind of jumped to the idea of applications having parallel
"agents" that come from the application. From my side -- independent of how
these are organized this led to the idea that it probably makes sense to have
plugins that can come from applications for query logic, much in the same way
that KFileMetaInfo can abstract away retrieval logic. This isn't immediately
useful since we're still a fair number of steps away from that, but certainly
an interesting way of looking at things.

Ok -- so, post FOSDEM -- while I haven't been coding on this stuff for the
last while, I have been reading quite a bit. Specifically:

*) Practical RDF -- from O'Reilly. Just some of the basic structural stuff,
naturally light on theory. Just wanted a crash course in RDF semantics, and
it's been somewhat helpful (though I'm not sure I would recommend it). The
more I learn about RDF the more I tend to believe those that told me that it
wasn't really all that useful for KLink like structures, but "somebody else
told me it's irrelevant" is hardly convincing when you're fielding questions
after a talk.

*) Ontology Learning for the Semantic Web -- again, recommended by K?vin --
who seems to be our resident academic on these topics. I think the point is
mostly on building "bottom-up" ontologies rather than "top-down" ontologies.
Or something like that. I'm not that far into it yet as it's rather slow
reading for someone not already involved in the field.

*) Essentials of Cognitive Psychology -- this hasn't actually arrived yet, but
should shortly. Since I'll be travelling a lot in the next couple of weeks
that means lots of reading time and I'd like to pick up a bit on basically
how people remember stuff as I think that may be useful down the line.

Right now I've printed out quite a lot of the older design related stuff and
am spreading it out on my living room floor to see if it all still makes
sense and what needs to be updated. I'm hoping to update the design document
tomorrow (as its terribly out of date) and possibly to attempt to harmonize
some of our vocabulary with that which is in use in academia. I'd like to
get back to coding too. We'll see how the time goes.

Cheers,

-Scott

[Kévin Ottens]

Post by Scott Wheeler
*) Mindshare is growing a bit, in a way that I'm mostly happy with. Most
people aren't really sure what it is that we're working on, but they know
that it's supposed to be cool.

Ah-ah! I'm not so lost in fact! =)

Post by Scott Wheeler
That's a good thing, since I think
explaining some of the ideas is a bit tough when you can't sit people down
for an hour and go through the details, and "it's supposed to be cool" is
probably better than random misinformation.

I hope we'll be able to sit around the end of august this year. ;-)
*hint* Malaga *hint*

Post by Scott Wheeler
*) One of the more interesting questions was from Sevtap -- and I thought
it's something that K?vin would find interesting given his research in
multi-agent systems. K?vin and I talked a bit about this right after
Essentially Sevtap's question (and feel free to correct me) was along the
lines of, "Why not move the query logic into applications rather than a
central place?" Essentially querying the applications as "agents" and
having them return things as such.

Where he's right, is that it'll be far easier to design the logic for each
application... you basically need a set of protocols if you use something
agent-based.

With something more centralized it'll be more more difficult to have something
well designed and working in all cases... And what happens when a new
application arrive? etc.

Post by Scott Wheeler
I'm not sure that it's a practical approach, but it's certainly an
interesting way of looking at the problem, so it's worth thinking about.

The biggest problem I could see with such an approach is performance, it'll
involve more active objects (even if you can cheat at the implementation
level)... Moreover, when you cross this line it becomes difficult to see
things as really deterministic.

Post by Scott Wheeler
Practically speaking there's the problem that the applications not running
all of the time, but K?vin kind of jumped to the idea of applications
having parallel "agents" that come from the application.

I see it more as a split between a frontend and a backend... The agent being
able to query the backend and the frontend being a good old GUI application
for the user.

Post by Scott Wheeler
From my side --
independent of how these are organized this led to the idea that it
probably makes sense to have plugins that can come from applications for
query logic, much in the same way that KFileMetaInfo can abstract away
retrieval logic.

Indeed, that seems to be a fair way of thinking. Just note that you'll start
to build agents as soon as you'll need them to be proactive.

Post by Scott Wheeler
The more I learn about RDF the more I tend to believe those
that told me that it wasn't really all that useful for KLink like
structures, but "somebody else told me it's irrelevant" is hardly
convincing when you're fielding questions after a talk.

Hmmm... sorry I'm not sure to understand what you mean here?
I really feel that my english is limited sometimes... :-/

Post by Scott Wheeler
*) Ontology Learning for the Semantic Web
-- again, recommended by K?vin --

Sssshh! Stop putting my name all the time like this... :-p
I prefer to be on the "not public" side of things. ;-)

Post by Scott Wheeler
who seems to be our resident academic on these topics. I think the point
is mostly on building "bottom-up" ontologies rather than "top-down"
ontologies. Or something like that.

Yes that's the point. You can find mixed approaches too : bootstrapping the
system with a small "general" ontology, or trying to reuse an ontology. I
don't remember if Maedche focuses his book only on bottom-up or refers to
mixed too.

Post by Scott Wheeler
I'm not that far into it yet as it's
rather slow reading for someone not already involved in the field.

Oh sorry... I thought it would be a good book as a start... :-/

Post by Scott Wheeler
*) Essentials of Cognitive Psychology -- this hasn't actually arrived yet,
but should shortly. Since I'll be travelling a lot in the next couple of
weeks that means lots of reading time and I'd like to pick up a bit on
basically how people remember stuff as I think that may be useful down the
line.

Indeed, and it could be important on the human interface level too... Very
difficult topic though.

Ok, that's enough for this evening... I'm not even sure to be understandable
anyway. :-)

Regards.

[Aaron J. Seigo]

Post by Scott Wheeler
Essentially Sevtap's question (and feel free to correct me) was along the
lines of, "Why not move the query logic into applications rather than a
central place?" Essentially querying the applications as "agents" and
having them return things as such.
I'm not sure that it's a practical approach, but it's certainly an
interesting way of looking at the problem, so it's worth thinking about.

ignoring the practical issues, i don't think this will work for several
reasons:

1. information and application domains do not map similarly
2. puts too much onus on the application developer intead of giving them a
tool
3. the next step is the network, and this will make things much more complex
4. we have multiple applications for the same information domains
5. i don't see what advantages it brings.

in more detail:

1. when looking at art, an artist may write books, make music, direct movies,
do sculpture .. they may do all these things. however, we have separate
applications that view books, view movies, listen to music and view pictures.
so to tie this information together properly, one would require a central
system to tie the individual results for "books", "music", etc together to
the get overall picture of an artist. so breaking this up along applicaiton
domains is a poor idea.

2. i fully expect that we will one day at least experiment with multiple
threads / processes accessing the mesh and their results being used
collectively. however, i don't think putting the onus on application
developers is useful in the least. looks at kcontrol. the developers of
kcontrol actually wanted to put in search and look how it ended up. most
application developers couldn't care about it, save to use it as a tool. if
we try and produce anything but a tool for application developers to consume,
i fear it will fail utterly.

3. keeping an eyes to the future here, the next step is the network: tieing an
entire office of these systems together. having each agent communicate with
the network would likely be horrendous, which leads us to some sort of
central switchboard. i think the network case will be tricky enough without
having a machine-local network (the agents) that operates along a different
set of dimensions to rationalize into the whole scheme.

4. for music, do the juk or the amarok people write the agent? which agent
gets used? what about beep or...? i see a tower of babel arriving with this
approach. unless the klink devels do all the work. ha ha.

5. so ... how is having agents better exactly? i understand it's different,
but ... why?
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050319/26053618/attachment.pgp

[Scott Wheeler]

Post by Aaron J. Seigo
1. information and application domains do not map similarly
2. puts too much onus on the application developer intead of giving them a
tool
3. the next step is the network, and this will make things much more complex
4. we have multiple applications for the same information domains
5. i don't see what advantages it brings

I'm actually not suggesting its use, but I think it's an interesting way to
view the problem.

Formulated differently, "Everything, tell me what you know about 'panda
bears'"

Now there are problems with encapsulating that sort of high level "knowledge"
-- it moves away from the "unqualified relationships". But if the query
structure returned something very quantifiable -- i.e. boolean properties --
it might open up a way to embed extensible query logic without diving into
fixed ontologies. (Wow, now that was really clear, right?)

It does however set up some interesting questions:

*) Will it at some point be useful to have domain specific queries that where
we're essentially crossing application borders? Will it be useful to be able
to query something in one application that encapsulates data handling that
logically "belongs" to another application?

*) If so, what sort of strategies for working with that logic will the
framework provide?

To put things in semi-concrete terms again -- say we've got a KWord document
about panda bears. KWord will know more about that document than we'll be
able to store in the KLink structure, naturally. If there were a "KWord
agent" it might be possible to say, "Is this word important in this
document?"

I don't think this is all that important for the moment, but I mostly just
wanted to document the question because I think it's an interesting one
that's probably worth putting on the mental back-burner for recall at some
future point.

Cheers,

-Scott

[Aaron J. Seigo]

Post by Scott Wheeler
Formulated differently, "Everything, tell me what you know about 'panda
bears'"

i don't see how this isn't equivalent to asking the same question of a central
store. applications understand different data structures, sure, but if you
remove the structure and look at just the "meaning" i don't see any advantage
at all here.

Post by Scott Wheeler
*) Will it at some point be useful to have domain specific queries that
where we're essentially crossing application borders?

i think i answered that already in my last email: yes.

Post by Scott Wheeler
Will it be useful to
be able to query something in one application that encapsulates data
handling that logically "belongs" to another application?

well, this is one of the _primary_ reasons for having the information not
encapsulated inside individual applications. the whole concept of
"information belongs to an application" is broken. an application is a viewer
or editor of information, and that's it. the information itself extends
beyond any single application.

Post by Scott Wheeler
*) If so, what sort of strategies for working with that logic will the
framework provide?

having a central store?

Post by Scott Wheeler
To put things in semi-concrete terms again -- say we've got a KWord
document about panda bears. KWord will know more about that document than
we'll be able to store in the KLink structure, naturally.

why "naturally"? i don't think that's at all a given. what will KWord know
about a document that would be useful for someone (or some app) using klink
that could not easily be externalized?

certainly there needs to be ways to transfer information out of specific
formats, such as "here are the words that were in headers / titles and
therefore more important". but it's completley unrealistic to expect
application authors to instrument their apps very much. we need a simple set
of tools to enable this externalization. actually responding to queries is
not going to happen.

i also think that if you sit down and draw it out on paper so you can see it,
you end up with the exact same sort of "central store" only now you've spread
out the store across multiple applications.

and at the end of the day we'd still need a central switchboard to coordinate
it all. we gain nothing. except a ton of running processes.

i remember when agents were all the rage back in the 90s. lots of research
done. lots of things tried. nothing particularly useful arose. i think it's a
far too complex way of doing it and it simply limits the possibilities.

remember, one of the reasons for having a central store is so that ANY
application can massage data along ANY patchway it sees fit too. this isn't
just a matter "add some data into a big pile" and "grab the needle in that
haystack by throwing CPU at it". this is creating a repository of metadata
and summary information that is bound together by a network representing
relationships both explicit and implicit. this is why applications must
reside at its periphery rather than define the network.
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050319/1df3ca05/attachment.pgp

[Kévin Ottens]

Post by Aaron J. Seigo
i don't see how this isn't equivalent to asking the same question of a
central store.

Because it's harder to design a central store able to answer any query for any
domain? Because it's harder to maintain since it introduce a lot of
complexity?

Just guessing here...

Post by Aaron J. Seigo
well, this is one of the _primary_ reasons for having the information not
encapsulated inside individual applications. the whole concept of
"information belongs to an application" is broken.

You're maybe right here... I stayed to much on Scott proposal last time we
discussed it, but we can have an agent/document mapping, agent/author mapping
etc. That's exactly design decision and what agent engineering is about.

In fact I acted more as an external consultant explaining how it could look
like with a agent/application mapping. =)

Post by Aaron J. Seigo
i also think that if you sit down and draw it out on paper so you can see
it, you end up with the exact same sort of "central store" only now you've
spread out the store across multiple applications.

Depends how you distribute too... It's really feasible to have a central store
with a low level query language, and then agents upon this central store able
to answer (and collaborate to answer) a higher level query language with more
semantic.

Post by Aaron J. Seigo
and at the end of the day we'd still need a central switchboard to
coordinate it all. we gain nothing. except a ton of running processes.

Implementation detail... really. It could be achieved using only one process.
Multi-agents systems are more about how to design the system. Using one
thread/process per agent is something to decide at the implementation detail.

Post by Aaron J. Seigo
i remember when agents were all the rage back in the 90s.

Still the case, it's a very active field...

Post by Aaron J. Seigo
lots of research done.

And lots were (are...) not in fact about multi-agent systems. Some people
simply relable some of their articles with the "agent" term so that it looks
"hype".

Moreover, please note that there're the multi-agent systems field, and the
"rational" (not sure of the english word...) agent field... they are really
different business.

Post by Aaron J. Seigo
lots of things tried. nothing particularly useful arose.

Wrong, and wrong...
I've just one example of a system done in my team that works better than
equivalent centralized (designed) systems (it's one example... it's not the
case for everything done by the multi-agent community).

Multi-agent systems have some systemic properties you can't find in
centralized systems.

Post by Aaron J. Seigo
i think it's
a far too complex way of doing it

Maybe it's because you have difficulties to _think_ distributed. But honestly
when you become used to it, it's sometimes easier to think distributed... At
the start I admit it's more natural to try to keep the control centralized
etc.

Post by Aaron J. Seigo
and it simply limits the possibilities.

I don't understand how it could limit the possibilities... It's just another
paradigm of designing, higher level than object oriented design, and even
compatible with the object oriented paradigm (most multi-agent systems
nowaday have both agents and passive objects manipulated by those agents).

On the other hand I'm not pushing the use of multi-agent systems at all. =)
It's just that not everything as been said... and that I disagree with some
Aaron points. ;-)

Regards.

[Aaron J. Seigo]

Post by Kévin Ottens

Post by Aaron J. Seigo
i don't see how this isn't equivalent to asking the same question of a
central store.

Because it's harder to design a central store able to answer any query for
any domain?

that's not necessary, though. we're not trying to create an oracle, but rather
create a set of descriptive (metadata, full text vectors, etc) nodes that map
to sets of data and build links in between them.

the system doesn't have to answer "did Picasso like Rembrandt?" it just has to
answer "show me artists that did paintings" and "show me paitings that i was
looking at yesterday".

if we look at the actual questions people actually ask in the process of
trying to explore their information, the way people tend to try and remember
where things were, the information people need to explore larger data sets...
it's not that diverse. it's pretty common. we describe things using
relationships to other things and times or by their attributes.

trying to create an oracular system is not particularly necessary or even in
scope IMO.

Post by Kévin Ottens
Because it's harder to maintain since it introduce a lot of
complexity?

i don't think so...

Post by Kévin Ottens

Post by Aaron J. Seigo
well, this is one of the _primary_ reasons for having the information not
encapsulated inside individual applications. the whole concept of
"information belongs to an application" is broken.

You're maybe right here... I stayed to much on Scott proposal last time we
discussed it, but we can have an agent/document mapping, agent/author
mapping etc.

for input, we'll need specialization. but for gathering results, while it may
well end up being a multiprocess affair to navigate things (i babbled once at
great length to Scott about this concept of movable frames of reference on
the mesh ;), i don't see the need for specialization on the
reading/traversing of nodes. in fact, that's one of the benefits i see: no
information is assumed to have special boundaries, or at least ones that
define upon it.

we certainly need to be able to find "well known start points" (the reason for
monaforms in copula.sql) but how much more than that do we need to find
"artists that have songs from 1995"?

Post by Kévin Ottens
In fact I acted more as an external consultant explaining how it could look
like with a agent/application mapping. =)

for input or results discovery? for input, per-application input is going to
be necessary (though even there there is a lot of similarty between apps, but
also a lot of domain-specific mchanics) and in this regard i find it
interesting.

for traversal/discovery of the mesh... i don't see the benefits. feel free to
enlighten me =)

Post by Kévin Ottens

Post by Aaron J. Seigo
i also think that if you sit down and draw it out on paper so you can see
it, you end up with the exact same sort of "central store" only now
you've spread out the store across multiple applications.

Depends how you distribute too... It's really feasible to have a central
store with a low level query language, and then agents upon this central
store able to answer (and collaborate to answer) a higher level query
language with more semantic.

there will certainly be multiple simultaneous searches, and perhaps even for
the same query. what concerns me is the concept of agent specialization,
which is to say "this agent looks at X, this agent knows how to look at Y".
it's a very seductive concept, especially if completely divorced from the
requesting applications (e.g. i do not see the need for a "kmail query agent"
and a "juk query agent"). despite its seductive nature, i really wonder at
its added complexity.

Post by Kévin Ottens

Post by Aaron J. Seigo
and at the end of the day we'd still need a central switchboard to
coordinate it all. we gain nothing. except a ton of running processes.

Implementation detail... really. It could be achieved using only one
process. Multi-agents systems are more about how to design the system.
Using one thread/process per agent is something to decide at the
implementation detail.

i was responding in specific to the concept of "applications are the agents".

Post by Kévin Ottens

Post by Aaron J. Seigo
i remember when agents were all the rage back in the 90s.

Still the case, it's a very active field...

it's not marketted quite so much anymore ;) it's gone the way of hard AI it
seems: reality set in and people are using it where it makes sense instead of
the utopian concepts of world domination previously spewed by the marketing
arms of those doing the research.

in particular, search agents for public use are non-existent. at least, i
don't see them in popular use.

Post by Kévin Ottens

Post by Aaron J. Seigo
lots of things tried. nothing particularly useful arose.

Wrong, and wrong...
I've just one example of a system done in my team that works better than
equivalent centralized (designed) systems (it's one example... it's not the
case for everything done by the multi-agent community).
Multi-agent systems have some systemic properties you can't find in
centralized systems.

certainly; you're right this was a bit of a heavy handed, sweeping statement.
i'm aware of MA systems used by, for instance, military organizations to
study battlefield situations. they seem to map well onto systems which are
themselves multi-agent in some way.

i'm not sure this is the case here.

Post by Kévin Ottens

Post by Aaron J. Seigo
i think it's
a far too complex way of doing it

Maybe it's because you have difficulties to _think_ distributed. But
honestly when you become used to it, it's sometimes easier to think
distributed... At the start I admit it's more natural to try to keep the
control centralized etc.

what would be the benefits in this case? how would the agents be defined? how
would it simplify or empower (either is good =) the system?

Post by Kévin Ottens

Post by Aaron J. Seigo
and it simply limits the possibilities.

I don't understand how it could limit the possibilities...

by treating different "types" of information as distinct. by casting
predefined concepts of the shape of the network by saying "this is how
information of type X is searched".

if the idea for agents in klink is to enable "parallel searching" to enable
quicker traversal of the network (by exploring multiple possibly-good
directions at once), that's something i'm interested in.

but the idea of application agents is not useful imo.
--
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050320/f65b30a2/attachment.pgp

[Kévin Ottens]

Post by Aaron J. Seigo
for input or results discovery?

For result discovery... but as I said I've been asked how it could look like
on an application/agent mapping. I never said it was the best idea...

Post by Aaron J. Seigo
for traversal/discovery of the mesh... i don't see the benefits. feel free
to enlighten me =)

I see the benefit (surely not with an application/agent mapping) because you
could make the system (the system, not necessarily the agents) to learn some
things thanks to the user behavior. I know at least one information retrieval
system working like this.

But, please don't push me at presenting a more complete solution... I'm not
pushing the use of multi-agent systems in Klink, I just want to clarify some
points and in particular to avoid giving up on the idea on some wrong
assumptions or rethoric arguments like "it's not so marketed anymore, so it's
not useful". ;-)

Post by Aaron J. Seigo
there will certainly be multiple simultaneous searches, and perhaps even
for the same query. what concerns me is the concept of agent
specialization, which is to say "this agent looks at X, this agent knows
how to look at Y". it's a very seductive concept, especially if completely
divorced from the requesting applications (e.g. i do not see the need for a
"kmail query agent" and a "juk query agent"). despite its seductive nature,
i really wonder at its added complexity.

Once again, I never said that I see a need for such a mapping.

Post by Aaron J. Seigo
it's not marketted quite so much anymore ;) it's gone the way of hard AI it
seems: reality set in and people are using it where it makes sense instead
of the utopian concepts of world domination previously spewed by the
marketing arms of those doing the research.

I admit that I don't know to which extend it has been marketed in the
non-academic world. =)
But I know it's very fashioned currently in the academic world... And we
regularly see things that put the label "multi-agent systems" on good old
expert systems... tssss...

Post by Aaron J. Seigo
in particular, search agents for public use are non-existent. at least, i
don't see them in popular use.

And this particular example is most of the time not about multi-agent
systems... A non trivial amount of researchs done around search agents are
just about distributed databases without any real multi-agents concern.

Post by Aaron J. Seigo
certainly; you're right this was a bit of a heavy handed, sweeping
statement. i'm aware of MA systems used by, for instance, military
organizations to study battlefield situations.

It's generally easy to apply MAS when you have a real life metaphor,
battlefield being a good example. Network bandwidth use some results of the
ants algorithms too coming from the multi-agents field.

Post by Aaron J. Seigo
they seem to map well onto
systems which are themselves multi-agent in some way.

That's a weird statement... multi-agent systems map well on multi-agent
systems. Wow! We're lucky. ;-)

Ok, I stop kidding... I guess I understood.

It's clearly a problem of metaphor and on how you approach the problem you
want to solve. I admit that sometimes it's not that easy to find the right
angle to look at a problem... it's true for other kinds of engineering
though.

Post by Aaron J. Seigo
i'm not sure this is the case here.

I'm not sure either... But I think that generally it needs more efforts at the
design stage to find a way to use agents, or to decide (using a set of
criteria) that agents are not the way to go.

Post by Aaron J. Seigo
what would be the benefits in this case?
how would the agents be defined?

It'll require more work than answering a mail to decide this. =)

Post by Aaron J. Seigo
how would it simplify or empower (either is good =) the system?

The system would gain more flexibility, be able to adapt to the user needs,
and answer questions you're not expecting the user to ask.

In my team we try to use some properties of the multi-agent systems giving
them the ability to adapt to their environment, and in particular the system
design is changing (the design of the system can be seen as how the agents
are linked, the social relations, hence why it's able to change and evolve
during the system lifetime).

Post by Aaron J. Seigo
by treating different "types" of information as distinct.

It's a flaw of the application/agent mapping... not of multi-agent systems
themselves.

Post by Aaron J. Seigo
but the idea of application agents is not useful imo.

I guess that's the problem in this whole discussion. We started on the wrong
basis, assuming only application/agent mapping could be used. An infon/agent
(I hope I got the infon name correct =)) mapping could be more interesting
for example.

Regards.