Hi Ron, Speaking of genealogy formats, I'm working some on a completely source-based format: http://carthag.github.com/sourcemarkup/ (don't mind the ugly color scheme, it was just a random one I chose).
The idea is to use transcribed sources and mark them up with all info that is contained therein, so as to force all information to be referable to an actual source. From this data, it should be possible to build family trees, data sheets for individuals, etc. It is still very much a work in progress and is just at this point an idea and a very fluid definition of what I want it to be able to do. The site has two unrelated examples, a birth (source1, recored as prose) and a marriage (source2, recorded in a table). Obviously it would be impossible to generate this data from a gedcom file, but it would be possible to (lossily) export from this format to gedcom. Additionally, this might also interest you, I came across it last month: http://bettergedcom.wikispaces.com/ Regards, Mikkel On 04/08/2011, at 21.44, Bob McConnell wrote: > The name GEDCOM2 implies that it will be a superset or evolution of the > existing format. However, due to the lack of standard semantics, the original > is not a sound base to build onto. For that reason, I suggest a new name that > doesn't have those implications. > > Bob McConnell > N2SPP > > Stephen Woodbridge wrote: >> Hi Ron, >> This all sounds very interesting and while I would like better support for >> media, one of my concerns comes from the fact the GEDCOM describes a format >> but not a semantic of how tags should be implemented regarding content. As a >> result, it is very hard to merge GEDCOM data from different products that >> output data to GEDCOM and stuff info in different but potentially legitimate >> TAGs. >> So, I see this project as creating kind of a "super" GEDCOM like database, >> but if the result is that I have to look in more places to find a given >> piece of information than I already have to look in, then this does not >> solve one of the BIGGEST problems of GEDCOM files in my mind. >> Anyway, it will be interesting to see how this develops. >> -Steve >> On 8/4/2011 1:49 AM, Ron Savage wrote: >>> Hi Folks >>> >>> I've been thinking about how to develop our software libraries, and I'm >>> thinking of formally requesting Gedcom2 as the parent namespace. >>> >>> The aim is to support genealogical data first, with the old Gedcom being >>> the most likely way data would be imported into the new db(s). >>> >>> Hence the requirements of g. data support will drive the design, and the >>> Gedcom spec will not, although it does have a lot to offer. >>> >>> Then, Gedcom2 would become the module name and the id to reference any >>> work in this field, and Gedcom2::Gedcom::* would be for modules >>> importing or exporting data in the original Gedcom format. To make >>> things clear, I'll try to always refer to the Perl Gedcom as Gedcom.pm. >>> >>> Also, I have a plan to collect the tags used by the major Open Source >>> and free programs. I've downloaded: >>> o Gedcom >>> o Gramps >>> o Webtrees >>> after getting their names from Wikipedia at >>> http://en.wikipedia.org/wiki/Genealogy_software >>> >>> My idea is to put these tags into an SQLite db, with an indicator of >>> which programs support which tags. Then they can be displayed, in HTML >>> say, with the tags (and explanations) down the left, and program names >>> across, so the intersection could be green (background) perhaps to >>> indicate support. This does not show if the support is just import or >>> just output. Nevertheless, I feel this could be a useful start to >>> Gedcom2. >>> >>> Of course, the tag db will be on CPAN under Gedcom2, so anyone can play >>> with it. >>> >>> I do realize some programs, e.g. Gedcom.pm, don't add tags (at least I >>> don't think it does) over and above Gedcom, they just manipulate what's >>> provided in the data. >>> >>> As I said, I'll do the above-mentioned, and the HTML display part, to >>> get started. >>> >>> So, if you'd like to volunteer to attack a program I haven't mentioned - >>> to extract it's tag list - just co-ordinate with others via this list. >>> >>> Ideally, the code will be incorporated into the Gedcom2 namespace, e.g. >>> as Gedcom2::Gedcom::Import::Tags::Gramps, or some such, so it can be >>> easily re-run against future releases of that other software. Standalone >>> scripts, and the file from the other software which is the input file, >>> would suffice at the start, and we can get more organized later. >>> >>> What do people think of all this? >>> >>> Lastly, I'm also thinking of developing a TiddlyWiki >>> http://tiddlywiki.org/ to record any info, e.g. suggestions for new >>> tags. I'll start off with some ideas from recent posts to this list. >>> >>> I would make it publicly accessible, too, perhaps in the Gedcom2 distro. >>> I'm a great believer in TiddlyWikis... >>> >>> However I could also use http://tiddlyspot.com/ to have an on-line wiki, >>> although then passwords are sent in the clear. >>> >>> Or does anyone have a suggestion about simple but password-protected >>> wikis? And yes, I know there a whole set of them on CPAN. None have yet >>> appealed to me. >
