Jump to content


Photo

Control over Record Numbers (RINs)?


  • Please log in to reply
35 replies to this topic

#1 DeadEnds

DeadEnds

    Member

  • Members
  • PipPip
  • 22 posts

Posted 05 January 2016 - 07:02 PM

I had asked a difficult question here last week, that not surprisingly got many views, but only one response -- "How Do You Manage Multiple Systems and Trees?"

 

So I have taken the bull by the horns and jumped into the problem to see what will happen. I started with three Gedcom files, one from my LifeLines database, one from my Ancestry.com online tree, and one generated from a RM database built from my FamilySearch Family Tree. I then created an empty RM database and successively imported the three Gedcom files on top of one another. That left lots of overlaps in persons, families, sources, etc, that I have been diligently working through.

 

Which has led to an interesting (to me anyway) question. Every merge removes a RIN from the database. I have been trying to do my merging in a way that, as far as possible, 1) the lower numbered RINs are preferred, and 2) the actual RINS from the most complete starting database are preferred (since persons were added to that database in an orderly fashion that make the numbers nice). But for various reasons I have not been able to always end up with the preferred RINs during the large number of mergings I have been doing.

 

I know this will sound like a fairly crazy question, but I'm still wondering. Does a user have any ability to change the RIN numbers of records. In some cases I know that a RIN must be available, since I just merged away the record that had the RIN I want to reuse. But I haven't found any documentation on how I might take advantage of these "holes" in the RIN space. If you think I'm an idiot for wanting to do this, I might even agree with you. But I still want to know.

 

Tom Wetmore



#2 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 05 January 2016 - 07:48 PM

The only control when doing Duplicate or Manual merge is to swap the two people before merge.

Some users change the name of the person to something like Reuse and remove the facts, etc. from the record so they can reuse the record number instead of deleting the person or merging.

#3 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3442 posts

Posted 05 January 2016 - 07:50 PM

The program was designed for the Record Number to only mean something ...for records in use (where the data is stored in an SQLite database).

So, when a Record Number is no longer in use (storing data), it is not reused ...so you cannot reuse them either.

 

You could painstakingly drag individuals and groups to a new database ...in the order you wish them to appear.

But that's not a system to be adhered to anyway, because you will not be adding individuals in a controlled order beyond the initial dragging anyway.

 

You likely should be considering the Reference Number fact or a custom-designed fact if you have a purpose other than reference/ordering.


---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#4 DeadEnds

DeadEnds

    Member

  • Members
  • PipPip
  • 22 posts

Posted 05 January 2016 - 09:06 PM

Thanks for the answers. What I anticipated. My only reason for wanting to control RINs is my own sense of "neatness." No biggie. I can export and re-import later to let RM renumber persons systematically when the merging is done.



#5 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 05 January 2016 - 09:11 PM

This may seem ironic but you have a control over record numbers when importing a RootsMagic GEDCOM to a new, empty database: choose between letting RM assign new numbers starting at 1 or preserve those from the originating database.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#6 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 206 posts

Posted 13 January 2016 - 12:24 AM

The term RIN as it relates to GEDCOM is an actual tag, but many people and systems use the XREF of the individual as a substitute, which is technically wrong.

According to the GEDCOM standard the XREF value is transient and arbitrary. It does not have to be a number nor will it be maintained in the receiving system.

I bring this up because a true RIN tag or REFN tag in a GEDCOM are intended to remain unchanged across systems.

From a database design standpoint a record number, the cross reference pointer (XREF) from one record instance to another should be hidden from users.

I personally control person identifiers in GEDCOM by using a user assigned ID placed in the REFN tag. This ID is also the key/index to paper folders I maintain in my library for individuals.

#7 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3404 posts

Posted 13 January 2016 - 07:39 AM

This whole debate and question about record numbers has been going on the the RootsMagic world since the Family Origins days. I'm not sure in our discussions that we should be identifying the actual GEDCOM term "RIN" with the term "record number" from RootsMagic, but we do. And we do in part because there are places in RM that make the same identification.

 

Here's the GEDCOM definition of RIN:

 

AUTOMATED_RECORD_ID:=A unique record identification number assigned to the record by the source system. This number is

intended to serve as a more sure means of identification of a record for reconciling differences in data between two interfacing systems.
 
But when I export a GEDCOM from RM, I don't find a RIN tag. Rather, the record number we are talking about is exported as a part of the INDI tag. E.g. if the record number for an individual in RM is 27 then the INDI tag for exported GEDCOM is "0 INDI @I27@" without the quotes. It seems to me that the RM data element that most closely matches up with the GEDCOM definition of RIN is RM's unique identifier. But the unique identifier is not very visible in RM's user interface (actually, not visible at all unless I'm missing somthing) and it exports as something like "1 _UID DC2CCE8033C74F25BDA7FA37FF03BDF9114C" without the quotes.
 
Actually, I don't think that RM's record number serves quite the function that the RIN number is intended to fulfill by the GEDCOM standard. The internal function of RM's record number is really to serve as the primary key for the PersonTable. But this primary key is exposed to the user interface, it's called RIN in at least a few places in the user interface, it serves as the number in the INDI record for exported GEDCOM, and people really want to preserve it at all costs. I know they do, because they say so on these forums and because I try very hard to preserve it myself. I don't have any reason to do so. I just want to.
 
I wonder if RM might be better served by not using the primary key for the PersonTable also as an ID number that is exposed to the user interface. All of the other tables have primary keys, and the only other one that's even slightly exposed to the user interface is the family number in the FamilyTable. For example, there is a SourceTable for Master Sources. It has a master key that's just the numbers 1, 2, 3, etc. If a Master Source is deleted or if two Master Sources are merged, a primary key is lost, never to be used again. But it doesn't matter because each Master Source has a name that is exposed to the user interface, and that's the ID for sources we care about.
 
I wonder if maybe we would be better served if the primary key for the PersonTable was not exposed to the user interface and if there were another person identifier for every person that was exposed to the user interface and that would be readily preserved. Many users use the Reference Number fact for this purpose, but it's not automatically generated and it otherwise does not quite function in all the same useful ways as does the existing record number from the PersonTable.
 
Jerry
 


#8 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 13 January 2016 - 11:15 AM

I am trying to understand how hiding the present visible record number and creating another number visible to the user is going to help RM users that use the present visable record number in their filing systems.

I am curious, what happens to RM's record numbers when imported into a new FTM database?

And, what gedcom tag does FTM use for the record number when it exports a gedcom?

And, does FTM export a hidden UID type number?

#9 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3442 posts

Posted 13 January 2016 - 12:04 PM

It seems to me, generally speaking, that any one individual is typically going to have a different number associated with referencing that person, in each of the different genealogy programs and their storage mechanisms (the exception being RootsMagic unto itself and ONLY where the destination database is either empty OR none of the record numbers to be preserved are already in use) irrespective of the scheme RootsMagic uses.


---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#10 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 13 January 2016 - 12:46 PM

I agree, and, as far as I can see, we can't depend on record numbers being kept from one program to another regardless of which programs they are.

That is why posters get the advice to not depend on record numbers for any program's record numbers for a filing numbering system.

#11 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 206 posts

Posted 14 January 2016 - 07:14 AM

It is a little hard for me to describe without a lot of words the various fields in a GEDCOM vs how they are used in programs vs how they should be used in those same programs. As a database designer, librarian and long time GEDCOM user I will still try.

In GEDCOM we have the following three tags.

XREF, REFN, RIN

XREF is a value that is the unique database key for a record instance used to link one record type to another. For example the individual to the family where they participate as a child. An XREF is NOT preserved across systems

RIN as described above is a unique ID assigned by the system to help identify record across system.

REFN is a user-defined number or text that the submitter uses to identify this record. For instance, it may be a record number within the submitter's automated or manual system

Because an XREF can change across systems it is not very valuable as a identifier to the outside world. XREF is also defined as a pointer and as such in database terms is also known as a DB_Key. A DB_Key in most database systems can be reused either when the database is reloaded or the record associated with that key is deleted. This also makes and XREF a poor value to expose to the world. While I understand in RM XREF values are not reused they theoretically could be lost during a reload or when merging in another GEDCOM.

Because we don't have a repository for unique individual IDs in the outside world the RIN tag cannot be a truly unique ID for an individual it is therefore not very valuable as an ID across systems.

This is why I prefer the REFN tag as a identifier within my system. It will be preserved to the outside world and is generally unique enough that it won't have a duplicate value in anyone else's system.

I believe that no system should expose the XREF tag as the RIN on screens or reports.

#12 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3404 posts

Posted 14 January 2016 - 07:26 AM

I believe that no system should expose the XREF tag as the RIN on screens or reports.

 

You were speaking entirely of GEDCOM tags. But do I understand you correctly that you are saying that RM's record number is really an XREF tag in GEDCOM?

 

Jerry



#13 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 206 posts

Posted 14 January 2016 - 07:26 AM

Also and by the way and XREF ID or database key does not necessarily have to be a number. It is define as: "The xref_ID is formed by any arbitrary combination of characters from the pointer_char set. The first character must be an alpha or a digit. The xref_ID is not retained in the receiving system, and it may therefore be formed from any convenient combination of identifiers from the sending system. No meaning is attributed by the receiver to any part of the xref_ID, other than its unique association with the associated record."

#14 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 206 posts

Posted 14 January 2016 - 07:28 AM

It is my belief ( though I don't have specific evidence) that the RM use of the term RIN is nothing more then the XREF value replicated to the screen .

#15 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 206 posts

Posted 14 January 2016 - 07:34 AM

This being said the original poster wanted to control his RIN IDs and therefore I suggest either using a true RIN or an REFN ID that he makes up in a unique way. An enhancement suggestion to roots magic would be to create a function that allows for the user to generate unique REFN ID values based on some algorithm that the user define's. I use an accession number similar to a format used in a library setting .

#16 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6145 posts

Posted 14 January 2016 - 08:47 AM

KFN, you would do well to obtain the free version of RootsMagic, the free SQLiteSpy SQLite database manager with which you can inspect a RootsMagic database imported from your GEDCOM and compare the latter to what RM then exports. I think you would find that what RootsMagic and its ilk call "RIN" can be the value of the 0 INDI tag if preserved on import or export and has nothing to do with XREF. Internally, the RootsMagic RIN or RN is the value of the key field PersonID in the PersonTable.

 

There can be many REFN values associated with a person so it is not necessarily a very effective way of indexing a person.

 

RM also creates a UID for each person in the database which has far, far lower probability of being generated for any other database than your winning the PowerBall lottery. It is exported with the custom _UID tag and is preserved by RM on import. However, it is necessarily a very long string not meaningful to the eye and is not exposed in the User Interface.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#17 DeadEnds

DeadEnds

    Member

  • Members
  • PipPip
  • 22 posts

Posted 14 January 2016 - 10:05 AM

I'm the OP and a recent FTM->RM convert. I built my RM database from three Gedcom files that had quite a bit of overlapping information that required much merging to clean up; I'm still not done. As I merged pairs of persons I tried to "keep" the RINs that had the lower values, since then the family members all would have similar RINs. Occasionally I messed up and merged the lower numbered person into the larger. I "know" the lower RIN is now "available" so I was kind of hoping there would be a way to change the higher RIN number for the lower number after the fact. Since there is no way to undo the merge and redo it in the other order I ended up doing a lot of head slapping and uttering of "doh's". I didn't expect there to be a way to do the RIN switch, and I think that is now confirmed. The RIN is RM's main database row id, and users have no business changing them. But I was hoping maybe I could have a sneaky way to grab one of the the post-merged, now ready for reuse, RINs. So it's just another "doh" am I stupid thing.

 

The REFN tag in Gedcom belongs to the user, period. It converts into RM as a fact, as it should. In Gedcom a person can have any number of REFNs. The purpose of REFN is simply to give the user a way to assign to any person a special string handle, or multiple string handles, for whatever purpose they want. In the LifeLines program persons can be searched for by name, by ID (Gedcom ID) or by REFN.



#18 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3442 posts

Posted 14 January 2016 - 10:38 AM

The REFN tag in Gedcom belongs to the user, period. It converts into RM as a fact, as it should. In Gedcom a person can have any number of REFNs. The purpose of REFN is simply to give the user a way to assign to any person a special string handle, or multiple string handles, for whatever purpose they want. In the LifeLines program persons can be searched for by name, by ID (Gedcom ID) or by REFN.

 

Yes, good characterization and it's offered by RootsMagic as an option to be shown beside each individual in lieu of a Record Number (RIN) or FamilySearchID because it is so universal. I'm not sure where Tom arrives at the conclusion that "it is not necessarily a very effective way of indexing a person" (perhaps he is thinking in database terms or automatic systems) but that is far from a good characterization of its viability IMO, as the user can actually incorporate multiple "systems" via REFN facts and their virtually-ensured portability is only limited by how other software packages implement access to it (them).


---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#19 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1473 posts

Posted 14 January 2016 - 11:37 AM

I've got a curious question:

-

Since a person's record can include multiple REFN facts, how does RM select which to show when REFN is selected for display?

-

I'd expect that setting one as the [x] Primary would control the display behavior, but what if the user has not selected a Primary? What would RM do then?



#20 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3442 posts

Posted 14 January 2016 - 12:46 PM

I'd expect that setting one as the [x] Primary would control the display behavior, but what if the user has not selected a Primary? What would RM do then?

 

My quick test seemed to show that the <order when first added> controls which is displayed if none are selected as primary


---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N