36 replies to this topic

[crwinflorida]

I have recently discovered that when Sharing Facts between individuals, after identifying all the individuals and ready to identify their "role", after double clicking the individual's name and the Edit shared event window opens, under the "role" section, I have duplicate roles which I would like to delete. Is there an easy way or any way to do this?

 

Thank you.

Carol

[zhangrau]

I don't use shared events/facts.

 

But wouldn't you edit the roles under Lists > Fact Type List ? Isn't that how the roles were originally created?

[Jerry Bryan]

I just sent through the exercise of deleting a couple of duplicate roles. It works as zhangrau describes. My only concern in the project was to be sure to delete the role that wasn't being used instead of the role that was being used. To that end, I renamed the role that I didn't think was being used before deleting it. To be extra sure, I wrote a simple SQLite script to verify that the role I wanted to keep was  being used and that the role I didn't want to keep was not being used. To the best of my knowledge, RM doesn't provide any reporting capability to tell you where roles are being used.

 

One thing that I didn't test and that I wish I had is the following. If RM follows its typical practice, it will delete an unused role without warning and it will give you a warning before deleting a role that is used. This would be useful in your case if it's true. But I don't know if it's true or not.

 

Jerry

[Nettie]

Only shared facts I use are ones generated by RM, marriage and census family.  Not worth it when transferring via gedcom to another software package. 

[Vyger]

There has to be something very questionable regarding the practice of selling features which you then lock in as proprietary and do not make transferrable, effectively those features cease to exist if users refuse to use them on the basis that they cannot be transferred to other programs.

[robertjacobs0]

There has to be something very questionable regarding the practice of selling features which you then lock in as proprietary and do not make transferrable, effectively those features cease to exist if users refuse to use them on the basis that they cannot be transferred to other programs.

 

But might one fear limiting software software innovation only to those features that are GEDCOM transferable? RM7 at least does go beyond the GEDCOM standard if one opts to do so. John Cardinal's Gedsite and Gedcom Publisher programs read and use the extensions, but I don't know of any other program that does.

 

RM7 doesn't go far enough in extending GEDCOM IMO, but one would suspect that the developers would probably find it uneconomical to spend time to do so.

[Jerry Bryan]

Only shared facts I use are ones generated by RM, marriage and census family.  Not worth it when transferring via gedcom to another software package. 

Strictly speaking, marriage and census family are not shared facts. They are family facts. It's a similar sounding concept, but family facts and shared facts work very differently in practice.

 

Jerry

[Jerry Bryan]

RM7 doesn't go far enough in extending GEDCOM IMO, but one would suspect that the developers would probably find it uneconomical to spend time to do so.

 

My biggest complaint in this area of RM7 is that it uses GEDCOM to accomplish drag and drop and thereby loses data. I think that any genealogy program ought to be able to exchange GEDCOM with itself without losing data, irrespective of what other genealogy software might do with such GEDCOM.

 

Jerry

[pstaveley]

I recently used drag and drop to remove a minor database corruption. I was instructed to do this by Support.

 

Are you saying that I would have lost data?

 

If so what sort of data would I have lost?

 

Peter

[Renee Zamora]

The DNA Test fact will not transfer in GEDCOM or drag n drop. You will loose your groups.

[Vyger]

 

But might one fear limiting software software innovation only to those features that are GEDCOM transferable? RM7 at least does go beyond the GEDCOM standard if one opts to do so. John Cardinal's Gedsite and Gedcom Publisher programs read and use the extensions, but I don't know of any other program that does.

 

RM7 doesn't go far enough in extending GEDCOM IMO, but one would suspect that the developers would probably find it uneconomical to spend time to do so.

 

Robert, I do use Shared Facts, I also use Place Details extensively and I can convert these for transfer to another program if I wish.

 

However, it would be nice if Rootsmagic was confident enough to facilite users migrating without data loss and build those proprietry features to a standard one would not wish to migrate to another platform. Falsly trying to trap a user base through the fear of losing data is a bit reprehensible in my opinion, we see it everywhere nowadays and it only angers customers.

 

It would be nice to get to the point where Rootsmagic is simply the best kid on the block and willing to compete and fight that position with the opposition.

[Jerry Bryan]

Tom Hayden recently posted a comprehensive list of data that is lost on a drag and drop, but I can't find the link. It's more than just DNA and groups, but the losses will probably not affect most users most of the time. The losses include trailing carriage returns in notes.

 

Jerry

[Vyger]

Tom Hayden recently posted a comprehensive list of data that is lost on a drag and drop, but I can't find the link. It's more than just DNA and groups, but the losses will probably not affect most users most of the time. The losses include trailing carriage returns in notes.

 

Jerry

 

I remember reading it and also can't quickly find the link, isn't it wonderful how quickly we lose touch with valuable reference works which really should be on the Rootsmagic Knowledge Base and maybe are.

[robertjacobs0]

 

Robert, I do use Shared Facts, I also use Place Details extensively and I can convert these for transfer to another program if I wish.

 

However, it would be nice if Rootsmagic was confident enough to facilite users migrating without data loss and build those proprietry features to a standard one would not wish to migrate to another platform. Falsly trying to trap a user base through the fear of losing data is a bit reprehensible in my opinion, we see it everywhere nowadays and it only angers customers.

 

Agreed, Vyger. I too use shared facts and place details extensively. So far as I can see the main disadvantage of those features is the transferability issue. But I don't want to transfer if I can avoid it. When TMG folded, I chose RootsMagic and ran the two in parallel for more than a year. Between the post-conversion cleanup and the double-data entries, I suffered the agonies of the damned.

 

Most of being "trapped" into one program is the inevitable result of diverse views of how data is to be handled.  I don't think that the RM or FH managements are deliberately designing their software to lock us in.

 

About the only program feature that might lure me away from RootsMagic would be the more flexible and attractively designed narrative reports available in Family Historian. Between RootsMagic, Gedsite and Word I can get almost everything I need from my data.

[Vyger]

Most of being "trapped" into one program is the inevitable result of diverse views of how data is to be handled.  I don't think that the RM or FH managements are deliberately designing their software to lock us in.

 

Outside of family links we all know the fundamentals of genealogy research depends on Name, Date, Place (site) in the simplest form, the golden trinity of research. Now what a program or platform does within itself to develop and enhance on those basic fundamentals is perfectly fine but I also believe there is an onus to facilitate migration to other platforms which do not support those unique selling points.

 

I believe I have read somewhere that webtags for Place Details were backed away from because they could not be supported in and way within the gedcom standard?

 

So if Rootsmagic is playing well within the accepted gedcom standard is it the fault of other programs that they cannot or are not interested in importing that extended standard?

[Bob C]

It's here http://sqlitetoolsfo...transfer losses

[Trebor22]

I take the view that my research is only safe if it can be transferred - RM or any other programme may disappear or take a path I do not like, let alone being able to use 'my data' in ways RM does not provide for - like export into something like GedSite or anything else I choose. Gedcom used to offer that (or at least a reasonable chance).

I accept that programmes might add 'extras' that don't transfer but give users the confidence to use the programme by listing incompatibilities in detail and perhaps warning when you try to add data in a way that will not transfer :-)

[robertjacobs0]

 

I believe I have read somewhere that webtags for Place Details were backed away from because they could not be supported in and way within the gedcom standard?

 

So if Rootsmagic is playing well within the accepted gedcom standard is it the fault of other programs that they cannot or are not interested in importing that extended standard?

 

RootsMagic place details are exported in GEDCOMS as ADDR. Using a straight GEDCOM export (none of the enhancements specific to RootsMagic),Family Historian imports the place verbatim and the place details as "Address."  Latitude and longitude come over also. At least for your golden three, there seems to be substantial compatibility. Some facts ("occupation" is a particular offender, although that may be because of my own idiosyncratic entry techniques) require a lot of massaging after an RM7 --> FH6 import.

 

Does your question boil down to whether it's the importing program or the exporter who should be responsible for making the data compatible? My answer to that -- I suspect that we're in agreement -- is both. But I'm not holding my breath.

[Vyger]

Does your question boil down to whether it's the importing program or the exporter who should be responsible for making the data compatible? My answer to that -- I suspect that we're in agreement -- is both. But I'm not holding my breath.

 

Yes Robert, I suppose it does boil down to whether RM is faithful to Gedcom in its export or whether the recipient program is lacking in its import routine and what to do with those extensions.

 

ADDR being a subset of any Place is exported logically within the fact as more detail within the Place, if the recipient program does something different with that tag due to it being lacking then I would say the problem lies there. I am no expert on Gedcom but on the face of it I would say that many other programs out there do not yet have the facility to include Place Details. It's been a while since I done any testing but I know FTM 2014 puts the Place Details in the description field and therefore in is not unique and cannot support Media, Geocoding and Notes as a standalone component.

 

I can't find it but I do remember RM backing away from webtags on Place Details as they could not be supported within Gedcom, I applaud this decision rather than stepping out on a completely proprietary route. I choose not to share Place Details with Ancestry as I believe they reduce the accuracy of matches by convoluting the Place text further rather than making it more concise and understandable for matches, Rootsmagic supports this perfectly for me.

 

The old arguments are that RM should facilitate the prefixing of Place Details to the Place on Gedcom output so other programs can import a single Place component, also that the option of returning Shared Facts to individual facts should be facilitated for the same reasons, I believe Legacy have introduced Shared Facts but have no idea how they fit within Gedcom.

 

So I suppose my question is whether Rootsmagic should invest time in providing options to export gedcom in different versions so competitor software can understand? or should the competitor software be working to import Place Details and Shared events providing Rootsmagic are adhering to the Gedcom standard, I would believe the later.

 

I do need someone well up on the Gedcom standard to comment on this but the output for Place Details seems perfectly logical to me at present.

 

Some facts ("occupation" is a particular offender, although that may be because of my own idiosyncratic entry techniques) require a lot of massaging after an RM7 --> FH6 import.

 

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.

[KFN]

The problem with slapping the Place detail field into the ADDR tag within the PLAC tag is that it most likely will not follow the formats as noted in the GEDCOM standard.

It says:
The address structure should be formed as it would appear on a mailing label using the ADDR and the CONT lines to form the address structure. The ADDR and CONT lines are required for any address.

In essence this would include almost all of the data found in the PLAC tag (for USA, country, state, zip code other countries would have departments, city code etc). So most likely these items would not be repeated correctly into the ADDR->CONT lines and therefor confuse the receiving program. If you mean to store address information in RM for a place, you should include the proper fields in data entry interface to implement the correct outcome in GEDCOM. Or generate the proper PLAC and ADDR tags based on a different data entry and data storage scheme altogether. (Which is different than storing two fields in the DB place and detail)