From: Tim L. <guy...@gm...> - 2012-01-29 00:00:05
|
Would anyone mind if I implemented source citations on notes in order to improve compatibility with GEDCOM. I suggest doing it in trunk now because: (1) The database is being updated anyway for citations, so it would be more convenient to do the two updates at once. (2) Having done the citations update I am already familiar with the parts that need changing. (3) The change is small and simple, because it only involves adding an already existing secondary object to notes. (4) There is little extra maintenance effort because of the benefits of inheritance in Python in Gramps. (5) GEDCOM import and export code is now clean and clear, so I expect the changes to be quite simple. (6) Improved GEDCOM import compatibility is an important selling point for any genealogy program as it helps people who are changing programs. (7) As a one week special I would do it so as to upgrade existing version 16 databases as well (this would be removed later) Regards, Tim. |
From: Rob H. <rob...@gm...> - 2012-01-29 02:55:49
|
Greetings: I can truly see the benefit of doing this as I have wondered many times the why? Why is there not a Source for Notes.... I believe adding the code to Gramps would be better for those people that are changing from one software to the next greater Gramps! I also can see that adding the code to the plugins should be an easy update as well! Upgrading the database at this point like Tim says would be better to do it now rather than waiting for a minor point release. Since the database upgrade is already going on anyway! Since I have already updated my database to Citations code/ trunk, would the database take this into account and only upgrade as far as Note Sources??? Sincerely yours, Rob G. Healey On Sat, Jan 28, 2012 at 3:59 PM, Tim Lyons <guy...@gm...> wrote: > Would anyone mind if I implemented source citations on notes in order > to improve compatibility with GEDCOM. > > I suggest doing it in trunk now because: > > (1) The database is being updated anyway for citations, so it would be > more convenient to do the two updates at once. > (2) Having done the citations update I am already familiar with the > parts that need changing. > (3) The change is small and simple, because it only involves adding an > already existing secondary object to notes. > (4) There is little extra maintenance effort because of the benefits > of inheritance in Python in Gramps. > (5) GEDCOM import and export code is now clean and clear, so I expect > the changes to be quite simple. > (6) Improved GEDCOM import compatibility is an important selling point > for any genealogy program as it helps people who are changing programs. > > (7) As a one week special I would do it so as to upgrade existing > version 16 databases as well (this would be removed later) > > Regards, > Tim. > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Sincerely yours, Rob G. Healey |
From: Jérôme <rom...@ya...> - 2012-01-29 08:53:02
|
NOTE_RECORD: = n @<XREF:NOTE>@ NOTE <SUBMITTER_TEXT> {1:1} +1 [ CONC | CONT] <SUBMITTER_TEXT> {0:M} +1 <<SOURCE_CITATION>> {0:M} +1 REFN <USER_REFERENCE_NUMBER> {0:M} +2 TYPE <USER_REFERENCE_TYPE> {0:1} +1 RIN <AUTOMATED_RECORD_ID> {0:1} +1 <<CHANGE_DATE>> {0:1} http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#NOTE_RECORD NOTE_STRUCTURE: = [ n NOTE @<XREF:NOTE>@ {1:1} +1 SOUR @<XREF:SOUR>@ {0:M} | n NOTE [<SUBMITTER_TEXT> | <NULL>] {1:1} +1 [ CONC | CONT ] <SUBMITTER_TEXT> {0:M} +1 SOUR @<XREF:SOUR>@ {0:M} ] http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#NOTE_STRUCTURE This makes sense and I suppose there is some feature requests related to current limitation, like: * 5539: End-note/Footnote Source Citation References for Notes http://www.gramps-project.org/bugs/view.php?id=5539 Also, there is something specific about previous 'source reference' (current citation) with gedcom file format handling... The text from source (TEXT tag) is imported as a note. So, also exported as note and gedcom experts should not complain about this because Gramps does not loose any data, here. http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#TEXT_FROM_SOURCE It seems that source citations on notes could be added, despite the risk of the infinite loop! (Note -> Source -> Note -> Source -> Note ...) NB: this type of problem is also present on person/family (son/daughter is also its greatfather/mother) The annoying issue might be the Note filter on export or into backreferences! I reported a problem on current releases about a note ignored on filtering[1] #5058 Anyway, this problem is not about DB design. I agree with you about to implement source citations on notes. [1] http://www.gramps-project.org/bugs/view.php?id=5058 Thanks! Jérôme Tim Lyons a écrit : > Would anyone mind if I implemented source citations on notes in order > to improve compatibility with GEDCOM. > > I suggest doing it in trunk now because: > > (1) The database is being updated anyway for citations, so it would be > more convenient to do the two updates at once. > (2) Having done the citations update I am already familiar with the > parts that need changing. > (3) The change is small and simple, because it only involves adding an > already existing secondary object to notes. > (4) There is little extra maintenance effort because of the benefits > of inheritance in Python in Gramps. > (5) GEDCOM import and export code is now clean and clear, so I expect > the changes to be quite simple. > (6) Improved GEDCOM import compatibility is an important selling point > for any genealogy program as it helps people who are changing programs. > > (7) As a one week special I would do it so as to upgrade existing > version 16 databases as well (this would be removed later) > > Regards, > Tim. > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Benny M. <ben...@gm...> - 2012-01-29 10:27:24
|
Yes, I would mind. I don't think the interactions between our objects should become spaghetti. Per definition, a gramps not has no sources. If a not has a source, then it should be attached to a source, not the other way around. It is also not because GEDCOM does something, that it is a good thing. Benny 2012/1/29 Tim Lyons <guy...@gm...>: > Would anyone mind if I implemented source citations on notes in order > to improve compatibility with GEDCOM. > > I suggest doing it in trunk now because: > > (1) The database is being updated anyway for citations, so it would be > more convenient to do the two updates at once. > (2) Having done the citations update I am already familiar with the > parts that need changing. > (3) The change is small and simple, because it only involves adding an > already existing secondary object to notes. > (4) There is little extra maintenance effort because of the benefits > of inheritance in Python in Gramps. > (5) GEDCOM import and export code is now clean and clear, so I expect > the changes to be quite simple. > (6) Improved GEDCOM import compatibility is an important selling point > for any genealogy program as it helps people who are changing programs. > > (7) As a one week special I would do it so as to upgrade existing > version 16 databases as well (this would be removed later) > > Regards, > Tim. > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Benny M. <ben...@gm...> - 2012-01-29 10:39:01
|
Some more info. First, something like this defenitely is not possible before a next release. Secondly, the reason I'm against is because we need to be able to clearly explain how one should store genealogy information. That reasoning should be logical, so that we can actually put it as rules in software. The current logic is: You have people, events, ... . The case for these you build up from sources. You attach sources to them. The data of the source can be put in notes, and you can share the notes directly in the people, events, ... Otherwise, you can use notes to write down snippets of information. If you want to make a collection of deductions, you should however create a source, and add your reasoning as notes. What Gramps is missing is a fast way to find the note of a source that is relevant to the object you are viewing. Note sharing is used by some people for that. Me I start a note with an identifier that can be used for the citation. The moment we allow sources attached to a note, we introduce two different ways to do something, which will just make it more difficult to maintain the code and move forward. The probablity of duplicate notes becomes high, and the cyclic loops that Jerome talks about will be something users actually want to do, but which we can't handle in a logical way in software. So I see also big maintenance and logical problems with this idea. Benny 2012/1/29 Benny Malengier <ben...@gm...>: > Yes, I would mind. > > I don't think the interactions between our objects should become spaghetti. > > Per definition, a gramps not has no sources. If a not has a source, > then it should be attached to a source, not the other way around. > > It is also not because GEDCOM does something, that it is a good thing. > > Benny > > 2012/1/29 Tim Lyons <guy...@gm...>: >> Would anyone mind if I implemented source citations on notes in order >> to improve compatibility with GEDCOM. >> >> I suggest doing it in trunk now because: >> >> (1) The database is being updated anyway for citations, so it would be >> more convenient to do the two updates at once. >> (2) Having done the citations update I am already familiar with the >> parts that need changing. >> (3) The change is small and simple, because it only involves adding an >> already existing secondary object to notes. >> (4) There is little extra maintenance effort because of the benefits >> of inheritance in Python in Gramps. >> (5) GEDCOM import and export code is now clean and clear, so I expect >> the changes to be quite simple. >> (6) Improved GEDCOM import compatibility is an important selling point >> for any genealogy program as it helps people who are changing programs. >> >> (7) As a one week special I would do it so as to upgrade existing >> version 16 databases as well (this would be removed later) >> >> Regards, >> Tim. >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Tim L. <guy...@gm...> - 2012-01-30 23:42:50
|
On 29 Jan 2012, at 10:27, Benny Malengier wrote: > It is also not because GEDCOM does something, that it is a good thing. OK, I'll not add sources to notes! Not trying to get you to change your mind, at least not for this release:-), but just explaining some of the thinking. > The moment we allow sources attached to a note, we introduce two > different ways to do something, There are already many different ways to record things: the point about having more than one way to do record something is that some people might find one way best while other people find a different way best. I keep seeing this point made on advice given to users, with the important thing being that each individual user should be consistent in the way he stores information. > which will just make it more difficult > to maintain the code and move forward. Having multiple user interfaces to achieve the same effect is a maintenance problem, but I am not sure why sources on notes would be. > The probablity of duplicate > notes becomes high, I'm not sure why this would be true. If duplicate notes were thought to be a problem, then surely it would equally be a problem with the current arrangements, and then some automated merge (like of citations) could be implemented to help the user. > and the cyclic loops that Jerome talks about will > be something users actually want to do, Incidentally, cyclic loops were already possible, for example, Media- >Attribute->Source->Media->. I came up with recursion problems when testing out TestDataGenerator, and had to slightly change the frequency of generating some constructs so as not to get Python 'too deep recursion' errors. > but which we can't handle in a > logical way in software. I'm not sure that the software has any problems with this kind of situation. The only real impact on software is in reports, but reports are already a VERY SELECTIVE choice of exactly which elements are output. I first got into coding Gramps because one of the reports wasn't outputting something I was using (I think it was attributes of person as it happens). Regards, Tim. |
From: Benny M. <ben...@gm...> - 2012-01-31 08:44:38
|
2012/1/31 Tim Lyons <guy...@gm...>: > > On 29 Jan 2012, at 10:27, Benny Malengier wrote: > >> It is also not because GEDCOM does something, that it is a good thing. > > > > OK, I'll not add sources to notes! > > > > > > > Not trying to get you to change your mind, at least not for this release:-), > but just explaining some of the thinking. > > > > >> The moment we allow sources attached to a note, we introduce two >> different ways to do something, > > > There are already many different ways to record things: the point about > having more than one way to do record something is that some people might > find one way best while other people find a different way best. I keep > seeing this point made on advice given to users, with the important thing > being that each individual user should be consistent in the way he stores > information. Yes, but most of these don't really change the logic. Having a note that can have a source, means a note is a full object in real live (even if stored electronically), which you correctly source. Our take is that it then becomes another source. So, to keep in the Gramps objects, to do this, we might need a source which points to other sources (as done in real live, where a ternary source is created from other sources), but not a source -> note -> source. There have been some ideas around that in the past. A cyclic reference here can be avoided as the link would be: source x -- obtains data from --> source y. If then x is attached to y by the user, we can raise an error that that is logically impossible. Note that some users also would like sources to consist of a main source and then subsource objects, with the possibility of the citations to reference the subsource. This would allow a more fine grained control of the source object. Anyway, even if there are multiple ways of doing things, there should be only one somewhat official way, so that we can optimize the GUI to speed up data entry according to this. It also allows us to say: the census gramplet should work in this way, even if the data can be stored differently, our own gramplets do it the official way. Benny |
From: Jérôme <rom...@ya...> - 2012-01-31 09:04:52
|
About Gedcom file format, there is many issues. I suppose you already saw the 'shortcomings of Gedcom'[1] or others related pages[2] on the BetterGedcom wiki? About implementing 'Sources on notes' for next releases, maybe this might wait new 'BetterGedcom' or 'GedcomX' specifications? At a glance, this sounds rather like end/footnotes[3], children of a source. ie. handled on citation (text, note) or new DB objects related to source only. So, maybe a part of GEPS_018. [1] http://bettergedcom.wikispaces.com/Shortcomings+Of+GEDCOM [2] http://bettergedcom.wikispaces.com/Sources+and+Citations#GEDCOM [3] http://bettergedcom.wikispaces.com/Citation+Graphics [4] http://gramps-project.org/wiki/index.php?title=GEPS_018:_Evidence_style_sources Regards, Jérôme Tim Lyons a écrit : > On 29 Jan 2012, at 10:27, Benny Malengier wrote: > >> It is also not because GEDCOM does something, that it is a good thing. > > > OK, I'll not add sources to notes! > > > > > > > Not trying to get you to change your mind, at least not for this > release:-), but just explaining some of the thinking. > > > >> The moment we allow sources attached to a note, we introduce two >> different ways to do something, > > There are already many different ways to record things: the point > about having more than one way to do record something is that some > people might find one way best while other people find a different way > best. I keep seeing this point made on advice given to users, with the > important thing being that each individual user should be consistent > in the way he stores information. > >> which will just make it more difficult >> to maintain the code and move forward. > > Having multiple user interfaces to achieve the same effect is a > maintenance problem, but I am not sure why sources on notes would be. > >> The probablity of duplicate >> notes becomes high, > > I'm not sure why this would be true. If duplicate notes were thought > to be a problem, then surely it would equally be a problem with the > current arrangements, and then some automated merge (like of > citations) could be implemented to help the user. > >> and the cyclic loops that Jerome talks about will >> be something users actually want to do, > > Incidentally, cyclic loops were already possible, for example, Media- > >Attribute->Source->Media->. I came up with recursion problems when > testing out TestDataGenerator, and had to slightly change the > frequency of generating some constructs so as not to get Python 'too > deep recursion' errors. > >> but which we can't handle in a >> logical way in software. > > I'm not sure that the software has any problems with this kind of > situation. The only real impact on software is in reports, but reports > are already a VERY SELECTIVE choice of exactly which elements are > output. I first got into coding Gramps because one of the reports > wasn't outputting something I was using (I think it was attributes of > person as it happens). > > Regards, > Tim. > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |