Jump to content


Photo

Shared Facts - Individual Roles

shared facts

  • Please log in to reply
36 replies to this topic

#21 robertjacobs0

robertjacobs0

    Advanced Member

  • Members
  • PipPipPip
  • 327 posts

Posted 25 August 2018 - 07:54 AM

Personal entry styles is something no software company can do much about except, I would argue, understand and overcome the reasons for such personal systems. Alternate Name overcame all those personal entry techniques for missing names yet people still use them. I believe the remaining reason for that instance is wanting a place holder in reports where a name field is blank, this is something RM could easily overcome.

 

Bob Velke, who was the proprietor of Wholly Genes and the designer of TMG, argued that the software should make no assumptions about the nature of the data; it was to be organized and entered per the desires of the user. For example, the entry boxes for what we would call "place" and "place details" were marked L1 through L10. The user could design and label them as preferred, and the sentence templates could be set up accordingly. I thought that was an excellent system, but it didn't lend itself to ready GEDCOM transfers to other programs. I guess my point is that one is better off using just one database. It has to allow for easy data entry and it has to output reports and data in forms useful to the user.

 

It's hard to imagine a software company advertising its program as "accommodating exact transfers to our competitors X, Y and Z."



#22 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 298 posts

Posted 25 August 2018 - 08:03 AM

Facts shared between individuals is technically not an option in GEDCOM.

However, this can be implemented in any genealogy program without issue to the generation of a GEDCOM.

The real issue comes when a GEDCOM is received by a program that has implemented a shared fact scheme.

Since two individuals that have different sets of facts in a GEDCOM the receiving program would be hard pressed to recreate the required information to rebuild the sharing relationship. A program that generates a GEDCOM for itself, i.e. drag and drop, can create a dialect of GEDCOM that provides additional information to rebuild the relationship. This dialect would not violate GEDCOM but would generate tags that have meaning to itself but would and should be thrown away by other receiving programs, for example _SFACT @1234@ to denote the shared fact Record ID. Normally _ tags are tossed out by receiving programs.

#23 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3499 posts

Posted 25 August 2018 - 08:15 AM

Facts shared between individuals is technically not an option in GEDCOM.

However, this can be implemented in any genealogy program without issue to the generation of a GEDCOM.

The real issue comes when a GEDCOM is received by a program that has implemented a shared fact scheme.

Since two individuals that have different sets of facts in a GEDCOM the receiving program would be hard pressed to recreate the required information to rebuild the sharing relationship. A program that generates a GEDCOM for itself, i.e. drag and drop, can create a dialect of GEDCOM that provides additional information to rebuild the relationship. This dialect would not violate GEDCOM but would generate tags that have meaning to itself but would and should be thrown away by other receiving programs, for example _SFACT @1234@ to denote the shared fact Record ID. Normally _ tags are tossed out by receiving programs.

 

Thanks KFN, I was hoping you would bring your Gedcom knowledge to the discussion.

 

I believe the problem of other programs not having distinct Place Details remains. For example if Rootsmagic exported an occupation fact which had Place Details = High Street as ADDR and parsed the Place into CONC's how would another program adopting the Gedcom standard translate it into it's database? Obviously not as an Occupation fact with Place and Address or would it combine all the Place components, I have never experimented with this.


Customers should never be frustrated by things they cannot do - demand better

 

User of Family Historian 6.2.7, Rootsmagic 7.6.3, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#24 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 298 posts

Posted 25 August 2018 - 08:17 AM

Bob Velke, who was the proprietor of Wholly Genes and the designer of TMG, argued that the software should make no assumptions about the nature of the data; it was to be organized and entered per the desires of the user. For example, the the entry boxes for what we would call "place" and "place details" were marked L1 through L10. The user could design and label them as preferred, and the sentence templates could be set up accordingly. I thought that was an excellent system, but it didn't lend itself to ready GEDCOM transfers to other programs. I guess my point is that one is better off using just one database. It has to allow for easy data entry and it has to output reports and data in forms useful to the user.
 
It's hard to imagine a software company advertising its program as "accommodating exact transfers to our competitors X, Y and Z."

Velke makes and interesting point, BUT he makes it without telling you the whole story.

1) Software Programs have a life expectancy, all will die at some point. Therefor if you cant migrate your data to another program your data also will die. This is unexceptable!
2) programs with this mindset must have an open database, not protected, not encrypted, not written using proprietory DB, so that the data can be extracted when desired.
3) programs with this mindset must have a data dictionary that describes the data.
4) programs like this will require you to follow their way of exposing the data to the outside, or write your own reports. This is not a bad thing nessesarily but you would need to become a report designer and data architect which 90% of the genealogist and family historian population will never become.

#25 robertjacobs0

robertjacobs0

    Advanced Member

  • Members
  • PipPipPip
  • 327 posts

Posted 25 August 2018 - 09:52 AM

Dear Vyger & KFN,

 

A lot could be accomplished  if the import routines of contemporary genealogical software included a simple mapping routine that would allow the user to compensate for at least some of the idiosyncracies of the source program. That would require the operator to know at the outset how the data was organized. For one who is converting personally from one program to another that is probably possible. It would be much more of a problem if one is trying to import a GEDCOM from an unfamiliar program.

 

But even with such a mapping routine, interprogram conversion will never be fully automated:

 

When I export a GEDCOM with the RM7 extensions enabled, the GEDCOM contains the RM7 sentence templates using RM7's template language. These are not just the default templates; here's an example:

 

2 _SENT [Person:HeShe] studied — more or less —< at the [PlaceDetails:Plain]> <
3 CONC [Date]>.

 

The little joke about my academic prowess is, for me, part of the data that I wish to have preserved. Although I agree with all four of KFN's points, the data dictionary of point 3 is unlikely to preserve my joke (which seems to be getting less and less amusing as I write). To save that sentence in an ordinary RM7 GEDCOM I would have to blank out the template sentence altogether and write it as plaintext in the RM7 note field attached to the tag. With slight exaggeration, that's equivalent to writing it on a 3x5 file card so that it can be attached to reports with a paper clip.

 

If I import that GEDCOM into RM7, Gedsite, or Gedsite Publisher my sentence stays intact. As far as I know it doesn't survive GEDCOM importation elsewhere.

 

 

Robert



#26 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3499 posts

Posted 25 August 2018 - 10:41 AM

On reflection, I'm not sure RM is trying to lock people in, we go over this mine field from time to time and sadly there is no consensus between software providers on the best way forward.

 

I am totally committed to Place Details as I frequently find the geographic proximity of sites important indicators to possible family links, outside of that I like to study the history of the Places our ancestors lived and document them as best I can. There are always improvements which can be made but with Rootsmagics Name variations and Date approximaters I believe those two of my Golden Trinity are well covered, I remain hopeful of a more mathematical geographic approach to locations rather than the endless text variations in the next version of RM.

 

Many people still insist on 5 underscores where a name is blank, maybe LNU, MSU and then the various square bracket codes in suffix for married names which is disappointing. Alternate Name(s) overcome all these needs to enter invalid data for the purposes or sorting and grouping. However the one remaining temptation is for reports, obviously users do not want to see a blank portion in a report where the given or surname is blank and I fully understand that. Rootsmagic or any software provider could easily overcome this last temptation by simply giving the user the option to enter their own preferred text string to enter in the report where the given or surname is blank, or the Place for that matter, could be "Unknown" could be "still to be discovered", that would remove the perceived need to enter invalid data and increase data matching potential, IMO.


Customers should never be frustrated by things they cannot do - demand better

 

User of Family Historian 6.2.7, Rootsmagic 7.6.3, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#27 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3906 posts

Posted 25 August 2018 - 10:52 AM

If I import that GEDCOM into RM7, Gedsite, or Gedsite Publisher my sentence stays intact. As far as I know it doesn't survive GEDCOM importation elsewhere.

 

Ah, but there is a bug even in this limited universe of software and GEDCOM. If in RM you customize a sentence for a specific instance of a role, the customization of the sentence is not included in the GEDCOM produced by RM. Therefore, neither RM itself nor GedSite nor GedSite Publisher can import the customization of the sentence because the customization of the sentence is not there. There is nothing to import and the customization is lost. It's one of the things that's lost with RM's Drag and Drop.

 

My view of RM's sentence templates has evolved through the years to the following. They should  be used only for formatting, and should not be used to convey data (AKA information or intelligence - search for Claude Shannon's Information Theory for a theory what "information" really is). My reason for this view is that sentence templates are extremely likely to be lost when genealogical data is shared.

 

The primary example where first I was violating this principle was that I was using RM's sentence templates to denote that a person was the head of household in a census entry and if not the head of household, to denote the head of the household of the place where the person was living. After I became convinced of how fragile this made my data, I moved the head of household info to the note for RM's census fact instead of including it in the sentence template for the census fact. It's up to Robert of course, but the same view would advise moving his "studied - more or less" information out of the sentence template and into the note for his fact.

 

In the case of RM and GedSite, I began by importing RM's sentence templates into GedSite. But I quickly decided that I was better off defining the sentence templates for GedSite on the GedSite side of the house and ignoring RM's sentence templates. That way, sentence templates became metadata instead of data, and no data was lost between RM and GedSite. It also allowed me to use some alternate site formats on the GedSite side of the house, such as the Two Column format or the Three Column format, neither of which makes any sense if you are using RM's sentence templates in GedSite.

 

Jerry



#28 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 298 posts

Posted 25 August 2018 - 10:55 AM

 
When I export a GEDCOM with the RM7 extensions enabled, the GEDCOM contains the RM7 sentence templates using RM7's template language. These are not just the default templates; here's an example:
 
2 _SENT [Person:HeShe] studied — more or less —< at the [PlaceDetails:Plain]> <
3 CONC [Date]>.

Robert


Not knowing the full context of where the above tags are placed, I would say that these should not be part of any GEDCOM unless the CONC tag is preceded by an _ so that the CONC is dropped correctly by receiving programs.

My data dictionary comment was directed at the database in use by programs that are design in the way Velke proposed, not as part of the GEDCOM. THE GEDCOM standard has its own data dictionary document that should be followed, hence my above statement about CONC. The schema as defined in the standard most likely does not use a CONC in that location and therefore should use a _CONC.

However, a dialect of GEDCOM could provide additional records and tags that describe data for the receiving program to parse, but that dialect should clearly document the dialect and provide a way for receivers to implement the new understanding. We do this all the time in modern programming where we create translator interfaces so that exported data from one application can be imported into another. I developed or use these translators regularly in my office. But it requires rules and data understanding most people don’t relate to.

#29 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 298 posts

Posted 25 August 2018 - 11:10 AM

Jerry,

I would tend to take a slightly different tact in that sentence structures should not be exposed through GEDCOM but rather used to generate a proper NOTE tag or FACT where the data (rather than the field variable) is transmitted.
For example: The sentence used in Roberts example would generate a NOTE tag with the completed sentence, He studied - more or less - at Stavanger University in 1985.

This would allow internal use of your sentence structure for RM reporting and provide less data loss when exported via GEDCOM. The receiver will at least get you sentence with data even if their reporting mechanism cant use it directly. Then the user can rework the information into the new platform at time permits.

#30 Vyger

Vyger

    Advanced Member

  • Members
  • PipPipPip
  • 3499 posts

Posted 25 August 2018 - 11:45 AM

I see merit in what KFN advocates although it would need some user optional control. I say that as if the Gedcom output was intended for another Rootsmagic user or one’s own use then data would start duplicating.

 

We each have different needs, mine is heavily weighted towards matching possible duplicate individuals through all means available. I only have 10 custom facts as I try to stay as much as possible within a standard and not re-inventing the wheel, all are essentially sanity checkers. Three of those custom events are aimed as census notation where the description field of my “Relation to Head”, “Marital Status” and “Recorded age” facts are populated simply with the data to hand. Two of these get used elsewhere and I find “Marital Status” useful further down the line where the bride or groom are noted as widow or widower, obviously these are all visible on DSM. Recorded age just acts for me as another refinement indicator to approximated birth dates as more data, census or other, is collected.


Customers should never be frustrated by things they cannot do - demand better

 

User of Family Historian 6.2.7, Rootsmagic 7.6.3, Family Tree Maker 2014 & Legacy 7.5

 

Excel to Gedcom conversion - simple getting started tutorials here

 

Root


#31 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 202 posts

Posted 25 August 2018 - 12:33 PM

 

It's hard to imagine a software company advertising its program as "accommodating exact transfers to our competitors X, Y and Z."

Perhaps we will soon see DVD films that only play on one make of player? Compatibility is an advantage particularly when the data is so important! imo anyway.



#32 robertjacobs0

robertjacobs0

    Advanced Member

  • Members
  • PipPipPip
  • 327 posts

Posted 25 August 2018 - 02:41 PM

There are certainly some powerful ideas being put forth in this discussion. I hope I'm following everybody correctly.

 

In response to my last post, Jerry Bryan correctly points out that customized role sentences [for shared facts] do not make their way into RM7 GEDCOMS. He suggests that I put my custom remark into the note field. But a deficiency of RM7 is that the text of “notes” entries can only be appended to the report output. That is, the template language does not permit notes to be interpolated. Sometimes the [desc] field can be used, but it is limited in llength and is frequently used for other purposes in a sentence template. Jerry concludes, from the non-transferability of some of the sentences, that the templates “should  be used only for formatting, and should not be used to convey data.” That seems to me to hobble RM7 by forcing the user to use a time-consuming workaround.

 

So here we have two design failures IMO: RM7’s inability to do anything but append the note field, and its failure to output customized role sentences for shared facts.

 

KFN corrects my misunderstanding of his earlier use of the term “data dictionary” and suggests documented GEDCOM dialects. If I understand him correctly, this is relates pretty closely to my earlier notion that programs should offer a mapping facility for imports. He also suggests a note tag which could contain my completed sentence. As I’ve tried to explain above, one can do that with RM7, but at the cost of substantial inconvenience (to me, at least, but then I suppose the whole enterprise is inconvenient).

 

Trebor22 argues for compatibility. I don’t think the DVD player analogy is really in point, but compatibility does lie at the bottom of what we are discussing. The problem is that standards are also limits — limits on innovation, limits on eccentricity, limits on choice. Vyger uses place details extensively, I assume because the region with which he primarily deals doesn’t divide itself neatly into City, County, State, Country. Suppose (I’d bet a dollar on it) he’d prefer more fields so that his reports could be made more exact more easily? One size doesn’t fit all, except perhaps in DVD players.

 

Robert



#33 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 298 posts

Posted 25 August 2018 - 03:43 PM

DVD vs Blue Ray (does anyone remember LaserDisk) players, VHS vs Beta vs Hi8, 8 track vs cassette vs reel. We have a long list of standards in media players. Innovation is not always limited by standards because a standard can evolve but it takes either an active user base to demand a standard to be used (or updated) or manufacturers to embrace the need and care enough about their user base to develope a standard. Ive advocated for an active use base to make the demand companies to: first, use the current standard correctly and effectively: second to be involved, to care enough about their user base to update that standard to their and our benefit.

GEDCOM may not be the future of interchange, it probably will not, but it is what we have and we must learn use it correctly.

#34 JCK74656

JCK74656

    Advanced Member

  • Members
  • PipPipPip
  • 42 posts

Posted 26 August 2018 - 07:52 AM

I just wanted to say I have very much enjoyed reading the different styles and perspectives on this post, it will improve how I record data.



#35 crwinflorida

crwinflorida

    New Member

  • Members
  • Pip
  • 3 posts

Posted 04 September 2018 - 01:00 PM

Thank you all for the interesting read, and although I think my answer will be that I can't fix the titles I want to fix, let me just go through the process I'm using.

  1. On the Event Edit page I enter events and in this case it's a Census Fact.
  2. While I choose to add it to  the head of the household (if possible) and source it, I then under Census Details, choose to share it with others by Sharing this fact. 
  3. In the next box - People who share this fact - since there are multiple people in the household, I go into my datafile index and look for the family members to check to be included in this share.
  4. In the People who share this fact is a list of individuals from my datafile.
  5. I then double click on the individual's name and get the Edit shared event box where I can identify that this person is in my file or that this person is not in my file.
  6. Above the Note section is the Role box. As I've used the Sharing function for census records before, I have multiple roles, i.e. wife, daughter, son, etc. It's this list of Role Types that I want to correct.

This is not a source so the Source List under Lists will not satisfy my request. It is not a To Do List function so that does not help me. Nope, not a Research Manager function. Nor would this have anything to do with the Media Gallery, the Address List, the Repository List, Correspondence List, Place List, Fact Type List or Source Template. 

 

So, again, my original question involves the fact that I have duplicate roles when I use the Sharing function of a Fact, which I would like to delete. Guess there's no easy way to do this, and/or no way at all.

 

Thank you all.



#36 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6429 posts

Posted 04 September 2018 - 01:28 PM

I think the first two responses were directed at your question but the discussion veered away after that. Roles are defined in Lists > Fact Type List > select Fact Type > Edit but the management of them is sadly lacking in RM. You will see the duplicate roles in that dialog. They appear in the order in which they were created. You might try deleting either of them. If you succeed with one, problem solved. However, if both are used, you have a challenge because there is no ready way to find whose event uses one or the other so you can change it to the one you want to keep.

 

One trick would be to edit the role name for the second of the duplicate pair to contain some distinct code. Generate Individual Summary reports for everyone in a batch and save it to a text file or PDF which you can then search for the code. Find each person with the code and reassign their role to the desired one. When finished, delete the coded role from the FactType List

 

Otherwise, you might be able to do something with a GEDCOM export and a text editor to reassign roles.

 

And then there is SQLite, where it is simply a matter of replacing the unwanted RoleID in the WitnessTable with the desired RoleID as defined in the RoleTable. For someone who knows a little SQLite, that is a trivial, 5-minute task. The actual modification of the database is over in milliseconds.


Tom user of RM7630 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 bundle of RootsMagic utilities.


#37 crwinflorida

crwinflorida

    New Member

  • Members
  • Pip
  • 3 posts

Posted 07 September 2018 - 12:47 PM

Tom, thank you for your simple explanation without all of the complaints that my question generated.