* Assigning a fact to multiple individuals

[dbnut]

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.

That's a highly revealing description of your perspective, which I can see is holistic.
And, despite mankind's efforts to understand it and work with it in manageable chunks, there is compelling evidence the Universe itself is (somehow) "connected" across both space and time.

I'd dare to guess that the female mind tends to holistic and the male analytic. And I'm not in the least suggesting one is "better" than the other. Though I do believe they are sometimes better suited to different kinds of problems.

My own thinking was conditioned (very comfortably) early on by the "relational data model" and rather later (and to a much lower level of expertise) "object-orientated analysis" which, although there are competing paradigms, have served the computing industry remarkably well for decades and continue to be mainstream.

The basis of my arguments has little to do with GEDCOM (which at surface level is not relational anyway, besides having gross deviations from any realistic data model suited to genealogy and especially family history) and everything to do with visualising~modelling "fh" data in a standardised fashion that meshes with the mindset and tools of computer professionals.

[How a computer program structures and manipulates data in memory doesn't need to mirror the way data is stored (on disk) - and vice versa. That leads me to wonder if Calico works with (enhanced) GEDCOM-like memory structures or went for "OO". Just being curious, I'll probably never find out.]

And how I wish I could create diagrams for display as fast as sketching them illegibly. Because they really do illuminate the entities we are talking about here. The idea of "encapsulation" would make better sense (even if objected to) and it would be easier to explain how you can still discover qualities about "connections" without "storing them in the wrong place" (as I would have it).

The application (FH) doesn't always make the distinction~boundaries between entities very clear. The user interface is designed to favour easy data entry/editing, easy holistic understanding, easy navigation, with the least distraction from other stuff "under the hood". And does that job rather nicely IMO.

So alternative "views" of the data architecture can be informative. I'd support the idea of documenting all the record types, including auxiliary types, in diagram fashion with a chart showing their relationship (i.e. a relational view). Companion sheets could document all the events/properties available for any one record type and show in context any elements where GEDCOM had been extended. Quite a bible!

That would never be the starting point for most new users (bedtime reading for the likes of me ) but parts of it quite a good map of common ground in debates such as this. Pipe dream.

I do go on.

[dbnut]

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")

Very interesting. I suppose your source record does include lots of Notes, and it's a pity we can't (apparently) add custom properties - like Date Last Accessed. And presumably you have Sources for each Census and would gladly exploit multi-level Sources to record your details at the best level.

Then there is the situation with certain but not all sources within a Repository having some common features. And, in general, other sets of sources with common factors.

And a question whether there is mileage in linking (or transferring) some of this stuff to Research Notes (which could be easily extended with pointers). It goes on and on. Like me.

[ColeValleyGirl]

Paul, with 42 years and counting experience in IT, I'm pretty familiar with object-orientation and relational databases and my preferred programming style is object-oriented. Plus, a degree in Physics does tend to push one towards an analytical mindset. I'm just analysing the problem in a different way!

My arguments are in no way based on GEDCOM (nor should FH be constrained by GEDCOM, which is only its data storage vessel, not a set of instructions for how the program should be designed/operate.)

visualising~modelling "fh" data in a standardised fashion that meshes with the mindset and tools of computer professionals.

Why are the mindset and tools of 'computer professionals' relevant to using FH? Yes, I suspect the user base does skew that way, but there are plenty of users who would have a clue -- and don't need a clue -- about visualising-modelling 'fh' data. They just need to understand how to use the program to do the things they want to do in a way that works for their mindset. (Most of them could care less about GEDCOM, as well, except when it comes to exporting data.)

Not complete, but a starter for 10 (drafted for a slightly different purpose, so it focuses on a particular way of working):

fh records.jpg (190.56 KiB) Viewed 1074 times

[ColeValleyGirl]

it's a pity we can't (apparently) add custom properties - like Date Last Accessed

GetLabelledText is your friend.

[dbnut]

it's a pity we can't (apparently) add custom properties - like Date Last Accessed

GetLabelledText is your friend.

Brilliant, and something I will try to remember next time in extremis.
(not that I think it's a final solution, hehe)

[Mark1834]

I believe the core FH application is written in C++, so almost certainly heavily OO internal plumbing.

[dbnut]

Paul, with 42 years and counting experience in IT, I'm pretty familiar with object-orientation and relational databases and my preferred programming style is object-oriented. Plus, a degree in Physics does tend to push one towards an analytical mindset. I'm just analysing the problem in a different way!

Just winding me up then, Rotter! No, not so, accepted.

My arguments are in no way based on GEDCOM (nor should FH be constrained by GEDCOM, which is only its data storage vessel, not a set of instructions for how the program should be designed/operate.)

OK, and neither were mine - except as illustration. And I think FH is gradually throwing off an over-adherence to "core GEDCOM", adding "legal" extensions when it improves functionality (Places, Witnesses), better support for features in other programs (Research Notes), and doubtless other things I haven't noticed.

Not complete, but a starter for 10 (drafted for a slightly different purpose, so it focuses on a particular way of working):

Super tool, super effort. Hope they chain you to the desk until it's finished and you donate it to the FH documentation (don't answer that).

Loved the exchange, thanks, and maybe you agree it's time to focus better on more important things? Be kind to ourselves and everyone else, Let peace Reign.

As a parting request to someone who's been there, done that, could you advise how I can DM or quietly tag Jane? We haven't got a bug here, it's a design choice perhaps eligible for Calico attention, so I'm thinking to request parking the relevant parts of this thread in a separate topic. And, better still, then send a link to Calico?

[dbnut]

I believe the core FH application is written in C++, so almost certainly heavily OO internal plumbing.

<thumbs up emoti> <thanks emoti>

[ColeValleyGirl]

Asking for a design change belongs on the Wish List, so put a suggested wording in the New Wish List Requests.

[dbnut]

The one anomaly that you have spotted before is Family Facts such as Marriage and Divorce.
Their Owner record is the Family record, so when they change, the Family record Updated changes, but NOT the Parent Individual records.

Not wanting to be provocative or - heaven forbid - start another annoying digression, but... off the cuff:

In my story book, they are "components" of a family group, as are children. In some sense more "senior", of course, but neither is a parent of the family unit. Mother/father/child are alternatively well modelled as having roles in a non-hierarchical relationship/association with the family object abstraction.

In a general case, fathers are optional if we are dealing with a known female and only her offspring, or forbidden if paternal continuity is not proven. If both are present, then marriage (etc) events/properties are automatically equivalent to marriage events shared by two individuals.

My data includes a custom pair of Family attributes dating beginning and end of a "meaningful" family unit from the partners' point of view. Small-scale-useful when it's proved a couple married only after some child was conceived, and when definitive separation occurs before death (which is the natural end of the unit, in the absence of divorce).

Without those properties, marriage & death events can be a misleading guide to the "family lifetime".

As many will have contemplated (including you, I'm certain), the waters get even more muddied when we eventually have to deal with sperm donors, surrogacy, three-in-a-bed, and stuff I haven't thought of, on top of adoption & fostering. Will be interested if I get to see what data models emerge (but probably won't have the faculties to critique).

Written in haste, some of that is probably wrong, but no matter.

I don't particularly want to, or insist on, the last word; but neither invite another long thread. Because I'm not at heart a trouble-maker - just gobby and too excitable.

[davidf]

Very interesting. I suppose your source record does include lots of Notes, and it's a pity we can't (apparently) add custom properties - like Date Last Accessed. And presumably you have Sources for each Census and would gladly exploit multi-level Sources to record your details at the best level.

(I'm still on V6) When I create a source record I generally make a point of adding notes to force me to think about the source.

So "1865 New York State Census (Anc)" has notes "Source Information" and "About New York, U.S., State Census, 1865" - lifted direct from Ancestry - the "(Anc)" in the title. Then I may have additional notes listing any exhaustive searches that I did and when - for instance "Search for all "Williamson" July 2020" with details of specific searches (terms and date) and the number or records returned (sometimes the number of returns will change due to improvements in the data quality).

I may have multiple sources for a Census. e.g.:

• 1851 E&W Census (30 March 1851) (Ancestry)
• 1851 E&W Census (30 March 1851) (FMP)
• 1851 E&W Census (30 March 1851) (Genealogist)

This is partly denormalising the Source-Repository records - but it makes it easier to select. If I know the date, including the date in the Source title makes it easier to enter the date (if not using AS)

I do view them as separate sources because the indices are not as comprehensive as might be thought and sometime pages are missing, so a household might be found in one company's offering but not in another. I subscribe to FMP (price permitting), I use Ancestry when in the Library and buy occasional short subscriptions to The Genealogist.

I have pondered multi-level sources (I think some use source type for this) but I have never found the need pressing. I use source type to indicate matters like; Online part index and Images, Online Part index, Printed Book etc. This helps when I am trying to plan research and want to think about what sources to consult.

The other thing possibly worth mentioning about my approach is that I do not use FH as a means to automatically produce fancy reports or books etc. - when issues of for instance consistency in naming sources would become important. I use FH as a working tool when constructing families and as a repository for information which I consult when manually writing histories.

[dbnut]

Very interesting. I suppose your source record does include lots of Notes, and it's a pity we can't (apparently) add custom properties - like Date Last Accessed. And presumably you have Sources for each Census and would gladly exploit multi-level Sources to record your details at the best level.

(I'm still on V6) When I create a source record I generally make a point of adding notes to force me to think about the source.

So "1865 New York State Census (Anc)" has notes "Source Information" and "About New York, U.S., State Census, 1865" - lifted direct from Ancestry - the "(Anc)" in the title. Then I may have additional notes listing any exhaustive searches that I did and when - for instance "Search for all "Williamson" July 2020" with details of specific searches (terms and date) and the number or records returned (sometimes the number of returns will change due to improvements in the data quality).

I may have multiple sources for a Census. e.g.:

• 1851 E&W Census (30 March 1851) (Ancestry)
• 1851 E&W Census (30 March 1851) (FMP)
• 1851 E&W Census (30 March 1851) (Genealogist)

This is partly denormalising the Source-Repository records - but it makes it easier to select. If I know the date, including the date in the Source title makes it easier to enter the date (if not using AS)

I do view them as separate sources because the indices are not as comprehensive as might be thought and sometime pages are missing, so a household might be found in one company's offering but not in another. I subscribe to FMP (price permitting), I use Ancestry when in the Library and buy occasional short subscriptions to The Genealogist.

I have pondered multi-level sources (I think some use source type for this) but I have never found the need pressing. I use source type to indicate matters like; Online part index and Images, Online Part index, Printed Book etc. This helps when I am trying to plan research and want to think about what sources to consult.

The other thing possibly worth mentioning about my approach is that I do not use FH as a means to automatically produce fancy reports or books etc. - when issues of for instance consistency in naming sources would become important. I use FH as a working tool when constructing families and as a repository for information which I consult when manually writing histories.

Wow, didn't look for that change of direction! And didn't want to get drawn in again. Or bore the pants off everyone else. But passion conquers all, so:

You are annoyingly organised (more rigorous/thorough and typical (probably), compared with mine), and such a clear justification. Tracking included.

[While agreeing wholeheartedly about the completeness/indexing "thing", this is sometimes down to transcription errors. I'm determined (whenever possible/practical/justified) to judge "original" images for myself, record my own reading, report it if allowed, and generally ignore "dissenting" opinion on that site.]

[My source types are as generic as possible, but roll on the day when we could have multiple classification there. And, what are maybe closely related: explicit recording of "Collection" within (mainly) AGGREGATOR sources (that include fh societies); as well as "format consulted" (to include "transcription".]

["fancy reports or books etc.": ditto, but there's my own OCD and sanity to look out for.]

In the early days I did use broad sources like Ancestry, FMP, as it was clear from the context what category of record was involved and of course the "Where": what I used to store the "primary" "source locator".

I continued this digression with a lot more comment but wisely (for once) cut it out for other topics where I hope to remember to quote this post! Thinking back, my behaviour has been far too gobby and hijacking. A lot more discipline is needed to avoid getting my knuckles rapped or being banned.

Signing off, and thanks.