WeRelate talk:Suggestions/Naming Conventions for Nobility Living before the adoption of Modern Surname Practice

Can we try a different approach? [19 February 2013]

When you say that WeRelate is optimized for the modern definition of surname, that is only partly true. As far as I am aware, it is only the categories feature that assumes surnames are family names. Default page naming and searching both rely on the use of surnames wherever possible. Surnames have been around for over 600 years, and have not always been family names. In fact, in Iceland, they are still patronymics or matronymics (Wikipedia:Surname).

Why not fix the categories feature instead of changing how people use surnames? The software that I use, and I suspect other genealogy software as well, provides navigation and search by surname, as well as finding potential duplicates, etc. From my experience of sharing data at RootsWeb or WeRelate, most people put into the surname field whatever was considered a surname at the time, especially patronymics for Scandinavian names prior to the 20th century. And in spite of its limitations and issues, I think we still want to allow GEDCOM upload to WeRelate from people's personal databases (to limit data entry errors).

Given that the earliest use of the word "surname" dates back to the early 14th century, before it was equated with family name, it seems to be revisionist to assume that people did not have surnames before the modern use of family names. Noble names, such as "de Malbank" were surnames by the earliest definition of the word: "an epithet added to a person's name" (see: Word Origin & History of "surname").

Rather than restricting the use of the surname field, we should consider changing how categories make use the field. Maybe it could be something as simple as a flag that people can uncheck if a surname is not a family name (good user interface design dictates that boxes be checked for something positive and unchecked for something negative).

Since I am still in the process of loading my data, I have not explored name categories much. Therefore, I am not sure if this simple solution would solve the issue - but I would much rather we explore something along those lines than to stop using the surname field for something that was defined as a surname at the time the person lived.--DataAnalyst 20:32, 18 February 2013 (EST)

Thanks for considering my proposal! I admit, tossing the surname field seems like a sacrifice. But I found it to be much less so than I initially suspected.

Considering that strings are indeterminant length XML under the covers, there isn't any particular size limitation on either field. Sacrificing use of the surname does not cost you in the overall size of a name you might create. Also, searching isn't a simple affair of equating a field with a target string. Rather, it's a matter of whether the indicated field contains any or all of the set of indicated target strings. Try this example - "Bjornsson" - in the given name field. Not too surprisingly, you get all the given names that contain that patronym - which is presumably exactly what you asked for. Only if "Bjornsson" is truly being used as a modern surname, would you want to place it in the surname field - and then you'ld want to get names where that's a modern surname.

What if you're looking at an "early" form of surname? This is perhaps a more interesting case, but I'm not sure what we gain there either. The point of a surname is to search for genuine examples of the modern surname - and to see groups of people that genuinely might be related in the western style by way of that surname. What is the practical utility of a pedantic insistence on treating proto-surnames as, in fact, surnames? If you can't recognize modern-form descendants - my claim is that this simply isn't what we mean (at least in WR at present) by a surname. Let the string live elsewhere (given or suffix field) - rather than trying to mash the semantics of "surname".

So I came to the conclusion, that the ability to label a portion of a name as the "surname" is useful IFF that name, in fact, behaves as a true modern-form surname that relates people across several generations. Otherwise, it's simply no loss. --jrm03063 23:24, 18 February 2013 (EST)

How WikiTree handles it [19 February 2013]

You might be interested to see how WikiTree handles this issue:

http://www.wikitree.com/wiki/Name_Fields_for_European_Aristocrats

Jillaine 23:09, 18 February 2013 (EST)

That's interesting. I tried using the name of a house of nobility as a surname. I didn't like putting it in the surname field with the rest of the name, since it created name strings that looked more profoundly different than what you would find in the literature. So I tried instead to use multiple name entries. The initial entries would consist of names as they might appear in the literature. A final, following name, consisted only of a surname field populated by the name of the house of nobility. I worked with that for quite a while, but decided that it looked artificial. I also found that most of the categories created (name crossed with geography) were not apt to be useful. So I wound up moving to the simpler explicit form that I'm using now. --jrm03063 23:34, 18 February 2013 (EST)

Wikitree has a very weak search engine, unfortunately. Jillaine 10:16, 19 February 2013 (EST)

Patronymic names [19 February 2013]

In the Netherlands, surnames were generally adopted in 1811. On WR, the standard protocol for people who died prior to adopting a surname is to put their patronymic name in the surname field (for example, the pages for Family:Jan Douwes and Ettje Meinderts (1)). First, the majority of our Dutch GEDCOMs already have the patronymic name in the surname field. Second, if the surname field is left blank, the page is titled Jan Unknown which is not beneficial. --Jennifer (JBS66) 10:04, 19 February 2013 (EST)

I accept that it's been the unchallenged practice by virtue of the contents of inbound GEDCOMs. But I'm also pretty sure there's never been an on-point discussion, that reached a conclusion that tossing such names in the surname field led to anything useful (other than less typing).

I agree that a title of "XYZ Unknown" isn't helpful for a page name - but I treat the name(s) on the page and the name of the page as separate issues. Besides the ability to rename a page, it's certainly possible to add a page as "given=first" and "surname=last", then to move the patronym to the given field after entering edit for the Person/page (I do this all the time).

But let's try coming at this from a different direction. What value exactly, is gained by having a patronym in the surname field? If it simply serves to increase the specificity of the given name - then it works just as well if placed in the given name field (you can search on both). I offer that there are only one advantage to placement of such names in the surname field:

• The limitations of other software and related use practice, have conditioned people to expect to place patronyms in that field, regardless of the correctness of the choice, or the implications of that choice on WeRelate. GEDCOMs, resulting from such software, will likewise carry that practice.

If we think this is worth dealing with - what's the best way to do it? Perhaps we could create a template that tags such pages as having a patronym in the surname field. Then what? The software can omit generation of the various categories, and perhaps omit the patronym from surname searches. Great! But how is that different from just pushing the patronym over into the given name field, and leaving the surname empty? Either approach requires some editing of the Person page - but leaving the surname field empty works today without any supporting code changes.

If you think there's a need for consistency with broken behavior in other software and GEDCOMs - then I think you're on the hook to get Dallan to sign up for software changes. I don't think the current situation of treating patronyms as genuinely modern surnames (and therefore creating scads of useless categories and entries therein), is at all reasonable. I could go with either approach - omit the surname or software changes to flag that the surname isn't a surname - but I'ld like to know which. --jrm03063 12:25, 19 February 2013 (EST)

I'm a bit late jumping into this discussion. I am still somewhat new to Werelate, and it has only been a few months that I have only been poking around the areas of Werelate where patronyms commonly arise, so I was a bit hesitant to stick my two cents in, but anyway, here it goes... I think I can understand the argument for putting patronyms in the given name field: Russian patronyms seem more like a middle name than a surname. But on the other hand, maybe that is because Russians also have "modern" surnames. In situations where "modern" surnames don't exist, patronyms seem closer to surnames than to given names. I believe this is the opinion of people living in the modern age who actually use patronyms -- at least, if the Icelandic Ministry of the Interior has any authority on the matter. Also, in entering medieval Welsh people by hand (I am not about to inflict my GEDCOM on you all), I found that searching for duplicates was pointless unless the patronym had been entered in the surname field. I guess this might not have been such an issue if the patronyms of people already in the database were in the given name field, but few were. I am OK with going along with whatever convention is decided on, and I don't understand all the software issues, but my general opinion is that while patronyms, in the absence of surnames, might not be "true" modern surnames, even less are they true given names, so in a system where I was forced to choose between "given name" and "surname", I would prefer to put patronyms in the surname field. --Werebear 20:11, 17 March 2013 (EDT)

Just to add a little: surnames and patronyms basically serve the same function -- they make individuals easier to identify by specifying the family of origin. There are important differences, of course, but to me those seem secondary to the fundamental similarity.--Werebear 20:26, 17 March 2013 (EDT)

I'm coming around to another point of view... [22 February 2013]

In working with the conventions as I originally wrote them, I'm finding myself a little less comfortable with the idea of not using the surname field in at least some situations. While the approach works well for many of the situations I've been dealing with (in medieval and earlier time periods), I am starting to better appreciate the concerns that others have expressed about avoiding use of the surname field.

I'm also thinking that my approach is less reversible if we change our minds about things. Not that anything is irreversible on a wiki - but the truth is that we don't really know what the right way to handle patronyms as surnames (or other non-modern forms) is going to be. Stripping the surname field on such pages solves the immediate problem of generating scads of categories - but it wouldn't give us a way to find our way back to those pages if we make a different choice about things in the future.

So now I'm thinking that we need another way. Instead of just always stripping the surname, if there is some belief that the person in question had a surname (just not a surname where it makes sense to generate the standard set of categories), then the user is free to do whatever makes sense for now, but they will also add a template that marks the page as having a {{NonDefaultSurname|Name}}. The name parameter would be optional if you want to designate what that non-default surname is. Perhaps, the software could be updated to recognize this template and suppress automatic category generation on those pages. But whatever the eventual approach, the template would give us a page where we can look at "what links here", to systematically get back to pages where we want to revisit what we're doing surname-wise.

How does this sound to folks? --jrm03063 11:59, 22 February 2013 (EST)

Discussion transferred from talk page of Ekjansen

Surnames and Nobility... [18 March 2013]

You're going to find a lot of pages for nobility where the surname field is empty - which is my doing. I've been taking the view that "van <whatever>" or "of <whatever>" isn't a surname. I hate seeing a whole bunch of useless category generation at the bottom of the page.

I wrote a proposal on this, and some folks did find my position a bit extreme, particularly for cases where a patronym is declared to be a surname, even if it isn't inherited like a conventional present-day Western surname. For those folks, my last thinking was that we would mark the page with a template - {{NonDefaultSurname}} - which wouldn't really do anything for the moment. Potentially, the software could be changed to use that to decide not to generate categories. Alternatively, if practice for these names should change somehow, we can at least go to the template page to systematically find all the pages that need to be updated.

--jrm03063 17:56, 26 February 2013 (EST)

I don't really agree with this construct, but it won't hurt to add this template. To include the patronyms in this category there will be a 100'000 pages of Dutch people in WeRelate to be enriched with this template. Further in my European view and also in European genealogical publications the surnames of the nobility are used as real surnames. I don't think the American Wikipedia nameing standard is the best choice, I would prefer the German/Dutch/French original names for those nobles from continental Europe, but I can't speak for the British peerage.--Klaas 18:16, 26 February 2013 (EST)

Let me take this a bit at a time.....

* I've updated my document, and would love for you to offer your views on the talk page. I may even take the liberty of bringing some of your observations over there, so that the discussion stays somewhat together.

* I can see the burden of putting a template on every page where the surname doesn't inherit in the way that WR software anticipates.

* Explicitly requesting generation of categories seems even less apt to be appropriate (that would be, putting a designator on all the pages where surname practice IS as WeRelate currently expects).

* I agree that it has been common practice to use "of location" to refer to someone who is really of the noble house of that location. I think there are a number of practical technological reasons why that happened to begin with, but it doesn't make them useful or meaningful. It also doesn't mean that the practice should be continued, when it's essentially incorrect, and particularly for a group that is ultimately a distinct minority of people (I think this may be one of the few things where you and I appear to be in actual disagreement).

* If useful categories are going to be semi-automatically generated, we need to do something - even if it isn't practical to put a marker on EVERY person page that either does or does not follow the inherited last name practice.

* I definitely intend and prefer names ON the page, as well as the name OF the page to be in forms that are closest to what would be considered "native" for that person. However, if an editor is not a master of the appropriate languages, and the appropriate names are not yet established, we don't want to preclude that editor from making contributions in the meantime.

For patronyms that practically serve as surnames - in relatively recent European history - is it the case that the patronym is objectively recognizable? If there are introducer strings that mark a name as being a patronym, we could potentially register those and make the software look for them. Alternatively, perhaps the introducer and patronym together, could be designated on the Surname page, as being a patronym only? Then the software could use the surname field content to lookup guidance on whether to treat the surname as a patronym.

I'm not trying to make things harder, or to inflict a particular set of views. I am however, finding that without some additional nailed-down practices such as these, the results I'll get in the noble and royal genealogical spaces are not going to be satisfying or attractive. Please do feel free to vigorously disagree - but understand that I'm looking for something that will let me work effectively now - or at least soon - not just in some remote future. --jrm03063 18:56, 26 February 2013 (EST)

I feel like we have to do something - the default behavior is burdensome in the extreme for fo

I will comment the 6 statements above:

• I agree to move the (or some) statements made here on the talk page of your document.
• This is clear.
• I will precise why we can't in general add only one defined surname-category to people just with patronyms. My direct oldest ancestor is registered as Haarman which is not really a surname but comes from the hamlet or farm where he lived. So because of my familyname one could give this person the Jansen-Netherlands category. But this doesn't work because his male descendents took different surnames: van der Haar, Kieft, Jansen, Evers, Everts - to add one of these as his surname-category is not correct. This is absolutely nothing special or unique, because in 1811 every person could make a free choice of surname and in quite a few famlilies they did so.
• I do prefer and advise to use the surname categories for the nobility as done in the Europäische Stammtafeln
• I am not much (not to say never) working with surname-categories, so I can't give a comment to this.
• See my note above: Europäische Stammtafeln.

For Iceland: there are no surnames at all, just patronyms, for Northern Europe, the Netherlands and northern Germany the surnames have been introduced as soon as the civic administration started. In my opinion we should use the patronyms as surnames before that.--Klaas 09:43, 27 February 2013 (EST)

Thanks so much for taking the time to thoughtfully respond. I'll try to bring this together and give a sane response when I next have the chance.

My Very Best Regards, --jrm03063 09:55, 27 February 2013 (EST)

--DataAnalyst 19:48, 28 February 2013 (EST)=== Discussion Continued... [27 February 2013]=== I we think that it unrealistic to place a designator on EITHER all pages that ARE a conventional western surname or all pages that ARE NOT - then we start running out of options fast.

I wonder if we can imagine some logic that examines a surname, and for some large majority of cases, correctly identifies whether the string is a surname or patronym? If so, we could rely on a combined approach of that logic to make an initial determination of whether to apply the standard surname categories, refined by the ability to designate either {{NonDefaultSurname}} or {{DefaultSurname}}? --jrm03063 12:20, 27 February 2013 (EST)

How much of this is being driven by the desire to perfect what text appears for automatic categories at the bottom of pages? There is a good chance these categories may be removed (based on the feedback on the Watercooler). In that case, if we put aside for the moment any concerns about automatic categories, what are the remaining issues you are trying to solve? --Jennifer (JBS66) 13:36, 27 February 2013 (EST)

A fair bit - and I think that the automatic generation of categories probably has been more harm than help. But the question remains for nobles and royals in the pre-1300 (or so) period - and more so as we go back. In some cases, a "toponymic" was jammed in to a surname field aeons ago, more on account of software restrictions and limitations than on account of the string being a reasonable approximation of a surname.

If you can tell me that I can rely on elimination of automatic category generation, I should be able to narrow the scope of this suggestion considerably. --jrm03063 15:08, 27 February 2013 (EST)

I understand your frustration with automatic generation of categories, but I'm not getting why you are so against using "of <placename>" in the surname field. Granted, the tags associated with many nobility were probably assigned after their death, and therefore are not true surnames, but even so, if a qualifier is added to a person's name to distinguish that person from others with the same name, that is essentially a surname by its earliest definition. As far as I know, surnames did not originate as inherited names - that is a later concept. And qualifiers that originated as place names became hereditary surnames - we may not know in which generation that occurred because of reliance on secondary sources that may be using the surname anachronistically for earlier generations. My family tree shows a "de Charlton" from the 13th century, who passed on that name until it became "Charlton" in the early 15th century - I don't really know when it changed from being a description of where the person lived to a truly inherited surname.

A second point I would make (less relevant now that there is talk of removing automatic category generation) would be about the usefulness of categories that reflect non-inherited surnames. While many genealogists like to focus on a particular (inherited) surname and find all the relationships, there may be others who want to tease out all the recorded information about (say) "Knut Olsson" from a particular generation, in order to separate information on one person from information on another. In this case, "Olsson" as a category is not absurd, even though it is a patronymic, not an inherited surname, and the Olssons in XYZ parish might or might not be related to each other. (In reality, there would be a very good chance that they would be second cousins, their fathers having been named after the same grandfather.) So just because the most popular type of surname research relates to inherited surnames does not mean that others might not be interested, for very legitimate genealogical reasons, in categories of patronymic surnames. The relatively low number of first names in common use prior to the 19th century means that the number of patronymics is not absurdly high compared to the number of inherited surnames - so volume would not necessarily be a reason for excluding them.--DataAnalyst 19:49, 28 February 2013 (EST)

First off, thanks very much for the careful response. I think we disagree less than you might think. I have the disadvantage of having put an initial practice proposal out there in hard terms for all to see - and the extent to which that represents my personal views (and changed views) is much less obvious.

I'm currently writing elsewhere - that I'm not fundamentally a devotee of the "conventional" western surname definition - I offer that it's simply what the software inflicts. I've tried to work with the system as it is, and come up with practices that are orderly and don't lead to wretched display. I would also like to be more certain that the category assignment is about to go away - but when I asked about the matter I was told that the oversight committee might get to it in a few weeks. It's hard to be inspired that a change in direction is forthcoming. When things get nailed down on that - I'll be able to really revisit the proposal.

I'm not FOR removing the (is this the right term?) "toponyms" - I'm for moving them out of the surname field, and adding them as suffix/title information, which I think is more correct as a matter of what the strings really are. I'm also doing this in the context of adding Noble Family category and designation information, which hasn't previously been systematically present. To the extent that I've made changes of this sort, there will be a way to revisit them systematically.

I'm also not against trying to do something intelligent with patronyms. I have even considered whether software could analyze our database and (reasonably accurately) recognize patronyms so that we can work with that information. I think I've already agreed that it's practically impossible to push patronyms out of surname fields for reasonably modern, non-noble/royal genealogy. It's also unreasonable to expect people to manually tag all pages that ARE or ARE NOT patronyms. --jrm03063 23:07, 28 February 2013 (EST)

I think werebear's comment about searching is really important. How would we expect people to search for the name? Most likely they're going to put the patronymic name in the Surname field. Yes? Jillaine 15:24, 18 March 2013 (EDT)

If we're going to let the state of WeRelate technology drive the choice, then we shouldn't ever allow patronyms in the surname field, since they yield a bunch of obnoxious and useless categories (at least for the moment). But I think a quick test search will show that identifying a name term as being part of the given or surname - in a search - is usually a soft limitation.

I'm starting to think that any absolute decision about placement of patronyms in the surname field or elsewhere is wrong. Instead, we need to understand how the name was used in the context of its times and the historical practice of that family. --jrm03063 18:58, 18 March 2013 (EDT)

My comment isn't about the technology, it's about user behavior. Moving names otherwise thought of as surnames (despite your arguments that they really aren't surnames) out of the surname field does harm to users trying to find those profiles. And you discredit your "we-shouldn't-be-driven-by-technology" argument further by your own actions being driven by WeRelate's technology that generates surname-in-place categories. The disruption your single-handed actions is causing seems far out of scale with the annoyance of a bunch of categories at the bottom of the page that few people probably use anyway. But what disturbs me most is that you're working against the spirit of wiki and making major changes to ways names are entered all on your own. And if you're doing so simply to bring this issue to the forefront because the issue is not getting the attention you feel it deserves, well, frankly, such behavior is petty and juvenile and has no place here. Jillaine 08:02, 21 March 2013 (EDT)

What in the world are you talking about? I've struggled for years to bring some order and sanity to the medieval spaces - de-duplicating, adding sources, and lately, trying to bring in houses of nobility to try to help further add some order and organization. Instead of contributing a concrete opinion on the subject at hand - you take a gratuitous swipe at a practice I didn't even develop - but rather - have simply carried from the original effort by Amelia. I have reached out proactively to try to get people to talk about the issues relevant in these spaces (you are, after all, commenting on a subject/thread I initiated for just this purpose). When people disagreed, I've adjusted and tried to come up with something else that people can agree with. I'm listening and trying to figure out what the standards are - or ought to be. Why take offense? How about helping with the question at hand - just what is a surname?

It's sort of ironic - I really don't care much what a surname is. I'm learning as I go. I'm pretty sure that they didn't exist before about 1000 AD and that they're pretty universal by about 1400 AD. Stuff in the middle is all over the map. They're sometimes last names as ordinary Americans understand them - apparently they're sometimes other sorts of things. I'm trying to take the medieval spaces to a next level of consistency and quality, and I'm trying out conventions that seem like they'll help. So maybe I'm wrong - great! So I took the first step, and offered the absolutist definition below that got folks very riled up:

1. Whatever a surname is, we don't need to figure out, because WeRelate has a default sense that last names are inherited and creates a whole bunch of categories that only make sense if that's the case. Therefore, patronyms aren't surnames and so on.

This created a bit of excitement (and mind you - I didn't create the behavior of the software, I was only observing it). I am happy to accept the position of folks who claim that patronyms are often understood as surnames by virtue of being the accepted practice in the society. Great! Thanks! This helps! So I moved to a definition that I'm working with now:

2. A surname can only be recognized, and even then imperfectly, from the family and historical context. If a given family group have names that reflect a practice of repeating a style, or reliably using a patronym, or some other pattern, then the string is a surname (whatever else it might be).

So as I work through the medieval spaces now, further cleaning and de-duplicating, I am trying to assign people to noble families as best I can. I take some initial opinion on whether there seems to be a surname practice or not in the family, and then I run with it. Sometimes, I wind up changing my mind - but that's fine - because I now have the group in a common noble house category - and I can revisit the group systematically and quickly. Indeed - that means there's a great place to discuss what ought to be the practice for that group!

I ABSOLUTELY INVITE ANYONE TO DISAGREE! Disagree with a specific page. Disagree with a practice I've adopted for a family. Disagree more generally! I mean - it's all good isn't it? I never claimed to have all the answers or be any sort of expert! I only know that these spaces were a disaster when I started a few years ago, and they now actually have a chance of becoming something modestly useful. If ideas change - I can go back and resolve things.

If someone has a better definition for "surname" than - "whatever I feel like" or "read my mind". I would be very, very glad to hear it. I do not desire to do work that is not accepted - but neither will I stop working because the community hasn't yet offered workable guidance on how to do some types of things. After all, the ultimate counter-wiki is to not act because someone, somewhere, might not agree.

I think the adage was to "be bold". I am. Now can we direct some of this ire in the concrete direction of coming up with a surname definition that can work for a project like werelate? --jrm03063 10:17, 21 March 2013 (EDT)

Initial Version of Suggestion Withdrawn [9 May 2013]

I regret that some members of the community have taken offense at my initial proposal and attempts to exercise the practices suggested therein. I more greatly regret that as my perspective and ideas on the matter changed, such changes did not seem to be understood or recognized to their full extent. To end confusion on the matter, I've renamed and labeled the original proposal as withdrawn. A new effort will be forthcoming in the near future. --jrm03063 18:05, 22 March 2013 (EDT)

(To be clear - if someone ELSE wants to put forward a new effort, they may - this user has endured enough). --jrm03063 16:59, 9 May 2013 (EDT)