sources, subsources and sourceref

[bm-5]

Hi,

I have discussed about sources before. This time I have made an example to make
my case.

How you should work with sources is made clear in the tutorial of Richard on
census:
http://www.gramps-project.org/wiki/index.php?title=Recording_UK_Census_data

So you have a source, an image is connected to it with sourceref containing the
page and microfilm info.
Next data of person (event, attributes, ...) is entered and with scratchpad the
data of sourceref is repeated everywhere to make the connection to the source.

I propose to allow for another setup, using a subsource
source --> subsource -- 1 sourceref 1 -- object (person, event, attribute, ...)

Using subsources has advantages:

1/with present digitisation, websearch tools only return the one entry you look
for, not the entire page. So you have one act, a line of census info, an index
entry. Perhaps later, you will go in person and make a copy of the entire
page/book.

2/in civil offices, you can ask a copy of an act. You get only that act, not the
entire page (this is a common practise in Belgium, where you can pay to get a
nice printout of an act of one of your predecessors, eg to use as a gift).

3/people can still use the data in the way they do now. Adding this to GRAMPS
does not break the present database, or implies people MUST work differently.
Don't like it, don't use it

4/it accommodates how many people already work today. I already work in this
fashion, only GRAMPS does not support it. Looking at databases of other people,
I see many other people also work like this.


An example to show working with many sources is clearer (to be honest I made the
one source quite quickly from the many source, it could be done better):

1/file with one source for the marriages book:
http://cage.ugent.be/~bm/varia/sourceexample_true.gramps

2/file with the marriages book source split in pieces (how I actually enter it):
http://cage.ugent.be/~bm/varia/sourceexample.gramps

Please, play a bit with the above to see what in my eyes is the problem.
The source is the marriage act book of Zonnebeke 1794-1830


What I perceive as problems with sources as is now in GRAMPS:

1/I have a lot of information from some sources. This means the source has 40
images connected. This makes look-up complicated. Eg: event Occupation farmer
is coupled to the source with info: page: 40. I now want to find the picture.
Which one of the 40 has a sourcereference also containing page 40?

2/Transcription. In the example of census, Richard does not repeat the info on
the act in the note as text with the source. This often not feasible: info you
copy from a source, a Latin text, hard to read text, all need transcription.
You could make an office document and attach it to the source, but it is more
straightforward to add the text in note field of the source. However, this means
the note section blows up with 1000's of line of text, some completely unrelated
(eg transcript of marriage act of Jane Doe and John Di as well as marriage of
Britney Spies and Bradd Pass appears).

3/data retrieval/back references. What of that one line of census data is
already in your database. If all entries of that census are one big source, the
backreferences is a huge list which is useless. If one line would be a source,
you immediately see what that one line of data did to your database. The case
of retrieval of how you found an information is explained in 1/. Another
example is: born 1874. You find another source claiming 1870, and now want to
check why 1874? You go to the source of the event, which claims 'source census'
and the sourceref says page 40. How do you quickly find the image, the
transcript, ... in the huge amount of data in this source?

4/if I use the act or census line as a nucleus source, it is not actually
correct. They are part of a book, and that book is in a repository.


Using subsources can remove the above problems, as a subsource would be a
nucleus information set: one line in a census, one marriage act, ...., and that
connected to a source.

Why not use the sourceref?

The sourceref cannot be used for this! The text of an entire source, or an image
of an entire source is something you need to share between objects, so it must
be a source, not a sourceref. The note in the sourceref should only be used to
explain how the information of the source was used for the object.

However, it is true that a subsource can have a date/page/volume/number within
the larger source. Note that in the census example this is repeated on *all*
sourceref objects. In the case of a subsource, it would be entered once in the
subsource, and then not be repeated in the sourceref. I don't care to much for
this as in the case where subsource is usefull, there is no problem of
mentioning this in the note, .... section.

Is sourceref useless then?

I don't think this. For sources of which little information is learnt, or real
books (bibliography, diary, ...) the sourceref is ideal. However, for sources
which contain many unrelated short subparts that each can lead to large amount
of changes throughout your genealogical database, the sourceref is less
usefull, and a subsource is in order.

Long mail, thanks if you read this far.
I'm off on holiday. Food for some thought.

Benny

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Brian Matherly]

Benny,

>I have discussed about sources before. This time I have made an example to make
>my case.

[snip]

>I propose to allow for another setup, using a subsource
>source --> subsource -- 1 sourceref 1 -- object (person, event, attribute, ...)

[snip]

>Long mail, thanks if you read this far.
>I'm off on holiday. Food for some thought.

You obviously put a lot of thought into this. Being just a casual researcher myself, I really can't do justice to everything you wrote with any kind of response. It's out of my league.

I wonder if you would have better luck on the users mailing list first?

Thanks for everything you do. I know I appreciate it.

~Brian




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Leif Biberg Kristensen]

On Friday 6. April 2007 02:35, [hidden email] wrote:

>I propose to allow for another setup, using a subsource
>source --> subsource -- 1 sourceref 1 -- object (person, event,
> attribute, ...)

As I have mentioned here before, I'm using a similar approach in my
home-grown genealogy database Exodus <http://solumslekt.org/forays/>.
There is no doubt in my mind that a hierarchical source model is the
way to go, as also has been discussed in the Gentech GDM document.

However, I'm wondering if you've got any thoughts on how this may be
reconciled with the GEDCOM model. So far I'be been unable to find out
how, and my "solution" to the problem has been to ignore the GEDCOM
model entirely, which I find has become a straitjacket on the
development of more modern genealogy data models.
--
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE
My Jazz Jukebox: http://www.last.fm/user/leifbk/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Don Allingham]

On Wed, 2007-04-11 at 15:24 +0200, Leif B. Kristensen wrote:
> However, I'm wondering if you've got any thoughts on how this may be
> reconciled with the GEDCOM model. So far I'be been unable to find out
> how, and my "solution" to the problem has been to ignore the GEDCOM
> model entirely, which I find has become a straitjacket on the
> development of more modern genealogy data models.

I couldn't agree more. User's insist on GEDCOM compatibility, and this
comes at a *great* cost.

A straitjacket is a good analogy :-)

Don

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Douglas S. Blank]

On Wed, April 11, 2007 10:03 am, Don Allingham wrote:
> On Wed, 2007-04-11 at 15:24 +0200, Leif B. Kristensen wrote:
>> However, I'm wondering if you've got any thoughts on how this may be
>> reconciled with the GEDCOM model. So far I'be been unable to find out
>> how, and my "solution" to the problem has been to ignore the GEDCOM
>> model entirely, which I find has become a straitjacket on the
>> development of more modern genealogy data models.
>
> I couldn't agree more. User's insist on GEDCOM compatibility, and this
> comes at a *great* cost.

Those evil "users" :)

Anyone that tries to move data between two genealogy systems realizes
that, currently, GEDCOM is all that there is. Why don't we propose the
GRAMPS XML (or something similar) as a Open Genealogy Format, get it
approved, and request that these companies and projects support it?

-Doug

> A straitjacket is a good analogy :-)
>
> Don
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

--
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 6501

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Leif Biberg Kristensen]

On Wednesday 11. April 2007 16:12, Douglas S. Blank wrote:

>Anyone that tries to move data between two genealogy systems realizes
>that, currently, GEDCOM is all that there is. Why don't we propose the
>GRAMPS XML (or something similar) as a Open Genealogy Format, get it
>approved, and request that these companies and projects support it?

Another Norwegian, Christoffer Owe, has put a lot of work into a modern
genealogy exhange format called GenXML <http://cosoft.org/genxml/>. I'd
suggest that rather than reinventing yet another wheel, the GRAMPS
project should take a good look at GenXML and maybe initiate some kind
of collaboration with Christoffer.
--
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE
My Jazz Jukebox: http://www.last.fm/user/leifbk/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Don Allingham]

On Wed, 2007-04-11 at 10:12 -0400, Douglas S. Blank wrote:

> On Wed, April 11, 2007 10:03 am, Don Allingham wrote:
> > On Wed, 2007-04-11 at 15:24 +0200, Leif B. Kristensen wrote:
> >> However, I'm wondering if you've got any thoughts on how this may be
> >> reconciled with the GEDCOM model. So far I'be been unable to find out
> >> how, and my "solution" to the problem has been to ignore the GEDCOM
> >> model entirely, which I find has become a straitjacket on the
> >> development of more modern genealogy data models.
> >
> > I couldn't agree more. User's insist on GEDCOM compatibility, and this
> > comes at a *great* cost.
>
> Those evil "users" :)

In this case, it is more like "those evil applications". Users want some
type of export ability. GEDCOM is all there is right now. And GEDCOM
export works in the commercial vendors favor.

From what I can gather, GEDCOM was never designed to be a general
purpose genealogy interchange format. It was designed by the LDS church
to meet the needs of the LDS church (just like we designed the GRAMPS
XML format to meet the needs of the GRAMPS project). It does not support
everything simply because the designers did not need it to support
everything.

GEDCOM export allows genealogy programs to pretend to interoperate, but
anyone who has any significant amount of data knows that you will lose a
fair amount of data when you export. This creates vendor "lock in".
Since no one wants to lose any of their data, they stay with the program
that they have.

Even when the programs do export, take a look at the GEDCOM that they
produce. The data that is exported usually violates the GEDCOM
specification, making the data that they do export very difficult for
another program to interpret.

>
> Anyone that tries to move data between two genealogy systems realizes
> that, currently, GEDCOM is all that there is. Why don't we propose the
> GRAMPS XML (or something similar) as a Open Genealogy Format, get it
> approved, and request that these companies and projects support it?
>
> -Doug
>

We tried that at one point. Alex contacted the other OSS genealogy
projects to see if we could develop something. We offered the GRAMPS XML
format as a starting point, and indicated we would be willing to work
with any other proposed format. The other projects were not interested.

If we can't get the OSS projects to agree on anything, we won't be able
to get the commercial guys to do anything either.

The only thing we can do (and we are already doing this) is to:

  * Make sure all data in the database is exported to the XML format
  * Keep the XML format open (Alex has published a DTD)
  * Keep our code open.

Unfortunately, this is only a one way operation. We can make it easy for
other programs to import our data, but that does not help us import data
from any other program.

Don

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Don Allingham]

On Wed, 2007-04-11 at 16:27 +0200, Leif B. Kristensen wrote:

> On Wednesday 11. April 2007 16:12, Douglas S. Blank wrote:
>
> >Anyone that tries to move data between two genealogy systems realizes
> >that, currently, GEDCOM is all that there is. Why don't we propose the
> >GRAMPS XML (or something similar) as a Open Genealogy Format, get it
> >approved, and request that these companies and projects support it?
>
> Another Norwegian, Christoffer Owe, has put a lot of work into a modern
> genealogy exhange format called GenXML <http://cosoft.org/genxml/>. I'd
> suggest that rather than reinventing yet another wheel, the GRAMPS
> project should take a good look at GenXML and maybe initiate some kind
> of collaboration with Christoffer.

We would be open to working with others on such a format. From what I
can tell, GenXML has not exactly taken off. However, maybe that is where
we can help out.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Douglas S. Blank]

On Wed, April 11, 2007 10:34 am, Don Allingham wrote:

> On Wed, 2007-04-11 at 16:27 +0200, Leif B. Kristensen wrote:
>> On Wednesday 11. April 2007 16:12, Douglas S. Blank wrote:
>>
>> >Anyone that tries to move data between two genealogy systems realizes
>> >that, currently, GEDCOM is all that there is. Why don't we propose the
>> >GRAMPS XML (or something similar) as a Open Genealogy Format, get it
>> >approved, and request that these companies and projects support it?
>>
>> Another Norwegian, Christoffer Owe, has put a lot of work into a modern
>> genealogy exhange format called GenXML <http://cosoft.org/genxml/>. I'd
>> suggest that rather than reinventing yet another wheel, the GRAMPS
>> project should take a good look at GenXML and maybe initiate some kind
>> of collaboration with Christoffer.
>
> We would be open to working with others on such a format. From what I
> can tell, GenXML has not exactly taken off. However, maybe that is where
> we can help out.

>From looking at Christoffer's page, GeniML is gone (or moved), GenML
hasn't changed since 1999 (maybe a good thing?), GDM is gone (or moved),
and GenXML has continued to be developed and maintained.

Looks like a contact email is "contact AT cosoft DOT org" if anyone would
like to invite him to a discussion. Are there any points in GenXML that
GRAMPS would like changes?

-Doug


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Leif Biberg Kristensen]

On Wednesday 11. April 2007 16:32, Don Allingham wrote:

>Even when the programs do export, take a look at the GEDCOM that they
>produce. The data that is exported usually violates the GEDCOM
>specification, making the data that they do export very difficult for
>another program to interpret.

One part of the problem is that GEDCOM is full of ambiguities. Another
one is that there, at the time of active development, circulated
several draft versions among developers, some of them with mutually
incompatible constructs.

The third problem is that GEDCOM has been left totally unmaintained, and
with no community support whatsoever. Thus, it's still at the core a
proprietary format.

>GEDCOM export allows genealogy programs to pretend to interoperate,
>but anyone who has any significant amount of data knows that you will
>lose a fair amount of data when you export. This creates vendor "lock
>in". Since no one wants to lose any of their data, they stay with the
>program that they have.

That is of course the major reason for the failure of GEDCOM. But this
is obviously not in the interest of OSS developers. Nor should it be in
the real interest of users of genealogy software, open as well as
proprietary.

Thinking of it, it would be like restricting the exchange of text
documents to MS Word 6.0-format because that's what most users can
agree upon.
--
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE
My Jazz Jukebox: http://www.last.fm/user/leifbk/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[bm-5]

Quoting Don Allingham <[hidden email]>:

> On Wed, 2007-04-11 at 15:24 +0200, Leif B. Kristensen wrote:
>> However, I'm wondering if you've got any thoughts on how this may be
>> reconciled with the GEDCOM model. So far I'be been unable to find out
>> how, and my "solution" to the problem has been to ignore the GEDCOM
>> model entirely, which I find has become a straitjacket on the
>> development of more modern genealogy data models.
>
> I couldn't agree more. User's insist on GEDCOM compatibility, and this
> comes at a *great* cost.
>
> A straitjacket is a good analogy :-)

I have some implementation ideas.
Concerning GEDCOM however, I feel we need to have an "import GRAMPS GEDCOM"
option.

I noticed the following in 2.2.6: make data in GRAMPS: person with attribute
profession. Export to GEDCOM. Import GEDCOM in GRAMPS: the person now has a
'profession' event.
So to be able to export to GEDCOM, and import and not loose or see data
changed
would be nice.

Having an 'Import GRAMPS GEDCOM' option would allow to have subsources, export
to GEDCOM as a source with title: sourcetitle-subsourcetitle, and have it
import into GRAMPS again correctly.

Whatever, it should be tried to have as good as possible all data available in
GRAMPS also available in the GEDCOM.

Benny

>
> Don
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Duncan Lithgow-2]

In reply to the thread "Re: [Gramps-devel] sources, subsources and
sourceref"
and Benny's message

On Wed, 2007-04-11 at 19:26 +0200, [hidden email] wrote:
> Concerning GEDCOM however, I feel we need to have an "import GRAMPS GEDCOM"
> option.
>
> I noticed the following in 2.2.6: make data in GRAMPS: person with attribute
> profession. Export to GEDCOM. Import GEDCOM in GRAMPS: the person now has a
> 'profession' event.
I assume the problem here is that GEDCOM doesn't support the concept
'attribute'?

For unsupported concept and data fields isn't it best to make a human
readable markup 'gramps-markup'/ 'genealogy-markup' (gm) which goes into
the GEDCOM 'notes' field?

For the example you have it might be:

<gm attribute="profession">dentist</gm>

Which can then be parsed by GRAMPS if it's ever imported, and any half-useful software could do something sensible with it if the devs choose to. Would this avoid much of the information-loss people are talking about?

I also assume that the current GRAMPS XML could easily fit this way of working?
I may be way off, just a thought.

Duncan


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Don Allingham]

On Wed, 2007-04-11 at 21:10 +0200, Duncan Lithgow wrote:

> In reply to the thread "Re: [Gramps-devel] sources, subsources and
> sourceref"
> and Benny's message
>
> On Wed, 2007-04-11 at 19:26 +0200, [hidden email] wrote:
> > Concerning GEDCOM however, I feel we need to have an "import GRAMPS GEDCOM"
> > option.
> >
> > I noticed the following in 2.2.6: make data in GRAMPS: person with attribute
> > profession. Export to GEDCOM. Import GEDCOM in GRAMPS: the person now has a
> > 'profession' event.
> I assume the problem here is that GEDCOM doesn't support the concept
> 'attribute'?
>
> For unsupported concept and data fields isn't it best to make a human
> readable markup 'gramps-markup'/ 'genealogy-markup' (gm) which goes into
> the GEDCOM 'notes' field?
>
> For the example you have it might be:
>
> <gm attribute="profession">dentist</gm>
>
> Which can then be parsed by GRAMPS if it's ever imported, and any half-useful software could do something sensible with it if the devs choose to. Would this avoid much of the information-loss people are talking about?
>
> I also assume that the current GRAMPS XML could easily fit this way of working?
> I may be way off, just a thought.
>
> Duncan

Any markup language we create would not be understood by anyone but
GRAMPS. And exporting to GEDCOM so that you can reimport into GRAMPS
really doesn't make any sense, since GRAMPS XML format can do the same
without loss today.

We would instead be guilty of what every other genealogy programs does -
adding incompatible extensions to an already overly abused format.

This is kind of like trying to remix a Britney Spears song over and over
again to try to make it not sound so horrible instead of listening to a
B.B. King (*) song.

(*) Feel free to substitute The White Stripes, Sarah McLachlan, The Who,
    The Captain and Tennille, or whoever your favorite artist is... :-)



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Leif Biberg Kristensen]

On Wednesday 11. April 2007 22:15, Don Allingham wrote:

>This is kind of like trying to remix a Britney Spears song over and
> over again to try to make it not sound so horrible instead of
> listening to a B.B. King (*) song.

Which goes to show that you can't polish a turd :-)

Another approach is to "flatten" every subsource upon export to
something passing as a valid GEDCOM source. This will of course imply a
multiplication of sources, and some obvious loss of structure, but at
least you won't lose any data.
--
Leif Biberg Kristensen | Registered Linux User #338009
http://solumslekt.org/ | Cruising with Gentoo/KDE
My Jazz Jukebox: http://www.last.fm/user/leifbk/

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Duncan Lithgow-2]

On Wed, 2007-04-11 at 14:15 -0600, Don Allingham wrote:

> Any markup language we create would not be understood by anyone but
> GRAMPS.
Well, maybe not the software - but the eyes can read it. That's why we
like XML right?

> And exporting to GEDCOM so that you can reimport into GRAMPS
> really doesn't make any sense, since GRAMPS XML format can do the same
> without loss today.
I agree, but I am saddened by my inability to export more of my data to
GEDCOM for sharing. Here I try to solve both issues.

> We would instead be guilty of what every other genealogy programs does -
> adding incompatible extensions to an already overly abused format.
With the very important different that we would be preserving the data
in a human readable format which _does not_ abuse the format. I'm
talking about this markup being part of a comment field shown directly
to the reader - as is - not part of the parsed GEDCOM structure.

>
> This is kind of like trying to remix a Britney Spears song over and over
> again to try to make it not sound so horrible instead of listening to a
> B.B. King (*) song.
>
> (*) Feel free to substitute The White Stripes, Sarah McLachlan, The Who,
>     The Captain and Tennille, or whoever your favorite artist is... :-)
B.B. King I've heard of, the others? I guess I'm just too young at 32.

Duncan


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel