And the choice of DB begs the Q, table vs relational? My old php/perl site used SQL populated by perl-gedcom from my windows software.
But genealogy is by nature relational. On Thu, Aug 4, 2011 at 2:03 PM, william scheding <w...@wls.org> wrote: > > All, > > I would suggest MySQL for the database. It runs on everything and is free. > > wls > > On Aug 4, 2011, at 1:44 PM, Mikkel Eide Eriksen wrote: > >> 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. >>> >> >> >> > >
