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 Source-entiteiten opgenomen in 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 van Ancestris kunt u de entiteiten dus in de door u gewenste volgorde invoeren. Maar 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 bron en het 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.

Hier zijn de beschikbare mogelijkheden om gegevens in het Gedcom bestand, en dus ook in Ancestris, in te vullen:

1.  De gegevens worden ingevuld binnen een Bron property, deze bron-property is een property van een bepaalde gebeurtenis, en die gebeurtenis hoort bij een bepaalde persoon. De gegevens die op deze manier zijn ingevuld, zijn dan niet te delen. Een andere gebeurtenis kan hiernaar dus niet verwijzen. De 3 puntjes geven aan, dat er voor deze gebeurtenis meerdere van dergelijke properties kunnen zijn. Elk van deze bron-properties bevat dan de volgende informatie:
   • Een link naar een Source entity. Deze link heeft dan de volgende kenmerken:
     • De pagina binnen deze bron (Source) - Tag: PAGE
     • De kwaliteit van de bron, op een schaal van 0 tot 3 - Tag: QUAY
       • 0 = Onbetrouwbaar, of afkomstig van schatting
       • 1 = Subjectief (interviews, mondelinge verklaringen, mogelijke vooringenomenheid, autobiografisch)
       • 2 = Bron uit de tweede hand, officiële gegevens gerapporteerd na een gebeurtenis.
       • 3 = Directe en officiële bron van de gebeurtenis.
     • De transcriptie of de tekst van de bron - Tag DATA met de subtag TEXT
     • Links naar multimedia bestanden - Tag OBJE
     • Het type gebeurtenis dat in de bron wordt genoemd. (Dit kan verschillen van de gebeurtenis van de persoon waaraan het is gekoppeld.) - Tag EVEN
2. De gegevens worden ingevuld binnen een Bron entity (Source). Dit s een gegeven dat wel gedeeld kan worden, en het kan de volgende gegevens bevatten:
   • De Soure (bron) titel, zowel met een lange als met een korte beschrijving. - Respectievelijk met de tags TITL en ABBR.
   • De transcriptie van de tekst van de Source (bron) - Tag: TEXT
   • Links naar de multimedia files - Tag OBJE
   • Links naar de Repositories (archieven) waar de Source (bron) kan worden gevonden. - Tag: REPO.
     • Hierbij is er voor elke Repository, een referentie in die repository met de bijbehorende index. (er kunnen er meerdere zijn) - Tag: CALN
       • En voor elke referentie ook nog het type media ondersteuning van de bron ( audio, boek, kaart, elektronisch, formulier, film, tijdschrift, manuscript, krant, foto, graf, video) - Tag: MEDI
   • De types van de gebeurtenissen zoals aangegeven door de bron, tegelijk met de locatie ervan en de tijdsperiode. - Tag: DATA/EVEN/DATE and DATA/EVEN/PLAC
   • De Verantwoordelijke Agent - Tag: DATA/AGNC
   • De Auteur die de bron gemaakt heeft - Tag: AUTH
   • En de Publicatie Informatie (wanneer en waar) - Tag: PUBL.
3.  De gegevens worden ingevuld binnen de Repository entiteit (archief). Dit is een gegeven wat gedeeld kan worden, en het kan de volgende informatie bevatten:
   • De Naam van de Repository. - Tag: NAME.
   • Het fysieke adres van de Repository - Tag: ADDR.
   • Het Internet adres - Tag: WWW.
   • Een contact nummer (Telefoon, Email, Fax) - Tag: PHON, EMAIL, FAX.

We raden aan om op de volgende efficiënte manier te werk te gaan, namelijk om de informatie op te slaan als gedeelde gegevens als deze voor meerdere gebeurtenissen kan worden gebruikt, of als niet-gedeelde gegevens als deze slechts voor één enkele gebeurtenis kan worden gebruikt, hetzij de gebeurtenis van een individu, hetzij van een familie. Zie de pagina Gedeelde informatie voor meer details.

Voor de bron is het des te relevanter omdat het vaak een lange tekst bevat die dan telkens moet worden getranscribeerd. Meerdere keren invoeren is dan niet aan de orde. Bovendien zou dan deze (zelfde) tekst op twee verschillende plaatsen worden opgeslagen, vandaar dat er een keuze moet worden gemaakt.

Onze eerste vraag is nu dus: Waar vullen we een huwelijksakte in, met de tekst van de transcriptie?

Het efficiëntieprincipe vertelt ons dat het veiliger is om een ​​huwelijksakte in te voeren in een bron entiteit (entity) in plaats van in een bron eigenschap (property).

Een huwelijksakte kan een bron van informatie zijn over verschillende gebeurtenissen. Dat van het huwelijk van de echtgenoten natuurlijk, maar het informeert ons ook vaak over het bestaan ​​van andere individuen, mogelijk zelfs met hun naam, geboortedatum en -plaats. De afwezigheid van een ouder van een van de echtgenoten kan ons ook aanwijzingen geven over hun vermoedelijke overlijdensdatum.

Er zijn dus voordelen aan het invoeren van een huwelijksakte in een gedeelde bron, dus in een Bron entiteit, en wel de volgende:

• De gedeelde bron en de bijbehorende tekst worden slechts éénmaal ingevoerd
• De gedeelde bron kan later worden gelinked aan elke andere genealogiegebeurtenis
• De gedeelde bron is rechtstreeks toegankelijk vanuit de tabel met entiteiten
  

En de volgende vraag is: maar waar voer je dan het archief (repository) in waar het certificaat (de huwelijksakte) zich bevind?

Volgens de Gedcom-standaard wordt het archief (repository) ingevoerd binnen een bron en is de huwelijksakte een pagina van het archief, waarbij dat archief zich op een natuurlijke manier in een broneigenschap registreert. Maar dan werkt ons principe van gedeelde informatie niet meer.

Bovendien moedigt de Gedcom specificatie ons aan om een ​​​​begraafplaats te definiëren als een archief en een graf als een bronentiteit. Als een begraafplaats een bewaarplaats is, waarom zou een register dan geen depository zijn? Dat maakt het er niet eenvoudiger op, want in het echte leven zijn de informatiebronnen ook niet zomaar op 2 gedeelde niveaus gerangschikt.

Mogelijke keuzes:

Hier zijn wat mogelijke oplossingen uit de praktijk voor het bovenstaande voorbeeld. Maar er zijn natuurlijk ook andere oplossingen mogelijk:

Individu			Source (Bron)			Repository
	Source property
Gebeur-tenis	Blz/ Kwaliteit	Tekst/Media	Titel	Tekst/Media	Ref repository / Media support
Huwelijk 1	-/3	-	Huwelijks certificaat	Tekst + Media	Deel 3AB12- Doop, Trouw, Begraaf Register van 1787-nb12 p219/ Manuscript	Nationaal Archief van  Boston
Huwelijk 2	p.219/3	Tekst (Huwelijk van ...) + Media	Doop, Trouw, Begraaf Register van 1787	-	Deel 3AB12/ Manuscript	Nationaal Archief van  Boston

Overwegingen bij de keuzes bij Huwelijk 1 hierboven

• De belangrijkste informatie van de broneigenschap is de kwaliteit
  • Deze informatie kan alleen in de gebeurtenis worden bewaard, omdat het de geloofwaardigheid van de bron aangeeft om de gebeurtenis te bewijzen, niet de geloofwaardigheid van de bron als zodanig.
• De aanduiding van paginanummers of aktenummers zal eerder worden opgenomen in de verwijzing naar het register dan op de pagina aan de gebeurtenis-kant, of in de titel van de bron
  • Als u voor een bron meerdere repositories aangeeft (die dan uiteraard een andere vorm hebben, maar wel met dezelfde inhoud), heeft het akte- of paginanummer geen zin meer voor meerdere repository's waarnaar tegelijkertijd wordt verwezen.

Overwegingen bij de keuzes bij Huwelijk 2 hierboven

• Wanneer het register een bron is, horen de tekst en de media duidelijk aan de gebeurtenis-kant
• Het paginanummer is dan logisch aan de gebeurtenis-kant
• De enige plaats om de titel van de acte in te voeren is in de bron-tekst
  

Hoe moet u nu beslissen? Door te kijken hoeveel gebeurtenissen u gemiddeld aan dezelfde acte kunt koppelen, en hoeveel actes u in hetzelfde register denkt te hebben.

Hoe dichter die verhouding bij 1 ligt, hoe meer dingen er op dezelfde plaats moeten worden opgeslagen, en hoe groter de verhouding, hoe meer ze moeten worden gescheiden.

 

 

 

====================================================================================

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.