Jump to content


Photo

Sorting in Index


  • Please log in to reply
10 replies to this topic

#1 Paul1307

Paul1307

    New Member

  • Members
  • Pip
  • 1 posts

Posted 26 November 2014 - 06:22 PM

I'm sure this has come up numerous times in the past, but I'm new to this blog, so please, forgive me.

 

I'd hoped to see this rectified in v7, but nope! It's how names are sorted in the Index. Apparently, they're sorted as "Last name," then on the "first name," and finally on the middle initial, then the birth date.

 

Could you please give us the option of changing this default behavior to either include, or ignore the middle initial in the sort order? The problem is that any name with no middle initial automatically sorts before every name with a middle initial with the result that in a list of identical names, they're sorted by birth date until we begin getting those names that include a middle initial, and then the sorting by birth date goes totally out the window!

 

Taking the middle initial out of the sort algorithm would make people with identical names, either with, or without a middle initial, sort by their birth date.

 

Thank you!

 

Paul

 



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6254 posts

Posted 26 November 2014 - 08:24 PM

The sort order after surname is by Given Names, then birth. There is no separate field for middle initials or middle names so, in effect, you are asking that the Givens be parsed at the first space character for sorting. What about hyphenated names? 


Tom user of RM7550 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.


#3 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8470 posts

Posted 27 November 2014 - 08:48 AM

Paul, this is the way every computer would sort that field. I think if we added a separate field for the middle name it would still have to sort like that, so I don't see any way around it. I will put it as an enhancement request, but its not really a bug.

 

About the only way you could get around the way things sort is to remove all the middle names from the primary name so they sort in the order you want. Then add the full name as an alternate name to the person. 


Renee
RootsMagic

#4 zhangrau

zhangrau

    Advanced Member

  • Members
  • PipPipPip
  • 1518 posts

Posted 27 November 2014 - 09:59 AM

I enter an Alternate Name every time I find the individual with a variation in some record. So I have most people with at least three Alt Names:

Full given and middle names - Surname

Full given name and MI - Surname

Given - Surname

 

I also add Alt Names when I come across alternate spellings of the given or surname, so I have some individuals from the 16th to 19th centuries that have a different Alt Name for each census. It's interesting to see how spelling "conventions" have changed over the years. Since I can attach a Source & Citation for each Alt Name, RM allows me to keep a vast amount of info well-organized. Recently I've begun to add Sort Dates for every Alt Name, so that my printed reports will output the Alt Names in the sequence I prefer. I have a set of rules in my head for how I like to set that order, but I don't think it would be very practical to try to encode those rules into a software program. Then, again, perhaps a skilled programmer would find the task manageable....



#5 Laura

Laura

    Advanced Member

  • Members
  • PipPipPip
  • 4276 posts

Posted 27 November 2014 - 12:15 PM

I have some Alternate names as Middle name, Surname when a person goes by the middle name instead if the first name.

My criteria is full names for the name and any variations that helps me find a person as Alternate name(s).

#6 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6254 posts

Posted 27 November 2014 - 02:00 PM

Paul, I think this is something like what you are asking for. It is an index for a batch of Individual Summary reports for which RootsMagic creates no index. I posted a workaround solution for indexing based on the creation of a concordance table using a SQLite query at Reports - Concordances for Indexes just two days ago so your question was timed nicely with an improvement in my understanding of indexing. I revised the query to split the first and middle names by the person's era. MS Word takes care of sorting. The highlighted ones are the only examples of common first names in this report; one is an Alternate, another is a different person. If I can do it with SQLite and Word, I doubt that there is any technical reason that precludes the program from being enhanced to do the same. 

 

Names_Concordance_Caps_First_Yrs_Mids.pn

 

I'm unsure what to do with Prefix and Suffix. In this case, they follow the MiddleName(s) without punctuation; perhaps they should be output as "(Prefix; Suffix)". 


Tom user of RM7550 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.


#7 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3590 posts

Posted 27 November 2014 - 07:38 PM

Paul, this is the way every computer would sort that field. I think if we added a separate field for the middle name it would still have to sort like that, so I don't see any way around it. I will put it as an enhancement request, but its not really a bug.

 

 

I would respectfully disagree that sorting has to be so limited. Ultimately, every sort algorithm ever invented has at its heart a compare routine. A compare routine can do anything its designers want it to do. For example, a compare routine could take a single piece of data such as RM's "given names" field and parse it into first name and middle name and compare only on the first name. The way the name was stored would never have to change in order for the compare to operate in such a way. I do this sort of thing all the time in my own programming.

 

It's really no different conceptionally as being able to sort alphabetic data without regard to upper case and lower case. Alphabetic data really is stored in a way that is sensitive to upper case and lower case, and a very simple compare routine used with a sort of alphabetic data would sort upper case letters differently than the equivalent lower case letters. But a compare routine can be smarter than that, and for example can treat a lower case "a" for comparing and sorting purposes as if it were the same character as an upper case "A".

 

But having said that it's quite possible (and actually, quite easy) to program things in the way that's being requested, I'm not persuaded it would be very wise to do so. How many users would really want John G. Doe born in 1835 sorted ahead of John D. Doe born in 1840 sorted ahead of John A. Doe born in 1845?

 

Jerry



#8 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6254 posts

Posted 27 November 2014 - 09:25 PM

Jerry, what you say is correct but Microsoft Word indexing (and, by inference, indexing in RootsMagic reports) is strictly case-sensitive, alphabetical across the index label. RootsMagic cannot change how Word sorts indexes; all it can do is control what string is output to the index mark. To sub-sort common first names of a common surname by something other than the middle names requires the other to be interposed between the first and middle names as in my example above.

I am not entirely comfortable with the result but I understand why Paul wants that option. My script could be readily changed to include both styles in the same index: surname, prefix givens suffix (era) AND surname, firstname (era) middlenames (prefix; suffix). They would all be sorted together, giving two different entries for each name ( and an index twice as large!).

As you say, it is not so difficult. In fact, there could be a user interface that would allow the user to design the index 'sentence' - an Index Template! Then we could have whatever indexing pattern each of us prefers. RM could include standard, uneditable, built in ones that comply with certain publishing standards and users could create custom ones. How about that?!

Renee! Enhancement alert!

Tom user of RM7550 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.


#9 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3590 posts

Posted 27 November 2014 - 10:18 PM

Jerry, what you say is correct but Microsoft Word indexing (and, by inference, indexing in RootsMagic reports) is strictly case-sensitive, alphabetical across the index label.

 

Actually, I misunderstood Paul's request  -- plus your message and my message "crossed in the mail". I thought he was talking about the Index sidebar rather than the name Index that appears at the end of reports. I didn't realize we were talking about a name index in a printed report until I saw your message after posting mine. So your are correct: after outputting an index mark to Microsoft Word, RM has no further control. I do think my coments were appropriate for the Index sidebar.

 

Jerry



#10 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6254 posts

Posted 27 November 2014 - 10:50 PM

Actually, maybe I misunderstood Paul's request because my headspace has been into Report Indexes in the last couple of days. Now that I have reviewed his message, I may have forked the discussion in a direction he did not intend. But maybe a user controllable sentence template for the Sidebar Index is a solution, along the lines I proposed for Report Indexes. It is already partly there with the option of appending the Birth Year. Parsing Givens into First and Middles can be a process common to both.

One Nane Studies might benefit from Paul's request.

Tom user of RM7550 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.


#11 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8470 posts

Posted 28 November 2014 - 05:18 PM

Even if things did get a little sidetracked I am confirming enhancement requests are in our tracking system. 


Renee
RootsMagic