gramps

On Tue, May 29, 2012 at 10:02:03AM +0200, Benny Malengier wrote:

> My idea was to go more for a textual input method, where one pastes the
> text of a source, and indicate in the text what is what (call it
> annotations, which are actually your conclusions drawn from the text).
> Preselecting a certificate would give you a default pre-annotated text
> which you fill in.
> So, as a userinterface, think of two columns, left a textual input, right a
> number of colored annotations you can select ('center person', 'father
> person', 'date birth', ...), you enter text and color code it as needed, or
> in a default certificate, you see color coded pieces with dummy texts, and
> clicking those allows to enter text for it.

I think this is a very good idea for those users who have already transcribed
a number of sources from mages into ASCII-text - my own research has more
than 2500 such transcribed sources. Support for selection of a string and
its annotation with the keyboard only would be a plus.

What I am dreaming of is the day when my genealogy software can take
two annotated sources and estimate the entropy[*] of the information that
overlap between them. Then, with all sources annotated, the software can
point to any link with a weak conclusion, i.e. sources with so little entropy
in their overlap, that the conclusion based on those sources is to be improved
(via more sources) or possibly discarded. Once all links are based on conclusions
with a chosen minimum entropy, one can basically quantify the strength of a
link between any two individuals in the reaserch.

I think that would be a really awesome way to do genealogy.

[*] http://en.wikipedia.org/wiki/Entropy_%28information_theory%29

Thank you for your time,
-Lars.
--
GEDCOMP: Free, state-of-the-art GEDCOM comparison with focus
on Scandinavia: http://www.lklundin.dk/gedcomp/english.php

Hallo Benny,
> With a certificate manager, you would enter source information by 
> selecting the certificate type (census, birth certificate, ...). The 
> certificate itself would be stored, and information generated in the 
> normal Gramps structure. The way this is done is via an 
> evidence/derivation structure, which can map onto the conclusions 
> (events, sources generated)
This sounds very interesting, and I'm a bit surprised that I didn't see 
that earlier. Maybe that's because I associate the term certificate with 
something official, or something to do with security, and not what I 
normally just call a record, possibly just from an index on the web.
> My idea was to go more for a textual input method, where one pastes 
> the text of a source, and indicate in the text what is what (call it 
> annotations, which are actually your conclusions drawn from the text). 
> Preselecting a certificate would give you a default pre-annotated text 
> which you fill in.
I can imagine that processing can be automatic when the text comes from 
an index like FamilySearch, or genlias for Dutch users, or some other 
index that is sort of documented.
> So, as a userinterface, think of two columns, left a textual input, 
> right a number of colored annotations you can select ('center person', 
> 'father person', 'date birth', ...), you enter text and color code it 
> as needed, or in a default certificate, you see color coded pieces 
> with dummy texts, and clicking those allows to enter text for it.
H'm, looks like I need a picture to get an idea of what you mean here. 
Can we use the talk page on the wiki for that purpose?

What I was initially thinking about was to create hyperlinks from names 
in the text, that refer to new or existing persons in the tree, but with 
those you can't easily store link dates and places, so it's rather 
incomplete.

That's why I also think of something like the web clipping method that 
is part of Family Tree Maker. With that, you mark pieces of text, and 
add them to some sort of person on the clipboard, by selecting the right 
type of data in the context menu (right mouse button). In FTM, you can 
then merge the data set into an existing person, but that's not what I 
would like to see here. I'd rather put these pieces into the key value 
pairs that we already have in the source and citation dialogs. If we 
standardize the keys, I think it's possible to create a consistent 
translation for all sorts of certificates, and maybe even cover parts of 
another GEPS: 
http://www.gramps-project.org/wiki/index.php?title=GEPS_018:_Evidence_style_sources

With standardized keys, a certificate may translate to something like:

event-type: marriage
event-date: ...
event-place: ...
bride-name: ...
bride-age: ...
groom-name: ...
groom-age: ...

etc.

And I can imagine that keys can be localized too.

If we want, we can even link persons in the certificate to persons in 
the tree by adding:

bride-ID, groom-ID, etc.

And using an event-ID is possible too.

And all this can be done without changing anything in the data model. 
Whether that is the most elegant way, is something that I'm not sure 
about, but a hacker type of person, I just like to build on what we have 
already. I.E. as long as things don't get too obscured. If they do, I'd 
rather have real persona's here.
> We could suggest different ways to do certificates, and connect it 
> with evidence registration. Main point is to find a versatile setup 
> that can handle the huge amount of different sources and conclusion 
> derivation, without becoming impossible to maintain.
True, and when it comes to evidence registration and proper citation, I 
can imagine that things can get rather complicated. I've seen a lot of 
discussions about RDF and such on the better gedcom wiki and the gedcomX 
site, and while truly elegant, it's just too much for me at the moment.
> My take on the evidence entry is that the market for genealogy 
> products is first and foremost about the end result you obtain (the 
> family tree). Most people will only record the evidence part if it 
> means entry of data is not noticeably slower. I believe certificates 
> is the logical way to achieve this goal. People will want to use 
> certificates for data entry, and the evidence, and final family tree 
> comes automatically from that.
Right. We may not be able to do everything automatically, given the many 
difference in spelling, and even when names look exactly the same it may 
be rather dangerous, but when done right I really think it saves a lot 
of work. That's because at the moment it's a lot of work to create 
source references for each and every person that you find in a 
certificate. When you create a person from the citation data, or attach 
it to an existing person, these references can be created fully 
automatically. I hereby assume that choosing between the creation of a 
new person, or attaching to an existing one, is all done manually.

Bonus: When in doubt, you can put the name (or persona) on a smart type 
of to do list too.

cheers,

Enno

On Tue, May 29, 2012 at 5:53 PM, Enno Borgsteede <ennoborg@...> wrote:

> What I was initially thinking about was to create hyperlinks from names
> in the text, that refer to new or existing persons in the tree, but with
> those you can't easily store link dates and places, so it's rather
> incomplete.

BTW, you can do something like that in Gramps since version 3.3. In
the notes editor, you can edit text, and put links to any of the main
objects in Gramps (person, family, place, media, events, etc). In that
manner, you can put together a narrative, with links to all the
components through the story.

These links become HTML links in the Narrated Web Report and in
http://Gramps-Connect.org/, the on-line version of gramps.

A combination of certificates and live-linking in notes could give a
close approximation to these ideas.

-Doug

2012/5/30 Doug Blank <doug.blank@...>

> On Tue, May 29, 2012 at 5:53 PM, Enno Borgsteede <ennoborg@...>
> wrote:
>
> > What I was initially thinking about was to create hyperlinks from names
> > in the text, that refer to new or existing persons in the tree, but with
> > those you can't easily store link dates and places, so it's rather
> > incomplete.
>
> BTW, you can do something like that in Gramps since version 3.3. In
> the notes editor, you can edit text, and put links to any of the main
> objects in Gramps (person, family, place, media, events, etc). In that
> manner, you can put together a narrative, with links to all the
> components through the story.
>
> These links become HTML links in the Narrated Web Report and in
> http://Gramps-Connect.org/, the on-line version of gramps.
>
> A combination of certificates and live-linking in notes could give a
> close approximation to these ideas.
>

Yes, this was what I had in mind somewhat.

What would extra be needed in such 'certificate text':
* overlap of links. That is why I call it annotations. The same piece of
text might be needed in different objects. So instead of showing it as a
single underline, different colored underlines that on hover or so show an
annotation text.
* the annotation text (link) is a combination of free text and link into an
object.

Ok, just brainstorming now. Do pick the holes in the following. For
example:

Certificate: 'John Doe, born on 14 Okt 1954.'

You link this to an existing source, or select that a new source must be
created for it. You select John Doe, and click in the annotation part:
Select existing person -> John Doe. This gives in the annotation part
overview of known data that can be relevant, eg the existing birth event.
You then select 14 Okt 1954,  and you select birth event date.
You set confidence to high.

On save of the certificate, we store a certificate, with text and
annotation, and update the normal objects with the new data (so here add a
source of type birth record, source text, the name of the person is updated
with a new citation, the existing birth event is changed to the new date
and source citation is added). The user has the option to keep the old
birth date (conclusion not applied), or overwrite it with the new one from
this source (conclusion applied). The 'conclusions' are saved in the
certificate as a timestamped 'diff' between old data and new data.

As all update of objects goes together with adding source citation, the
source citation is the object that links back to the certificate ID. This
allows to retrieve the conclusions.

Together with this, we then require a 'record' mode. In record mode, a
certificate is openend, linked to an existing or new source, and one edits
the normal gramps data. The open certificate records all changes to the
data as diffs in the certificate. This as a way to use the conclusion
system even when entering data the old way.

So, with such a structure, you can hope to undo a conclusion (undoing would
not require to delete the conclusion, so a conclusion is applied or not
applied).
You can also open a person, and see a list of all sources and source
citations, and a list of all accompanying certificates. The sources and
citations give you how the current information derives from sources, while
the certificates give an overview via the diffs how the conclusion was
reached. Eg, in the example you would see you made a birth event with a
date, and later changed it to the new date based on what is in the
certificate.

One might believe from above that source and certificate are 1-1, so we can
merge them. I believe it is more like source-certificate is 1-n, so a
source collects different parts. Question is if source citation
-certificate is then n-1, and if those cannot be merged somehow. We should
aim for a n-1 relation here, so not n-m. As a certificate holds the
information that is changed in the other objects (to source extra text is
added, to event a date, to person an extra citation for the name, ...) it
should be a new object.

Obviously, storing changes done in the family tree like this, will really
blow up the database. We can be clever however. When a new object is
created, we only need to store the ID with no data. After that, we only
need to store the old data from the changes. We can use the serialize
function of the objects. So store the old data of the difference in
serialized data.
A database upgrade would give a serious headache however, requiring an
upgrade of the certificate data. In other words, somebody who has time to
think this through should do the programming :-)
Obviously, everything becomes again more complicated.

Benny


> -Doug
>

Enno,


If you want, I have generated some templates for a feature request[1] !
You can load it as a 3rd party tool.

Incomplete features (call editors, monitoring, signals, python code, modal windows, etc ...) but it is easy to improve/hack the GUI because it is .glade files[2].

If you want to see *all* available models/forms, you need to modify .gpr.py file... 'index.py' should be the parent dialog/window for managing (could be hidden), the templates are for birth/baptism, death/burial, marriage and census. Entries will be available as utilities into Tools menu.

The idea was a simple storage for records, in relation with our data (date, note, name, person, event, place, source, citation, evidence, repository, relationships) without be stored into our Family Tree because I want to keep something nice for publications (my work) and exchange.

We should have the same type of 'official/civil' sources between the Netherlands and France. So, I suppose these samples should already match the need for common transcription in relation with our data, type of events and type of sources?


[1] http://www.gramps-project.org/bugs/view.php?id=5552
[2] http://glade.gnome.org/


regards,
Jérôme

--- En date de : Mar 29.5.12, Enno Borgsteede <ennoborg@...> a écrit :

> De: Enno Borgsteede <ennoborg@...>
> Objet: Re: [Gramps-devel] better GEDCOM, gedcomX
> À: "Benny Malengier" <benny.malengier@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Mardi 29 mai 2012, 23h53
> Hallo Benny,
> > With a certificate manager, you would enter source
> information by 
> > selecting the certificate type (census, birth
> certificate, ...). The 
> > certificate itself would be stored, and information
> generated in the 
> > normal Gramps structure. The way this is done is via an
> 
> > evidence/derivation structure, which can map onto the
> conclusions 
> > (events, sources generated)
> This sounds very interesting, and I'm a bit surprised that I
> didn't see 
> that earlier. Maybe that's because I associate the term
> certificate with 
> something official, or something to do with security, and
> not what I 
> normally just call a record, possibly just from an index on
> the web.
> > My idea was to go more for a textual input method,
> where one pastes 
> > the text of a source, and indicate in the text what is
> what (call it 
> > annotations, which are actually your conclusions drawn
> from the text). 
> > Preselecting a certificate would give you a default
> pre-annotated text 
> > which you fill in.
> I can imagine that processing can be automatic when the text
> comes from 
> an index like FamilySearch, or genlias for Dutch users, or
> some other 
> index that is sort of documented.
> > So, as a userinterface, think of two columns, left a
> textual input, 
> > right a number of colored annotations you can select
> ('center person', 
> > 'father person', 'date birth', ...), you enter text and
> color code it 
> > as needed, or in a default certificate, you see color
> coded pieces 
> > with dummy texts, and clicking those allows to enter
> text for it.
> H'm, looks like I need a picture to get an idea of what you
> mean here. 
> Can we use the talk page on the wiki for that purpose?
> 
> What I was initially thinking about was to create hyperlinks
> from names 
> in the text, that refer to new or existing persons in the
> tree, but with 
> those you can't easily store link dates and places, so it's
> rather 
> incomplete.
> 
> That's why I also think of something like the web clipping
> method that 
> is part of Family Tree Maker. With that, you mark pieces of
> text, and 
> add them to some sort of person on the clipboard, by
> selecting the right 
> type of data in the context menu (right mouse button). In
> FTM, you can 
> then merge the data set into an existing person, but that's
> not what I 
> would like to see here. I'd rather put these pieces into the
> key value 
> pairs that we already have in the source and citation
> dialogs. If we 
> standardize the keys, I think it's possible to create a
> consistent 
> translation for all sorts of certificates, and maybe even
> cover parts of 
> another GEPS: 
> http://www.gramps-project.org/wiki/index.php?title=GEPS_018:_Evidence_style_sources
> 
> With standardized keys, a certificate may translate to
> something like:
> 
> event-type: marriage
> event-date: ...
> event-place: ...
> bride-name: ...
> bride-age: ...
> groom-name: ...
> groom-age: ...
> 
> etc.
> 
> And I can imagine that keys can be localized too.
> 
> If we want, we can even link persons in the certificate to
> persons in 
> the tree by adding:
> 
> bride-ID, groom-ID, etc.
> 
> And using an event-ID is possible too.
> 
> And all this can be done without changing anything in the
> data model. 
> Whether that is the most elegant way, is something that I'm
> not sure 
> about, but a hacker type of person, I just like to build on
> what we have 
> already. I.E. as long as things don't get too obscured. If
> they do, I'd 
> rather have real persona's here.
> > We could suggest different ways to do certificates, and
> connect it 
> > with evidence registration. Main point is to find a
> versatile setup 
> > that can handle the huge amount of different sources
> and conclusion 
> > derivation, without becoming impossible to maintain.
> True, and when it comes to evidence registration and proper
> citation, I 
> can imagine that things can get rather complicated. I've
> seen a lot of 
> discussions about RDF and such on the better gedcom wiki and
> the gedcomX 
> site, and while truly elegant, it's just too much for me at
> the moment.
> > My take on the evidence entry is that the market for
> genealogy 
> > products is first and foremost about the end result you
> obtain (the 
> > family tree). Most people will only record the evidence
> part if it 
> > means entry of data is not noticeably slower. I believe
> certificates 
> > is the logical way to achieve this goal. People will
> want to use 
> > certificates for data entry, and the evidence, and
> final family tree 
> > comes automatically from that.
> Right. We may not be able to do everything automatically,
> given the many 
> difference in spelling, and even when names look exactly the
> same it may 
> be rather dangerous, but when done right I really think it
> saves a lot 
> of work. That's because at the moment it's a lot of work to
> create 
> source references for each and every person that you find in
> a 
> certificate. When you create a person from the citation
> data, or attach 
> it to an existing person, these references can be created
> fully 
> automatically. I hereby assume that choosing between the
> creation of a 
> new person, or attaching to an existing one, is all done
> manually.
> 
> Bonus: When in doubt, you can put the name (or persona) on a
> smart type 
> of to do list too.
> 
> cheers,
> 
> Enno
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and 
> threat landscape has changed and how IT managers can
> respond. Discussions 
> will include endpoint security, mobile security and the
> latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

Hi Doug,

> BTW, you can do something like that in Gramps since version 3.3. In
> the notes editor, you can edit text, and put links to any of the main
> objects in Gramps (person, family, place, media, events, etc). In that
> manner, you can put together a narrative, with links to all the
> components through the story.

So what you're saying is that I've spent weeks looking for my horse
while sitting on it?

I really didn't know about this feature, and I think that's because I
still use PAF as my main genealogy program, and I merely use Gramps
for data analysis, for which it is very useful. What I mean is that I
use views like location to look for misspelled names and such, and
then correct things in PAF.

> These links become HTML links in the Narrated Web Report and in
> http://Gramps-Connect.org/, the on-line version of gramps.

That's very nice, because linking from narratives to persons, places,
and events, is something that I have always missed in other genealogy
software.

> A combination of certificates and live-linking in notes could give a
> close approximation to these ideas.

I agree. I created a few notes and links to try things, and found that
it's really nice, and it also gave me some ideas for expansion, like:

1. When I paste data from an index site into a citation note, I often
find see new persons that don't exist in my database yet. It would be
nice to create those right from the menu where you add the link, or
put the person's name on a to be researched list.
2. At the moment, I can't figure out if a person is referenced by a
note, other than by searching notes for the person's name. It would be
nice to see backlinks from persons (and other items) to notes, so you
can see where they are referenced.

In my view on evidence based genealogy, I would probably most of my
work starting from notes in sources or citations. What I mean is that
I paste everything that I think is relevant in there, be it something
from an index, a transcription that I made myself, or an email that I
got from someone else.

I need some more experimentation to figure out a reasonable workflow,
so I'll get back to the subject later.

cheers,

Enno

On Thu, May 31, 2012 at 11:04 AM, Enno Borgsteede <ennoborg@...> wrote:
> Hi Doug,
>
>> BTW, you can do something like that in Gramps since version 3.3. In
>> the notes editor, you can edit text, and put links to any of the main
>> objects in Gramps (person, family, place, media, events, etc). In that
>> manner, you can put together a narrative, with links to all the
>> components through the story.
>
> So what you're saying is that I've spent weeks looking for my horse
> while sitting on it?
>
> I really didn't know about this feature, and I think that's because I
> still use PAF as my main genealogy program, and I merely use Gramps
> for data analysis, for which it is very useful. What I mean is that I
> use views like location to look for misspelled names and such, and
> then correct things in PAF.
>
>> These links become HTML links in the Narrated Web Report and in
>> http://Gramps-Connect.org/, the on-line version of gramps.
>
> That's very nice, because linking from narratives to persons, places,
> and events, is something that I have always missed in other genealogy
> software.
>
>> A combination of certificates and live-linking in notes could give a
>> close approximation to these ideas.
>
> I agree. I created a few notes and links to try things, and found that
> it's really nice, and it also gave me some ideas for expansion, like:
>
> 1. When I paste data from an index site into a citation note, I often
> find see new persons that don't exist in my database yet. It would be
> nice to create those right from the menu where you add the link, or
> put the person's name on a to be researched list.
> 2. At the moment, I can't figure out if a person is referenced by a
> note, other than by searching notes for the person's name. It would be
> nice to see backlinks from persons (and other items) to notes, so you
> can see where they are referenced.
>
> In my view on evidence based genealogy, I would probably most of my
> work starting from notes in sources or citations. What I mean is that
> I paste everything that I think is relevant in there, be it something
> from an index, a transcription that I made myself, or an email that I
> got from someone else.
>
> I need some more experimentation to figure out a reasonable workflow,
> so I'll get back to the subject later.

Glad to hear that this could be useful! The full discussion regarding
the idea is here:

http://gramps.1791082.n4.nabble.com/Linking-in-Notes-td2131431.html

Creating a new person from the link page is an interesting idea! That
would go a long way toward a narrative-based genealogy workflow. Just
write, insert links (and creating new personas as needed) as you go.
It may depend on UI issues (eg, creating a person, adding notes, which
creates a person, etc).

We discussed adding the backlinks in the "References Tab" but decided
against it for now (time expensive).

There is a Quickview Gramplet/Report of limited use that shows you the
linked-to items for a given note. To use it:

1) go to the note view
2) add the Quickview Gramplet to the sidebar or bottombar
3) click on the configure button on toolbar
4) change "view type" to Note, and "Quickviews" to "Link References"
5) click on save

But we could do more with the links all the way around.

Looking forward to your ideas!

-Doug

> cheers,
>
> Enno

Hi Benny,

> Yes, this was what I had in mind somewhat.

Me too.

> What would extra be needed in such 'certificate text':
> * overlap of links. That is why I call it annotations. The same piece of
> text might be needed in different objects. So instead of showing it as a
> single underline, different colored underlines that on hover or so show an
> annotation text.

I'm not sure whether I would actually need that. That's because I see
most certificates as formal registrations of single events, births,
marriages, and deaths. Most of these events involve multiple persons,
and I believe that multi person events are already covered in Gramps.

Can you give me an example where a piece of text is used in different objects?

> You can also open a person, and see a list of all sources and source
> citations, and a list of all accompanying certificates. The sources and
> citations give you how the current information derives from sources, while
> the certificates give an overview via the diffs how the conclusion was
> reached. Eg, in the example you would see you made a birth event with a
> date, and later changed it to the new date based on what is in the
> certificate.

Nice!

> One might believe from above that source and certificate are 1-1, so we can
> merge them. I believe it is more like source-certificate is 1-n, so a source
> collects different parts. Question is if source citation -certificate is
> then n-1, and if those cannot be merged somehow. We should aim for a n-1
> relation here, so not n-m. As a certificate holds the information that is
> changed in the other objects (to source extra text is added, to event a
> date, to person an extra citation for the name, ...) it should be a new
> object.

In my view, which is a little different from what you sketched here, a
certificate is simply a special type of citation, just like an email,
or a narrative text from a book. As such most of the certificate data
goes to the citation, and parts, like the book title or something, go
to the source.

And in my mind, events may be part of the evidence domain. With that I
mean that a certificate linked to a citation defines and event, in
which persons and places are referenced by name, as can be seen in the
certificate itself, but don't need to be linked to actual persons and
places in the conclusion tables yet. Linking those, and unlinking them
too, is part of the conclusion process, IMO.

I'm curious what you think about this.

cheers,

Enno

Hi Jerome,

> If you want, I have generated some templates for a feature request[1] !
> You can load it as a 3rd party tool.

I'm having a little trouble with Xubuntu on my laptop, so I'm afraid I
can't try them yet. Hope to find time to read through all your
references though.

> We should have the same type of 'official/civil' sources between the Netherlands and France.

That's right. It's 200 years ago that our civil registrations started.
Something to do with Napoleon, right?

We happen to live somewhere near this monument:
http://fr.wikipedia.org/wiki/Pyramide_d%27Austerlitz

cheers,

Enno

Hi Enno


> We happen to live somewhere near this monument:
> http://fr.wikipedia.org/wiki/Pyramide_d%27Austerlitz

This is not the smallest ...
Here, there is benches and small obelisks.

> It's 200 years ago that our civil registrations started.
> Something to do with Napoleon, right?

Yes, with Napoleon, we have common civil registrations.

I have lost (trace) of one of my direct ancestor, who was soldier in 
Amsterdam, then I suppose that he died during one of Napoleon's 
campagnes... But I know that we can also find 
Belgian/Dutch/German/Polish/Czech/Swiss/Austrian/Italy/etc... 
individuals or census via military indexes. http://www.ancestramil.fr/


> I'm having a little trouble with Xubuntu on my laptop, so I'm afraid I
> can't try them yet. Hope to find time to read through all your
> references though.

This 3rd party tool is a 'draft' utility for gramps...
It should also runs fine under WindowsOS or MacOS.

Even glade editor seems to be available under Windows OS!
http://ftp.gnome.org/pub/GNOME/binaries/win32/glade/3.13/

I started others experimental gramplets, which are for 'POSIX compliant' 
OS only, but I suppose you need Xubuntu for looking at content of 
'SourceIndex.addon.tgz'?

Maybe for 'tgz' archive under Windows OS, to try '7-zip' ?
http://www.7-zip.org/

Else, there is an alternate way: I copy files into gramps-addon SVN 
repository (trunk), we ignore these files into listing files, we add a 
'setup.py' file for not building this package yet (pre-alpha)!

Otherwise, I should also add screenshots for 'marriage', 'death', 
'census', witness' forms on this feature request[1].

Finally, I thought on something like a 'wiki desktop' program, like 
zim[2], oriented genealogy usage and in relation with current link 
feature into note object (gramps)! So, the need was a 'simple' 
collections manager and editor, with loading, searching/filtering and 
editing features.

To re-use editors logic (gramps) was the quicker solution with some 
samples of code. GUI design was also quick and it is also accessible for 
non-expert. XML parsing was also a simplier solution. This common stuff 
has been tested on this addon, that's all! About forms themself, I hope 
to have generate global templates according to needs and existing 
programs[3]! I know that FamilySearch and Ancestry have started to 
provide some forms for transcriptions but it is maybe a little bit too 
late[4][5][6] for the French market!!!


[1] http://www.gramps-project.org/bugs/view.php?id=5552
[2] http://zim-wiki.org/
[3] 
http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_024:_Certificates
[4] http://expocartes.monrezo.be/agregactes.php
[5] 
http://genealogy.about.com/b/2012/05/29/french-births-deaths-marriages-online.htm
[6] 
http://genealogy.about.com/od/france/tp/France-Genealogy-Records-Online.htm


regards,
Jérôme

Enno Borgsteede a écrit :
> Hi Jerome,
> 
>> If you want, I have generated some templates for a feature request[1] !
>> You can load it as a 3rd party tool.
> 
> I'm having a little trouble with Xubuntu on my laptop, so I'm afraid I
> can't try them yet. Hope to find time to read through all your
> references though.
> 
>> We should have the same type of 'official/civil' sources between the Netherlands and France.
> 
> That's right. It's 200 years ago that our civil registrations started.
> Something to do with Napoleon, right?
> 
> We happen to live somewhere near this monument:
> http://fr.wikipedia.org/wiki/Pyramide_d%27Austerlitz
> 
> cheers,
> 
> Enno
>

> Even glade editor seems to be available under Windows OS!
> http://ftp.gnome.org/pub/GNOME/binaries/win32/glade/3.13/

Sorry, the above link is for Gtk3 projects!
http://blogs.gnome.org/tvb/2011/01/15/the-glade-dl/

If you want to modify current .glade files used by Gramps (editors, tools, addons), there is an other version:
http://ftp.gnome.org/pub/GNOME/binaries/win32/glade3/3.8/



--- En date de : Ven 1.6.12, Jérôme <romjerome@...> a écrit :

> De: Jérôme <romjerome@...>
> Objet: Re: [Gramps-devel] better GEDCOM, gedcomX
> À: "Enno Borgsteede" <ennoborg@...>
> Cc: "Gramps Development List" <gramps-devel@...>
> Date: Vendredi 1 juin 2012, 10h14
> Hi Enno
> 
> 
> > We happen to live somewhere near this monument:
> > http://fr.wikipedia.org/wiki/Pyramide_d%27Austerlitz
> 
> This is not the smallest ...
> Here, there is benches and small obelisks.
> 
> > It's 200 years ago that our civil registrations
> started.
> > Something to do with Napoleon, right?
> 
> Yes, with Napoleon, we have common civil registrations.
> 
> I have lost (trace) of one of my direct ancestor, who was
> soldier in 
> Amsterdam, then I suppose that he died during one of
> Napoleon's 
> campagnes... But I know that we can also find 
> Belgian/Dutch/German/Polish/Czech/Swiss/Austrian/Italy/etc...
> 
> individuals or census via military indexes. http://www.ancestramil.fr/
> 
> 
> > I'm having a little trouble with Xubuntu on my laptop,
> so I'm afraid I
> > can't try them yet. Hope to find time to read through
> all your
> > references though.
> 
> This 3rd party tool is a 'draft' utility for gramps...
> It should also runs fine under WindowsOS or MacOS.
> 
> Even glade editor seems to be available under Windows OS!
> http://ftp.gnome.org/pub/GNOME/binaries/win32/glade/3.13/
> 
> I started others experimental gramplets, which are for
> 'POSIX compliant' 
> OS only, but I suppose you need Xubuntu for looking at
> content of 
> 'SourceIndex.addon.tgz'?
> 
> Maybe for 'tgz' archive under Windows OS, to try '7-zip' ?
> http://www.7-zip.org/
> 
> Else, there is an alternate way: I copy files into
> gramps-addon SVN 
> repository (trunk), we ignore these files into listing
> files, we add a 
> 'setup.py' file for not building this package yet
> (pre-alpha)!
> 
> Otherwise, I should also add screenshots for 'marriage',
> 'death', 
> 'census', witness' forms on this feature request[1].
> 
> Finally, I thought on something like a 'wiki desktop'
> program, like 
> zim[2], oriented genealogy usage and in relation with
> current link 
> feature into note object (gramps)! So, the need was a
> 'simple' 
> collections manager and editor, with loading,
> searching/filtering and 
> editing features.
> 
> To re-use editors logic (gramps) was the quicker solution
> with some 
> samples of code. GUI design was also quick and it is also
> accessible for 
> non-expert. XML parsing was also a simplier solution. This
> common stuff 
> has been tested on this addon, that's all! About forms
> themself, I hope 
> to have generate global templates according to needs and
> existing 
> programs[3]! I know that FamilySearch and Ancestry have
> started to 
> provide some forms for transcriptions but it is maybe a
> little bit too 
> late[4][5][6] for the French market!!!
> 
> 
> [1] http://www.gramps-project.org/bugs/view.php?id=5552
> [2] http://zim-wiki.org/
> [3] 
> http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_024:_Certificates
> [4] http://expocartes.monrezo.be/agregactes.php
> [5] 
> http://genealogy.about.com/b/2012/05/29/french-births-deaths-marriages-online.htm
> [6] 
> http://genealogy.about.com/od/france/tp/France-Genealogy-Records-Online.htm
> 
> 
> regards,
> Jérôme
> 
> Enno Borgsteede a écrit :
> > Hi Jerome,
> > 
> >> If you want, I have generated some templates for a
> feature request[1] !
> >> You can load it as a 3rd party tool.
> > 
> > I'm having a little trouble with Xubuntu on my laptop,
> so I'm afraid I
> > can't try them yet. Hope to find time to read through
> all your
> > references though.
> > 
> >> We should have the same type of 'official/civil'
> sources between the Netherlands and France.
> > 
> > That's right. It's 200 years ago that our civil
> registrations started.
> > Something to do with Napoleon, right?
> > 
> > We happen to live somewhere near this monument:
> > http://fr.wikipedia.org/wiki/Pyramide_d%27Austerlitz
> > 
> > cheers,
> > 
> > Enno
> > 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and 
> threat landscape has changed and how IT managers can
> respond. Discussions 
> will include endpoint security, mobile security and the
> latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

On May 31, 2012, at 8:36 AM, Doug Blank wrote:

> On Thu, May 31, 2012 at 11:04 AM, Enno Borgsteede <ennoborg@...> wrote:
>> Hi Doug,
>> 
>>> BTW, you can do something like that in Gramps since version 3.3. In
>>> the notes editor, you can edit text, and put links to any of the main
>>> objects in Gramps (person, family, place, media, events, etc). In that
>>> manner, you can put together a narrative, with links to all the
>>> components through the story.
>> 
> 
> Glad to hear that this could be useful! The full discussion regarding
> the idea is here:
> 
> http://gramps.1791082.n4.nabble.com/Linking-in-Notes-td2131431.html

That's great -- it's a feature I've been wanting, to be able to write proof arguments with citations -- but why isn't it described in the manual? At the very least create a wiki page and paste in that email!

Regards,
John Ralls

On Fri, Jun 1, 2012 at 11:16 AM, John Ralls <jralls@...> wrote:
>
> On May 31, 2012, at 8:36 AM, Doug Blank wrote:
>
> On Thu, May 31, 2012 at 11:04 AM, Enno Borgsteede <ennoborg@...>
> wrote:
>
> Hi Doug,
>
>
> BTW, you can do something like that in Gramps since version 3.3. In
>
> the notes editor, you can edit text, and put links to any of the main
>
> objects in Gramps (person, family, place, media, events, etc). In that
>
> manner, you can put together a narrative, with links to all the
>
> components through the story.
>
>
>
> Glad to hear that this could be useful! The full discussion regarding
> the idea is here:
>
> http://gramps.1791082.n4.nabble.com/Linking-in-Notes-td2131431.html
>
>
> That's great -- it's a feature I've been wanting, to be able to write proof
> arguments with citations -- but why isn't it described in the manual? At the
> very least create a wiki page and paste in that email!

That is a great point! Updated with a short comment:

http://www.gramps-project.org/wiki/index.php?title=Gramps_3.4_Wiki_Manual_-_Entering_and_editing_data:_detailed_-_part_2#Note_editor

But we need an entire page, with limitations, workflow, examples, etc.
This is one place where those people looking for a way to help could.
Looking at the manual, it needs some major revisions. Some of it is
wrong, or at least misleading. Especially those items in big block
NOTE sections. Those should especially be checked for accuracy.

-Doug

> Regards,
> John Ralls

On Thu, May 31, 2012 at 11:04 AM, Enno Borgsteede <ennoborg@...> wrote:
> Hi Doug,
>
>> BTW, you can do something like that in Gramps since version 3.3. In
>> the notes editor, you can edit text, and put links to any of the main
>> objects in Gramps (person, family, place, media, events, etc). In that
>> manner, you can put together a narrative, with links to all the
>> components through the story.
>
> So what you're saying is that I've spent weeks looking for my horse
> while sitting on it?
>
> I really didn't know about this feature, and I think that's because I
> still use PAF as my main genealogy program, and I merely use Gramps
> for data analysis, for which it is very useful. What I mean is that I
> use views like location to look for misspelled names and such, and
> then correct things in PAF.
>
>> These links become HTML links in the Narrated Web Report and in
>> http://Gramps-Connect.org/, the on-line version of gramps.
>
> That's very nice, because linking from narratives to persons, places,
> and events, is something that I have always missed in other genealogy
> software.
>
>> A combination of certificates and live-linking in notes could give a
>> close approximation to these ideas.
>
> I agree. I created a few notes and links to try things, and found that
> it's really nice, and it also gave me some ideas for expansion, like:
>
> 1. When I paste data from an index site into a citation note, I often
> find see new persons that don't exist in my database yet. It would be
> nice to create those right from the menu where you add the link, or
> put the person's name on a to be researched list.
> 2. At the moment, I can't figure out if a person is referenced by a
> note, other than by searching notes for the person's name. It would be
> nice to see backlinks from persons (and other items) to notes, so you
> can see where they are referenced.
>
> In my view on evidence based genealogy, I would probably most of my
> work starting from notes in sources or citations. What I mean is that
> I paste everything that I think is relevant in there, be it something
> from an index, a transcription that I made myself, or an email that I
> got from someone else.
>
> I need some more experimentation to figure out a reasonable workflow,
> so I'll get back to the subject later.

I've implemented Enno's suggestion in trunk regarding creating new
objects from the Link Editor, and I think that this could be a work
flow that matches a lot of the ideas floating around. I think the
basic complaint is that narrative text are usually very disconnected
from the fields one has to fill-in in a database. No more.

Now, you can start your work with a narrative text, and use that to
create the objects. It works as you would expect:

1. open up a new or old note
2. write up a description of people, places, events, etc.
3. highlight an item, say a person
4. click on the link button
5. select Person, and click on "New"
6. control+v will paste the text that was highlighted in the note
7. save by pressing "ok"
8. This will populate the Link Editor with the new info. Click "ok"

You now have a link that will take you to the new person. I also added
an edit button in the Link Editor, so you can revisit each item, and
add more details to them as you write.

Some other ideas:

1) Would you like to share this note with your new Person? (or maybe a
checkbox: [x] Share note)
2) remember recent new/edited items for quick retrieval
3) maybe use some of the logic of Data Entry Gramplet to quickly add a
spouse, child, etc.
4) recognize some phrases such "Michael Smith was born on March 5,
1862 in France", parse, and create objects
5) customizable short-cuts for such common phrases (easy way to create
multiple objects given a pattern):

if "X was born on Y in Z" then:
 create Person(X), BirthEvent(Y), Place(Z)

...dreaming out loud...

-Doug

> cheers,
>
> Enno

2012/6/1 Doug Blank <doug.blank@...>

> On Thu, May 31, 2012 at 11:04 AM, Enno Borgsteede <ennoborg@...>
> wrote:
> > Hi Doug,
> >
> >> BTW, you can do something like that in Gramps since version 3.3. In
> >> the notes editor, you can edit text, and put links to any of the main
> >> objects in Gramps (person, family, place, media, events, etc). In that
> >> manner, you can put together a narrative, with links to all the
> >> components through the story.
> >
> > So what you're saying is that I've spent weeks looking for my horse
> > while sitting on it?
> >
> > I really didn't know about this feature, and I think that's because I
> > still use PAF as my main genealogy program, and I merely use Gramps
> > for data analysis, for which it is very useful. What I mean is that I
> > use views like location to look for misspelled names and such, and
> > then correct things in PAF.
> >
> >> These links become HTML links in the Narrated Web Report and in
> >> http://Gramps-Connect.org/, the on-line version of gramps.
> >
> > That's very nice, because linking from narratives to persons, places,
> > and events, is something that I have always missed in other genealogy
> > software.
> >
> >> A combination of certificates and live-linking in notes could give a
> >> close approximation to these ideas.
> >
> > I agree. I created a few notes and links to try things, and found that
> > it's really nice, and it also gave me some ideas for expansion, like:
> >
> > 1. When I paste data from an index site into a citation note, I often
> > find see new persons that don't exist in my database yet. It would be
> > nice to create those right from the menu where you add the link, or
> > put the person's name on a to be researched list.
> > 2. At the moment, I can't figure out if a person is referenced by a
> > note, other than by searching notes for the person's name. It would be
> > nice to see backlinks from persons (and other items) to notes, so you
> > can see where they are referenced.
> >
> > In my view on evidence based genealogy, I would probably most of my
> > work starting from notes in sources or citations. What I mean is that
> > I paste everything that I think is relevant in there, be it something
> > from an index, a transcription that I made myself, or an email that I
> > got from someone else.
> >
> > I need some more experimentation to figure out a reasonable workflow,
> > so I'll get back to the subject later.
>
> I've implemented Enno's suggestion in trunk regarding creating new
> objects from the Link Editor, and I think that this could be a work
> flow that matches a lot of the ideas floating around. I think the
> basic complaint is that narrative text are usually very disconnected
> from the fields one has to fill-in in a database. No more.
>
> Now, you can start your work with a narrative text, and use that to
> create the objects. It works as you would expect:
>
> 1. open up a new or old note
> 2. write up a description of people, places, events, etc.
> 3. highlight an item, say a person
> 4. click on the link button
> 5. select Person, and click on "New"
> 6. control+v will paste the text that was highlighted in the note
> 7. save by pressing "ok"
> 8. This will populate the Link Editor with the new info. Click "ok"
>
> You now have a link that will take you to the new person. I also added
> an edit button in the Link Editor, so you can revisit each item, and
> add more details to them as you write.
>
> Some other ideas:
>
> 1) Would you like to share this note with your new Person? (or maybe a
> checkbox: [x] Share note)
> 2) remember recent new/edited items for quick retrieval
> 3) maybe use some of the logic of Data Entry Gramplet to quickly add a
> spouse, child, etc.
> 4) recognize some phrases such "Michael Smith was born on March 5,
> 1862 in France", parse, and create objects
> 5) customizable short-cuts for such common phrases (easy way to create
> multiple objects given a pattern):
>
> if "X was born on Y in Z" then:
>  create Person(X), BirthEvent(Y), Place(Z)
>
> ...dreaming out loud...
>

Yes. We should do a bit more designing instead of hacking away. The new
object from link is ok, but for the rest, all we add needs to be maintained
later.
With this we are effectively mixing notes with some source text, and we
should not muddle the objects of Gramps like that.
If two things are conceptually different, we should make two things,
instead of using one for two.  It seems logical to reuse the note engine,
but it should in a different jacket. I lean to a certificate manager.

About the question to share the note with the object. Also here, the
correct workflow is a source, with a note with source transcript. Then
source citation that shares this specific note also, and citation that is
added to the constructed objects. Again, the workflow is different. We
should try to make sure there is only one good way to do things, it makes
our live to support the code much easier. So perhaps we can start with only
allowing these new features in a note of a source/source citation? Or
again, use a different jacket, the certificate manager, that contains this
functionality. The note with the created text would be a different object
then than the notes used in eg the source object. Like that we can extend
it with features, without encumbering the normal default notes.

Benny

>
> -Doug
>
> > cheers,
> >
> > Enno
>

On Fri, Jun 1, 2012 at 4:00 PM, Benny Malengier
<benny.malengier@...> wrote:
>
>
> 2012/6/1 Doug Blank <doug.blank@...>
>>
>> On Thu, May 31, 2012 at 11:04 AM, Enno Borgsteede <ennoborg@...>
>> wrote:
>> > Hi Doug,
>> >
>> >> BTW, you can do something like that in Gramps since version 3.3. In
>> >> the notes editor, you can edit text, and put links to any of the main
>> >> objects in Gramps (person, family, place, media, events, etc). In that
>> >> manner, you can put together a narrative, with links to all the
>> >> components through the story.
>> >
>> > So what you're saying is that I've spent weeks looking for my horse
>> > while sitting on it?
>> >
>> > I really didn't know about this feature, and I think that's because I
>> > still use PAF as my main genealogy program, and I merely use Gramps
>> > for data analysis, for which it is very useful. What I mean is that I
>> > use views like location to look for misspelled names and such, and
>> > then correct things in PAF.
>> >
>> >> These links become HTML links in the Narrated Web Report and in
>> >> http://Gramps-Connect.org/, the on-line version of gramps.
>> >
>> > That's very nice, because linking from narratives to persons, places,
>> > and events, is something that I have always missed in other genealogy
>> > software.
>> >
>> >> A combination of certificates and live-linking in notes could give a
>> >> close approximation to these ideas.
>> >
>> > I agree. I created a few notes and links to try things, and found that
>> > it's really nice, and it also gave me some ideas for expansion, like:
>> >
>> > 1. When I paste data from an index site into a citation note, I often
>> > find see new persons that don't exist in my database yet. It would be
>> > nice to create those right from the menu where you add the link, or
>> > put the person's name on a to be researched list.
>> > 2. At the moment, I can't figure out if a person is referenced by a
>> > note, other than by searching notes for the person's name. It would be
>> > nice to see backlinks from persons (and other items) to notes, so you
>> > can see where they are referenced.
>> >
>> > In my view on evidence based genealogy, I would probably most of my
>> > work starting from notes in sources or citations. What I mean is that
>> > I paste everything that I think is relevant in there, be it something
>> > from an index, a transcription that I made myself, or an email that I
>> > got from someone else.
>> >
>> > I need some more experimentation to figure out a reasonable workflow,
>> > so I'll get back to the subject later.
>>
>> I've implemented Enno's suggestion in trunk regarding creating new
>> objects from the Link Editor, and I think that this could be a work
>> flow that matches a lot of the ideas floating around. I think the
>> basic complaint is that narrative text are usually very disconnected
>> from the fields one has to fill-in in a database. No more.
>>
>> Now, you can start your work with a narrative text, and use that to
>> create the objects. It works as you would expect:
>>
>> 1. open up a new or old note
>> 2. write up a description of people, places, events, etc.
>> 3. highlight an item, say a person
>> 4. click on the link button
>> 5. select Person, and click on "New"
>> 6. control+v will paste the text that was highlighted in the note
>> 7. save by pressing "ok"
>> 8. This will populate the Link Editor with the new info. Click "ok"
>>
>> You now have a link that will take you to the new person. I also added
>> an edit button in the Link Editor, so you can revisit each item, and
>> add more details to them as you write.
>>
>> Some other ideas:
>>
>> 1) Would you like to share this note with your new Person? (or maybe a
>> checkbox: [x] Share note)
>> 2) remember recent new/edited items for quick retrieval
>> 3) maybe use some of the logic of Data Entry Gramplet to quickly add a
>> spouse, child, etc.
>> 4) recognize some phrases such "Michael Smith was born on March 5,
>> 1862 in France", parse, and create objects
>> 5) customizable short-cuts for such common phrases (easy way to create
>> multiple objects given a pattern):
>>
>> if "X was born on Y in Z" then:
>>  create Person(X), BirthEvent(Y), Place(Z)
>>
>> ...dreaming out loud...
>
>
> Yes. We should do a bit more designing instead of hacking away. The new
> object from link is ok, but for the rest, all we add needs to be maintained
> later.

Right; I wasn't thinking of adding any of the wild ideas to the Notes
editor. I think that the current set of changes are as far as one
would want to stretch it. Actually, I have one more, related idea:
drag and drop a Gramps object onto a Note to create a link. That will
help when constructing a narrative given that you already have your
data entered.

(On a related note, it scares me a little having the markup stored
separately from the text. If anything goes wrong (say, by changing str
to unicode, or \r\n to ^M or something) it will be badly malformed. I
think it would be better to keep the markup *in* the text, and just
strip it out if we want plain text. I guess it is useful for speed
purposes to have the plain text immediately available, but maybe we
can keep just the "preview" text cached and ready. This will allow
different editors to work more easily with the text, too.)

> With this we are effectively mixing notes with some source text, and we
> should not muddle the objects of Gramps like that.
> If two things are conceptually different, we should make two things, instead
> of using one for two.  It seems logical to reuse the note engine, but it
> should in a different jacket. I lean to a certificate manager.

I'd like to see more about what a certificate manager would look like.
Would it be like the census gramplet?

> About the question to share the note with the object. Also here, the correct
> workflow is a source, with a note with source transcript. Then source
> citation that shares this specific note also, and citation that is added to
> the constructed objects. Again, the workflow is different. We should try to
> make sure there is only one good way to do things, it makes our live to
> support the code much easier. So perhaps we can start with only allowing
> these new features in a note of a source/source citation? Or again, use a
> different jacket, the certificate manager, that contains this functionality.
> The note with the created text would be a different object then than the
> notes used in eg the source object. Like that we can extend it with
> features, without encumbering the normal default notes.

I think I see where you are headed, but not certain. Would these
certificates be just text?

-Doug

> Benny
>>
>>
>> -Doug
>>
>> > cheers,
>> >
>> > Enno
>
>

2012/6/1 Doug Blank <doug.blank@...>

>
> >> ...dreaming out loud...
> >
> >
> > Yes. We should do a bit more designing instead of hacking away. The new
> > object from link is ok, but for the rest, all we add needs to be
> maintained
> > later.
>
> Right; I wasn't thinking of adding any of the wild ideas to the Notes
> editor. I think that the current set of changes are as far as one
> would want to stretch it. Actually, I have one more, related idea:
> drag and drop a Gramps object onto a Note to create a link. That will
> help when constructing a narrative given that you already have your
> data entered.
>

Nice

>
> (On a related note, it scares me a little having the markup stored
> separately from the text. If anything goes wrong (say, by changing str
> to unicode, or \r\n to ^M or something) it will be badly malformed. I
> think it would be better to keep the markup *in* the text, and just
> strip it out if we want plain text. I guess it is useful for speed
> purposes to have the plain text immediately available, but maybe we
> can keep just the "preview" text cached and ready. This will allow
> different editors to work more easily with the text, too.)
>

Well, those were design desicions taken some time ago. They were sound, the
first implementation of Zsolt had the markup stored in the note text and
there where many issues (specifically the difference in markup between
gtk-cairo - xml - different docgen. At this moment this code is very
robust, I'm not aware of bugs.
So, I'd say, don't bother to undo this design, it would be really a lot of
work (I wrote docgen interpretation of the markup, and it is really hard)
for only a hypothetical problem. We are not a word editor :-)

>
> > With this we are effectively mixing notes with some source text, and we
> > should not muddle the objects of Gramps like that.
> > If two things are conceptually different, we should make two things,
> instead
> > of using one for two.  It seems logical to reuse the note engine, but it
> > should in a different jacket. I lean to a certificate manager.
>
> I'd like to see more about what a certificate manager would look like.
> Would it be like the census gramplet?
>

That is a decision to take. I don't think gramplet code can be made
reusable enough for many different certificates. That is why I proposed
just a note text, and derive from there. That would fit many certificates.
Something like a census gramplet would then be a dedicated interface for a
specific certificate to make data entry still more easy.


>
> > About the question to share the note with the object. Also here, the
> correct
> > workflow is a source, with a note with source transcript. Then source
> > citation that shares this specific note also, and citation that is added
> to
> > the constructed objects. Again, the workflow is different. We should try
> to
> > make sure there is only one good way to do things, it makes our live to
> > support the code much easier. So perhaps we can start with only allowing
> > these new features in a note of a source/source citation? Or again, use a
> > different jacket, the certificate manager, that contains this
> functionality.
> > The note with the created text would be a different object then than the
> > notes used in eg the source object. Like that we can extend it with
> > features, without encumbering the normal default notes.
>
> I think I see where you are headed, but not certain. Would these
> certificates be just text?
>

As I wrote some days ago, it would be an overarching object with type date,
creator, corresponding source..., containing certificate texts, which is
just text as you list, that can be parsed (based on certificate type) or
linked to create objects. User would howoever need to see what will happen
before clicking on 'Execute' or 'Save'. So part of the interface should
list the changes which will occur in the real data. Let's call those
Conclusions, and they are diffs. Conclusions can be applied or unapplied.
As Conclusions are diffs, the idea is they can  be undone.

This is the full complexity, we could of course go for something simpler,
eg, dropping undo and conclusions for now. The census gramplet with all
objects that are created from it gives an overview of everything a
certificate should do in the gramps data. As a certificate, you would
however be able to call up the census you where working on 2 months ago,
see what that entry changed in the data, update something, and save it
again. That is the main reason for the certificate, to look again at the
process that lead to data entry, and go over it again. Without conclusions,
it would be read-only however I think.
The census could be looked at as we see in the census gramplet, or as a
running text resembling the actual text (different parsers for different
types of census).
Well, for census the running text would be diffucult as it is a table
instead of a text, but birth certificate, ... don't have that problem

Anyway, also this is dreaming out loud
Benny


> -Doug
>
> > Benny
> >>
> >>
> >> -Doug
> >>
> >> > cheers,
> >> >
> >> > Enno
> >
> >
>

> Well, those were design desicions taken some time ago. They were sound, 
> the first implementation of Zsolt had the markup stored in the note text 
> and there where many issues (specifically the difference in markup 
> between gtk-cairo - xml - different docgen. At this moment this code is 
> very robust, I'm not aware of bugs.
> So, I'd say, don't bother to undo this design, it would be really a lot 
> of work (I wrote docgen interpretation of the markup, and it is really 
> hard) for only a hypothetical problem.

Also, I noted that strings for translated key into 
gen/lib/styledtexttagtype.py seem not to be used: will not be displayed!

_DATAMAP = [
         (BOLD, _("Bold"), "bold"),
         (ITALIC, _("Italic"), "italic"),
         (UNDERLINE, _("Underline"), "underline"),
         (FONTFACE, _("Fontface"), "fontface"),
         (FONTSIZE, _("Fontsize"), "fontsize"),
         (FONTCOLOR, _("Fontcolor"), "fontcolor"),
         (HIGHLIGHT, _("Highlight"), "highlight"),
         (SUPERSCRIPT, _("Superscript"), "superscript"),
         (LINK, _("Link"), "link"),


#: src/gen/lib/styledtexttagtype.py:68
msgid "Fontface"

#: src/gen/lib/styledtexttagtype.py:69
msgid "Fontsize"

#: src/gen/lib/styledtexttagtype.py:70
msgid "Fontcolor"

#: src/gen/lib/styledtexttagtype.py:71
msgid "Highlight"

#: src/gen/lib/styledtexttagtype.py:72
msgid "Superscript"

Only strings translated into:
     gui/widgets/styledtexteditor.py
seem to be used by the interface.

#: ../src/gui/widgets/styledtexteditor.py:450
msgid "Italic"

#: ../src/gui/widgets/styledtexteditor.py:452
msgid "Bold"

#: ../src/gui/widgets/styledtexteditor.py:454
msgid "Underline"

#: ../src/gui/widgets/styledtexteditor.py:464
msgid "Background Color"

#: ../src/gui/widgets/styledtexteditor.py:466
msgid "Link"

http://www.gramps-project.org/bugs/view.php?id=5621

It is very cosmetic (maybe just an extra work for translators!), but 
names are not consistant (background color???) and this does not help 
for trying to understand this markup environment and behavior by looking 
at these modules.


Jérôme


Benny Malengier a écrit :
> 
> 
> 2012/6/1 Doug Blank <doug.blank@... <mailto:doug.blank@...>>
> 
> 
>      >> ...dreaming out loud...
>      >
>      >
>      > Yes. We should do a bit more designing instead of hacking away.
>     The new
>      > object from link is ok, but for the rest, all we add needs to be
>     maintained
>      > later.
> 
>     Right; I wasn't thinking of adding any of the wild ideas to the Notes
>     editor. I think that the current set of changes are as far as one
>     would want to stretch it. Actually, I have one more, related idea:
>     drag and drop a Gramps object onto a Note to create a link. That will
>     help when constructing a narrative given that you already have your
>     data entered.
> 
> 
> Nice
> 
> 
>     (On a related note, it scares me a little having the markup stored
>     separately from the text. If anything goes wrong (say, by changing str
>     to unicode, or \r\n to ^M or something) it will be badly malformed. I
>     think it would be better to keep the markup *in* the text, and just
>     strip it out if we want plain text. I guess it is useful for speed
>     purposes to have the plain text immediately available, but maybe we
>     can keep just the "preview" text cached and ready. This will allow
>     different editors to work more easily with the text, too.)
> 
> 
> Well, those were design desicions taken some time ago. They were sound, 
> the first implementation of Zsolt had the markup stored in the note text 
> and there where many issues (specifically the difference in markup 
> between gtk-cairo - xml - different docgen. At this moment this code is 
> very robust, I'm not aware of bugs.
> So, I'd say, don't bother to undo this design, it would be really a lot 
> of work (I wrote docgen interpretation of the markup, and it is really 
> hard) for only a hypothetical problem. We are not a word editor :-)
> 
> 
>      > With this we are effectively mixing notes with some source text,
>     and we
>      > should not muddle the objects of Gramps like that.
>      > If two things are conceptually different, we should make two
>     things, instead
>      > of using one for two.  It seems logical to reuse the note engine,
>     but it
>      > should in a different jacket. I lean to a certificate manager.
> 
>     I'd like to see more about what a certificate manager would look like.
>     Would it be like the census gramplet?
> 
> 
> That is a decision to take. I don't think gramplet code can be made 
> reusable enough for many different certificates. That is why I proposed 
> just a note text, and derive from there. That would fit many 
> certificates. Something like a census gramplet would then be a dedicated 
> interface for a specific certificate to make data entry still more easy.
>  
> 
> 
>      > About the question to share the note with the object. Also here,
>     the correct
>      > workflow is a source, with a note with source transcript. Then source
>      > citation that shares this specific note also, and citation that
>     is added to
>      > the constructed objects. Again, the workflow is different. We
>     should try to
>      > make sure there is only one good way to do things, it makes our
>     live to
>      > support the code much easier. So perhaps we can start with only
>     allowing
>      > these new features in a note of a source/source citation? Or
>     again, use a
>      > different jacket, the certificate manager, that contains this
>     functionality.
>      > The note with the created text would be a different object then
>     than the
>      > notes used in eg the source object. Like that we can extend it with
>      > features, without encumbering the normal default notes.
> 
>     I think I see where you are headed, but not certain. Would these
>     certificates be just text?
> 
> 
> As I wrote some days ago, it would be an overarching object with type 
> date, creator, corresponding source..., containing certificate texts, 
> which is just text as you list, that can be parsed (based on certificate 
> type) or linked to create objects. User would howoever need to see what 
> will happen before clicking on 'Execute' or 'Save'. So part of the 
> interface should list the changes which will occur in the real data. 
> Let's call those Conclusions, and they are diffs. Conclusions can be 
> applied or unapplied. As Conclusions are diffs, the idea is they can  be 
> undone.
> 
> This is the full complexity, we could of course go for something 
> simpler, eg, dropping undo and conclusions for now. The census gramplet 
> with all objects that are created from it gives an overview of 
> everything a certificate should do in the gramps data. As a certificate, 
> you would however be able to call up the census you where working on 2 
> months ago, see what that entry changed in the data, update something, 
> and save it again. That is the main reason for the certificate, to look 
> again at the process that lead to data entry, and go over it again. 
> Without conclusions, it would be read-only however I think.
> The census could be looked at as we see in the census gramplet, or as a 
> running text resembling the actual text (different parsers for different 
> types of census).
> Well, for census the running text would be diffucult as it is a table 
> instead of a text, but birth certificate, ... don't have that problem
> 
> Anyway, also this is dreaming out loud
> Benny
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

Hi Doug, Benny,
> About the question to share the note with the object. Also here, the 
> correct workflow is a source, with a note with source transcript. Then 
> source citation that shares this specific note also, and citation that 
> is added to the constructed objects. Again, the workflow is different. 
> We should try to make sure there is only one good way to do things, it 
> makes our live to support the code much easier. So perhaps we can 
> start with only allowing these new features in a note of a 
> source/source citation? Or again, use a different jacket, the 
> certificate manager, that contains this functionality. The note with 
> the created text would be a different object then than the notes used 
> in eg the source object. Like that we can extend it with features, 
> without encumbering the normal default notes.
When I think about workflow, I think about the steps listed on the 
Better Gedcom wiki for the Evidence & Conclusion process: 
http://bettergedcom.wikispaces.com/Evidence+and+Conclusion+Process

QUOTE

The Evidence and Conclusion Process consists of the following steps:

 1. A researcher finds a source of information that contains evidence
    that mentions persons he may be interested in. He creates a record
    to document the source.
 2. The researcher creates records to document each item of evidence in
    the source that mentions the persons of interest.
 3. The researcher creates records to document each event mentioned in
    the evidence, where an event describes something that happened to
    one or more persons. Events occur at specific times and places,
    involve one or more persons as role players, and may serve to
    establish or change relationships between persons.
 4. The researcher creates records to document each person mentioned in
    each event, containing only information available from the evidence.
    The event and associated person records must be treated as a
    cohesive whole since the person records may hold information that is
    true only within the context of the event, e.g., the person’s name
    or age or place of residence, at the time the event occurred.
 5. The researcher continues this process, completing steps 1 to 4, for
    a number of sources, until he has built up a number of groups of
    associated event and person records that contain all he has
    discovered about a set of persons.
 6. The researcher reasons about the available person records and sorts
    them into groups, where each group contains the person records that
    the researcher believes refer to a single real person. The
    researcher builds these groups based on experience and good
    practices, and records the justification for each grouping decision.
    Because later evidence may prove some groupings to be incorrect, the
    grouping operation cannot destroy or remove original event or person
    records. Groups need to be supported by the model.
 7. The researcher reasons about the event records associated with the
    persons in each of the person groups in order to infer the
    relationships that existed between the real persons represented by
    the groups. The data model allows him or her to establish these
    relationships, possibly through new records that represent inferred
    genealogical events, or possibly by establishing relationship links
    between groups.

UNQUOTE

I don't know who wrote this text, but it looks like something I can use, 
and when it comes to Gramps, I hope that a certificate manager can 
support steps 3 and 4. What I mean is that it can store information 
about events, persons and their roles/relations as they are found in 
source records.

When I mention events, persons and relations (families in GEDCOM terms), 
I don't refer to the objects that we have in Gramps today, because I 
think that they are all part of the conclusion domain, and the E & C 
domains should be strictly separated.

Anyway, with a certificate manager in place, and a new way to create the 
structures that we already know (persons, relations, and events) from 
evidence, or link existing ones to new evidence, or unlink them if 
necessary, we can bring Gramps very close to my ideal of E &C based 
software.

And now I wonder what YOU think. :-)

cheers,

Enno

2012/6/4 Enno Borgsteede <ennoborg@...>

>  Hi Doug, Benny,
>
>   About the question to share the note with the object. Also here, the
> correct workflow is a source, with a note with source transcript. Then
> source citation that shares this specific note also, and citation that is
> added to the constructed objects. Again, the workflow is different. We
> should try to make sure there is only one good way to do things, it makes
> our live to support the code much easier. So perhaps we can start with only
> allowing these new features in a note of a source/source citation? Or
> again, use a different jacket, the certificate manager, that contains this
> functionality. The note with the created text would be a different object
> then than the notes used in eg the source object. Like that we can extend
> it with features, without encumbering the normal default notes.
>
> When I think about workflow, I think about the steps listed on the Better
> Gedcom wiki for the Evidence & Conclusion process:
> http://bettergedcom.wikispaces.com/Evidence+and+Conclusion+Process
>
> QUOTE
>
> The Evidence and Conclusion Process consists of the following steps:
>
>    1. A researcher finds a source of information that contains evidence
>    that mentions persons he may be interested in. He creates a record to
>    document the source.
>    2. The researcher creates records to document each item of evidence in
>    the source that mentions the persons of interest.
>    3. The researcher creates records to document each event mentioned in
>    the evidence, where an event describes something that happened to one or
>    more persons. Events occur at specific times and places, involve one or
>    more persons as role players, and may serve to establish or change
>    relationships between persons.
>    4. The researcher creates records to document each person mentioned in
>    each event, containing only information available from the evidence. The
>    event and associated person records must be treated as a cohesive whole
>    since the person records may hold information that is true only within the
>    context of the event, e.g., the person’s name or age or place of residence,
>    at the time the event occurred.
>    5. The researcher continues this process, completing steps 1 to 4, for
>    a number of sources, until he has built up a number of groups of associated
>    event and person records that contain all he has discovered about a set of
>    persons.
>    6. The researcher reasons about the available person records and sorts
>    them into groups, where each group contains the person records that the
>    researcher believes refer to a single real person. The researcher builds
>    these groups based on experience and good practices, and records the
>    justification for each grouping decision. Because later evidence may prove
>    some groupings to be incorrect, the grouping operation cannot destroy or
>    remove original event or person records. Groups need to be supported by the
>    model.
>    7. The researcher reasons about the event records associated with the
>    persons in each of the person groups in order to infer the relationships
>    that existed between the real persons represented by the groups. The data
>    model allows him or her to establish these relationships, possibly through
>    new records that represent inferred genealogical events, or possibly by
>    establishing relationship links between groups.
>
> UNQUOTE
>
> I don't know who wrote this text, but it looks like something I can use,
> and when it comes to Gramps, I hope that a certificate manager can support
> steps 3 and 4. What I mean is that it can store information about events,
> persons and their roles/relations as they are found in source records.
>
> When I mention events, persons and relations (families in GEDCOM terms), I
> don't refer to the objects that we have in Gramps today, because I think
> that they are all part of the conclusion domain, and the E & C domains
> should be strictly separated.
>
> Anyway, with a certificate manager in place, and a new way to create the
> structures that we already know (persons, relations, and events) from
> evidence, or link existing ones to new evidence, or unlink them if
> necessary, we can bring Gramps very close to my ideal of E &C based
> software.
>
> And now I wonder what YOU think. :-)
>

Well, the main difference is that in bettergedcom and some other circles,
they intend to duplicate a lot of information. So they make 10 person
objects, and then conclude those 10 are the same person, and offer a view
with a merge of all those people.
In theory nice, in practice, I would not implement it like that. As humans
we can make 1 person, perhaps 2, and later merge.
So instead of groups of people/events, we create the links as we believe
them. We offer merge to combine two objects into one, and with evidence, we
can now also offer a 'disentangle' function. In this, you indicate the
sources that appear to be another person, and we split a record in two
records based on the stored evidence in the certificate manager.

I believe such a workflow is more sensible than the theoretical one of many
objects that are groups. You just consider every source citation (or the
evidence that leads to it) as a 'base' person, and you could show how the
person object would look like based on only that source/source citation.

Benny

>  cheers,
>
> Enno
>
>

Hi Doug,
> You now have a link that will take you to the new person. I also added
> an edit button in the Link Editor, so you can revisit each item, and
> add more details to them as you write.
Nice! I'm reacting a little late, because I spent the last few days 
thinking about different concepts, and while I'm not completely sure 
what's the best thing for full support of the E & C process, I think 
that the idea of linking from (source or citation) notes is very useful 
already.
> Some other ideas:
>
> 1) Would you like to share this note with your new Person? (or maybe a
> checkbox: [x] Share note)
That's a very interesting question, because I read the thread that you 
referred to earlier, and found that the idea of linking back from 
objects to notes was dismissed when you introduced the linking idea. And 
when I say YES to the idea above, the shared note becomes a sort of link 
between the citation and the object it refers to. I tested this by 
linking the citation note to a new relation myself, and found that I can 
even use a quickview gramplet to see where the note is coming from. 
That's really nice.

So, yes, if I you create a checkbox that says Share note, I will 
probably check that, hoping that every new link I create will 
automatically cause my citation note to be shared with the object linked 
to, and of-course also that a note will be un-shared when I change or 
remove that link.
> 4) recognize some phrases such "Michael Smith was born on March 5,
> 1862 in France", parse, and create objects
> 5) customizable short-cuts for such common phrases (easy way to create
> multiple objects given a pattern):
>
> if "X was born on Y in Z" then:
>   create Person(X), BirthEvent(Y), Place(Z)
>
> ...dreaming out loud...

Right ... :-)

Well, yes, the ideas above sound nice, and I can think of a couple of 
other things too, like automatically splitting the name like PAF does, 
or use the highlighted string to help find the right object to link to. 
What I mean here is that when I create a link for a person named Michael 
Smith, the link editor tries Smith, Michael to find the right person, so 
that I don't have to scroll through the full alphabet. The same 
technique can be used to fill in some fields for the newly created person.

Now there's one other thing that I like to ask: Would it be possible to 
create links from highlighted text with the context menu (right mouse 
button)? I ask, because I often find myself pressing that right after 
highlighting that text, and then realizing that I have to click a button 
in the toolbar instead. But maybe a keyboard shortcut will help too.

thank you,

Enno

I entirely agree with Benny. I don't think the process has been properly
thought through in
http://bettergedcom.wikispaces.com/Evidence+and+Conclusion+Process.

It looks as though the process has been designed on the basis of (using)
existing features of programs, rather than thinking afresh.

I have a census for John Doe, from which I estimate that he was born in
1858. Then I find his birth certificate in which he is called Jonathan Doe,
and his birth-date is 12 Dec 1857.

So the process (step 4) wants me to create a person record for John Doe EST
1858 and another person record for Jonathan Doe 12 Dec 1857. Why? The whole
process seems to be oriented around the existing "event and associated
person records" (step 4), rather than designing a suitable process from
scratch.

The whole process is also far too labour intensive. I appreciate that the
author might be describing a process that is part manual and part automated
without distinguishing the two, but again this betrays a lack of thinking
the thing through.

--
View this message in context: http://gramps.1791082.n4.nabble.com/Re-better-GEDCOM-gedcomX-tp4655174p4655312.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

Hi Tim,
> It looks as though the process has been designed on the basis of (using)
> existing features of programs, rather than thinking afresh.

True. I think that this piece of text was written by Tom Wetmore, with 
his own software in mind, and I also think that the terms person and 
event in this text are confusing, since it is not clear whether they 
refer to the person and event objects that we already have in our 
software, or to a special class of so called source or evidence persons 
(and events). I think it's the latter.

> I have a census for John Doe, from which I estimate that he was born in
> 1858. Then I find his birth certificate in which he is called Jonathan Doe,
> and his birth-date is 12 Dec 1857.
>
> So the process (step 4) wants me to create a person record for John Doe EST
> 1858 and another person record for Jonathan Doe 12 Dec 1857. Why? The whole
> process seems to be oriented around the existing "event and associated
> person records" (step 4), rather than designing a suitable process from
> scratch.

Right, but IMO we can think about a certificate manager that stores data 
from the census and the birth certificate in such a way that Gramps can 
access the 'base' persons contained in those, where I use the word 
'base' in the same way, I hope, as Benny wrote about in his reply.

And in the same way, a certificate manager can store the type of event 
found on the web. And when we have such a certificate manager, I can 
imagine that we can link the information stored in that, about persons 
and events, to the persons and events that we already have in Gramps.

And when implemented right, I can also imagine that processing evidence 
in this manner makes our workflow easier and faster than the classic way 
of doing genealogy, where you create persons and events, and then link 
those (back) to the sources that we use.

And when gedcomX becomes reality, I can also imagine that we download 
citations and certficates using a standard format, or even connect to 
live indexes from sites like FamilySearch.

regards,

Enno

Hi Benny,

> So instead of groups of people/events, we create the links as we 
> believe them. We offer merge to combine two objects into one, and with 
> evidence, we can now also offer a 'disentangle' function. In this, you 
> indicate the sources that appear to be another person, and we split a 
> record in two records based on the stored evidence in the certificate 
> manager.
That's assuming that we have a certificate manager that has some 
structured event/person data in it, right? So it depends on how we 
implement that.
> I believe such a workflow is more sensible than the theoretical one of 
> many objects that are groups. You just consider every source citation 
> (or the evidence that leads to it) as a 'base' person, and you could 
> show how the person object would look like based on only that 
> source/source citation.
Right, except that I consider every source citation as a container for a 
group of 'base' persons, meaning that a birth certificate provides 
information about a child, and one or two parents, and a marriage 
certificate for two spouses, sometimes their parents too, and both can 
list witnesses that can be related to the primary person(s) too.

Now, I can imagine that in line with the addition of links to notes, I 
can create a gramplet that helps me link persons to citations, while 
working in the citation screen. When I can do that, it will probably 
save me a lot of time compared to the usual adding of citation links in 
the person (or event) edit screen.

How about that?

cheers,

Enno

Hi Jérôme,
> Finally, I thought on something like a 'wiki desktop' program, like 
> zim[2], oriented genealogy usage and in relation with current link 
> feature into note object (gramps)! So, the need was a 'simple' 
> collections manager and editor, with loading, searching/filtering and 
> editing features.
Exactly. And the big question is: Do users (or we developers) think that 
there is a need for such a piece of software inside Gramps, or is it 
much easier to use some sort of wiki, like you say. There are lots of 
those, including MoinMoin, which is written in python too, and also runs 
the official Ubuntu wiki:

http://moinmo.in/

And of course there's good old mediawiki, which is a little harder to 
run on a desktop PC, but which is very powerful, and has semantic 
extensions that can be very useful for all genealogists and historians. 
MoinMoin doesn't have those yet.

And a few days ago, I found this:

http://www.tamurajones.net/Historical-data.org.xhtml

and figured that I have no clue what to do next. I mean, we can expand 
Gramps with a full fledged certificate manager, and we already have 
notes with links, which are a bit wiki like, and we already know that 
Gramps is the most powerful piece of genealogy software on this planet. 
Do we want more?

I figure that if websites enhance their data with markup like described 
above, and others provide API's that give us some sort of access to 
indexed records, then what can we do that will be really used? When I 
look at how I work, I mostly think about a source (and notes) editor 
that acts like a word processor with some smart markup, that can run in 
a large window, i.e. not inside the screen estate that we have inside 
Gramps, where gramplets live. And when this editor can interact with 
persons and events in Gramps, or Gramps Connect, life might be simpler 
for me than with a full blown Gramps that integrates everything.

So, then, it's more about the ecosystem then the application.

Would you agree?

cheers,

Enno

Hi Enno,

> use some sort of wiki, like you say. There are lots of those, including MoinMoin, which is written in python too

In fact, I am "old" school, prefering local usage than full external 
hosting! My goal is also oriented end users. So, external DB , like 
storing under servers is maybe good for some compagnies but not for 
"sustainable/futur development"!

That's also 'zim' logic or indirectly 'weboob' way!
http://zim-wiki.org/ #local wiki
http://weboob.org/ #web out of browser
http://wwwsearch.sourceforge.net/mechanize/

When I started to make my genealogy under a personal computer, there was 
a great collaborative ecosystem. Some volunteers easily shared common 
data and indexes. Today, some compagnies seem to index records from 
places where people can read french, but they do not know local french 
history or some cultural differences, genearting poor quality 
transcriptions.

Question: Maybe you wonder why there is so many free or semi-free 
records indexes in France and related programs (managers, editors)?

Note, I also added screenshots for the experimental try of forms into 
Gramps via Tools -> Utilities... menu:
http://www.gramps-project.org/wiki/index.php?title=Talk:GEPS_024:_Certificates

1. as you pointed out, there is a specific model for some european 
countries having large 'civil' records, like Nederlands, Belgium, 
France, etc ...

2. In France, there were two major collaborative 'centralized' indexes, 
in the past. Also some local indexes. One major one has been bought by a 
private compagny. The second one has a partnership with a pseudo-private 
compagny. Now, there is also some policies; ie. data will still be 
public with privacy guards...

Answer: These copyrigths and ownership issues are currently fixed by 
using a local indexing and private displayers.

About 'historical-data.org/gedcomx' (google, family search), we can see 
that french records might be hard to retrieve, except making there own 
indexes, even quality issues...
See also: http://bcove.me/tq1z42h1 (~ 30 minutes) !
http://googleblog.blogspot.fr/2011/06/introducing-schemaorg-search-engines.html

So, in stead of to have a private account for having access to records, 
some french genealogists are only members of local genealogical 
societies. We get local publications, and often have access to private 
indexes: local indexes made by members and self hosting.

Finally, I thought on wiki, like desktop note-taking, which is also what 
is currently done via external programs (see above url). I do not want 
to store too many alternate names, events, hypothesis, etc ...; which 
will be also printed by reports. So, the simplier way was to have an 
other related database (agreed, like gedcomx templates/patterns/tables, 
but for users!).

My only one problem was a fast and accessible model for genealogists.

* Parsing an alternate Gramps schema/structure in memory?
Why not ! If so, a light one... do not need to handle all entries

* Handling gedcomx, bettergedcomx, etc ...
Why not ! If so, do not ignore desktop apps...

* 'gramps-connect' for indexing records?
Work in progress, but I guess it also makes sense to think on this, even 
old "client/server" way! ie. we should be already able to edit indexes 
via 'gramps-connect', improved 'merge/syncr' functions into Gramps might 
also help us to handle evidences/conclusions: users import what they 
want! 
http://www.gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge

Sorry my reasoning and english could be cryptic.
I hope you get my thoughts about recording our data into gramps in a 
perfect world! Does it exist?


regards,
Jérôme


Enno Borgsteede a écrit :
> Hi Jérôme,
>> Finally, I thought on something like a 'wiki desktop' program, like 
>> zim[2], oriented genealogy usage and in relation with current link 
>> feature into note object (gramps)! So, the need was a 'simple' 
>> collections manager and editor, with loading, searching/filtering and 
>> editing features.
> Exactly. And the big question is: Do users (or we developers) think that 
> there is a need for such a piece of software inside Gramps, or is it 
> much easier to use some sort of wiki, like you say. There are lots of 
> those, including MoinMoin, which is written in python too, and also runs 
> the official Ubuntu wiki:
> 
> http://moinmo.in/
> 
> And of course there's good old mediawiki, which is a little harder to 
> run on a desktop PC, but which is very powerful, and has semantic 
> extensions that can be very useful for all genealogists and historians. 
> MoinMoin doesn't have those yet.
> 
> And a few days ago, I found this:
> 
> http://www.tamurajones.net/Historical-data.org.xhtml
> 
> and figured that I have no clue what to do next. I mean, we can expand 
> Gramps with a full fledged certificate manager, and we already have 
> notes with links, which are a bit wiki like, and we already know that 
> Gramps is the most powerful piece of genealogy software on this planet. 
> Do we want more?
> 
> I figure that if websites enhance their data with markup like described 
> above, and others provide API's that give us some sort of access to 
> indexed records, then what can we do that will be really used? When I 
> look at how I work, I mostly think about a source (and notes) editor 
> that acts like a word processor with some smart markup, that can run in 
> a large window, i.e. not inside the screen estate that we have inside 
> Gramps, where gramplets live. And when this editor can interact with 
> persons and events in Gramps, or Gramps Connect, life might be simpler 
> for me than with a full blown Gramps that integrates everything.
> 
> So, then, it's more about the ecosystem then the application.
> 
> Would you agree?
> 
> cheers,
> 
> Enno
> 
>

Hi Jérôme,
> In fact, I am "old" school, prefering local usage than full external 
> hosting! My goal is also oriented end users. So, external DB , like 
> storing under servers is maybe good for some compagnies but not for 
> "sustainable/futur development"!
Some people may disagree on that, but I too like to have some sort of 
control over what I see as MY data. That's why I try wiki software that 
I can run on my own PC, and that allows me to access the pages that I 
make in an easy way. So, Gnote, TomBoy, Zim, are all OK, but I feel that 
they are a bit limited compared to bigger wiki's like DokuWiki, 
MediaWiki, and MoinMoin. I tried them all, and found that DokuWiki and 
MoinMoin both store pages as files, not in a database, and MoinMoin is 
the only one among these that can be run in desktop mode as a simple 
python process, without needing anything else. The other two need a web 
server, but MoinMoin is like Gramps, it's all python if you want to run 
it on your own PC.
> When I started to make my genealogy under a personal computer, there 
> was a great collaborative ecosystem. Some volunteers easily shared 
> common data and indexes. Today, some compagnies seem to index records 
> from places where people can read french, but they do not know local 
> french history or some cultural differences, genearting poor quality 
> transcriptions.
Sounds familiar. I noticed that some FamilySearch indexes are also poor 
quality, because the people doing the indexing are not aware of local 
habits w.r.t. the spelling of names etc. That's not to day that their 
work is bad, but I see mistakes that locals probably don't make.
> Finally, I thought on wiki, like desktop note-taking, which is also 
> what is currently done via external programs (see above url). I do not 
> want to store too many alternate names, events, hypothesis, etc ...; 
> which will be also printed by reports. So, the simplier way was to 
> have an other related database (agreed, like gedcomx 
> templates/patterns/tables, but for users!).
So you think about separating the records from the conclusion world 
(Gramps) just like GedcomX decided to. I was a little sad about that at 
first, but I'm slowly coming to understand the reasoning behind that.
> My only one problem was a fast and accessible model for genealogists.
>
> * Parsing an alternate Gramps schema/structure in memory?
> Why not ! If so, a light one... do not need to handle all entries
At the moment, I don't think that we really need an alternate schema or 
structure. That's because we already have key value pairs, and they can 
be used to store results from all the indexes that I have seen up to 
now. What I mean is that a result from FamilySearch like:

Name: 	Franciscus Hendricus Borgsteede
Gender: 	Male
Burial Date: 	
Burial Place: 	
Death Date: 	06 Nov 1847
Death Place: 	Amsterdam, Noord-Holland, Nederland
Age: 	2
Birth Date: 	1845
Birthplace: 	
Occupation: 	
Race: 	
Marital Status: 	
Spouse's Name: 	
Father's Name: 	Hendrik Borgsteede 
<https://familysearch.org/pal:/MM9.1.1/FNHH-F4K>
Father's Birthplace: 	
Mother's Name: 	Jacoba Quirina Aaltsz 
<https://familysearch.org/pal:/MM9.1.1/FNHH-F42>
Mother's Birthplace: 	
Indexing Project (Batch) Number: 	I05743-4 
<https://familysearch.org/search/records/index#count=20&query=+batch_number:I05743-4> 

System Origin: 	Netherlands-EASy
Source Film Number: 	253774
Reference Number: 	p.132


Or something similar from Genlias:

Bron 	Burgerlijke stand - Huwelijk
Archieflocatie 	Noord-Hollands Archief
Algemeen 	Gemeente: Amsterdam
Soort akte: Huwelijksakte
Aktenummer: reg.2;fol.60
Datum: 06-03-1839
Bruidegom 	Andries Borgsteede
Leeftijd: 22
Geboorteplaats: Amsterdam
Bruid 	Anna Overeem
Leeftijd: 29
Geboorteplaats: Amsterdam
Vader bruidegom 	Jan Andries Borgsteede
Moeder bruidegom 	Barbara Catharina Pfann
Vader bruid 	Jan Herman Overeem
Moeder bruid 	Johanna Helena Steenbrugge
Nadere informatie 	beroep Bg.:schoenmaker;beroep Bd.:werkster


can be easily converted to a piece of XML with data_item structures and 
key value pairs, and then be imported into Gramps.
> * Handling gedcomx, bettergedcomx, etc ...
> Why not ! If so, do not ignore desktop apps...
Up to now, better gedcom hasn't created any standard yet, and the first 
version of GedcomX was highly criticized by Tamura Jones, for good 
reasons I think, so maybe it's much simpeler to stick to our own Gramps XML.
> * 'gramps-connect' for indexing records?
> Work in progress, but I guess it also makes sense to think on this, 
> even old "client/server" way! ie. we should be already able to edit 
> indexes via 'gramps-connect', improved 'merge/syncr' functions into 
> Gramps might also help us to handle evidences/conclusions: users 
> import what they want! 
> http://www.gramps-project.org/wiki/index.php?title=GEPS_009:_Import_Export_Merge
H'm, yes, I think it can work if you keep the indexes and the 
conclusions separated, meaning that the index part can have many 
duplicate persons, since every certificate has its own persons linked to 
the events they describe, while the conclusion part only has the persons 
you are interested in, as people that appear in all sorts of indexes, 
with different names, while you know that they are the same individuals.

So what you do is probably what you like best, and I think that Gramps 
XML and schema.org are perfectly fit for the job. I mean that when I 
have to code the examples mentioned above into either one of them, the 
results are very similar and easy to understand.

So who needs better gedcom or gedcomx anyway? We have the technology in 
our own hands!

cheers,

Enno

On Jun 14, 2012, at 9:51 AM, Enno Borgsteede wrote:

>> Finally, I thought on wiki, like desktop note-taking, which is also what is currently done via external programs (see above url). I do not want to store too many alternate names, events, hypothesis, etc ...; which will be also printed by reports. So, the simplier way was to have an other related database (agreed, like gedcomx templates/patterns/tables, but for users!). 
> So you think about separating the records from the conclusion world (Gramps) just like GedcomX decided to. I was a little sad about that at first, but I'm slowly coming to understand the reasoning behind that.

Actually, that's getting revisited. See https://github.com/FamilySearch/gedcomx/issues/134 -- and join the fun, even if only to +1 some of the suggestions. The more folks who advocate for expanding beyond a pure conclusion model the more likely Ryan is to add the necessary features.

> Up to now, better gedcom hasn't created any standard yet, and the first version of GedcomX was highly criticized by Tamura Jones, for good reasons I think, so maybe it's much simpeler to stick to our own Gramps XML.

That goes for Ms. Jones, as well. GedcomX is very much a work in progress, and if she has constructive criticism (rather than her usual nit-picking) she should open issues at https://github.com/FamilySearch/gedcomx instead of throwing rocks from afar.

In any case,  I entirely agree that we should not constrain our design of Gramps by any interchange format, nor by the strictures of relational design. 

Regards,
John Ralls

On Thu, Jun 14, 2012 at 9:47 AM, John Ralls <jralls@...> wrote:
>
> On Jun 14, 2012, at 9:51 AM, Enno Borgsteede wrote:
>
>>> Finally, I thought on wiki, like desktop note-taking, which is also what is currently done via external programs (see above url). I do not want to store too many alternate names, events, hypothesis, etc ...; which will be also printed by reports. So, the simplier way was to have an other related database (agreed, like gedcomx templates/patterns/tables, but for users!).
>> So you think about separating the records from the conclusion world (Gramps) just like GedcomX decided to. I was a little sad about that at first, but I'm slowly coming to understand the reasoning behind that.
>
> Actually, that's getting revisited. See https://github.com/FamilySearch/gedcomx/issues/134 -- and join the fun, even if only to +1 some of the suggestions. The more folks who advocate for expanding beyond a pure conclusion model the more likely Ryan is to add the necessary features.
>
>> Up to now, better gedcom hasn't created any standard yet, and the first version of GedcomX was highly criticized by Tamura Jones, for good reasons I think, so maybe it's much simpeler to stick to our own Gramps XML.
>
> That goes for Ms. Jones, as well. GedcomX is very much a work in progress, and if she has constructive criticism (rather than her usual nit-picking) she should open issues at https://github.com/FamilySearch/gedcomx instead of throwing rocks from afar.

The only correction I have is that (I believe) "Tamura" is a man
living in Leiden, in the Dutch province of South Holland. Although I
have never met him.

> In any case,  I entirely agree that we should not constrain our design of Gramps by any interchange format, nor by the strictures of relational design.

We actually don't stray too far from GEDCOM in most places, being
careful to create structures that can be represented in GEDCOM, if
possible. But as soon as there is a generally agreed upon replacement,
then we can use that as our primary constraint, and hopefully it can
be extended.

-Doug

> Regards,
> John Ralls
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel

Hi,
> Actually, that's getting revisited. See 
> https://github.com/FamilySearch/gedcomx/issues/134 -- and join the 
> fun, even if only to +1 some of the suggestions. The more folks who 
> advocate for expanding beyond a pure conclusion model the more likely 
> Ryan is to add the necessary features. 
Well, it cost me a few days to understand what the discussion is about, 
and I'm glad you pointed this out. I think I'm somewhere between John 
and Tom w.r.t. persona's, but there's so much in the discussion that I 
hardly know where to add that +1.
> We actually don't stray too far from GEDCOM in most places, being 
> careful to create structures that can be represented in GEDCOM, if 
> possible. But as soon as there is a generally agreed upon replacement, 
> then we can use that as our primary constraint, and hopefully it can 
> be extended.
Sounds sensible, and I sincerely hope that shared events can be 
introduced in Gramps some time. That's because I have always thought 
that it's strange that most software still thinks that all events are 
individual. I mean, most births list at least two known persons, and 
most certificates list three or more, and the same goes for death 
certificates which very often mention spouses. And for me the most 
annoying single person event is residence, since that one is also very 
often about whole family groups, like censuses.

And IMO, most of this can probably be part of GEPS 024:

http://www.gramps-project.org/wiki/index.php?title=GEPS_024:_Certificates

At the moment, I'm a little tired though, so I hope to pick things up a 
little later.

cheers,

Enno

Hello Enno



> Sounds sensible, and I sincerely hope that shared events can be 
> introduced in Gramps some time. That's because I have always thought 
> that it's strange that most software still thinks that all events are 
> individual. I mean, most births list at least two known persons, and 
> most certificates list three or more, and the same goes for death 
> certificates which very often mention spouses. And for me the most 
> annoying single person event is residence, since that one is also very 
> often about whole family groups, like censuses.
> 
> And IMO, most of this can probably be part of GEPS 024:

Gramps has had shared events for quite some time. An event is shared between people using an event reference.

Bye

Gary

Hi Gary,
> Gramps has had shared events for quite some time. An event is shared 
> between people using an event reference.
Thanks, I stand corrected now. I looked for ways to link persons to 
events, and didn't find those in the event edit screen, so I gave up. 
After reading your message, I checked the person screen, and found that 
I add shared events there.

That said, I would find it way easier to link persons to events from the 
event edit screen, just like you can link persons to notes. With that, 
entering something like a residence event will work much faster, IMO.

In this respect, I find Tom Wetmore's comment on gedcomX quite interesting:

https://github.com/FamilySearch/gedcomx/pull/134#issuecomment-6380722

And with that in mind, it would make sense to me to link events to 
everyone involved, so that a birth event can be linked to one or more 
persons acting as parents, a marriage to witnesses, etc.

Well, that's it for now.

cheers,

Enno

On Jun 17, 2012, at 6:50 PM, Enno Borgsteede wrote:

> Hi Gary,
>> Gramps has had shared events for quite some time. An event is shared 
>> between people using an event reference.
> Thanks, I stand corrected now. I looked for ways to link persons to 
> events, and didn't find those in the event edit screen, so I gave up. 
> After reading your message, I checked the person screen, and found that 
> I add shared events there.
> 
> That said, I would find it way easier to link persons to events from the 
> event edit screen, just like you can link persons to notes. With that, 
> entering something like a residence event will work much faster, IMO.
> 
> In this respect, I find Tom Wetmore's comment on gedcomX quite interesting:
> 
> https://github.com/FamilySearch/gedcomx/pull/134#issuecomment-6380722
> 
> And with that in mind, it would make sense to me to link events to 
> everyone involved, so that a birth event can be linked to one or more 
> persons acting as parents, a marriage to witnesses, etc.
> 
> Well, that's it for now.

Enno,

If you find a comment interesting, useful, or persuasive, please do join in to support it! The discussions lately are Tom, Sarah, and me arguing amongst ourselves, and we certainly need more viewpoints and voices to get a good spec.

Regards,
John Ralls

Enno,


There is also a page on wiki which shows some samples on 'events table' 
use and related references or outputs!

http://www.gramps-project.org/wiki/index.php?title=Events_manager

Gramps can already use a record like model based on event/source because 
  it is not dependant of family or person centric models...


Example:
1. a group of persons with ancestors who immigrated to USA create an 
association/society.
2. they have a dns and install 'gramps-connect' (or gramps via cli!)
3. multiple accounts and worldwide 
events/sources/media/notes/persons/families tables editions
4. they share some records which are common and find some relations

=> they can extract events for generating an index of common and shared 
events (or sources) with related references (persons/families).


It seems that Cumberland Family Tree program was also able to go further 
than old gedcom basics with events by ordering/sorting them by group.

As said, Gramps is able to share events since many years and do not need 
any person or family record for editing an event. :)

Once I have read that new gedcom concepts cannot go too far too quickly 
because windows programs or web applications are not ready (database 
design), then this did not make sense to still slow down any development 
for this reason...

It may be naive, but they use more energy for trying to communicate that 
to provide solutions!

See Michiel's scripts
http://members.tele2.nl/m.d.nauta/typeless_data_entry/typeless_data_entry.html

Much more modestly, I tested the validation (syntax and content) of 
Gramps XML file, and a rapid transformation in local (or via server).
http://gramps-project.org/wiki/index.php?title=Lxml_Gramplet
Note, to re-use Michiel's scripts can also work!

True, we could also try to generate a 'GrampsXML2gedcomx.xslt' but as 
you said, gedcomx/bettergedcom (draft) are 'in progress'... Also, to use 
java makes things harder, even if Oracle seems behind gedcomx project!



Jérôme

Gary Burton a écrit :
> Hello Enno
> 
> 
> 
>> Sounds sensible, and I sincerely hope that shared events can be 
>> introduced in Gramps some time. That's because I have always thought 
>> that it's strange that most software still thinks that all events are 
>> individual. I mean, most births list at least two known persons, and 
>> most certificates list three or more, and the same goes for death 
>> certificates which very often mention spouses. And for me the most 
>> annoying single person event is residence, since that one is also very 
>> often about whole family groups, like censuses.
>>
>> And IMO, most of this can probably be part of GEPS 024:
> 
> Gramps has had shared events for quite some time. An event is shared between people using an event reference.
> 
> Bye
> 
> Gary
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

On Jun 18, 2012, at 10:30 AM, Jérôme wrote:

> Enno,
> 
> 
> There is also a page on wiki which shows some samples on 'events table' 
> use and related references or outputs!
> 
> http://www.gramps-project.org/wiki/index.php?title=Events_manager
> 
> Gramps can already use a record like model based on event/source because 
>  it is not dependant of family or person centric models...
> 
> 
> Example:
> 1. a group of persons with ancestors who immigrated to USA create an 
> association/society.
> 2. they have a dns and install 'gramps-connect' (or gramps via cli!)
> 3. multiple accounts and worldwide 
> events/sources/media/notes/persons/families tables editions
> 4. they share some records which are common and find some relations
> 
> => they can extract events for generating an index of common and shared 
> events (or sources) with related references (persons/families).
> 
> 
> It seems that Cumberland Family Tree program was also able to go further 
> than old gedcom basics with events by ordering/sorting them by group.
> 
> As said, Gramps is able to share events since many years and do not need 
> any person or family record for editing an event. :)
> 
> Once I have read that new gedcom concepts cannot go too far too quickly 
> because windows programs or web applications are not ready (database 
> design), then this did not make sense to still slow down any development 
> for this reason...
> 
> It may be naive, but they use more energy for trying to communicate that 
> to provide solutions!

Do you mean GedcomX or BetterGedcom?

> 
> See Michiel's scripts
> http://members.tele2.nl/m.d.nauta/typeless_data_entry/typeless_data_entry.html
> 
> Much more modestly, I tested the validation (syntax and content) of 
> Gramps XML file, and a rapid transformation in local (or via server).
> http://gramps-project.org/wiki/index.php?title=Lxml_Gramplet
> Note, to re-use Michiel's scripts can also work!
> 
> True, we could also try to generate a 'GrampsXML2gedcomx.xslt' but as 
> you said, gedcomx/bettergedcom (draft) are 'in progress'... Also, to use 
> java makes things harder, even if Oracle seems behind gedcomx project!

Not yet time to write a Gramps <-> GedcomX module. GedcomX isn't yet well enough specified.
I haven't noticed anyone from Oracle being involved, either. Don't worry about the java. That's
just Ryan's (weird) way of generating the spec, schemas, and diagrams. The actual spec will be English
and implementable in any computer language.

Regards,
John Ralls

Hi Jérôme,
> There is also a page on wiki which shows some samples on 'events 
> table' use and related references or outputs!
>
> http://www.gramps-project.org/wiki/index.php?title=Events_manager
>
> Gramps can already use a record like model based on event/source 
> because  it is not dependant of family or person centric models...
I'm aware of that, but I really like to use some sort of true record 
model. For me, that means something where the persons from the source 
certificates are separated from the persons in my genealogy.

So, when I find a marriage certificate, I want to store the information 
that I find about the spouses A and B in a simple table, where I can see 
their names, roles, ages, birth dates, and whatever information that is 
in the source. And for me, the same goes for the event itself. This 
event is linked to a the source citation, and the persons mentioned 
above sort of belong to the event, which by itself can also be in a 
separate event table, as part of the record model.

Now, when I find a birth certificate, I create a new event with parents 
A and B, and child C, where A, B and C are all new evidence persons, 
that belong to the new event. This is because I'm not completely sure 
that the A and B in the birth certificate are the same real persons as 
the A and B that married earlier. And the same goes when I find another 
birth certificate for child D.

Up till now, all that I've done in this process is indexing, or copying 
information from an on-line index like genlias to my own PC. The 
conclusion process comes next, when I combine all A's into real person 
A, and do the same for B, and of course also when I find other 
information about C and D.

And in this conclusion process, I hope that my dream software creates 
links from the events and persons in the record model to some persons 
and events in the conclusion model, i.e. the model that we already have 
in Gramps. And creating links means that I don't destroy anything in the 
record model. The only thing that I do is associate events and persons 
in the evidence domain with events and persons in the conclusion domain. 
And when I think that things went wrong, I correct my actions, by 
destroying associations, or creating different ones.

With this approach, I can share my certificates with other genealogists 
without forcing them to accept my conclusions, as is now the case when I 
exchange GEDCOMS. And in the end, I may end up with a tree that has less 
persons than I have now, because there is no need to import or store 
every name that I find as a full person in my tree just in case. When 
I'm not sure, I leave the data from the record model there as is, for 
further investigation when I have the time for that.

And the fun thing is that all of this can already be done when I store 
all certificate data in key value pairs in the citation record. I can 
use standard key names like event-type, father-name, mother-name, etc. 
for all the values that I find on FamilySearch or genlias, and the 
process may go pretty fast when I adapt Michiel's greasemonkey code to 
create the right parts of Gramps XML for citations with key value pairs.

Having real record event person tables is more fun however, because when 
they are there, you can use the same kind of spreadsheet like overviews 
that we already have for events and persons in the conclusion domain.

That's it for today.

cheers,

Enno

> > Once I have read that new gedcom concepts cannot go too
> far too quickly 
> > because windows programs or web applications are not
> ready (database 
> > design), then this did not make sense to still slow
> down any development 
> > for this reason...
> > 
> > It may be naive, but they use more energy for trying to
> communicate that 
> > to provide solutions!
> 
> Do you mean GedcomX or BetterGedcom?

Bettergedcom !
I do not find the reference post about relational models vs hierarchical models, but here, a related one: http://bettergedcom.wikispaces.com/message/view/DeadEnds+Model/31192425#31195909

> > Also, to use java makes things harder, even if Oracle seems behind gedcomx project!
> 
> Not yet time to write a Gramps <-> GedcomX module.
> GedcomX isn't yet well enough specified.
> I haven't noticed anyone from Oracle being involved, either.
> Don't worry about the java. 

It was just a simple shortcut: 
1. Oracle = sponsor at RootsTech
2. RDF, XSL, C++, java (=Xalan? Xerces?)
3. Apache (=Xalan?)
4. no binding/specification with more accessible samples or python scripts with alternate XML schemas

What I do not understand is why samples of libraries with serialization for C client or Objective C client in conjunction with libxml2, and nothing for python?

"Libxml2 is the XML C parser and toolkit developed for the Gnome project (but usable outside of the Gnome platform)"
http://www.xmlsoft.org/
http://www.xmlsoft.org/python.html

> That's just Ryan's (weird) way of generating the spec, schemas, and
> diagrams. The actual spec will be English
> and implementable in any computer language.

Yes, but it just sounds strange to already provide many spec (drafts), when we do not know where we are going, right now! Agreed, this was also done by Gramps, but looking at opened issues for gedcomx[1], by trying to certificate all processes, I wonder if there will have place for simple handling/hack of our data! 

I remember some TAGS into Gedcom:
RFN (Permanent Record File Number)
AFN (Ancestral File Number)
REFN (User Reference Number)
RIN (Automated record id)
etc...
which bother us rather than help us.

None of them seem to be still valid on new gedcomx model...
http://www.gedcomx.org/Legacy-GEDCOM-Migration-Path.html

So, maybe ontology and semantic will be winner with these re-organisations, sustainability might be also better. Currently, for me on gedcomx project, it is 'wait and see'!


[1] https://github.com/FamilySearch/gedcomx/issues


regards,
Jérôme


--- En date de : Lun 18.6.12, John Ralls <jralls@...> a écrit :

> De: John Ralls <jralls@...>
> Objet: Re: [Gramps-devel] better GEDCOM, gedcomX
> À: romjerome@...
> Cc: "Enno Borgsteede" <ennoborg@...>, "Gramps Development List" <gramps-devel@...>
> Date: Lundi 18 juin 2012, 20h50
> 
> On Jun 18, 2012, at 10:30 AM, Jérôme wrote:
> 
> > Enno,
> > 
> > 
> > There is also a page on wiki which shows some samples
> on 'events table' 
> > use and related references or outputs!
> > 
> > http://www.gramps-project.org/wiki/index.php?title=Events_manager
> > 
> > Gramps can already use a record like model based on
> event/source because 
> >  it is not dependant of family or person centric
> models...
> > 
> > 
> > Example:
> > 1. a group of persons with ancestors who immigrated to
> USA create an 
> > association/society.
> > 2. they have a dns and install 'gramps-connect' (or
> gramps via cli!)
> > 3. multiple accounts and worldwide 
> > events/sources/media/notes/persons/families tables
> editions
> > 4. they share some records which are common and find
> some relations
> > 
> > => they can extract events for generating an index
> of common and shared 
> > events (or sources) with related references
> (persons/families).
> > 
> > 
> > It seems that Cumberland Family Tree program was also
> able to go further 
> > than old gedcom basics with events by ordering/sorting
> them by group.
> > 
> > As said, Gramps is able to share events since many
> years and do not need 
> > any person or family record for editing an event. :)
> > 
> > Once I have read that new gedcom concepts cannot go too
> far too quickly 
> > because windows programs or web applications are not
> ready (database 
> > design), then this did not make sense to still slow
> down any development 
> > for this reason...
> > 
> > It may be naive, but they use more energy for trying to
> communicate that 
> > to provide solutions!
> 
> Do you mean GedcomX or BetterGedcom?
> 
> > 
> > See Michiel's scripts
> > http://members.tele2.nl/m.d.nauta/typeless_data_entry/typeless_data_entry.html
> > 
> > Much more modestly, I tested the validation (syntax and
> content) of 
> > Gramps XML file, and a rapid transformation in local
> (or via server).
> > http://gramps-project.org/wiki/index.php?title=Lxml_Gramplet
> > Note, to re-use Michiel's scripts can also work!
> > 
> > True, we could also try to generate a
> 'GrampsXML2gedcomx.xslt' but as 
> > you said, gedcomx/bettergedcom (draft) are 'in
> progress'... Also, to use 
> > java makes things harder, even if Oracle seems behind
> gedcomx project!
> 
> Not yet time to write a Gramps <-> GedcomX module.
> GedcomX isn't yet well enough specified.
> I haven't noticed anyone from Oracle being involved, either.
> Don't worry about the java. That's
> just Ryan's (weird) way of generating the spec, schemas, and
> diagrams. The actual spec will be English
> and implementable in any computer language.
> 
> Regards,
> John Ralls
> 
>

On Jun 19, 2012, at 9:07 AM, jerome wrote:

>>> Once I have read that new gedcom concepts cannot go too
>> far too quickly 
>>> because windows programs or web applications are not
>> ready (database 
>>> design), then this did not make sense to still slow
>> down any development 
>>> for this reason...
>>> 
>>> It may be naive, but they use more energy for trying to
>> communicate that 
>>> to provide solutions!
>> 
>> Do you mean GedcomX or BetterGedcom?
> 
> Bettergedcom !
> I do not find the reference post about relational models vs hierarchical models, but here, a related one: http://bettergedcom.wikispaces.com/message/view/DeadEnds+Model/31192425#31195909
> 
>>> Also, to use java makes things harder, even if Oracle seems behind gedcomx project!
>> 
>> Not yet time to write a Gramps <-> GedcomX module.
>> GedcomX isn't yet well enough specified.
>> I haven't noticed anyone from Oracle being involved, either.
>> Don't worry about the java. 
> 
> It was just a simple shortcut: 
> 1. Oracle = sponsor at RootsTech
> 2. RDF, XSL, C++, java (=Xalan? Xerces?)
> 3. Apache (=Xalan?)
> 4. no binding/specification with more accessible samples or python scripts with alternate XML schemas
> 
> What I do not understand is why samples of libraries with serialization for C client or Objective C client in conjunction with libxml2, and nothing for python?
> 
> "Libxml2 is the XML C parser and toolkit developed for the Gnome project (but usable outside of the Gnome platform)"
> http://www.xmlsoft.org/
> http://www.xmlsoft.org/python.html
> 
>> That's just Ryan's (weird) way of generating the spec, schemas, and
>> diagrams. The actual spec will be English
>> and implementable in any computer language.
> 
> Yes, but it just sounds strange to already provide many spec (drafts), when we do not know where we are going, right now! Agreed, this was also done by Gramps, but looking at opened issues for gedcomx[1], by trying to certificate all processes, I wonder if there will have place for simple handling/hack of our data! 
> 
> I remember some TAGS into Gedcom:
> RFN (Permanent Record File Number)
> AFN (Ancestral File Number)
> REFN (User Reference Number)
> RIN (Automated record id)
> etc...
> which bother us rather than help us.
> 
> None of them seem to be still valid on new gedcomx model...
> http://www.gedcomx.org/Legacy-GEDCOM-Migration-Path.html
> 
> So, maybe ontology and semantic will be winner with these re-organisations, sustainability might be also better. Currently, for me on gedcomx project, it is 'wait and see'!
> 
> 
> [1] https://github.com/FamilySearch/gedcomx/issues

OK, let's dive in a bit deeper. Ryan has written a pile of java to conform to the JAXB [1] java library. He's doing this backwards, because JAXB is intended to take an XML Schema and auto-create the java. JAXB has some pretty severe limitations, and the results are poor quality XML *and* poor quality Java. Ryan has also written a program called enunciate [2] to take the java and produce even worse-quality (as in it won't even build) C, .Net, Objective-C, and Ruby, with both XML and JSON storage.

The code itself is, in C++ terms, the class statement and a getter/setter pair for each parameter. Utterly useless for anything more than driving enunciate (which can be thought of as a lame rewrite of javadoc) to produce the documentation.

Ignore it. Instead, read the specs at
https://github.com/FamilySearch/gedcomx/blob/master/specifications/file-format-specification.md
and the linked documents. Until those get hammered into something more-or-less complete, there's no point to writing interface code in any language.

Regards,
John Ralls



[1] http://www.oracle.com/technetwork/articles/javase/index-140168.html
[2] http://enunciate.codehaus.org/

> OK, let's dive in a bit deeper. Ryan has written a pile of java to conform to the JAXB [1] java library. He's doing this backwards, because JAXB is intended to take an XML Schema and auto-create the java. JAXB has some pretty severe limitations, and the results are poor quality XML *and* poor quality Java. Ryan has also written a program called enunciate [2] to take the java and produce even worse-quality (as in it won't even build) C, .Net, Objective-C, and Ruby, with both XML and JSON storage.
> 
> The code itself is, in C++ terms, the class statement and a getter/setter pair for each parameter. Utterly useless for anything more than driving enunciate (which can be thought of as a lame rewrite of javadoc) to produce the documentation.
> 
> Ignore it. Instead, read the specs at
> https://github.com/FamilySearch/gedcomx/blob/master/specifications/file-format-specification.md
> and the linked documents. Until those get hammered into something more-or-less complete, there's no point to writing interface code in any language.
> 

Looking at tools like SWIG[1], pyxml, generateDS[2], we can also quickly 
generate a xsd schema!

Here a simple one for Gramps XML (1.5.0):
http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/trunk/contrib/lxml/grampsxml.xsd
I suppose this could be used by 'gramps-connect' (django)? For desktop 
apps without serveurs connection/transfer/validation/capture, we do not 
need this type of schema...

Maybe this could help for completing 'gramps' page[3] on gedcomx project?

Note, I also added 'superclasses/subclasses' working with generateDS on 
revision 1359: 
http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?view=revision&revision=1359


[1] "SWIG is a software development tool that connects programs written 
in C and C++ with a variety of high-level programming languages. SWIG is 
used with different types of target languages including common scripting 
languages such as Perl, PHP, Python, Tcl and Ruby."
http://www.swig.org/

[2] "generateDS.py generates Python data structures (for example, class 
definitions) from an XML Schema document. These data structures 
represent the elements in an XML document described by the XML Schema. 
It also generates parsers that load an XML document into those data 
structures. In addition, a separate file containing subclasses (stubs) 
is optionally generated. The user can add methods to the subclasses in 
order to process the contents of an XML document."
http://cutter.rexx.com/~dkuhlman/generateDS.html

[3] http://www.gedcomx.org/GRAMPS-Migration-Path.html

On Jun 22, 2012, at 11:06 AM, Jérôme <romjerome@...> wrote:

>> OK, let's dive in a bit deeper. Ryan has written a pile of java to conform to the JAXB [1] java library. He's doing this backwards, because JAXB is intended to take an XML Schema and auto-create the java. JAXB has some pretty severe limitations, and the results are poor quality XML *and* poor quality Java. Ryan has also written a program called enunciate [2] to take the java and produce even worse-quality (as in it won't even build) C, .Net, Objective-C, and Ruby, with both XML and JSON storage.
>> The code itself is, in C++ terms, the class statement and a getter/setter pair for each parameter. Utterly useless for anything more than driving enunciate (which can be thought of as a lame rewrite of javadoc) to produce the documentation.
>> Ignore it. Instead, read the specs at
>> https://github.com/FamilySearch/gedcomx/blob/master/specifications/file-format-specification.md
>> and the linked documents. Until those get hammered into something more-or-less complete, there's no point to writing interface code in any language.
> 
> Looking at tools like SWIG[1], pyxml, generateDS[2], we can also quickly generate a xsd schema!
> 
> Here a simple one for Gramps XML (1.5.0):
> http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/trunk/contrib/lxml/grampsxml.xsd
> I suppose this could be used by 'gramps-connect' (django)? For desktop apps without serveurs connection/transfer/validation/capture, we do not need this type of schema...
> 
> Maybe this could help for completing 'gramps' page[3] on gedcomx project?
> 
> Note, I also added 'superclasses/subclasses' working with generateDS on revision 1359: http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?view=revision&revision=1359
> 
> 
> [1] "SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is used with different types of target languages including common scripting languages such as Perl, PHP, Python, Tcl and Ruby."
> http://www.swig.org/
> 
> [2] "generateDS.py generates Python data structures (for example, class definitions) from an XML Schema document. These data structures represent the elements in an XML document described by the XML Schema. It also generates parsers that load an XML document into those data structures. In addition, a separate file containing subclasses (stubs) is optionally generated. The user can add methods to the subclasses in order to process the contents of an XML document."
> http://cutter.rexx.com/~dkuhlman/generateDS.html
> 
> [3] http://www.gedcomx.org/GRAMPS-Migration-Path.html


Jéroôme,

I'm intimately familiar with swig, been using it for many years. Wonderful program. Beats the Boost equivalent handily.
But it works only in one direction, to wrap C/C++ libraries for use in other languages. There's no C here, and the C generated by Enunciate is crap. Besides, we won't want to wrap a C/C++ implementation of Gramps <-> GedcomX, we'll want to write it in python.

But that's not really the issue. GedcomX itself isn't ready for use. Not even close. Any effort implementing it now would be a wasted effort.

OTOH, thanks for the GrampsXML schema. I've been meaning to familiarize myself with Gramps's backend structure, and that's an enormous help. But what's with all of the empty complex types? E.g.,
 <element name='first'>
  <complexType mixed='true'>
  </complexType>
 </element>

There are tons of them, and many (including the example) look like values of an enum.

Regards,
John Ralls

John,

> what's with all of the empty complex types? E.g.,
>  <element name='first'>
>   <complexType mixed='true'>
>   </complexType>
>  </element>
> 
> There are tons of them, and many (including the example) look like values of an enum.

Maybe an incomplete migration...
Note, it was a simple use of current DTD to one type of XML schema!
It seems to be inherited from Gramps XML DTD or tool used for generating 
the XSD file: http://www.w3.org/2000/04/schema_hack/

Something incomplete on DTD file or into 'dtd2xsd.pl'? :(

Anyway, I just tried to test what I have read on "XSLT and generateDS - 
Analysis, Comparison, and Evaluation" page:
http://cutter.rexx.com/~dkuhlman/xsltvsgenerateds.html
and just have seen (too late...) that we were also able to generate 
Django models and Django forms that represent the data structures 
defined in an XML Schema! 
http://cutter.rexx.com/~dkuhlman/generateDS.html#django-generating-models-and-forms

I suppose gedcomX aims to parse/validate genealogical content via their 
servers. Same idea with most web applications.

But there is no technical reasons for that: we can already check XML 
syntax and content on desktop/client applications without external 
connexion. We can use script (even pure python validator) for testing 
XML. Both performed and tested under Gramps for Gramps XML (1.5.0).

Your issue (#173; gedcomX) is also something that need a solution, else 
few client applications will use these RDF resources...


Jérôme



John Ralls a écrit :
> On Jun 22, 2012, at 11:06 AM, Jérôme <romjerome@...> wrote:
> 
>>> OK, let's dive in a bit deeper. Ryan has written a pile of java to conform to the JAXB [1] java library. He's doing this backwards, because JAXB is intended to take an XML Schema and auto-create the java. JAXB has some pretty severe limitations, and the results are poor quality XML *and* poor quality Java. Ryan has also written a program called enunciate [2] to take the java and produce even worse-quality (as in it won't even build) C, .Net, Objective-C, and Ruby, with both XML and JSON storage.
>>> The code itself is, in C++ terms, the class statement and a getter/setter pair for each parameter. Utterly useless for anything more than driving enunciate (which can be thought of as a lame rewrite of javadoc) to produce the documentation.
>>> Ignore it. Instead, read the specs at
>>> https://github.com/FamilySearch/gedcomx/blob/master/specifications/file-format-specification.md
>>> and the linked documents. Until those get hammered into something more-or-less complete, there's no point to writing interface code in any language.
>> Looking at tools like SWIG[1], pyxml, generateDS[2], we can also quickly generate a xsd schema!
>>
>> Here a simple one for Gramps XML (1.5.0):
>> http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/trunk/contrib/lxml/grampsxml.xsd
>> I suppose this could be used by 'gramps-connect' (django)? For desktop apps without serveurs connection/transfer/validation/capture, we do not need this type of schema...
>>
>> Maybe this could help for completing 'gramps' page[3] on gedcomx project?
>>
>> Note, I also added 'superclasses/subclasses' working with generateDS on revision 1359: http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?view=revision&revision=1359
>>
>>
>> [1] "SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is used with different types of target languages including common scripting languages such as Perl, PHP, Python, Tcl and Ruby."
>> http://www.swig.org/
>>
>> [2] "generateDS.py generates Python data structures (for example, class definitions) from an XML Schema document. These data structures represent the elements in an XML document described by the XML Schema. It also generates parsers that load an XML document into those data structures. In addition, a separate file containing subclasses (stubs) is optionally generated. The user can add methods to the subclasses in order to process the contents of an XML document."
>> http://cutter.rexx.com/~dkuhlman/generateDS.html
>>
>> [3] http://www.gedcomx.org/GRAMPS-Migration-Path.html
> 
> 
> Jéroôme,
> 
> I'm intimately familiar with swig, been using it for many years. Wonderful program. Beats the Boost equivalent handily.
> But it works only in one direction, to wrap C/C++ libraries for use in other languages. There's no C here, and the C generated by Enunciate is crap. Besides, we won't want to wrap a C/C++ implementation of Gramps <-> GedcomX, we'll want to write it in python.
> 
> But that's not really the issue. GedcomX itself isn't ready for use. Not even close. Any effort implementing it now would be a wasted effort.
> 
> OTOH, thanks for the GrampsXML schema. I've been meaning to familiarize myself with Gramps's backend structure, and that's an enormous help. But what's with all of the empty complex types? E.g.,
>  <element name='first'>
>   <complexType mixed='true'>
>   </complexType>
>  </element>
> 
> There are tons of them, and many (including the example) look like values of an enum.
> 
> Regards,
> John Ralls
> 
> 
> 
>

On Jun 23, 2012, at 10:34 AM, Jérôme <romjerome@...> wrote:

> John,
> 
>> what's with all of the empty complex types? E.g.,
>> <element name='first'>
>>  <complexType mixed='true'>
>>  </complexType>
>> </element>
>> There are tons of them, and many (including the example) look like values of an enum.
> 
> Maybe an incomplete migration...
> Note, it was a simple use of current DTD to one type of XML schema!
> It seems to be inherited from Gramps XML DTD or tool used for generating the XSD file: http://www.w3.org/2000/04/schema_hack/
> 
> Something incomplete on DTD file or into 'dtd2xsd.pl'? :(
> 
> Anyway, I just tried to test what I have read on "XSLT and generateDS - Analysis, Comparison, and Evaluation" page:
> http://cutter.rexx.com/~dkuhlman/xsltvsgenerateds.html
> and just have seen (too late...) that we were also able to generate Django models and Django forms that represent the data structures defined in an XML Schema! http://cutter.rexx.com/~dkuhlman/generateDS.html#django-generating-models-and-forms
> 
> I suppose gedcomX aims to parse/validate genealogical content via their servers. Same idea with most web applications.

Yeah, that seems to be FamilySearch's focus. It's unfortunate, because using RDF to specify class dependencies is bulky and hides intent. I haven't yet been able to get Ryan to see that, but maybe Tom's simplification in #173 will get some traction.
> 
> But there is no technical reasons for that: we can already check XML syntax and content on desktop/client applications without external connexion. We can use script (even pure python validator) for testing XML. Both performed and tested under Gramps for Gramps XML (1.5.0).
> 
> Your issue (#173; gedcomX) is also something that need a solution, else few client applications will use these RDF resources...
> 

I'm not so sure that mere size is that much of an issue. Thanks to online video people are pretty blasé about sending around a couple of gigabytes. IMO the RDF morass is a bigger problem, because there's no simple way to validate that a URI points to what you think that it should -- or even that it points to anything.

Regards,
John Ralls



Regards,
John Ralls

> there's no simple way to validate that a URI points to what you think that it should -- or even that it points to anything.

I just thought on file URI scheme[1]!

> what's with all of the empty complex types? E.g.,
> <element name='first'>
>  <complexType mixed='true'>
>  </complexType>
> </element>
> There are tons of them, and many (including the example) look like values of an enum.

About issues on name, there is a problem for validating some 
elements/attributes on current Gramps XML files: all possible values for 
custom types cannot be fixed into a scheme or specification...

  * child-rel (parent/child relations, custom, etc ...)
  * name type (Birth Name, Also Known As, custom, etc ...)
  * surname derivation (Inherited, Given, Taken, custom, etc ...)
  (*) Gramps' types, custom, etc ...

I made a minor change[2] on the experimental XSD file[3] 
(documentation): we are not listing hardcoded 'event/attribute/Gramps' 
types, why should we set values for 'child-rel', 'name', 'surname 
derivation'?

This is the same problem for old Gedcom specification(s) (events, facts, 
genders, relations, family cell, types of specific id, etc ...) and new 
exchange/validation/semantic file formats: validating or not all 
possible custom values...

I agree, there is no simple way.


[1] http://en.wikipedia.org/wiki/File_URI_scheme
[2] 
http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons?revision=1371&view=revision
[3] 
http://gramps-addons.svn.sourceforge.net/viewvc/gramps-addons/trunk/contrib/lxml/grampsxml.xsd


regards,
Jérôme


John Ralls a écrit :
> On Jun 23, 2012, at 10:34 AM, Jérôme <romjerome@...> wrote:
> 
>> John,
>>
>>> what's with all of the empty complex types? E.g.,
>>> <element name='first'>
>>>  <complexType mixed='true'>
>>>  </complexType>
>>> </element>
>>> There are tons of them, and many (including the example) look like values of an enum.
>> Maybe an incomplete migration...
>> Note, it was a simple use of current DTD to one type of XML schema!
>> It seems to be inherited from Gramps XML DTD or tool used for generating the XSD file: http://www.w3.org/2000/04/schema_hack/
>>
>> Something incomplete on DTD file or into 'dtd2xsd.pl'? :(
>>
>> Anyway, I just tried to test what I have read on "XSLT and generateDS - Analysis, Comparison, and Evaluation" page:
>> http://cutter.rexx.com/~dkuhlman/xsltvsgenerateds.html
>> and just have seen (too late...) that we were also able to generate Django models and Django forms that represent the data structures defined in an XML Schema! http://cutter.rexx.com/~dkuhlman/generateDS.html#django-generating-models-and-forms
>>
>> I suppose gedcomX aims to parse/validate genealogical content via their servers. Same idea with most web applications.
> 
> Yeah, that seems to be FamilySearch's focus. It's unfortunate, because using RDF to specify class dependencies is bulky and hides intent. I haven't yet been able to get Ryan to see that, but maybe Tom's simplification in #173 will get some traction.
>> But there is no technical reasons for that: we can already check XML syntax and content on desktop/client applications without external connexion. We can use script (even pure python validator) for testing XML. Both performed and tested under Gramps for Gramps XML (1.5.0).
>>
>> Your issue (#173; gedcomX) is also something that need a solution, else few client applications will use these RDF resources...
>>
> 
> I'm not so sure that mere size is that much of an issue. Thanks to online video people are pretty blasé about sending around a couple of gigabytes. IMO the RDF morass is a bigger problem, because there's no simple way to validate that a URI points to what you think that it should -- or even that it points to anything.
> 
> Regards,
> John Ralls
> 
> 
> 
> Regards,
> John Ralls
> 
> 
> 
>