"singhals" wrote: > Lor' God Almighty. If the current one-size-fits-all approach > isn't working there's no rational cause to believe any other > one-size-fits-all approach (including yours) will work better. The whole point of this thread is that I don't believe a one-size-fits- all approach is a good one at all. That's why, for example, I want a rules engine with a configurable set of fuzzy rules instead of hard- coded cultural norms. The example Ian Goddard quoted earlier about places is particularly apt. For those of us not based in the US, places simply don't fit into the neat city-county-state hierarchy that the US has, and that a number of existing programs assume. In England, parish-county is often a better hierarchy, but I'm not advocating that either. What I want is the ability to say that in the English branch of my family, a particular place name hierarchy should be used, while, say, the German branch should use something different. It may take longer to set up, but the result is more far powerful. > ANY approach works better for some folks than for others. > NO approach works best for everyone. I agree with those two points. > ALL approaches work for some. But I don't agree with that. Just because a program allows someone to rapidly amass a collection of names and set it out as a family tree doesn't mean it's working. You only need to look at some of the garbage in some of, say, Ancestry.com's trees to see that there's a lot of so-called research out there that's patently wrong. The way that GEDCOM doesn't adequately support sourcing of data does everyone a disservice, as do programs that base their data models too heavily on GEDCOM. Similarly for programs that make it hard to accurately enter source information (again, as many GEDCOM-based programs do). > Far's I can tell, most genealogy programs allow you to say > what country you're in and none of 30 or so I've used or > seen demonstrated prohibit the addition of OS/NS as > appropriate. But quite a lot can't *default* to something sensible. There are plenty of programs that simply cannot be configured so that 1 Jan 1720 is *by default* treated as a date in the Julian calendar -- i.e. that it is a Friday rather than a Monday -- and that it is the day after 31 Dec 1720. Certainly most programs allow you to specify this, but many do not allow this to be a default. Unless it has been changed very recently, Gramps is an example of such a program. In Gramps, if I enter "1720-01-01 (Julian,Mar25)", it will do the right thing, but so far as I'm aware, it cannot be made to do the right thing if I simply enter "1720-01-01". And Gramps is not the only program I've used that has this problem. > > I'm far more interested in using (and if necessary, writing) a program > > that's flexible enough to cope with the subtleties and ambiguities > > that crop up in real life, than something that's easy to use and has a > > pretty interface. (That said, I don't necessarily see these as > > Of you think I prefer pretty over functional, you're sadly > mistaken. If you're wanting to change globally the > background color or your font color, go for it and God > Bless. If you're proposing to permit font, font style > and/or font color changes INDIVIDUALLY within a single > database -- how can I help? Why on earth are you talking about font colours? Who even mentioned fonts or colours? Compromising flexibility for a pretty user interface is a common problem. Take a look at any word processor to see it in action. They're acceptable if you want to write a letter, or even a privately published pamphlet. But few, if any, professionally publishing houses would use a word processor to lay out books. In the scientific community, a piece of software called TeX (or more commonly these days, LaTeX or XeTeX) is used instead of word processor. It's vastly more flexible and powerful, and allows much better consistency and conferability than a word processor does. And it's interface makes it *far* less easy to use -- it doesn't even have a graphical user interface, for example. You see similar problems with genealogy programs. There was a discussion on this newsgroup around a year ago about software coping with an individual with two possible sets of parents. Although some software can handle this, most cannot. And one commonly given reason for this is that there's no clean way of displaying it in a pedigree view. That's almost a text-book example of where the desire for a pretty interface is allowed to adversely influence the data model. > But, IME, subtleties and ambiguities are not susceptible to > automated analysis with any reliability, because sure as > check the very next after you end testing will FUBAR and > bite you on the sit-upon. Again, you're missing the point. It may or may not be possible to analyse complex cases, and the results will certainly need human checking. But that's not the point. The point is that the information should be stored in a computer-readable form. Suppose I have an individual that I'm interested: let's call him John Smith. I've found two possible baptisms for him. I'm fairly confident he must be either the son of Henry and Sarah or of George and Mary, but I don't know which. Now suppose some time later I'm researching another family in that area and I discover quite unambiguously that John, the son of George and Mary, emigrated to Argentina and died childless out there. I enter that in my program, but I've forgotten that I had previously been interested in these families. I want my program to notice that the original ambiguity can be resolved. Maybe it won't do it automatically -- it's probably best if it doesn't -- but it should, at least, draw my attention to it. > > contradictory goals.) If I'm going to spend thousands of hours using > > the software to organise my research, I certainly don't begrudge a > > extra quarter-hour configuring it so that it's right for me. You're > > right that not everyone will agree, but it's unlikely that an event- > > oriented genealogy program, as opposed to the many existing lineage- > > oriented ones, will appeal to them anyway. > > Perhaps I've not yet had my weekly allotment of caffeine, > but it seems to me you keep changing what you want to do. > First you're wanting to write a program that's "better" than > what's available. Then when we point out that "better" is > fairly subjective, you say you're looking only to customize > YOUR database and revert to writing code. I don't think I've made any substantive changes to what I'm intending to do. Whether I write a program, modify someone else's code, or use an existing program as-is is largely irrelevant. I'm not looking to make work for myself, but I do need a program that matches the three requirements set out in my very first email. That hasn't changed. If I write a program, it'll be open source, and if I modify an existing one, then of necessity it will be. I would hope the program might appeal to others too, but that's not a primary goal. If others don't want to use it, then I care only because it's likely to be symptomatic of bad design decisions that will adversely affect me too at some stage. I've no idea what you think "looking to customize [my] database and revert to writing code" means, other than writing a program, and in any case, I didn't use phrases like those. > Commercial computer programs are written to prevent novices > and children from doing irreparable damage to the facts and > getting the developer sued; they are rarely written for the > purpose of facilitating experimentation by advanced users, > because there is no way to ensure that ONLY advanced users > use the product. That's true of some products, but it's certainly not true of all. The Unix ethos, which has largely been inherited by Linux, does not generally prevent people doing irreparable damage. It's a completely different mindset. The Unix philosophy is to give people powerful tools and expect them to learn to use them properly. If they don't, then it's not the developer's fault if they break something. Sometimes that philosophy can go too far, but generally not. In any case, the idea of the developer getting sued is laughable. Invariably all such liability is disclaimed. > >> Worse, in some cases, families > >> combine cultures, norms, religions ... few would want a > >> program that forces them to use a different program or > >> dataset for each branch of the family. > > > A good point, but one that I think can be solved easily enough. The > > Gentech data model supports dividing your research into separate > > projects. Although they were seemingly designed for entirely self- > > contained areas of research, what's interesting is that these projects > > do not need to be self contained. It would be easy enough to use them > > as a way of dividing research into separate areas to which different > > settings could be applied. That way I can apply different settings to > > my English, Irish, German and J�rriais ancestors. > > >> More, I'm not sure you can call a rule with enough > >> exceptions to fit a "rule", fuzzy or not, because > >> eventually, fuzzy logic loses its logic. > > > Now you're just arguing about semantics. Would you be happier if I > > used the term "cultural norm" instead of "fuzzy rule"? Whatever you > > No, because I was thinking more of "I before E except ..." > which is a standard "rule" in English and American, but > which has so much verbiage after the 'except' that it is > all-but useless as a 'rule'. [see also, weird vs yield] The rule "'i' before 'e'" works around 90% of the time -- I know because I've just checked all the words in my dictionary. Add the exception "except after 'c'" and it improves quite a bit further. Whilst I think your comparison with English spelling has no validity whatsoever, I personally would welcome a genealogical rule that held well over 90% of the time. > > call them, they're potentially useful. I want my genealogy program to > > draw it to my attention if I have a sixty-year-old woman giving > > birth. Certainly it's not impossible, but it's sufficiently unusual > > that I want alerting to it. > > That's something most genealogy programs can be told to do. > If yours doesn't, try PAF or Legacy or FTM. > > OTOH, if you're wanting an event-based program, try The > Master Genealogist. www.whollygenes.com You evidently haven't read the first email in this thread. Had you done so you would see immediately why I can't use any of these programs. But don't let the facts stand in the way of you expressing your opinion: you certainly haven't done so far. Richard