Sunday, August 30, 2009

New approach needed: a structured data bag is needed to keep information: compose-able information units can't be that flat as expected

CIU need to carry the piece of info saying "I was generated because of a sensor reading operation" or "I was generated because of an invokation of an actuator, done with these values and whose result was". It is like driving a stepper motor: you have to read the feedback to understand if the pulse moved something, otherwise information could be useless and corrupt the knowledge base introducing false results.

Fix to data rendering for DTOs that have "setter" methods

Solution to data rendering for DTOs that have setter methods, could be actually easy. I will try making a call to send a write action notification whenever a "setter" or a "write to actuator" method is invoked (like driveLeft(), driveRight(), brake()). This should bring getters (like getCenterOfMassPosition(), getLinearVelocity()) and setters for data operations on virtualized sensors/actuators, at the same level of abstraction. At this point, this is the situation: virtualized sensors reading actions and virtualized actuators invokation actions can be represented with the same hardware-domain-neutralized objects. All the operations can be represented. Question is: operations need not only to be represented (I just did it hopefully), but also to be performed, of course for the operations of type "write" on actutators. If a "driveLeft()" call operation has been saved as performed, the same operation should be able to be replicated again. This way we are already facing with the needs of the agnostic decision maker working with relations among compose-able information unit.