Looking (too far?) Ahead

2004-09-02
2013-04-03
  • Nick Charsley
    Nick Charsley
    2004-09-02

    As I approach this project not being a 'pure' genealogist I thought I would put the following forward for consideration.

    Being a House/Local Historian, I am interested in many of the things Family Historians are, and also should follow the same rigour of evidence to assertions that the GDM is based on. However People are not the only items that I wish to track through time. In fact I need to treat Houses in pretty much the same way the I treat People.

    One small extension of what exists currently would allow this and possibly other future enhancements to be easily inserted.

    If we look logically at the make up of the Subject table we have three distinct types of entity stored in it.
    1)    Singular Items (Persona)
    2)    Groups of Singular Items (Group)
    3)    Events.

    The last two have an associated type, if the idea of type was extended to Persona, then the project would gain another level of flexibility, with very little extra work.

    It could be argued that I should be using the Place construct to track this, but unless I've got the wrong end of the stick It's not that easy to group places based on assertions and evidence!

    I'm interested in other peoples views on this, as at this stage as we aproach the end of the planing stages change is not expensive.

     
    • Ed Ridpath
      Ed Ridpath
      2004-09-03

      Well, this certainly got me thinking.  I have to confess to not know what "House History" is.  Is it tracking landmarks and historical homes - ie old real estate? 

      And I think what you are saying can apply to all "places" - that we should be able to make prove assertions (things like Prussia = parts of Germany, or the city of New Amsterdam = New York, etc.).  I can see many cases where genealogically, we consult old gazetters, track city and county histories, even national borders move around quite often.

      The more I elaborate, I think the more I would lean towards a very good "place" history/genealogy tracking capability, since it would cover a much more generic issues with places.  I would not like to see us fudging the person/persona - we will have enough filters and processing to do without the extra step of segregating artificial "types" of people that are really places.  This is also assuming I understand what you are looking for - and place "expert" and management is an important part of GeneaPro - we have a whole subproject dedicated to figuring that all out.

       
    • Tom Morris
      Tom Morris
      2004-09-03

      I'd be interested in hearing more about what types of information a 'house historian' collects, how they'd like it organized, how they'd want to retrieve it and report on it, what records they search to find it, etc, etc.

      Personally I think the genealogy problem is big enough initially with without adding to it, but having said that, there are many needs of genealogists which I suspect overlap with those of a house historian.  Land records are an important source of genealogical information.  The 'farm' in some Scandinavian cultures is a key social grouping for genealogy.  And so on...

      Historically, genealogy programs have only considered people as first class objects (and perhaps families).  Places might be nothing more than a string representing its name, perhaps with a little structure added by commas.  More recently programs have started to add more structure and capabilities, but the functionality for operating on places still greatly lacks that for people.

      Tom

       
    • Tom Morris
      Tom Morris
      2004-09-03

      Oops, forgot to mention that the reason I made the subject Use Cases is that they are something that we could use more of in general, even for main line genealogy tasks.

      These could come in lots of flavors at all levels of detail from "work like TMG for the <foo> task" to detailed process description.  Now's the time to go wild with the imagination, not later.  It's much easier to provide the framework to enable a future feature upfront than it is to go back and retrofit.

      Should a future post-GEDCOM version of Rootsweb's WorldConnect be possible to build on GeneaPro?  Well, then it'll need a web interface as well as some scalability.  Perhaps that'll never be needed though and instead what people really want is superb PDA synchronization capabilities or ....

      The point isn't to prioritize them now, but rather to make sure that they're all collected.

      Tom

       
      • Nick Charsley
        Nick Charsley
        2004-09-03

        I can't of course talk for all house historians, but my take on it is as follows.

        House History usually stems from moving into an old house and wondering when it was built, and how the environment around it has developed. This happened to me when I moved into our current house which was built sometime between 1600 and 1800.

        The records that a house historian will use are probably a sub-set of those a Family Historian would use. So far I have various Censuses, Licensing Returns and Valuation Lists. The reason for seeing the parallel with the Persona Element is that (especially in villages) House Numbers just didn't exist until sometime in the 20thC, and so on each of the 5 Census and 6 Valuations I have various characteristics (number of rooms, estimated annual rent etc) for 30 Houses that need to be  rolled up into their singular entity. At the same time I'm also tracking the inhabitants of the Houses (in the 'normal' way a Family Historian would). To my understanding this is why a House is different to a Place and similar to a Persona. The GDM considers a place to be WHERE an event happened, where as a Person is something that an event happened TO or Characteristics describe.. Although it may appear that A Census didn't happen to a house, a Valuation definitely did, and the characteristics of a house recorded on the Census definitely belong to it.

        One suggestion would be 'Why not just enter the House as a Persona?, after all with the ability to create new characteristics We can just define "Built" instead of Birth, 'extended' or 'altered' instead of Married and 'Demolished' if the inevitable happens'. The quick and glib answer is a House is not a Persona and never will be. The more complex answer is that a House could be treated as a Persona for 80% of operations, but I for see some times when it would need to be excluded. i.e. you wouldn't want a House to appear in your list of Individuals with out Gender, or Birth Dates, etc.

        I am not asking that the design provide House History features from day one, Indeed I would perceive them very much as a separate plug-in, but if it were to be feasible to provide this kind of functionality then I think the foundations need to be correct, and that means someway of differentiating between 'Persona' Types.

        I'm sorry that this is such a long e-mail, but this is a great opportunity to include a growing minority of researchers, who are probably forcing Houses into Genealogy Software and then wondering how to Marry them to the people who lived in them (and how to stop the House Dying after 120 years:)

        Nick (c)

         
    • Ed Ridpath
      Ed Ridpath
      2004-09-04

      Nick,

      Thanks for the education on house history.  I do beleive that the GDM can be extended to support the idea of "place" genealogy (a house is just a unit of a place) - the key being that all the data items of the GDM are available, specifically sources, citations, researchers, people, etc.  Adding a place sub-system that shares much of the logic and design of the GDM - ie assertions, groups, roles should be possible.

      I do feel strongly that the place sub-system has to be separate - I think the idea of a "persona" record as just a "thing" ie person or place or rock collection is not the intent of the GDM design. 

      But that doesn't mean the ideas and even requirements of a robust and thourough place system won't do all that is needed for a house (or city, region,country) historian.  I guess I would challenge us to create a place subsytem that ties into the GDM, but could standalone if a user's only interest was place history.

       
    • Nick Charsley
      Nick Charsley
      2004-09-09

      Interestingly (or maybe not:) the GDM hints at the way a Place Expert may treat Places (C.2  PLACE NAME EXPERT SYSTEM).

      "It may be useful to think of places as having genealogies of their own, with multiple parents, a birth or creation date, and a death or dissolution date."

      I think it was this that first made me think that Places were the same as Persona. As well as the method above another solution to this would be to add another table to the original GDM (a copy of the Persona Table), this of course would then migrate across in to the GeneaPro schema as using the Subject table with possibly an stype of 'H'. Again my desire here is not to ensure that this has been built in to the first version, but that nothing we do prevents us from doing this when we get to the point of extending it.

      Nick (c)

       
      • Ed Ridpath
        Ed Ridpath
        2004-09-09

        Nick,

        I agree that a place expert done right will look like a mini (or not so mini) genealogy.  But places are different than people and should be modeled on their own atributes.  Places do not have parents - they may be contained in other places, or created from the breaking up or merging of other places.  They have borders, coordinates, and other attributes people do not have.  I think it would end up doing a dis-service to both the people genealogy and the place "genealogy" to try too hard to model them identically. 

        Where there are exact matches, however, such as the entire Administrative and Evidence section of the GDM, we should be able to accomodate any type of historical research.  Adding a Place Genealogy conclusional model that might look like the GDM Conclusional model only geared towards Place data might be a good answer.

        In looking closly at where Place data is in the GDM, moving that place data to "Subject" table  introduces severe changes to the GDM and even to the Subj1/value/Subj2 general statement model - we would be forced to either a Subj1/value/Subj2/place value/Subj3(Place)  general statement OR going to complex groupings with 3 statements where 1 is used in the GDM:  Subj1/value/Group1 Event/value/Group1 Place/value/Group1 in order to track the place an event happened.  I think this might be the technical deal breaker unless a less cumbersome solution could be found.

        Either way, I think we will have an excellent platform for managing place data and hosting a superior place expert system.

         
    • Tom Chatt
      Tom Chatt
      2004-09-27

      Greetings from an interloper who just stumbled onto this very interesting discussion.

      One observation from the point of view of house history: some of the responders to Nick are confusing a house with a place. A house, to my mind, is certainly much more like a PERSONA than it is like a PLACE. One would make assertions about a house, connecting it to EVENTs (construction, remodel, electrification, demolition, relocation), CHARACTERISTICs, and GROUPs; each supported by evidentiary SOURCEs. Just as with a person, a house through its "lifetime" may have a variety of names. It will also help break the confusion between a house and a place to realize that sometimes houses move from one place to another. (The part of Los Angeles I live in has many houses greater than 100 years old, and a number of them have been moved from their original locations. In the early part of the 20th century, at least in this area, various economic factors made it sometimes more reasonable to buy an existing house and move it than to build a new house from scratch.)

      I don't actually see anything inherent in the GenTech model per se that should prevent PERSONA from being completely useable for houses. Indeed, that may be an interesting test. The only problems that Nick anticipates arise from various culturally embedded assumptions that tend to become data constraints in genealogy software implementations: eg that every person has exactly two parents, that every marriage unites one male and one female, that every person dies within 120 years.

      One of the things I find intriguing about the GDM is that it has done a great job of avoiding any such cultural assumptions. Whereas GEDCOM defines a "FamilyRec" as having exactly 1 husbandfather, 1 wifemother, and zero or more children, GDM leaves open how PERSONAs are arranged into GROUPs. This limtation in GEDCOM is somewhat surprising coming from the Mormons, many of whom will have polygamists in their family history. Polygamy can be shoe-horned into GEDCOM with multiple concurrent overlapping FamilyRecs (if the software even allows you to do that), but it gets awkward. Even more boggling are trying to capture some of the relationships being created today, such as: "John marries David, Amy marries Gretchen, and the four of them are co-parenting Benjamin (the biological son of John and Amy) and Grace (the biological daughter of David and Gretchen)". Just try putting that into GEDCOM! I see GDM as being much more amenable to the vast variety of relationships that people over various times and cultures have constructed or will construct. And I'm hoping that implementations of GDM avoid building those cultural assumptions back in.

      If PERSONA can truly capture the dazzling variety of relationships where human persons are the subject, it ought to be able to serve for ASSERTIONs where a house is the subject.

      Just my $.02, for what it's worth.

       
      • Ed Ridpath
        Ed Ridpath
        2004-09-28

        OK, I have to say this,  we have People (genealogy), Places (History) and now Things (movable houses)  - I think we have every noun covered :)

        Seriously, this just expands the scope too much for this already ambitious project - tracking moving architecture (the London Bridge, anyone?) while similiar to genealogy, I think would be biting off more than we can chew.  However, the beauty of open source is that at somepoint the code generated here could be either added to via plugin, or wholesale rearranged for places and objects.  And since we are all now aware of the requests, we will certainly keep our eye out for directions that may enhance or at least not limit this type of use.

        Ed