storage: this is the actual storage mechanism employed. for now (and perhaps permanently) we are using an RDBMS. this allows us to concentrate on things other than low level storage mechanisms and gives us an efficient and networkable system to start with. storage is split into two primary domains: the graph (infonspace) and the content (e.g. full text indexes). nodes in the graph (primarily infons) are referenced by entries in the content. note that "content" does not necessarily mean the literal content of the data being represented (e.g. email, notes, songs, outlines...). the content that is stored may be processed representations of said data, such as in the form of full text search vectors, etc.. nodes in the graph are strictly short strings of text, while content may consist of a variety of sizes of a variety of data types. so while id3 tags may appear in the graph itself, full text indexes would appear in the content area and reference nodes in the graph. term searches are done on the content primarily and on the graph secondarily, while navigation is done by traversing the graph. in this way content provides entry points into the graph which is then traversed. alternatively one can start navigating the graph directly by starting with a specific monaform (e.g. 'Audio') or location (e.g. 'file:/home/aseigo/mobydick.pdf') population: population is how data from outside of klink gets mapped into the graph and content. this is domain specific and done through a standard API. this allows any klink-enabled application to store add arbitrary sets of data to the graph. this API will allow adding new nodes to the graph, adding data to the content and using standardized indexing techniques such as a standard full text indexer. it also will allow defining locations which may be application specific. this is to allow, for instance, an email application to add an email to the graph and link it to a given identity, saved attachments, date of sending as well as reference it from a full text index of the message in the content storage area. the API must be simple to use to encourage application developers to use it extensively. preferably, a single a file-system perusing application (daemon?), the klink indexer, will be provided as a simple application that combs through a file system and populates storage with the files it finds. it will likely be the first consumer of the population API and an important test bed. an interesting issue will likely be how to make applications cooperate with each other such that entries that already exist in the graph due to being placed there by another application are respected. if a word processor creates an entry for given document, then the indexer shouldn't create a duplicate entry for it. at best it should augment the graphing. this will need to be a part of the functionality of the population API. another interesting avenue of research will be creating links within the graph that aren't explicitly defined but which can be inferred algorithmically. query language: what is the syntax of text-driven searches? how is it defined? "normalized queries" that can be used to generate SQL queries (or whatever the storage system uses) would allow multiple front ends, including NLP (i18n!), simple keywords based and complex/advanced search builders. the queries would be process as such: raw query --> normalized query --> actual query (e.g. SQL) a raw query would be what was derived from a user interface or an API call. it may be NLP, a glob of keywords or a list of "parameter" => "keywords" pairs. these would then be processed into a normalized query, which would likely look much like the latter raw query example of a list of "parameter" => "keywords" pairs. this normalized query would then get turned into an actual query by the storage layer and executed. the result would be a result set. search: searching consists of a standard set of user interface elements (widgets) which applications can use as a standard entry point, as well as a set of APIs that allow searches to be initiated and results retrieved. searches may return infons, locations or both as results. these result sets may be used as-is or may be used as starting points for traversing the graph, or "navigation". navigation: navigation takes the form of a set of APIs that allow determining relationships between nodes on the graph as well as "spatial" navigation of the graph. relationship navigation may be used to find the 5 nearest (most realated) control panels given any other control panel in the graph. spatial navigation might be used by a media player to display a playlist consisting of all the song files available to the user by artist, genre, year, album, year, etc.. that same media player might use relationship navigation to list other, non-audio works by the same artist such as books or multimedia associated with a given song such as album covers. this may also be used to provide context-sensitive, user-authored notes that can be attached to any data (viewed in a klink aware application). this would be accomplished by linking nodes of the Notes monaform to locations, and then requesting a navigation to the infon in the graph that exists between the Notes monaform root and the current location node. result sets: results of searches and navigation requests may be large sets. to make dislpaying and manipulating these sets as easy as possible a class providing a model that can be then connected to any Qt4 MV view widget will be provided. specialized view widgets that provide standardized result listings will also be provided to compliment the APIs. this set of classes will provide greater convenience as well as standardization and, hopefully, greater quality through code sharing of well designed classes. by selecting an entry int he model, one should also be able to navigate. misc: a way to open a given location referenced in the graph must be available. we have the current mimetype based KDE classes that allow openning arbitrary URLs without special knowledge within the application to use as a template here.