Warning in advance: I know nothing about Bayesian networks, and I've only quickly skimmed through the article; but I did understand the parts I read so hopefully my insights will still be useful to you :-)
The most important thing I should note is that the "objects" in this article don't seem to be very much like objects in object-oriented languages. The objects don't actually keep state, and hence don't have methods to operate on them. They are more a kind of component-based approach to building probabilistic functions.
(•Addendum: the authors of the article in fact mention that their objects are "static", fixed once defined. This is ofcourse not the case with real objects in object-oriented languages)
In fact, if I skip the probabilistic part for now and just assume for input value there's only one valid output value, then their "simple variables" and "structured variables" are perl scalars and hashes (if I may assume attributes are strings, which in practice they would be). Their objects would simply be subs.
Let's look at their car-crash example (figure 1b in the article) while ignoring probabilistics. It has the Driver and Weather objects as inputs, and Damage as output. It could be written as a perl sub like this (note that I'm not paying any attention to efficiency, it's just a demo):
sub CarAccident {
my (%I) = @_;
my $Driver = $I{Driver};
my $Weather = $I{Weather};
my $Car = Car( Owner => $Driver );
my $Road = Road( Weather => $Weather );
my $CarSpeed = CarSpeed(
CarMaxSpeed => $Car->{MaxSpeed},
DriverAgression => $Driver->{Aggression},
RoadSpeedLimit => $Road->{SpeedLimit} );
my $Accident = Accident(
SteeringSafety => $Car->{SteeringSafety},
CarSpeed => $CarSpeed,
RoadCondition => $Road->{Condition} );
my $AccidentLevel = AccidentLevel(
BreakingPower => $Car->{BreakingPower},
DrivingSkill => $Driver->{DrivingSkill},
Accident => $Accident );
my $Damage = Damage(
CurrentVal => $CurrentVal,
AccidentLevel => $AccidentLevel );
return {
Damage => $Damage
};
}
Ofcourse since every function here is actually probabilistic, it all gets a bit more complex, but my main point is that it's still a function (as you might expect in a mathematical paper).
So as for your original question.. if you seek a standard object notation, the one used in this paper certainly isn't one. The objects of the paper however certainly can be represented in perl and XML, if you solve the issue of how to deal with the "simple probablistic functions" (as in, the set of primitives you build on).
As the paper mentions, a simple (but crude and memory-consuming) way to represent them is by using conditional probability tables. In perl you could use hashes if the input values can be represented as a string:
OutputVar => {
InputValue1 => {
OutputValue1 => (probability),
OutputValue2 => (probability)
},
InputValue2 => {
OutputValue1 => (probability),
OutputValue2 => (probability)
}
}
However this gets tedious quickly, and impossible if the value ranges are infinite. You will then probably have to represent them as real functions instead. Ofcourse this isn't a problem if it's perl code; in XML however you'll have to define a few basic operations and combine those.
The OONFs can then be represented as some big nested data structures, both using perl hashes and using XML.
If you need more help, you should probably first explain in more detail what exactly it is you're asking of us.
•Addendum: one point I hadn't touched yet is type-checking. If you represent "objects" as perl subs then type-checking is ofcourse very difficult, if not impossible. If you however construct them as data structures then type-checking is possible ofcourse. Since it's not entirely clear to me what it is you want to do, I can't really give any approaches yet. |