Automatic tagging of source when residence is added
I have noticed on the new persons detail page that after I attach a census source and add the place of residence to the person's detail page, that location shows up but no tag for it. I've been adding the tag manually, but that is time consuming. Please consider making the source for when the location was added be automatically tagged. Thank you.
Comments
-
Source Linker predates the new person page's ability to tag conclusions in the Other Information section. It's probably going to take a complete re-write of the function to add this capability -- I certainly can't think of a way to expand the current fixed set of checkboxes to include the Other box's variable contents.
4 -
Isn't it thrilling that after so many years they have been able to get this frequently requested feature of tagging sources to more than just Vitals working! It is just great to be able to tag the residence at all. Sure, it's at the model T stage, but that is a huge step above the horse. The Porsche is going to take some time. Hope it won't be another ten years to be able to tag in one step but it will probably be at least a few years to design, develop, program, test, and release it.
4 -
The code already exists to automatically tag a marriage record as a source when it's used to create a marriage event during linking. It doesn't seem like it should take a total redesign to port that same functionality to the other fields.
0 -
This may seem pedantic, but it's an important distinction: Source Linker doesn't tag marriage sources to events. It just adds the source to the mysterious, hidden couple relationship area's Sources list. Sometimes. With no pattern that I've been able to discern. (Probably because I seldom take up Source Linker on its offer to transfer the marriage event, since it's almost always already there.)
Once a source has been added (somehow) to that well-hidden, totally-segregated list, then a user can tag it to the event. Which in the current setup is shown right above the source. (There's a Facts section in between, but who has ever used that?) This makes me think that they must be planning or preparing for future revisions where such tagging will make sense, such as a source counter on couple events (like what we now have on everything in Vitals and Other).
1 -
One place the marriage sources show up is the new Couple Event View Data popup which you get to from clicking in grey highlighted area that appears when hovering over the couple event and from which you can tag sources to the event:
This first iteration only allows this for the single event that shows in the Family Members section and the only sources that can be tagged are ones that appear in Couple Relationship Edit popup. But this is nice progress. They just need to add the counter, add all the other marriage events, and add the ability to add sources from the husband's source page and the wife's source page.
1 -
I just tried it. After attaching this marriage record to this couple automatically tagged as a source for the relationship, it's listed as a source for the relationship event. That's what we're saying should have been implemented out the gate for Other Info sources.
0 -
@RTorchia, no, that source has not been tagged for that marriage.
As I wrote above, the marriage record has merely been added to the couple relationship's sources list.
1 -
| As I wrote above, the marriage record has merely been added to the couple relationship's sources list.
Which for all intents and purposes is "tagging". It's tagged as a source for the Relationship. If you object to the use of the word "tagged" to mean "added to the list for", it's the same term used when adding sources to the Relationship Event source list itself: the word "tag" is used, but there is no marriage "tag" like there is for birth, death, etc., just a checkbox.
Yes, I misspoke slightly when I said "relationship event" because I didn't realize those had separate source lists -- the existence of the Relationship Events source list is completely hidden unless sources have been added to the Relationships list. But the point was that the general functionality already exists that generating an entry from a source gets automatically adds that source to a list. It should not be especially difficult to copy that functionality to other source lists. It's clearly what a user would reasonably expect to happen now.
Looking at it more closely, there's a lot of problems with the current design. Having separate source lists for relationships and marriage events seems a little unnecessary -- maybe slightly useful if there are conflicting dates and places, marriage/divorce/remarriage, and maybe if we had marriage intention/engagement/registration events (ew, no, don't do that), but most relationships have only have a wedding event and maybe a divorce event, which really don't need separate dedicated source lists. Otherwise when were dealing with multiple sources, it's usually duplicate copies of records or derivative records that describe the same event. And that's what leads to a bunch of problems here:
- Linking a marriage source only automatically adds it to the relationship source list only if the marriage event is added during linking. The option to add the event isn't available if there's already an event with the exact same user-facing and standardized dates and locations -- if that's true, you can't add the source to the relationship source list during linking. If there's any mismatch in any field, for example "04 Apr 2023" in the source's user-facing field, even though the standardized values are the same, then event can still be added during linking (and must be if you want it to appear in the relationship source link automatically) -- it'll be essentially a duplicate event with the same information, which then has to be deleted manually. If you edit the fields during linking so that they are an exact match, the source still gets added to the list, but a duplicate event is not created -- this tells me they're already pretty close to being able to allow the source to be matched to an existing relationship event and automatically added to the source list, just like you'd link a birth record to an existing child.
- (The source is added under the source ID and title of the source for the spouse, not the person in focus during linking. I don't think that's a bug necessarily, but it feels weird. If you open the source from the source list, it opens with the spouse in focus.)
- Similarly, adding the marriage event during source linking adds the source to the Relationship source list, but not the Relationship Event source list. I think it's fair to say that's a design bug. If the intent is that relationships and relationship events are separate things with separate source lists, it makes no conceptual sense that an action that adds an event doesn't add it to the event source list.
- Also, if they're different things with different source lists, the Relationship and Relationship Events dialogs should have different titles. They're both just "Couple Relationship".
- There's conflicting design models here: a person and their relationships are totally separate, but not the relationships and their events. The whole thing should be hierarchical: Event sources are a subset of Relationship sources, which are a subset of person sources. That can be done either through tagging or checkboxes, but the complete disconnect here is a design flaw with substantial negative effects, for example: 1) There's no easy way to add a source already linked to a person to the Relationship source list. 2) Deleting a source from the Relationship source list also removes it from the Relationship Events source list, but deleting it from the person's Source list doesn't remove it from the Relationship source list, even if you detach it immediately after linking within the Source Linker. 3) External sources have to be entered from scratch separately for both people and relationships.
- Sources that were added to the Relationship source list during linking do not indicate they're attached user's Source Box and can be added again. That's bad.
- "Marriage notice" and I would guess "Marriage registration" events that are added during source linking are added as custom events (which is a separate bug -- it's obnoxious behavior and doesn't help for anybody with more than one marriage), and are not added to the relationship source list, even though they're clearly sources for that relationship.
- It's inconsistent behavior that adding a marriage event during linking adds it to the Relationships source list for couples, but adding a birth/marriage/death records doesn't doesn't get added to the Relationships for parents and children.
2 -
First, I want to state for the record that I agree fully with any sentiment expressing bewilderment (and less polite things) about the current relationship-area setup. I hope it's a work in progress.
However, @RTorchia and I are still using the same words different ways here, I think.
When you say "Relationship Event source list", do you actually mean those sources from the relationship sources list that have been tagged to that event? I mean "tagged" very precisely: "used FS's tagging tools to establish a direct link between that specific conclusion and that specific source."
I wonder if this same mismatch in the use of the word "tag" accounts for the recurrent mistaken belief that the old layout tagged Other Information to sources. (Held for example by at least two commenters on this thread: https://community.familysearch.org/en/discussion/comment/504754.)
2 -
You're right in that those people are mistaken in thinking Other Event source tagging existed before. I think they're reacting on a more abstract level: the old system didn't say, for example, that a Residence entry had zero sources supporting it:
You and I understand what this means from the FS design level: that nothing in the person's main Source list has been tagged as proof of this specific entry. I think their interpretation is that the system is basically telling them "there is no evidence that this is true", and their reaction is that the census is in Sources and that's the source.
You're right in that this is a misunderstanding of the design, but I can't really fault them for this reaction. I would point out to them that sources added before the Vital Info tags were introduced also show 0 sources for those vitals, even though sources have already been attached.
I don't know the best way to resolve this confusion. Maybe FS should consider only showing the number of sources attached if it's not zero? Or you can tell them if they're really bothered by it saying 0 sources, they'll have to make the time to link it on the profiles they most care about.
The confusion between us is because FS is creating different flavors of identifying relationships between things and isn't handling it consistently.
- Identifying the relationship between an index in a source to a person's profile page is done by "linking", and is intended to be a 1:1 relationship.
- More granularly identifying the relationship between a source and a Vital or Other information for a person is done by "tagging" from the Person's source list -- an actual graphic label that appears on the list as soon as it's added. This can also be done from the Vital/Other Info side by checking a box, but the graphical "tag" does not appear when the source is viewed from the that event's source list. So does "tagging" refer to the object or the act of identifying the relationship between the source and the information?
- Identifying the relationship between a source and the Relationship between multiple people (i.e. getting something on the Relationship source list) is done while "linking" a source -- an action intended to establish a 1:1 relationship, and even lists it as a source for only one member of the relationship -- by adding the Relationship event during linking. What's the short-hand term for that action?
Given the lack of a clear concept for that action, and how it doesn't really fit the concept of "linking", calling it 'tagging' due to the similarity of the action seems reasonable . That's why people will rely on that term even though that's not what it's defined as from FS's technical perspective: it's perceived as the same action. Otherwise another term is needed, and the design really doesn't suggest one.
0 -
(I wonder if a change in wording would help the people who object to the "0 Sources" display: what if it said "0 Source Tags" instead?)
I conceptualize FS's source tagging fairly simply: the profile has a list of sources, and a bunch of conclusions, and you can establish a link between a specific source and a specific conclusion by tagging the one to the other. The word "tag" refers to the link, which can be established and looked at from either end: you can tag a conclusion with sources, or you can tag a source to conclusions.
The only limitation is that the source and the conclusion have to be on the profile. You can't tag Uncle Rob's 1930 residence with the 1930 census unless you've found and added that census to Uncle Rob's Sources list, and likewise, you can't tag the census to his residence if you haven't entered the residence. Entering the residence or attaching the source on Aunt Sue's profile doesn't help one iota.
The way relationships and their sources are currently set up, it's practically like the relationship is a separate profile. It certainly has its own separate sources list and its own separate bunch of conclusions (relationship events and facts), and you can only put tags between entries on that separate sources list and those separate conclusions. Having their marriage index attached to both Uncle Rob and Aunt Sue doesn't help with tagging it to their marriage event, just as Aunt Sue's census entry doesn't help with tagging Uncle Rob's residence.
This segregation of relationships into their own entities may make the programming easier, but it sure as heck isn't intuitive. What I and I think most other users of the Tree would expect or want is for the sources list for Rob's and Sue's marriage to consist of all of Rob's sources plus all of Sue's sources, and we'd expect or want their marriage event to be available to tag from either of those sources lists. I have no idea if such a structure is at all feasible, but it would sure be nice.
1 -
I conceptualize FS's source tagging fairly simply: the profile has a list of sources, and a bunch of conclusions,
I think it's almost the other way around. "Conclusion" implies a deductive thought process. Tagging represents substantiation of a fact with a source.
You'd link a source to a person page if you examine the source, the known facts about the person, and logically deduce that the person referred to in the source is the same as the person represented by the page -- i.e. the conclusion is they're the same person. That a marriage occurred on a certain date based on a marriage record or that person lived in a certain place on a certain date based on a census is a statement of fact. You're just repeating something a source said. Tagging the source just links that source to that fact (though whether the source is linked to the correct person is still a logical conclusion).
(I could also see a conclusion being, for example, listing a child's 1840 residence based on an 1840 census report for their father that includes a resident of the correct age -- the record doesn't explicitly mention the child's name, so it's a logical conclusion based on available data.)
Whatever the verbiage used, the difference there is much too subtle for most people to perceive and distinguish between the two systems.
I think we agree on the design of the Relationships section. For me, one priority for FS should be to design a better and more fully integrated sourcing and tagging model. I don't know -- off the top of my head, I'd say FS needs a way to link two (or three, for parents and children) source indexes together an have that as a single Relationship source entry. This would also allow the source lists to be better connected by allowing Relationship sources to be drawn from person source lists.
0 -
I agree that the act of attaching a source to a profile represents a conclusion, but I disagree that the entries derived from it are simply facts. Those are also all conclusions. Even if there's only one source for a particular entry, there's a judgement involved of whether the document is trustworthy for that detail, and whether our reading or interpretation of it is correct. When there are multiple sources for a particular entry, and they don't entirely agree, the conclusionary nature of the entry becomes even more apparent.
But as you said, whatever the terminology, the important point is that treating relationships as a segregated and separate thing, almost like a leper colony, is not conducive to effective sourcing.
0