thoughts from FOSDEM, status

[Aaron J. Seigo]

On Sunday 20 March 2005 02:26, Kévin Ottens wrote:
> Le Dimanche 20 Mars 2005 06:50, Aaron J. Seigo a écrit :
> > 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.

> Because it's harder to maintain since it introduce a lot of 
> complexity?

i don't think so...

> > 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"?

> 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 =)

> > 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.

> > 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".

> > 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.

> > 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.

> > 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?

> > 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