Can we allow pointers to substructures in 7.1? #328
Replies: 4 comments 3 replies
-
|
I think you can do this (differently) in 7.0 today using extensions, e.g. something like: |
Beta Was this translation helpful? Give feedback.
-
|
An interesting proposal. Change all to That does avoid record proliferation, but it also makes for datasets that cannot be merged without understanding the semantics of the extension, which I am very hesitant to do. If I had to do this I'd rather do it with something that can be merged, like UID, but even that feels like a hack: we have pointers in the spec, with a syntax that allows them anywhere and just one half sentence barring that. I'd prefer to remove that half of that sentence and do this (and other similar ideas, such as the ALIA-like pointers inside events that some applications have) using the existing GEDCOM pointer mechanism. |
Beta Was this translation helpful? Give feedback.
-
|
I have a different approach: Saying this I do not see the example telling us we need pointers to substructures. |
Beta Was this translation helpful? Give feedback.
-
|
This approach (or the version using ALIA instead of merging) is a nice way of handling the uncertainty, but does not capture the dependency between a conclusion (such as the merge action) and the supporting evidence (such as the name and birth date of the persons merged). If a subsequent merge with another INDI @i4@ overrode the name or birth date, substructure pointers allow automatic notification that previous reasoning may no longer apply. |
Beta Was this translation helpful? Give feedback.
-
|
A few other example reasons I want pointers to substructures:
.. and so on. I find myself encountering this desire repeatedly as I work on family history applications. Admittedly, all of these can be solved in other ways. I could make record copies of the pointed-to thing and point the substructures to the records. I could make a _XREF_ID substructure to encode pointers without using pointers. I could use UUIDs to make the _XREF_ID substructure resistant to collisions during file merges. If the decision is "No, 7.x will continue to ban pointers to substructures even in extensions" I can survive. But all of the work-arounds I've found so far involve duplicating information or creating two alternate ways to expressing the same information, which feel like anti-patterns from a software engineering perspective; thus I'd rather just add pointers to substructures. |
Beta Was this translation helpful? Give feedback.
-
|
This topic exposes the bigger issue in that GEDCOM is not normalized very well. If a place can be used in multiple facts and/or substructures it needs to be broken out as a new (and referenced) entity. The same is true for source_citations, events, surnames and probably other structures that are regularly reused. This also brings to mind the talk/suggestions for changes to the level 1 FAMC linkage to include pedigree information about the parents, removing them from the BIRT and ADOP events. Normalization rules would indicate that these need to be linkable records so multiple structures and use the data, rather than having the data in multiple places. This suggests that some of these changes are better held off for GEDCOM v8.0, so that other normalization concepts (a FACT/EVEN Record) can be reviewed. The concept of inner record linkage looks great to reduce redundancy, but from a database design perspective (SQL, Relational) it is not. If we were talking about object oriented databases exclusively then it has more benefits. |
Beta Was this translation helpful? Give feedback.
-
|
These are good points. I'm now leaning toward waiting for 8.0 and rethink how this works at a broader level. |
Beta Was this translation helpful? Give feedback.
-
7.0 prohibits pointers to substructures as follows:
I'd like to see the prohibition on pointers to substructures removed from 7.1. A motivating example follows.
I have an extension that uses pointers to substructures to track the dependencies of reasoning. I use this to document complicated reasoning in cases where names are not enough to identify individuals, with a machine-readable tracking of the dependencies of my reasoning.
For example, I might pick which of two people is the bride in a marrriage based on their age. Given
I'd add a
WIFEstructure with supporting reasoning, like soHowever, this violates the rule that substructures can't have cross-reference identifiers, and thus cannot be pointed to by other structures.
I can work around this by making a record copy of everything I might want to reference (all events, names, dates, places, etc)
but that results in a large amount of duplicated data and a much more complicated set of extension structure types. I could also just remove the
_SUPPORTstructure altogether, but then I can't have my tool automatically warn me when a change I make invalidates some of my reasoning, nor can I communicate the essence of my reasoning in a machine-readable way.If 7.1 adds support for pointers to substructures, I'll be able to use this extension without violating the standard or creating a few hundred extension types and significant data duplication.
Beta Was this translation helpful? Give feedback.
All reactions