Re: How about Gedcom2 for a new namespace?

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