From: Tim L. <guy...@gm...> - 2012-02-28 16:23:12
|
I agree with Benny when he says "I would not silently ignore things GRAMPS does not import. There is no Way I see the user would know he does not want that imported." [1] The roadmap for 3.2 and 3.4 [2] proposes a GEDCOM import error/ warnings report. I have raised bug 0005599 [3] for this. In revision 18815 [4a][4b] I have implemented a report dialogue box for GEDCOM import, showing lines that were not imported. I have made a number of subsequent fixes where there are more places where lines are ignored silently. At the same time as I implemented the report, it was easy to include code that would store data that is not imported. Data related to people, families, notes etc. is stored as notes attached to those objects, and submitter data is stored as repositories attached to the 'default source' (simply because repository objects have the data items necessary). I also extended the data items in the 'default source' to store more of the header and submission information. I know that some people (e.g. Tamara Jones [5]) deprecate adding notes, but this seems the most sensible way to preserve data, especially in view of the fact that Gramps does not have the same data model as GEDCOM, so there are bound to be some things that Gramps cannot sensibly import. There are several ways to control the storage of additional data: (1) Store data in the 'default source' if the 'default source' option is selected. (2) Store data in the 'default source' anyway. (3) Store the data anyway. (4) Store the data if an option is selected. (a) Attach the default source to objects anyway (b) Attach the default source to objects if an option is selected. (c) attach the data to objects (d) Attach the data to objects if an option is selected. I have chosen (1b) for submitter and submission and (3c) for notes for ignored data. (1b) is consistent with the current handling for default source and (3c) prevent data loss without requiring an extra option for the user to take care of. I would prefer to choose (2b) for submitter and submission. In other words, store the information about the import anyway (to hold a true record of what happened) but only attach it to what may be masses of objects if the user wants that. I would prefer to retain option (3c) for notes, despite Tamura Jones' comments because I think users will want to keep the information. But if we want to satisfy Tamura, we could go to (4d) - a single option to store ignored data in notes and attach them to the relevant objects - but this would be at the expense of complicating the user interface for preferences by an extra option. So, what do you think (obviously not for changing in 3.4.0). Should the creating of the 'default source' with its associated information be made unconditional with just its attachment to objects the subject of an option. And should an option be introduced to prevent the creation and attachment of notes about non-imported data. [1] in http://www.gramps-project.org/bugs/view.php?id=1360#c3705 (0001360: Gedcom input: SUBN and SUBM record handling) [2] http://www.gramps-project.org/wiki/index.php?title=3.4_Roadmap#Minor_goals [3] http://www.gramps-project.org/bugs/view.php?id=5599 [4a] http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18815 [4b] http://gramps.1791082.n4.nabble.com/GEDCOM-import-report-td4353333.html [5] http://www.tamurajones.net/Geves2.0Beta.xhtml "A general problem...shares a few design errors with several other applications; when it does not recognise a non-standard GEDCOM tag...it modifies your database by adding notes for tags it does not recognise" |
From: Gary B. <bur...@ya...> - 2012-02-28 18:38:48
|
Hello Tim Storing data as an attribute might be a better alternative to using notes for Gedcom data for which Gramps has no natural home. I think all primary and secondary Gramps objects come with an attribute or data tab on which parameter/value pair can be stored. The parameter could be named the same as the Gedcom tag. The challenge would be determining the most appropriate Gramps object to host the unhandled data. Bye Gary >________________________________ > From: Tim Lyons <guy...@gm...> >To: "gra...@li... List" <gra...@li...> >Sent: Tuesday, 28 February 2012, 16:22 >Subject: [Gramps-devel] GEDCOM import: how to handle things Gramps does not import. > >I agree with Benny when he says "I would not silently ignore things >GRAMPS does not import. There is no Way I see the user would know he >does not want that imported." [1] > >The roadmap for 3.2 and 3.4 [2] proposes a GEDCOM import error/ >warnings report. I have raised bug 0005599 [3] for this. > >In revision 18815 [4a][4b] I have implemented a report dialogue box >for GEDCOM import, showing lines that were not imported. I have made a >number of subsequent fixes where there are more places where lines are >ignored silently. At the same time as I implemented the report, it was >easy to include code that would store data that is not imported. Data >related to people, families, notes etc. is stored as notes attached to >those objects, and submitter data is stored as repositories attached >to the 'default source' (simply because repository objects have the >data items necessary). I also extended the data items in the 'default >source' to store more of the header and submission information. > >I know that some people (e.g. Tamara Jones [5]) deprecate adding >notes, but this seems the most sensible way to preserve data, >especially in view of the fact that Gramps does not have the same data >model as GEDCOM, so there are bound to be some things that Gramps >cannot sensibly import. > >There are several ways to control the storage of additional data: > >(1) Store data in the 'default source' if the 'default source' option >is selected. > >(2) Store data in the 'default source' anyway. > >(3) Store the data anyway. > >(4) Store the data if an option is selected. > > >(a) Attach the default source to objects anyway > >(b) Attach the default source to objects if an option is selected. > >(c) attach the data to objects > >(d) Attach the data to objects if an option is selected. > >I have chosen (1b) for submitter and submission and (3c) for notes for >ignored data. (1b) is consistent with the current handling for default >source and (3c) prevent data loss without requiring an extra option >for the user to take care of. > >I would prefer to choose (2b) for submitter and submission. In other >words, store the information about the import anyway (to hold a true >record of what happened) but only attach it to what may be masses of >objects if the user wants that. > >I would prefer to retain option (3c) for notes, despite Tamura Jones' >comments because I think users will want to keep the information. But >if we want to satisfy Tamura, we could go to (4d) - a single option to >store ignored data in notes and attach them to the relevant objects - >but this would be at the expense of complicating the user interface >for preferences by an extra option. > >So, what do you think (obviously not for changing in 3.4.0). Should >the creating of the 'default source' with its associated information >be made unconditional with just its attachment to objects the subject >of an option. And should an option be introduced to prevent the >creation and attachment of notes about non-imported data. > > > >[1] in http://www.gramps-project.org/bugs/view.php?id=1360#c3705 >(0001360: Gedcom input: SUBN and SUBM record handling) >[2] http://www.gramps-project.org/wiki/index.php?title=3.4_Roadmap#Minor_goals >[3] http://www.gramps-project.org/bugs/view.php?id=5599 >[4a] http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18815 >[4b] http://gramps.1791082.n4.nabble.com/GEDCOM-import-report-td4353333.html >[5] http://www.tamurajones.net/Geves2.0Beta.xhtml "A general >problem...shares a few design >errors with several other applications; when it does not recognise a >non-standard GEDCOM tag...it modifies your database by adding notes >for tags it does not recognise" > >------------------------------------------------------------------------------ >Keep Your Developer Skills Current with LearnDevNow! >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-d2d >_______________________________________________ >Gramps-devel mailing list >Gra...@li... >https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > |
From: Jérôme <rom...@ya...> - 2012-02-28 18:50:55
|
Gary, Alternatively, one note can store all ignored data and additional descriptions (also translated) into one object and might be easier to handle by users? > I think all primary and secondary Gramps objects come with an attribute or data tab > on which parameter/value pair can be stored. Primary: Place, Repository, Notes objects ? Secondary: Attribute, LDS !!! > The parameter could be named the same as the Gedcom tag. This type of mixed model seems to be already used, see keys/values into Data items (Source/citations). ;) Regards, Jérôme Gary Burton a écrit : > Hello Tim > > Storing data as an attribute might be a better alternative to using > notes for Gedcom data for which Gramps has no natural home. I think all > primary and secondary Gramps objects come with an attribute or data tab > on which parameter/value pair can be stored. The parameter could be > named the same as the Gedcom tag. > > The challenge would be determining the most appropriate Gramps object to > host the unhandled data. > > Bye > > Gary > > *From:* Tim Lyons <guy...@gm...> > *To:* "gra...@li... List" > <gra...@li...> > *Sent:* Tuesday, 28 February 2012, 16:22 > *Subject:* [Gramps-devel] GEDCOM import: how to handle things Gramps > does not import. > > I agree with Benny when he says "I would not silently ignore things > GRAMPS does not import. There is no Way I see the user would know he > does not want that imported." [1] > > The roadmap for 3.2 and 3.4 [2] proposes a GEDCOM import error/ > warnings report. I have raised bug 0005599 [3] for this. > > In revision 18815 [4a][4b] I have implemented a report dialogue box > for GEDCOM import, showing lines that were not imported. I have made a > number of subsequent fixes where there are more places where lines are > ignored silently. At the same time as I implemented the report, it was > easy to include code that would store data that is not imported. Data > related to people, families, notes etc. is stored as notes attached to > those objects, and submitter data is stored as repositories attached > to the 'default source' (simply because repository objects have the > data items necessary). I also extended the data items in the 'default > source' to store more of the header and submission information. > > I know that some people (e.g. Tamara Jones [5]) deprecate adding > notes, but this seems the most sensible way to preserve data, > especially in view of the fact that Gramps does not have the same data > model as GEDCOM, so there are bound to be some things that Gramps > cannot sensibly import. > > There are several ways to control the storage of additional data: > > (1) Store data in the 'default source' if the 'default source' option > is selected. > > (2) Store data in the 'default source' anyway. > > (3) Store the data anyway. > > (4) Store the data if an option is selected. > > > (a) Attach the default source to objects anyway > > (b) Attach the default source to objects if an option is selected. > > (c) attach the data to objects > > (d) Attach the data to objects if an option is selected. > > I have chosen (1b) for submitter and submission and (3c) for notes for > ignored data. (1b) is consistent with the current handling for default > source and (3c) prevent data loss without requiring an extra option > for the user to take care of. > > I would prefer to choose (2b) for submitter and submission. In other > words, store the information about the import anyway (to hold a true > record of what happened) but only attach it to what may be masses of > objects if the user wants that. > > I would prefer to retain option (3c) for notes, despite Tamura Jones' > comments because I think users will want to keep the information. But > if we want to satisfy Tamura, we could go to (4d) - a single option to > store ignored data in notes and attach them to the relevant objects - > but this would be at the expense of complicating the user interface > for preferences by an extra option. > > So, what do you think (obviously not for changing in 3.4.0). Should > the creating of the 'default source' with its associated information > be made unconditional with just its attachment to objects the subject > of an option. And should an option be introduced to prevent the > creation and attachment of notes about non-imported data. > > > > [1] in http://www.gramps-project.org/bugs/view.php?id=1360#c3705 > (0001360: Gedcom input: SUBN and SUBM record handling) > [2] > http://www.gramps-project.org/wiki/index.php?title=3.4_Roadmap#Minor_goals > [3] http://www.gramps-project.org/bugs/view.php?id=5599 > [4a] > http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18815 > <http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18815> > [4b] > http://gramps.1791082.n4.nabble.com/GEDCOM-import-report-td4353333.html > [5] http://www.tamurajones.net/Geves2.0Beta.xhtml "A general > problem...shares a few design > errors with several other applications; when it does not recognise a > non-standard GEDCOM tag...it modifies your database by adding notes > for tags it does not recognise" > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Gary B. <bur...@ya...> - 2012-02-28 20:56:05
|
Hello Jerome, I should have qualified my statement by saying that I hadn't checked :) > I think all primary and secondary Gramps objects come with an attribute or data tab on which parameter/value pair can be stored. > >Primary: Place, Repository, Notes objects ? >Secondary: Attribute, LDS !!! For consistency, perhaps those primary objects should include attribute/data tabs too. Also on the subject of consistency, I see we are not consistent on naming these tabs. Sometimes we call it 'Data' (e.g. source editor) and sometimes 'Attributes' (event editor). Bye Gary |
From: Nick H. <nic...@ho...> - 2012-02-28 22:03:17
|
On 28/02/12 20:55, Gary Burton wrote: > > Hello Jerome, > > I should have qualified my statement by saying that I hadn't checked :) > >> I think all primary and secondary Gramps objects come with an attribute or data tab on which parameter/value pair can be stored. >> >> Primary: Place, Repository, Notes objects ? >> Secondary: Attribute, LDS !!! > > For consistency, perhaps those primary objects should include attribute/data tabs too. Also on the subject of consistency, I see we are not consistent on naming these tabs. Sometimes we call it 'Data' (e.g. source editor) and sometimes 'Attributes' (event editor). Attributes are Data items which can have a Source. This is why there are Data tabs for Citation/Source/Repository and not Attribute tabs. > Bye > > Gary > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |
From: jerome <rom...@ya...> - 2012-02-29 07:51:38
|
Note, the behavior is not the same and we cannot re-order data items... It seems there was a post and/or bug report for that? --- En date de : Mar 28.2.12, Nick Hall <nic...@ho...> a écrit : > De: Nick Hall <nic...@ho...> > Objet: Re: [Gramps-devel] GEDCOM import: how to handle things Gramps does not import. > À: gra...@li... > Date: Mardi 28 février 2012, 23h03 > On 28/02/12 20:55, Gary Burton > wrote: > > > > Hello Jerome, > > > > I should have qualified my statement by saying that I > hadn't checked :) > > > >> I think all primary and secondary Gramps objects > come with an attribute or data tab on which parameter/value > pair can be stored. > >> > >> Primary: Place, Repository, Notes objects ? > >> Secondary: Attribute, LDS !!! > > > > For consistency, perhaps those primary objects should > include attribute/data tabs too. Also on the subject of > consistency, I see we are not consistent on naming these > tabs. Sometimes we call it 'Data' (e.g. source editor) and > sometimes 'Attributes' (event editor). > > Attributes are Data items which can have a Source. > This is why there > are Data tabs for Citation/Source/Repository and not > Attribute tabs. > > > > Bye > > > > Gary > > > > > > > ------------------------------------------------------------------------------ > > Keep Your Developer Skills Current with LearnDevNow! > > 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-d2d > > _______________________________________________ > > Gramps-devel mailing list > > Gra...@li... > > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2012-02-29 09:10:18
|
Correct. Data is stored as a python dictionary (unordered). Attributes are stored as a list (ordered) of Attribute objects. On 29/02/12 07:51, jerome wrote: > Note, the behavior is not the same and we cannot re-order data items... > It seems there was a post and/or bug report for that? > > > --- En date de : Mar 28.2.12, Nick Hall<nic...@ho...> a écrit : > >> De: Nick Hall<nic...@ho...> >> Objet: Re: [Gramps-devel] GEDCOM import: how to handle things Gramps does not import. >> À: gra...@li... >> Date: Mardi 28 février 2012, 23h03 >> On 28/02/12 20:55, Gary Burton >> wrote: >>> Hello Jerome, >>> >>> I should have qualified my statement by saying that I >> hadn't checked :) >>>> I think all primary and secondary Gramps objects >> come with an attribute or data tab on which parameter/value >> pair can be stored. >>>> Primary: Place, Repository, Notes objects ? >>>> Secondary: Attribute, LDS !!! >>> For consistency, perhaps those primary objects should >> include attribute/data tabs too. Also on the subject of >> consistency, I see we are not consistent on naming these >> tabs. Sometimes we call it 'Data' (e.g. source editor) and >> sometimes 'Attributes' (event editor). >> >> Attributes are Data items which can have a Source. >> This is why there >> are Data tabs for Citation/Source/Repository and not >> Attribute tabs. >> >> >>> Bye >>> >>> Gary >>> >>> >>> >> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> 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-d2d >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >>> >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> 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-d2d >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel >> > |
From: Benny M. <ben...@gm...> - 2012-03-05 13:52:59
|
2012/2/29 Nick Hall <nic...@ho...>: > Correct. > > Data is stored as a python dictionary (unordered). > > Attributes are stored as a list (ordered) of Attribute objects. One of the things we should fix, unfortunately, a quite extensive fix for such a small thing (database upgrade as it is pickled data in the db). Benny > > > On 29/02/12 07:51, jerome wrote: >> Note, the behavior is not the same and we cannot re-order data items... >> It seems there was a post and/or bug report for that? >> >> >> --- En date de : Mar 28.2.12, Nick Hall<nic...@ho...> a écrit : >> >>> De: Nick Hall<nic...@ho...> >>> Objet: Re: [Gramps-devel] GEDCOM import: how to handle things Gramps does not import. >>> À: gra...@li... >>> Date: Mardi 28 février 2012, 23h03 >>> On 28/02/12 20:55, Gary Burton >>> wrote: >>>> Hello Jerome, >>>> >>>> I should have qualified my statement by saying that I >>> hadn't checked :) >>>>> I think all primary and secondary Gramps objects >>> come with an attribute or data tab on which parameter/value >>> pair can be stored. >>>>> Primary: Place, Repository, Notes objects ? >>>>> Secondary: Attribute, LDS !!! >>>> For consistency, perhaps those primary objects should >>> include attribute/data tabs too. Also on the subject of >>> consistency, I see we are not consistent on naming these >>> tabs. Sometimes we call it 'Data' (e.g. source editor) and >>> sometimes 'Attributes' (event editor). >>> >>> Attributes are Data items which can have a Source. >>> This is why there >>> are Data tabs for Citation/Source/Repository and not >>> Attribute tabs. >>> >>> >>>> Bye >>>> >>>> Gary >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>>> Keep Your Developer Skills Current with LearnDevNow! >>>> 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-d2d >>>> _______________________________________________ >>>> Gramps-devel mailing list >>>> Gra...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Keep Your Developer Skills Current with LearnDevNow! >>> 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-d2d >>> _______________________________________________ >>> Gramps-devel mailing list >>> Gra...@li... >>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>> >> > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: jerome <rom...@ya...> - 2012-02-29 07:49:24
|
Hello Gary, > For consistency, perhaps those primary objects should > include attribute/data tabs too. If so, we might also try to use custom tags with value only !!! Sorry, but how we will understand something like _TKE: yes; RATY: on 1856; BLAB: with uncle John; COOR: 154'56''00, etc ... Same way with tags objects (which are also custom gedcom's tags!): '_TKE: yes', 'RATY: on 1856', 'BLAB: with uncle John', 'COOR: 154'56''00'. The thing with tag is also a temporary way to mark some data and can be easily removed, with custom attributes this becomes harder. There is no common dictionary for custom or valid tag/token and this might grow into our data with less chance to understand what it is. > I should have qualified my statement by saying that I hadn't > checked :) No problem, I assume you thought on level. //I just looked at DB objects on last days and having a simple hierarchical overview[1] gave me a better view on current DB design. We can also see where this could be improved by using more hlink and primary objects???// If level logic, as gedcom is person centric, we can imagine that children levels are all related to a person or a family. Even notes, repositories, places, attributes/facts with data not imported could have a reference added on the top level (person/family). There will be some problems with submit/header data not handled on import, but I guess this is also on possible way? [1] http://gramps-project.org/wiki/images/5/50/Xpaths.gz regards, Jérôme --- En date de : Mar 28.2.12, Gary Burton <bur...@ya...> a écrit : > De: Gary Burton <bur...@ya...> > Objet: Re: [Gramps-devel] GEDCOM import: how to handle things Gramps does not import. > À: "gra...@li... List" <gra...@li...> > Date: Mardi 28 février 2012, 21h55 > > > Hello Jerome, > > I should have qualified my statement by saying that I hadn't > checked :) > > > I think all primary and secondary Gramps objects come > with an attribute or data tab on which parameter/value pair > can be stored. > > > >Primary: Place, Repository, Notes objects ? > >Secondary: Attribute, LDS !!! > > > For consistency, perhaps those primary objects should > include attribute/data tabs too. Also on the subject of > consistency, I see we are not consistent on naming these > tabs. Sometimes we call it 'Data' (e.g. source editor) and > sometimes 'Attributes' (event editor). > > Bye > > Gary > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |
From: Nick H. <nic...@ho...> - 2012-02-28 19:36:55
|
Yes, using Attributes is a good idea. On 28/02/12 18:38, Gary Burton wrote: > Hello Tim > > Storing data as an attribute might be a better alternative to using > notes for Gedcom data for which Gramps has no natural home. I think > all primary and secondary Gramps objects come with an attribute or > data tab on which parameter/value pair can be stored. The parameter > could be named the same as the Gedcom tag. > > The challenge would be determining the most appropriate Gramps object > to host the unhandled data. > > Bye > > Gary > > ------------------------------------------------------------------------ > *From:* Tim Lyons <guy...@gm...> > *To:* "gra...@li... List" > <gra...@li...> > *Sent:* Tuesday, 28 February 2012, 16:22 > *Subject:* [Gramps-devel] GEDCOM import: how to handle things > Gramps does not import. > > I agree with Benny when he says "I would not silently ignore things > GRAMPS does not import. There is no Way I see the user would know he > does not want that imported." [1] > > The roadmap for 3.2 and 3.4 [2] proposes a GEDCOM import error/ > warnings report. I have raised bug 0005599 [3] for this. > > In revision 18815 [4a][4b] I have implemented a report dialogue box > for GEDCOM import, showing lines that were not imported. I have > made a > number of subsequent fixes where there are more places where lines > are > ignored silently. At the same time as I implemented the report, it > was > easy to include code that would store data that is not imported. Data > related to people, families, notes etc. is stored as notes > attached to > those objects, and submitter data is stored as repositories attached > to the 'default source' (simply because repository objects have the > data items necessary). I also extended the data items in the 'default > source' to store more of the header and submission information. > > I know that some people (e.g. Tamara Jones [5]) deprecate adding > notes, but this seems the most sensible way to preserve data, > especially in view of the fact that Gramps does not have the same > data > model as GEDCOM, so there are bound to be some things that Gramps > cannot sensibly import. > > There are several ways to control the storage of additional data: > > (1) Store data in the 'default source' if the 'default source' option > is selected. > > (2) Store data in the 'default source' anyway. > > (3) Store the data anyway. > > (4) Store the data if an option is selected. > > > (a) Attach the default source to objects anyway > > (b) Attach the default source to objects if an option is selected. > > (c) attach the data to objects > > (d) Attach the data to objects if an option is selected. > > I have chosen (1b) for submitter and submission and (3c) for notes > for > ignored data. (1b) is consistent with the current handling for > default > source and (3c) prevent data loss without requiring an extra option > for the user to take care of. > > I would prefer to choose (2b) for submitter and submission. In other > words, store the information about the import anyway (to hold a true > record of what happened) but only attach it to what may be masses of > objects if the user wants that. > > I would prefer to retain option (3c) for notes, despite Tamura Jones' > comments because I think users will want to keep the information. But > if we want to satisfy Tamura, we could go to (4d) - a single > option to > store ignored data in notes and attach them to the relevant objects - > but this would be at the expense of complicating the user interface > for preferences by an extra option. > > So, what do you think (obviously not for changing in 3.4.0). Should > the creating of the 'default source' with its associated information > be made unconditional with just its attachment to objects the subject > of an option. And should an option be introduced to prevent the > creation and attachment of notes about non-imported data. > > > > [1] in http://www.gramps-project.org/bugs/view.php?id=1360#c3705 > (0001360: Gedcom input: SUBN and SUBM record handling) > [2] > http://www.gramps-project.org/wiki/index.php?title=3.4_Roadmap#Minor_goals > [3] http://www.gramps-project.org/bugs/view.php?id=5599 > [4a] > http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18815 > <http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18815> > [4b] > http://gramps.1791082.n4.nabble.com/GEDCOM-import-report-td4353333.html > [5] http://www.tamurajones.net/Geves2.0Beta.xhtml "A general > problem...shares a few design > errors with several other applications; when it does not recognise a > non-standard GEDCOM tag...it modifies your database by adding notes > for tags it does not recognise" > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > <mailto:Gra...@li...> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Nick H. <nic...@ho...> - 2012-02-28 19:22:08
|
Tim, Thanks for looking at these GEDCOM issues. I think you have made a good summary of the options. My preferences would be: For submitter and submission I don't really mind, but would be happy to stick with (1b). However, If you decided on (2b) it would be very easy to delete the extra source record after the import. We should warn the user that it has been created though. For non-standard tags I would prefer (4d). The user should have an option "Import non-standard tags as notes". If (3c) is chosen, then I think we need to tool to remove the possibly unwanted extra notes. Regards, Nick. On 28/02/12 16:22, Tim Lyons wrote: > I agree with Benny when he says "I would not silently ignore things > GRAMPS does not import. There is no Way I see the user would know he > does not want that imported." [1] > > The roadmap for 3.2 and 3.4 [2] proposes a GEDCOM import error/ > warnings report. I have raised bug 0005599 [3] for this. > > In revision 18815 [4a][4b] I have implemented a report dialogue box > for GEDCOM import, showing lines that were not imported. I have made a > number of subsequent fixes where there are more places where lines are > ignored silently. At the same time as I implemented the report, it was > easy to include code that would store data that is not imported. Data > related to people, families, notes etc. is stored as notes attached to > those objects, and submitter data is stored as repositories attached > to the 'default source' (simply because repository objects have the > data items necessary). I also extended the data items in the 'default > source' to store more of the header and submission information. > > I know that some people (e.g. Tamara Jones [5]) deprecate adding > notes, but this seems the most sensible way to preserve data, > especially in view of the fact that Gramps does not have the same data > model as GEDCOM, so there are bound to be some things that Gramps > cannot sensibly import. > > There are several ways to control the storage of additional data: > > (1) Store data in the 'default source' if the 'default source' option > is selected. > > (2) Store data in the 'default source' anyway. > > (3) Store the data anyway. > > (4) Store the data if an option is selected. > > > (a) Attach the default source to objects anyway > > (b) Attach the default source to objects if an option is selected. > > (c) attach the data to objects > > (d) Attach the data to objects if an option is selected. > > I have chosen (1b) for submitter and submission and (3c) for notes for > ignored data. (1b) is consistent with the current handling for default > source and (3c) prevent data loss without requiring an extra option > for the user to take care of. > > I would prefer to choose (2b) for submitter and submission. In other > words, store the information about the import anyway (to hold a true > record of what happened) but only attach it to what may be masses of > objects if the user wants that. > > I would prefer to retain option (3c) for notes, despite Tamura Jones' > comments because I think users will want to keep the information. But > if we want to satisfy Tamura, we could go to (4d) - a single option to > store ignored data in notes and attach them to the relevant objects - > but this would be at the expense of complicating the user interface > for preferences by an extra option. > > So, what do you think (obviously not for changing in 3.4.0). Should > the creating of the 'default source' with its associated information > be made unconditional with just its attachment to objects the subject > of an option. And should an option be introduced to prevent the > creation and attachment of notes about non-imported data. > > > > [1] in http://www.gramps-project.org/bugs/view.php?id=1360#c3705 > (0001360: Gedcom input: SUBN and SUBM record handling) > [2] http://www.gramps-project.org/wiki/index.php?title=3.4_Roadmap#Minor_goals > [3] http://www.gramps-project.org/bugs/view.php?id=5599 > [4a] http://gramps.svn.sourceforge.net/viewvc/gramps?view=revision&revision=18815 > [4b] http://gramps.1791082.n4.nabble.com/GEDCOM-import-report-td4353333.html > [5] http://www.tamurajones.net/Geves2.0Beta.xhtml "A general > problem...shares a few design > errors with several other applications; when it does not recognise a > non-standard GEDCOM tag...it modifies your database by adding notes > for tags it does not recognise" > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > 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-d2d > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > |