Re: How about Gedcom2 for a new namespace?

If you need a separate database engine instead of an embedded version, 
you would be much better off going to PostgreSQL. Not only is it free, 
in both senses, it's a more stable engine and actually conforms to 
published SQL standards.

Bob McConnell
N2SPP

william scheding 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.