- Posts: 2993
Question GEDCOM Tag _ASSO support
- norwegian_sardines
- Offline
- Platinum Member
Ken
Please Log in or Create an account to join the conversation.
- bertkoor
- Offline
- Platinum Member
- Greetings from Utrecht, Holland
But being an "associate" for your own marriage seems somewhat wrong. That I would remove.
To solve the reported problem, you could try to remove the husband I3761 from F1397, check whether all pointers back & forth are removed in both the person & family GEDCOM record (also perform check for Errors to see weather it helped) and then add him again as the husband.
stamboom.BertKoor.nl runs on webtrees v1.7.13
Please Log in or Create an account to join the conversation.
- Peter_S
- Offline
- Senior Member
you are right in scope of GEDCOM 5.5.1 but you are wrong in scope of webtrees.
In webtrees it is allowed to use the ASSO tag in FAM-records to show relations from marriages to witnesses of marriage.
See also in webtrees Wiki: [url] wiki.webtrees.net/en/Custom_Relationship...of_the_ASSOciate_tag [/url]
Best regards
Peter
Peter
webtrees 2.1.19, vesta modules, chart modules of magicsunday, extended family and imprint of hartenthaler
PHP 8.2.4, MariaDB 10.3.38
Webhosting: genonline.de
Please Log in or Create an account to join the conversation.
- norwegian_sardines
- Offline
- Platinum Member
- Posts: 2993
You are probably right. Thanks for the insight.
But as Bert says this is not a MARR.ASSO in my mind. A MARR.ASSO would be for things only related to the marriage event not for interpersonal relationships. This relationship would more likely in my mind be used with the actual REAL use of the ASSO tag INDI to INDI not on an event.
If the individual had presided over the event or participated in the event as a "best man", "maid of honor" then I could see the inclusion.
This all being said I think the GEDCOM looks right and I don't know why the report would flag the error.
Ken
Please Log in or Create an account to join the conversation.
- thomas52
- Offline
- Premium Member
- Western North Carolina
"Failure is an amazing teacher." (L'échec est un professeur extraordinaire.)
Please Log in or Create an account to join the conversation.
- norwegian_sardines
- Offline
- Platinum Member
- Posts: 2993
If the INDI has two FAMS pointers each of the FAM records MUST point back to the INDI.
If this is not the case then this is an error in your GEDCOM. I did not see this in your example but I may have missed the evidence.
Ken
Please Log in or Create an account to join the conversation.
- thomas52
- Offline
- Premium Member
- Western North Carolina
"Failure is an amazing teacher." (L'échec est un professeur extraordinaire.)
Please Log in or Create an account to join the conversation.
- norwegian_sardines
- Offline
- Platinum Member
- Posts: 2993
The INDI.FAMS tag is read as: "This INDIvidual is a spouse in the FAMily of @F...@". The FAM.HUSB tag is read as: "This FAMily is made up of HUSBand @I...@".
Ken
Please Log in or Create an account to join the conversation.
- fisharebest
- Offline
- Administrator
IMHO, if you want to note that the man is marrying his cousin, then a NOTE would be a better choice than an ASSO.
Although the error message is misleading, I'm not sure we should attempt to fix the "bug".
Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net
Please Log in or Create an account to join the conversation.
- Peter_S
- Offline
- Senior Member
fisharebest wrote: The code assumes that there will only be one type of link between two records. Here you have two types of link between the FAM and the INDI.
IMHO, if you want to note that the man is marrying his cousin, then a NOTE would be a better choice than an ASSO.
Although the error message is misleading, I'm not sure we should attempt to fix the "bug".
Hello Greg,
Why are you not sure? The error message as Thomas52 wrote "INDI I3761 has a FAMS link to F1397. F1397 does not have a link back to I3761." has nothing to do with the detected error described by you.
Best regards
Peter
Peter
webtrees 2.1.19, vesta modules, chart modules of magicsunday, extended family and imprint of hartenthaler
PHP 8.2.4, MariaDB 10.3.38
Webhosting: genonline.de
Please Log in or Create an account to join the conversation.
- fisharebest
- Offline
- Administrator
There are two ("HUSB @I3761@" and "ASSO @I3761").
The second link overwrites the first.
So, when we analyse the links, we find just the following:
I3761 has a FAMS link to F1397
F3971 has a ASSO link to I1763
Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net
Please Log in or Create an account to join the conversation.
- Peter_S
- Offline
- Senior Member
yes, I understand. But an error message like "Double or multiple links to the same person are not allowed: HUSB: I3761, ASSO: I3761" is more useful than "INDI I3761 has a FAMS link to F1397. F1397 does not have a link back to I3761."
Best regards
Peter
Peter
webtrees 2.1.19, vesta modules, chart modules of magicsunday, extended family and imprint of hartenthaler
PHP 8.2.4, MariaDB 10.3.38
Webhosting: genonline.de
Please Log in or Create an account to join the conversation.
- norwegian_sardines
- Offline
- Platinum Member
- Posts: 2993
Ken
Please Log in or Create an account to join the conversation.
- WGroleau
- Offline
- Platinum Member
- Posts: 2152
I agree with Greg that it may be worthwhile to support extensions that a large number of other programs have adopted.
And I think the evolutionary enhancements that list seems to be coming up with are the only way we’ll ever get a “better GEDCOM.” All the other well-meaning and even sometimes well-done “throw it out and start over” proposals share a fatal flaw, which is that no one offering a working program wants to start over—and no one wants to buy/use a program that doesn’t talk to the others.
But I do not think it was not a good decision to create a custom tag that differs from a standard tag only by the leading underscore.
--
Wes Groleau
UniGen.us/
Please Log in or Create an account to join the conversation.
- nigelo
- Visitor
WGroleau wrote: But I do not think it was not a good decision to create a custom tag that differs from a standard tag only by the leading underscore.
Wes, do you really mean "I do not think it was not a good decision ...." or should that be "I do think it was not a good decision ..."??? You seem to have a double-negative going on there.
Please Log in or Create an account to join the conversation.
- WGroleau
- Offline
- Platinum Member
- Posts: 2152
--
Wes Groleau
UniGen.us/
Please Log in or Create an account to join the conversation.
- norwegian_sardines
- Offline
- Platinum Member
- Posts: 2993
But unfortunately many programs have adopted similar concepts but not necessarily similar tags or placed the tags in the same place.I agree with Greg that it may be worthwhile to support extensions that a large number of other programs have adopted.
Some GEDCOMs add tags that are not necessary if they had read the v5.5 or v5.5.1 standard. For instance _NATU in FTM for natural mother and father. The concept exists in the GEDCOM already, but in a less than perfect way. Also all the event and fact additional tags for DNA, school, military service, property etc. And the misuse of the "Description" tag.
It would take us a long time to sift thru the tags and decide which ones were most used, because if we pick one based on our users and we don't have enough users YET from another software set then we could be missing a much larger population of users.
So this brings me back to the translation both in and out of GEDCOM tags for round trippers. If we intend to have a normalized, non-GEDCOM based database... We will, if we want to please everyone have to support input and output of various specific dialects of GEDCOM as well as our own dialect and maintain that going forward.
If we don't want to have a non-GEDCOM based database then none of this matters except for tables to translate the 100 or 1000 of various tags that people could send to us. _ASSO vs ASSO in a fact/event is only one of them.
Ken
Please Log in or Create an account to join the conversation.
- WGroleau
- Offline
- Platinum Member
- Posts: 2152
the claim was that a group had come up with a consensus that many programs had adopted. Different thing from incompatible independently developed extensions.norwegian_sardines wrote:
But unfortunately many programs have adopted similar concepts but not necessarily similar tags or placed the tags in the same place.I agree with Greg that it may be worthwhile to support extensions that a large number of other programs have adopted.
Like _MARNMSome GEDCOMs add tags that are not necessary if they had read the v5.5 or v5.5.1 standard.
--
Wes Groleau
UniGen.us/
Please Log in or Create an account to join the conversation.
- thomas52
- Offline
- Premium Member
- Western North Carolina
But if there are that many different "packages," this would suggest to me a USER setup, or something unique to that user or a group of users.
Would not a module of some type be possible where a user could input their own tags.
The histo.en_US file allows me to show the events of my choosing. Perhaps an option something like the theme option? Or possibly something of this nature where the data or settings could be input offline and added?
Just a thought; I have no clue of the feasibility, but I do know if you try to please EVERYONE, the result is you please NO ONE.
"Failure is an amazing teacher." (L'échec est un professeur extraordinaire.)
Please Log in or Create an account to join the conversation.
- nigelo
- Visitor
thomas52 wrote: If I recall, I can edit the language file to add _MILI to mean Military (or something of that nature.)
But if there are that many different "packages," this would suggest to me a USER setup, or something unique to that user or a group of users.
Would not a module of some type be possible where a user could input their own tags.
The histo.en_US file allows me to show the events of my choosing. Perhaps an option something like the theme option? Or possibly something of this nature where the data or settings could be input offline and added?
Just a thought; I have no clue of the feasibility, but I do know if you try to please EVERYONE, the result is you please NO ONE.
Already exists: wiki.webtrees.net/en/Custom_Tags
Please Log in or Create an account to join the conversation.