smithjd25

A similar concept to Bayesian filtering overall. - Jan 02 2010

I wonder if following prototype design initiative, a backend paradigm shift might be wise for semantic storage;

A way of using policykit to restrict the ability to (from example) index the root filesystem thereby allowing a deselection of what should have been indexed for semantic crawling.

It should allow to drop a dependency of not looking at a filesystem (in explicics) as accorded by Microsoft drive letters, instead passing by the root and sub-directory model of Unix to everything homedir including mounts and possibly /usr should policy be altered so.


A semaphoric return to C prompt intentions with a semantic bent. Non-explicit user access to root by acl in the semantic engine, which then crawls the entire filesystem.

Kind of like union-fs or reverse-bind mounts where the indexer can not index system directories.

I can actually then see a pervasive use for ACL keys as opposite lists in policy-based machine setups inclusive with semantic layer. x_attrs can be easily targetted as an engage-able technology by the storage backend.

Also the door is left open for a dropoff of responsibilities to the VFS layer over handling of x_attrs and acl depending on underlying filesystem.

A roll-up of attributes can be done from the database and dumped through the VFS layer to platter.

x_attrs copy is assured for file copies between devices by technology like sem_browser irregardless of underlying VFS layer.

A stipulation for actually storing and retrieving x_attrs on pluggable media via
Akonadi for filesystems that don't honour acls and x_attrs. (policy)

I don't know enough about acls/x_attrs to say whether it would be seamless and elegant but from my perspective it follows in gui userspace what Hans did attempt in kernel-land, and it has the benefits of scale ability within limits of reason. With a shift to exlusions rather than inclusions for the advent of the sematic method of storage it's easier to see what isn't required in-mind (such as /) vs. what's required to avoid information overload. In between is obviously a method to balance demands on time, hence why the computer was invented. - Dec 31 2009

Are we likely to see a Kpart for Koffice for Skrooge? It would be a joy to compare finances with in-mind expenses before scheduling in KOrganizer. Balance sheets and overdraft and all that. =)

Still waiting on Gentoo ebuilds. - Oct 19 2009