Jump to content


Photo

Need for more info in fact description


  • Please log in to reply
22 replies to this topic

#1 NEreswearcher

NEreswearcher

    Member

  • Members
  • PipPip
  • 6 posts

Posted 04 January 2018 - 01:46 PM

I have been using Rootsmagic version 7 for about 3 years. I converted from The Master Genealogist. It was a large cleanup project since many many functions in TMG are not supported in any other product including RM7.

Now I am running into a problem that I don’t know how or cannot put the data into RM7 cleanly.

A fact allows for a date, place, place details, description, sort date, and current status of proof. That is all I can put into a fact or event. The real problem comes with the description field where RM7 severely limits the amount of data for a fact. If I have more than the 100 or so characters in the description field I am out of luck. Some people have suggested putting the additional data into the notes field which accommodates about 65,000 characters.

Nice try but all the data in the notes field is printed in reports outside of the footnotes so that the additional data is essentially unsourced. Another massive editing effort to move the data inside the footnotes field.

Putting actual event or fact data in the notes complicates using that field for anything else like proof statements or additional comments about the fact that I may or may not want printed. Printing notes is all or nothing. I have been using Personal Historian version 2 and this really complicates moving data from RM7 to PH2. PH3 may solve some issues.

Does anyone have a good solution for this?

Rootsmagic V7 is over 3 years old. Is there a new version on the way and will it address this problem?

 

A good solution would be to enhance the description field to work like the notes field thus including all the pertinent data within the footnotes.



#2 kbens0n

kbens0n

    Advanced Member

  • Members
  • PipPipPip
  • 3306 posts

Posted 04 January 2018 - 04:24 PM

A good solution would be to enhance the description field to work like the notes field thus including all the pertinent data within the footnotes.


I'm sure that the Description issue is on the Wish List. No telling whether 8.0 will deal with it differently until it's released.

---
--- "GENEALOGY, n. An account of one's descent from an ancestor who did not particularly care to trace his own." - Ambrose Bierce
--- "The trouble ain't what people don't know, it's what they know that ain't so." - Josh Billings
---Ô¿Ô---
K e V i N


#3 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 5593 posts

Posted 04 January 2018 - 04:57 PM

Fact/Event Notes do not print in Footnotes in narrative reports; they can be printed immediately following the fact/event sentence. Citations are printed as footnotes or endnotes in narrative reports, optionally with the citations Notes for Detail Text/Research Note and/or Comment. Fact/Event Notes can be printed as footnotes or endnotes on FGS and Indi Summary; likewise for citations, separately. 


Tom user of RM7230 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> Rmtrix_tiny.png app, a growing bundle of RootsMagic utilities.


#4 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2746 posts

Posted 04 January 2018 - 04:59 PM

I'm sure that the Description issue is on the Wish List. No telling whether 8.0 will deal with it differently until it's released.

 

The reason that RM does not support longer Description fields is that GEDCOM does not support longer Description fields. RM8 is therefore not likely to address this issue.

 

I like it that Description fields can have a source and a citation superscript. It's really the fact as a whole that has a source and a citation superscript; but if a fact consists only of a Description field then you have the effect that you want.

 

I do not like it that Note fields cannot have a source and a citation superscript. Again, I think the problem for RM is that GEDCOM does not support sources and (and hence citation superscripts) for notes.

 

Jerry



#5 NEreswearcher

NEreswearcher

    Member

  • Members
  • PipPip
  • 6 posts

Posted 05 January 2018 - 12:45 PM

I appreciate all your responses but in the end it looks like there will be no solution. Jerry I appreciate the fact that GEDCOM does not support a longer description but GEDCOM is so old and outdated that it should probably be scrapped for something better. It seems that every software package out there is struggling with how out of date GEDCOM is and they have made many alterations and Rootsmagic is no exception.

 

Maybe what I would like is not something that anyone else wants or needs which is ok and I should not be accommodated if I am the only one. That would not bode well for the survival of Rootsmagic.

 

Based on comments I will need to work this out for myself and arrive at a usable workaround.

 

TomH. If i read your response correctly I cannot print out a fact in a narrative report and have the Note field printed within the Footnote structure, I am assuming that the footnote number should follow the fact footnoted and not before as happens in a narrative report, Rootsmagic prints the description and then the footnote followed by the Note field. The text of the Note field will be outside the footnote so If I have an obituary and include it in Notes then that part of the event that I included in notes will not be properly footnoted.

 

Again thanks for your responses.

 

P.s. I have looked at the wish list for Rootsmagic but has anyone done any research on what the users of Rootsmagic would like?



#6 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 06 January 2018 - 09:21 AM

PLEASE DO NOT SAY: "GEDCOM is old and outdated" as a substitute for proper GEDCOM use by genealogy programs.

Jerry is not completely correct to say that "GEDCOM does not support long description", technically GEDCOM does not have a "description" tag nor do facts have any field that should be used like a description. At the very most the FACT tag has an "attribute_descriptor" tag used to describe new attributes of a person not covered in the standard set of attributes (aka facts). Description is a made up tag.

The real question is "what data do you want to add that is not found in the data model provided by RM?" Many people have additional data that should be part of the source_citation or that RM needs additional fields in its data model that may or may not be mapped to GEDCOM.

Please understand I do not believe that the GEDCOM standard is perfect, it does have a few misgivings and could have some modern touches added to areas like Source definition, default selection values for media and relationships. Some concepts for non-standard relationships (marriage for one) could be updated and ASSOC relationships could be retained at all facts not just at a personal level. But the basic concepts are strong and when all tags are supported in a software program most data can be applied to GEDCOM.

But a longer description is not a valuable reason to bash GEDCOM. NOTEs are an appropriate place to put some data, "shared notes" as defined in GEDCOM can have restrictions applied to them so potentially, if supported, can prevent printing in reports, and thus stop the all of nothing issue you described.

#7 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 06 January 2018 - 09:52 AM

Jerry,

GEDCOM does support source_citation on a NOTE record aka "shared note".

#8 NEreswearcher

NEreswearcher

    Member

  • Members
  • PipPip
  • 6 posts

Posted 06 January 2018 - 10:53 AM

I've done a little research on GEDCOM and perhaps KFN you are correct in stating that GEDCOM may support far more than the software programs allow for now. One field comes to mind that is outdated and that is the surety level of sources. Gedcom provides a single byte and a 0 to 9 values (most use only 0 - 3) to describe the quality of the source. RM7 provides the Elizabeth Shown Mills version where we have original/derivative/don't know, Primary/secondary/don't know, Direct/Indirect/Negative/Don't know and a proven/disproven/disputed. When exporting to GEDCOM all that data gets manipulated into the 0 to 3 values and a user defined _proven tag with the subsequent loss of data. RM maintains the data by using its extensions which are rejected by other software packages.

 

On the positive side I could find nothing in the GEDCOM standard that prevents using longer descriptions. RM7 outputs the description field in an EVEN tag and puts all the data into that descriptor. If I put in enough data in the description field where the total EVEN tag exceeds 255 characters then the whole EVEN tag is in violation of the GEDCOM standard and RM7 puts up to 249? characters into the NOTES field.. I see nothing in the standard, so far, that would prevent the use of the CONT or CONC tags to extend the length of the EVEN tag and thus the description field. I did a quick test and edited the GEDCOM file and changed the invalid EVEN tag to conform to the 255 character limit by using the CONC extender tag. When imported back into RM7 the EVEN tag was not put into the description field but still in the NOTES field but this time RM7 did recognize the extender CONC.

 

GEDCOM allows for user defined tags by placing an underscore in front of them. It seems everyone does this, or at least RM7 and Legacy 8. The problem with this approach is that when moving data from one person to another using different product those user defined tags are likely to be not recognized. RM7 puts out two such tags (_proven and _color). Both are very useful, conform to the GEDCOM standard but are not usable passing data between two different software packages. The standard should be flexible enough to rapidly adjust to new needs and make data transfer seamless.

 

I did not intend to get into a discussion of GEDCOM. I think my primary issue was the length of the description field. It appears that it may be possible and within the GEDCOM standard to do so but I am not holding out hope that it will be implemented any time soon - thus I need to define my own workaround.

 

One last point. The Notes field in RM7 does not appear to be structured to support actual event data. It can be either included or not at some later time - not what I would want to see in data that should be part of the event. With the Notes field being printed outside of the footnote number it appears that RM had indeed intended that field to be additional data without need for footnoting such as a proof statement or other such observations or comments.



#9 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 06 January 2018 - 11:26 AM

The length of all GEDCOM lines including level number, tag and value must not exceed 255 characters as set in the standard on page 11.

 

The EVEN/FACT tags do not allow for CONT or CONC subtags.  so multi-line events and facts are not allowed.

 

User defined tags with preceeding "_" are allowed, but that is an older holdover and facts/events are better defined using the FACT or EVEN tag and the TYPE subtag.  I can give you better examples with some real data requests.

 

The _color tag is specifically for RM7and while it can be placed in a GEDCOM I would suspect that no other program would understand its meaning or intent.  A data definition language would need to be developed as part of any GEDCOM refresh to allow this to be transmitted to other programs.

 

I'm not sure I understand your reference to quality of source.  GEDCOM only states a 0-3 for quality. 0=Unreliable, 1=Questionable (for oral interviews, census or biased data.  aka Tertiary data), 2=Secondary evidence recorded after the fact, 3=Direct or primary evidence (dominance of evidence).   In genealogy most of the people I deal with think things are proven when they find a source that states the data.  "Proven" is a little harder than that.  You must have lots of data from multiple INDEPENDENT sources.  most of the time we can only find one primary source and a lot of data that can by some be noted as "hearsay".



#10 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 06 January 2018 - 11:40 AM

Elizabeth Shown Mills "Evidence Explained" is a great product and I encourage others to begin to understand what it says.

 

However, it is only one way to record and display sourcing material.  It is rather complicated for most people to understand and correctly use.  I studied Library Science and have my Master Degree from one of the better LS schools in the nation.  Cataloging and Source Description is something we take very seriously.  ESM's sourcing model has so many variations that few really understand it well and of course GEDCOM does not support it.

 

GEDCOM has its own sourcing model which as I've discussed previously does require some updating to include better documentation of online sources, it is Book, Article and Oral History oriented. A little more geared toward an older version of Chicago Style.

 

I agree that this discussion should not be about GEDCOM, I've refrained from discussing GEDCOM over that couple of month since I was called out on it.  But I did not want to let misunderstandings of GEDCOM get published here without a little counter-point. 



#11 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 06 January 2018 - 11:57 AM

I will correct myself.  One GEDCOM FACT does allow for CONT || CONC lines to extend the "description" for an individual.  This is the DSCR tag (physical_description)
 
It can be:
 
1 DSCR 5 foot 10 inches tall
2 CONT 195 pounds
2 CONT Scar over right eye.

#12 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 2746 posts

Posted 06 January 2018 - 12:29 PM

I'm not sure what the proper GEDCOM terminology is, but RM seems to truncate description fields at 100 characters.

 

However, RM's behavior has changed recently - I think with the implementation of TreeShare. Here is a simple GEDCOM entry for a person with a 105 character description field for the birth fact. I had to enable the description field for the birth fact in order to make this GEDCOM.

 

The description field is " 0000 1111 2222" etc. without the quotes. The dummy description data is in groups of a blank and four characters to make the total number of characters very easy to count.

0 @I1@ INDI
1 NAME John /Doe/
2 GIVN John
2 SURN Doe
1 SEX M
1 _UID AB9AB198DB3848CFA692560119172FE88E05
1 CHAN
2 DATE 6 JAN 2018
1 BIRT  0000 1111 2222 3333 4444 5555 6666 7777 8888 9999 aaaa bbbb cccc dddd eeee ffff gggg hhhh iiii jjjj kkkk
2 DATE 1850
2 NOTE This is a dummy birth note.
3 CONT
3 CONT
3 CONT asdf
1 DEAT Y

If this same GEDCOM is imported into RM, then the 105 characters of description field is inserted at the beginning of the birth note and followed by a carriage return line feed. The birth description field for the imported person is empty. No data is lost, but the description field is moved to the beginning of the note field.

 

Previous to the recent change, RM would have imported the 105 character description field into the birth description and would have truncated the description field to 100 characters without warning. The last five characters would have been lost, with the lost characters being the " kkkk" at the end.

 

I also went back to the original RM database and deleted the " kkkk" characters myself, thereby reducing the number of characters in the birth description field to 100 characters. After doing so, a GEDCOM export followed by GEDCOM import cycle brings the person back into a new database with the description field still stored as the description field. It is not moved into the note.

 

Until the recent change, RM always truncated description fields over 100 characters on a GEDCOM export/import cycle. I don't have an earlier version of RM to test with, so I don't know if the truncation was on the export part of the cycle or the import part of the cycle. It is obviously the case presently that export doesn't truncate and import moves data that is too long to the note. When this problem was first reported, Bruce said that the GEDCOM standard for the description field was 100 characters.

 

Jerry



#13 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 06 January 2018 - 12:55 PM

The GEDCOM standard for the data following the fact/event tag depends specifically on the fact/event tag used.

For example:

BIRT, DEAT, CHR only allow 1 character "Y" or null

Attributes (aka facts), have various lengths as defined by GEDCOM. CAST = 90 while EDUC = 248. Others have somewhere in between.

#14 NEreswearcher

NEreswearcher

    Member

  • Members
  • PipPip
  • 6 posts

Posted 06 January 2018 - 04:54 PM

KFN

 

I am always interested in the correct information and I wonder if you would share where the correct source for GEDCOM fields is?

 

I thought I had the latest version of 5.5 and 5.5.1. My versions do not indicate the lengths that you are referring to and I did not see anything about the use of CONC and CONT as you describe.



#15 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 06 January 2018 - 06:44 PM

I have a personal copy of the 5.5.1 GEDCOM standard in hand. The CAST value is found on page 43.

#16 NEreswearcher

NEreswearcher

    Member

  • Members
  • PipPip
  • 6 posts

Posted 09 January 2018 - 10:04 AM

I looked at the family search website and found both the 5.5 and 5.5.1 standard in downloadable format. It also said that those standards are no longer maintained and they have a new standard called GEDCOM X which is a totally different concept. I would think that the new GEDCOM X will take a long while to implement across multiple vendors before the GEDCOM X will be usable for us.



#17 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 09 January 2018 - 06:17 PM

Yes GEDCM 5.5.1 is no longer being maintain and family search would have you believe GEDCOM X is the future.

Personally I think GEDCOM X is not all that different from a data standpoint than GEDCOM 5.5.1. The current focus is using modern tools and file structures, but I don't think it adds much in providing addition data points, just how the data is defined.

#18 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 75 posts

Posted 10 January 2018 - 02:58 AM

Yes GEDCM 5.5.1 is no longer being maintain and family search would have you believe GEDCOM X is the future.

Personally I think GEDCOM X is not all that different from a data standpoint than GEDCOM 5.5.1. The current focus is using modern tools and file structures, but I don't think it adds much in providing addition data points, just how the data is defined.

 

So is there a way forward for 'gedcom'? or is it likely my research may end up marooned in whatever family history programme I happen to use?



#19 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 145 posts

Posted 10 January 2018 - 07:54 AM

In my opinion, others will most likely disagree, your research (and everyone else's) is already "marooned" to some degree on the software system you currently use. This is as I see it for two reasons. Bad GEDCOM building and inconsistent databases.

Using GEDCOM to transfer data has never been a cake walk due to issues with the way the files ares built. Previously, someone discussed the made up tag _proven to indicate that a relationship of an individual to a family was "proven" to be true. GEDCOM already has such a tag as part of the child to family linkage. [challenged | disproven | proven] Are the options. There are many such made up tag that should be reformulated. While others should never be in GEDCOM.

Transferring data between programs either with GEDCOM or by direct database to database transfers is not perfect. Every software companies database is designed a little differently. We can already see that ACOM is designed differently than RM7. Each programs supports different sets of data and the way they relate to each other can be very different. Some for instance don't support multiple names or have the ability to support international nameing conventions, for instance patronymic names, surnames based on gender, or multiple surnames in the Portuguese style, Asian names and characters. Date storage in databases can be problematic is some databases. And other data issues exist.

Most of these issues make it hard for almost everyone to move from program to program OR to have multiple programs and use them and their features interchangeably. I tried to own several programs to give my clients the best of many different reports or websites or color coding, (no one program is the best) but data interchangeably is non-existent, therefore I pick the best I can, and because I am a programmer and database designer in my real life, I can create software to augment some programs if they have an open database.

Sorry for the long post. I'll get down from my soapbox!

#20 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 75 posts

Posted 10 January 2018 - 12:08 PM

A rather disheartening situation, are we returning to the incomparability seen in early family history programmes?

I rather hope FamilySearch do get Gedcom x to float,  I cannot think of another large organisation (with out commercial interests) who would take on a gedcom replacement - or am I missing something?