I often think there really is no need for marriage and related events to be treated any differently from normal events. The only difference I can think of is that you would have two people with a primary role in the event instead of one.
Trying to use a Group construct to replace Family would be a significant undertaking given how embeded that part of the Gedcom model is in the current Gramps design.
Because of that in my mind you would need to approach it in two phases. The first to introduce the Group concept as a top level item and provide the needed framework around it with regards to editors/export/import/reports, and then perhaps later a second phase to migrate the existing Family construct to it.
In principle I like the idea but let me play devil’s advocate and list some doubts nevertheless
I believe that many users (and potential users) of Gramps, myself included, would like to use it as a lineage-liked genealogy program and I strongly feel that the family should continue to play a special role, not just as a special case of an arbitrary group of people.
After all, when you talk about groups of people, they are not just a collection of person objects. From an ontology point of view, they are actually collections of roles, with person objects linked to the roles.
For the family, we have the role of the partners (father and mother in the simplest case) and the children (first, second, third …). For a sports club, we might have a president, coach, players, …
Having a completely general ontology is a fascinating topic, but it’s also a never ending story and given Gramps’s current design (without a truly relational database for historical reasons), I think we should be careful not to overcomplicate things and make the app less accessible to new users, the code base harder to maintain, reports more difficult to write, and data more difficult to migrate elsewhere (yes, Gedcom…).
Two examples of different kind of groups with their particular attributes. That could seem like a class and its derived classes. Familly is one derivative, and father, mother and childs some presentation method. The sport club another.
That is well said, and from a practical standpoint you are right. It would be a lot of work to try to use them for the core family so likely doesn’t make sense unless you were writing something new from the ground up.
I do think there would be value in having them as an available feature though. And at some point hope to put a prototype together knowing full well it may never be accepted for incusion in the core codebase because of some of the concerns you express.
Just as Persons currently have Associations with one another, they could have Affiliations with a Group? And these Affiliations could have Dates? The Group itself could have Place(s)?
This would be solved by a “Household” group, right?
Yes that is the thinking though I have not thought about them in terms of places that much. But yes I suppose we would want that to model households which is the most obvious use case. I’ve also an interest in using them for my family who were members of fraternal organizations and benevolent societies.
Yes. The relationships would still be modelled by the Family object, but the user could create a Group to model a household. The household could include members of an extended family.
As @DavidMStraub suggested earlier, people would be linked to the group by one or more roles. These roles would include a date range.
Otherwise a Group does bear some similarity to a Person. A group may change its name over time. It can have an address, an url, media, notes, citation etc…
It may be associated with another group. We could even consider allowing a group hierarchy where one group would be part of another group. Football teams part of a league or military units part of a formation. Gorups can split and merge. Things could get complicated.