ruleresproadmap

= Rule Responder:RoadMap =

[ [|hide] ] *  [|1 Rule Responder Current] == Rule Responder Current  == == Rule Responder 0.6  == (all tasks in progress) == Rule Responder 0.65  == == Rule Responder 0.7  == == Rule Responder 0.75  == == Rule Responder 0.8  == == Rule Responder 0.85  == == Rule Responder 0.9  == == Rule Responder 1.0  ==
 * == Contents ==
 * [|2 Rule Responder 0.6]
 * [|3 Rule Responder 0.65]
 * [|4 Rule Responder 0.7]
 * [|5 Rule Responder 0.75]
 * [|6 Rule Responder 0.8]
 * [|7 Rule Responder 0.85]
 * [|8 Rule Responder 0.9]
 * [|9 Rule Responder 1.0] ||
 * Process Autostart (startup script in Taylor's account folder to be automated as much as possible with .bat-like file). See [|Rule Responder Guide]
 * Prova in Mule
 * Mule shut-down, wrapped in Java
 * Servlets running in Tomcat
 * Move Taylor's account contents to Harold's account
 * VMWare-based VM for [|SymposiumPlanner-2010]
 * Justin: Transfer VM from Taylor's network drive to Harold's network (P:) drive
 * Only for archiving not for running
 * WellnessRules2 and PatientSupporter: Use a special-purpose 'duration' structure measured in (hour, minute) instead of reusing the 5-argument dateTime structure that has the 3 arguments (year, month, day) 'zeroed out'. Use duration[hour, minute] instead of dateTime[0, 0, 0, hour, minute]. Progress in WR2 has previously been made and stored on NRC's server; see [|PA_WIP]
 * Reason: These variables are really unneeded as durations are not logically greater than a day.
 * Implementation: Modify the POSL and N3 knowledge bases, and change how they are parsed in the Personal Agents (Java).
 * WellnessRules2: Simplify the fitness level schema by removing location, and ambience.
 * Reason: Location and Ambience should not factor in to the fitness level for the day as they are details which the user will not likely require.
 * Implementation: Modify the POSL and N3 knowledge bases, and change how they are parsed in the Personal Agents (Java).
 * WellnessRules2: Create test data and profile generation automation tools.
 * Reason: WellnessRules2 should have a way to generate test profiles much like PatientSupporter; this proved useful for testing and debugging.
 * Implementation: Anaylze the already implemented testing library for PatientSupporter and adapt it to WellnessRules2.
 * New PatientSupporter/WellnessRules website layout
 * Completed proposed layout (Completed Sept 8,2010 ).
 * The proposed layout can be found [|here].
 * Require future meeting to discuss layout
 * Re-examine RuleML 1.0 use in Rule Responder. (discussed and agreed to postpone serious work until RuleML 1.0 is in a better release state).
 * Convert the PAConfiguration.java file to an XML file.
 * Reason: It is better practice to have an external file which is easily modified to handle the configuration of systems; currently the user is required to compile a Java file for configuration.
 * Implementation: Analyze the current configuration Java file, port its format to an XML file, and have a Java library to read it and assign values as appropriate.
 * Add more try-catch blocks inside the personal agent main classes; also modify the catch statements to have more specific error statements as opposed to “ERROR has occurred:”.
 * Reason: This assists in users' debugging of the system by providing more useful feedback of errors.
 * Implementation: Add more try blocks to the main Classes of each personal agent. Useful catch statements will also need to be implemented so understanding of what error is occurring is important.
 * Allow support for local knowledge bases instead of requiring the user to use the HTTP protocol only.
 * Reason: This small change that would allow for better testing on local machines because the user would not have to "upload" their resource to a website after every modification.
 * Implementation: Modify the personal agent classes which fetch these HTTP URL contents.
 * Consideration should be put towards the EA being a tomcat servlet.
 * As of right now, the EA is conceptually inside the system, but from a technical standpoint is not. While our EA is a nice interface to our system, it is not a required entry point into the system. As the system relies on a URL address to submit the query to the OA, the browser itself could be considered (not conceptually!) the EA. For example [[http://198.164.40.194:8888/?Horde=3a466331bca877eeb014be19eee68790&box1=%3CRuleML+xmlns%3D+%22http%3A%2F%2Fwww.ruleml.org%2F0.91%2Fxsd%22+xmlns%3Axsi%3D+%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22+xsi%3AschemaLocation%3D+%22http%3A%2F%2Fwww.ruleml.org%2F0.91%2Fxsd+http%3A%2F%2Fibis.in.tum.de%2Fresearch%2F+ReactionRuleML%2F0.2%2Frr.xsd%22%3E+%3CMessage+mode%3D%22outbound%22+directive%3D%22query-sync%22%3E+%3Coid%3E+%3CInd%3EPatientSupporter%3C%2FInd%3E+%3C%2Foid%3E+%3Cprotocol%3E+%3CInd%3Eesb%3C%2FInd%3E+%3C%2Fprotocol%3E+%3Csender%3E+%3CInd%3EUser%3C%2FInd%3E+%3C%2Fsender%3E+%3Ccontent%3E+%3CAtom%3E+%3CRel%3EmyDiscussion%3C%2FRel%3E+%3CVar%3EProfileID%3C%2FVar%3E+%3CVar+type%3D%22Toe%22%3EInjury%3C%2FVar%3E+%3CInd+type%3D%22integer%22%3E20%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E50%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E2%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E10%3C%2FInd%3E+%3CVar%3ECategory%3C%2FVar%3E+%3CVar%3ETreatment%3C%2FVar%3E+%3CVar%3EHealingStage%3C%2FVar%3E+%3CExpr%3E+%3CFun%3EdateTime%3C%2FFun%3E+%3CInd+type%3D%22integer%22%3E2010%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E5%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E21%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E10%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E0%3C%2FInd%3E+%3C%2FExpr%3E+%3CExpr%3E+%3CFun%3EdateTime%3C%2FFun%3E+%3CInd+type%3D%22integer%22%3E2010%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E5%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E21%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E11%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E40%3C%2FInd%3E+%3C%2FExpr%3E+%3CExpr%3E+%3CFun%3EdateTime%3C%2FFun%3E+%3CInd+type%3D%22integer%22%3E0%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E0%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E0%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E0%3C%2FInd%3E+%3CInd+type%3D%22integer%22%3E30%3C%2FInd%3E+%3C%2FExpr%3E+%3CVar%3EChannel%3C%2FVar%3E+%3CVar%3EContact%3C%2FVar%3E+%3CVar%3EGender%3C%2FVar%3E+%3CVar%3ETimeZone%3C%2FVar%3E+%3C%2FAtom%3E+%3C%2Fcontent%3E+%3C%2FMessage%3E+%3C%2FRuleML%3E|this link]] will do a PatientSupporter query to the system (should only take several seconds) without going through our EA interface. In this way, access to the OA can be considered an endpoint which can be accessed by anybody. This allows other systems to circumvent our EA interface and query the system directly.
 * This could also eliminate our communication issues that occasionally occur on "Fred-EZone".
 * It would enable us to pre-process our answers from the query. Nicer looking results parsed into english would be beneficial for demos.
 * We would no longer have to worry about any internet browser's limitation on URL address character length. This was a problem we made a work-around for with WellnessRules2 and PatientSupporter for Internet Explorer. However, any future use-case that uses more variables in RuleML queries may encounter problems.
 * WellnessRules2 and PatientSupporter: Rework how event time is matched and calculated; this large fix would enable event matching to work accurately. Additionally, we can eliminate most of the math being used in global rules which would give us a faster system.
 * Reason: Currently, when an enquirer user specifies the time range they want to have an activity in, all profile user's available times has to match that exactly.
 * Implementation: Modify the POSL and N3 knowledge bases, and change how they are parsed in the Personal Agents (Java).
 * A global knowledge base rule could transform a dateTime complex value (containing ?Year,?Month, ?Day, ?Hour, ?Minute) into one single value for comparison purposes. With this method we can compare 2 dateTime expressions with nearly no math required.
 * For example, for comparison purposes, the date 2010/10/24 13:00 becomes the value 201010241300 and 2010/10/26 12:00 becomes 201010261200 and can be compared to each other. 201010261200 > 201010241300, therefore we know 2010/10/26 12:00 is greater than 2010/10/24 13:00. This works significantly better than our current implementation of breaking down our dateTime structure into seconds and comparing it that way.
 * Update Mule ESB to latest version.
 * Reason: It is important to stay up to date on the resources which a system uses; Mule promises that there should be an increase in efficiency as well.
 * Implementation: Has been briefly attempted already; there was a gap in documentation and implementation and so more time needs to be invested.
 * Restructure the “personalAgents” package so that every personal agent has their own specific package.
 * Reason: Logically, it makes sense to package all of these personal agents under their instantiation however, in practice each of these PAs are implemented as a separate Tomcat servlet. Therefore, from a maintainer’s perspective it makes more sense to package each PA separately.
 * Implementation: Add new packages to the project for each personal agent and move the code to the desired locations.
 * WellnessRules2 and PatientSupporter: Re-implement N3 Support
 * Reason: In order for there to be symmetry between the POSL and N3 representations of these instantiations N3 must also support typed variables. This is not something natively supported by Euler but is supported via N3's expressiveness.
 * Implementation: Contact Jos and ask for assistance with implementing a workaround in Euler and the N3 knowledge base which would allow the use of typed variables.
 * Upgrade Rule Responder to PROVA 3.0
 * Reason: It is important to stay up to date on the resources which a system uses; PROVA adds new features which would be beneficial to Rule Responder (e.g. slots).
 * Implementation: Ask for Adrian's help with implementation of PROVA 3.0; it would likely take a significant amount of time as a lot of source code must be changed or created.
 * Clean up the referenced libraries in the "lib" folder.
 * Reason: Currently, the Rule Responder system is filled with unused (or once used) libraries that are no longer needed. This would free up a significant amount of space so that users may have a less cumbersome project to work with.
 * Implementation: Analyze the system and determine which library files are unneeded, and delete them.
 * Develop an installer. An automated system to assist with the installation of Apache, Tomcat, and Rule Responder.
 * Reason: Currently, users must go through a lengthy process with a large number of complicated steps to install Rule Responder. The documentation is clear enough to assist them but an installer which packaged everything into one file would be much more efficient.
 * Implementation: Research how to create such installers and consolidate all of the Rule Responder resources into the executable. Additionally, work would need to be done on automating the set up of Tomcat and the HTTP server.