Two indexings of their marriage but Source Linker _still_ hasn't let me enter it
Can Linker please be made less literalist?
I'm still perpetually aggravated by the half-butted conclusions that Linker forces on me, but this one is threatening to make me boil over into rage: the civil marriage registration was indexed twice (misreading the bride's mother's name two different ways, handy for telling them apart), and I have now attached both — but the couple STILL doesn't have a marriage. I'm going to have to go in and go through the twenty-jillion longhand steps because Source Linker has decided for me that a marriage registration isn't a marriage. (In this case, it very much is.)
PLEASE, can the tool be a tool rather than an impediment? The decisions should be up to the user, not the computer.
Comentarios
-
My own preference (and I know I disagree with many users / Community members on this) is for Registrations never to be treated as an actual (BMD) event. This particularly applies to marriage registrations, whereby (and I have just tested this++) a January 1900 Sunderland (Reg. Dist.) marriage registration, when carried across by the source linker, would replace the more detailed / accurate 11 January 1900 Monkwearmouth detail of the marriage ceremony that has already been inputted and has been placed on the Details page. Okay, experienced users will go back and check on the effect on the profile pages after carrying across data via the NSL, but others will not, leading to "inferior" marriage detail now being displayed on the Details page, until such a time someone picks up on this.
++ (Obviously I did not test via the NSL, but this would definitely happen if the NSL decided marriage registration = marriage.)
My objection to Birth and Death and registrations being treated the same as the actual event lies in my day to day experience in handing England & Wales BMD sources. The registrations are often made / recorded for the following year and often in a registration district that is nor even in the county where the birth / death took place! This position is not quite so important as with the marriage situation, as at least the data cannot replace existing, more detailed entries already inputted on the Details page, but it still does not reflect accuracy: i.e., an indexed registration record can show totally conflicting detail from where / when the event actually occurred. (Example: Birth registered January 1874 Stockton R.D., County Durham, but birth took place 12 December 1873 in Middlesbrough, Yorkshire.)
In summary, as far as I'm concerned a marriage registration source does not necessarily represent a true picture of the marriage (as is the case with other marriage related events - e.g., licence and banns sources), so should continue to be treated as an "Other Information" item.
0 -
Screenshot of the effects of adding an additional marriage (related) item via the NSL. (Assuming marriage registrations could be carried across as Marriage events, in future - see my comments in previous post)
The marriage registration data would replace any marriage ceremony details - already entered to the Couple Relationship area - on the Details page:
0 -
A Hungarian civil registration of a marriage is the civil marriage. Even when an entry is copied into the register from a foreign marriage certificate or extract, the date and place are filled in with the actual marriage date and place, not the date and place of entering it. And all civil registrations clearly give the date and place of the actual event (birth, marriage, death) that's being registered, often including the time of day.
My point is that _I_ should be the one making the decision about event-versus-registration. Source Linker should assist me in putting it where I want it to go. It should NOT make the decision for me — not even if it gets it right, but especially not when it perpetually gets it wrong.
0 -
Yes, I appreciate I am talking from the specific position I experience with the England & Wales registration process. However, what worries me with regards to the collaborative Family Tree format is that other users will be able to make bad choices if this detail is allowed to be carried across as a marriage. Unfortunately, there would be no difference in behaviour whether the event related to England or Hungary. Many of the profiles in which I have an interest have had good data replaced with bad on their Details pages (because earlier dated marriage licences were indexed as marriages) and I just don't want more instances of comprehensive, accurate marriage (ceremony) detail being replaced on the Details pages by vague and misleading data from E&W marriage registration records. I agree, in principle that we should be given such choices, but as in Family Tree our work affects multiple users, the NSL options should not just reflect what is preferable to us as individuals.
0 -
There's nothing FS or anyone can do about inattentive or clueless users. For everyone else, a tool that clearly leaves the decision to the user would, I believe, greatly reduce the incidence of misplaced conclusions, because people would pay more attention.
This is one of the (subtle) changes in the new Linker that I fully approve: instead of the infuriating required reason statement about a person's deceased status (when I just got done entering a birthdate two centuries ago), the new Linker's "Add" panel simply doesn't have a default for "deceased" or "living". You have to choose one to activate the "Save" button. Yes, clicking a radio button can be done fairly mindlessly, but that's still better than the computer deciding for us.
Another advantage to having the user decide whether it's a marriage or not is that said user would be able to correct for index errors. Those old indexes that classify licenses as marriages are still in the system. When attaching them, we currently have a choice of evils: either we don't transfer the event, losing the license information (or needing to add it later, longhand), or we transfer it, and displace the actual marriage from the display (because the license is by definition earlier than the wedding).
If users had control of where a conclusion goes — not just marriage-related ones, but especially those — then index-misclassified license event information would not need to be either lost or placed wrong. It could be added to the Other Information section (ideally on both profiles of the couple), where it belongs (in the current structure/setup of relationships in the Tree).
0 -
I clearly understand your points here and am sure most users will probably agree with you on this one. However, I still can't agree, based on how this would affect the profiles I am dealing with daily. As you probably know from my previous posts, I'd prefer to see the data we can carry over via the NSL to be as limited as possible. Carrying over items like "Marital Status" and "Residence" (especially where there are two fields for the latter) creates meaningless clutter on the Details page, unless the user returns immediately to that page and adds the necessary, applicable dates. I could overcome these problems if I was dealing with the profiles exclusively, but amending / correcting the huge amount of vague and meaningless data put there by other users (especially through source linking activity) is a big headache for me.
1 -
I mentioned the "half-butted" conclusions that Source Linker currently forces on us, and the aggravation they cause. They're a broader manifestation of the same problem I'm trying to address in this discussion: the consequences of Source Linker's literalism.
If Linker weren't so literalist — or, to describe it another way, if it didn't take it upon itself to make all of the decisions for us — then those half-blank and thus all-useless conclusions wouldn't happen, or not nearly as often. If clicking the arrow on a residence (say) brought up the entire "add/edit event" popup along with a sidebar with the entire index entry, then we could transfer the date and location, and even type in the exact street address from the image. The source-attachment tool would actually be useful for attaching detailed sources to detailed conclusions.
Annoyingly, the current setup gets partway there, under some circumstances: if Linker, in its infinite wisdom, decides that the index is sufficiently different (but not too different) from an existing conclusion, then you get the "edit" pencil, and you can add all of the details and even explain your reasoning (if you don't accidentally hit "save" too soon — there's no "undo" or "edit again" function). But if Linker sees a birth in the index but a blank on the profile, that's too different: you don't get a pencil, just the arrow, which (in my experience) transfers only half of a conclusion (i.e., either the date or the place, almost never both), and doesn't allow entry of your reasoning. And, if it wasn't included in the indexing, then it doesn't exist, as far as Linker is concerned. It doesn't matter how clearly the marriage registration (say) records birthdates: if they weren't indexed, then Linker doesn't even let you see whether the profile has a birthdate entered or not, nevermind editing it.
Imagine a ratcheting screwdriver that decides for you whether to go clockwise, counterclockwise, both, or neither, depending on esoteric criteria beyond your control. That's what Source Linker is, currently.
1