On 16/05/2011 14:55, Ian Goddard wrote: > [email protected] wrote: >> >> I've read thru this thread, and I wonder if there will be any program, >> including your own, that will fullfil all things that have been asked here. >> >> It seems to me that you're after a kind of logging system, rather than a >> genealogy program. But you want to define persons, places, events, >> relations, sources and even dates (and a few more?) as entities and have n:n >> relations (in relational database speech) between all of them, > > If you model data in entity-relational terms most of these things have > to be seen as entities. And in some cases the relationships /are/ n:n. > In an RDBMS implementation a link table is a good way of representing > an n:n relationship and once one start's thinking in such terms it > becomes clear that such a table can hold more than just link information > which is why relationships start to emerge as entities in their own right. > > If, OTOH, you model data in OO terms you would model them as objects and > provide classes for them. And again in such a model some of the > inter-class associations are again n:n. > > "even dates"? Historical dates are a real problem. Are we talking > Gregorian or Julian? What's the start of the year, January 1 or Lady > day? What year is 3 Elizabeth? How do "Early nineteenth century", 1820 > and "First quarter nineteenth century" collate - a problem which has put > me off trying to devise a historical date data type for my favourite > RDBMS. At least the OO approach enables you to make some of this > explicit by providing such attributes to dates - I don't know if your > favoured genealogy program does this but Gramps certainly does. > >> including recursive relationships on all of them. > > Not all. However if you think about some of the > entities/objects/whatever you want to call them, they have an internal > structure which is hierarchical and the hierarchy differs from one > instance to the next. For instance one record might come from the > parish register of Dunny-on-the-Wold which is in the Dunshire archives. > Another might be in a book of parish register transcriptions which was > published in 1900 by the records section of the Wolds Archaeological > Society. Another might be a page reference of one of several books by > an author which is one of many books published by a publisher. Another > may be a paper in a journal.... You get the picture. They're all > similar in nature and different in detail and even in depth. And parts > of any hierarchy might be re-used - different pages from the same book, > different books by the same author, etc. And a good way of dealing with > this is to use a recursive model. That means that you don't have to > keep lots of copies of the title of the archive etc. It also means that > you can have the option of linking the PR directly to the archive but > another document to a particular collection which has its own distinct > identity within the archive. > >> So, is there then any real structure in the data?? Only in the way, as an >> example, that a date cannot appear in the place of a link where one would >> expect a person reference. But other than that? > > Yes, of course there's structure. It just makes a lot of sense to use a > data model flexible enough to fit the actual data rather than force fit > the data onto a preconceived model. For instance I know of no ancestor > of mine who lived in a city. Why should I have to warp their data to > re-use a "city" field as something else& then how does this warped data > sit properly alongside that of some of my wife's ancestors who did live > in a city? > >> >> Can such program be built? Yes, but the degree of freedom you want assures >> you to frequent (and some substantial) changes to be applied. And changing >> the program is one thing, but assuring your data survive those changes is >> another story, where ultimate care will be needed. > > Nope. You end up having to make such changes because you didn't think > it through in the first place. If you plan for flexibility you can code > for it. > [lengthy Example snipped] > > %>< > >> There has been discussions about hierarchy of places. I think trying to >> register such things is a bad idea in the first place, because such >> "relationships" have been so volatile in history. The only indication one >> could give that would remain consistent is something like : place X is part >> of (located nearby, ....) Y in 2011. Even geographical coordinates are no >> good, since villages etc. have moved in the run of time. >> > > By now it should be clear how to treat this. You recognise /in advance/ > that the hierarchies will be time-dependent and make provision for > optional start and finish dates. You also recognise that a particular > place may be simultaneously in different hierarchies, e.g. > ecclesiastical (even different ecclesiastical hierarchies, such as > different Anglican& RC parishes), manorial, Poor Law. You adopt a data > model that fits and then code to that. > > > I can envisage a system with several aspects: > > - The genealogical data itself. > > - Standing data such as location information. > > - Rules such as the fuzzy logic which Richard mentioned. > > - A shared data model to describe the above. > > - Code to handle them. > > > This leaves scope for different S/W vendors and open source teams to > provide the last part. It also provides scope for specialists to > provide shared standing data or shared rules. It even, in an ideal > world, provides scope for archive sites such as A2A to export data in a > useable form. And it provides scope for users such as you and I to > explore that data and to find the family relationships which hide within it. > I didn't intend to comment on this thread because my project is at a very early stage, there's no functional program yet but there is code and the beginnings of a practical (I hope) database design at thefamilypack.org - but that was such an actuate description of what I am trying to achieve that I feel obliged to point it out. In particular, you mention standing data; I think this is an area where open source collaborative efforts can really be made to work. I'm sure that anyone who has spent a few years on their family tree will have become expert on some small areas of local history and geography, if there was a simple way to contribute that expertise, without commercial interests taking advantage, then I'm sure it would happen. FreeBMD and friends are a good example of what can be done. Unfortunately this will be the last piece in what has become a very large jigsaw in designing such a system - but a lest it is being thought about at the beginning of the process. If anyone does go to the trouble of looking it up - I should point out the the database design only includes the minimum necessary for the program code that is being written. So if you have a question starting "Why doesn't the database include ...." the answer is almost certainly "No, not yet, but ...". Nick.