* Assigning a fact to multiple individuals

[AdrianBruce]

Witness is a one-way link that could be souped up to be two-way

To be rigorous, we need to specify what 1-way and 2-way mean in this context.

For instance, if I have a marriage event of X and Y, with Z acting as a Best-Man witness, then I can see the path to Z from the Fact tabs of both X and Y.

Conversely, if I'm on the Fact tab for Z, then I can see his role as Best-Man in the marriage of X & Y.

So visually, looking at the Fact tabs in question, Witness is already 2-way.

Presumably, what you are after is accessibility from, as you say, the All tab for Z. But for what purpose? Well, you say, e.g. "Witness detail, in both directions, would be accessible to standard queries & reports."

In fact, a narrative report for Z will already show his role as Best-Man in the marriage of X & Y. Or at least, it will if the sentences are set up. I believe that other, non-narrative reports are not so good at showing witnesses but that's presumably a different kettle of fish that could be fixed in other ways.

As for queries, well, fact queries will, I believe, show Witness details. There are even Individual Queries that show their owners' witness details but they are reliant on constructions like %INDI.~SHAR[2].ROLE% and repeating for [1] thru, well, whatever, [9] on the one I'm looking at.

That construction is a pain (not least because there's a hard-coded limit) but it's a pain that applies to any multiple events. I'm not sure whether getting into that pain is because I've started from the wrong place, i.e. from an Individual query when I should have started from a Fact query, but whatever it is, it's not particularly witness related.

So given that some of the links that witnesses require are already there - is it more that those links are not wholly visible / practical? If so, which? Or are there things that are totally missing?

[tatewise]

I would like to clarify some points...

That a Fact is shown on the Facts tab does not imply any direct 2-way linkage.
e.g. Timeline Facts are shown there but are only linked to the Individual indirectly via one or more Family records.
It is possible to traverse the links via the All tab but it is quite longwinded.
Fact Witnesses have no direct link back to the Principal Fact so nothing appears in the All tab.

Fact Witnesses appear in all the popular Reports such as Individual Summary Report and Family Group Sheet, as well as Narrative reports, and is one of the attractions of FH v7 over FH v6.

IMO Fact Queries show Fact Witness details little better than Individual Queries.
They certainly do not appear in a single column in the way that Principal Fact Owners do.
If there were 9 Fact Witnesses to a single Fact then you would need 9 extra columns to list just their Names and another 9 to list their Roles.

The sort of 2-way link needed to assist with Queries, Expressions, etc, would have custom tags in the Fact Witness record each with a link back to the Principal Fact.

[dbnut]

As an aside, I have often wondered why the updated date/time for a Source record changes if one of its citations is deleted, but not if an extra citation is added. Is there a logical explanation for this?

Lorna, just discovered this old post and remark of yours, and was really surprised.
For a moment thought such a (presumed) bug would have been reported and fixed, so it wouldn't be there anymore.
But nosey me was curious enough to check.

It's actually worse now because "updated" was modified for added citations as well as deletes. Plus there's a quirk in the Individual Record Property Box, tab "All" where the citation shows directly beneath the individual's citing fact (in a simple case). Checked also the stored data at every stage and found nothing but valid GEDCOM structure, no custom extensions, so there's no logical explanation.

In my book that breaks the rules, trivial though it might look. But it could be a problem for some and should be fixed.

Expected there to be some protocol for bug reporting, like posting in a dedicated forum for a period of review (in case I'm wrong, or it's been reported before, or it's more extensive than I realised, or whatever) before bothering Calico.
Seems not, though, and I can't message Jane L.

I'm used to working with a formal bug tracking system the team can monitor, so a bit disappointed.

[LornaCraig]

Firstly, there is a protocol for bug-reporting. You can open a 'ticket' with Calico Pie, the developers, here: http://support.calico-pie.com/index.php There is no dedicated forum for discussing bugs but it's common practice for a problem to be discussed in these forums first and if others agree that it is a bug then someone raises a ticket.

Secondly, yes the problem was reported back in 2016. It wasn't fixed quickly, but CP must have added the fix to a recent version. I hadn't realised, and mentioned it again recently in this topic: https://www.fhug.org.uk/forum/viewtopic ... 32&t=20087# However Mike then pointed out that it has been fixed. In other words both adding and deleting a citation update the time stamp for the Source, which is what I would expect. (However I note that you think this is worse...?)

[dbnut]

That's really informative, thanks. Sorry I didn't go searching for any follow-up.
I do know the ticket system and used it a few times, but glad to know informal review is commonplace here.
Yep, I definitely have a different perspective.

It's no contest if Calico has some under-the-hood imperative to update source records when citations are added or drop off.
But imagine what a real-world analogy is: GRO (knowing about and) recording every time that someone cited (or uncited) any piece of their "intellectual property". And the argument may change in detail (depending on notions of source hierarchy and "Methods"), but the principle still holds.

It's perfectly correct to update an individual's "version date" if you add or delete an occupation, for example - which is a property "owned by" the individual. You are changing the detail inside one record.

By contrast, the source record in question is totally independent from the individual, or any citation, or anything else except its own properties (author, for example).

The structural difference is that citations make a one-way reference to a source record[1] (not leaving any footprints behind!).
In GEDCOM terms:

• occupations are elements within one (individual) record structure

• citations contain only a pointer (XREF) to another (source) record

Hope that's convincing enough, but of course I don't know anything about Calico's reasons.
Review away!
__________
[1] That reference/pointer/link could in theory be made two-way simply by "enriching" source records to have "backwards/downwards" pointers to all the citations made to it.

That may sound odd but it's exactly the structure of a family record which "knows" (by pointers) who all the children are.
And that is why, in a Family Property Box, on the "All" tab, you can "expand-button down" the generation tree.

And that is why, in a source record, you can't see any citations made. Which is a great shame, of course.
But the way to provide this is not converting those pointers to be two-way because that is a "GEDCOM illegal" [Edit: I mean in the context of GEDCOM specification's standard source record structure. Breaking that is taboo (something only other programs do!), but extensions are allowed].

[dbnut]

Witness is a one-way link that could be souped up to be two-way...
To be rigorous, we need to specify what 1-way and 2-way mean in this context...

Adrian, acknowledging everything you say, which is perfectly right (I think), let me shut down with these:

• Thanks for responding generously & constructively to what was meant as a teaser for a comprehensive proposal in draft.

• That was a mistake, a distracting intrusion in the wrong (if maybe relevant) thread. Should hold my water until/if I've got something coherent to say!

[ColeValleyGirl]

citations contain only a pointer (XREF) to another (source) record[/list]

This is wrong.

Citations contain a pointer to a source record, but can also contain: a Quality Assessment, a Note, Text from Source, Where within Source, an Entry Date, and Event Type Responsible.

So Adding or Removing a citation is more than just adding or removing a pointer, and OUGHT to be recorded as a change to the record. IMO.

And that is why, in a source record, you can't see any citations made.

Unless you use View > Citations to Source Record...

[Mark1834]

There may be a case for arguing that a lumped source containing hundreds or thousands of citations need not be updated when an individual citation changes. However, by adding or deleting a citation to a source, you are changing the significance of that source in supporting the story you want to tell (and remember that the sources are there only to support the conclusions we draw - data versus information). It would be impossible to draw a line at the transition between "significant" and "insignificant" changes, so a consistent approach is to say that all links between GEDCOM record types result in an update.

CP are removing the anomaly that a Rich Text link updates the linked record but a web page link does not in the next revision of FH.

[tatewise]

Helen, Paul is not complaining about a record having its Updated timestamp changed when a Citation is added, with whatever other fields are involved as well as the Xref link.
He is complaining about the Source record Updated timestamp being changed when a new Citation Xref links to it.
That Source record Updated timestamp is changed again whenever a Citation link to that Source is deleted.
In neither case is the Source record itself changed in any way.
Only its Citations link count is updated, which is not a GEDCOM field.

The same Updated timestamp changes occur with any added or deleted link from one record to another.
e.g.
When a Repository is added or removed from a Source the Repository record Updated timestamp changes.
When a Note record is added or removed from another record the Note record Updated timestamp changes.
When a Media record is added or removed from another record the Media record Updated timestamp changes.
In all these cases the target record GEDCOM is not changed in any way. Only its Links Count is updated.

The same is true when a Rich Text Note adds or removes a link to a record.
That other record has its Updated timestamp changed consistently with the above behaviour.
However, a special exception is being made for this Rich Text Note case in the next FH version.
Then the target record Updated timestamp will no longer change even though its Links Count will still change.

So when Lorna reported a problem with the Updated timestamp, FH was inconsistent.
That was recently fixed to make FH consistent throughout.
IMO the next FH version will become inconsistent again regarding Rich Text Note links.

I tend to favour Paul's opinion that the Updated timestamp should NOT change just because the Links Count changes.
There is no GEDCOM data changed so the Updated timestamp should not change in any of the above cases.

[ColeValleyGirl]

I believe that if the connectivity of a record changes, that should be reflected in the record's timestamp.

[LornaCraig]

From a purely practical point of view I like the fact that a record (particularly a Source record) has its updated time stamp changed when any links are added or removed. This is because I can leave the Sources tab of the Records window sorted by Updated date so that the Sources I have used most recently are quickly accessible at the top.

From a purely theoretical viewpoint I can see that there are arguments on both sides...

[tatewise]

I've removed my reference to Individual records. However, Paul did make his comments with respect to Individual records, although they can be interpreted in the more general case of wherever Citations are allowed.

You "believe that if the connectivity of a record changes, that should be reflected in the record's timestamp."
So I presume you oppose the planned change in the next FH version with regard to Rich Text Note record links, where when such links change the connectivity of another record its timestamp will not change.
See https://www.fhug.org.uk/forum/viewtopic ... 55#p120152.

It seems there are pros and cons, so perhaps FH should provide an option to switch such timestamp changes on and off.

[Mark1834]

Agree with Lorna - “inconsistent” seems to mean inconsistent with one’s own view of which changes should update the timestamp, rather than inconsistent with any absolute standard. I’m sure the forum has had many years of “this is how I would do it if it were my application” - including from me, so I’m in the glasshouse as well ...

[tatewise]

The absolute standard I am applying is the GEDCOM definition of the CHANGE_DATE CHAN tag, which is where the FH Updated timestamp ends up:
GEDCOM 5.5.1 says on Page 31:

The change date is intended to only record the last change to a record. Some systems may want to manage the change process with more detail, but it is sufficient for GEDCOM purposes to indicate the last time that a record was modified.

IMO a change to the Link Count that is internal to FH, and does not modify the record, violates that GEDCOM definition.
It is another example of where FH is not strictly 100% GEDCOM compliant, despite claims to be so.

[ColeValleyGirl]

So I presume you oppose the planned change in the next FH version with regard to Rich Text Note record links, where when such links change the connectivity of another record its timestamp will not change.

On the topic of updated dates, I've never found a use for them, and don't display them anywhere -- to me they're just noise.

I have what you might call a theoretical opinion on thep lanned change, but it hardly matters whether I oppose it or not. It's Calico Pie's product, to Calico Pie's design, and I don't think it's my place to dictate that design. (I'm less bothered than many people seem to be by perceived inconsistencies -- I've used software products that are a lot more inconsistent than this one.)

What would bother me -- on principal -- is introducing more and more options to try and make the product all things to all users. In the dim and distant past, I saw too many software development projects go off the rails, trying to include every feature that every user wanted, rather than drawing a line in the sand and saying: this is how the product will work. Full stop. You cannot design a robust software product by committee.

[LornaCraig]

Agree with Lorna - “inconsistent” seems to mean inconsistent with one’s own view of which changes should update the timestamp, rather than inconsistent with any absolute standard...

Actually the inconsistency I originally reported was pretty clear cut, more than just my 'own view'. I had noticed that adding a citation to a Source record didn't change its timestamp, but deleting a citation did change the timestamp. Whichever side of the fence you are on, you probably agree that adding or deleting a citation should either both change the timestamp or neither change it!

I happen to find it convenient that the timestamp now gets changed in both cases, but I'll leave the discussion of Gedcom compliance to others....

[dbnut]

citations contain only a pointer (XREF) to another (source) record[/list]

This is wrong.

Citations contain a pointer to a source record, but can also contain: a Quality Assessment, a Note, Text from Source, Where within Source, an Entry Date, and Event Type Responsible.

So Adding or Removing a citation is more than just adding or removing a pointer, and OUGHT to be recorded as a change to the record. IMO.

And that is why, in a source record, you can't see any citations made.

Unless you use View > Citations to Source Record...

Sorry to contradict. This is right. Or, more graciously as I should say it, I'm 100% convinced this is right. Let me explain my thinking.

That entire collection of data you list is your personal record of what you took away, COPIED, from your virtual visit, including your assessment and interpretation, all elements of which can potentially be revised over time. Even "Event Type Responsible" is your private decision.

What you COPY and whatever abbreviations/mistakes you make in the process, and whatever revisions you make later to any part of all that, and (significantly) whether you throw it in the bin or not, are of absolutely no interest to the SOURCE itself.

More subtly, your interpretation can evolve (often in the light of other data), even influence all sorts of other "facts" (such as supporting the notion reported age at death must have been an error). You'll likely want to have that in the Notes on death and maybe (as I find convenient) add a remark in the original citation we're concerned with here. Source updated???

You went, you copied, you returned, typed it into FH, messed with it on-and-off, maybe binned it if something better turned up.

You might even sneakily copy a citation wholesale from someone else and (in the absence of hierarchical "sources") not mention that in your citation notes. Would you want the Source record's change date/time bumped for that?

You "visit" online access to a source, or a ledger, or terminal, or get a researcher/staff to give you a slip of paper. You may have left a cookie on a website, a log of your reader's ticket scan, a pencil on a desk, or a smile on the face of the guy who helped out. The institution and the archive itself couldn't care less. It's STATE hasn't changed one iota.

A real-world analogy might be a cooking programme on TV. You could learn something and add it to your recipe book. Even add a note you found it courtesy the BBC? Would that make any difference to the BBC?

Lorna, you may be right and me wrong, but you haven't managed to shake my confidence one bit that this is a bug. And if it turns out there is similar behaviour in other areas then I think it's appalling. It contradicts the whole ethos of "encapsulation" and, for us, gives totally misleading information about when updates to important objects[1] have taken place.

Finally, I'd never noticed that lovely feature [THANKS!] in the main application menu bar, also (curiously) tucked away under the Settings button of the Source Record Property Box toolbar, menu name "Show Source Record's Citations in Result Window". It could usefully be added to the context (right click) menu on rows in the Main Window, Sources tab.

It is a shortcut to (what I'd deduce to be) FH main code or a Lua script, kindly provided to work around the fact that Citation details are NOT stored in the Source itself! So an ordinary (standard or custom) query cannot deliver that beautiful layout with instant access to the event, while a script/program can "walk the (GEDCOM) tree" and find all the relevant pointers/references.

[That is yet another area where Calico has done a great job compensating for what I consider to be one of very many defects in the GEDCOM data model. Some of those are gradually being addressed by (careful) extensions particular to FH.]

_______________
[1] There is a place where citation edits should automatically update "Updated" - in the citation itself. But it can't because GEDCOM does not treat citations as "records". There are other examples.

[ColeValleyGirl]

That entire collection of data you list is your personal record of what you took away, COPIED, from your virtual visit, including your assessment and interpretation, all elements of which can potentially be revised over time. Even "Event Type Responsible" is your private decision.

What you COPY and whatever abbreviations/mistakes you make in the process, and whatever revisions you make later to any part of all that, and (significantly) whether you throw it in the bin or not, are of absolutely no interest to the SOURCE itself.

Let us consider just one item in my list: Text from Source.

Why would you consider a source record updated if you changed Text from Source within the Source Record, but not when you changed it within a Citation? (Which might be the only place you record Text from a particular Source)

[dbnut]

The same Updated timestamp changes occur with any added or deleted link from one record to another.
e.g.
When a Repository is added or removed from a Source the Repository record Updated timestamp changes.
When a Note record is added or removed from another record the Note record Updated timestamp changes.
When a Media record is added or removed from another record the Media record Updated timestamp changes.
In all these cases the target record GEDCOM is not changed in any way. Only its Links Count is updated.

Oh dear.

I tend to favour Paul's opinion that the Updated timestamp should NOT change just because the Links Count changes.
There is no GEDCOM data changed so the Updated timestamp should not change in any of the above cases.

I'm glad. Also a bit miffed I didn't think of that last observation myself.

[ColeValleyGirl]

I wonder if the differences of opinion are rooted in a philosophical difference in how we understand records.

For me, a Source record is a record aboutthe Source AND about my view of that source. It contains information to enable me to find the Source again, information about what I found within the source, information about how reliable I think it is, etc.

The data associated with a Citation for a Source is (IMO) more information about the Source. (If it was information about an Individual or a Fact, I wouldn't put it in the Citation or the Source record, but in a Fact or an Individual record)

So if the connectivity of a source changes, it's a change to the information about the Source.

And for me, the same basic principle applies to other records -- they are all records about some entity, and connectivity is part of the information about that entity...

I'm afraid that a 'purist GEDCOM-based argument' is not going to convince me otherwise.

[dbnut]

There may be a case for arguing that a lumped source containing hundreds or thousands of citations need not be updated when an individual citation changes. However, by adding or deleting a citation to a source, you are changing the significance of that source in supporting the story you want to tell (and remember that the sources are there only to support the conclusions we draw - data versus information). It would be impossible to draw a line at the transition between "significant" and "insignificant" changes, so a consistent approach is to say that all links between GEDCOM record types result in an update.

If you look in the Sources tab of the Records Window, number of citations is there (or easily added, can't remember what was in the default configuration) and can of course be a sort column. Handy for spotting unused records, good to tell which are "popular".

And IMHO "lumped sources" are the historically ORIGINAL "SOURCES". I think the alternative kind should never be allowed out without a suitable qualifier... something like "ripped pages from a book".

[tatewise]

If I understand Helen's point correctly, then changes to a Citation such as its Entry Date, Assessment, Text From Source, Where Within Source, Citation Note, or Citation Media should change the Updated timestamp of the Source record?
That does NOT happen. Only adding and removing Citation links to Source records change their timestamp.

[ColeValleyGirl]

Mike, yes, you've understood.

But as I said, I'm not really bothered, as I don't use the date stamps.

[Mark1834]

I'm not sure how you can have "100% compliance" with something as ambiguous and badly written as GEDCOM anyway...

Get a bunch of retired folk with time on their hands together, and it's amazing what they'll find to discuss, even if it doesn't change a thing. As a user, I'm less bothered about adherence or not to some arbitrary model or philosophy than I am about whether it behaves predictably and reasonably logically. For me, the present balance is about right.

[davidf]

I wonder if the differences of opinion are rooted in a philosophical difference in how we understand records.

For me, a Source record is a record aboutthe Source AND about my view of that source. It contains information to enable me to find the Source again, information about what I found within the source, information about how reliable I think it is, etc.

The data associated with a Citation for a Source is (IMO) more information about the Source. (If it was information about an Individual or a Fact, I wouldn't put it in the Citation or the Source record, but in a Fact or an Individual record)

Does it also depend on your lumper/splitter position?

As a lumper:

My source record will hold "master record" information about a source - a book, an artefact, or a collection (such as FreeBMD Births or the 1851 Census on FMP). Against it I will want to hold information specific to the source:

• Its repository
• Its general reliability/applicability (e.g. "This collection is actually a meta collection of parish marriage registers, banns, and bishops transcripts - check what you are looking at!", or "IGI Patron records seem to have a lot of wishful thinking and therefore should only be indicative")
• Notes about my searching history on that source (e.g. When I last reviewed the 1939 register source to pick up un-redacted records)
• Notes about accessibility of a source (e.g. "If you ask the record office staff very nicely they will dig out the actual parish register - rather than get you to try to read the microfilm")

My citation will hold information about what I take from that source

• Specific text from the source relevant to the fact being supported
• Location of the specific information within the source (book page, GRO ref, TNA ref etc.)
• My estimate of the quality of the specific information that I have taken from that source for the fact holding the citation - which could relate to my uncertainty about conclusions drawn from the source or about for instance difficulties in reading an image.

If I change the above citation information (whilst keeping the same lumped source), I would not consider that a change to the source record.

If I was a splitter the "citation" info is pretty much redundant other than holding the pointer to the source - because all "information" relates to the split source.

The fact that "citations" are not recognised as GEDCOM "records" (but are held as a branch of the ~fact~ being supported) is I think only relevant in trying to work out where an "update date" should theoretically be held. Because of the structure of GEDCOM, updating a citation should change the "update date" of the record holding the fact that the citation is supporting. For a Lumper, that would not be the Source Record?