edit
IndependentProject.ImplementationDetails
Independent Project
.
Implementation Details
* Which version of a command should be the 'main' one and which should be translated to it? + I would think that it would be best for this to be purely an implementation detail and not visible anywhere else. === Data structures: * list of translations + list of regular expressions + translation result + context (list of words/phrases/subjects) result can be of type: * lua function * shell command/script (not in all circumstances) * english script * what if I want the result to scrape html from a webpage? * what about an rdf interface? === How do you chose between two matching statements with different results? The command "Pause" could apply to many things. How do you know which you want to pause. The movie that is palying, or the music? * The one that was referred to most recently? + try pausing each thing in the context until one of the makes sense... * past context * some kind of pre-programmed similarity context saying that these commands all go together Implementing Designing Translations: --- * -> How about using a shell script as the language of choice. * some kind of interface can be created DBUS or something similar so that the script can query the context and history, etc * the output can be sent to stdout with certain formatting. * example output: - Boredoms <context> <item> <title>Boredoms</title> <uuid>abcdefg</uuid> </item> </context> <display> display of some kind here... a table, I dunno </display> etc - * os(date) : should print out the date * chomp(os(date)) : should print out the data with no newline if there is one * What is the time : should print out the time * what [[[ThoughtsOnResultStructure]]] important views into this data structure: * translate this string * what translations are similar to this string that didn't have a translation? Looking for translations with: + similar words + similar wildcards + similar context (in similar clusters as the previous commands) * views necessary for a context clustering algorithm (how often is this run?) === Context --- * How are items add to it? + list of items to add in translation structure + similar to syntax for translations: * $1, $2, etc are substituted with the incoming arguments as the translation is * $$ is substituted with the result of running the translated expression + should useful metadata also be stored in the context? how? ex: * what album is this? : God's Money : God's Money is an album + should it somehow refer exactly to the result if it can? ex: * what album is this? : God's Money : <rdf God's Money uuid=... ...> + some kind of heirarchical or tagging formatting of each entry describing exactly what it is, where it applies to: * play, amarok, music + this way if the next command is pause, it knows that it should apply to the music. * algorithm: + find matches for the command + compare the keywords with the context (useful for making things work with less training) + compare the statistics about past context for each. (useful for learning subtleties of each user. === Files, data --- * Where are files stored? * How is data kept track of? * What kind of filesystem should be exposed? === GUI: --- * how will this look? + Web interface? (for now) + local or remote server (user's decision/both for syncing) * syncing raises new issues. Same as any other management system like CVS, SVN, etc + how do you keep this secure? ssh? + how do you provide multiple views? + how do you decide what is displayed given the context? When asking about music, show other relevant information. * perhaps this could be done by automatically displaying information in the same cluster. The same clusters used to determine the current context. * what about answers to common questions whose answer doesn't make sense without knowing what the question was. There shouldn't be too many of these, but even a small number of them could lead to very confusing displays * information/questions that might need to be asked of the user: + which of these translations do you mean?