Category names: Switzerland Project

Question

As current leader of the Switzerland Project, I am hoping to add guidance to the conventions for Switzerland category names. 

My understanding is that for categories, it is helpful to have standardization (i.e., not just the "use their words" approach) since the purpose is to organize in a way that is easy to search and navigate. For instance, the England project made the decision to use only historical county names rather than the current ceremonial counties. My own ancestral Swiss village was called Ried-Mörel until 2003, and in that year it was subsumed by a new municipality called Riederalp. It would be confusing for some people to be categorized (using English version)  [[Category: Ried-Mörel, Canton of Valais, Switzerland]] while others are categorized as [[Category: Riederalp, Canton of Valais, Switzerland]].

In Swiss genealogical circles, there is no more famous resource than the Historical Dictionary of Switzerland, and in particular the Register of Swiss Surnames associated with it (which also serves as a Register of Municipalities). This database provides a *very convenient, easily findable and searchable* standardization of naming that can go down even to the municipality level. In particular, the Register of Swiss Surnames within the larger project states regarding the municipalities it uses:

"The spelling of the communities mentioned, follows the 1980 version of the official index of Swiss communities ("Gemeindeverzeichnis der Schweiz") published by the Swiss Federal Statistical Office."

(See https://hls-dhs-dss.ch/famn/?pagename=famn2)

So I have been thinking a simple and comprehensive system of placenames would be just to use placenames from that 1980 index. All a user has to do to construct the correct category name would be then to search that index. The format would be:

[[Category: Town, Canton, Switzerland]]

I am hoping that experts from the Categorization project, or others who have experience with this in other projects, would weigh in with thoughts. The link to the index may eventually change, but I don't see the Register of Swiss Surnames or the HDS going away.

Switzerland is a multi-linguistic culture. Concerning the issue that the same town can have differently spelled endonyms in different languages, I believe the index just chooses one language. The Switzerland Project category structure already uses the AKA Template to give alternate versions of the canton names in different languages. I would think if there is a standard name for a town in another language, then we could use the 1980 index version for the appropriate language version, as well as for the English version, and then the AKA template to provide other languages.

Some cantons use districts between the canton and municipality levels, but since it is not universal, and since additional cantons are moving away from their use, I would think we should avoid using them. But I am interested in thoughts about this. 

(If two towns in one canton have the same name, perhaps a district in parentheses would be a useful way to distinguish? Maybe there's a better way to handle that.) 

I believe the Cemeterist project has special guidelines for cemetery categories, so those would need to be considered.

What other things need to be considered? Thanks for your help.

Answer 1

I am not an expert on categories, but what I have been wondering is whether the categories should be based on the place of birth or (what I'd prefer) on the place of origin (Heimatort), especially for persons born before let's say 1900 or so. For older records (I am mainly working with church records before 1875) the place of birth is often not exactly known (especially in larger parishes encompassing several villages), but the place of origin is almost always known and also more helpful when looking for relatives.

Comments

You can add multiple categories, so I had been thinking one could add both the birth place and the Heimatort, if different.

Answer 2

Hi Barry

Thank you very much for all your thoughts about categories. I'm the team leader for Italian Location Categories, so I'm a bit into this topic – but I hesitated to add location categories on all "my" Swiss profiles, as I wasn't sure what would be the best practice.

In Italy Project we decided to use the "today" name, according to the Italian Wikipedia page, as those are sometimes more accurate or up to date than the English Wikipedia pages. Italy also had several municipalities that changes in the past ten years, so we have a similiar issue. We decided to keep it simple, so in those cases we only have the category for the "today" municipality, with a description of historical name changes or town mergings. We only use the "before/after" template if someone is doing a One Place Study or has another good reason with many profiles to add.
In Italy Project, we add location categories for any "event", such as birth, marriage, death, but also if someone lived somewhere for longer time (eg. children were born there or similar). I would do this the same way for Switzerland, plus adding the category for the town of origin. Problem is: this way there is no possibility to differ between location of events and place of origin. Maybe we could get a sticker for "Swiss place of origin is ..."? Would that group them according to the location, similar as veterans stickers?

With the Swiss issue of places of origin, I would be fine with the place names from 1980, as long as there are descriptions in the category iteself, explaining name changes and town merges. The free spage page for Swiss Location Categories could explain how to use the categories and how to find out which category would be the correct one.

Language issue: as you mentioned, the AKA-template could be used. I think the AKA-template should only be used for truly bilingual places, such as "Biel / Bienne", and that wouldn't be many. Or would you also use it for towns such as Bern = Berne, Genève = Genf ?
But now that I'm thinking of it, at least the official Swiss name (in whatever language) and the English name would make sense. As most American members don't have the special keys such as éèàéè in their keyboards. And even if so, the language problem still exists.

Districts are not used for place names in Switzerland, so I would not use them for categories. As much as I know, districts in Canton Berne are only used for adminstration things such as courts or civil registry offices. In everyday life, no one would ever refer to a place name and it's district.
To distinguish two towns from each other, sometimes the abbrevation of a Canton is used, eg. Arni BE (Canton Berne) and Arni AG (Canton Aargau) – that's also how German Wikipedia names them.

Would the general rule for location categories remain the same as now, so "municipality / town, canton"? Eg. [[Category: Riederalp, Valais]] ? I think this is a good rule and is the same for the Italian location categories (at least the basic rule, we have some additional special rules).

Comments

Thanks for the thoughtful response.

>> "Problem is: this way there is no possibility to differ between location of events and place of origin. Maybe we could get a sticker for "Swiss place of origin is ..."? Would that group them according to the location, similar as veterans stickers?"

I have seen it said that stickers are a decorative feature for profiles. I have inferred, maybe wrongly, that this means they have less functionality than, say, categories. But the Heimatort is so special that it would be nice to have a way to single it out.

A question about using the "today" name. I see some people use historical names as subcategories of "today" names. But what happens when a "today name" changes? The Wikipedia page will change overnight. But if you change the name of a Wikitree category, all of the profiles with that category name in their text would still need to be updated. That's why I was thinking that fixing one point in the past and using names from that point would be simpler --- hopefully, there would never be a need to update a ton of profiles due to a name change.

There is currently no top-level category [[Category:Valais]]. All of the cantons currently have "Switzerland" in the name. Some of them say "Canton of" (in the English version) and others just have the Canton name. That struck me as weird, but I see that Wikipedia has their cantonal categories setup the same way. Weirdly, Wikitree's choice for which ones get "Canton of" and which ones don't is different than Wikipedia's! So I would assume, with my limited knowledge of Wikitree's category rules, that municipalities should be [[Category: Riederalp, Canton of Valais, Switzerland]] since the canton category is currently setup as [[Category: Canton of Valais, Switzerland]].

But boy does "Canton of" sound clunky. And it's a pain to write over and over. I don't put it in the placename field. I wonder if we could break from Wikipedia and just standardize the category names so that none of them have that extra verbiage?

---

What we did for parts of Canada, like Prince Edward Island, was to use the today names and then have a "Historic Places" category to hold the earlier names and used the Previous/ Next mechanism of the Location CIB to navigate in time. Granted Switzerland has a lot more history so that there will be more names to deal with.

---

Stickers: when I joined WikiTree, I also learned that stickers are just a decorative feature for profiles. But this must have changed in the past very few months, because since then there are also links for stickers at the bottom of profiles that lead to categories that groups profiles with this sticker. I guess we would need someone very experienced with categories to discuss the technical part of this.

>>I see some people use historical names as subcategories of "today" names.<<
This would be wrong, but there is also still much clean-up to do on the Italian Location Categories.
Correct would be the before/after template. The historical place name links to the today place name and the other way around. This works also for merged municipalities.
Here is an example for Italy, see the "timeframe" and "timeline": https://www.wikitree.com/wiki/Category:Castelmonardo%2C_Vibo_Valentia

We have WikiBot that renames all the profiles after a category needs to be renamed or merged. Thankfully that's not really a problem :-).
You are right that when the 1980 places names would be the standard, we would not need to keep track of renamed or merged municipalities.

Well, as everyone on WikiTree can create categories and as they were not really important until recently, there are lots of location categories that didn't follow a style guide or were else set up a bit incorrectly or just not the same as other subcategories from the same category. So after having a more detailed style guide, it would be time to clean up.
Example from Italy:
Region: Calabria, Italy = Calabria, Italia
Province: Province of Catanzaro = Provincia di Catanzaro
Special case that we treat like a province: Metropolitan City of Reggio Calabria = Città metropolitana di Reggio Calabria
Municipality inside of Metropolitan City of Reggio Calabria: Ferruzzano, Reggio Calabria
Following this, the Swiss categories would be:
[[Category: Canton of Valais, Switzerland]] = [[Category: Kanton Wallis, Schweiz]]
[[Category: Riederalp, Valais]] = [[Category: Riederalp, Wallis]]

But that's how we chose it for Italy Project and I think this is what Isabelle told us and started to create and we followed this as it made sense to us.
Also about Wikipedia: for Italy I found that the English pages are not always up to date with the Italian pages (as those are separate projects and not just translations). So if you would want to use Wikipedia as source (which I do for Italian Location Categories), then you would need to use the page in the original language of the location. Or maybe the German Wikipedia for all languages, as that one has a very strong community with many Swiss users (I think German Wikipedia is the biggest right after English).

Whatever we choose as style rule for Switzerland, it should be the same for all categories. So as I said, there's probably some clean-up work waiting.

---

I. Caruso, some stickers indeed have categories tied to them which they enter automatically, this is not generally the case though.

Answer 3

hi Barry,

Isabelle has done a lot of work in this area already, and the various Cantons in many instances have been made multilingual.  Switzerland gets 4 languages, so frankly don't see why English should be primary choice.  I know family friends en Suisse did not speak English particularly.

Comments

I didn't mean to imply there was a primary language version. My understanding is that the AKA template was created so that users can create content in their native language without ever worrying about putting it in another language correctly. So a Francophone could create categories while writing only in French and would need never create an English version. No version becomes primary, and many categories have no English version right now.

When I mentioned English in the OP, my intent was just to point out that in my examples, I create content in English, so they would be the English language versions of the category pages. I don't feel comfortable creating German language versions or French language versions (although I could probably create German ones that are usually reasonable). And when the EN version of a category is created for a non-English-speaking place, if a common exonym exists, that would be used (i.e., the Province of Florence category (English-language) under Italy). But most small places have no exonym, so it seemed to me reasonable to select the endonym from the HDS to use on the English-language version.

I would think a main topic point in guidance for creating categories in the Switzerland project pages would say: if the category is being created in one of the official languages of the place, the endonym from that language should be chosen. There would be, farther down, specialized guidance for native English speakers like myself. But a user who has no interest in creating English-language versions of categories could completely ignore that guidance.

---

Switzerland, Cantons and Place name categories is a page that already gives the outline of how they were set up and the desired usage.

---

Thanks, Danielle. That page, as far as I know, does not address the reason for my original post: what to do about place names that have changed over time. I would like to edit that page to give such guidance.

---

I see this similar as Barry wrote: with the AKA-template, categories get sort of connected, so you would have eg. Canton of Berne = Canton de Berne = Kanton Bern. Then if an English speaking memer uses the English category, and a German speaking member uses the German category, both profiles are shown in all the "connected" categories. This is useful, because members might not know the town name in the official language that is spoken in the town.
We use AKA-templates for all Italian regions and provinces (English / Italian), but only the Italian names for municipalities / towns.

Yes, it may sound silly to have English categories for a country that has four other official languages. But to be honest, even if I know three of those four languages, I still speak English with people whose first language is French :-( And they do the same if they are in German speaking locations. But this happened somewhen in the past 10-15 years, maybe with internet access. (Edit: I grew up and live in Switzerland.)

@Barry: I don't understand the part with exonyms and endonyms, could you make an example?

---

Exonym is a name for a place that isn't used by the people who live in that place. For instance, "Florence" in Italy is an exonym, since nobody in Firenze would call it that. It's not even just a mispronunciation of Firenze --- it's a different name. The category for Florence that I saw has only the English language version now, and it uses "Florence" as the name.

---

Category Info Boxes have an option of giving aka names that change over time, so that could be used, or just the aka itself, which they also have.  Neuville category shows info box as an example for you.

---

Thank you Barry, so I hope I do understand what you meant.

More or less, this is why we chose the Italian municipality level as Italian - because most small towns / municipality are the same in Italian as in most other languages. And all upper level categories have the aka template.

Answer 4

Hi Barry

Most of the profiles that I am working on are within the Canton of Schaffhausen. I do my best to add that category when I work on a profile. Also, I have been putting the Switzerland Sticker on there. Is there a way for the computer to automatically sort the profiles by the person's village, based on the birth location in the profile. Or possibly be searched by location rather than by surname. I realize that I'm not expressing it well, but it seems like there might be an easier way than adding categories for each and every little village in Switzerland. Thanks for being our project leader.

Comments

hi Beth, the system will not sort by location inside a category, it sorts by name.  You can however use WikiTree+ as a tool to do searches with 2 parameters, although I am not an expert on this tool so you should ask others how to run it.

Answer 5

There are two main considerations, the structure of the location categories and their use in terms of place of residence and/or place of origin.

The Historical Dictionary of Switzerland would provide a good way of standardizing towns/municipalities for categories. This would align also with the way locations are structured now with town/municipality, canton, and country. I think the use of ‘canton of’ is not necessary and, at least to me, sounds very odd. Differences in language can be covered with the AKA template. I was not aware that there was a ‘’before/after’’ template to indicate change over time but, again, this could provide great context and negate the need for ‘historical’ categories.

The question of place of origin is more difficult to tackle. Both, the place of residence and the place of origin is equally important for research. Some of my ancestors did not live in their place of origin for many generations, some have two places of origin, women changed/added the place of origin with every marriage, some bought into a ‘place of origin’, and for some of my early ancestors, their place of residence is only vaguely known, especially were the municipality covers many villages. For most municipalities I research, early records don’t mention the place of origin until around 1750s.  

I am not that familiar with stickers but some seem to link profiles to categories and some seem to be ‘just’ visual. Someone with experience on how stickers work might have some suggestions on how to group profiles by place of origin without having to create two sets of locations (which I am not proposing ) At the moment, I link any location where an event happened in a person’s life including the place of origin. I have also started adding a small image of the coat of arms of the place of origin as a visual clue. Not sure if this is an ‘acceptable’ way of the use of an image but I have not been told otherwise.

Answer 6

Other question: would the normal category level be the municipality? And would exceptions be possible if we have many profiles for a village or small place inside a municipality?

The reason is, I have many ancestors and their children who were born in a hamlet and I lately found that some of them also married someone else from that hamlet. So it would be great to have a category for them.

In Italy project this is possible as exception, if someone is doing a One Place Study or else adding many profiles to that category. But we don't create such categories in advance.

If possible, I would suggest to name them [[Category: Village, Canton]].

Answer 7

Hello Barry,

I realize that it has been a long time since you first asked this question, and it is clear that a LOT of very helpful ideas and plausible solutions were discussed last year. But I was wondering if you could point me to a page where the result of that discussion is clearly described. Which of the proposed solutions did you decide would be best for the Switzerland project? What steps have been taken to implement that solution? Is there a new Sticker or new Guideline in the works? Is there anything anyone can do to help?

Comments

Perhaps my attempt to summarize the issues raised above will be helpful to others, as well:

1) If having "standardized" location categories is the ultimate goal, what standard should be applied in the case of Switzerland?

:Sub-issues include (a) which name should be used, (b) which language should be used and (c) which hierarchical structure should be reflected in the category

:Which NAME 

::use the name valid at time of event

::use the name valid "today"

::use the name included on a designated list (e.g. 1980 index). 

: Which LANGUAGE

::the official language used by the majority of the "normal" population of the town/village at the time of the event

::the official language used by the sovereign authority controlling the town/village at the time of the event

::the official language "currently" used by the majority of the population of the town/village

::some "lingua franca" for a presumed majority of WikiTree users (e.g. English)  

::create and allow use of multiple languages in parallel categories

: which HIERARCHY?

::the political hierarchy valid at the time of the event, with town/village, county, state/province, and sovereign entity. 

::the political hierarchy valid at the time the data is entered in WikiTree (or any other arbitrarily determined "today")

::the political hierarchy valid at the moment the data is viewed ("today")

It should be noted that there were over 170 changes to the "current" official statistical entities used in Switerland between 2020 and 2023. see Gemeinden - Suche | Applikation der Schweizer Gemeinden (admin.ch)

EDIT 2023-08-22 11:30: I wanted to explicitly acknowledge and include the work already done and the page Danielle and Barry referred to in last year's discussion. This issue really boils down to the question of whether (and if so, how) the existing solution needs to be adapted to address Barry's initial concerns: Category names: Switzerland Project - WikiTree G2G

---

2) Regardless of how categories are standardized, the next issue involves their USE. How and when should location categories be added to profiles in the Switzerland project?

Note: A distinction needs to be made between "selecting the right location in a field" and "adding [[Category: xxx]] to the text of a profile.  The "selection" issue is really the same as the "standardization" issues listed above - once there is consensus on the standard format, it should be used in fields. The following refers to adding the [[Category: xxx]].

: How should categories be used? This is my understanding (please keep in mind that I'm a WikiTree "newbie", so feel free to gently correct any misunderstandings!):

::(At least) one location category should be added to any Switzerland project profile, to ensure the person is grouped on the appropriate location page. ONLY the lowest-level (most specific) category should be used.

::If major life events or periods of time in the biography occurred in DIFFERENT locations (not just "less precise"), then the profile should get those categories, too. As far as I know, no parameters or additional details should be added in the [[Category: xxx]], because that may prevent the profile from being included on the appropriate location category page. Details can be included in the Bio.

---

3) There is a completely SEPARATE issue regarding how/whether we might be able to meaningfully include the concept of "Heimatort" in a Swiss profile. In this context, various ideas have been presented surrounding the concept of "Stickers"

:One idea is to create and use a "Heimatort" sticker

:Another idea is to further develop the existing "Switzerland" sticker so that it could accept parameters (perhaps "Heimatort" as one of the possible parameters). This might also allow more flexible display of what now is always the default "has Swiss roots" text.

:There are other existing stickers (e.g. "non-migrating ancestor", "heritage") which might also provide a good alternative to creating a specific "Heimatort" sticker.

Answer 8

I was thinking about the Heimatort sticker since last year and here is my suggestion. Please post your opinions here, so we can work out what the Switzerland Project needs. Then I would post a new G2G thread for the Template Project, which could then made us a working template to use on profiles.

I would love to have a sticker with the Heimatort, which would lead to the location category. But I would want a different sticker than the "has Swiss roots" stickers, as it seems weird for me to place the "has Swiss roots" or "has Italian roots" on profiles that never left their respective country. It seems more fitting for me to use the "roots" stickers on profiles that lived in another country than their ancestors.
Despite that, someone can have a Swiss Heimatort without having Swiss ancestors (if someone was naturalised) and someone can have Swiss roots without having a Swiss Heimatort (if someone was born in another country and their Swiss parents didn't claim Swiss nationality).

My suggestion about the template of the sticker:
- has not the same purpose as the Switzerland Sticker ("... is of Swiss descent")
- the template could be named "Switzerland Heimatort Sticker"
- the sticker would contain the Swiss flag image, same as on the Switzerland Sticker
- the text on the sticker could be ".... has the Heimatort .... (municipality / town) in the Canton of ...., Switzerland".
- the municipality / town should be filled in by the user, same as the canton. Or, if possible, it could automatically fill in the canton by the information in the location category (I don't know if this is technically possible)
- the sticker should automatically add the location category of the municipality / town

I'm happy to hear other ideas.

Comments

Hi I,

I would be happy to see a Sticker which showed the text you are suggesting. One thing I would welcome would be the ability to select a different flag (perhaps the city or canton flag that was valid at the time?) if so desired.

I'm not sure what the difference is between adding a "template" and adding a "sticker". Not being an expert on either one, I would like to check with someone about the technical possibilities and the various pros and cons before a final decision is made. Maybe a "template" which allowed us to identify things like "Heimatort", "Hospital location", "Baptism location", "Education location" (or whatever else seemed interesting enough as a way to look at groups of profiles) would be easier for WikiBots or apps to work with. Could be entirely separate from the "sticker" display. I would also suggest that the link between the Sticker and a location might be the WikiTree ID of the appropriate location category page. That way, the "right" location category should be able to be updated "automatically" if the location category page needs to be updated later. It might even allow selective inclusion of profiles related to the location regardless of "timeline". Again... we need to get an expert involved in this before we go too much farther!

---

Templates on WikiTree need to be set up (sort of programmed) by the Templates Project. There are templates that are very short and not individualised, such as the "Died Young" sticker. Then there are templates for much complexer things, such as the CategoryInfoBoxes for location and migration categories or military stickers, which all can be individualised.
In short, templates are defined first and sort of saved to WikiTree by the Templates Project, and then afterwars can be used by members in form of stickers or CategoryInfoBoxes.

Knowing the location and migration categories, I assumed that linking to the location category (as the migration categories do) could work similar for our sticker here. But yes, someone with more expertise would need to help us.

As for the image shown on the sticker, I would suggest one only image for all profiles, just out of simplicity: first, that way we only need to maintain one image, not thausand of flags of municipalities. And while the Swiss flag is not copyrighted, the flags of Swiss cantons are copyrighted (I'm not sure if the flags of municipalities are copyrighted). Second, members would again need historical knowledge to choose the right image (eg. Canton Aargau that formerly was part of Canton Berne).
Third, I personally would like to have the Swiss flag, because it highlights the nationality, which would not be shown if the "is of Swiss decent" sticker is not used.

---

Hi I,

You have obviously given this a lot of thought, and I respect your opinions. As a newcomer to the issue, I am still just trying to sort out what various people are trying to achieve, and hoping that we can find a consensus and start actually working toward an effective implementation.

It would be helpful (to me, maybe to whoever the "experts" are) to keep the various goals clearly defined - at least for a moment - so that each of them can be addressed and hopefully resolved. It seems to me that your last post addresses the following separate (but related) goals (please correct any misunderstandings!) :

1) Finding a way to link a profile to the location identified as "Heimatort", so that profiles with the same Heimatort appear together on a corresponding location page.

2) Finding a more attractive way to present the fact that someone was born in Switzerland on their profile than the current {{Switzerland Sticker}} currently provides.

3) Assuming that the solution to (2) involves creating or adapting a "Sticker", the "Sticker text" should make sense for people who did not leave Switzerland.

4) Again assuming that the solution to (2) involves a "Sticker", the image should be standardized and mandatory

5) Your specific preference would be for the current Swiss flag to be that image, for the reasons you outline above.

I definitely support the first three of these goals, and find the last two reasonable but debatable. Personally, I tend to err on the side of letting people make their own decisions, so I would not necessarily make a particular image mandatory. But I understand the copyright argument and the "recognition value" of the Swiss flag.

From your earlier posts to the discussion a year ago, I know that you also share the goal of finding a standardized, pragmatic consensus on the issue Barry raised in his initial question: naming location categories for Switzerland. But perhaps that issue is too complex for us to tackle at the moment. What would you say to concentrating on goals (1) and (2) for the moment?

---

Hi GM

Thank you for your response. Yes, as you wrote this is my personal opinion and a suggestion (and not necessarily perfect) and I agree that we need to find a consensus for the Switzerland Project. Thank you for summarizing the five points, this is exactly how I had it in mind.

We could concentrate on (1) and (2), but possibly all points are related, so we might need to consider all points before we can get a result. But we could start with the first two points and see where we get.

---

OK, I.

So you and I seem to have a "mini-consensus" on how to proceed. That's GREAT!

How do you suggest that we go about bringing in Barry, other Switzerland project members, and any of the WikiTree leaders who might be important in helping us consider "system-wide" aspects and opportunities?

---

Perfect :-)

I hope that other members of the Switzerland Project and of the Categorization Project, who should follow the tags in the first post of this topic, will be able to help us here.

---

Following a PM from Danielle, I found this page. Perhaps this is a way forward for at least the "location name" issue listed above - which I think was Barry's main concern when he first posted his question.

Categorization - Proposing Category Structures (wikitree.com)

EDIT 2023-08-22 19:40 BEFORE proceding, it may be useful (even necessary) to consider the proposal made and adopted in 2018: Switzerland locations proposal - WikiTree G2G

Answer 9

Okay, I think I found a solution for the multilanguage problem.

I found this page from the categorization project: https://www.wikitree.com/wiki/Space:Swiss_cantons
it's a list with all cantons and the five languages. Isabelle created the canton categories in all languages that are needed: English cantons are needed for categories like migration, cemeteries etc. (as much as I understand). And then all cantons were created in the language that is spoken there, so eg. French and German for Canton of Berne, only French for Canton of Vaud and only Italian for Canton of Tessin.
Then, what I learned by now, is that location categories on municipality level should always only have the parent category (in this case: the canton category) of their language. So, as it is already, Fribourg (city) is under Canton de Fribourg and Freiburg (city) is under Kanton Freiburg.

So, that's what already was set up by the categorization project in earlier years.
And this also corresponds by this page that explains the language boarders inside Switzerland: https://en.wikipedia.org/wiki/R%C3%B6stigraben
According to the German Wikipedia page, there are only four towns which lay exactly on the French-German boarder: Biel / Bienne, Freiburg / Fribourg, Murten / Morat, Siders / Sierre.

So my suggestion is: those four towns get a category in both languages, each with their correct language as parent category (canton) and are mirrored with the aka template. This already exists for Fribourg, but would need to be cleaned up for Biel / Bienne. Because Biel-Bienne doesn't exist: the train station is called Biel/Bienne and it's often used that way, but actually it's just "Biel" in German and "Bienne" in French.
And then, all other municipalities are only created in their main language according to the map in the Wikipedia article above. If in doubt or if the sources tell different, a category in the other language can be created and again, be mirrored with the aka template.
And even if we decide to use the 1980 locations according to Familiennamenbuch der Schweiz (which I still support), we can use Wikipedia of "today" to decide the local language. It most often won't be that different from 1980. But please don't use the official administration language of historical times, because if we then use Napoleonic time as a reference, it gets complicated.

By the way, here are the approved rules for Swiss location categories: https://www.wikitree.com/wiki/Space:Switzerland_Cantons_and_Places_Categories

As by now I already have some experience with the Italian location categories, I could go through the Swiss location categories and see if they need to be cleaned (such as Biel-Bienne).

If there are no answers against Barry's suggestion with the 1980 locations as basis for the Swiss location categories, and if there are no answers against my suggestion with the Röstigraben to decide which location should get which language, I will post those suggestions separately to get approval for them. Then we could add them to the approved rules in the page above.

Comments

Hi I,

I also found the work done by Isabelle Martin to be very convincing. It made sense (to me) that she created "parallel language categories" to cover the official languages of bi- or tri-lingual cantons, and made a generous gesture to mono-lingual Wikitreers to retain an English category even though English isn't an official language in any Swiss canton.

At the moment, it appears that all available categories (en|fr|de|it) are being used, which unfortunately splits up the list of profiles depending on which language is chosen in the aka profile selector.

If I understand your proposal correctly, you would want ONLY the "main language" for the canton to be used as a location category. That would ensure that all profiles used the "correct" category and were displayed on the same page.

I have three concerns:

1) many existing profiles would need to have their location categories "corrected". I wonder whether that effort is truly necessary and/or worthwhile.

2) The "aka" template would become rather useless. After all profiles were updated, the parallel language categories would no longer be used or recommended - and probably best deleted. I suspect that many find this feature very attractive.

3) The instructions to WikiTreers would be dramatically different for filling out "dropdown" location fields (use the name which was valid at the time) and categorizing that same profile (use whatever location category the relevant project decided would be "eternally" valid).

My hope was that a more "open" system, which was flexible enough to handle real-world changes, could be developed which would address your immediate goal - which I understood as wanting all profiles with an association to a given location to be displayed together on that locations page - and the more far-reaching goal of allowing profiles to be connected to locations in more subtle ways than possible using only "birth", "marriage" and "death" fields. The discussion of "Heimatort" is, in my opinion, only one of many possibly interesting relationships which people have to locations. Looking at various examples of existing templates, I thought it might be worth exploring the possibilities.  

I had also hoped that it would be possible to enter the "historically correct" location category in a profile (or Sticker) and still give us the desired display and analysis results.

But if you and other categorization project leaders feel that

(a) only one language should be offered for each location and

(b) the location names valid at some "fixed" time should be used for all past, present and future profiles (whether accurate or not), and

(c) it is better to create new "simple" Stickers or Templates for each new group than to create (or use) more flexible tools with corresponding parameters,

then I'm sure you will get enough votes on G2G to justify doing it that way. That definitely seems to be a popular approach, It was surprising to see how few votes were actually cast after all the work Isabelle Martin did in 2018. The Germany project has apparently recently collected enough votes for their decision to delete all "historic" location categories - ironically ensuring that future WikiTreers will consider today's location names just as "historic" as we consider those of the 1950s - not to mention the 1750s. I will not vote against your proposal, but I doubt that I will find much use for non-historic location categories in the work I was hoping to do on WikiTree.

Answer 10

And another question that I asked last year: the approved rules for Swiss location categories https://www.wikitree.com/wiki/Space:Switzerland_Cantons_and_Places_Categories
only mentiones municipality location categories. That's also what we do as "lowest" category level in the Italy Project. But in Italy Project we decided that exceptions would be possible, eg. if someone is doing a One Place Study on a village inside of a municipality.

So I would suggest to allow location categories for villages or even hamlets for Switzerland too, but as exception and only if someone is going to add "many" categories for that location.
The category would need to be set up a little bit different, mainly with a short description below the CategoryInfoBox that explains this and links to the municipality category. I could explain this later and also help with setting up such categories.

Examples on where to use such village categories:
- doing a One Place Study only for a village
- adding many profiles of one hamlet (many of my relatives were born in a hamlet of only 3 or 4 farms, and they often married from one farm to another of them, which would be very interesting to document this)
- a village might have been an important place but now be part of a city. Bümpliz would be an example for this (see question about creating a location category for it), as Bümpliz has a very old church that seemed to have been a liked place to marry even for couples from 20 km away, and today Bümpliz is still a quarter inside the town of Berne. So here it wouldn't be about the historical municipality before merging Bümpliz to the city of Berne, but rather creating a category for a location that is "smaller" than the municipality.
 

Comments

Hi I,
first of all, I agree wholeheartedly that location categories should be ALLOWED for smaller units. There is a limit to what the project leadership can set up and maintain, and I think Isabelle Martin's decision to stop "pre-populating" location categories at the canton level makes sense. There is a procedure in place for requesting new sub-categories, and I would support guidelines for Switzerland Categorization Project teams which encouraged approval of well-structured requests for more specific categories.

So if we want to look at Bümpliz as a part of the City of Bern, I would support creating a location category that went down to that level. I just don't think that is the best way to categorize profiles associated with Bümpliz BEFORE it became part of the City of Bern. So yes, create a category for the present-day situation. But I still would like to have some way to categorize a 17th century profile in a way that makes clear it was NOT associated with the City of Bern at that time.

I do understand the desire for "simplicity", but municipalities continue to change (over 170 official changes in Switzerland since 2020) and an ad-hoc decision to make an exception to the "town, canton, country" structure just so that we can avoid admitting that things change over time seems destined to cause trouble in the future.

---

Hi GM,
There are two things in WikiTree: the birth, marriage and death location fields, that should be filled in with the "then and there" location, so in those fields the historical place can be filled in (mandatory for pre-1700 profiles).
The other thing are categories. For location categories, it makes sense to have a standartised way (eg. the 1980 municipality list), because what we want to achieve with categories generally, is to group profiles. If you have historical location categories as well as modern location categories, they are not grouped, but split. Even if using the before/after template, as this template only adds a link to the other category.

I'm aware that there are and were many changes in the municipalities of Switzerland, that's why I think the 1980 list is a good compromise.

I worked out a proposal an all the topics above, but I'm waiting for an answer of Barry before posting it. I hope we can then continue to work on location categories.

---

Hi I,

perhaps I am missing something, but I still do not follow the logic which gets you from "what we want to achieve with categories" to your conclusion that picking some time-dependent "snapshot" of political geography is the best way to do this. The issue is not whether the 1980 list is a good compromise - perhaps arguments can be made that it is the best available to us in 2023, perhaps not. The point is that no solution which requires adherence to what was valid at ANY arbitrary moment in history has ANY chance of long-term validity. In my opinion, the solution MUST be sought in figuring out a way for profiles to be grouped in the way we would like them to be grouped WITHOUT insisting that all past, present and future profiles follow any static system of categories, which will at some point require the maintenance of counterfactual data in the context of a constantly evolving world.

There have been many suggestions made in this regard - from geo-coding to allowing display of all categories matching the "previous/next" chain described in the Info Box. All such suggestions have been shot down - for reasons many find convincing - mostly on technical grounds or because it is felt that all potential users have a very clear (and limited) ability to understand and/or implement anything other than what WikiTree veterans consider standard practice.

I have no wish to break another lance against this particular windmill. As I have indicated elsewhere, I do not intend to add inaccurate location categories to any profiles I manage. But I neither will I remove them, if someone else decides to go that route.

---

Hi GM,
Well, the logic behind my thoughts is simply that I'm trying to find a way of implement what we would like to achieve into what WikiTree offers us technically.

The problem is that WikiTree itself is static. If I understand correctly, then WikiTree is based on MediaWiki software and then was programmed from there. Because of this, the basic software is outdated for years and any special wishes are now programmed by apps. The categorization works the same way as the basic MediaWiki software does (eg. same as Wikipedia). If we would want to change this, we probably would need a completely different software, but as WikiTree is free and every member here is helping in their free time, this is not possible.

Location categories usually have the coordinates from Wikipedia in the Category Info Box, so there is sort of geo-coding already happening. But I guess, this isn't what you meant.

Edit: corrected software name.

---

I have a lot of empathy for you, and wish you whatever success is possible within the WikiTree framework. It may, in fact, be a workable solution - and possibly the best that can be achieved within the given constraints. I will not oppose your proposal. I just happen to believe that it has a fundamental flaw which will (eventually) need to be adressed.

I wonder if the wonderful folks behind WikiTree Plus and the Apps could help us out here? There seems to be a lot of magic going on to make the Tree Apps such great (and flexible) tools. The extended genealogy tables, with options to retrieve and show parents and spouse "on demand", demonstrate that not EVERYTHING in WikiTree is frozen by the antiquated Wiki software. Perhaps the tech wizards could create a table view of profiles, based on either the location in the data section or on location categories in the text section, which would be able to follow the "chained" logic established by the category info boxes. I haven't really explored what can and cannot be "read" out of the various page types on WikiTree - but the task would seem logically "solvable":

a) read the location category pages to create a data-map from specific location (historically accurate "most local" category or location text) to a specific "core" location (mutually exclusive and collectively exhaustive at any given level of analysis, such as continent, country, state, city or village - this will require the use of a placeholder category like "unknown" at each level)

b) Allow selection of the level of analysis and ("specific" location category to be used as a filter. This could be accomplished by a hierarchical selection procedure (pick country, then state, then city, then neighborhood or village) or - since most users won't know the hierarchy - by matching terms entered (e.g. "Bümpliz") with all matching hierarchical strings (as is now done in location fields) and allowing selection.

c) Offer the option to set (or ignore) time constraints - and then return all profiles with specific categories and/or location data fields mapped (step a) to the same "core" location. If start and end dates were included, then only those location categories with appropriate entries in their Info boxes would result in selection of the profile.

d) display the table using data from the filtered profiles, allowing various sort options (date of birth, LNAB, etc.)

That sort of app, in my opinion, would come closer to what you are trying to accomplish than anything WikiTree could currently provide as a list of profiles using any given category on a "Location category page". I have generally not been happy with the "profiles using this category" lists, because they often have limited scope and do not allow filtering or searching across multiple pages of results.

I understand that WikiTree relies on volunteers, has limited resources etc., etc., etc. But in my experience it is crucial - before you initiate a project - to be sure it has a chance of actually giving you what you want. Think of the effort that will be involved in developing, implementing and maintaining your proposed solution. If the result won't give you what you really want, my advice would be to keep looking for a solution that might.

Again - I'm not going to oppose your proposal. I sincerely wish you all possible success and hope that you can get it approved and implemented - and are happy with the ultimate results.

---

Thank you, GM

I don't know much about the apps, maybe one day they might be able to do what you are looking for. I would also like to see some small improvements on the categories, such as a button for all unconnected profiles, or listing the death location of the profiles.

WikiTree+ already can do a lot of things and you can save any results as a spreadsheet and sort it. But there are two problems: the first also is because of how WikiTree was programmed: every profile contains just the information about itself, with links to other profiles. That's probably why it can't show parents or spouse in the results. The second problem is that it doesn't search the biography. I assume this is because of server resources, because then it would need a way faster server and this means more costs that we don't have, as WikiTree is free. I personally would love if both would change.

What WikiTree+ already can do, is searching the location fields. So if you search for Bümpliz, you will get the profiles that have Bümpliz in one of the three location fields. For Bümpliz, this porbably isn't really a problem. But already Berne might be a problem, at least if there are over 1000 profiles and you would need to look through them manually for some reason. As the location fields are each one field in the database, there's no difference between Berne city and Berne canton. Worse, there is also no difference to Berne as a former sort-of-country. Then, people might write Bern in German, but also Berne in French or English - which you have to search seperate in the database (or you do a search with "AND"). If you search for "Bern", also "New Bern" turns up in the results. I'm sure there would be technical solutions for this (ignoring the software we have), such as geocoding where you would need to pick a location on a map or similar. But I imagine a nightmare if I look at the German location fields, where I have absolutely no idea how to use the proper "then and there" locations. Or a solution might be to have each one database field for village, municipality, canton, country. But the later wouldn't solve the problem with languages or "New Bern".

So, what we do with profiles to group them, no matter what "then and there" location they have in the location fields, is to have location categories that group all profiles together. By deciding on the naming of categories, we would get sort of a core name. Category names can be searched in WikiTree+. But I have to admit that the search for categories doesn't work as expected, so I will look at least into this detail.

---

I applaud your initiative, energy and thoughtfulness! Please don't interpret my comments as opposition to what you are trying to accomplish. I do recognize that "the perfect can be the arch-enemy of the good" - and there is a lot of good in what you are proposing.

Allow me to pursue your last point: "By deciding on the naming of categories, we would get sort of a core name".

I think that idea has merit, provided that the geographical definition of the location named by the category does not change. That is pretty easy at the highest and lowest levels of analysis (continents and communities), but it gets messy in the middle - especially during periods of conflict (what country is a town on the Crimean penisula currently part of? - if the "core location" is "Foros" or "Sevastapol", then identifying the place as "Russia" or "Ukraine" becomes secondary). 

Your idea to use the "community list" for Switzerland from 1980 would probably result in a (large) list of "core" categories - the vast majority of which would refer to the same geo-boundaries over decades, if not centuries. My concern is not about using that list to create the list of core categories, but with permanently defining the core categories in terms of that or any other time-dependent list. I suppose my minimum "ask" is that there should be some discussion and resolution of the question "what do we do if (when) the actual geo-boundaries change?" I am NOT particularly concerned with the shifting assignments of locations to municipalities, counties, states, countries, or empires. In my opinion, a neutral system identifying the lowest-level location units WITHOUT including any historically-bound hierarchy would be the best bet. You can let users FIND the category by referencing the larger context at the time, but the "core" category code should be as neutral as possible, so that it remains as "timeless" as possible and would only need to be changed if its physical boundaries are actually re-defined. We would still need a strategy for dealing with that (very rare) situation - but that would avoid having to maintain (or accept incorrect) political hierarchies (and/or languages).

Basic idea: use the (historical, political, language) hierarchy to DETERMINE the right "core" location category, but only RECORD the (neutral, lowest level) location category code in the profiles.      

---

... one more thought: it would seem to me that the benefit of "grouping" profiles diminishes as the location categories get bigger. Your discussion of Bümpliz and Bern is a great example: If the "core" location category attached to one profile referred to the small geographical area named "Bümpliz", and another profile had a "core" location category for "Interlaken" (both within the City and Republic of Bern in the 18th century), then searching for "Bern" in the location FIELDS would return both of them.

But the grouping by "Bern" is rather meaningless in that case, if you were trying to trace connections between individuals. You might well end up with over 1000 profiles.

If the location categories ONLY referred to the lowest level units, that wouldn't be a problem. A little navigation aid (as I have seen on WikiTree in other contexts) might be used to allow easy selection of the neighboring low-level location. It wouldn't be as easy to say "show me everyone in the whole city of Bern", but if your category page showed only those in the "Innere Stadt", you would be offered the chance to look at profiles marked with "Kirchenfeld" to the South.

One more point: IF the "core" location categories attached to profiles are limited to only reflect the lowest-level units, then future apps may be able to use that information to allow time-and-language sensitive groupings (and thus allow cross-checking and correction of info in the location data fields).

This does NOT mean that a profile couldn't ALSO have higher-level location categories (like "Germany", "Bavaria", "Switzerland" or "Bern"). It just means that those "higher level" terms would NOT be included in the "core" location category and could not be "core" location categories themselves. In my opinion, that would be much better (and easier to use and maintain) than allowing "core" location categories to exist at multiple levels of analysis.

It might be a good idea to insist that every profile has a "core" (= lowest level) location category, perhaps even add one automatically on creation, the the default being "unknown". That way, new users in particular would not be subjected to the stress of figuring out exactly which detailed geo-location was correct. They could attach a higher-level location category like "Switzerland" and leave the "core" location category "unknown".

I would also STRONGLY recommend that the location category attached to a profile provide for the optional addition of both a DATE and an EVENT parameter. We may not think we "need" this now, but looking ahead it might allow apps to differentiate in important ways. Maybe a couple that resided and appears in multiple events in the Innere Stadt simply went to Bümpliz to have a wedding in a nice old church. Maybe it would be interesting to tag the profiles of their guests and parents as also having been in Bümpliz on that occasion. Definitely not mandatory or even recommended in every case, but if we could include the option when designing the "core location category" system, it might be a useful tool and/or additional bit of information to use when working on brick walls and trying to figure out family connections.

---

Hi GM,
These are all very good thoughts.

However, I assume that in Switzerland it was rather rare for villages or towns to change their geographical location, whereas this seems to have happened in Italy. I have already read about several places that were damaged in a landslide and then rebuilt nearby. In Switzerland, many communities can often be traced back to the High Middle Ages with their current name or a similar name. At the municipality level, not many changes are actually to be expected. As you wrote, the situation is different at cantonal or regional level and also at country level, although Switzerland didn't have as many changes as Germany or Italy, for example. This is also one of the reasons why they / we decided against historical location categories in these two projects - because it is simply too complicated and in the end we just want to group the profiles that belong together.

Only the category name is entered in the profiles themselves, e.g. [[Category: Schlosswil, Bern]]. If the entire category actually needs to be renamed (and not just individual profiles), then there is a command for renaming and then EditBot would update all profiles.
So I wouldn't worry about this very rare and special case of a geographical change until we find such a case. Or have I misunderstood you?

I agree that the larger a location is, the more crowded the location category will be and therefore possibly less useful. But I would still start as suggested, and if someone wants to research this place in more detail, there would still be the possibility to make subcategories.
But Bern is another good example: anyone born etc. in Bümpliz after 1919 is registered in official documents under Bern. Without an exact residential address, which can only be obtained from the residents register in the archive or perhaps from the address book (not all people are listed there) or from family documents, it is impossible to assign a person precisely to Bümpliz.

It is correct that a search in WikiTree+ for "Bern" would find the city of Bern, Bümpliz and Interlaken as part of the Canton of Bern.
I have found out how to search for categories in WikiTree+ in "Text Search", here is an example: CategoryFull="schlosswil,_Bern"
As said, categorisation does indeed become pointless for cities at some point (see the city of Rome in Italy), but I can't think of anything better if the source only mentions that place.

According to WikiTree, we should only add the lowest category, which for location categories means that the municipality would be entered in the profile if it is known (sometimes only the canton or country is known, then a higher level category might be added to the profile).

At the moment, I'm fine with new members not adding any categories at all. It's a very complex topic. In the Italy project, my / our plan has two parts: first create all location categories with at least one profile, then use WikiTree+ to search for further profiles and add the appropriate categories there. This will of course take years, but this way new members won't have to go through the stress of entering something incorrectly.

I find the other suggestions interesting, but I have no idea how we could do this. That sounds like something that might be done with apps. Personally, I would like to concentrate on what is technically feasible first :-). Maybe that would be a good basis for an app.

---

I wish you well. It sounds like you are completely convinced that your approach will provide the functionality you desire, and are willing to spend years making it happen.

Maybe some day, in a different life, we will sit down together with a favorite beverage and find a way to overcome my inability to clearly and convincingly communicate why I believe that there are some fundamental flaws in that approach.

In the meantime, the windmill has won and I won't take up my lance again. I will retreat from the glorious arena known as "G2G" and go see what Dulcinea is up to.   ; )

[category: la Mancha]