Proposal to Modify "use their conventions instead of ours" for Categorization

Question

Proposal to Modify "use their conventions instead of ours" for Categorization

692 views

Help:Category Name General Rules currently states that:

A fundamental style rule on WikiTree is to "use their conventions instead of ours," i.e. we should attempt to use the name that the person themselves would have known and used. For regional categorization, for example, this means using the place name in the language and time in which the person lived rather than what it's called now in English.

This applies for bottom-level categories that contain profiles but may not apply to higher-level categories. Higher-level categories exist for our own organizational and navigational purposes, e.g. a town that no longer exists may be included in its current county (? example?).

In some cases this may not be practical. The purpose of categorization is to group profiles. If the people we're trying to group would have used different names for the same thing it may make sense. However, keep in mind that this can often be achieved through mid-level categories. For example, we could have "Czech Bricklayers" with whatever "bricklayers" is in Czech, as a subcategory of Bricklayers.

While it is true that one of the guiding principals for profile Name and Location Fields is to "use their convention instead of ours", this principal does not compute very well within categories, and could possibly even prohibit the grouping of some profiles, due to the language restriction that is added.

On Help:Location Fields, it is stated that:

We used to recommend using the native language for all location-based categories. However, this involved a lot of difficulties, particularly when a location had multiple official languages. So, we switched to having parallel categories in multiple languages.

With this in mind, and to provide full clarification, I would like to propose that we incorporate some of the existing clarification (example) given on Help:Location Fields and remove the reference to language, so that the guidance would now read:

A fundamental style rule on WikiTree is to "use their conventions instead of ours," i.e. we should attempt to use the name that the person themselves would have known and used. For regional categorization, for example, this means using the place name in the time in which the person lived rather than what it's called now.
- For example, Ottawa, the capital of Canada, used to be called Bytown. So, someone who lived there before 1855 would be categorized under a Bytown category, not an Ottawa category.

asked Jul 20, 2020 in Policy and Style by Steven Harris G2G6 Pilot (744k points)

I have never understood why or how the "use their convention" principle ever got applied to categories. It was established for name and place fields. Never categories. But somewhere along the line it got applied to categories where it makes absolutely no sense.

Categories are used to group profiles of interest. It is the one place where we actually should use current place names since they cannot be applied to data fields. Current place name categories would enable people to search for all people in current day West Virginia despite the fact that when their ancestors were alive, they lived in what was then Virginia before it became West Virginia. Or consider all those North Carolina county names that changed a gazillion times over a century.

I think the "use their conventions" principle should be detached from Categories entirely.

commented Jul 21, 2020 by Jillaine Smith G2G6 Pilot (907k points)

Jim said: "It often takes some side research to verify the correct name for the time period."

The converse is also true. When sourcing a profile, a source (especially contemporaneous original sources) often uses the place names that the people themselves used. It can then take quite a bit of side research to figure out where that place is now and what the modern name is.

We can't get around the fact that picking one option over the other will often require someone to do the extra research.

I'm thankful for resources like Digital Atlas of Denmark's historical-administrative geography (DigDag) which lets you find a place in one time frame and then switch to maps in another time frame. Unfortunately, they don't exist for all locations.

commented Jul 21, 2020 by Mary Jensen G2G6 Pilot (130k points)

8 Answers

Answer 1 · 2020-07-20T18:32:54+0000

You and Doug are both correct, and I left out a significant part here.

The proposed change was actually supposed to include the caveat that "this may not always be possible".

Perhaps a better version is:

A fundamental style rule on WikiTree is to "use their conventions instead of ours," i.e. we should attempt to use the name that the person themselves would have known and used; however, this may not always be possible.
- For regional categorization, for example, this means using the place name in the time in which the person lived rather than what it's called now. Ottawa, the capital of Canada, used to be called Bytown. So, someone who lived there before 1855 would be categorized under a Bytown category, not an Ottawa category.
- In Occupational categorization, for example, names often changed throughout the years or changed based on gender, so having separate categories to represent the same thing may not make sense.

commented Jul 20, 2020 by Steven Harris G2G6 Pilot (744k points)

I still prefer the other option of "their conventions" not applying to categories. But if we wind up applying their conventions to category names, then I suggest a third bullet point under not always possible:

There are many situations where specific guidelines have been developed which may override this general consideration. Please review the other sections of this page for links to more specific category guidelines which may be applicable before applying this principle.

As a general matter, in the top section of this help page, we need a general rule which says that specialized guidelines apply over general principles when there are actual or apparent inconsistencies and that emphasizes where to find all those specialized guidelines and the need to consult them.

commented Jul 21, 2020 by Mary Jensen G2G6 Pilot (130k points)

Answer 2 · 2020-07-20T19:21:33+0000

Whether or not navigating name changes is straightforward or not with the CIB options depends a great deal on the complexity and frequency or governmental reorganization and regulation of place names. It works in some places and does not work in others. There are some geographic regions where the government was very fond of regular major reorganization of regional administration units and place names with little regard for how the new related to the old. And there are places where wars and conquests resulted in fairly frequent major changes in language and place names.

Just because something does or does not work well in the regions you are used to working with does not mean that it will work in other parts of the world.

Try figuring these links out for areas of the Holy Roman Empire in Europe through their transitions in the major wars of the middle ages and later through at least the end of WWII. I've tried it for my one place study, and it is quite difficult. The regional projects for Canada, England, Scotland, Germany, Sweden and Denmark have all resolved these issues in different ways that work for each of their areas, and these are just the ones I'm familiar with.

commented Jul 20, 2020 by Mary Jensen G2G6 Pilot (130k points)
edited Jul 20, 2020 by Mary Jensen

Answer 3 · 2020-07-20T19:45:17+0000

The location category guidelines for some geographic areas have addressed this problem in some detail. Given the different resources available in different geographic areas covering different parts of history, different ways of handling these issues work best in different geographic areas.

I think the issue of how to handle historical name changes should be left to the geographic projects for the respective areas taking into account their better knowledge of their geographic areas. The variety in problems faced with names in different geographic areas is part of why projects have put so much effort into working out detailed location category guidelines for their geographic areas. Both language and history are issues best left to the projects to figure out how best to handle. Only the project members know what is practical in their regions.

I do not think the general category name help pages should make any statement on these issues other than that the "use their conventions" principle does not apply to category names (especially location categories) and that users should look for regional category guidelines for direction on how to handle historical and language place name variations.

Therefore, I make this counter proposal. This section of the Help page should be changed to read:

A fundamental style rule on much of WikiTree is to "use their conventions instead of ours," i.e. we should attempt to use the name that the person themselves would have known and used. This principle does not apply to regional or location category names. The primary purpose of categories is to functionally group profiles for useful purposes. Place names vary over time and language in many different ways in many different geographic regions. So too, the resources available to figure out how a place name changes over time and language vary across geographic regions. For these reasons, many regional projects have put a lot of effort into developing category naming guidelines for location categories in their geographic region. Please consult the collection of guidelines for regional categories at Help: Category Names for Regions.

answered Jul 20, 2020 by Mary Jensen G2G6 Pilot (130k points)

Steve, I don't think you can take out the issue of language. Sometimes, parallel languages work, and sometimes they don't. Project Denmark decided that everything below the country level would be Danish only because there simply were not any resources available to figure out how enough place names translate into other languages.

This week, I saw that the Netherlands reached the same conclusion for the same reason. Below a particular level, the resources just are not there to represent the place names in any language other than Dutch.

Except for truly bilingual places, I think that it is fairly common for place names below the highest or (few highest) levels to be difficult to translate into anything other than the native language.

But to separate out language to somewhere else, I'll change the proposal to

A fundamental style rule on much of WikiTree is to "use their conventions instead of ours," i.e. we should attempt to use the name that the person themselves would have known and used. This principle does not apply to regional or location category names. The primary purpose of categories is to functionally group profiles for useful purposes. Place names vary over time in many different ways in many different geographic regions. So too, the resources available to figure out how a place name changes over time vary across geographic regions. For these reasons, many regional projects have put a lot of effort into developing category naming guidelines for location categories in their geographic region. Please consult the collection of guidelines for regional categories at Help: Category Names for Regions.

commented Jul 20, 2020 by Mary Jensen G2G6 Pilot (130k points)

Most of Denmark. A number of the herreder names use common words that can be translated into English, but except for the directional words like North, South, East and West, the results of attempts at translation are often nonsensical and no sources I have ever seen use English or French or even Swedish or Norwegian versions of the names. Same for the amter. In theory, the word Kommune translates into either Commune or City, but in the context of place names it doesn't really translate. The kommuner in Denmark are just administrative units that often include several towns and sometimes more than one city. Except for the Slesvig/Sleswig area which is bilingual (Danish/German), and the names of a few of the larger islands (which are not part of the category structure) and the city of Copenhagen, very few place names in Denmark ever appear in any language other than Danish.

Isn't that what this language means in the Netherland's proposal?

At this time, there are not readily available comprehensive sources for the necessary geographic information in English below the country level, so all category levels below the country level will be in Dutch, including any descriptive qualifiers

My guess is that there are a lot of countries where there is no English or other major foreign language translation or name for most of the location divisions. In short, I think it most likely that parallel language names for places are mostly the exception and occur mostly in countries with more than one official language or in the larger countries of multilingual places like Europe.

It is true that Europe represents a huge percentage of profiles on WikTree. And in locations which currently have a multilingual culture or a multilingual history, the aka template and parallel language streams do make a lot of sense. But there are a lot of other areas where I doubt that anyone will ever go to the effort of developing parallel streams and using the aka template.

commented Jul 20, 2020 by Mary Jensen G2G6 Pilot (130k points)

Most of Denmark. A number of the herreder names use common words that can be translated into English, but except for the directional words like North, South, East and West, the results of attempts at translation are often nonsensical and no sources I have ever seen use English or French or even Swedish or Norwegian versions of the names. Same for the amter. In theory, the word Kommune translates into either Commune or City, but in the context of place names it doesn't really translate. The kommuner in Denmark are just administrative units that often include several towns and sometimes more than one city. Except for the Slesvig/Sleswig area which is bilingual (Danish/German), and the names of a few of the larger islands (which are not part of the category structure) and the city of Copenhagen, very few place names in Denmark ever appear in any language other than Danish.

This is not an issue. For example, let's look at Rønde. While it may not translate to English or have an English name, that does not mean you cannot use it in the English structure (using full location names in these example):

English Structure:
Denmark
Central Denmark Region, Denmark
Syddjurs Municipality, Central Denmark Region, Denmark
Rønde, Syddjurs Municipality, Central Denmark Region, Denmark

Danish Structure:
Danmark
Region Midtjylland, Danmark
Syddjurs Kommune, Region Midtjylland, Danmark
Rønde, Syddjurs Kommune, Region Midtjylland, Danmark

Isn't that what this language means in the Netherland's proposal?

At this time, there are not readily available comprehensive sources for the necessary geographic information in English below the country level, so all category levels below the country level will be in Dutch, including any descriptive qualifiers

See my previous response. This is in line with the example I have given for Denmark.

In short, I think it most likely that parallel language names for places are mostly the exception and occur mostly in countries with more than one official language or in the larger countries of multilingual places like Europe.

At the beginning, that may have been true. But in order to provide a full user experience for all languages, these parallel structures are growing daily. This would help someone to document and categorize their ancestors in the members native language, rather than trying to figure out another language and how to categorize the profile.

commented Jul 20, 2020 by Steven Harris G2G6 Pilot (744k points)

In the Netherland's stream, I posted the following which is applicable here.

Isabelle said:

"It is indeed more work to create and organize the category structure, but that can be done over time. I hope you will leave open the possibility of having English-language geographic categories to mirror the Dutch ones."

It is not only extra work to create and organize the category structure, but also a great deal more work to maintain the multilingual structure as it increases the number of categories that must be watched to make sure that the extra categories are created and organized correctly. This is no small burden, especially for smaller projects and projects which are already struggling with an insufficient number of bilingual people to do all of the other work requiring bilingual fluency.

Spreading the extra work over time is often no answer at all. For smaller projects or those with a limited number of members willing and able to work on creating categories, all the extra time we have is already needed just to create single language categories for all the places we need to categorize all our profiles properly.

Projects need the option of deciding what work is most important for meeting their goals. Limiting locations categories below a specified level to the native language to improve consistency and conserve people resources so more effort can be put into putting profiles in landing level location categories often makes a great deal of sense for regional projects.

Making the aka template available and setting guidelines for how to handle multiple language category streams for projects which find it worth the effort and want to do it is one thing. Pushing projects toward establishing guidelines which support multi-lingual language strings in all or most levels of location categories is an entirely different matter. There are valid reasons for restricting location categories below a specified level to a single native language. Having an authoritative resource to consult for place names in only the native language which can be used to improve consistency in category names is one such valid reason.

Leave it to the regional projects to decide whether limiting categories to a single language below a certain level is beneficial or not in their geographic area.

Additionally, introducing so called equivalencies perpetuates some misconceptions about administrative divisions. For example, Herred or Herreder is often translated as Hundred and Amt or Amter as County or Counties and Sogn or Sogne as Parish or Parishes. This encourages the perception that these administrative divisions are the equivalent of counties, hundreds and parishes in England or the United States, which they are not.

Such translations can tend to move some people toward the idea that if such translations exist, then the units are sufficiently similar that we can move toward standardizing the format of all or most location categories along the lines of town/city, county, state/province with sometimes country tacked on the end. In some places and times whatever gets translated as "county" for example may or may not be a significant administrative divider.

Sticking to the native language can be a reminder to pay attention to the context of the country and its administrative history as well as what is genealogically important in deciding what works best for a geographic area.

Although parallel language structures add a great deal to the understanding of what categories are intended to cover in topical and non-regional categories, place names generally don't receive the same benefit from multilingual translations. Geographic terms are the one area where both tourists and genealogists have to adapt to the locality and be able to deal with the native language to function at even the most basic level. I think it is reasonable for a genealogy site to expect all users to be able to function with place names in the native languages.

Again, leave this choice to the projects. It is one area that does not need to be standardized and in fact benefits greatly from variations.

commented Jul 21, 2020 by Mary Jensen G2G6 Pilot (130k points)

Mary, the major issue I am seeing with your comments is that if there are not enough members to support the usage of a language (and the English equivalents), then there should be no effort to create categories in those languages. While it may be beneficial to a few people in the project, we need to consider the whole of WikiTree, which is primarily English.

How would we expect a user who speaks only English to use another languages category stream if they are not fluent in that language?

Leaving this to projects to support only one language will ultimately alienate the majority of WikiTree members, which is highly incompatible with our mission to be a collaborative platform. I can also easily see 100 times more errors in our structure than what we have now if this was indeed allowed.

commented Jul 21, 2020 by Steven Harris G2G6 Pilot (744k points)

Steve,

I disagree that leaving the choice of language in location categories to regional projects will ultimately alienate the majority of WikiTree members. I am not advocating this position for any topical area of the category tree, just the location categories. (I think some of the practicalities of my position may apply in other areas, but here I'm speaking only in regard to place name categories.)

As for how we can expect a member who speaks only English to use another country's language stream, it happens all the time in genealogy. Most of us are not fluent in all the languages of all our ancestors. The first thing genealogists develop a functionality in for another language is geography. We can't do genealogy (or travel for that matter) unless we learn to figure out the native tongue in regard to geography. Next, we develop a genealogical understanding of the language sufficient to pull genealogical information out of records in the native language or sometimes yet another language like Latin. We do all that before we become fluent enough to write in the other language or to translate it to our native tongue.

There are more members of the Denmark Project who speak only English than there are members who are fluent in Danish. Yet we came to the native language decision for location categories for the same reason the Netherlands did. We need the official place names tools that are available in Danish only to sort out all the places with similar names. There are official place names only in Danish. We don't have reliable resources to figure out those place names in any other language. (The rest of our category stream will likely be developed first in English because there are not enough people with sufficient fluency in Danish in our project with an interest in developing topical categories to create the categories first in Danish. That is reality. We hope that in time we will have volunteers who will offer to at least create the parallel categories in Danish, but realistically I doubt that will happen in my lifetime.)

Our multi lingual members are very generous and enjoy very much the collaborative process of helping the members not fluent in Danish figure out what the Danish sources say about our ancestors. That doesn't mean that these same members have any interest at all in putting time into helping create parallel language structures for categories. They don't. Much as we want to have our basic landing level location categories available to categorize our profiles, most of us would much rather spend our time and energy doing genealogical research and working on profiles and helping our English only speakers do genealogical research and work on their profiles.

Even though most WikiTreers would rather spend our time doing genealogy research, who do you think created most of the categories in WikiTree's current category structure? It wasn't members of the Categorization Project. It was members of the regional and topical projects. That is reality and practicality. As much work as the Categorization Project does (and I know its a lot), it does not have the manpower to create all the categories especially in parallel languages. The bulk of that work as well as the monitoring of categories will likely always be done by other project members.

Nothing in my position suggests that parallel language streams not be developed where members are willing and able to do that. The Categorization Project and the Template group worked together and gave all of WikiTree the tools to create parallel language topic categories where there is interest in doing so. And in topical areas, your points make good sense.

But as I've laid out above and in other comments, place names are different. They don't translate as well. We can expect everyone to be able to navigate place names in the native tongue if they have an interest in genealogy. And there are fewer resources available to help translate place names properly into other languages. So in the area of location categories, one size definitely does not fit all. Those areas where translation works can have the option of using the AKA template and developing parallel categories where it fits their needs. That doesn't mean it makes sense or that it has to be done or even available for the location categories in all geographic areas.

You seem to have forgotten the past animosity created by the viewpoint that the Categorization Project was running roughshod over the needs and goals of other projects. I remember that very well. My memory was that it was strongest in the area of location categories. Leaving regional projects out of the policy choice on languages in location categories in their geographic focus area (especially where there are official place names and the resources related to those names are in the native language only) feels very much like running roughshod over the needs and goals of regional projects.

I think you may also have forgotten some of the heated debate about how English and US centric WikiTree has been and how that puts off non English speakers and natives of other cultures. Non English speakers are a growing segment of WikiTree. Genealogists outside of the US and England are also a growing part of WikiTree. There are circumstances in some of these areas regarding place names that just don't translate well to English, and those circumstances and projects also need to be respected.

And in my opinion, you are seriously downplaying the intelligence of English only speakers to suggest that they cannot navigate location categories in the native language of the countries they are doing research in.

commented Jul 21, 2020 by Mary Jensen G2G6 Pilot (130k points)

Answer 4 · 2020-07-21T12:01:51+0000

This proposal should not be needed, but if it is, it is a proposal to restore categories to the understanding they had at the beginning. We have categories in order to group profiles in certain ways for OUR CONVENIENCE.

The principle to "use their conventions, not ours" was never intended to be applied to categories, and I know that several years ago when I was a Project Coordinator on the Categorization Project, I made a determined effort to insist that people understand that categories were different from what goes in the data field on profiles.

If indeed we've fallen away from that original principle, then this proposal is a good one and long overdue. The proposal needs to be strengthened -- categories are not an exception to a policy that would otherwise apply to them, they are something different. Categories are of course intended to reflect a truth, but their primary purpose is our convenience, not to reflect the idiosyncrasies of people who died hundreds of years ago!

The place to tell the truth about a person is in the biographical narrative and in the data field that reflects the documentation in the narrative. Categories are not about telling the truth, they are about groupings helpful to us!

answered Jul 21, 2020 by Jack Day G2G6 Pilot (461k points)

I think there were some errors and inconsistencies in the Category Help pages from the beginning. (There were Categorization Help pages prior to 2012 which did cover naming categories in an overgeneralized sort of way, but they were far from comprehensive in covering the standards which had been discussed and agreed upon.) Once or twice along the way, there were some efforts to root out those inconsistencies, discuss them and make decisions to iron out the inconsistencies and to update the help pages to reflect changes in policy that had gone all the way through the full approval process. But the limitation of help pages being maintained and edited only by leaders and periods when there were not enough leaders meant that the help pages always lagged behind and that a thorough and comprehensive updating of the categorization help pages never happened.

On top of the leader load issue, we've lost a lot of our institutional history in the Categorization Project, and probably in some other places on WikiTree as well. Nevertheless, you can't just pick a date, say the policy started then and throw out everything that occurred before that point.

In the years before either Natalie or Steve joined the Categorization Project, the issue of categories, location fields and the "their conventions instead of ours" and the "categories are structured for our convenience" was discussed at some length. We did not have the Google Groups then and a lot of that discussion occurred in private emails, so it isn't easy to find now. A decision was made to clarify the language of the help page to fit with Jack's initial post here, but the help page never got updated.

And so we are back to this issue yet again and we seem doomed to keep rehashing the same old issues.

Categorization needs consistency over time to work. Consistency requires a well developed plan, comprehensive review and implementation, and then a commitment to institutional history and limited change. When change is made, thorough documentation of the change, comprehensive updating of all documentation, and implementation is necessary, so the institutional history of the change won't be lost.

WikiTree categorization started without a fully developed plan and consistent policies, and the original help pages reflected some of that.

I once devoted a great deal of time and effort to contributing to improving the consistency of WikiTree's category structure. Over a period of years, I came to understand that given the structure of WikiTree in general, the lack of unity of viewpoints on categorization, and the lack of commitment to comprehensive review and upkeep of the help pages, and the lack of commitment to institutional history and sticking by and directing users to the category policy development and changes that had gone through the full process of approval, I was unlikely to ever see the benefits of that level of work and effort. This isn't really a criticism, but rather just a reflection on the reality of the volunteer nature of WikiTree and the history of how it actually developed. That history is something we have to acknowledge and will likely never go away.

So I mostly retired back to doing genealogy work, except for defending those areas of the category tree which I use a lot. But every now and then, I get an itch and must scratch. Both the lawyer and the librarian in me just can't resist opening my mouth (or typing) and relating what I remember of the institutional history.

For what its worth, my memory of the institutional history is in line with Jack's original comment. And I think that position is the best policy. It makes a lot of sense. See my other answer with revised counterproposal.

commented Jul 21, 2020 by Mary Jensen G2G6 Pilot (130k points)
edited Jul 21, 2020 by Mary Jensen

Answer 5 · 2020-07-21T15:54:29+0000

This has already been in place in England for some time. Categories and Location Fields do not use "their conventions" , but rather something which is considered easier to use for wikitreers in general ( ie requiring less local and historical knowledge), even though it does not necessarily correspond to the primary sources. The idea, as reported to me, is that "ease of use" is more important than historical accuracy. Nothing bad has happened so far... :-)

Answer 6 · 2020-07-21T16:11:13+0000

I do not believe you can remove reference to languages from this. The question comes up too frequently, so there needs to be something in the help text that covers the question. Even if only as a statement of principle.

On occupation categories, the gender issue can be solved by using the grammar rule from French, which entails that the masculine form includes the feminine in generic words, ie postmaster includes postmistress. Just put a note to that effect on the category pages where this can be an issue.

The purpose of having location categories that are different as political changes occur, such as Canada, Nouvelle-France 16xx-1763-> Province of Québec 1763-1791-> Bas-Canada 1791-1867-> Québec, Canada 1867-now is to group people who may live in the same location all their lives but be under different régimes that affect their lives.

Sticking them all under current place name category winds up creating huge categories that lose a lot of their usefulness as a tool for research. Granted, some people live through more than one period in my example, born in Canada, N-F, married in Province of Québec, died in Bas-Canada is a fairly frequent occurence; they would show up in 3 different location categories, which are in fact the same place, the categories reflect who was where when to a certain extent, thus adding value to research possibilities.

Isabelle mentions avoiding historic categories in France, although she did create the migration structure for migrants out of the various provinces of France to New France, which is greatly appreciated. There have however been some strange DBE reports on some in my own watchlist whereby a category changed 2 years ago by bot is suddenly being flagged as wrong time frame for it, like Paris, France, I had Paris, Île-de-France previously before the bot change. Something needs to be agreed upon in that era for sure. I know certain areas in Europe are ping-pong balls, like the Netherlands or Germany, Alsace province of France goes back and forth between France and Germany over time. Definitely hard to figure such.

Categories

Proposal to Modify "use their conventions instead of ours" for Categorization

Please log in or register to add a comment.

Please log in or register to answer this question.

8 Answers

Please log in or register to add a comment.

Please log in or register to add a comment.

Please log in or register to add a comment.

Please log in or register to add a comment.

Please log in or register to add a comment.

Please log in or register to add a comment.

Please log in or register to add a comment.

Please log in or register to add a comment.

Related questions