Re: Wiki software for genealogy (long)

'Bob - remove cap to reply' (Bob) wrote:

On Sat, 9 Aug 200, "Tony Proctor"
<tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
..

However, I'd stress that I'm

currently looking at the way the data is organised internally, and the paradigm by which it is accessed. What types of reports, displays, or analyses than can be generated from such a data source is up to the desktop genealogical programs rather than the underlying database, i.e. there's still room for a competitive edge for the vendors, and for cheaper-and-easier versus expensive-and-powerful differentiations. However, the data engine could become a tried-and-tested generic commodity that's applicable to several fields. Representation of genealogical data would just be one of many possible "schemas"


Some thoughts about this approach -
1) a genuine model is not static and should work over different dimensions.
The approach to slicing up the data is dependant on the way you want to
produce output. A static (or slowly-changing dimension) such as family
relationships suggests a relationally-linked or tagged approach. But more
rapidly changing dimensions (such as time or place) suggest another. Then
you have the requirements to match data (such as dates, multiple name
choices, geography, DNA, or look-alikes) and a method to deal with fuzzy or
probablistic data (am I "sure" about this relationship or is it on "balance
of probalities" or conjecture?)

2) "Storing" the data over time - much data is fragmented across different
sources, media types, access and across different researchers, so trying to
link it all in one big monolith is ultimately a lousy idea. New sources
appear and other researchers emerge to become the "specialist" in parts of
"your" database. Might it be better if you can open up part of your
database in a federated manner to reference part of someone else's that
they maintain elsewhere?

And don't forget the "worse is better" syndrome; getting the model right
will require complex software. Yet by chosing a cheaper, simple approach
using the lowest common demoninator with a weaker data model (such as a
GEDfile that only holds the bare minumum of data) then anyone can claim to
be a "open" software package. Thus a better data model not only has to
perform as well as the current slew of offereings, but also has to offer
something compelling, above and beyond the norm, for it to be successful.

Not easy to get something compelling. Perhaps the DNA market is the
stronger market to appeal to?

Bob


Yeah. "Good enough for what it's for and fully-functional today" beats "When we've ironed out the bugs, this will be the one everyone wants" hands-down over any given 5-year plan of business.

Not to mention, current genealogy programs do one thing well, whether it's lineages or events. You can kludge most of 'em into doing the other, and you can even browbeat 'em into doing a migration database, but they won't do 'em as well as a dedicated program will.

Then you get the Hardware/OS improvement problem. If you can visualize how a hardware engineer will improve the hardware, or how a software engineer will create a new OS for the new hardware, you're probably not writing programs.

I don't believe in the one-program-suits-all-purposes, any more than I believe that a single screwdriver will solve all my carpentry needs (or that I need only one saucepan).

Cheryl
.

Relevant Pages

  • Re: Wiki software for genealogy (long)
    ... desktop genealogical programs rather than the underlying database, ... how a hardware engineer will improve the hardware, ... Even if you had to copy such a database from one data engine to another ...
    (soc.genealogy.britain)
  • Re: 3vl 2vl and NULL
    ... reporting, MV end-users were either churning out reports and ad hoc ... MV-database-independent applications as often as they do in the SQL ... where I cannot leave MV behind unless I can find a better data model. ... screen to be identical to the logical data model of the database. ...
    (comp.databases.theory)
  • Re: Value ...
    ... I actually use Pick-Like ... > quicker than others because my data model is better. ... What i need is the posibility to use any of them with my database. ... hey Uncle Bossman can even swipe his mouse and import it into Excel!!! ...
    (comp.databases.pick)
  • some ideas about db rheory
    ... The database records not only the ... What I have done is a data model, in which time is not in a “record ... Above mentioned technical solutions can have troubles in real world ... identifier of a state. ...
    (comp.databases.theory)
  • Re: reactivation when nothing changed
    ... IF Microsoft's hardware database for each PC were coded ... Now take out the pencil and have that someone record again what is in the pencil cup. ... You think Microsoft should record everything that was ever installed and allow you to remove and add the same devices without tracking those changes? ...
    (microsoft.public.windowsxp.general)