(this is a summary of what uschi and adrian drafted, just to publish our wishes, needs and ideas somewhere.)the data model should consist of the following elements:
- organisational unit
- information object
motivation for this abstraction was derived from the fact that in both university we've got people working in different position (with different office hours, postal and email addresses). if we use the person-role-organisation paradigma, we can abstract the organizational structure enough. fluctuations in the organisation (team members move to other teams, new coworkers, etc) are easy to manage this way. german university really like their workgroups. every 6 months members change and roles can differ.
using roles also enables us to filter people based on their function. with a role "coordinator" in the unit "language center" i can add contact informations on one page without having to know or care who really fulfills this role.
a organisational unit object stores data about every organisational unit in the framework. an organisational unit is a collection of persons and roles. an arbitary number of information objects can be attached to an organisational unit
a person is a living human being that is a member of a organisation. every person is a member of at least one organisational unit, can have an arbitary number of roles and information objects. (instead of allowing direct associations between persons and organizational units, it would be more flexible and clean to add a dummy role "member" to every person and attach that role to the organizational unit.)
every person acts in different roles. a role is a defined as a situational context where the actions and responsibilities of a person are different. eg in one context a member of an organisation is the leader of a project group, in another he is a developer. every role is part of at least one organisational unit. information objects are attached to roles as well.
information object are information capsules that can be attached to every unit, person or role. information objects keep attributes of that element (abilitites, skills, names, addresses, etc). to keep the party management framework adaptable to a different number of situations, these information objects can and should be easily extendable. this way we could eg create a information object that stores different projects or publication of a person.