.
FRDCSA | internal codebases | KBFS
Homepage

[Project image]
KBFS

Architecture Diagram: GIF
Code: GitHub

Jump to: Project Description | Parent Description | Capabilities

Project Description

kbfs stands for knowledge based file system. It is wrong to call it a file system, but it has a lot of features, and maybe could be eventually made into a virtual file system. Pack is a subsystem for packing files onto DVDs. Mainly this is an exercise for me in Object Oriented Perl programming. Its a fun and manageable domain. The goal is to efficienty and orderly pack a given media with the right directories. Print nice labels, with barcodes for CD's/DVD's based on contents, for reminders and correlation with the media relations part of kbfs.

Capabilities

  • write a function that allows us to look at the text of a pdf in kbfs/dired mode without loading the pdf, maybe even bound to RET or whatever.
  • kbfs should try to log, via assertions, the aetiology of different files, such as whether a file was generated by processing a different file, and can even guess at these relationships.
  • Make an sql log of kbfs commands, to rebuild if there is corruption, etc.
  • Make an edited book on AI using our writings that we mark with kbfs. Get kbfs going with Formalog/WSM.
  • Work on kbfs soon.
  • Work out the kbfs system and then backpropagate information from Academician to refer to the correct documents in kbfs.
  • Fix the system for generating DVDs using kbfs
  • Implement something to automatically generate backups and diffs of all of our repositories for kbfs.
  • kbfs see: File::Dedup
  • kbfs does Digital Asset Management
  • Enter all of Michael Iltis' documents and software into the kbfs system, and begin annotating it using NLU and such, in order to derive our representation and also to have the information required. Write a document mentioning all the different layers. Fix the NLU code to work with kbfs. etc.
  • clear should use kbfs to represent the state of a file, so that we can read a file and then read all changes between versions, etc.
  • Set up a system with kbfs using Prolog which understands whether a directory has been updated or not. And reminds us, when doing the kmax-update-frdcsa-repositories to do all the different ones that need updating.
  • kbfs should work irregardless of whether a file is in git's version control.
  • For kbfs have Perl load the kbfs ids of all the source files it is loading. Somehow get this from the Perl interpreter.
  • For kbfs use Cyc's AIS stuff.
  • Have it also assert the kbfs id of the particular result file.
  • Have the KNext analyzer assert the relationship about processed into kbfs when it has completed processing a given piece.
  • For packager, when we get kbfs going especially w/ the prolog aspects we can use a logic program to assert that the files respect the criteria we need, such as permissions and such.
  • kbfs should consider: Language::Prolog::Types::Internal
  • kbfs should use some techniques similar to rsync for knowing whether something has been modified.
  • kbfs/Release-Helper should check out look into encrypted git
  • Pair up elog with kbfs to have the state of the files in the buffer as they were seen. Also, use memax.
  • kbfs consider tocc
  • kmax should use ELog and kbfs to record the files which it is editing, and mark those files up with annotations and tags against a git version control version.
  • Store in the kbfs a proof of a given files license, along with that file.
  • Look into integrating Magit with kbfs.
  • Okay - so for kbfs, git stuff, I'm not seeing a lot in the way of existing RDF or OWL export of Git versioning information, therefore I'm considering an alternate, verbose format. What you could say is something like (FileVersionFn (GitRepoFn "http://github.com/aindilis/cyc-mode") (FileNameFn "cyc-mode.el") (BranchFn "master") (RevisionFn "3250293570237509237570523")). You could then assert things about that particular file. Perhaps, there is already a "permalink" or something that refers to a specific version of a file, and you could just use (FileVersionFn "http://github.com/aindilis/cyc-mode/32095723075023750927530973257/cyc-mode.el"). There should be functions for obtaining information about the file from cyc or whatnot, i.e. (RevisionForFileFn (FileVersionFn "http://github.com/aindilis/cyc-mode/32095723075023750927530973257/cyc-mode.el")).
  • Okay, so for kbfs, git stuff, I'm not seeing a lot in the way of existing RDF or OWL export of Git versioning information, therefore I'm considering an alternate, verbose format. What you could say is something like (FileVersionFn (GitRepoFn "http://github.com/aindilis/cyc-mode") (FileNameFn "cyc-mode.el") (BranchFn "master") (RevisionFn "3250293570237509237570523")). You could then assert things about that particular file. Perhaps, there is already a "permalink" or something that refers to a specific version of a file, and you could just use (FileVersionFn "http://github.com/aindilis/cyc-mode/32095723075023750927530973257/cyc-mode.el"). There should be functions for obtaining information about the file from cyc or whatnot, i.e. (RevisionForFileFn (FileVersionFn "http://github.com/aindilis/cyc-mode/32095723075023750927530973257/cyc-mode.el")).
  • Apply NLU/kbfs to the web, not just local files.
  • Add to academician assertions about the length of files in pages, add to kbfs actually.
  • Use kbfs, have it learn when to automatically attribute facts to files based on certain correlations. Also use Sayer and Sayer-learner, and Thinker to learn when these facts apply to the files. Then, for instance, do automatic classification of text files into subject headings. Ultimately organize all of the research papers and documents I have into a coherent, cohesive whole.
  • kbfs should be sure to have a git store available and reference specific git items.
  • Perhaps kbfs can integrate with kmax
  • With kbfs you could relay which version of two similar files was preferable for certain reasons.
  • Use kbfs to tag which files are known to be software archives, versus which are known to be data sets, versus which are not known to be either, versus which we know nothing about at all. This database could be bootstrapped by iterating over /var/lib/myfrdcsa/codebases/external versus /var/lib/myfrdcsa/codebases/datasets, and then tagging several of neither kind. Then extract features of those data points, using Sayer, etc, to do machine learning to automatically classify items as being software collections or not.
  • do an analysis of what is wrong with the current kbfs system, as to why we need to reengineer it.
  • Rework the system for nlu etc to use kbfs tags for representing the contents of a buffer. so for instance, it will know the buffers title, etc. these will be properties specific of individual kinds of files, for instance an nnvirtual:article buffer has a summary, store that, etc, in kbfs and associate with the annotations.
  • Transition academician over to using kbfs because, for instance, when you mark a page as read, that is relative to the specific version of the document, and not to the title of the document.
  • Build the Sayer/NLU/kbfs system that asserts information about files and explores all the possible things to assert about them.
  • Rewrite kbfs to use theorems stated about files, sort of like that one derivative system we made.
  • Rewrite academician to use kbfs. Fix kbfs.
  • NLU/kbfs/Sayer should practice as in the field of deduction.
  • NLU/kbfs/Sayer should say: "Consider this file", and then begin making notes about it.
  • Rewrite academician stuff to use kbfs.
  • Add something to kbfs to indicate between public and private dumps, and modify the /tmp deletion routing then to accomodate a certain number of each.
  • Rewrite kbfs-tracker to use features of a file for its identification, some features which don't depend on it's filename, like md5sum and crc etc.
  • Rewrite kbfs-tracker to use features of a file for its identification, some features which don
  • Have to have the option of passing context information about the item as derived from kbfs/Sayer, such as for instance if it is the top of the stack.
  • Have the option to query the commands that can be run on the given entries in the freekbs2-stack. For instance, if they haven't been processed with NLU/Sayer/kbfs
  • Offer the ability to correct automatic annotations by NLU/Sayer/kbfs
  • Make ghost part of kbfs somehow.
  • Develop a mode for completing read assertion of stuff such as kbfs drawn from existing contexts.
  • kbfs needs semantic carving for recognition of contents of files, such as files that are montages
  • auto-packager should use data enrichment of package orig.tar.gz, debian/* and included patches via sayer/thinker, nlu and kbfs as input features to various machine learning systems in order to determine how to automatically package something for Debian. brilliant. difficult though.
  • Add a diff capability to NLU, track different versions of the same article using kbfs or equivalent.
  • Get kbfs::Cache to write it's cache when used with system-implementor
  • Finally create critic using kbfs and NLU.
  • Create minor kbfs modes for things like packager, etc.
  • Write tests for the parts of kbfs we got working today, so that when we go to make changes to get the File stuff also working, it doesn't kill everything.
  • Create commands between NLU and kbfs that allow you to assert knowledge about the text contents of files.
  • Redo classify.el to be able to mark files using kbfs
  • Create a unilang version of kbfs-tracker, change the commands in kbfs.el to use the unilang version.
  • Add the ability to radar-web-search to download the containing webpages as well as the links themselves. Add the ability to have kbfs index the items (MD5 sum etc), assert metadata (such as where they were downloaded from, and for what search). Have the ability to check if a given item has already been downloaded for another search.
  • Look into forensic systems for kbfs.
  • kbfs should have the capability to do filesystem archaeology, basically, work out movements and large scale actions that happened to different files and so forth, to explain the present location, etc.
  • Integrate kbfs with NLU, so as to assert things about various revisions in git or what not.
  • kbfs can use inotify, git
  • Academician must use the stuff that kbfs does, in order to represent knowledge about files.
  • use tracker for kbfs: https://live.gnome.org/Tracker/Documentation
  • Actually make use of kbfs and databases as well for data-manager.
  • Combine Sayer with cso, to have a system that asserts knowledge about software packages and archive files, etc. That's kbfs, so finish it.
  • Not only should kbfs know what file a given request matches too, but architect (or something) ought to know which functions or objects implement the described capabilities.
  • Often times, certain files implement certain solutions. We will want to track that information with kbfs.
  • Should break up books into functionality (like CCM) and then verify using our kbfs/architect requirements traceability mappings.
  • I just noticed that with locate, you often get a directory, we could design a kbfs version of locate that summarized the different chunks.
  • kbfs then ought to have a mode that works like this. If we have file IDs, etc. We can approximate file derivation from this database. Maybe it should be part of kbfs.
  • Should probably make an effort to determine all files that are modified by us, and what they are and represent (i.e. kbfs)
  • sanctus should eliminate pornography, illegally obtained media, (should work with kbfs to tag all incoming data), etc.
  • Add to kbfs something that goes around cleaning things up.
  • I think maybe we ought to use kbfs with SourceManager
  • I just noticed that with locate, you often get a directory, we could design a kbfs version of locate that summarized the different chunks.
  • Have a lost and found facility in kbfs, if you have lost any files, describe the data, etc. kbfs may find it for you eventually.
  • kbfs could use dvdisaster
  • Develop a self-organizing file system (kbfs).
  • Cleversafe should interface kbfs.
  • kbfs should operate like LogicMoo, having a MUD like representation of the file system.
  • We can have kbfs do transparent compression of non-active, inefficient files.
  • This new system is the basis for critic, kbfs (now we have the KB for it), gourmet's ontology, etc, etc, etc.
  • Should break up books into functionality (like CCM) and then verify using our kbfs/architect requirements traceability mappings.
  • Not only should kbfs know what file a given request matches too, but architect (or something) ought to know which functions or objects implement the described capabilities.
  • Should probably make an effort to determine all files that are modified by us, and what they are and represent (i.e. kbfs)
  • sanctus should eliminate pornography, illegally obtained media, (should work with kbfs to tag all incoming data), etc.
  • Work on implementing kbfs in OWL
  • kbfs use SemFS
  • tagfs for kbfs
  • kbfs see DircSpan
  • Duh kbfs can use KBS
  • Duh, kbfs can use KBS
  • kbfs depends on cdcat
  • kbfs should have a classifier that automatically classifies items, using the classification system I am to write tonight.
  • kbfs should track what important project information is where. For instance, if we were to move all packages to the projectbox server, and delete them to free space, kbfs should know that
  • Should configure kbfs to start commenting on files. For instance - konik_laird_ilp2004.pdf is related to corpus.
  • Inventory management/kbfs should make use of a common system to manage instances of important items/data.
  • numerous ideas on the subject: should have classes be a type hierarchy. Maybe build a grpahical tool to interactivcely classify these. Convert these system over to kbfs::Cache, keeping a copy of current method. For each icodebase and common (agentified), add a class. For instance, rather than classifying into a vague category, you could classy directly to "pse, goal", etc.
  • I bet we could store all personal data on an encrypted loopback file system, which would be part of say, kbfs.
  • could configure clear to use kbfs and then in this way, it would be capable of correctly processing documents (as in identification via metadata)
  • Naturally clear should provide the ability to search backwards through what has been read, in order to answer questions and so forth. For instance if I read something to the effect that this truth is as clear as the sun, searching for this should get me the results I want. This reinforces the notion that clairvoyance should keep a central kbfs implementation of voy files, and run against that, as these can then easily be equipped for searching by a common search interface.
  • Also, we want to change the library directory of clear to be under /var/lib/clear/library or something, or even kbfs
  • For kbfs?
  • (OntoFerret for kbfs::Digest)
  • (kbfs - WebCache::Digest kbfs - WebFS::FileCopy)
  • (kbfs::Pack - Algorithm::Knapsack - brute-force algorithm for the knapsack problem)
  • (kbfs - http://search.cpan.org/modlist/File_Name_System_Locking)
  • Forgot to mention need to work on classification system and kbfs using those new perl mods.
  • medusa kbfs
  • By looking at word frequecies, etc, subterm, etc, we can practically determine in many cases which documents came from which. This will be useful for kbfs.
  • kbfs should also be concerned with identifing when data is missing.
  • Thinking about kbfs pack, it makes at least some sense that, with the project still being unclassified, that we implement a compressed, cryptographic filesystem on top of a tiny live linux disk as the basis of the backup. An interesting idea is then that any machine that has two dvd drives could serve to access all the data since we can then have an arbitrary number of additional data fses.
  • kbfs: Should be a generalized system for looking up directories containing stuff and putting these on the command line.
  • relfs is to be helped, to be developed into what we are looking for. prepare an email to this person - get him to add security classification, as well as other things that come from kbfs.
  • recommend items in kbfs to others
  • Interface spam filtering gnutella client with kbfs and [Greenstore]
  • Interface kbfs with machiavelli to detect sour grapes in public domain.
  • /var/lib/myfrdcsa/kbfs/
  • Need to consolidate software that recognizes file types, perhaps using MIME, and even learns like my software for files, apply this to both files and URL prediction - i.e. learn all information from the name and context possible - that's a big thing, the context. In fact this is even a bigger problem, but can be factored, that deciding how data is to be organized. We have to look into the primary classification rules, for instance, that one can classify with a formula, by file type, etc, and come up with a scheme for classifying this data. Ultimately this is indeed the kbfs, and so should this predictive capability lie within its domain? Or shouldn't it? These questions are interesting, yet my previous background indicates to me they are trivial, just not from our vantage.
  • kbfs should consider framerd
  • the way an auto packager will handle a program tgz is the same as the way kbfs and Digest will break it down.
  • the notion of critic applies to clairvoyance and its notion of tracking what a user has seen, as well as kbfs, and also relates to the general properties of exploration, for instance, in searching for documentation about a particular capability. what is the name of the capabilities management system? cando?
  • could use kbfs to manage the source directories, etc. That way, it would be much more flexible.
  • add classification system to kbfs
  • add encryption support to kbfs
  • atfs for kbfs
  • OASIS entity management for kbfs
  • libsvn-core-perl for kbfs
  • fam in connection with kbfs
  • Review relation between kbfs, Amanda
  • Use the 160 GB as a cache when sorting a merging existing files in kbfs operations.
  • There should be some sort of system, part of kbfs, Pack, and FRDCSA-dist, that create FRDCSA recover disks, and that these then, testing on what FRDCSA disks are at hand, create plans for reconstituting as much of the system as possible. Also, should look at coding theory for ways to disemminate the data into secure hands anonymously, for instance, steganographically. Perhaps that is why there are so many versions of movies out there.
  • Part of or a similar project to kbfs should be partially concerned with DBMS, but more generally, knowing the storage format of databases. This is related to the overall goal of compactly and efficiently storing data.


This page is part of the FWeb package.
Last updated Sat Oct 26 16:53:36 EDT 2019 .