faces and XREFs: why not use (_)UID?

[ungeahnt]

First, many thanks for the wonderful module!

In my trees faces has for a few INDIs links to 'old' XREFs which no longer exist. I assume it happend due to merging, updates or 'Renumbering XREFs' in the past, but actually I don't know.

At the moment I haven't created that many links in faces, so it's not a big problem for me yet. I will correct the lost links manually.

I just wonder what happens when there are so many that a manual correction becomes very time-consuming or an assignment is no longer possible.

So I have the following questions:

1. What could have been the cause of this? What do I have to watch out for?
2. Since XREFs can change, I wonder if it would not be better to use a unique ID (like UID: officially in the standard since GEDCOM7; or the custom tag _UID)?

[zhoueysun]

I second this. I was planning to reference the XREF to the _UID

[UksusoFF]

What could have been the cause of this? What do I have to watch out for?

Importing tree from GEDCOM file can break relatation.
Maybe reuploading photo or document also.
In admin panel you can try repair broken relations. It's can be compared by media filename.

Since XREFs can change, I wonder if it would not be better to use a unique ID (like UID: officially in the standard since GEDCOM7; or the custom tag _UID)?

As I know webtrees does not support GEDCOM7 yet. Custom tag don't want to use.

[ungeahnt]

In admin panel you can try repair broken relations. It's can be compared by media filename.

In faces settings I can see the broken links (= some invalid/old XREFs are visible per media), but I see no possibility to repair the broken links. Could you please give a hint how to fix?

As I know webtrees does not support GEDCOM7 yet.

But would it be an option for you once UID is supported in wt?

wt already supports many GEDCOM7 tags and I guess it will only be a matter of time until UID is supported as well.

It seems that with XREFs there will be always a risk of broken links or am I wrong? At the moment, this still keeps me from a more intesive use of faces.

Custom tag don't want to use.

Maybe you can make it configurable for the user?

[hartenthaler]

_UID can be used as a custom tag already in GEDCOM 5.5.1.

But there is a definition in GEDCOM 7 how to specify "faces". So it does not make sense to develop another solution now based on _UID.

[ungeahnt]

But there is a definition in GEDCOM 7 how to specify "faces".

Which definition do you mean?

[UksusoFF]

@ungeahnt

but I see no possibility to repair the broken links. Could you please give a hint how to fix?

[ungeahnt]

Ah thanks, but in my case it could not fix it:

[hartenthaler]

But there is a definition in GEDCOM 7 how to specify "faces".

Which definition do you mean?

GEDCOM 7.0.10 says on page 55:

MULTIMEDIA_LINK :=

n OBJE @XREF:OBJE@ {1:1} g7:OBJE
+1 CROP {0:1} g7:CROP
+2 TOP {0:1} g7:TOP
+2 LEFT {0:1} g7:LEFT
+2 HEIGHT {0:1} g7:HEIGHT
+2 WIDTH {0:1} g7:WIDTH
+1 TITL {0:1} g7:TITL

Links the superstructure to the MULTIMEDIA_RECORD (p.40) with the given pointer.
The optional CROP (p.70) substructure indicates that a subregion of an image represents
or applies to the superstructure.
The optional TITL (p.89) substructure supersedes any OBJE.FILE.TITL substructures
included in the MULTIMEDIA_RECORD

and on page 70

CROP (Crop) g7:CROP
A subregion of an image to display. It is only valid when the superstructure links to a
MULTIMEDIA_RECORD (p.40) with at least 1 FILE (p.75) substructure that refers to an ex‐
ternal file with a defined pixel unit.
LEFT (p.79) and TOP (p.90) indicate the top-left corner of the region to display. WIDTH (p.94)
and HEIGHT (p.76) indicate how many pixels wide and tall the region to display is. If
omitted, LEFT and TOP each default to 0; WIDTH defaults to the image width minus
LEFT ; and HEIGHT defaults to the image height minus TOP .
If the superstructure links to a MULTIMEDIA_RECORD that includes multiple FILE sub‐
structures, the CROP applies to the first FILE to which it can apply, namely the first ex‐
ternal file with a defined pixel unit.
It is recommended that CROP be used only with a single-FILE MULTIMEDIA_RECORD .
The following are errors:
LEFT or LEFT + WIDTH exceed the image width.
TOP or TOP + HEIGHT exceed the image height.
CROP applied to a non-image or image without a defined pixel unit

[ungeahnt]

GEDCOM 7.0.10 says on page 55:

MULTIMEDIA_LINK :=

In this case the Mediafile and the (faces)region are part of the same GEDCOM. Therefore, changing the XREF should no longer result in data loss. That sounds good.

However, at the moment I still see a problem with the assignment of the MULTIMEDIA_LINK. You don't want to have all MULTIMEDIA_LINKs from a GEDCOM listed in faces. To distinguish this there would have to be a way to assign the MULTIMEDIA_LINK to specific applications/purposes (like faces). This doesn't seem to be possible at the moment. I think an additional tag 'purpose' (e.g. 'PURP UksusoFF-faces') would have to be introduced for MULTIMEDIA_LINK.

If faces can't find its own MULTIMEDIA_LINKs independently after a change, then we have a similar problem as now.

[UksusoFF]

@ungeahnt

Ah thanks, but in my case it could not fix it:

Are you see links on media view? On admin part it's always display as person id.

[ungeahnt]

Are you see links on media view? On admin part it's always display as person id.

By 'links', do you mean the names? No. The single one with name (Adalbert Schmidt) I've corrected manually.

All other individuals had their XREFs changed from 'I' (like I92, I91, ...) to 'X' at some point. As I said, when and how this happened I can't say anymore (probably the "Renumber XREFs" function in wt). But I had no other problems with it so far.

[UksusoFF]

@ungeahnt
Yes, if id is similar you can run sql update for fix it.
If you send me database I can check this.

[ungeahnt]

Yes, if id is similar you can run sql update for fix it.

What is 'similar'? May you want have a look to the following faces-image on my tree. May you can see what happens and give me a hint to avoid it in future:

faces-view with the old XREFs: https://proavitus.de/tree/proavitus/media/M213/Hubl-Familienbild-ca-1900#
family with new XREFs: https://proavitus.de/tree/proavitus/family/F143/Bernard-Hubl-Anna-Janisch

If you send me database I can check this.

Thanks, but I think I will fix it manually (there are only 10 images connected to faces).