When I’m sharing a fact I can either search for an existing person in my database, or “just type a name”. When I do the latter, what does RM do? I don’t see that it creates a new person, so what happens? How is the name I just entered represented in the db? How will it show up in reports?
Hey @markwhidby – I could be wrong BUT it appears to do nothing-- it doesn’t appear to show up in a report and it does NOT create a new person–it only appears when you click on the marriage and who it was shared with…
Actually guess it is useful for info you want to save but don’t need the person in your database or know anything else abt the person such as Evelyn Parker was the Midwife
1 Like
Thanks for confirming my observations. It is a useful feature for the reason you say.
My experience is that the “just a name” people do show up in narrative reports. Other than that, it appears that “just a name” does nothing. It certainly does not create a new person.
It’s hard to describe further what “just a name does” without devling a bit into RM’s database structure. You can’t really share a fact in RM, even though that’s what the user interface and the documentation says. What you are sharing is a role for the fact. It’s a subtle distinction which not all RM users think makes a difference but which I think does make a difference. With either an actual person or a “just a name” person, when you are sharing a role for a fact, RM places an entry into a table called WitnessTable.
When you share a role for a fact, RM fills in a field in WitnessTable with the ID for the original fact. That links the shared role in WitnessTable to the original fact. That part of the process works the same whether you are sharing the role with an actual person or whether you are sharing the role with “just a name”.
The same record in WitnessTable then has fields for the ID of the person with whom the role is being shared and for the “just the name” of the person with whom the role is being shared. The “just the name” field is just the text of the name and doesn’t link to anything. When you share a role, RM fills in either the ID of the person with whom the role is being shared or the “just the name” field but not both. When you share a role with an actual person, RM gets the name of the person by using the ID of the person.
So when creating narrative reports, RM can print the name of the person with whom the role is shared no matter if it’s an actual person or if it’s a “just a name” person. Either way, the name of the person with whom the role has been shared will appear only if you include the variable for role in the sentence for the original fact. For example, the default sentence for the birth fact is as follows.
[person] was born< [Date]>< [PlaceDetails]>< [Place]>.
The Birth fact includes a role called Doctor by default. If you simply share the role of Doctor with the doctor who attended the birth, the Birth fact will not include the name of the doctor. But you can include the name of the doctor in the Birth fact by including the Doctor role as follows.
[person] was born< [Date]>< [PlaceDetails]>< [Place]>.< The delivery was attended by [Doctor].>
The appearance of the sentence in the narrative report will be exactly the same, no matter whether doctor is actually in your database or whether the doctor is not actually in your database and is a “just the name” person.
One difference is that if the doctor is actually in your database, then he or she will appear in the Name Index at the end of the report. But if the doctor is a “just a name” person, then he or she will not appear in the Name Index at the end of the report.
My message has emphasized narrative reports. I don’t think shared roles show up very much if at all in other kinds of reports. That’s because roles only show up if they are added to sentence templates, and I think RM’s narrative reports are the only reports that are based on sentence templates.
2 Likes
As always @thejerrybryan thank you for the detailed explanation. As a database guy, I value these peeks behind the curtain as they help me anticipate how a feature in RM might work.
I gotta say, though, I get a bit twitchy knowing that RM is overloading an ID field to use for Names.
Nothing is really being overloaded. I probably gave the impression that the ID field in WitnessTable was being overloaded by the way I described it. RM is not using the ID field in WitnessTable for the names of people who are already in the database. It’s using the ID field in WitnessTable to find the names of people who are already in the database. The ID field in WitnessTable is null for the “just a name” people.
I obviously can’t see the actual RM code, but what has to happen is that there is a JOIN between WitnessTable where the Shared Role information is stored and NameTable where the name is stored. The JOIN is based on the person’s ID number. It’s the same way that PersonTable works with names. Namely, PersonTable doesn’t contain any names. If RM needs to display the name of the person whose ID number is 97, then there is a JOIN between PersonTable and NameTable with the person’s ID number being the key that is used for the JOIN.
This is a very standard design with relational databases. In the olden days, databases and even just plain old files had repeating fields. Relational databases don’t have repeating fields. Instead, they have repeating rows. And in fact, we probably shouldn’t use the term fields at all with relational databases. Instead, we should speak only of columns and rows.
RM needs the old “repeating fields” concept for names because of Alternate Names. A particular person in the RM database can have any number of Alternate Names in addition to the one Primary Names. If the names were stored in PersonTable, then PersonTable would need to have repeating fields for the variable number of names. But because relational databases do not support repeating fields, the relational structure more or less mandates a separate PersonTable and NameTable which are joined together with multiple rows in NameTable for a person when the person has more than one name. Absent the need to support a variable number of Alternate Names, PersonTable and NameTable could be combined into a single table.
With that model in place for PersonTable and NameTable, other tables such as WitnessTable can also join with NameTable. Or WitnessTable can join with PersonTable which joins with NameTable, depending on the needs of the moment. Either way, there is no overloading.
Just to complete the picture, names for the “just a name” people are actually stored directly in WitnessTable. Again, there is no overloading. The only thing the name in WitnessTable is used for is to store the “just a name”. There are actually four columns in WitnessTable for the “just a name” people - Prefix, Given, Surname, and Suffix, but it’s all just one name. In other words, the “just a name” people can’t have Alternate Names.
Thanks for clarifying; I feel much better 