Hi Ron,
I think you have summed this up correctly. Using a UID or UUID and
collecting a stream of them probably does the job. I think that one
subtle point is that given an object identified by a UID it can change
over time as information is added to it. I think version tracking on the
object is a good idea. That would allow you to merge and object at some
version and later deal with updating that object from its source to a
new version.
Overall, it sounds like you have the ideas and it sounds like it could
be a very enabling tool.
Thanks,
-Steve
On 8/6/2011 7:30 PM, Ron Savage wrote:
Hi Steve
On Sat, 2011-08-06 at 11:32 -0400, Stephen Woodbridge wrote:
On 8/6/2011 2:28 AM, Ron Savage wrote:
Hi Steve
On Sat, 2011-08-06 at 00:39 -0400, Stephen Woodbridge wrote:
On 8/5/2011 9:04 PM, Darren Duncan wrote:
Ron Savage wrote:
http://swoodbridge.com/family/Woodbridge/index.php?indi=I2921
I keep all the data in Family Tree Maker, export that to a GEDCOM, then
load it use a Gedcom.pm script into Postgresql database and serve the
pages via php. The photos are integrated by a separate web app that
allows loading, editing and linking them to the genealogy tables in the
database.
I really big requirement is persistent IDs for individuals. I have to be
very careful to not do anything that might renumber them.
Noted.
Is there some specific action with programs we've mentioned which does
renumber them?
Well the obvious one is a renumber command ;), but merging files and
merge individuals some times creates a new individual and then copies
the data from the two merged ones into the new which causes the new one
to be a new number.
OK. This is what I wanted spelled out. Saves me having to make baseless
assumptions :-).
Yes, I see the difficulty. Thinking aloud...
Let's say we try to solve this by giving each INDI a unique # (UID)
besides the # in the INDI statement itself.
Renumbering changes INDI # but not UID.
When combining data from 2 parties, INDI can be set to anything, but we
haven't solved the problem, since the question now is: Which UID is
definitive? A: Neither. We've gained nothing. Right? But read on...
Or is it enough to record a trail of UIDs, so a set of UIDs can be
attached to the final INDI? This allows backtracking from the combined
data to the 2 source data sets (by ignoring the actual value of INDI,
and working off the UID). Would that suffice?
No. See below.
But from a more general point of view and talking about versioning of
data, if 100 people create an INDI record for the same person in
separate research projects and later some of them merge their research
at various points in time it would be nice to know if my INDI includes
one or more of those other INDIs and it might be nice to know at what
version of those INDI(s) got merged into my work.
I think this is just the above, extended such that each assertion about
an individual, not just each individual, owns a set of UIDs. Make sense?
I suppose one way of thinking about this would be like SVN or GIT source
code respository, where files were INDIs or FACTs and there exists a
link like item the connects facts to INDIs or "LINK"s and INDIs to other
INDIs. I'm not suggesting this as a technical design but as a way of
thinking about the problem of revisioning and history.
It might be tempting to use git, but I think not:
o With git (etc) the end result is, for each assertion, 1 definitive
value (after a merge), but with a history managed by git to enable
tracing of where that value came from, i.e. what the alternative values
were at the time(s) of the merge(s).
o My feeling from the discussion so far is that what's wanted is to
carry forward all versions of the assertion, in parallel so to speak.
I really think this means a set of UIDs per assertion, with the UIDs'
purposes being pointers back in time to the multiple sources leading to
the 'current' state.
