Assume we have two related MeshObjects, each blessed with a (hypothetical) type Person. Like this:
MeshObject obj1 = ...; MeshObject obj2 = ...; obj1.bless( PERSON ); obj2.bless( PERSON ); obj1.relate( obj2 );
Now if we want to express that the second Person is the daughter of the first Person, we cannot do this:
obj1.blessRelationship( PERSON_PARENT_PERSON, obj2 );
because we don’t know, from this API, whether obj1 or obj2 is the daughter or the parent.
Instead, in InfoGrid, we have to explicitly specify the direction, and we do this by specifying the “end” of the relationship type instead of the relationship type for the bless operation, like this:
obj1.blessRelationship( PERSON_PARENT_PERSON.getSource(), obj2 );
Hopefully, the documentation of the parent relationship type in the model indicates the semantics of the source and the destination of each relationship type. These “ends” are called RoleTypes, by the way.
One nice side effect of this approach to the API is that it becomes quite straightforward to extend it if InfoGrid ever decided to support ternary or N-ary relationship types: Just pick a RoleType beyond a source or destination RoleType.
If you bless relationships from the HttpShell — the simplest way of manipulating the graph from a web application — you thus need to specify the identifier of the RoleType, not of the RelationshipType. By convention, the source RoleType of a RelationshipType with identifier ID is ID-S, and ID-D for the destination.