REFN under MARR

[jorgenjo]

REFN should be under in gedcom 7.1.13

0 @F99@ FAM
1 REFN 99
1 MARR

This is the only allowed way.

and not under MARR like in export from LEGACY9.ged 5.5.1

0 @F99@ FAM
1 MARR
2 REFN 99

Gives Gedcom Validator Warning in 5.5.1
Gives Gedcom Validator Error in 7.1.13

But then a MARR and a CENS under FAM cant have their own REFN Reference number. only the Family can have a reference number.

should perhaps be allwed under each Family Event, and not under the main FAM event only.

This is working in 7.1.13

0 @F99@ FAM
1 REFN 99
1 HUSB @i173@
1 WIFE @i174@
1 CHIL @i172@
1 CHIL @i583@
1 CHIL @i586@
1 CHIL @I584@
1 CHIL @i587@
1 MARR
2 TYPE RELIGIOUS
2 DATE 15 Sep 1911
2 PLAC Strellev Kirke, Strellev, Varde, Danmark
3 FORM Church, Parish, Commune, Country
1 CENS
2 DATE 1916
2 PLAC Mosbøl, Strellev, Varde, Danmark
1 CENS
2 DATE 1921
2 PLAC Mosbøl, Strellev, Varde, Danmark
1 CENS
2 DATE 1925
2 PLAC Mosbøl, Strellev, Varde, Danmark
1 CENS
2 DATE 1930
2 PLAC Mosbøl, Strellev, Varde, Danmark

But what if i wanted a two different REFN under MARR and under CENS

Best regards
Jørgen Johannessen.

BTW: You are doing a fantasitc job with the updated gedcom standard :)

[Norwegian-Sardines]

Why do you need a REFN under a family “fact”? The concept of a reference number is to provide an outside identity number to a record instance for a family or individual? In my database I use reference numbers in a similar way as a library catalogs a book or other document! But it could also represent a position in a chart or family tree! Why would you need to create a reference number for a fact?

[jorgenjo]

Yes i see the point why do need a REFN under fact..

REFN under FAM only gives one REFN, but under family there can be multiple facts of the same type like CENS

0 @F99@ FAM
1 HUSB @i173@
1 WIFE @i174@

is a uniqe key to a family... and could replace the REFN for a family.

CENS
2 DATE 1916
2 PLAC Mosbøl, Strellev, Varde, Danmark

is a unique key to a census..

CENS
2 DATE 1921
2 PLAC Mosbøl, Strellev, Varde, Danmark

is a another unique key to a census under the same family

The problem comes when i am

exporting data from my system to a gedcom file,
import gedcom file into LEGACY
... working with the data in LEGACY or other systems
.. syncronizing data with Familysearch via Legacy.. som data like place.. can be changed.
exporting gedcom file from LEGACY
importing data into my system again..

if LEGACY changes the key values ... person identifier... place names.. then its impossible to import data back into my system from the exported Legacy gedcom file..
if it keeps the REFN, then i will be able to import data again.

Note: Legacy is just one of several systems that can import export gedcom data, but is the one im using now, together with my own designed system. Why do i have my own system... because not all data can be stored the the systems available on the market today. I also have som private data and comments that i dont want to be exported to the gedcom files.

Hope this will explain.

[Norwegian-Sardines]

I'm not sure I understand this statement:

REFN under FAM only gives one REFN, but under family there can be multiple facts of the same type like CENS

0 @F99@ FAM
1 HUSB @i173@
1 WIFE @i174@

is a uniqe key to a family... and could replace the REFN for a family.

The value @F99@ is a unique pointer to an instance of the Family_Record, these "pointers" are know as an XREF and by definition are:

Cross-reference identifiers are not retained between data streams and should not be made visible to the user to avoid them referring to transient data within notes or other durable data.

Therefore you - as you have seen - should not depend on them to be retained when using a GEDCOM to transfer data between systems. They should also not be used externally to identify an instance of any record in the database.

Personally I would never put an XREF in the REFN as a way to maintain a link from a database record instance (i.e. an Individual or Family) to your external document management system. I would however use the REFN along with a self created unique numbering system to link an individual, family unit, source document, or media document/image to a separate filing system external to your genealogy software.

You said:

CENS
2 DATE 1916
2 PLAC Mosbøl, Strellev, Varde, Danmark

is a unique key to a census..

CENS
2 DATE 1921
2 PLAC Mosbøl, Strellev, Varde, Danmark

is a another unique key to a census under the same family

I believe you are not using the GEDCOM as it was designed! Let me show you how I do this in my system with an example v5.5.1 GEDCOM listing.

0 @F516@ FAM
1 WIFE @I1480@
1 HUSB @I1420@
1 REFN F-1985-0001
1 MARR Y
2 SOUR @S78@
3 PAGE p. 53
1 CENS
2 DATE 1801
2 PLAC Jølster, Norway
2 SOUR @S78@
3 PAGE p. 53

The Census should be entered as a "Source_Record" so all uses of the information found in the census can be referenced by an XREF pointer.

0 @S78@ SOUR
1 TITL Census: 1801 Jølster, Norway
1 REFN S-1985-0004
1 REPO @R1@
... 

0 @R1@ REPO
1 NAME The Norwegian Digital Archive, Digitalarkivet
1 WWW http://digitalarkivet.uib.no/
1 REFN R-1984-0001

Please note that for the CENS and MARR tags in the Family_Record both point to the @S78@ Source_Record (via SOUR @S78@), and I would have something similar in the Individual_Record for the Husband and Wife (@I1480@, @I1420@) that make up this family unit for information taken from the census! This I believe is the way we should be referencing a Census and any documentation that is outside of the GEDCOM database.

FAM.CENS points to the SOUR via the XREF and the SOUR points to your external catalog document via the SOUR.REFN.

You said:

if LEGACY changes the key values ... person identifier... place names.. then its impossible to import data back into my system from the exported Legacy gedcom file..
if it keeps the REFN, then i will be able to import data again.

I call the function of exporting GEDCOM to other software, then re-importing to back to the origin as "Round-Tripping"

This type of work does cause issues, but as I indicated before we should expect the XREF (key values, person identifier) to change with each import. What should not change is actual data and REFN is data. If Place Names are being changed then I feel that this is a bug, because data should never be changed in the "round-tripping" process.

I would love to continue this discussion, because I'm sure that this does not make a lot of sense and others may have differing viewpoints. But I would not agree that a CENS tag should have a subtag of REFN because REFN numbers are like Catalog Numbers on the spine of a book. The Census is a Source and therefore should be added as a Source_Record, the CENS tag should reference that Source_Record via the CENS.SOUR XREF relationship.

[Norwegian-Sardines]

Following thru on my sourcing example. Let’s say that the census also provided a birth year (1755) for the father in the family. My GEDCOM Individual_Record would look something like this:

0 @I1420@ INDI
1 NAME John /Doe/
1 REFN I-1985-0016
1 BIRT
2 DATE 1755
2 SOUR @S78@
3 PAGE p. 53

Again I’ve pointed to the Census Source_Record for detail information about what provided the information.

I could also add a Census participation entry for this person as well.

1 CENS
2 DATE 1801
2 PLAC Jølster, Norway
2 SOUR @S78@
3 PAGE p. 53

[jorgenjo]

Thanks for your long and detailed answer, and that you will take this discussion here.. yes maybe i have misunderstood what the purpose is with the gedcom file.

• I am not using the XREF value because they can change, if the gedcom file is optimized...
  as you wrote ... Cross-reference identifiers are not retained
  and thats why i need the REFN.

• The F100427 and REFN 100427 is not because i wanted to use the same number as the xref, but it came from the old days when i was starting i family tree. And yes it could also just be another number not matching the xref.

• As i understand it, if i want a REFN to each Family CENS or MARR, then i need to add a SOUR and then ad a REFN in the Source Record, like this example, it will work in GEDCOM 7.

0 @F100427@ FAM
1 REFN 100427
1 HUSB @I102279@
1 WIFE @I102280@
1 CHIL @I3297@
1 CHIL @I102281@
1 MARR
2 DATE 27 Feb 1795
2 SOUR @s1000@
1 CENS
2 DATE 1801
2 SOUR @s1001@
0 @s1000@ SOUR
1 REFN SOURCE1000
0 @s1001@ SOUR
1 REFN SOURCE1001

Then i get a REFN 100427 to the Family, Marriage REFN SOURCE1000 and the Family Census in 1801 with REFN SOURCE1001.

This will give a very lot of sources if i import it in other systems. Maybe its a bad idea or maybe not.

And then we are back GEDCOM is not designed to store REFN. fields the way i want, and its not designed to store Census data but only link to pages in a book.

[Norwegian-Sardines]

This will give a very lot of sources if i import it in other systems. Maybe its a bad idea or maybe not.

1. I would expect that you already have the census as a Source_Record when you use the information such as: Age, Name, Address, and other things that are already on the census line!

2. I do this myself, with census records for everyone in my database, from several countries, Norway, USA, Germany, UK and maybe a few more. So having a bunch of Source_Records is not a big deal! Every Census by Year and Location has its own Source_Record.

I don't understand your concern about your statement:

its not designed to store Census data but only link to pages in a book.

My example clearly shows a page number from a real Census in Norway! Furthermore the PAGE tag can contain more information than just the actual page number. The GEDCOM v7 specification say the following about the PAGE tag:

A specific location within the information referenced. For a published work, this could include the volume of a multi-volume work and the page number or numbers. For a periodical, it could include volume, issue, and page numbers. For a newspaper, it could include a date, page number, and column number. For an unpublished source or micro‐filmed works, this could be a film or sheet number, page number, or frame number. A census record might have an enumerating district, page number, line number, dwelling number, and family number.

I set the specific information to bold for you to see!

So I would say again, the Source_Record gives us information about the source of the information in this case the Census, and the Source_Citation SOUR.PAGE provides the exact location within the source of the information being cited! Using the REFN in you way does not make sense!

[jorgenjo]

Thanks for your hints, i will try to use the Gedcom 7, the way it is ment to be used.

I will look at the PAGE tag... , the below examples have not been tested but i think it will be something close to that.

Example from the danish public archives, a Census, from

direct link to the census archives.
https://ao.sa.dk/ao/data.ashx?bid=2899258

or the same page,,
https://www.sa.dk/ao-soegesider/da/billedviser?bsid=26255#26255,2899258

Here in Danmark,,, we typical have 5-6 families on a Census page, so it would be somthing like

Page No, Løbenr(house no) , Individual no in the household on each page.

Link to the person Anders Hansen Fris could be ....

Under the Induvidual INDI
1 CENS
2 DATE 1 Feb 1801
2 PLAC Janderup, Janderup, Varde, Danmark
3 FORM Place, Parish, Commune, Country
2 AGE 53
2 NOTE Gårdmand
2 SOUR @CENSUS_DK_2899258@
3 PAGE p. 2899258 h. 4 i. 1
3 WWW https://ao.sa.dk/ao/data.ashx?bid=2899258

Under the Family FAM

1 CENS
2 DATE 1 Feb 1801
2 PLAC Janderup, Janderup, Varde, Danmark
3 FORM Place, Parish, Commune, Country
2 SOUR @CENSUS_DK_2899258@
3 PAGE p. 2899258 h. 4
3 WWW https://ao.sa.dk/ao/data.ashx?bid=2899258

The Source

0 @CENSUS_DK_2899258@ SOUR
1 TITL Census: 1801 Janderup, Varde, Danmark
1 REPO @r1@
1 DATA
2 EVEN CENS
3 DATE FROM 1 Feb 1801 TO 1 Feb 1801
3 PLAC Janderup, Janderup, Varde, Danmark
4 FORM Place, Parish, Commune, Country

The repo

0 @r1@ REPO
1 NAME The Danish National Archives, Rigsarkivet
1 WWW http://https://www.rigsarkivet.dk/arkivalieronline/

[Norwegian-Sardines]

I think you are moving in the right direction! Now I also understand why you are losing your well crafted Source_Record XREF IDs! These XREF @CENSUS_DK_2899258@ are perfect from my viewpoint but will probably get flagged or changed when you import the GEDCOM into another program! This is ok as I’ve noted before, and based on your well-crafted XREF , I would use that value as the REFN number in your Source_Record.

0 @CENSUS_DK_2899258@ SOUR
1 TITL Census: 1801 Janderup, Varde, Danmark
1 REFN CENSUS_DK_2899258
1 REPO @r1@
1 DATA
2 EVEN CENS
3 DATE FROM 1 Feb 1801 TO 1 Feb 1801
3 PLAC Janderup, Janderup, Varde, Danmark
4 FORM Place, Parish, Commune, Country

As an interesting side note:
If you have control over the GEDCOM generator in your program, before you import into LEGACY add the REFN based on the XREF, you can also regenerate the XREF when you reimport the GEDCOM from LEGACY back to your program!

[jorgenjo]

Tested some of it now..

REFN CENSUS_DK_2899258 was still intact after a import and export through Legacy 9,
thats an ok solution for me :) So now i have my link to my external Census pages.

The
0 @CENSUS_DK_2899258@ SOUR was changed to
0 @s161@ SOUR, so all source variables is changed after Import and Export, but that was expected.

Thanks for your help :)