What a fabulous find @kfunk !! Development will be interested to hear about your findings (and I hope they take on board some of the other suggestions too 
)
Confirmed your observation, the consequence of which is that you cannot get at the Association Types edit window from the Fact Type List window. the workaround is via an Association in an Edit Person screen. I’m sure this can readily fixed by an RM9 update for future imports and, maybe, said update could detect the absence of the Fact Type and correct it for prior imports. It can be readily corrected using sqlite:
https://sqlitetoolsforrootsmagic.com/forum/topic/fix-rm9-association-fact-type-missing-from-imports/#postid-740
Confirming the issue when importing RM7 or earlier versions not including Associations on the Fact Type List has been reported to development.
I believe there are only 4 reports that support Associations. The rest are on the development list for review.
Association List (Relationship)
Association List (Individual)
Custom Reports
Narrative report
If I have missed one you will see the check box to include the associations on it.
The headers on the Association View are sortable. From there you can select person 1 or person 2 to open both their edit person screens.
1 Like
Would be nice to be able to produce the Association List (Individual) for all people assigned to a group
1 Like
Confirming suggestion has been reported to development.
I (think I) understand the rationale for Associations, and I can understand why they might be useful in some situations. However, I also think that the emphasis on the Association fact type is ignoring the existing facility for declaring associations: the ability to share a fact type. IMO a shared fact declares an association between two individuals, very similar to the relationship declared by the Association type. With this in mind, I recommend modifying the Association view to allow shared facts to be displayed in addition to (instead of?) declared Association entries. The columns could be something like:
- Relationship: the fact type
- Role 1: “Primary” or something similar
- Person 1: the primary person attached to the fact
- Role 2: the role associated with the shared fact
- Person 2: the second person
- Date, place: as extracted from the shared fact
One thing I’m not certain about is “transitive” associations. That is, if Person A is associated with Person B (either via an Association or a shared fact) and Person B is associated with Person C, does that / should that imply an association between A and C? If so, what should the role be for the transitive association, and should there be a date criteria for declaring A and C associated (A is associated with C only if the association between A and B was within, say, a year of the association between B and C)? If the A-B-C association is called a “second level association”, then what about third and 4th and … level associations? Should there be a report of second- and higher-level associations for an individual or group? Is the compute power needed to determine the second- and higher-level associations worth whatever historical clarity we gain?
2 Likes
You’ve raised some excellent questions and concepts. The 13-year old shared-events feature has remained underdeveloped since its release. It lacks in reporting, searching, grouping, analysis and transmission. Now we have a bolted-on Associations feature with some degree of reporting, at least, albeit primitive. So there is lots of room to improve both and maybe interface them, provided developers have the motivation to do so and not let them moulder on marketing’s Features checklist.
One of the early and still present difficulties with shared-events is transmission to other systems. A few now handle RM’s custom GEDCOM tags for them but they are not involved with TreeShare and FamilySearch. Associations are currently even more confined but hold out the possibility of wider-spread compatibility because they are defined in GEDCOM 7.0. To overcome transmission barriers for shared-events, I (and others) requested that RM split them on-the-fly as an option for GEDCOM export and, potentially, for interaction with Ancestry and FSFT. I developed a converter to demonstrate the process as a batch procedure on the database and to assist those who found their embrace of shared-events trapped. Now I’m wondering if a converter from shared-events to Associations might prove viable and useful.
Hmmm… I didn’t realize that Association was in the standard. Given that, it’s understandable that RM9 would make Association a first-class event. Converting from RM shared events to Association seems fairly straightforward: create an Association for each primary-to-shared-target connection. Going back would seem to be more of an issue, particularly since it doesn’t appear that Association has sufficient standard fields to indicate the fact/event from which it came. I emphasize “going back” since in the best of all worlds a RM GEDCOM export would be “lossless” - importing a RM GEDCOM export should produce exactly the same RM project file (except perhaps for the media links). Maybe put formatted text into the Notes field of a “derived” Association that would allow the RM import to produce the proper event/fact share?
If I’m understanding correctly @shorero (and I’m not sure if I do), you’d like shared events converted or “merged” into the associations functionality.
I’d just like to add that if development take this on that the process should be optional, and only instigated by the user. I have used shared events for what I see as “transitive” relationship events, and use Associations where I would like to explore a relationship more. I would like to keep these groups separate.
Also, I think others have used the share functionality to facilitate data entry and have thus added household family members found in census records using the share facility. To “merge” these would, I think, be unmanageable.
But I can see how many would appreciate and use the concept that’s being suggested – I just think it needs to be optional.
I tend to agree. My canonical example of a shared event is a post-1850 census event, where the children are listed in the census as well as the parents. In this case the fact in the children should have exactly the same info as the ones in the parents, except for the role that the children are playing.
The census also provides an example of an Association. I used shared events to record neighbors of the family I’m interested in, but that’s not entirely satisfactory, since (a) this approach drags the entire base source into the neighbor’s record and (b) the neighbor relationship is reflexive (if A is a neighbor of B, then B is a neighbor of A). I can show these relationships, but it tends to clutter the person record of both A and B. An Association is a better representation of the neighbor relationship, since an Association is reflexive by default.
So, my bottom line is that I can now use both, which is a good thing.
WRT to conversions, I don’t want anything to mess with the shared events that I’ve defined. What I’m suggesting is that, to stick closer to the GEDCOM standard, RM’s GEDCOM export should somehow convert shared events into Associations, but only for the export. The trick, as I see it, is to ensure that the import of a RM GEDCOM produces an identical project, including the shared events, which means that the RM import code needs some way to distinguish Associations derived from a shared event from an Association entered “natively”.
Agree totally @shorero! Thanks so much for taking the time and explaining (as I did misunderstand the finer points made!). 
I was really excited to see the update. I have one person I’m researching that wrote a lot of letters… A lot.
I created a new association called letters (sender/recipient). The ability to see layers deep was really helpful, but it would be great to be able to have the option to include associations in the Individual Summary Report.
At the moment, my workaround is essentially a double entry - add the association by letter, then create a Misc fact for it and share it with others as Sender, Receiver, or Subject of.
Overall though, I’m really a fan (pun intended) of the new feature.
Thank you!