Add marriage date and place to the Tag list.

LegacyUser

James Barrett Tadje said: When adding a source, the Tag list allows one to identify the event that the source pertains to. The Tag list does not allow marriage date or place to be indicated. That has to be done separately. It would save time and effort if the Tag list included these two events.

LegacyUser

Juli said: Unfortunately, with the current backwards setup of the tagging function, this is simply impossible, because people can have multiple marriages.

(What I mean by "backwards setup" is that currently on FS, tagging is not between a citation and a specific conclusion, but between a citation and a subset of profile fields, specifically the ones under Vitals. The crucial characteristic of these profile fields for this purpose is that they're all single-value: you can only have one name etc. under Vitals. This allows for a completely static list of tagging checkboxes, which I suppose is easier to program and implement than a dynamic one would be, but is far less useful.)

LegacyUser

Jeff Wiseman said: As Juli pointed out, the support of sources on all relationship types has been messed up pretty bad. You cannot tag a marriage source attached to an individual to couple or parent-child relationships of any sort related to that individual. FS has been trying to set up totally separate and distinct source lists for each and every relationship any person record in the system can have with any other person record in the system.

I believe that this is a totally inappropriate implementation. I also suspect that the reason the ability to use sources already attached to individuals in the support of relationship events has been missing for quite a while now, is due to this problem. I.e., either FS can't figure out how to make it work in any consistent and unambiguous way, or (hopefully) they are starting to understand the extreme complexities that they are going to continue to run into by persisting in the current course of development.

I hope that the feature you are requesting is eventually implemented, but in order for that to happen, FS will first have to give up on their current development approach to supporting both couple and parent-child relationships. I don't know how likely that is.

LegacyUser

Adrian Bruce said: "backwards setup" - hmm. I can think of some less restrained Anglo Saxon terminology!

LegacyUser

Adrian Bruce said: In fairness, sourcing parent-child relationships seems difficult in just about any software. I suspect this is partly because it's not wholly clear what the evidence actually means.

Suppose the tree says John C PID-1 is the son of William C PID-2.

Suppose also that I have a marriage certificate that says that the father of John C (known to be PID-1) is William C. What that does not tell me is which William C is the father! So is the certificate evidence that John C PID-1 is the son of William C PID-2? Errr... Partly, yes, I guess - but it can't be the whole story... It is deadly if you start thinking about it...

LegacyUser

Juli said: I initially wrote a different phrase, but decided to let the bare facts speak for themselves instead. :-/

LegacyUser

Jeff Wiseman said: That is why the essential model for all of this has the derivation logic for the conclusion BETWEEN the conclusion and the evidence provided by sources. In the case you are describing, simply attaching sources to the conclusions are not enough. You must also provide a derivation logic type document (e.g., a Note) that shows how the set of sources your have are interpreted to arrive at the conclusion.

That's how it would be done now. And if the ability to tag the Notes (derivation logic) to the conclusions in the same way as the sources (historic evidence documents) are, it would be even easier.

LegacyUser

Adrian Bruce said: "Simply attaching sources to the conclusion is not enough".

Yes, that's a neat summary.

LegacyUser

Adrian Bruce said: :-)