First off, I’ve been reading the GENTECH Data Model spec. I read it years ago, when I was working at Ancestry, but time erases a lot of details. :) Anyway, it’s interesting food for thought. I don’t think I’ll end up adopting it (at least not wholesale), but it does have a lot of good ideas. I like the idea of being able to associate dates and places with characteristics (so you can say, “John Smith was a farmer from 1730 to August 1749 in Hartford, Connecticut”).

OpenID caught my interest today, primarily because of the easy sign-in capability. I’m still not entirely sure how it works, or if it’s even desirable for Beyond (genealogy may be a touchy area as far as that goes), but it’s definitely an option. I do plan on having MicroIDs implanted in the header of user’s pages, which’ll make it easy to use claimID to say “This is my genealogy.”

Coding-wise, I took some Ruby code to convert GEDCOM to XML and started writing some classes which convert the XML to Ruby objects. (Eventually the XML will disappear, of course; this is just a temporary hack to get some data to work with.) Once that’s done, I’ll write code to import the Ruby objects into the database, and then it won’t take long before the prototype goes live.

Speaking of the database, I’m almost done drafting the data model (and GENTECH is influencing a few things here and there). One issue I came up with a tentative solution for is that of sources. Ideally, you should be able to add a source to any bit of data that could reasonably have a source. So, to that end, I think the Sources table is going to be open-ended — instead of having a set list of types, there’ll be an “object_id” field and an “object_table” field, which means I can add a source to anything that shows up in a table.

But that’s still not enough, at least not yet. For example, events will include fields for the date and the place, preventing a source from being added specifically for the date (or the place), and instead forcing it to be added for the event as a whole. Hmm. The idea of being able to source everything is really nice, but is it feasible without turning the database into a mess?

One last thing. For storing information about individuals, I’m thinking about using a similarly flexible system: everything gets stored as a key/value pair. So instead of having set fields, you’d just add a “first_name” key and fill in the value. If there’s no middle name, you don’t have to add a middle name. The advantage is that you don’t have to use fields you don’t need, and you can use other fields that you do need (and that I’ve never heard of). The disadvantage comes in displaying the information and ordering it into groups. But maybe I could include a groups table, so you could put all the name information and gender and birth/death information into a “Vitals” group (or whatever you want to call it). Hmm… I’m considering the possibility of using templates to make this kind of thing easier for newbies — a scaffolding with common keys already in place for you to use.

End brain dump. :)

Posted in Design, Development
Comment feed for this post