Tie in Family module with the Event and Calendar modules.

I know I haven't been active in developing this module myself for the past long while but I feel that I need to get working on it again. I agree that we need to make location a node. I have started looking at how to do that as well as integrating the location.module and gmap.module so I can plot locations with GoogleMaps which would require locations to have node status. I also think that a "sources" node also needs to be done. Considering anything we want to integrate with the location module would probably require a node or should we try to use/manipulate them using only the relationships schema? I can post another task for this if need be.

Seth,
Explain a bit more what you mean specifically by a "sources" node.
Thanks,
Jonathan

Warning: This post transforms from an explanation at the beginning to more of a thought experiment for the remainder. Proceed with caution and criticism. Everything is subject to discussion and change (in fact, I hope it does).

I can't seem to find a pdf copy of the GEDCOM 5.5 spec and my own copy is at home so I will try to explain from the top of my head.

I approach this module to support two activities: sharing family stories & media and also to share/coordinate family history research. Research requires citations from source documents (both primary and secondary) such as census data, family history books, grave stones, etc. GEDCOM Facts and sources have a many to many relationship (a fact supported by multiple sources and many facts derived from a single source). Also included in the GEDCOM spec are Repositories. I think these may also be many to many but could also just be a one (Repository) to many (sources).

So, my question is whether or not a source needs to be a node. We could implement this to run exclusively from the facts/relationships tables which seems like the best idea to me at the moment. So I guess that invalidates my earlier statement about making sources nodes.

Repositories, on the other hand do make sense as nodes. Why? Because for many repositories there is a location associated with it and from what I understand the location module is designed to work with nodes. So, if something is likely to be a place (location) it ought to have the ability to interact with the location node (requiring it to be a node). Of course, many FACTS are places (e.g. Birth place, death place) but are not nodes, or do we want to link these place facts to location nodes? Perhaps I need to go read the location module api before I pursue this train of thought anymore.

Does any of this make sense?

Oops, I just changed the title for the entire issue, I hope I changed it back correctly.

Ok. I just looked over the GEDCOM 5.5.1 spec again. Location data in the form of a PLAC fact, including Lat & Lon data (in decimal degrees), can be associated with the Header, all events, and sources, but oddly enough and counter to my assumptions not repositories (which have a separate address field but no Lat & Lon). The problem with this is that it generates a large amount of redundant data. You need to re-enter the latitude and longitude for every time you say an event occurred in a single place. I suppose we can simply abandon the GEDCOM model and allow pointing to the same PLAC fact. We would just have to remember this when importing (to search for matching places to reduce redundancy on the fly?) and while exporting (by writing out the redundancies in their proper place).

This still leaves us open to the question of a PLAC node for location.module integration, but I am finding that leaving it a relation might work just fine for my additional purpose of integrating GoogleMaps. I suppose for the time being I can start by just creating viewing scripts to display pure fact table PLAC data and then we can integrate it with nodes later if we need to. However, I think we need some consensus about allowing pointers to independent PLAC facts to replace PLAC facts embedded in events and sources or sticking with current GEDCOM specs. Mind you that the pointers do not exclude the option of making multiple similar PLAC facts, but would allow for unification if desired. Let me know if I should do up some examples.

Seth,
Great write-up. I'm pressed as usual for time, but here are my initial thoughts:

• I feel that the only times we need to be mindful of GEDCOM specs are for importing and exporting. Otherwise I think we should approach this in the way that best suits and works within the Drupal architecture.
• I think that just about all of the types of facts should be nodes, though having functionality at first without nodes is acceptable. Being new to Drupal still, I'm not one hundred percent certain, but it seems it's easier to integrate nodes with other modules. These are the fact types that I absolutely feel should be nodes: Individual, Event, Location, (and now that you've cleared up what it is) and Source.
• About your point in bold... I agree that having redundant PLAC facts seems a little silly. Pointers instead of redundant embedded facts makes sense to me. Run it by PFOLK for total consensus.

On a slightly unrelated note, attaching images to Family records would be a bonus. I think the IMAGE ATTACH module handles this quite well, but we would need to redesign the index view to pretty it up some.
One another slightly unrelated note, Windows CVS clients are kicking my butt and making it difficult for me to commit a new branch to FAMILY. Let me know if you know of any good tutorials for using WinCVS or TortoiseCVS. I've read a couple of tutorials, but am getting unexpected results.
Thanks
Jonathan

I touch on comments made by pyutaros and talk about a few related items in a new task for sources.

As I mention in the other task post I feel the most comfortable in sticking with the GEDCOM specs in part because it means we can focus more on needed alterations to the spec rather than creating a whole new one. Besides, we are already heavily relying on their structure for the current system anyway. I think that PLAC is one of those obvious alterations we need to make (subject to discussion and consensus). Partly because the source (SOUR) fact structure already employs a linked architecture we could apply to PLAC.

I completely agree about the need to allow attaching/embedding images. It was partly the promise of moving that direction which made me want to starting working on this project in the first place. I figure it will come, but we need to get the core of the module much stronger before I will divert my energy that direction.

I've had a chance now to check out the event module. It appears there are severe limitations on how far back dates can go in the current version (i.e. Unix Epoch). The 5.2 version should have removed these limitations. Postponing until release of Event 5.2.