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.

Wednesday, August 26, 2009

How to transform a java object, a dto essentially, in a "shape" of the information it keeps

An object of the type I'm taking into consideration has few things to offer to be manipulated (and this is good): it has "getters" and "setters" methods, plus values kept is class variables accessed by these. Now, what do I mean for shape of an object ? I speak with myself but it is anyway a good question. Shape is the object represantion that can be viewed by an agent that must be able to do operations on these. I'm speaking about a composable information unit produced from a dto of data received by sensors. So, shape has not to change with time passing, and many read operations on the same object must find the same "shape". The conclusion of this analysis is that the shape of a dto is a sorted list of key-value pairs with its getters and setters methods names as key, and values retrieved by the calls to these as... values.

Example: object class "person"

key: value:
getName stefano
getAge 35

This seems to run fine until I don't get into considerations the writable methods: the setters.

Information rendering: from sensors' readings to composable information units

Code on svn repository is at a very interesting point: I need now to define how to render a DTO java object (the paylod in jmx notifications received by virtualized sensors), into a knowledge domain, how to render them into a composable information unit, removing its original nature of jmx:

package it.free.i.virtual.machine.hal.devicealias.echo;

import it.free.i.virtual.machine.hal.devicealias.command.DeviceAliasPortCommand;
import it.free.i.virtual.machine.hal.devicealias.laboratory.positioningsystem.physics.CenterOfMassPosition;
import it.free.i.virtual.machine.hal.devicealias.laboratory.positioningsystem.physics.LinearVelocity;

/**
* Positioning data DTO impl
* @author stefano
*/
public class PositionEchoImpl extends EchoImpl implements PositionEcho {

private CenterOfMassPosition centerOfMassPosition = null;
private LinearVelocity linearVelocity = null;
private DeviceAliasPortCommand deviceAliasPortCommand = null;

public PositionEchoImpl(){
super();
}

/**
* @return the centerOfMassPosition
*/
public CenterOfMassPosition getCenterOfMassPosition() {
return centerOfMassPosition;
}

/**
* @param centerOfMassPosition the centerOfMassPosition to set
*/
public void setCenterOfMassPosition(CenterOfMassPosition centerOfMassPosition) {
this.centerOfMassPosition = centerOfMassPosition;
}

/**
* @return the linearVelocity
*/
public LinearVelocity getLinearVelocity() {
return linearVelocity;
}

/**
* @param linearVelocity the linearVelocity to set
*/
public void setLinearVelocity(LinearVelocity linearVelocity) {
this.linearVelocity = linearVelocity;
}

/**
* Set the command that caused this response to be generated
* @param deviceAliasPortCommand is the source do read command
*/
public void setInitiaLDeviceAliasPortCommand(DeviceAliasPortCommand deviceAliasPortCommand) {
this.deviceAliasPortCommand = deviceAliasPortCommand;
}

/**
* Get the command that caused this response to be generated
* @return source command that caused the do read operation
*/
public DeviceAliasPortCommand getInitiaLDeviceAliasPortCommand() {
return this.deviceAliasPortCommand;
}


}
In other words: I have some setters and getters and values associated. I think that the name of the method could generally become the name of a property, whose value is obtained invoking that method. Doesn't matter the semantic of the name of the property, they just have not to collide each other or overlap (this approach satisfy this need and make it simple to see original data). Can be that every composable information unit is a bunch of key-value pairs, where the keys are the methods' names and values associated are the values obtained invoking the "keys" ? Of course a dto can have nested objects to render in a flattened representation (no nested objects please), so every dto must provide its rendered version because of the paradigm interface defining what a payload for jmx notifications is.