thoughts from FOSDEM, status

[Aaron J. Seigo]

On Saturday 19 March 2005 08:41, Scott Wheeler wrote:
> 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.

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

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

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

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

having a central store?

> 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