Monday, June 22, 2009


A group of information (DNA can be an example ?) can be considered as an informaion context ? If information are grouped up for unit of time they were captured in, is that the time context for those information ? It is not of small importance this, has it gives a new light to next steps in theory. How do different context with different meanings interact ? Phrase semantic, a new further view on this new concept (that is composable inormation unit chains HBRWCIC, HBROCIC, HBWOCIC), could help. Every time I find a new view on the elments of the theory, It implies having more opportunities to find a better approach based on a different meaning and analogy/pattern.

Wednesday, June 17, 2009

A collection of information units makes an experience

Explaining: a composable information unit is a bunch of data received by a virtual sensor installed on the virtual simulation environment (the car with the simple shape of a box). This info is transformed into a DTO that generalize the concept of information into a "composable information unit" (CIU, CIU can be CIU obtained by a read or write operation: CIU(r), CIU(w) ), neutralizing the specificity. In a unit of time (a clock class capture them) several iformation are received, usually of different type. All the info collected in a unit of time are grouped together to build a so called "experience". Experiences will be all saved to make a knowledge base that will be source-agnostic. We will call this collection a "composable information unit chain": a chain of CIUC. Every CIU and CIUC has a timestamp as a reference on the time axis. So every CIU and CIUC has an age. Let's now think about how to work on the several obtained CIUC.

I'm thinking about introducing "generations" for CIUC as well as for generations for the steps I make refining my theory, producing a new version of it every time.

Tuesday, June 02, 2009

Requirements for the DTO that should carry data for the ciu

Going to design the java object for carrying data taken from the jmx notification what should be considered a requirement ?

1 Must be generic enough to be able to absorbe differences between different types of notifications into a common interface.

2 Could be needed to be thread safe, like a non mutable object.

3 Its properties must be able to be explored by external agents (that could be one or more threads, see point 2).

4 Could be needed to be link-able or group-able with other composable info units.

From virtual devices' echoes to composable information units

About the first point let's analize how to render a composable information unit. These need to change domain as the
format they have when they are received by the clock class (DeviceAliasPortReadClockDaemon) is still very jmx-
notification like. In a very simplified view every information received is a property (sometimes structured) object.
Thinking to this (I ilike this game of watching objects as physical shapes) as geometric elements, what is that is
defined by a variable eguals to a number, another variable equals to another number, like:
x = 1y = 3z = 5anothervariable = 7stillanothervariable = 12
It seems to me to be a point. A point in a space defined by as many dimensions as how many are the properties
carried by the composable information unit received. So, for example, let's analize a sample (one unsolicited echo
received because of the fuel limit notification, an interrupt driven echo received because the vehicle bumped
against an obstaclea, an echo sent back as an answer to a read request generated by the clock class to gather the
vehicle position):

Sample of fuel notification that says "GREEN" level: ****************************Sequence number: 4Source: FuelTimestamp: 1243956311584User data: User data payload: parameter changing echo parameter name: FuelDynamic parameter changing echo parameter level: GREENUser data payload data type: nullClass: class Fuel FuelType: UNSOLICITED_VALUE_CHANGED****************************

Sample of a collision detected echo:
****************************Sequence number: 21Source: devicealias.port.positioningsystem.collisiondetector-1243956298973Timestamp: 1243956311506User data: User data payload: echo impacted object type: 0Collision echo center of mass position: x: 1.8370745 y: -3.553998 z: 1.1854142Collision echo impacted object description: BoxUser data payload data type: nullClass: class devicealias.port.positioningsystem.collisiondetector-1243956298973
devicealias.port.positioningsystem.collisiondetector-1243956298973Type: PORT_INTERRUPT****************************

Sample of an echo received by the on board virtual GPS:
****************************Sequence number: 8Source: devicealias.port.positioningsystem.locator-1243956300864 READ verb answer Timestamp: 1243956312178User data: User data payload: echo center of mass position: x: -0.022259876 y: -4.7243595 z: -0.15895882Position echo linear velocity: Vx: 0.011706882 Vy: 0.16265121 Vz: -0.14992155User data payload data type: nullClass: class devicealias.port.positioningsystem.locator-1243956300864 devicealias.port.positioningsystem.locator-
1243956300864 READ verb answer Type: PORT_DO_READ_ANSWER****************************

These logs come from the application running a test. Now, these three types of echo you can find in package, are always communicating a bunch of information (as seen, solicited,
unsolicited, interrupts) but they have heterogeneous formats, as some have a structure, some have different
properties. This implies that a neutralizer and a common format is needed. possibly the format will be made as a
property object representing so an n-dimensional point in a n-dimensional space. This sounds particularly
interesting if taking into account that these will all become what we defined as composable information units. From
a geometric perspective these will be points going to be linked together and, still to play with solid
representations for java objects in design, these points linked in a structure will create a sort of "segment" or a
solid volume. Important to note: different points derived from different composable information unit could have a
different number of properties: points with different number of coordinates, so points in spaces with different
numbers of dimensions. The reason why I continue with this parallelism between java objects and geometric shapes is
that the closer I get to the "experience store" (knowledge base) representation, more It seems that the aggregation
is something more easy to understand if it is "visible". Well, it is also funny.
First problem by now, important to be solved, is the definition of a DTO for the composable information unit, and
(this comes for second and it is simpler to me) of a renderer to change every echo object into a unit of generalized

swarm-i code evolutions

Code in warm-i is now at this point: a simple vehicle using jbullet demo has been instrumented using jmx. This allow for virtual device aliases (plugged on the jbullet demo) to collect informations and push them into a "clock" that every "n" milliseconds set on configuration, group up these data bags received from different virtual sensors into snapshots of the system. These informations received have attributes. These are composable information units. There are interrupt generated values for collisions, a positioning system, dynamic parameter fluctuating as fuel and structural consistency. These decrease with time but could be increased when hitting a specific shape. Commands are also available to: brake, accelerate, turn right and left. These will be made available to the clock thread as well. Now problem will be two:

First: how to render these data (as specified before all are echoes from read input commands sent by the clock class, or unsolicited interrupt-like jmx notifications) into composable information units. These are already collected in bundles grouping them toghether for the unit of time they took place.

Second: interesting game, defining how to create relationsships to build composable information units' chains.

It is necessary to solve first point 1.

Second: how to start