Currently, the knowledge base is a simple in-memory store. Add support for additional knowledge base providers. Also, will need to review other knowledge base projects for standard practices, etc.

Modular Source Providers Plan

This rough draft outlines a modular approach to adding support for file, API, and syscall sources for Facts, Rules, and FactValues in the SymbolicReasoningEngine. Each source provider should be independently implemented and easily swapped.

1. Define Source Provider Traits:

Create traits for different source providers, such as FileSourceProvider, ApiSourceProvider, and SyscallSourceProvider. Each trait should define methods for retrieving Facts, Rules, and FactValues from their respective sources.

trait FileSourceProvider {
    fn load_facts_from_file(&self, file_path: &str) -> Vec<Fact>;
    fn load_rules_from_file(&self, file_path: &str) -> Vec<Rule>;
    // ... other methods for FileSourceProvider
}

trait ApiSourceProvider {
    fn fetch_facts_from_api(&self, endpoint: &str) -> Vec<Fact>;
    fn fetch_rules_from_api(&self, endpoint: &str) -> Vec<Rule>;
    // ... other methods for ApiSourceProvider
}

trait SyscallSourceProvider {
    fn get_facts_from_syscall(&self) -> Vec<Fact>;
    fn get_rules_from_syscall(&self) -> Vec<Rule>;
    // ... other methods for SyscallSourceProvider
}

2. Implement Source Provider Modules:

Create modules that implement the defined traits. For example, you might have a FileSourceProviderImpl, ApiSourceProviderImpl, and SyscallSourceProviderImpl implementing the corresponding traits.

struct FileSourceProviderImpl;

impl FileSourceProvider for FileSourceProviderImpl {
    // Implement methods for loading facts, rules, and other data from files
}

struct ApiSourceProviderImpl;

impl ApiSourceProvider for ApiSourceProviderImpl {
    // Implement methods for fetching facts, rules, and other data from APIs
}

struct SyscallSourceProviderImpl;

impl SyscallSourceProvider for SyscallSourceProviderImpl {
    // Implement methods for getting facts, rules, and other data from syscalls
}

3. Update SymbolicReasoningEngine to Use Source Providers:

Modify the SymbolicReasoningEngine to accept instances of these source providers during initialization.

struct SymbolicReasoningEngine {
    file_source_provider: Box<dyn FileSourceProvider>,
    api_source_provider: Box<dyn ApiSourceProvider>,
    syscall_source_provider: Box<dyn SyscallSourceProvider>,
    // ... other fields
}

impl SymbolicReasoningEngine {
    pub fn new(
        file_source_provider: Box<dyn FileSourceProvider>,
        api_source_provider: Box<dyn ApiSourceProvider>,
        syscall_source_provider: Box<dyn SyscallSourceProvider>,
    ) -> Self {
        // Initialize the engine with the provided source providers
        SymbolicReasoningEngine {
            file_source_provider,
            api_source_provider,
            syscall_source_provider,
            // ... initialize other fields
        }
    }

    // ... other methods for the engine
}

4. Add Methods to Load Data from Sources:

Implement methods in SymbolicReasoningEngine that use the source providers to load Facts, Rules, and other data from different sources.

impl SymbolicReasoningEngine {
    pub fn load_facts_from_file(&self, file_path: &str) -> Vec<Fact> {
        self.file_source_provider.load_facts_from_file(file_path)
    }

    pub fn fetch_facts_from_api(&self, endpoint: &str) -> Vec<Fact> {
        self.api_source_provider.fetch_facts_from_api(endpoint)
    }

    pub fn get_facts_from_syscall(&self) -> Vec<Fact> {
        self.syscall_source_provider.get_facts_from_syscall()
    }

    // ... similar methods for rules and other data
}

5. Usage Example:

fn main() {
    // Create instances of source providers
    let file_source_provider = Box::new(FileSourceProviderImpl);
    let api_source_provider = Box::new(ApiSourceProviderImpl);
    let syscall_source_provider = Box::new(SyscallSourceProviderImpl);

    // Create the SymbolicReasoningEngine with the source providers
    let engine = SymbolicReasoningEngine::new(file_source_provider, api_source_provider, syscall_source_provider);

    // Use engine methods to load data from different sources
    let facts_from_file = engine.load_facts_from_file("/path/to/facts.json");
    let facts_from_api = engine.fetch_facts_from_api("http://api.example.com/facts");
    let facts_from_syscall = engine.get_facts_from_syscall();

    // ... perform other operations with the engine
}

Currently, this project has all of its code in lib.rs. Being new to rust, the last time I went to organize modules in a rust project, it was more involved than I expected and set it aside for later. I'll use this refactoring to learn how to organize rust code and better organize the codebase.

• Configure github workflow(s) for CI.
• Configure github project to ensure sanity.

• Add project origins and goals.
• Add links to relevant research papers.
• Add roadmap.

String interpolation from variables via ComparableValue::Direct(FactValue::Text("...".to_string())) is confusing. I think ComparableValue::Variable("varName".to_string()) is much more straight forward. If Box isn't necessary or can be done within the method itself, readability should improve. Also, probably should review Direct type... perhaps it would be better to have Integer, Float, etc first-class for ComparableValue.

LogicalOperator::GreaterThan(
    Box::new(ComparableValue::Direct(FactValue::Text("${temp}".to_string()))),
    Box::new(ComparableValue::Direct(FactValue::Integer(20)))
)

vs

LogicalOperator::GreaterThan(
    ComparableValue::Variable("temp".to_string()),
    ComparableValue::Integer(20)
)

Integration Layer Plan for NSCR Framework

The NSCR (Neuro-Symbolic Cognitive Reasoning) framework involves integrating the SymbolicReasoningEngine with a neural network engine and an integration engine.

Plan Summary:

The NSCR framework aims to seamlessly integrate symbolic reasoning with neural network capabilities through the Integration Engine. By defining common data representations, protocols, and feedback mechanisms, this framework will allow for a combination of symbolic and neural reasoning to tackle complex cognitive tasks.

Components:

1. SymbolicReasoningEngine (SRE):

   • This is the core reasoning engine based on symbolic reasoning.
   • It handles logical rules, facts, and inference.

2. Neural Network Engine (NNE):

   • Responsible for training and executing neural networks.
   • Deals with pattern recognition, learning from data, and complex non-linear relationships.

3. Integration Engine (IE):

   • Serves as the middleware that connects SRE and NNE.
   • Manages communication and data flow between symbolic reasoning and neural network processing.

Plan:

1. Define a Common Data Representation:

• Establish a common format for representing facts, rules, and inputs/outputs that both SRE and NNE can understand.
• This could be a shared data structure or a standard data interchange format.

2. Data Exchange Protocols:

• Define protocols for exchanging data between SRE, NNE, and IE.
• Consider using standard formats like JSON or Protocol Buffers for seamless communication.

3. SRE Changes:

• Modify SRE to expose interfaces for:
  • Accepting input data in the common format.
  • Retrieving output in the common format.
• Enhance SRE to work with continuous data flows, as neural networks often require iterative training.

4. IE Implementation:

• Create the Integration Engine (IE) to facilitate communication between SRE and NNE.
• IE should handle data preprocessing, passing data between SRE and NNE, and handling feedback loops.

5. Integration Logic:

• Implement logic within IE to decide when to involve the neural network engine based on certain conditions.
• Define rules for deciding whether to delegate to the neural network or rely solely on symbolic reasoning.

6. Feedback Mechanism:

• Establish a feedback mechanism where the output from NNE influences the symbolic reasoning in SRE and vice versa.
• Ensure that learning from data is integrated into the overall reasoning process.

7. Testing and Validation:

• Rigorous testing is crucial to ensure the seamless integration of SRE, NNE, and IE.
• Implement test cases that cover various scenarios, including cases where neural network results affect symbolic reasoning and vice versa.

8. Documentation:

• Provide clear documentation for developers and users explaining how to use the integrated NSCR framework.
• Include guidelines on configuring, training, and maintaining the system.

9. Example Use Cases:

• Create example use cases or applications that showcase the synergies between symbolic reasoning and neural networks in the NSCR framework.
• Demonstrate how the combined capabilities of SRE and NNE lead to more powerful and flexible reasoning.