* How to record slaves in Family Historian

[divester]

I recently discovered an ancestor who owned several slaves and bequeathed two of them by first name to a couple of his children. Any suggestions about how to record enslaved persons in Family Historian? I could address the subject as Possessions under Facts, but that seems inadequate and off. I could record them as Unrelated Persons, but that too seems to miss the mark. And as I'm fairly new at Family Historian, I don't see how Unrelated Persons can be linked to the person owning the slaves.

I tried a word search in the Forum and Knowledge Base to no avail. The software indeed insisted on reading "slave" as "save."

Any help will be much appreciated.

[Mark1834]

An interesting question.

Context is probably everything here. Were the enslaved people simply property that was bought and sold, or is there any evidence of relationships with the family? Remember that the role of the historian is to record facts as they were at the time, not filtered through the lens of current fashion or sensitivities. Are you recording it just for your information, or will it be shared with other people who may be offended by a straight factual record?

On the assumption that there were not relationships with the "owning" family, I would add the enslaved people as unrelated individuals, and link them with their "owner" under the standard Possessions attribute. Open the attribute note and create a link to each enslaved person in the rich text editor, along with an explanatory narrative. You could mark the attribute as private if you prefer to exclude it from summary reports.

[ColeValleyGirl]

Another approach would be to create a custom fact -- something like Slave Owner, or Owned Slaves, with a witness Role of Slave; create the slaves as Unrelated Individuals and add them at witnesses to the custom Fact.

[jimlad68]

I would record them "somehow" as it could help any of the descendants trace their roots. With respect to helping other genealogists I suspect unrelated individuals is the obvious way to go, but how to link them. The previous suggestions are food for thought, but probably connected by a shared "Source". It might be beyond your remit, but there is also a chance that some are related, in which case you could have "unrelated families". For me, I often follow an unrelated "family", especially if they are "culturally" significant or weave in and out of my related individuals. Do you want to be clinical and DNA, or tell a broader environment story.

[divester]

Thank you for the ideas and food for thought. I appreciate the kindness of your replies. I agree that it is a good idea to record slaves somehow that may come to the notice of others seeking ancestors who were slaves. That sort of research is tough enough, so any way to facilitate it sounds good to me.

Context naturally is important. If there is evidence of a spousal or parent/child relationship, I can simply record them as such. So far though, I have no such evidence, so need to develop a way to record them apart from such familial relationships.

I’m so far leaning toward the approach of recording a slave as an unrelated person and then linking that person to the slave owner in a note in the Possessions attribute of the slave owner. I’m new enough at this that it came as news to me that such links could be made. And I’m new enough also not to know how really visible such links are to other researchers—or even me. They don’t seem to pop up anywhere except when I open the Possessions fact.

And not to lean overly much on my newbie status, but I also don’t know what advantages might be afforded by creating a custom fact and linking a slave as a witness to that fact. Any further thoughts on that?

[ColeValleyGirl]

The Custom Fact route is less likely to shock researchers who are related to the people who were enslaved than recording them as 'Possessions' no matter how historically accurate that is. Nobody is under any doubt about the historical situation, or about the role of a historian, but present-day sensitivities ought not to be ignored.

You can use a Custom Fact and create links in the Fact note (in the same way as Mark described for the Possessions fact.

You should give some thought to how you're going to present your research, and to whom. Witness Facts) are easily accessed from the Facts Tab of Property Box, but not shown in Standard reports except for Narrative ones, and may not export well to other programmes. Fact notes (including links to individuals) are visible on the Facts tab when the relevant fact is selected, but rich text including links is also a challenge when exporting.

[jimlad68]

Custom Facts are great, standard Gedcom and are very portable between products, even Ancestry trees. I have quite a few, not limited to, for things like DNA match recording, various kinds of notes, surety, name information. One that might interest you is my Note_Common_Source where I create a fact for various people all with the same Source(s) that might explain a "situation".
Just note that, I think an FH custom attribute does not export "as is", for that kind of information I would use the "note" of a fact in a structured way.

For many, using witnesses would be the way to go, I do not use them but I am sure you could find much information on that. But as yet not very portable, and not well supported/ compatible elsewhere for reports.

I use ASSOciations (nicely catered for in Ancestral Sources), but not catered for very well, even in FH, despite being standard Gedcom, .

[tatewise]

Just note that, I think an FH custom attribute does not export "as is", for that kind of information I would use the "note" of a fact in a structured way.

As long as you use the 'Export Gedcom File' plugin, FH custom attributes export "as is" to most products, either using the GEDCOM 5.5.1 custom attribute FACT code, or the GEDCOM 5.5 custom event EVEN code with the attribute value.
If neither is supported in the destination product then the attribute value is moved to a local Note of the EVEN code.

[divester]

Thank you again. I'm persuaded that creating a custom fact of Slave Owner, creating an individual for each named slave (usually with just a first name), and linking that individual to the Slave Owner fact as a witness with a role of Slave is the way to go. This approach more directly addresses slaves in the category of persons, rather than possessions--much better.

There is a question of what to do with unnamed slaves. I wonder if creating entirely unnamed individuals in FH makes any sense. I could mention them in the Slave Owner facts (noting their age ranges if reported in censuses), but so far see little advantage in creating entirely unnamed individuals in FH and linking them to the Slave Owner.

As I learn more about FH from your guidance and my own bumbling around, I also realize I have ignored or underused some features, including I now realize witnesses.

[AdrianBruce]

It is possible to create "Name Only" witnesses. These are entered as Witnesses but, if marked as "Name Only", have no individual record, only a "name". Because they have no individual record, pretty much anything can go into a "Name Only" witness' "name". For instance, the "name" could contain the text "three enslaved persons of unknown name".

Doing it like that allows all entries to be done using the witness mechanism but without cluttering the FH file up with unnamed individuals with no known details.

Yes, it is paradoxical to use the "Name Only" witness facility to record people with no known name!

You probably need to adjust my suggestion to fit in with your narrative sentence.

[ColeValleyGirl]

I see no value in creating individuals for the unnamed slaves. Adrian's suggestion about name only witnesses id a good one depending on how much information you have to record; your suggestion of using the fact note would work as well.

It would be worth experimenting with both approaches to see which gives you the out put you prefer.

[tatewise]

When Helen refers to "the out put you prefer", I think she means Reports and possibly exporting to other products.
So before making a final decision, try some of your favourite types of Report and export (via GEDCOM) to another product.
IMO That is good advice for any new feature you intend to use.

[Mark1834]

Interestingly, this relationship is included specifically in the new RM9 “Associations” feature that allows non-family relationships to be recorded (friends, employer/employee, enslaver/enslaved, etc). It will be interesting to see if FH follows suit in due course.

[jimlad68]

Interestingly, this relationship is included specifically in the new RM9 “Associations” feature that allows non-family relationships to be recorded (friends, employer/employee, enslaver/enslaved, etc). It will be interesting to see if FH follows suit in due course.

I hope this is OK with the "VERY NECCESARY and respected" site police, but I think it is a very relevant and interesting feature of extending Family History details capture to other connections/ intermediaries that might play a big part in Family History.

The standard Gedcom has for ages had ASSOciations, but it has been very poorly supported and in many programs not supported at all. Although FH caters for Gedcom ASSOciations, it does not support it very well. As far as I can see one has to add it by the All tab or a Plugin, including AS of course and I don't know of reporting/ analysis methods other than via a query.

To my mind, theoretically, associations can also be garnered and analysed via a shared source, but I don't know of a program that "reports" on that.

I had a quick look at this video https://www.youtube.com/watch?v=URvuXuuH4jw and I doubt it could be catered for with the standard Gedcom ASSOciations, it seems to use a kind of Fact, perhaps also similar to witnesses.

I think some of their reports could be duplicated in FH just using the Gedcom ASSOciations, e.g. A sort of descendant list of associations and their associations etc etc. Also a How related that includes associations.

Again, this is an area where having a "Standard" that the whole industry conforms to would make portability so much better. As ever, I am not holding my breath, especially as the likes of Ancestry trees are so unfriendly to displaying imported data.

[tatewise]

The standard Gedcom has for ages had ASSOciations, but it has been very poorly supported and in many programs not supported at all. Although FH caters for Gedcom ASSOciations, it does not support it very well. As far as I can see one has to add it by the All tab or a Plugin, including AS of course and I don't know of reporting/ analysis methods other than via a query.

I agree that ASSOciated Persons are unsupported or poorly supported (including FH) in most programs.
In FH they can be added via the Main tab or a custom tab after a little customisation of the Property Box.
See FHUG KB > Downloads > Property Box Tabs > Associated Persons.
They can be customised into some Reports and mentioned in Diagram boxes, but it is not ideal.

There already is Wish List Ref 374 ASSOciation features dating from 2008 but with very few Votes!
I suspect the low Vote may be that most users are unaware of the ASSOciated Person feature as it is well hidden in FH.
Some of the requested features have been overtaken by Fact Witnesses and some features discussed here are only mentioned in the Comments.

[NickWalker]

I think part of the problem is that the ASSOciated Persons GEDCOM structure is a very limited in terms of what it can do. You could link an individual to another and describe the link as 'Friend' but you would then need to create another 'Friend' association for the second person in the opposite direction. And there's no dates associated with this so that you record when the two people were friends. The lack of dates is quite a problem I think. They may only have 'owned' the slave between certain dates or been an employer over a few years but there isn't a way to record that in the fact (other than as a note)

[tatewise]

I guess FH could add 'custom' Date (and also Place) fields as has been done elsewhere.
c.f. Media record Date %OBJE._DATE% field and also Notation %OBJE._NOTA% field.