Re: [Gramps-devel] GEDCOM import: how to handle things Gramps does not import.

[Gary B. <bur...@ya...>]

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