In my gedcom I prefer to use the original characters for persons (I), families (F), notes (N), etc.
I noticed that the used ID behind that character only uses one chain. E.g.
I1000 married to a person (stored in an F record, it will be F1001). The spouse is I1002, etc.
I prefer several chains, a chain for all Individuals, a chain for all families, etc.
How do I achieve this?
“Reference Numbers” are defined by the REFN tag and in webtrees are manually entered. What you are probably referring to are xref_ID (a pointer, aka XREF). The GEDCOM Standard v 5.5.1 says the following about them:
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.
An add on module can be used to do what you want, but I don’t recommend depending on the XREF for external identification.
The collection of genealogical data in a webtrees site is not part of a datastream. I argue that it should be considered to be a staging of data, that *might* be streamed to another application. When it gets streamed the XREF's are not guaranteed to be retained.
Within the site/tree, the XREF is well defined for internal references, in the same way as the XREF is well defined in a properly formed gedcom file.
As for 'not exposing this XREF to the user': Is that a reference to the datastream, or in general? Should we encode the XREF's in the gedcom file as blue text on a blue background - hiding it from users, but still machine readable? (My apologies, very tongue in cheek). Should url's be formatted differently just to comply with this? I don't think so. That XREF in the url is well defined.
External references are another matter, and will depend on choices made by the curator/s of the data. I.e. how unique do they want the reference (REFN) to be, and that will make them choose a particular convention.
If the only evidence of not using a database pointer was the information quoted above your argument “may” have a very weak leg to stand on, however there is more to not using a database pointer or DBKey externally by users or displaying them outside of the application.
A very simple answer to the “stream” point you talked about. Because a database pointer - in this case also known as an XREF - can also be, and often is, reorganized by the application they should never be used outside of the application to reference a specific datapoint. Databases during an “unload/reload procedure” very often reorganize their internal pointer (DBKey) values and many times change their algorithm to accommodate their need. At some time in the future the XREF could be changed within webtrees because of a new feature. So yes, the XREF should be hidden from the user and only application readable. URLs are by nature for the “machine” to read for navigational purposes within the application. Removing that URL to another application or storage is alway fraught with danger when a page or site moves, which would be true for any application not just webtrees.
As a database designer and engineer I could go on about database pointers and DBKeys but your argument holds no water with this regard either.
External references for library and archival purposes can follow two paths.
1) For external use by the specific archival institute where the reference only has meaning to the institute itself.
2) A universally designed and developed algorithm that is produced by a clearing house and referenced by all institutes needing this reference number to define a specific item and will *always* retrieve the same item regardless of the institute you are using.
Because in Genealogy their is no clearing house for ID designation, an internally developed and maintained system is the only answer. I personally use a pseudo accession numbering system as a REFN value that generates a value automatically for ever new individual added to the webtrees database. These reference numbers are then used in the paper based filing system of my data archive. REFN number will survive both GEDCOM transfer to other applications and any internal database reorganization within webtrees.