Does anyone know how OCR for old handwriting is coming? Last I heard, it was still pretty far behind, but maybe some advances have been made. But I agree that having a scan of the original document right there is very nice.

I’m particularly interested in the high-res scans. It is ludicrous for people to type information from old documents into their computer when they can scan them with inexpensive hardware and perform human assisted-OCR. You end up with fewer errors, and the actual source can be automatically included in the database with no extra effort. If I disagree with what someone typed in, I can just look at the scan instead of hunting down the actual document.

And yes, I agree that not everyone will want to host their data with the Church. That’s just something that happens with religious organizations. And I also agree that innovation is a lot easier in a smaller group (which is why startups are often successful as opposed to large companies like Microsoft — Paul Graham talks a lot about this).

There will indeed be separation between data and presentation. It’s often a pain when the presentation doesn’t do what you need it to do. (For example, today in the lab where I work, someone wanted to copy the individual list from PAF into Excel. But you can’t do that, or at least not in any easy way. You can’t select the list or do anything except export it into GEDCOM, really. Not good. Locking anyone into using only your program is a bad thing.

Regardless, Beyond as a web application is a great idea. I’ve been mulling over some future scenarios and it seems to me that a centralized solution will not ultimately be scalable. Furthermore, not everyone will trust the Church as a data repository. And of course, as you mention Ben, some simply want to host their data themselves. This offers the additional advantage of flexibility and innovation, which would come much more slowly to a bureaucracy.

I think these reasons are compelling enough to press forward. I would make the obvious recommendation though of a careful separation between data and presentation. Create a solid data source component, along with a useful web-based UI. Don’t worry about the API just yet. When/if anyone wants to write a fat client for it, it won’t be difficult to design a good API. If noone does, at least you’ll have a good architecture.

The CVS repository idea is still important, of course, even using web clients alone, because there’s always the possibility that you and someone else could be working on the data at the same time.

As for Family Tree, even if Beyond ends up being similar (excluding the desktop clients for the time being), I think it’s still worth it to proceed, because innovative ideas are important (like tags, for example). And variety is good. And people may want to host it themselves. Okay, I think I need to come up with better reasons, and it’s starting to sound like I’m repeating myself a lot. :)

Is Family Tree going to be open source, by the way?

I don’t think you could say that the Church expects Family Tree to replace PAF. First of all, their initial incarnation doesn’t have a desktop interface. Nor does it have the ability to export GEDCOM. My understanding is that these things wil be added later. And they’ll probably want other desktop genealogy programs to interface with Family Tree through some kind of sync protocol. But a shared family respository like a CVS repository, where the updates that you make are automatically reflected in my copy the next time I sync, and where the two of us can choose to share data on living as well as dead people, would require more work I think. So it seems you have a good niche with your idea.

BTW, I’ve checked into the various XML GEDCOM specs. Most of them don’t appear to have had any activity in years. GenXML is a the only exception I could find. Developing a parser that can accept the various flavors of GEDCOM out there and output data suitable for XML or database representation is proving to be somewhat of a challenge.

As for compatibility, Beyond will be PAF compatible, and if I can get file format specs for other record managers, it’ll read/write those formats as well. I agree that GEDCOM is rather lossy in some cases, and that’s not good. There are other standards (most based on XML, it seems), and I’ll be evaluating those to see if any would work. Not for storage, that is — it’ll be SQL — but for transfering data. In all reality, though, I doubt that those companies are necessarily going to want to hand out their file format specs. Some may, but certainly not all.

I think that to pull off the synchronization, other collaborators will have to use Beyond, because other record managers won’t have the sync functionality. (If they added it, however, that’d be another question.) My hope is that Beyond will be good enough that everyone will want to switch to it anyway. ;)

I’m not quite sure I understand what you mean by removing offline updates to the pedigree. I do plan on using Ajax to build the web client, and it’ll be quite functional for editing one’s pedigree. (The main difference I see between the offline clients and the web client is that some of the fancier stuff won’t be in the web client, but with advances in technology it may become a moot point.) I want the web client to be as rich as possible. In fact, if this takes off, I see people mainly using the web client instead of the desktop client (like Gmail and the other web-based e-mail clients replacing desktop e-mail clients). And yet there still needs to be offline functionality, because sometimes you go places where there isn’t any Internet access.

Does the Church expect Family Tree to replace PAF? It didn’t seem like that was the case. Hopefully Beyond will be able to interface with Family Tree (and WeRelate, for that matter). We’ll see.