Leg uw stamboom bronnen vast

In de loop van de tijd zult u veel officiële documenten verzamelen om toe te voegen aan uw stamboom in Ancestris.

Elk document dat u vind zal u genealogie verrijken met personen, gebeurtenissen, bronnen of aantekeningen.

Deze pagina legt u uit, hoe u een akte invoert met behulp van bronnen en archieven.

Het belang van het vastleggen van bronnen van uw stamboom.

Wat de oorsprong ook is, elke goede genealoog moet zijn bronnen tonen: er is geen goede stamboom zonder bronnen.

Alle informatie die samen alle bronnen vormen voor een stamboom kan het resultaat zijn van:

Persoonlijk onderzoek (burgerlijke stand, notarissen, begraafplaatsen, diverse archieven, enz.)
Delen van gegevens met andere genealogen
Verzamelen van mondelinge informatie
Bestuderen van familiedocumenten

Zelfs als de bron die je hebt niet de beste is, of niet definitief is, dan baseer je toch noodzakelijkerwijs het bestaan van een persoon of een feit op een informatiebron. Dit wordt uw bron in de stamboom, en u houdt bij waar uw informatie vandaan komt, zelfs als dit betekent dat u later een betere bron moet zoeken.

Bronnen en archieven in uw stamboom

Een bron is dus een originele transcriptie op een medium waarmee informatie die in een genealogie is ingevoerd, kan worden verantwoord. Bijvoorbeeld een parochieregister, een tienjarentafel, een akte van de burgerlijke stand, een akte van een parochieregister, een familieboek, een grafsteen, een video, een audiobestand.

Bovendien moet elke bron aan een archief (Repository) worden gekoppeld.

Een repository (Archief) is de plaats van de fysieke of elektronische opslag, de geografische locatie, die het oorspronkelijke medium (bron) bevat (gemeentehuis, departementale archieven, begraafplaats, adres van het gebouw, enz.) of de website (van de provinciale archieven van een bepaalde regio of plaats).

Hoe moeten bronnen en archieven in Ancestris worden georganiseerd.

Onthoud:

Een bron (Source) is opgeborgen in een archief (Repository).

In Ancestris en in de Gedcom-specificatie zijn ~~Bron-~~Source-entiteiten opgenomen in ~~Repository-~~Repository-entiteiten.

Wanneer de bron wordt ingevoerd, wordt tegelijk de repository ingevoerd. De repository moet dus op dat moment al bestaan. Daarom is het logischer om de repository aan te maken vóórdat u de bron aanmaakt.

Deze verwijzing naar de repository is echter optioneel. Daarom kunnen we de bron en de repository dus aanmaken op het moment dat we die nodig hebben tijdens het maken van de bron, of later.

Met de editors invan Ancestris kunt u de entiteiten dus in de door u gewenste volgorde invoeren. InMaar in de praktijk, namelijk in uw onderzoek en bij de volgorde waarin u uw gegevens invoert, is het gebruikelijker, om de repositories vóór de sources (bronnen) in te voeren, vooral omdat dezelfde repository door verschillende bronnen zal worden gebruikt.

Waar bewaart u de source (bron)bron en dehet repository (archief)?archief?

Al is het aanmaken van een persoon redelijk rechttoe rechtaan, en wel via de entiteit "Persoon", voor het aanmaken van zowel de bron als het archief heeft u een keuze.

How to organize the information in Ancestris

A source is contained in a repository

Where to store the deed and the register?

If the creation of the individual is pretty straight forward, that is via the creation of the entity 'Individual', a choice exists for both the Source and the Repository.

Here are the available possibilities where we can write things in the Gedcom standard and therefore in Ancestris.

Inside a source property, inside a given event of a given individual or family: it will therefore become a non-sharable piece of data. It cannot be referenced by another event. There can be several such properties for the same given event. Each property will include the following information.
- Link to a source entity. This link will have the possible following attributes :
  - The page inside the source - Tag: PAGE
  - The source quality, on a scale from 0 to 3 - Tag: QUAY
    - 0 = Unreliable or data resulting from an estimate
    - 1 = Subjective (interviews, oral statement, possible bias, autobiography)
    - 2 = Second-hand source, official data reported after the event
    - 3 = Direct, official and instant source of the event
  - The transcription of the text of the source - Tag: DATA and subtag: TEXT
  - Links to multimedia files - Tag: OBJE
  - The type of event cited in the source (may be different from the event of the individual to which it is attached) - Tag: EVEN
Inside a Source entity : it will be a shareable piece of data. It may contain the following information.
- The source title, as a long and a short description - Tags: TITL and ABBR respectively.
- The transcription of the text of the source - Tag: TEXT
- Links to the multimedia files - Tag: OBJE
- Links to the repositories where the source can be found - Tag: REPO
  - For each repository, references in the repository, and its index (there could be several of them) - Tag:CALN
    - And for each reference, the type of media support of the source (audio, book, card, electronic, record, film, magazine, manuscript, newspaper, photo, grave, video) - Tag: MEDI
- The event types indicated by the source, with their location and time period - Tag: DATA/EVEN/DATE and DATA/EVEN/PLAC
- The Risponsible Agent - Tag: DATA/AGNC
- The Author who created the source - Tag: AUTH
- The Publication information (when and where) - Tag: PUBL
Inside the repository entity : it will be a shareable piece of information. It may contain the following information.
- The repository Name - Tag: NAME
- The physical address of the repository - Tag: ADDR
- The Internet address - Tag: WWW
- A contact number (phone, email, fax) - Tag: PHON, EMAIL, FAX.

For the source, this is all the more relevant as it includes a text that is often long to transcribe. It is out of question to enter it several times. We note that this text could be stored in two different places, hence a choice to be made.

So now, a first question: where do we put a marriage certificate and the text of its transcription?

The principle of efficiency tells us that it is safer to enter a marriage certificate in a source entity rather than in a source property.

A marriage certificate could constitute a source of information about several events. That of the marriage of the spouses of course, but it also often informs us about the existence of other individuals, potentially on their name, date and place of birth. The absence of a parent of one of the spouses can also give us some clues about their likely death date.

It is therefore beneficial to enter a marriage certificate in a shared source, therefore in a Source entity.

The shared source and its text are only entered once
The shared source can be referenced later by any other genealogy event
The shared source can be accessed directly from the table of entities

And the next question is: but then, where do you enter the register which contains the certificate?

According to the Gedcom standard, the registry is rather entered in a source, and the marriage certificate is a page of the registry, which naturally fits into a source property. But then our principle of shared information no longer works.

In addition, the Gedcom standard could suggest to define a cemetery as a repository, and a grave as a source entity. If a cemetery is a repository, why shouldn't a register be a repository? Not easy therefore because in real life, the sources of information are not just arranged on 2 shared levels of information.

Possible choices

Here are possible solutions observed in practice for the example above. There may be others.

Nb	Individual			Source			Repository
		Source property		Source
	Event	Page/ Quality	Text/Media	Title	Text/Media	Ref repository / Media support
1	Marriage	-/3	-	Marriage certificate	Text + Media	Section 3AB12- Baptism Marriage Burial Register of 1787-nb12 p219/ Manuscript	National Archives of Boston
2	Marriage	p.219/3	Text (Marriage of ...) + Media	Baptism Marriage Burial Register of 1787	-	Section 3AB12/ Manuscript	National Archives of Boston

About choice number 1 above

The useful information of the source property is the quality
- This information can only be in the event because it indicates the quality of the source to justify the event, not the quality of the source as such.
The indication of page numbers or act numbers will rather be included in the reference to the register rather than in the page on the event side, or in the title of the source
- Indeed, if you indicate several repositories for a source (which would then obviously be in different form and with the same content), the act or page number no longer makes sense for several repository referenced at the same time.

About choice number 2 above

When the register is a source, the text and the media clearly go to the event side
The page number makes sense for the event
The only place to enter the title of the deed is in the text of the source

How to decide? By looking at how many events you will have on average to attach to the same act, and how many acts you will have in the same register.

The closer the ratio is to 1, the more things will have to be stored in the same place, and the larger the ratio, the more they will have to be separated.

if you think you have a lot of events for the same act, you have to separate the act from the event, otherwise you will spend your time re-entering the same act many times.
if you think you have a lot of acts in the same register, the more it will be necessary to separate the register of acts. It might also be interesting in this case to merge the register with the repository, but it all depends on whether you have a lot of registers for the same repository.

Our recommendation is to favour information shared at the level of acts, therefore choice number 1 above. This is what the Cygnus editor does. The other two editors allow you to make the choices you want.

As you generalize, you may find it useful to make this type of summary table for all the kinds of sources and repositories you come across.

Associating a source with a repository

As we said above, we can create a source and then a repository, or the other way around.

The creation of entities is not documented here. This can be done from the 3 editors, from the contextual menu and from the Aries edit bar.

Example for the creation of a repository with the contextual menu from any entity.

Creation of a repository from the button bar.

The most important part is the association between the two.

Several solutions exist depending on the editor used.

Using the Cygnus editor

With Cygnus, when you are editing a source, click on the Repository button at the bottom right.

This button is only available if a source is actually being edited.

Clicking on this button opens the window for choosing a repository, existing or to be created.

In this window, the detailed content of the repository selected on the right hand side, is showing at the top of the left hand side.

The part in the middle is the list of used sources referenced by this repository.

The data at the bottom displays the references, in the repository, of the source being edited, that is to say the one from which we clicked just before. In this editor you can only put one reference.

Using the Aries editor

With Aries, when editing a source, either directly from a source entity, or from the source of an event, choose the repository tab then click on one of the two highlighted buttons.

In the case of the Attach button, a list of repositories appears, you just have to choose one.

In the case of a repository that does not already exist, the following window appears.

This window contains exclusively the data of a deposit to be entered.

Once the repository data has been entered, you will return to the previous window where you can then indicate the index and the type of Media.

Using the Gedcom editor

From the Gedcom editor, go to the Source entity, then right click anywhere on the top panel of the Gedcom editor, and choose Add a media, a note, a source, etc. then Add a repository.

The following window appears, either to create a new repository, or to choose one from the list.

Assuming you choose to create a new repository, you then see this window, which shows the fields of a repository. You may want to complete the full address.

If you go back to the previous entity, i.e. the source entity, by clicking on the left arrow in the navigation bar, you see that the repository has been added.

The references of the repository are added by right-clicking the REPO line, and choosing "Add a property directly", then CALN.

Then again by clicking on CALN to add MEDI.

You get the following result.

There you go.

You might have noticed the differences of efficiency and transparency of the respective editors.