We have now completed our second development cycle of the Family Tree modeling language. Even though this would be the first version we could use for some real modeling, it is very usual that the modeling language continues to evolve. The next most probable target of development in our Family Tree language is the Family relationship. Though we are not going to explore it further within this tutorial, here is some food for thought in case you want to experiment with it by yourself.

Currently the Family relationship in our Family Tree modeling language is semantically quite loose. This is both an advantage and a disadvantage. As it just presents the situation where a Male and a Female can have a union that produce children, we can model all such situations easily with the same relationship type (e.g. there is no requirement for parents to be married before they can have children). The emphasis here is on natural bloodline. However, in many cases we are actually not so much interested in the bloodline of the family as a legal entity. For instance, we may want to separate families where parents are married from those where parents are not married. This may require a specialization of the Family relationship in the same way we did with Male and Female.

Another important question is the status of adopted children. In the family tree that presents only bloodline relations they are not shown, but in legal family trees they may have an important role (e.g. in the families of Roman emperors an adopted child could become an heir to the throne). Perhaps the best way to do this would be to specialize the Child role as Physical child and Adopted child.

A further step would be to apply the Family Tree modeling language—with modifications of course—to some other problem domain. One possible domain for such an application would be animal breeding. The people who breed animals, such as horses and dogs, need to store information about their animals. They also want to be able to follow and analyze certain properties of the animals through the breeding lines and generations. This would require a whole new set of properties to be included into the Family Tree modeling language – or is it a Breeding Line modeling language already?

As you can see, the need for modeling language constructs and how they are implemented originates from the problem domain itself and the intended use of the language. Finding the required domain concepts is a very important part of creating a modeling language and also one of the more difficult tasks to carry out. However, MetaEdit+ provides you with a solid, flexible basis, so you can feel free to experiment with your ideas!