User talk:Quesotiotyo/Year 2

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

anexes

Regarding annex/annexe (L20033), I'm not sure how best to model it, but "anex" is attested as the U.S. Postal Service's preferred spelling for the street name designation. [1] (The USPS also maintains countless outposts called "annex", with the more common spelling.) It follows that the plural for "anex" would be "anexes" rather than "annexes", but that plural is naturally rarer because there would be fewer reasons to pluralize a relatively rare street name designation. – Minh Nguyễn ^💬 20:34, 14 August 2021 (UTC)

"ANEX" is an abbreviation in that context, for use when writing an address on a piece of mail (often in all caps) within a limited space. You can see a similar pattern with "SUMIT" for "SUMMIT" and "TUNEL" for "TUNNEL". There also seems to be some built-in leeway with the spelling of some of the suffixes, presumably to account for likely misspellings: "BAYOO" for "BAYOU", "RADIEL" for "RADIAL", "SHOARS" for "SHORES" -- I wouldn't call these "abbreviations" as they are no shorter than the standard forms that they represent.

I've searched quite a bit on Google Books and in various dictionaries for any other possible uses of "anex" and haven't found any (other than the Middle English variant spelling listed in the OED). I could see a case for adding "ANEX" to annex/annexe (L20033), just as you had done with "ANX". I'm not sure that it makes sense to try to apply the standard rules of pluralization in this particular context (note that a couple of the suffixes have a plural abbreviation explicitly given, such as "HOLWS" for "HOLLOW" and "TRLRS" for "TRAILER").

--Quesotiotyo (talk) 00:22, 16 August 2021 (UTC)

I disagree that "anex" is only being used as an abbreviation in this context. The table only lists the preferred spelled-out word in the first column and any alternative spellings and abbreviations in the second and third, but "anex" appears in both the first and second columns, while the other examples you gave only appear in the second and third columns. I'll readily admit that the USPS preference for "anex" as the spelled-out form is bewildering, considering that even they use "annex" on signs outside their postal annex facilities. I believe the table's inclusion of plurals is meant to be non-exhaustive: only for plurals that commonly appear in addresses, whereas e.g. "Bends" or "Causeways" is less likely to be part of a place or street name. If there's a way to mark a form as exceedingly rare, I'd happily support it. Newspapers.com turns up over 128,000 results, but I don't know how much stock to put into results that could include abbreviations, names, and likely typos among much more deliberate uses of this spelling. [2][3] (Clippings courtesy of my Wikipedia Library account.) – Minh Nguyễn ^💬 01:12, 16 August 2021 (UTC)

I must beg your pardon Minh -- I looked at that page several times and completely overlooked that "ANEX" appears in the leftmost column as the primary street suffix name. Suddenly everything that you were saying makes a lot more sense! :) What still doesn't make sense to me is why that version is currently given as the preferred spelling when as early as 2000 and as recently as 2011 the USPS website listed "ANNEX" as the primary name. I thought that perhaps it was a typo introduced when the website was redesigned, but the same change appears in PDF versions of the Postal Addressing Standards ("ANNEX" in the July 2006 version, "ANEX" when it was printed again in July 2008.). I'm not sure what I find harder to believe: that this was an intentional change, or that a typo was made by someone formatting official USPS documentation, it was unknowingly copied onto their website, and both errors have gone uncorrected for more than 13 years.

In either case, "anex" is certainly attestable. Thank you for the newspaper citations -- I definitely should have thought to search for some. I'm finding plenty of uses on fultonhistory.com for both the noun sense as well as as a verb. I have also found via some more Googling an additional use of "anex"/"ANEX": as an abbreviation for "anion exchange". I have very little experience working with lexemes here, so I'm not sure how to best format this at Lexeme:L20033, or even if "anex" should be a separate item. I'll go ahead and put things back to the way they were before I messed it up and keep out of the way. Sorry about the hassle and keep up the nice work!

--Quesotiotyo (talk) 23:51, 16 August 2021 (UTC)

No worries – this discussion has given me an opportunity to expand wikt:anex, and I had no idea about Fultonhistory.com until you brought it up. Thank you! – Minh Nguyễn ^💬 04:57, 17 August 2021 (UTC)

ITT Olympic game

Hi Quesotiotyo, you may wonder why I keep on removing "ITT" from the nature of Q65242224. It is not because it is not an ITT, but because ITT describes a stage type. The olympic game is not a stage, it is a single day race. It leads the Cycling race module in the wall so to say (https://fr.wikipedia.org/wiki/Saison_2021_de_l%27%C3%A9quipe_cycliste_f%C3%A9minine_Movistar#Sur_route). Normally, as the Olympic Game ITT has already the nature, Q70114578 it is clear that it is an ITT. Why do you need this ITT in the nature? Worst case, I should create an ITT "single day race". Psemdel (talk) 15:06, 16 August 2021 (UTC)

Maybe Q70114578 should have a statement that connects it to Q2266066? I cannot provide much assistance with the modeling of cycling events or with the use of Wikidata in Wikipedia modules. I am sure that you will find good help at Wikidata talk:WikiProject Cycling.

--Quesotiotyo (talk) 00:21, 17 August 2021 (UTC)

Remixes

Please use remix of (P9810) instead of modified version of (P5059) in the future. Thanks --Trade (talk) 00:05, 31 August 2021 (UTC)

I shall use whichever property is more appropriate for the given item. --Quesotiotyo (talk) 00:30, 31 August 2021 (UTC)

Q6499064

Usually this is handled by creating a new item and moving or correcting (but not removing) the statements.--GZWDer (talk) 12:09, 13 October 2021 (UTC)

Thank you for taking the time to fix your mistakes. --Quesotiotyo (talk) 17:26, 13 October 2021 (UTC)

John Edward Bouligny (Q503659)‎

Since you asked "huh?" in your revert on the French- and Spanish-language versions of his name, John Edward Bouligny was part of the first generation of the Louisiana Boulignys to become Americanized; however, the family used French- and Spanish-language versions of their names depending upon who they were speaking/writing to and in which language (see Thomas (2017) "Vous Êtes Hombre de Bien": A Study of Bilingual Family Letters to and from Colonial Louisiana, 1748-1867. It is also attested in Martin's A History of the Bouligny Family and Allied Families that John Edward's baptismal name was given in Spanish as "Juan Eduardo", and in the family he was called "Edouard" in French. —Tcr25 (talk) 20:03, 18 October 2021 (UTC)

I will go ahead and add those versions as aliases as well as statements with the appropriate references. Thank you for providing the sources. The label does need to remain as "John Edward Bouligny" to reflect common usage.

--Quesotiotyo (talk) 20:33, 18 October 2021 (UTC)

Thanks, that makes sense... Tcr25 (talk) 21:04, 18 October 2021 (UTC)

marriage and end time: unknown value

Hi, I noticed that you changed some statements about spouses (example). I’m afraid I don’t really your edits. Could you please clarify what you mean with those qualifiers? Thank you! --Emu (talk) 15:57, 23 October 2021 (UTC)

Philipp Grobecker's marriage to Anna Grobecker had a start time of 1856 but no end time listed. Obviously the marriage did end, but the exact date may not be certain; however, since we know that Philipp died before Anna, his date of death is the latest possible date that the marriage could have lasted (I decided to add just the year for simplicity's sake).

--Quesotiotyo (talk) 20:13, 23 October 2021 (UTC)

Ranking vs Results

What am I missing ranking are prediction going into an event results are the results? Also why are you edits deletes rather than correction it doesn't encourage people to contribute. Also what is your dislike with the correct winners being over half the sailing events have more than one person. There is even clear wikipedia category for it "crew" on boats. :--Yachty4000 (talk) 15:46, 7 November 2021 (UTC)

Hello @Yachty4000: ! :) I am not sure what exactly you are asking. Can you please add a link to an item that you are having a problem with? That will help me to understand so that I can explain it to you. There is usually a good reason why data must be entered in a particular way but sometimes the reason is not obvious and is almost never personal. And if I made a mistake then I will be happy to fix it. Either way, let's work together to make it right!

Thanks for getting in touch,

--Quesotiotyo (talk) 21:53, 7 November 2021 (UTC)

You undid a number of my edits but lets just talk about Q4751917. The part I don't understand is the difference in the use of the term ranking and result. :--Yachty4000 (talk) 19:12, 10 November 2021 (UTC)

Ranking (P1352) is a quantity-type property. The value should be a number that represents the position in which a person finished within a competition (1 = first place, etc.). Results (P2501) is an item-type property. The value should be a Wikidata item that contains information about the results of a competition. You added results (P2501)3 (Q201) as a qualifier to mean that Anastasios Bountouris (Q4751917) finished in third place in sailing at the 1980 Summer Olympics – Soling (Q7400283). A human would read that and understand what is meant but a computer would not. A computer would go to https://www.wikidata.org/wiki/Q201 to look for details about the competition results and would not find any.

Now that the correct property has been added, the information will appear in this query: https://w.wiki/4NBy. As you can see, there is still a lot of data that needs to be added! That is why I am glad that you are here to help out. We just want to make sure that the proper format is used so that all of your work can be put to good use and does not have to be redone. If you are ever not sure what property to use or if you have any other questions then you are always welcome to ask me about it here and I will do my best to help you. :)

--Quesotiotyo (talk) 20:40, 10 November 2021 (UTC)

Parentheses for people's dates

I see you're adding a bunch of changes link this to add parentheses around people's dates of birth and death. It's not a form of description that I've seen used much. Is this an established convention? Sam Wilson 09:55, 10 November 2021 (UTC)

Yes, the parentheses are used to set aside the birth and death years since they are parenthetical to the "{label} is (a/an/the) {description}" structure. They also help to differentiate from any years that are functionally part of the description.

--Quesotiotyo (talk) 18:48, 10 November 2021 (UTC)

Q500639

What do you mean by this? Marc Antoine Auguste Gaudin was a father of Félix Gaudin, see "Félix Gaudin: peintre-verrier et mosaïste, 1851-1930" by Jean-François Luneau, Presses Universitaires Blaise Pascal, 2006, page 35. Андрей Романенко (talk) 17:00, 19 November 2021 (UTC)

Ah, but you put that Félix was the father of Marc Antoine instead of child. I will add the correct relationship along with the reference that you have provided.

--Quesotiotyo (talk) 19:49, 19 November 2021 (UTC)

Sardinia

Hi Quesotiotyo, I've seen that you changed the sc.wiki article for Q1462 and I had to put Sardigna back there, since it's the main article. Most of the wikis don't consider Q1462 to be an article related to Sardinia as just a political entity but first of all as an island, as you can see from the fact that all of their history sections are related to the island's history and not the autonomous region's one, and that they usually start with something like "Sardinia is the second-largest island in the Mediterranean Sea, and one of the 20 regions of Italy". The articles in Q3760293 are all stubs with the exception of the Latin one, which is a redirect, and of the Italian one, that is a bit bigger exclusively because it's a copy and paste of some text from Sardegna that was moved there from the sub-article "Geografia della Sardegna" a few months ago (on 16 March 2021‎). The existence of a Sardegna (isola) article is a mistake made by a user that wanted to follow the Sicilian example, which by the way also makes no sense since Sicilia (isola) is nothing but a copy of Geografia della Sicilia that is considered as a part of the main article Sicilia, as it should be. So if anything it's the political entity of the Autonomous Region of Sardinia that should have a separate item, like it is on the Sardinian Wikipedia, since its history is way shorter and most of the information is not about it. And the English and French descriptions for Q1462 should also go back to what I wrote, since their articles say exactly that and are mostly about the island.--L2212 (talk) 03:45, 21 November 2021 (UTC)

The descriptions are meant to reflect the content of the Wikidata item, not necessarily the attached Wikipedia articles. Q1462 and its statements have consistently been about the autonomous region and not the island itself. The struggle to map WP articles that cover multiple concepts onto WD items that (ideally) do not is an ongoing issue here (I need only point you to Help:Handling sitelinks overlapping multiple items, and in particular the section labeled "Wikidata handling until a better solution is identified", which was created six years ago and remains mostly unchanged). This is certainly the case for Sardinia and at least some of its sitelinks, as you have pointed out. Two possible solutions would be to create a new item for the merged polity/island concept (which would contain few statements and serve mainly as a hub for sitelinks) or to designate Q1462 for that purpose and migrate the polity statements to the new item. Either of these would not be a simple task (at the very least you would need to synchronize all sitelinks, incoming links, and labels and descriptions written in a variety of languages) and it would be best to solicit input from the community before such a change is made. That no one seems to have yet undertaken this suggests to me that the costs might outweigh the benefits, but you can certainly bring up the issue at either Talk:Q1462 or Wikidata:Project chat / Wikidata:Bar to see what others think.

--Quesotiotyo (talk) 21:58, 21 November 2021 (UTC)

I see, I think that the best solution would be the second one, and that the polity pages should be considered secondary ones, but I will try to contact the others here on Wikidata like you said (and even on it.wiki, to see if they can fix the situation and delete the double pages). Right now I have my hands full with other stuff on sc.wiki and elsewhere, but I will do it as soon as I can. Thank you very much for your help.--L2212 (talk) 14:38, 24 November 2021 (UTC)

Wikidata:Database_reports/items_with_P569_greater_than_P570

Sadly has not run in a month either manually or automatically, queries that were under a minute a month ago are taking over 1 minute as all queries appear to be slowing from query congestion. Any ideas? A month worth or errors and vandalism is going to be a big list, I usually run weekly minimally. --RAN (talk) 05:09, 24 November 2021 (UTC)

Clicking "Manually update list" worked for me just now. --Quesotiotyo (talk) 05:15, 24 November 2021 (UTC)

Wikidata

OK, before this goes any further: How can edit summaries appear to me on Wikidata? Because they don't appear to me and I think that part of the problem we're having stems from I being unable to add them.--EdgarCabreraFariña (talk) 20:16, 2 December 2021 (UTC)

Wikidata:Tools/Enhance_user_interface#EditSum --Quesotiotyo (talk) 20:23, 2 December 2021 (UTC)

Q2897866

Hi. I notice that you reverted my edit to the label of Louis (Q2897866).[4] The problem with removing the disambiguation from the English label is that editors in English may select it in error when they should select Louis (Q97156058). If, on the other hand, you think the items should be merged despite having different language scripts, this should probably be discussed on Project Chat as a continuation of Wikidata:Project chat/Archive/2021/12#Do we need a separate data set for the Greek form of Louis?. From Hill To Shore (talk) 22:26, 13 December 2021 (UTC)

No, the items should not be merged. Any name item is by default written in the same writing system as the language of the description; if not (meaning the label is transliterated), the native label should appear in the description in parentheses. Here is a list of guidelines to follow when working with name items: Wikidata:WikiProject_Names#Basic_principles.

--Quesotiotyo (talk) 22:37, 13 December 2021 (UTC)

Louis (Q97156058)

Hi Quesotiotyo. I only entered what user From Hill To Shore wrote there so as not to annoy anyone after the discussion. Otherwise I agree with you. Regards --HarryNº2 (talk) 01:13, 14 December 2021 (UTC)

@HarryNº2: Sorry, my fault. If you notice that I am editing against agreed guidance, it usually means that I am either not aware of it or I have forgotten it (there are so many guidance documents across Wikimedia projects that they are hard to keep track of). Feel free to revert me in such cases. The worst that will happen is that I will ask you the reason for your reversion. From Hill To Shore (talk) 01:42, 14 December 2021 (UTC)

Is not a problem, everything is fine. Best regards --HarryNº2 (talk) 01:48, 14 December 2021 (UTC)

Please stop removing useful and sourced information from the items

Where have you seen that people should not have the different mothers of their children stated in a structured way in their item? Why are you removing that information from the items? Please show the place where such thing was decided by the community, or stop doing that.-- Darwin ^Ahoy! 00:09, 19 December 2021 (UTC)

Hello there! :) I want to reassure you that no information was lost and that the only things that were removed were unnecessary duplications. Because mother (P25) and father (P22) statements were already present on the children's items, they do not need to be given as qualifiers on the child (P40) statements. The same goes for other data such as date of birth (P569), place of birth (P19), and the various name (P2561) properties. In general, a Wikibase item (Q29934200) property does not need to be qualified with a value that belongs as a main value on the target item. If we started doing that wherever possible, it would create a lot of redundancy and put further strain on the software and userbase that both constantly struggle to maintain such a large dataset. (Not to say that your extra qualifiers were creating a problem; I just like to help prune the metaphorical tree whenever I see the need. :))

I hope that that helps to clear things up for you. I do quite a lot of work on human (Q5) items and am very familiar with how they should be structured and I would be happy to look over any of the other ones that you have created to make sure that they have been formatted probably. Come by any time!

--Quesotiotyo (talk) 06:36, 21 December 2021 (UTC)

P19 and P20

The national borders change over the centuries, especially in Europe, Latin America, etc. Local boundaries, city limits, administrative districts, etc. also shift every few years. Such information is not always in the data set. place of birth (P19) and place of death (P20) has therefore under property constraint → allowed qualifiers constraint → country (P17) and located in the administrative territorial entity (P131). In addition, Commons, for example, evaluates this in the info boxes. We are no exception because of New York, as some write New York and some New York City. In the info box, the difference becomes clear by adding the state or federal state. In addition, people do not have fast internet everywhere in the world. The New York City site is huge and takes a long time to build. And then the information is hidden somewhere or not available at all. New York and New York City did not always belong to the United States, see History of New York. You'll be the first to delete this from the records. Should you have problems with this, please discuss it in the Wikidata:Project chat. --HarryNº2 (talk) 16:40, 23 December 2021 (UTC)

The first, huh? --Quesotiotyo (talk) 17:17, 23 December 2021 (UTC)

Someone single-handedly made the changes en masse without discussing it in the forum beforehand. I can remember a discussion that was explicitly requested, therefore under property constraint → allowed qualifiers constraint → country (P17) and located in the administrative territorial entity (P131). But as I said, you are welcome to discuss this in the Wikidata:Project chat. --HarryNº2 (talk) 17:26, 23 December 2021 (UTC)

Adding lifespan to WikiData item descriptions

Hi there, has there been any discussion or agreement to add lifespan information to all wikidata biographies, as you seem to be doing here. I understand doing so where there is ambiguity, but lots of these are completely unambiguous without the years of birth/death. The-Pope (talk) 03:47, 30 December 2021 (UTC)

If some of these items are "completely unambiguous", why do they contain any description at all? --Quesotiotyo (talk) 04:25, 30 December 2021 (UTC)

same question : where is the agreement to add these non-essential elements? Jmax (talk) 05:23, 30 December 2021 (UTC)

@Jmax: I find lifespans in descriptions very usefull, ambiguousnes or not, and have been doing the same thing (to primarily Danish descriptions though).--Hjart (talk) 07:16, 30 December 2021 (UTC)

@The-Pope, Jmax: Yes, there has been a discussion, see Wikidata:Project_chat#Should_the_description_of_a_person_include_year_of_birth_and_death,_if_applicable? No, there isn’t any consensus. From my point of view, this batch should be undone as soon as possible, but then again, I might be biased. -- Emu (talk) 10:46, 30 December 2021 (UTC)

there are many tools that do not want these dates as deces.matchid.io: https://deces.matchid.io/id/uwXdH7exqUaS . many people think that wikidata is only for wikipedia but it is wrong. added by Jmax

I'm not happy with this batch as well. It complicates maintenance of descriptions, and add plenty of load to the query servers since description nodes can barely be shared by multiple items. Please stop this, and preferably undo the changed descriptions. —MisterSynergy (talk) 12:42, 30 December 2021 (UTC)

Could you please elaborate on how adding this information "complicates maintenance of descriptions"? --Quesotiotyo (talk) 14:54, 30 December 2021 (UTC)

For one, life dates on Wikidata are a lot less stable than one might think. Various sources often have very different opinions about the correct year of birth and/or year of death. In Western culture, this is especially true for certain professions (such as those in the arts), but also for whole centuries. If new information emerges, adding new statements and sorting out ranking issues is relatively easy, but descriptions have to be changed for any number of languages (which is a lot of work) or they stay as they are (which is bad for obvious reasons). It’s the same reason why we generally try to avoid data duplication. --Emu (talk) 17:32, 30 December 2021 (UTC)

Years are not translated into different languages. It is simple to adjust them for multiple descriptions if the need arises. For the vast majority of people this will never be a problem. Also, please note that I am currently adjusting descriptions only for people who have a single preferred date of birth and death, both with at least month precision and neither value having been changed over the last six months.

--Quesotiotyo (talk) 17:57, 30 December 2021 (UTC)

So you personally don’t think it’s a problem and even if it was, somebody else should fix it? That’s not the best way to use your colleagues’ time.

Just to make it clear: You do realize that are still performing bot-like operations without approval and without consensus? That you have not at least suspended this operation even after several users asked you to? And your only real reason for all of this seems to be that you like your format better? Sorry, but that’s not how users should behave in a project like this. Emu (talk) 19:05, 30 December 2021 (UTC)

I take full responsibility over all of my edits and will fix any problems that I make. I do not expect others to do so. If you would like to ask me a question, please allow me to answer for myself. Thank you.

--Quesotiotyo (talk) 21:52, 30 December 2021 (UTC)

It makes it more complicated to compile such descriptions since more information needs to be included.
It also makes it more complicated to figure out missing descriptions, particular in languages other than someone's native language. Provided a person's nationality and occupation is known—which is usually the case—one can currently query the most prevalent description for this person via WDQS. This does not work any longer if descriptions are deliberately designed to be individual (rather than label+description needs to be individual) since all descriptions then have a low prevalence.

Two other aspects which have not been mentioned yet:

If this is changed for English on a larger scale, many or even most other languages will follow since they use English as the reference.
You are behaving aggressively here. Several users have raised concerns about your editing, but your batch continues nevertheless all day long. This is a poor style of collaboration.

—MisterSynergy (talk) 21:21, 30 December 2021 (UTC)

Nowhere have I stated that anything needs to be included in a description. Any information that can be added is good; more information is better.
I am only changing existing descriptions, not adding any new ones, so missing descriptions are not affected. I am not sure why you are bring up native language when nothing I have added is language-dependent. I also do not understand what you saying about WDQS but if you can provide an example, I will be happy to help show you how to adjust a query to account for this.
Good, I hope that these dates are used in other language descriptions; as they are just numbers, no translation is needed. I have no plans to do this myself.
I take umbrage with your characterization of my behavior as aggressive. I have run QS batches continuously simply because, even when doing so, this particular project will take 1-2 weeks to complete. During this time I am virtually prohibited from performing other edits, so I would like to finish as quickly as possible. Were I to have any uncertainty that these additions are not wholly beneficial to Wikidata, I would stop them immediately. I do not foresee this happening.

Thank you for responding.

--Quesotiotyo (talk) 22:42, 30 December 2021 (UTC)

There is nothing to help here, you are simply killing this workflow. It was based on the assumption that a most members of a set of items about humans with a given set of features country of citizenship (P27), occupation (P106), sex or gender (P21) share the same description in a given output language. I have done this a lot in the past using a script in order to loop over a large range of combinations of these features but it will not be possible any longer. —MisterSynergy (talk) 23:39, 30 December 2021 (UTC)

https://w.wiki/4cpy

SPARQL is more flexible than you give it credit for. :)

--Quesotiotyo (talk) 00:18, 31 December 2021 (UTC)

Sure, one can try to remove those dates from descriptions.
However, given the various formats in use, this fails more often than you can imagine. This workflow is particularly interesting for all languages other than English which usually receives enough attention. The range of possible date addition formats is *really* wide.
Anyways, this removal should not be done in SPARQL anyways, since it is not designed to be good with string manipulation. Post-processing in Python (or whatever script language one uses) and then re-aggregation would be the way to go.

—MisterSynergy (talk) 00:35, 31 December 2021 (UTC)

@MisterSynergy: I've been using really simple command line awk scripts to filter and/or build all kinds of wikidata descriptions. Handling these life span additions is not hard at all (once you're fairly familiar with regexp etc).--Hjart (talk) 06:47, 31 December 2021 (UTC)

Conceptually it is not difficult to try this, sure. But as soon as you need to constantly adapt the workflow to all sorts of special cases, it is not feasible any longer to automate it. —MisterSynergy (talk) 06:53, 31 December 2021 (UTC)

I've seen enough people add lifespans in the same manner, that I now consider it kind of (unofficial) standard. I have also often found it really helpfull. There's more than enough people in wikidata with very similar names by now and i have also seen many mistakes that could have been more easily avoided if descriptions had lifespans.--Hjart (talk) 07:38, 31 December 2021 (UTC)

Lifespans are useful and the best disambiguator if there was otherwise an identical combination of label+description. Otherwise the occupation is *usually* sufficient to identify people. —MisterSynergy (talk) 08:16, 31 December 2021 (UTC)

I disagree. Lots of people have had more than 1 occupation during their lives and it's far from uncommon to see different labels for the same person. Lifespans makes it way easier to spot coincidences. Countless are the times I've wanted to see lifespans when trying to match up new articles or relatives. Hjart (talk) 10:32, 31 December 2021 (UTC)

I happen to agree that including dates in descriptions is helpful, even if the label is unique. There are many people with the same name without Wikidata items and having a date in the description is quite useful when determining if an item is a match or not. This is why dates are added to unique names in access points in library authority files such as Library of Congress Name Authority File (Q18912790). Even if the name is unique, Library of Congress/NACO policy is to include dates in an authorized access point when they are known. UWashPrincipalCataloger (talk) 03:27, 2 January 2022 (UTC)

I don't think the mass edits discussed above is something someone urgently need to do, while it proves to be controversial. I suggest suspending the mass edits for the time being until you see explicit consensus. Voluntary suspension would help a lot at easing the tension. I don't see why you cannot move on to another task and come back at doing this later. Otherwise you might be (temporarily) blocked, judging by requests given at Wikidata:Administrators'_noticeboard#User:Quesotiotyo, sooner or later. (I'm not an admin but just someone passing by and trying to be helpful.) whym (talk) 12:41, 1 January 2022 (UTC)
Thank you for the wise words. --Quesotiotyo (talk) 20:19, 1 January 2022 (UTC)
It seems that this task is quite controversial, and I'll leave it to others to discuss/handle that, but as a sidenote, if this does gain consensus to go forward, then en-dashes should be used rather than hyphen-minuses; see w:MOS:RANGE. {{u|Sdkb}} ^talk 17:58, 1 January 2022 (UTC)
Of the more than 480,000 English descriptions that already contained a lifespan before I began, roughly 97% of them used a hyphen-minus. This seemed to me to be a well enough established convention as to not deviate from it. --Quesotiotyo (talk) 20:49, 1 January 2022 (UTC)
- I agree with Quesotiotyo. Hyphen is the typical character used to separate birth and death dates in authority files. UWashPrincipalCataloger (talk) 03:21, 2 January 2022 (UTC)
  The standard for en-WP short descriptions is to use en-dashes, since that's what's grammatically correct. We should be following that lead, not only to be grammatically correct ourselves, but also to keep the fields as synced as possible (although the inevitable endpoint here is that we abandon our descriptions and override them with short descriptions; it was a colossal blunder to fork those). {{u|Sdkb}} ^talk 21:54, 2 January 2022 (UTC)

I have temporarily blocked you. Please confirm you have stopped the QS task and I will unblock you. Please request bot approval before running this task again. BrokenSegue (talk) 18:42, 1 January 2022 (UTC)

Family name placeholders for given names

Hello. I have created Whitehouse (Q110746157) in response to your recent revert.

I wanted to explain my working practice. I do often leave family name placeholders for given names (when the name is identical). What I prefer to do, when the given name doesn't yet exist here, is to create the item, and then go through all the human items putting in that given name. This is to bring up the new given name in the drop-down menu, as far as possible - because if it is added just to one item, it may be a long way down. Also this is one way to bring under control the big backlog we have for human names, caused by bot creations.

Yes, there is also a backlog of constraint violations to fix. The places where a family name is standing for a given name are not hard to find. My impression is that the relevant given names are being created. I work mostly on a fix-as-find basis for these constraint violations, but when I am going down a list of 200 or so names, it isn't really practical to sort out everything on one pass.

So going back to Whitehouse (Q110746157), I see I spent 18 minutes doing that given name thoroughly.

You don't have to agree with any of this: it is for information. Charles Matthews (talk) 09:30, 30 January 2022 (UTC)

Discussion concerning your edits - given names & family names

Please be aware of the following admin noticeboard discussion created as a result of your edits: Wikidata:Administrators'_noticeboard#User:Quesotiotyo. I find these edits terribly unhelpful, I'll allow others to address them directly.--Labattblueboy (talk) 22:37, 31 January 2022 (UTC)

@Labattblueboy: I am in the process of correcting the given name (P735) values. Your adding back of the incorrect values makes this difficult. Please allow me to finish.

--Quesotiotyo (talk) 22:41, 31 January 2022 (UTC)

@Quesotiotyo, it appears that you have not yet completed adding back as given names the family names you removed (I was following more than just Frank Brackett (Q99522757)). I know you were blocked for some time, but please prioritize this. {{u|Sdkb}} ^talk 20:28, 28 February 2022 (UTC)

I will do my best to finish getting those in by the end of the day. Thank you for being understanding. --Quesotiotyo (talk) 20:39, 28 February 2022 (UTC)

February 2022

You have been blocked temporarily for abuse of editing privileges. Once this block has expired, you are welcome to make useful contributions. If you believe this block is unjustified, you may contest it by editing this page and adding the following template with a suitable reason: {{unblock|1=<the reason for your unblock request>}}. If you are logged in, and the option has not been disabled, you may also email the blocking administrator (or any administrator from this list) by using this form. See Wikidata:Guide to appealing blocks for more information.

⁠

I blocked your account for two weeks. Mass edits on this project require prior consensus. You have been blocked for this before, you have got complaints about your edits in a recent batch, you have decided to ignore the complaints and proceed. Next block for the same behavior might be of an infinite duration.--Ymblanter (talk) 19:56, 10 February 2022 (UTC)

Unblock request granted

This blocked user asked to be unblocked, and one or more administrators has reviewed and granted this request.

Quesotiotyo

block log • ipblocklist • crossblock • luxo's • unblock • remove gblock • contribs: +/-

Request reason:

I believe that you are referring to Batch #75984 (https://quickstatements.toolforge.org/#/batch/75984), with which I did not change any existing descriptions, despite what one user claimed at WD:AN. I added a description to around 2,300 individuals who did not already have one. There is in fact prior consensus for doing so in lieu of having no description at all -- more than half of people with a genealogics.org person ID (P:P1819) and an English description have a birth and/or death date as the entirety of that description. Also, this batch was not a continuation of a previous one, as another user insinuated. That user continues to insist that I seek permission at WD:RFBOT, even though I have never used a bot to perform any edit. Please consider that I have an extremely high accuracy rate -- fewer than 0.1% of my edits have been reverted, not counting a recent batch that was undone in error (Wikidata:Edit groups/QSv2/75178) -- and that I average around 70,000-80,000 edits in a two-week span (https://wikidata.wikiscan.org/user/Quesotiotyo). I am happy to discuss in detail the content of any of my edits and have no issue with submitting batch edits through an approval process if there exists such a place to do so. I ask that the block be removed so that I may continue making useful contributions. Thank you. --Quesotiotyo (talk) 22:00, 10 February 2022 (UTC)

Unblock reason:

Per Ymblanter below. Bovlb (talk) 23:03, 20 February 2022 (UTC)

This template should be archived normally.

Yes, I indeed refer to this batch, in which you added a bunch of nonsensical descriptions. I do not see how it is justified by a high volume of your contributions, and I do not see a reason to remove the block, but another administrator may thing otherwise.--Ymblanter (talk) 06:24, 11 February 2022 (UTC)

@Ymblanter: If those descriptions are indeed nonsensical, why have you not undone the batch? Why have you not begun removing similar descriptions from the millions of other human items that contain them? Why are you not acknowledging that several users with the most experience working on human items have expressed support (both here and above) for having these dates in the description (and have made similar bulk edits to add them), and that I have made counterpoints to the objections raised by others? If there needs to be a discussion about the particular formatting of these dates then let's have one, but the actual content and purpose of what I was adding should not have been in question and certainly did not warrant a block. The only point it is serving now is prohibiting me from making contributions to benefit the project, which I have enjoyed doing over the last 18 months and will continue to do so once I am able to again.

I do thank you and the other admins, bureaucrats, etc. for all of the work that you do to maintain and ensure the success of Wikidata. May all that I do here be a reflection of my appreciation and admiration for those who make it possible.

--Quesotiotyo (talk) 18:04, 11 February 2022 (UTC)

I am sorry but I am of a different opinion.--Ymblanter (talk) 18:25, 11 February 2022 (UTC)

I modified the block to only apply to the main namespace. I understand and appreciate that you do do good work here. I just think there should be more discussion before vast numbers of items are edited. BrokenSegue (talk) 01:18, 13 February 2022 (UTC)

Thank you for the acknowledgment. In regard to your last point, I understand where you are coming from but do not agree that this is necessary for edits, irrespective of quantity, that are patently correct in both content and structure and which wholly conform to the rules and guidelines of the site as well as any precedence established by previous community discussion and existing usage. Even so, as stated above I am happy to comply should a policy be implemented that would require the approval of batch edits before being run. Either way I will to continue to hold any edits that I make to this standard and I welcome input and correction from others should I fail to do so.

--Quesotiotyo (talk) 06:01, 13 February 2022 (UTC)

Quesotiotyo's claim that the batch in question merely adds descriptions and does not modify them as suggested in the complaint seems like an important point. I don't love these bald descriptions, but they are better than no description: They are useful for disambiguation, and they don't seem like a fragrant violation of description guidelines. Quesotiotyo is also right that we lack an agreed venue for discussing bulk edits. Some people say they should require bot approval, but that is far from clear from, say, Wikidata:Bots#Approval_process. Bovlb (talk) 17:22, 16 February 2022 (UTC)

@Ymblanter: What sort of assurance would you be looking for here for an unblock? Bovlb (talk) 22:44, 18 February 2022 (UTC)

I basically do not want to see this situation repeated for the third time. The safest way is to register a bot, but an acceptable way for me would be to discuss any edits which have a potential to be controversial in advance for example at the project chat. Ymblanter (talk) 06:51, 19 February 2022 (UTC)

I think the problem many editors face is that they find it very hard to predict what is going to be controversial. Ymblanter would probably argue that Quesotiotyo should be well-aware by this point that descriptions composed only of dates fall squarely into that category. There's certainly no harm in making the community aware of large-scale edits you're contemplating. You don't have to keep everyone happy, but it ought to let you know if there is going to be substantial pushback. And if there is subsequent pushback, it's something you can point to. Bovlb (talk) 18:00, 19 February 2022 (UTC)

@Bovlb, Ymblanter: Thank you both for taking the time to respond. I am in full agreement with Ymblanter that I do not wish to see this happen again. In order to minimize the likelihood of that occurring, I consent to posting a notice at Project chat a day or two before performing any mass edits. I will provide full details about what I will be doing and will respect the wishes of any user who asks that the batch not be run. My only concerns are that this could clog up the chat should I have many different batches planned and that it will come off as self-serving to constantly post about my work in such a public space. Might one of the subpages of Wikidata:Requests for permissions be a better place to do this? To be clear, I have only ever used widely available tools to assist in performing manually generated edits and never anything described at Wikidata:Bots. If you both feel that this is the best way for me to be able to continue using these tools to contribute to and improve Wikidata then I will be glad to comply.

--Quesotiotyo (talk) 00:42, 20 February 2022 (UTC)

This is good enough for me, and I have removed the block. We do not need plan everything at once, and presumably not all of your batches require discussion, as probably most of them are not in any way controversial. Once you have something which you think needs to be discussed please open a topic at the project chat, and we see how it goes. Ymblanter (talk) 07:59, 20 February 2022 (UTC)

That sounds like a reasonable compromise. I am grateful that we could work this out.

Kindest regards,

--Quesotiotyo (talk) 18:12, 21 February 2022 (UTC)

Thanks!

Sorry for adding the wrong gender, thanks for fixing it. How did you discover it? I guess you are looking for mismatches between a gender specific given name, and gender. Thanks again. --RAN (talk) 23:01, 28 February 2022 (UTC)

You're welcome! Actually, I came across William Tell Bartlett (Q99517759) when searching for people to add the given name Tell (Q111039047) (which I had just created) to. I figured that between the name "William" and the given image that the wrong gender had been added. I'm glad that you were able to add some more details to his item.

--Quesotiotyo (talk) 02:14, 1 March 2022 (UTC)

Incredible work on Michigan's Bio database

First off I wanted to say thanks for the incredible resolution of the persons. Have you looked at https://mix-n-match.toolforge.org/#/catalog/5080? I've similarly proposed https://www.wikidata.org/wiki/Wikidata:Property_proposal/Person#Arizona_Legislators_Then_and_Now_ID and https://www.wikidata.org/wiki/Wikidata:Property_proposal/Person#Virginia_Burgesses_and_Delegates_Database_ID I noticed that the date of death nor the position held were missing for the items that you created when the values exist in the referenced item. Were you relying on the export from Mix'n'match? Thanks again for the massive help resolving the entities. Wolfgang8741 (talk) 18:32, 10 March 2022 (UTC)

You're welcome, I've quite enjoyed it! It was rather easy to use PetScan to find all of the people in the proper Wikipedia categories that did not have a Michigan Legislative Bio ID (P10441) value and then pair those with the unmatched entries on Mix'n'match (there were five individuals that I could not find a match for: Frank Fitzgerald, David D. Aitken, John W. Smith, James S. Nunneley, and William W. Andrus -- they are either miscategorized on ENWP or missing from the Michigan Legislative Bio website). I assumed that the remainder did not already have an item and so they all got new items. I will be finishing up working on the newest batch of those today.

The reason that I did not add position held (P39) to any of these items yet is because I wasn't sure of the best way to format those statements and I figured that it would be best to hold off until a proper structure could be formulated. It can be tricky to add qualifiers to existing statements. This has been an issue with U.S. rep items, which originally had single bare statements imported from WP before far more detailed statements covering each Congressional session were appended rather than integrated into the existing statements. I've fixed a bunch of these by hand but there are still more than 1,000 items with these redundancies (https://w.wiki/4wJd).

As for the dates of death, I don't see these given in the Mix'n'match data set (which I assume was a scrape of https://mdoe.state.mi.us/legislators/Legislator/ViewLegislators rather than each individual page). Speaking of dates, there seems to be a January 1 problem with the dates of birth and death on that site, so I will have to go back and correct the ones that were imported with improper precision.

I will be more than glad to continue this work for other states when those become available. If I'm stepping on your toes at all here just let me know.

All the best,

--Quesotiotyo (talk) 19:42, 10 March 2022 (UTC)

Thanks for the detail, I wonder if you document that method any place. There are 5 missing ids in Mix'n'match's 5510 compared to the database's stated Total number of 5515. I matched John W. Smith (Q6262558), reverted David D. Aitken (Q1174133) as the reference is to his father in the article, the remainder are unclear and missing at least one might be a partial term appointment. I welcome the help. Yes, possibly a January 1 problem, they are open to emailed corrections which is what I encourage if a more precise source is available as it would show why they might want to allocate resources into integrating a workflow with Wikidata.

I've been reaching out to each source I've proposed a property for highlighting how they might integrate a workflow to integrate and enhance their databases with Wikidata and work with the community for robust checks on values. Regarding the position held format, have you looked at Wikiproject Every Politician and the outlined data model? I strive to have at least the basic statement of just the position as it enables use of the project's standard queries (even if the start year is not added it helps to detect duplicates). Aspiring for more complete statements is what I would like to get to eventually statement 5 detail with at least additional qualifiers of replaced by (P1366),replaces (P1365),series ordinal (P1545). While the data model approach 1 suggests the position held also have a start year as the most basic style, the position alone is the most useful to start basic queries more broadly with the persons in these roles. Definitely not stepping on my toes, I like the help. Does this help with improved position held statement format? Wolfgang8741 (talk) 22:22, 10 March 2022 (UTC)

Thanks for the links! I finally found some time to look into adding position held (P39) statements to the legislator items I created, and the models you showed me were very helpful. I wound up going with the Approach 4 format, as the parliamentary term (P2937) were inferable from the Mix'n'match data set. This meant having to omit start time (P580) and end time (P582) qualifiers though, since there was no easy way to tell if these were different from when the legislative sessions began and ended. Information such as electoral district (P768) and replaces (P1365)/replaced by (P1366) were also not readily available, so these statements will definitely have to be supplemented in the future, but I'm hoping that just having the basic info for now will still be of some use.

I'm starting now on adding additional statements to the Minnesota legislator ID (P3160) items that you created recently. The Minnesota Legislators Past & Present (Q111017101) website has some really nice search features, so we'll see just how much info I can wring out of it. :)

--Quesotiotyo (talk) 22:27, 17 March 2022 (UTC)

I'm loving this teamwork, and yes incremental improvement is better than nothing. How about we move further coordinating over to Wikidata talk:WikiProject every politician/United States of America to build on this an make it more accessible for others to join? Oravrattas was the person who has been eager to look at a well defined set to explore. I've queued up Arizona and working on Virginia's House. Waiting on OpenStates to get back about integrating with Wikidata, but that is not as clean as it is from scraping of gov sites yet it is more up to date on current people. Working on other possible integration options too. These are exciting times. Wolfgang8741 (talk) 00:13, 18 March 2022 (UTC)

Sounds good. Exciting times indeed! --Quesotiotyo (talk) 01:32, 18 March 2022 (UTC)

Non-binary gender

Regarding Alana Smith (Q65018347) and their value of sex or gender (P21), I removed an inaccurate datum and replaced it with an accurate one. I'm not sure that someone's previous (incorrect) gender should continue to be listed thus (even as deprecated), but I'll bring it to the attention of other members of the Wikimedia LGBT+ User Group and see what the users who spend more time here on Wikidata think. — OwenBlacker (talk; please {{ping}} me in replies) 19:12, 6 April 2022 (UTC)

@OwenBlacker: The notion of correctness is not relevant here. Wikidata stores information made by external sources. Statements should not be removed, overwritten, or deprecated in order to reflect a particular viewpoint. --Quesotiotyo (talk) 05:07, 7 April 2022 (UTC)

logically/technically driven changes in Pharaos?

It seems as if you do not know anything about history. What did you do?

What's the point describing a Pharaoh as human? Of course he was. But none of all properties inflicted in that fact are of any interest. Of course you could state him being a lung breather and it would be correct but nonsense.
It's an anachronism to title a Pharaoh with the number of his dynasty. Dynasty numbers have been recorded not before Manetho.
Same with Saqqara king list. This list has not been written before 18th dynasty.
No historic date before 1583 is to be given in Gregorian. Don't try to discuss! You won't change this. You may use proleptic Gregorian dates for astronomy as you probably will find an agreement about this. But such an agreement is necessary and you have none and won't ever ave one for history. So stay Julian here.

You may keep your addendums but undo your changes here please!

@Vollbracht: I have not added or changed any claims on these items so I am not sure what you are raving about. The exact subject matter is not being debated here. Some of the statements that you added used the wrong property, so I moved them to the appropriate one. For all persons, instance of (P31) must be set to human (Q5); other values should not be used with that property (see Help:Modelling/Other_domains#People). Also, you removed sourced statements from more than a few items; this should not be done. If there is an issue with the existing statement then please assign it a deprecated rank along with reason for deprecated rank (P2241).

It would be appreciated if you would undo your most recent edits so that these items will be structured properly. If you are still confused about anything then we should discuss it before any further changes are made. Thank you.

--Quesotiotyo (talk) 16:21, 11 May 2022 (UTC)

Given and family names

Message received; middle names are given names. I'll try to fix these as I come across them. Thanks for the pointer, sorry for the mixup! Aluxosm (talk) 19:40, 16 May 2022 (UTC)

Notified participants of WikiProject Names. Just thought I'd let you know that I've written a query that's been really helpful in fixing these. It goes through most of the people that I've been working on (WikiProject YDIH) and lists each component of everyone's name, using the series ordinal qualifier to separate them. I've started to slowly work my way though them; the entries at the bottom should be correct (a good few of them thanks to you as well).

Author names query

Let me know if you think you could make use of it and need a hand adapting it to your needs! Aluxosm (talk) 15:07, 17 May 2022 (UTC)

Terrific, thank you so much! I work a lot on given and family name statements so this should definitely be useful. --Quesotiotyo (talk) 16:25, 17 May 2022 (UTC)

Aliases for people

Is removing aliases like this the right thing to do? I've been adding these to people who have published works using that name format. They're really useful when using Scholia's curation page. Aluxosm (talk) 19:47, 16 May 2022 (UTC)

Yes, these can be recorded using subject named as (P1810), object named as (P1932), or author name string (P2093) but they do not belong in the alias field (at least for English; some other languages do allow them). I do correct the order when I find these rather than remove them outright.

--Quesotiotyo (talk) 20:06, 16 May 2022 (UTC)

Really appreciate your help, you're right again! Looking into it, Scholia and Author Disambiguator can actually utilise object named as (P1932) and author name string (P2093) already, so there's no need to do it the way I have been. I'll try and fix these too (correcting the order as you've been doing). Cheers, Aluxosm (talk) 20:44, 16 May 2022 (UTC)

You are quite welcome. :) --Quesotiotyo (talk) 21:11, 16 May 2022 (UTC)

You are correct on Florida Markers aliases being incorrect

I noticed the issue when I started trying to match the images of the plaques, but haven't gotten around to removing the alias. If you have a moment free, I wouldn't mind the assist removing the incorrect aliases. https://www.wikidata.org/w/index.php?title=Q111453694&oldid=prev&diff=1634434519 Wolfgang8741 (talk) 14:30, 27 May 2022 (UTC)

@Wolfgang8741: Consider it done. While you're here, last night I was taking a look at the 100 Years of Alaska's Legislature (Q111431375) site to see about importing the legislator IDs and creating any new items. I know you helped get the property set up so I just want to make sure that you weren't currently working on it. If not I should be able to get all of it added by tomorrow. Just let me know, thanks!

--Quesotiotyo (talk) 20:21, 27 May 2022 (UTC)

Thanks for the assist. Please help yourself to the Alaska Legislature or other political person properties I've proposed. Attention is currently elsewhere, but I'll monitor and circle back. Wolfgang8741 (talk) 17:12, 8 June 2022 (UTC)

Sounds good, thanks. --Quesotiotyo (talk) 17:53, 8 June 2022 (UTC)

Swartz (Q111073016)

Hi Quesotiotyo!

The data set has no reference or is linked to a given name. Please prove it or I suggest it to be deleted. Best regards --HarryNº2 (talk) 12:56, 3 June 2022 (UTC)

Thank you for noticing that; I was able to find a few usages. There are still 14,697 given names (https://w.wiki/5EUi) and 112,339 family names (https://w.wiki/5EVs) that need the same treatment though. :(

--Quesotiotyo (talk) 05:01, 4 June 2022 (UTC)

A name must not be linked, it is sufficient if a source is given. --HarryNº2 (talk) 06:48, 4 June 2022 (UTC)

For example, Swartz is not a first name here > Louise Swartz Beahm Wells (Q110495592). The other family members are called Swartz with surnames, see https://de.findagrave.com/memorial/58770912/agnes-l-beahm. Even with the other linked names, it is not 100% clear whether it is a given name or part of a compound surname. Especially with American names it is not always clear whether the middle name is a given name or a surname. E.g. John L. Smith: Since the "L." can be a given name but also a surname. --HarryNº2 (talk) 07:11, 4 June 2022 (UTC)

Huh? A middle name is a given name. It may be taken from a family name but that does not make it one. For Louise Swartz Beahm Wells (Q110495592) it is clear that she was given the middle name "Swartz" after her mother's maiden name, a common tradition (just as the name "Boehm" comes from her father). Compound surnames on the other hand are almost never seen in America, and if she did have one then her father and siblings would have it as well. As for John L. Smith, a man's middle name is often abbreviated as an initial; his family name (should he have a compound one) would not be. For women the initial could represent either a middle name or maiden name; I would not add it as a statement were I not able to determine which is the case.

Oh, and the numbers I cited above were for name items that are both unused and unreferenced (at least on the P31; some do have sitelinks or identifiers which support their existence).

--Quesotiotyo (talk) 09:28, 4 June 2022 (UTC)

Are you sure that every middle name is a given name? Wikipedia seems to disagree with you. --Emu (talk) 10:46, 4 June 2022 (UTC)

Ah, now I see where the disconnect is coming from. I was referring to de:Mittelname in particular rather than de:Zwischenname. "Secondary given name" would have been a better choice of words. Sorry about the confusion.

--Quesotiotyo (talk) 19:04, 4 June 2022 (UTC)

Removal of researcher

Regarding this, I have explained the reasons in User_talk:Epìdosis#Editing_items_for_mechanical_engineering_faculty. Best, --Epìdosis 08:57, 8 June 2022 (UTC)

@Epìdosis: Perhaps it was at the time, but university teacher (Q1622272) is not currently a subclass of researcher (Q1650915) (and I'm not sure that it should be). But even if it were, being a university teacher does not preclude someone from being a researcher either in other aspects or at a separate time. I think it would be wise to add back all of the statements that were removed.

--Quesotiotyo (talk) 16:03, 8 June 2022 (UTC)

university teacher (Q1622272) is indeed of a (recursive) subclass of researcher (Q1650915) (scheme) and all the occurrences of occupation (P106)university teacher (Q1622272) I removed weren't referenced, so I don't think a massive re-addition is needed; if appropriate, it will of course be done in single cases. --Epìdosis 16:31, 8 June 2022 (UTC)

I stand corrected -- I was looking at the graph that you had linked to on your talk page which was set to three iterations of subclass instead of the necessary four. Still, I think it is fallacious to assume that a university teacher could not possibly be a different kind of researcher as well; I would expect that a person would possess some experience in conducting research prior to being hired to such a position. Also, all of the statements could be supported by inferred from publications or works (Q106677433) or by any of the various researcher identifiers. I do hope that you will reconsider.

--Quesotiotyo (talk) 17:51, 8 June 2022 (UTC)

Please do not change a label and then merge it

inferred from NIK (Q109631961) is a very different thing. Please be careful before merging it. thank you! Germartin1 (talk) 01:57, 9 June 2022 (UTC)

@Germartin1: What are you using to infer a person's residence (P551) if not an address? --Quesotiotyo (talk) 03:30, 9 June 2022 (UTC)

Using the first few numbers of their government ID which is published on the election website. Germartin1 (talk) 04:08, 9 June 2022 (UTC)

That is not an inference. Please use type of reference (P3865)personal number in Indonesia (Q19729792) instead along with the exact portion of the ID being used as object stated in reference as (P5997).

--Quesotiotyo (talk) 15:39, 9 June 2022 (UTC)

Reversion at Noguchi

Hello! I saw that you reverted my edit here. Is that because Noguchi (Q24090442) exists? So we have a Latin script item and a kanji script item? That's fine, if so, but I suppose my second question is why have both? Thanks! — Huntster (t @ c) 21:53, 9 June 2022 (UTC)

That is correct. Please see Wikidata:WikiProject_Names#Basic_principles for an explanation. --Quesotiotyo (talk) 21:56, 9 June 2022 (UTC)

Thanks for pointing me in that direction, wasn't aware of it. Didn't know either that the Cradle tool existed; that'll make creation so much easier. — Huntster (t @ c) 22:05, 9 June 2022 (UTC)

Fair warning: I've always found the Cradle tool to be rather finicky to use and when you click the button to create an item there is no indication that anything has happened and no link to the new item is provided. It is definitely useful when working in unfamiliar areas though to have a basic template to build off of rather than starting with a blank slate.

--Quesotiotyo (talk) 22:19, 9 June 2022 (UTC)

Understood. Yeah, I'm used to the 'no-response' issue through other tools, but I suppose we just have to adapt to the tools we are provided, heh. — Huntster (t @ c) 22:26, 9 June 2022 (UTC)

Mizrahi and מזרחי

I've created a new item Mizrahi (Q112585447) for מזרחי

Thanks for pointing out the WikiProject Names page. One question though: which is the correct property to link Mizrahi (Q112585447) and Mizrahi (Q37535698), said to be the same as (P460) or different from (P1889)? UWashPrincipalCataloger (talk) 22:28, 15 June 2022 (UTC)

P460 is correct. Also, when the writing system for a name item differs from that of a particular description's language, the native label should be appended to the description inside parentheses (this allows, for instance, for Michael (Q22809771): male given name (Μιχαήλ) to be readily distinguishable from Michael (Q4927524): male given name).

Thanks,

--Quesotiotyo (talk) 22:48, 15 June 2022 (UTC)

native label (P1705)

Hello Quesotiotyo,

you wrote: "in Wikidata names are considered as strings written in a particular script and apply equally to all languages which use that script...this would not be reflected in the given source, hence the removal". Where can I read that this is true in relation to names? Has this been discussed anywhere? If there is only one language in field language of work or name (P407), then it is not multilingual, see Wikidata:WikiProject Names/Properties > native label (P1705) > native label (Q45025080). For example, Hansen (Q2712367) would be multilingual, see also http://www.namenforschung.net/id/name/109/1. Best regards --HarryNº2 (talk) 01:05, 16 June 2022 (UTC)

Help:Monolingual_text_languages#Special_language_codes reads "mul: For content in multiple languages, meaning either content that is the same in more than one language, or content that contains more than one language, [...]". In the case of name items, native label (P1705) is used to signify how the name is written in a particular writing system (this is a special use case for the property, since names are transliterated but not translated and thus do not have an "official language"). When that is the same across multiple languages, we use mul rather than adding each language individually, which in the case of Latin script would result in an unwieldy number of values. This is similar to the new mul language code for labels currently being developed (see https://phabricator.wikimedia.org/T285156).

--Quesotiotyo (talk) 03:18, 16 June 2022 (UTC)

"Unknown daughter"

Hi Queso,

would you agree with me that an item like unknown daughter Dewar (Q76374919) ("Unknown daughter of") shall not exist? --Casualty Affairs Officer (talk) 21:26, 17 June 2022 (UTC)

Why, simply because the given name is not known? I don't see that mentioned at Wikidata:Notability as a reason why a person would or would not be eligible for inclusion.

--Quesotiotyo (talk) 21:39, 17 June 2022 (UTC)

Because just being somebody's relative shall not give notability. If a person is a "genealogical connector" I would make an exception, but the unknown daughter seems to be a dead end.--Casualty Affairs Officer (talk) 22:13, 17 June 2022 (UTC)

Might I suggest discussing this with the user who created the item? You are also free to list it at Wikidata:Requests_for_deletions if you feel so strongly that it should be removed.

Welcome to Wikidata, I hope you enjoy your stay! :)

--Quesotiotyo (talk) 00:17, 18 June 2022 (UTC)

Edit request

Can you add w:ja:シェドルツェ to Q319813 ? Because Q319813 is protected now.--126.254.165.255 17:12, 28 June 2022 (UTC)

Done. --Quesotiotyo (talk) 17:18, 28 June 2022 (UTC)

"oo" and "ou" and "u"

Hi

Both "oo" and "ou" and "u" are correct forms of writing in English for Persian words. Like "Forouhar" and "Kourosh Yaghmaei" or (Kourosh Yaghmaee) and "Hushang Ebtehaj". They all represent "او" in Persian. So, all forms should be added.

Cheers Shkuru Afshar (talk) 23:20, 28 June 2022 (UTC)

When the native label (P1705) of a name item is in a non-Latin script, varying transliterations can be added as English aliases; otherwise, any alternate spellings need to have their own items. See Wikidata:WikiProject_Names#Basic_principles for more information.

--Quesotiotyo (talk) 01:29, 29 June 2022 (UTC)

Your reverts

Hello! Could you please explain what was not correct in your opinion in these elements: Q81176980 Q85995453 and others? Renvoy (talk) 11:08, 29 June 2022 (UTC)

The names of those individuals are written in Cyrillic and so the values used for given name (P735) and family name (P734) should be Cyrillic as well. Thank you for helping to correct those items.

--Quesotiotyo (talk) 14:12, 29 June 2022 (UTC)

Could you link to the policy you are basing this on, please? --Base (talk) 15:27, 29 June 2022 (UTC)

I'm not sure what you are expecting in terms of a formal policy (of which Wikidata has very few). This is a well-established practice, to assign only the value(s) to those properties which correspond to an individual's name in native language (P1559). Adding additional values for various writing systems is not necessary because those transliterations are already given in the item labels.

--Quesotiotyo (talk) 16:44, 29 June 2022 (UTC)

Watercourse coordinates

Thanks for semi-correcting the coordinates for Seventeen Mile River (Q65043151). Per Wikidata:WikiProject_Rivers#How to use, the coordinates for a watercourse are the mouth and source. Bamyers99 (talk) 22:23, 29 July 2022 (UTC)

Those would work better as qualifiers on mouth of the watercourse (P403) and origin of the watercourse (P885) statements. The values for coordinate location (P625) should ideally be a centrally located point.

--Quesotiotyo (talk) 20:45, 30 July 2022 (UTC)

Sorry, I was ignorant of the other way of specifying the source and mouth. I have updated Seventeen Mile River (Q65043151) with your suggestion. Thanks. --Bamyers99 (talk) 13:36, 31 July 2022 (UTC)