Question How to find the reference of an individual

We can reference an individual via @...@

Example, on my family tree, when I write in a note: "Reference to @X260@"
webtrees will translate the information with the real name of the individual :
Result
Reference to Marie Anne Klugesherz

One solution to find the reference of the individual, is to look in the URL.



My question, is there a webtrees smarter way to get the reference ?

If you have access to the raw GEDCOM for the individual, you will see the XREF value there!

The URL is the place to get it from. But with pretty URLs it has become more difficult to extract the XREF from the URL.

I would like to propose adding the XREF (like other identifiers such as the IDNO and SSN tags) to the block "extra information" found on the far right (just above the Family block)

Bert,

As you probably know from past discussions that the XREF is an internal reference value and should not be used as a reference by users of webtrees.

I would recommend users ether generate a Unique ID by turning on the UniqueID option for the tree or create Unique Identifiers using the REF tag.

XREF tags can be renumbered within webtrees and in other programs so they are not always the same for round trippers either.

Unless I'm writing a program on the backend the XREF number is meaningless to the regular user of webtrees.

bertkoor wrote: I would like to propose adding the XREF to the block "extra information" found on the far right (just above the Family block)

This would be nice, and I would agree

norwegian_sardines wrote: XREF is an internal reference value and should not be used as a reference by users of webtrees.

This is pity, because Greg propose to use this trick

This needs more clarification ..

Yes, Greg’s proposal is the only way, for those who must have an XREF, to obtain it without going directly to the raw GEDCOM.

My point is that using the XREF does have some issues for people, because it was not meant to be used as an identifier outside of the internal program, as defined by the GEDCOM Standard.

So the reality is that a PHP programmer could/should write some other program or code that is part of the NOTE markdown processing that would convert a name to an internal link or allow you to select a individual that would generate the XREF link. But this would be outside of the GEDCOM Standard use of a NOTE.

Sorry there is something that I didn't understand
My quest in the topic , was to point to an individual, without to use an absolute path to this person. (URL)
The solution proposed was to use XREF, which I considered as a smart approach !

Now, you are highlighting that this approach is not recommended because XREF tags can be renumbered within webtrees .. !!!

If this is the case, then XREF can have big impacts relative to our expectations, and should never have been proposed..

In other words.
There is no solution to my question

Here I'm lost.

If you don't round-trip and don't press the "Renumber Button" in the admin screen you are probably okay.

Again I point this out because not everyone uses only webtrees but import GEDCOM files from other programs or want to renumber their file after adding other GEDCOM files to their database. It is possible that at some point in the future some other reason could cause XREF numbers to change.

You could also delete a person that could break the chain, a user could change the note and the chain would we altered. Or something else could do something to the file. The link is hand coded and therefore not under the control of the application, which are what XREF numbers are suppose to be, controlled by the application not the user.

Some of this would be true for anyone that in-beds an absolute path link to the outside for pictures or other documents. And is a warning, nothing more!

@Klugesherz:

An XREF is similar to an auto incremented record id in a database table which is controlled by the database system. Delete a table entry and the record-id will be deleted and never be used again.

Creating a new individual will create its XREF. Deleting the individual will delete the XREF. When merging two individuals one of the XREFs must be deleted and all references to the lost XREF must be replaced by the remaining one. webtrees does this for you in the GEDCOM data in case you merge two individuals, but it cannot do this for all the links that might have been created to refer to that lost XREF. That would be a manual task.

So an XREF is not a 100% reliable reference. Its reliability depends on your way of working. Nevertheless I support the proposal to add it to the "extra information" block.

On the other hand, the XREF is the only unique (within the current tree) identifier of a person that is guaranteed to exist. That is why it is put first in the URL, followed by a name which gets ignored.

This is not only about adding a reference to other people in notes. When adding an associate or rejoining family members, you can look up a person using preferably a name, but the XREF works as well. If the name is not unique within the tree, then using the XREF takes less clicks and less error prone.

I sometimes get tired of when adding an existing child to a family, I have to chose between father John Smith (who cannot be his own child, but never mind that for now), the grandfather, the son and all his nephews that all share that common name. Or I found a person recorded twice and can't be bothered to go to the control panel to merge them. Well even then: you have to identify them!

Easy access to the XREF is needed for some tasks. Period.

Sir Peter wrote: webtrees does this for you in the GEDCOM data in case you merge two individuals, but it cannot do this for all the links that might have been created to refer to that lost XREF.

As long as a specific format is used in those links, I don't see why it shouldn't be possible to update them as well in these cases.

Bert said:

Easy access to the XREF is needed for some tasks. Period.

As an application and database designer if this is true then the application needs to make this task easier and less error prone. We have multiple people here who write great and interesting modules and add-on code. They should be the ones that create a better way for internally using a XREF in the places that they are needed.

So I reject exposing the XREF just to make these tasks easier, but rather I propose the users who find that the tasks they perform so often that need an XREF to: 1) identify those tasks, 2) develop a way along with a module programmer to update code to make finding those individuals easier.

Perfect.
You convinced me to continue to use XREF, with some restrictions to take into account
Even if not a 100% reliable reference.

However I agree with some of you. To the proposal to add XREF information it to the "extra information" block.

Klugehertz said:

To the proposal to add XREF information it to the "extra information" block

.

If this is needed then I would propose that it not be added to the base code but as an add-on module. As I noted above.

To

Klugehertz said:
To the proposal to add XREF information it to the "extra information" block

norwegian_sardines said
If this is needed then I would propose that it not be added to the base code but as an add-on module. As I noted above.

I don't want to hurt anyone, but Sorry, I'm not in line with that conclusion

If I take into account, according to the remarks which have been exchanged, the limitations and the cases of errors which could appear.
I see no reason why not to display the XREF information under the extra Information area.

I agree with you, that certainly an additional module is needed in the case of an import of a GEDCOM database, and a renumbering.
Which could create some mismatches.
What I understood, the objective of this external module should take into account the correspondence of XREFs before and after renumbering

Let us take a simple example

Before renumbering
After renumbering in order to respect the XREF
Conclusion
But in any case, I don't see why not display the XREF it to the "extra information" block
XREF which anyway appears in the URL level

Here for my 2 cents

The reason it should NOT be displayed is that it is for internal purposes only, the XREF is not for use by anyone other than the application. This is well defined in the GEDCOM Standard. I don’t want webtrees to encourage misuse of the XREF pointer!

In database terminology the XREF is called a “database key” or DBKey, and are subject to the control of the database engine not the user interface. It is therefore bad design to use, expose or allow users to enter database keys in the application.

When I was a member of the team that developed the IDMS database engine and later designed database schemas and application software, I had to explain this concept multiple times to people that the user interface must have a way to provide to the user a way to “connect” record instances (stored internally with DBKeys) a way to pick a unique record instance without using the internal DBKey.

You can do whatever you want with your database, but I must put a caution on doing the wrong thing, and make sure that people in the future understand the reason behind some concepts.

Sorry Ken, but I respectfully disagree.

Wherever one can point to an individual (or family or source etc) in webtrees, it accepts the XREF. This is a core function. It has its advantages, I hope you won't deny that.
There is a demand to have it readily available away from the url. I'm not asking for prepending it before the name, just put it somewhere - not in plain sight but one click away in a block hardly ever used. Does that really trouble you? Apparently it does.

New proposal:
Put it in the block Extra Information with CSS styling "hidden"
Then admins can make it visible by overriding the CSS class for this piece of information,.

Wherever one can point to an individual (or family or source etc) in webtrees, it accepts the XREF. This is a core function. It has its advantages, I hope you won't deny that.

It may have advantages, but it is bad design. It would be far better design to automatically generate a “user defined unique ID” in the REFN tag. Defined:

USER_REFERENCE_NUMBER:=
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, or it may be a page and position number on a pedigree chart.

Or generate a RIN tag:

AUTOMATED_RECORD_ID:= {Size=1:12}
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.

Which could in a simple system just copy the generated XREF, but would not be subject to an XREF renumber!

The REFN tag is defined as a user defined number or text. It does not have to be unique although there's good reasoning for it. webtrees should not generate it automatically but leave it to the user or administrator. For example I am using it for the Sosa-Stradonitz or Kekule numbering system.

The RIN tag is defined as a unique record ID number ... by the source system. This seems to be a much better candidate, but I am not sure whether it's supposed to be preserved or replaced during import of a GEDCOM file. I'd vote for replace.

Some genealogy software uses the _UID tag and calls it THE unique identifier even across multiple trees. This _UID tag is being dealth with by webtrees during import and amongst those that like AFN, REFN, RFN and RIN (at least for webtrees 1.7) are being shown in the "Extra information" box, see github.com/fisharebest/webtrees/blob/abc...mationModule.php#L94 .

I am afraid the whole discussion so far focuses on the identification of an INDI(vidual) record only, but there is much more behind this as currently there are no "Extra information" boxes for families, sources, repositories, etc. which can currently be referred to in webtrees by an @XREF@ as well. The _UID seems to be used for individuals only. REFN and RIN could be used for all kinds of records including families, sources, repositories, etc.

So ultimately I *believe" the RIN tag would be the best one for this purpose. And with regard to what Richard said about the specific format of such links I'd suggest to use something like #RIN:number# which would allow an easy replacement of these references in all HTML blocks, notes, shared notes and stories, etc.