[rules-dev] Automatic handling of relationships

[Mark Proctor]

I thought of a simple, yet powerful idea, anyone want to give this ago? 
It will be the start of making ontologies more sanily usable for java 
developers.

Person
   @relation(name="OwnerPetRelation", verb="IsOwnerOf")
    Set<Pet> pets;

Pet
   @relation(name="OwnerPetRelation", verb="IsOwnedByf")
    Person owner;


IsOwnerOf and IsOwnedBy do not live on the classpath. The engine detects 
those annotations and generates them as internal classes. Or actually it 
can be one class, where it's able to use the two keywords to reference 
that class in either direction. When you insert your Persons and Pets, 
the relations are automatically inserted too (assuming there are rules 
that use them). This allows people to more naturally explore the 
relational aspect of their data, without having to create and insert the 
relations themselves. Once a Relation is being maintained by the engine, 
any updates to the underlying collection will result in relations being 
added and removed.

If we build in relation inferrence, to avoid the extra binding, it would 
mean that by simply annotating their classes people can do the following 
(Assuming Cat is a type of Pet):

When
    Person( location == London ) IsOwnerOf() Cat( color == "Tabby")
    ....

The above will get all my london people and their tabby cats. The simply 
placement of the IsOwnerOf() pattern, would be nice if () was optioal, 
would constrain the Cat to those related to the Owner. i.e. the short 
hand equivalent of:
$p : Person( location == London ) IsOwnerOf( owner == $p, $c : Cat ) 
Cat( this == $c, color == "Tabby")

I think that's powerful and provides for a hyrbid OO and Relational 
modelling approaches,  asthey can still use graph notation:
person.pets[0].color == "tabby"

This also solves the question that people always ask, how do I insert my 
collection. With that in place there would still be plenty more to do, 
like constraints, but it would be a start to improving Drools' 
relationahip programming "out of the box" capabilities. So who's game?

Mark