FamilySearch should create individual sources for both marriage partners

LegacyUser

Paul said: Further to my post at https://getsatisfaction.com/familysea... I feel this specific request really needs to be addressed urgently.

It is surely not acceptable that the woman (because that is what always seems to be the case) in a marriage source no longer appears as the primary person, however the marriage source is added.

This is not only wrong because of the way it reduces her status in the event, but because the current resulting source heading (e.g. "Hannah Wrightson in entry for Robert Gibson...") could mean she is a parent of the other person. Indeed, if she were mentioned in the record of her SON Robert Gibson the source heading would appear no differently.

As illustrated in the other thread, and confirmed by Gordon Collett, this is not the way the marriage source for the woman used to be formatted, so please revert to the former way as soon as possible.

LegacyUser

Tom Huber said: I'll be very honest, Paul, I do not like the person-centric approach to sourcing records. I would prefer the approach be source-centric

Marriage record for Robert Gibson and Hannah Wrightson

That makes eminently more sense, no matter where the source shows up, including for the parents, for the marriage event itself, for both persons in their source list.

LegacyUser

Paul said: No, I don't think I'd have too many worries about that, Tom. This would make very clear what Hannah Wrightson's role was in the event. As I say, there are times when the mother is shown in her maiden name in a child's marriage record, leading to the source heading appearing in identical form as if it was for her own marriage. There should not be the confusion currently being presented, especially to other users, in identifying who Hannah (or any other female) was.

LegacyUser

Gordon Collett said: Years ago there were several posts about why FamilySearch uses the one source per person model. It's all to do with being able to use the sources collectively to confirm information about an individual and find more information based on that that. The Hinting process makes use of that.

Since each piece of information in the source can be used, having "person-centric" sources allows programming to pull out information for Mary:

Birth:
From birth record: 1845
From baptism record: 1845
From marriage record: 1846
From death record: 1844

to declare these as consistent and confirmatory and find more record for a Mary born 1844 to 1846 (of course taking all the information in the sources). If a source given a birth year of 1820 was ever added, a warning or data error could be placed on the record.

Conflating Mary's and Williams's marriage sources into a single source would give:

Birth:
From birth record: 1845
From baptism record: 1845
From marriage record: 1846 and 1840
From death record: 1844

The ability of any programing to provide reliable data analysis is impaired.

However, the title on the source does not make any difference in being able to use the data in the source. So the title should make sense and not be ambiguous.

So I do agree that the new form of the title, "Mary Jones in entry for William Smith...," for marriage records is a big step backward into confusion.

I don't think I would be bothered by having the title for both versions of the marriage record be "Marriage record for Mary Jones and William Smith."

The source linker already does a good job disguising that one is attaching between two and six different sources for each marriage record depending on how many people are mentioned in the record and many people who have posed on this board about the source linker clearly don't realize that they are attaching a different source to each person. And that really doesn't make any difference to their work. Having the title the same would just hide a little more what the source linker is doing.

LegacyUser

Jeff Wiseman said: The OPs observation is right on the money.

The fact is, that with an indexed marriage record you always had to have two distinct citations to the index. One to one spouse and another to the other. BOTH of these are applicable and should be attached to (or more appropriately Tagged to) the couple relationship for the marriage.

The problem occurred when FS tried kludging different things in their attempts to automatically attach these citations to a Couple Relationship. They tried several things such as only attaching ONE of the two citations, and then subsequently tried to "simplify" it by mucking around with the titles in order to fake a single citation.

(note, I have no "inside information" on this, it is just what I observed over time)

When I saw that experimenting start in the production database, I knew they were on the wrong path and it would eventually collapse. There were some more attempts to "fix" things that just made them worst, and then suddenly a couple months back, all of the changes stopped completely and the system stopped attempting to attach retitled clones of citations for the individuals to the couple relationships that they had.

So now, there is no easy way to use the marriage citations on each of the spouses by attaching them to the couple relationship at all!

But the nuisance is that there are still a bunch of old citations with hacked titles from those experiments that are still floating around. I'll typically correct those titles when I come across them, since the remnants of those experiments are littered across a lot of the records I've worked with.

Anyway, the issue comes back again to the method being used to support the sourcing for couple relationships. If they simply used tagging of those citations already attached to the individuals, modifying the way that they used to auto title citations would never have been necessary.

LegacyUser

Jeff Wiseman said: Tom, See my response below.

LegacyUser

Juli said: Jeff, I think you haven't stepped back quite far enough. You're trying to encode complicated relationship data in an index pointer. In my favorite library card catalog analogy, this is like trying to fit the book's entire foreword on the index card.

I think the essential model boils down to three parts:
1. Persons and conclusions about those persons -- including their relationships to each other -- in Family Tree.
2. Document images with associated metadata (film and image number, catalog and/or waypoint data).
3. Index entries consisting of labeled fields and their contents.

Each part has its own dedicated search interface (Find, Catalog, and Search - Records), which should be designed to deal only with the type of information included in that part. For example, we're used to expecting categories like "spouse" or "parent" in an index search, but really, it's just subsets of "people in record", based on groupings of the various possible field labels.

There are linkages between the parts. Some of these are "prepopulated": for example, if an index entry was based on a document image, then there's a link or pointer between the index entries and the image. Other such linkages are "aftermarket": for example, if a user finds Joe Schmo by paging through images, he can attach a citation to that image to Joe Schmo's person.

But here's where it gets complicated, and I'm not sure what's essential model and what's implementation: the linkages between parts aren't one-to-one. If that image where Joe Schmo was found contains six marriages, it's likely linked to twelve index entries (or more, if the parents were indexed). So when I attach a citation of the image to Joe's person page, what part -- if any -- of those twelve or more links should come with it? Should the system offer to attach a citation to Joe's relatives, too? There will always be indexes that don't have images attached, so we have to allow citations of indexes (i.e. links between parts 1 and 3), but should the availability of an image (a link between 2 and 3) affect that in any way?

Another part where I'm not sure where the model-versus-implementation line falls is the designation of a primary person for an index entry. We're used to "needing" one, because we're still accustomed to the notion of an alphabetical index or phone book or whatever, but if you can only access the index via a search engine, do you really actually need a primary person?

Relatedly, how should an index deal with groups of related people, like on a census page or ship manifest? Should each person be a separate entry, with no connection between, or should families or households be all one entry, or is there some other way to model it that doesn't introduce more complications than it solves? Where is the line between a "subjects:" card catalog and squashing the foreword onto an index card?

LegacyUser

Juli said: I'm not braining well enough tonight to comprehend everything you wrote, but I'm getting the basic impression that you're still thinking of the index as primary. I suppose this is natural, because the computer can't read the writing on images.

I want to be able to cite the sources that led to my conclusions independently of the indexes that helped me to find said sources. Including linkages between indexes and citations should be merely a convenience, designed to allow adjacent researchers to not need to re-invent the wheel, regardless of which side of the axle they're approaching from.

(I feel like we're probably re-inventing the wheel: surely someone has already thought through all of the aspects of a data model for genealogy....)

LegacyUser

Jeff Wiseman said: Not exactly sure of what you mean by "primary". I would not consider the index data to possibly be a "Primary" source when it is only a collection of conclusions based on an image or paper document type source. Furthermore, all those conclusions are arrived at by some random indexer who has little or no knowledge understanding of the names they are indexing. The original image or paper documents would be the primary. But from a digital searching standpoint, the index is the FIRST thing that you can find, because it is designed to be searchable. So would you call that a "primary" source? I probably wouldn't, but if it's an index of a primary source, could you call it "primary" then? I'm not sure what the semantics here would be.

The main issue, though, is how we enable automatic searching for data on a computer and having automatic tools to maintain hooking up all the details. I believe that you can use the indexes to find things and then from the index follow over to the source image and cite that image directly if you like. But of course you can't do that using things like the source linker and all that automated stuff. But that is just how the site is set up. Many people using the site are gonna like all that "single push button" stuff. I mean, I do too, but when I need to use those masses of records that aren't indexed, I want to know how to do that too.

But if you are bypassing actual indexed data to cite the original sources, it might result in some "collisions" by other less experienced folks working on those same records and seeing the indexed data.