Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Adding Marriage Sources via the Source Linker is Attaching the Source Multiple Times

Now when you attach a marriage source to a couple via the source linker, it is not only added to the person's source list, but it is also added to the marriage relationship data source list as well.

I don't have a problem with this but what is happening is that the source is always being attached TWICE to the marriage data source list. So overtime I add a source I have to detach one of the duplicates.
1 person likes
this idea
+1
Reply
  • More likely you have same data extracted from more than one source. This happens all the time.

    Take a closer look at the source information. If they are different, just attach the sources. You don't have to add places and dates again and again.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. sad, anxious, confused, frustrated indifferent, undecided, unconcerned kidding, amused, unsure, silly happy, confident, thankful, excited

  • 1
    I can confirm this is happening. This couple had no relationship sources at all. I added one instance of a marriage record source and this occurred:



    Viewing the first source then the second source:





    shows identical URLs.

    I imagine that what is suppose to be happening is that the husbands version of the source and the wife's version of the source are each supposed to be attached instead of two copies of the husband's source. I think this is about the third attempt to get these marriage records into the relationship sources. Thanks for continuing to work on trying to get this functioning. It will be nice when it finally does.
    • view 2 more comments
    • Well, the FS advantages are primarily through indexed type sources. For an unindexed marriage source you would still have to attach it separately to each partner and then a third time for the relationship source.

      I have been using a "Tagging-like" method for relationship sources for a while now. Since a relationship source gets attach to all person's source lists via the source linker, they are already duplicates (although their title might be slightly different). For example, when I enter a date and location for a marriage, I simply record in the Reasons for change the name of the source which is already attached to everyone in the relationship. It should be reasonably obvious that a person could go to any PID in that relationship and the source with that name will be found.

      Not ideal since anyone can blow away the reasons for change texts. But it's a darn sight easier than maintaining many more independent (and REDUNDANT) relationship Source lists
    • The "Attach to Family Tree" button on unindexed images can attach to any immediate relative of the primary person you choose, so it's only one set of parents (and the witnesses, if they're relatives) that need to have the citation attached separately -- and if you remember the Source Box checkbox, it'll even be the same "symlinked" source citation. Similarly for non-FS sources: if you create a source in one person's source list, and remember to check the (dratted) checkbox, you can add the source to everyone else starting from your Source Box (instead of square one, like on Ancestry) -- and they'll all be linked. This means that when you manage to decipher another word or three, you can edit the transcription in one person's source list, and it'll get corrected everywhere. Other than the need to find this all out the long way, because there's no documentation or instructions for anything on FS, it's all ingeniously done and convenient, and I wish something like it was available on WikiTree, Ancestry, etc.

      I do the same thing you do with relationship sources: I just put a (shorthand) reference in the reason box. Not perfect, but better than the alternatives (no explicit connection between source and relationship, or duplication of effort and text).

      I have zero experience with Source Linker and relationship sources -- until very recently, none of the marriage records for my ancestors were indexed on FS. (Budapest civil registration indexing is ongoing, and a surprising number of my relatives did stuff somewhere in Budapest, so I'm getting more and more record hints for events that I already found the long way and attached as images, but I haven't gotten any recently.)
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned kidding, amused, unsure, silly

  • Gordon, when I go look now I only see that one source. Perhaps it was a display problem? No indication in change log of dup Sources either.
    • view 1 more comment
    • I just had a second to check the change log. Strange. Adding the second source was not recorded and neither was detaching the second copy. But it did happen.
    • I've seen it too but haven't really investigated. When you detach a source that is in the Marriage relation source list (i.e., not a person's source list), where is that event recorded? Is it supposed to be recorded in the husbands change history, the wife's change history, or both? Technically it doesn't belong to either--it belongs to the relationship entity itself (i.e., the entity that contains the relationship source list). But does such a relationship specific change history even exist yet? I don't know, I haven't investigated that far, but this might just be another item that got missed.

      That's the problem with relationship entities. None of their attributes belong to the husband, or wife, or father, or daughter, etc. They belong to the relationship itself. Formalizing the relationship entity as has been done here (at least in part) by having a separate source list for the relationship, is technically the most "correct" approach, but practically it can create a data maintenance nightmare for the software supporting the relationship itself (e.g., the relationship source list). For example, if the source list for the relationships (such as marriages) is separate from the source lists of the husband and the wife, then technically you are also going to have to support a change history for each relationship source list in the system as a separate history from any of the PID histories.

      I have not done any in depth analysis on this, but I strongly believe that by formalizing all relationship entities in the system (such as the marriage relationships) FS is opening a can of worms. That is because of the following:

      The theoretically "correct" solution of a separately formalized relationship entity with its own source list would be fine if sources were all coherently "Clean". By that I mean that person vital sources would not contain relationship information, and relationship sources would not contain person vitals information. But this is almost NEVER the case. Nearly ALL relationship type sources (e.g., birth records, death records, marriage records, census records, etc.) also contain Person profile specific data. This means that all of these source types will now have to always be attached in multiple places. I.e., in both the PID sources lists for everyone involved as well as all the relationship sources lists that anyone is involved in.

      Note that this problem also extends BEYOND just the marriage source lists as you now have separate parent-child relationship source lists for every parent against every child in a family as well--this issue is expanding exponentially here. For example a source showing a US 1900 census record would be attached to a father's PID. That is because it contains birth and residence location in it. But because it shows family relationship information it would have to be attached to that father's marriage relationship source list, and then to each of the relationship source lists between he and each of his children. If he has 8 children, that means the same US Census source would have to be attached to 10 separate and distinct sources lists (i.e., 9 relationship and 1 PID source lists) for just HIS documentation!

      This is why I believe that the current implementations being tried out are based on major oversimplifications of the problem.

      To me it makes far more sense to just attach all sources for OR RELATED TO a person into that person's source list and do NOT maintain separate formalized relationship entities. That will eliminate the massive redundancy that is going to exist across many source lists, and it will remove all the software issues that will occur trying to maintain such a complex structure.

      Currently we don't attach the same source to each vital. Each source in the person's Source list gets tagged to each vital where it applies. When you are looking at the vital itself, you can see all the sources applicable to it (WONDERFUL addition by the way), but these are only REFERENCES to the actual sources stored in the person's source list. These are NOT separate attachable lists. All relationships should behave in a similar fashion. But then you get into the problem where the tagging has to come from a source set that is predefined and separate from the people involved in the relationship.

      So basically, I believe that some kind of pseudo tagging mechanism should be investigated as the compromise. Again, I don't know how this might work As I have no idea of the innards of the FS software is constructed. But I'm suspect that things will continue to get more complicated on the currently visible path.

      And that's why I said that I do wish them luck in their attempts to get this working in whatever method they choose to approach it. It will be great to be able to have relationship related sources somehow documented adjacent to the relationship data.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. sad, anxious, confused, frustrated kidding, amused, unsure, silly indifferent, undecided, unconcerned happy, confident, thankful, excited

  • If you get it in this situation again, post the pid. Thanks
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned kidding, amused, unsure, silly

  • I see we now have a second Joe Martel. Have you resorted to cloning to solve your resourcing problems?
    • view 2 more comments
    • This comment was removed on 2019-04-11.
      see the change log
    • I suspect that Joe has so much to go over from this forum all the time that he decided to categorize some of it into separate groupings :-)

      Or, because the new name is not identified as an employee, it does not automatically get placed at the top of the topic as an "Official Representative" when he posts in a topic.

      In any event, I miss his picture that I'm familiar with :-)
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited sad, anxious, confused, frustrated indifferent, undecided, unconcerned kidding, amused, unsure, silly