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.linton@gmail.com>
To: "gramps-devel@lists.sourceforge.net List" <gramps-devel@lists.sourceforge.net>
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
Gramps-devel@lists.sourceforge.net
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 Gramps-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gramps-devel