Questiions on gedcom REFN strategy

[jgsack]

This is probably not urgent, but should eventually be attended to.

It came up while examining whether sample gedcom from
   http://bugs.gramps-project.org/view.php?id=673
was doing bad things with imported REFN data.

The original problem was lost or truncated NOTE data, which I confirmed
is now fixed, and I decided the REFN was "not a problem" in view of my
interpretation of 2.2.x design with respect to REFN.

But in looking into REFN (from FTM output in this case) handling, I came
up with some observations and questions which I try to express here.

- - -

It appears that gedcom REFN support in Gramps 2.2.x is kind of primitive
and is somewhat different/improved in Version 3.0 although still minimal.

For INDI records,
 2.2.x seems to process an imported REFN but ignore the numeric
value(!). on export, REFN lines seem to simply echo the numeric ID values.
 3.0   seems to save the imported value and faithfully export that value

For FAM (and other records?)
 2.2.x code ignores any REFN element, but exports an REFN (echoes ID)
 3.0   saves and emits FAM REFNs, but I haven't checked other REFNs

The spec (5.5 or 5.5.1) says:
"""
USER_REFERENCE_NUMBER: = {Size=1:20}
A user-defined number or text that the submitter uses to identify this
record. For instance, it may be a record number within the submitter's
automated or manual system, or it may be a page and position number on a
pedigree chart.
"""
(Multiple) REFNs are permitted in any of the mainline records.

==> I'm inclined not to fuss about 2.2.x behavior.

..but it does strike me that the specified purpose is reasonable, namely
that of providing traceability to a submitter's record-keeping system.
However, I don't really know how important it is to serious genealogy users.

In some sense, the entire idea might be considered redundant with the
source concept. I do wonder how significant traceability to a
submitter's (presumeably unpublished) record is in a research sense.

The spec does not (specifically) say how to associate any given REFN
with a SUBM, but does provide a sub-element (TYPE <USER_REFERENCE_TYPE>)
to REFN, which may be the intended use of that sub-element.

If I'm not mistaken, we do NOT provide for submitter information in the
Gramps database (eg the XML dtd, etc). In fact there is evidence that
SUBM (submitter record or xref) may at one time have been confused with
SUBN (submission record).

If we do not link REFN with (some) SUBM, one might say it is meaningless
to pass-through the imported REFN value.Especially without any
sub-element TYPE, mentioned above.

Along the way, I noted that in 3.0, we misuse the FACT element which is
defined as part of an INDIVIDUAL_ATTRIBUTE_STRUCTURE by using it in a
family record to hold a REFN obtained via import.  The spec provides
INDIVIDUAL_ATTRIBUTE_STRUCTURE as part of an INDI but not a FAM record.

The whole REFN (and SUBM) handling could use a strategy review.

Recap:
 REFN seems not very meaningful without support for SUBM
 SUBM and REFN may require XML revision
 What do users need/want?

I apologize for a kind of disorganized post. I just wanted to get it
written down and out-there.

Regards,
..jim

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Benny Malengier]

I think the best way to handle these kind of issues is in collaboration with a user who needs the functionality.
Just working on your own to interpret the gedcom standard can be difficult I think.
I for example have no idea what to think about REFN, SUBM, SUBN, as the use case is lost on me.

Benny

2008/1/5, James G. Sack (jim) <[hidden email]>:

This is probably not urgent, but should eventually be attended to.

It came up while examining whether sample gedcom from
   http://bugs.gramps-project.org/view.php?id=673
was doing bad things with imported REFN data.

The original problem was lost or truncated NOTE data, which I confirmed
is now fixed, and I decided the REFN was "not a problem" in view of my
interpretation of 2.2.x design with respect to REFN.

But in looking into REFN (from FTM output in this case) handling, I came
up with some observations and questions which I try to express here.

- - -

It appears that gedcom REFN support in Gramps 2.2.x is kind of primitive
and is somewhat different/improved in Version 3.0 although still minimal.

For INDI records,
2.2.x seems to process an imported REFN but ignore the numeric
value(!). on export, REFN lines seem to simply echo the numeric ID values.
3.0   seems to save the imported value and faithfully export that value

For FAM (and other records?)
2.2.x code ignores any REFN element, but exports an REFN (echoes ID)
3.0   saves and emits FAM REFNs, but I haven't checked other REFNs

The spec (5.5 or 5.5.1) says:
"""
USER_REFERENCE_NUMBER: = {Size=1:20}
A user-defined number or text that the submitter uses to identify this
record. For instance, it may be a record number within the submitter's
automated or manual system, or it may be a page and position number on a
pedigree chart.
"""
(Multiple) REFNs are permitted in any of the mainline records.

==> I'm inclined not to fuss about 2.2.x behavior.

..but it does strike me that the specified purpose is reasonable, namely
that of providing traceability to a submitter's record-keeping system.
However, I don't really know how important it is to serious genealogy users.

In some sense, the entire idea might be considered redundant with the
source concept. I do wonder how significant traceability to a
submitter's (presumeably unpublished) record is in a research sense.

The spec does not (specifically) say how to associate any given REFN
with a SUBM, but does provide a sub-element (TYPE <USER_REFERENCE_TYPE>)
to REFN, which may be the intended use of that sub-element.

If I'm not mistaken, we do NOT provide for submitter information in the
Gramps database (eg the XML dtd, etc). In fact there is evidence that
SUBM (submitter record or xref) may at one time have been confused with
SUBN (submission record).

If we do not link REFN with (some) SUBM, one might say it is meaningless
to pass-through the imported REFN value.Especially without any
sub-element TYPE, mentioned above.

Along the way, I noted that in 3.0, we misuse the FACT element which is
defined as part of an INDIVIDUAL_ATTRIBUTE_STRUCTURE by using it in a
family record to hold a REFN obtained via import.  The spec provides
INDIVIDUAL_ATTRIBUTE_STRUCTURE as part of an INDI but not a FAM record.

The whole REFN (and SUBM) handling could use a strategy review.

Recap:
REFN seems not very meaningful without support for SUBM
SUBM and REFN may require XML revision
What do users need/want?

I apologize for a kind of disorganized post. I just wanted to get it
written down and out-there.

Regards,
..jim

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Julio Sánchez-2]

Jim,

I think that the GEDCOM designers had two different things in mind when they designed REFN.  On the one hand, they provided a way for a user-managed identifer (as opposed to the GEDCOM ID), whose role, as you point out could be covered perfectly by a source reference (using the page field to hold that number).  Or a custom attribute.  I have such id for some of my people and at some time in the past I used a custom attribute though later I settled for the source reference method.  If I had had REFN support maybe I would have used instead of the custom attribute and I might have not converted them to source references though, in restrospect, I like the source reference more.

The second usage they might have had in mind is that of a structured id able to be used for record matching.  I think this experiment has failed and the nonstandard _UID tag has taken its place.

So I think we should only think of it as if it was a user-maintained field.

Regards,

Julio

2008/1/5, James G. Sack (jim) <[hidden email]>:

This is probably not urgent, but should eventually be attended to.

It came up while examining whether sample gedcom from
   http://bugs.gramps-project.org/view.php?id=673
was doing bad things with imported REFN data.

The original problem was lost or truncated NOTE data, which I confirmed
is now fixed, and I decided the REFN was "not a problem" in view of my
interpretation of 2.2.x design with respect to REFN.

But in looking into REFN (from FTM output in this case) handling, I came
up with some observations and questions which I try to express here.

- - -

It appears that gedcom REFN support in Gramps 2.2.x is kind of primitive
and is somewhat different/improved in Version 3.0 although still minimal.

For INDI records,
2.2.x seems to process an imported REFN but ignore the numeric
value(!). on export, REFN lines seem to simply echo the numeric ID values.
3.0   seems to save the imported value and faithfully export that value

For FAM (and other records?)
2.2.x code ignores any REFN element, but exports an REFN (echoes ID)
3.0   saves and emits FAM REFNs, but I haven't checked other REFNs

The spec (5.5 or 5.5.1) says:
"""
USER_REFERENCE_NUMBER: = {Size=1:20}
A user-defined number or text that the submitter uses to identify this
record. For instance, it may be a record number within the submitter's
automated or manual system, or it may be a page and position number on a
pedigree chart.
"""
(Multiple) REFNs are permitted in any of the mainline records.

==> I'm inclined not to fuss about 2.2.x behavior.

..but it does strike me that the specified purpose is reasonable, namely
that of providing traceability to a submitter's record-keeping system.
However, I don't really know how important it is to serious genealogy users.

In some sense, the entire idea might be considered redundant with the
source concept. I do wonder how significant traceability to a
submitter's (presumeably unpublished) record is in a research sense.

The spec does not (specifically) say how to associate any given REFN
with a SUBM, but does provide a sub-element (TYPE <USER_REFERENCE_TYPE>)
to REFN, which may be the intended use of that sub-element.

If I'm not mistaken, we do NOT provide for submitter information in the
Gramps database (eg the XML dtd, etc). In fact there is evidence that
SUBM (submitter record or xref) may at one time have been confused with
SUBN (submission record).

If we do not link REFN with (some) SUBM, one might say it is meaningless
to pass-through the imported REFN value.Especially without any
sub-element TYPE, mentioned above.

Along the way, I noted that in 3.0, we misuse the FACT element which is
defined as part of an INDIVIDUAL_ATTRIBUTE_STRUCTURE by using it in a
family record to hold a REFN obtained via import.  The spec provides
INDIVIDUAL_ATTRIBUTE_STRUCTURE as part of an INDI but not a FAM record.

The whole REFN (and SUBM) handling could use a strategy review.

Recap:
REFN seems not very meaningful without support for SUBM
SUBM and REFN may require XML revision
What do users need/want?

I apologize for a kind of disorganized post. I just wanted to get it
written down and out-there.

Regards,
..jim

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel