Wikidata:Project chat

Latest comment: 9 hours ago by GualdimG in topic Good practice on labels

Wikidata project chat
A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

For realtime chat rooms about Wikidata, see Wikidata:IRC.
On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/07.

Railway junctions: Q24045957 vs Q336764


I'd be grateful if anyone could help me distinguish railway node (Q24045957) and railway junction (Q336764) -- both used specifically for railway junctions, and distinct from railroad switch (Q82818) and the more general junction (Q1777515).

There seem to be two different concepts here, at least in German, but I'm not entirely seeing how they should be named in English to express the difference, or whether articles in the various different language wikis are all connected to the correct item.

Which would be most appropriate for a location where one linear ELR railway line section (Q113990375) of track (perhaps 50 km long, double-track) meets another such section? Jheald (talk) 22:10, 2 July 2024 (UTC)Reply

Multichill (talk) Thryduulf (talk) 21:38, 2 November 2013 (UTC) -revi (talkcontribslogs)-- 01:13, 3 November 2013 (UTC) (was Hym411) User:JarrahTree (talk) 06:32, 3 November 2013 (UTC) A.Bernhard (talk) 08:28, 9 November 2013 (UTC) Micru (talk) 12:36, 9 November 2013 (UTC) Steenth (talk) YLSS (talk) 13:59, 25 November 2013 (UTC) Konggaru (talk) 12:31, 14 December 2013 (UTC) Elmarbu (talk) 21:48, 17 December 2013 (UTC) Nitrolinken (talk) 16:30, 14 February 2014 (UTC) George23820 Talk‎ 17:39, 17 August 2014 (UTC) Daniele.Brundu (talk) 21:34, 30 August 2015 (UTC) Dannebrog Spy (talk) 16:13, 9 December 2015 (UTC) Knoxhale 18:39, 26 June 2016 (UTC) happy5214 22:48, 8 July 2016 (UTC) Jklamo (talk) 07:32, 15 August 2016 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits DarTar (talk) 16:36, 5 September 2016 (UTC) Pizza1016 (talk | contribs) 01:33, 10 November 2016 (UTC) Sascha GPD (talk) 23:00, 1 February 2017 (UTC) Liuxinyu970226 (talk) 09:09, 2 February 2017 (UTC) A1AA1A (talk) 18:17, 21 May 2017 (UTC) Mauricio V. Genta (talk) 13:56, 9 June 2017 (UTC) Sam Wilson 10:26, 18 June 2017 (UTC) Danielt998 (talk) 05:01, 28 August 2017 (UTC) Maxim75 (talk) 06:04, 22 September 2017 (UTC) Fabio Bettani (talk) 17:48, 3 June 2018 (UTC) Geogast (talk) 23:51, 13 July 2018 (UTC) Bodhisattwa (talk) 19:29, 17 December 2018 (UTC) Jinoytommanjaly (talk) 13:13, 21 May 2019 (UTC) OktaRama2010 (talk) 00:25, 1 May 2020 (UTC) PhiH (talk) 14:20, 26 July 2020 (UTC) Jcornelius (talk) 18:47, 30 July 2020 (UTC) Mackensen (talk) 15:21, 29 August 2020 (UTC) Michgrig (talk) 22:04, 20 December 2020 (UTC) Trockennasenaffe (talk) 16:27, 5 September 2021 (UTC) Secretlondon (talk) 07:46, 3 September 2022 (UTC) GALAXYライナー (talk) 05:17, 14 October 2022 (UTC) Yirba (talk) 09:49, 10 August 2023 (UTC) Zwantzig (talk) 09:08, 07 September 2023 (UTC) S4b1nuz ᴇ.656(SMS) 16:16, 21 November 2023 (UTC) Prefuture (talk) 07:02, 16 December 2023 (UTC) Cmelak770 (talk) 14:06, 15 May 2024 (UTC) DaxServer (talk) 14:41, 31 May 2024 (UTC)Reply
  Notified participants of WikiProject Railways. (I did ask on the talk page there a couple of years ago, but it didn't get any responses.) Jheald (talk) 22:14, 2 July 2024 (UTC)
I can explain these from the Czech point of view, but the explanation is similar for all countries in the central Europe (Poland, Germany, Slovakia etc.). At thirst railway node (Q24045957) is very big (hundreds of switches) and railway junction (Q336764) is very small (sometimes only one switch, but usually not more than four switches). railway node (Q24045957) express connection of lot of railway lines usually in one town/city. E.g. železniční uzel Praha (Prague junction) consists of all railway station in Prague (Q1085), in which all railway lines leading to this big city are connected. railway junction (Q336764) is usually a place where one railway line splits into two railway lines and it is not railway station (Q55488), so if the railway lines are with one track, then one switch can be enough. In Czechia and Poland it is also a place on the double track line between two stations, where are 4 switches to go from the left to the right track and vice versa (the same place is Slovakia (till 2000 also in Czechia) is classified as passing loop (Q784159)). But I have no idea how to name these different places in English. When I translate it, I usually use "junction" for both, although they have completely different meanings. --Cmelak770 (talk) 06:54, 3 July 2024 (UTC)Reply
In Germany we strongly distinguish between free track (Q1302250) which roughly means track which is not part of a railway station (Q55488) and tracks that are part of a railway station (Q55488). railway junction (Q336764) is a junction, that is not part of a railway station (Q55488). As far as I know, (most?) english speaking countries don't have this concept free track (Q1302250), so this may not be easy to translate. --Trockennasenaffe (talk) 06:09, 4 July 2024 (UTC)Reply
Asked at en:Wikipedia_talk:WikiProject_UK_Railways whether anyone there can suggest better English-language labels / descriptions Jheald (talk) 12:56, 7 July 2024 (UTC) Reply
@Cmelak770, Trockennasenaffe: After some input from en-wiki and ChatGPT, I have updated the label/description for Q24045957 to "railway node" = "significant location in the railway network which may encompass multiple connected lines, stations, and facilities, often a major transit hub".
I also considered "rail hub" or "railway hub", which I think better captures the sense of the articles for Q24045957 in cs-wiki and ru-wiki, and of items like Prague rail hub (Q12046953) and Brno railway hub (Q20860267); however the concept described in the de-wiki, nl-wiki, and it-wiki articles seems not necessarily to be on such a large scale.
railway junction (Q336764) would then be for specific locations of track divergence, usually not in stations.
This could probably still be improved or refined, but it may be a start at least. Jheald (talk) 20:01, 9 July 2024 (UTC)Reply
Thanks, I think the English description is quite correct now. Cmelak770 (talk) 13:00, 10 July 2024 (UTC)Reply

Ingest of SEC EDGAR data into Wikidata?


I have recently noticed that many company infoboxes on Wikipedia are frequently out of date, even though they draw from Wikidata for many values like yearly results. All of this data is available online through the SEC's EDGAR system, at least for publicly traded companies in the US, so I was wondering whether it would be worthwhile to write a bot that would read SEC data and update Wikidata with it?

Botlord (talk) 19:18, 3 July 2024 (UTC)Reply

@BotlordYes, that would be nice and useful for a lot of infoboxes on various wikis. I think it would definitely be possible to do the mapping using XBRL. Feel free to discuss any kind of details at Wikidata talk:WikiProject Companies. Jklamo (talk) 08:08, 9 July 2024 (UTC)Reply

Conventions for Knowledge Graph aligning


Dear Wikidata Community,

We're looking to build a Aerospace Engineering Knowledge Graph, and linking (all) entries to wikidata. For some, like Q3319996, that's easy, for others like conceptual modelling not so much. Others, like CPACS, are not even in Wikidata yet, or Wikipedia for that matter. Given that context, I have the following cases and questions:

  1. If a perfect match exists, no questions.
  2. If a match exists that does look correct, but seems to be lacking relations, should we populate this entry as we see fit? (assumed answer: yes, see en:WP:BOLD)
  3. If a match exists that does look somewhat corect, but does not have the right type, should we split it into two different entities?
    1. e.g. Q377960 not being a Q3249551, but an Q166142 - should we create a new process instance with the same label?
    2. what about instances such as Q2623243, which specifically lists conceptual model (an object) and conceptual modelling (a process)? Does the existence of this entry mean differentiation is not desired?
  4. If no match exists, I assume we should create one. I've taken a look at Wikidata:Notability:
    1. "It refers to an instance of a clearly identifiable conceptual or material entity that can be described using serious and publicly available references."
      1. All instances would fall under this category, since all are derived from a systematic literature review and we can link to the respective papers where they are discussed.
    2. All our instances would be instances of Q10843872, Q7397, Q235557 or similar. Examples:,

Furthermore, I have some SPARQL / Database questions, which I'll add to a separate topic to not overflow this one.

Thanks, TimBorgNetzWerk (talk) 11:00, 4 July 2024 (UTC)Reply

2. --> yes, be warry of the distinction between instance of (P31) and subclass of (P279). Make sure that the relations you add respect the transitivity rule.
3. Probably hard to give a general answer, it's likely a case-by-case basis. For the examples you gave
- product data management (Q377960) is a bit of a weird case because after a quick skim it appears that the linked wikipedia pages themselves don't have the same type: the English seems to talk about a process (Q3249551) while the French one seems to be talking about software? If you decide to split the two, perhaps the wiki pages should be re-linked as well.
- On conceptual model (Q2623243) I don't know the original author's intent here, but will point out that the corresponding edit seems to have been partially automated, so there is a chance that mistakes slipped through. The same author added "Conceptual models" as an alias, which is spurious on the sole basis that it shouldn't be capitalized. In any case, I think it makes sense to create an entry for "conceptual modeling", with appropriate cross-links such as facet of (P1269).
Overall, it's possible that there were no curators with a deep expertise and a good overall view of this part of the graph, hence possible inconsistencies. Improvements welcome!
4. I would say yes, especially if you link the references.
Lastly I am not sure if your Aerospace Engineering Knowledge Graph will be publicly available, but if it is perhaps you could create an identifiers to link to it? Although I must say I'm not sure what is the process to create a new identifier, nor what the criterion are to propose a new one. Alcinos (talk) 10:50, 9 July 2024 (UTC)Reply

Very widely used property no longer works


See Property talk:P5380#No longer works BhamBoi (talk) 22:25, 4 July 2024 (UTC)Reply

This is National Academy of Sciences member ID (P5380). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:02, 11 July 2024 (UTC)Reply

constraint on instance or subclass of


ISFDB award ID (P11395) has constraint

subject type constraint:
class - type of award 
relation - instance or subclass of

So why is Ditmar Award (Q906455) which is a subclass of (P279) of science fiction award (Q107581015), an instance of (P31) of type of award (Q107467117) OK

While William Atheling Jr. Award (Q8004646) which is an instance of (P31) of literary award (Q378427), an instance of (P31) of type of award (Q107467117) reports a violation? Vicarage (talk) 14:07, 7 July 2024 (UTC)Reply

Because William Atheling Jr. Award (Q8004646) is currently neither an instance nor a subclass of type of award (Q107467117) (instance of (P31) is not transitive and neither literary award (Q378427) nor Ditmar Award (Q906455) are subclasses of type of award (Q107467117)) while Ditmar Award (Q906455) is a direct instance of type of award (Q107467117). It seems to me that the subject type of ISFDB award ID (P11395) should be instance or subclass of science fiction award (Q107581015), not type of award (Q107467117). - Valentina.Anitnelav (talk) 09:00, 8 July 2024 (UTC)Reply
Ah, I was expecting instance of (P31) to be transitive in this check. Changing ISFDB award ID (P11395) as you suggest solves my problem. Thanks. Vicarage (talk) 09:12, 8 July 2024 (UTC)Reply

Removing unreferenced religions and ethnicities


@Nikkimaria: Was a decision made to remove all unreferenced religions and ethnicities at some point? If so I missed that discussion. If the decision was made they should be deleted by a bot, not one-by-one by any individual. Doing it that way will lead to selection bias. I noticed some disappearing and traced the deletions to Special:Contributions/Nikkimaria RAN (talk) 16:21, 7 July 2024 (UTC)Reply

These are mostly reverts of a particular problematic IP editor who pops up periodically in Special:AbuseFilter/95. If there is a preference to revert such edits by bot I have no objection. Nikkimaria (talk) 16:37, 7 July 2024 (UTC)Reply
For ethinicities, removal was approved for unreferenced statements and deprecation for Wikipedia-referenced statements, see Wikidata:Bot_requests/Archive/2021/10#request_to_depreciated_ethnic_group_only_sourced_with_P143_(2021-10-23). At the time I think it was also notified or discussed on Project chat. Vojtěch Dostál (talk) 07:38, 8 July 2024 (UTC)Reply

Voting to ratify the Wikimedia Movement Charter is ending soon

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello everyone,

This is a kind reminder that the voting period to ratify the Wikimedia Movement Charter will be closed on July 9, 2024, at 23:59 UTC.

If you have not voted yet, please vote on SecurePoll.

On behalf of the Charter Electoral Commission,

RamzyM (WMF) 03:45, 8 July 2024 (UTC)Reply

Is there something like a Wikidata WP:DOB?


Specifically Q5364577, which seems to be ultimately sourced to imdb. Gråbergs Gråa Sång (talk) 06:43, 8 July 2024 (UTC)Reply

Yes - see Wikidata:BLP. ArthurPSmith (talk) 17:35, 8 July 2024 (UTC)Reply
Thankfully, Wikidata can structure these claims better than a textually-based Wikipedia project can.
For example, references can be attached directly to the DOB claim; these will unambiguously support that particular claim, and no others.
Also, multiple claims can be attached to one person's bio. Therefore if there is dispute, ambiguity, or competing claims for a DOB, all can be included!
Deprecation and preference values can be assigned. Therefore, if a DOB claim is found to be incorrect or invalid, it can be deprecated, colored red, and notations can be made about those reasons. Likewise, if a DOB is found to be valid above the others, it can be marked "preferred".
In this way we can better document any controversy, weak/strong sourcing issues, or disputes, not only about a date of birth but about any germane fact for a Wikidata item. It's a shame that enwiki still doesn't want to play nice and draw from Wikidata's growing pool of structured data such as this, because it's way easier to document and track such disputes here in one centralised location, than in parallel, on dozens or hundreds of language-specific wikis, with mazes of twisty little policies and guidelines, all different. Elizium23 (talk) 18:36, 8 July 2024 (UTC)Reply

Wikidata weekly summary #635


Showcase items discussion


Editors are invited to join the discussion at Wikidata talk:Showcase items § Formalizing the process. Sdkbtalk 19:31, 8 July 2024 (UTC)Reply

Good practice on labels


(pinging @Tm. continuing discussion from User talk:Tm#Edits on stores for Lojas com História. no harm to them.)

to the Wikidata community, I want to ask about Help:Label and what is the good practice in this situation. some Wikidata items, in this case buildings, are labeled simply as their street address with a prefix. take for example, Prédio na Rua Joaquim António de Aguiar, 45 (Q98962545) (literally, "building on Rua Joaquim António de Aguiar, 45") or Q90315021 (literally, "Loja Confeitaria Nacional, ground floor, including integrated movable heritage"). this is taken straight from the sourced external databases.

according to Help:Label: Labels begin with a lowercase letter except for when uppercase is normally required or expected [...] proper nouns such as the names of specific people, specific places, specific buildings, specific books, etc., should be capitalized. my question is, would this be counted as a proper name? the building itself has no name and these are simply descriptions of the given place. so then how would it be labeled? JnpoJuwan (talk) 00:13, 9 July 2024 (UTC)Reply

These are proper names, as i said to you. They have their proper name by the portuguese cultural heritage, the former DGPC. If you had taken a few minutes you would see that, no ad hoc translation made with any sourced translated name is made, these are proper names named so in legislation and\or portuguese cultural heritage databases kept by the portugues estate organizations that have in their remit said cultural heritage. You said that :Prédio na Rua Joaquim António de Aguiar, 45 that "the building itself has no name and these are simply descriptions of the given place" yet you have the main DGPC database, other database of DGPC with the same name.
And Loja Confeitaria Nacional, piso térreo, incluindo o património móvel integrado] is the listed part of the shop Confeitaria Nacional, as the shop is not all listed cultural heritage in its totality. Again the name is the proper name, as stated in main DGPC database and legislation listing it, from Anúncio n.º 174/2017, going with Anúncio n.º 38/2020 and ending in Portaria n.º 613/2020. Tm (talk) 00:28, 9 July 2024 (UTC)Reply
And these names are completly used in Wikidata, just as an example Iron Foundry (building Number 1/140) Iron Foundry (building Number 1/140) Including Railings And Bollards or Vulcan Block (Building Number 21) And Attached Bollards or Number 15 And Attached Agricultural Building or Factory Building Outbuilding Attached To Number 55 or Castle Farm Cottages Number 5 And Farm Building Attached, british listed cultural heritage monuments, among of hundreds silimars. Tm (talk) 00:48, 9 July 2024 (UTC)Reply
I am also asking to a wider community to determine whether it is a good thing to continue doing as such. JnpoJuwan (talk) 00:50, 9 July 2024 (UTC)Reply
Any search for listed buildings will show you that this is a common and long established pratice. Tm (talk) 01:07, 9 July 2024 (UTC)Reply
Like, as an example of an US building New York Herald Building or the listed building in U.S. National Register of Historic Places Building at 73 Mansion Street and this last building uses same the name in its articles in english Wikipedia and german Wikipedia Tm (talk) 01:35, 9 July 2024 (UTC)Reply
The labels for British buildings comes from their source as being imported from a heritage register. We ensure that the listing property has subject named as (P1810) to preserve this, but I fully expect that we might change the name to a more colloquial form on WD, as we should not be bound by a listing officer's conventions on defining a site's scope, and it makes little sense to create 2 items merely to have them with and without their bollards. There are many examples of things where their official name is different from the common name. We should record both in the body of the entry, but the label, for use by humans scanning the site and report summaries, should be the colloquial version. I'd also expect foreign language labels to adjust for their own formatting conventions (moving the street number to the start in English for example), but without actually translating names literally.
"The Vulcan Building" is a good example, and I'd expect other Portsmouth historic buildings to be changed too in time Vicarage (talk) 06:10, 9 July 2024 (UTC)Reply
I have seen the descriptions given in these items, that I do not doubt. what I ask is: what is considered a proper name here, as the same databases list many other designations for the same item besides that, or for SIPA, do not list the original.
even if these are the legally recognised names, is it useful to list these names first as opposed to descriptive and importantly translatable names? JnpoJuwan (talk) 00:48, 9 July 2024 (UTC)Reply
This are monuments are named so in legislation and the databases of the portuguese Património Cultural, IP (former DGPC), so these are proper names. The pratice in Wikidata is not not make ad hoc translation without proper sources that state that there is a commons translated name and you have the example of the british listed cultural heritage monuments to see what these are proper names and they are capitalized in Wikidata.
These are designations are other proper names to the same items, from the databases of portuguese Património Cultural, IP (former DGPC) from the main DGPC database (and legislation) for cultural heritage monuments. For complement, there are other databases from Património Cultural, IP (former DGPC) like the SIPA database and, for specific cases, other databases of works of specific routes or arquitects like the as the one linked as "other database of DGPC" and or archeological sites database. Tm (talk) 01:04, 9 July 2024 (UTC)Reply
I think a good rule of thumb here is "how would this label work in the middle of a sentence?" Would one write "This is a photo of Prédio na Rua Joaquim António de Aguiar, 45" or "This is a photo of prédio na Rua Joaquim António de Aguiar, 45"? Maybe in English the answer would be one way and in another language it would be different; I know for example in French lower-case is very common for what in English would be upper-cased. In any case I think this general rule should work across most languages. ArthurPSmith (talk) 15:43, 9 July 2024 (UTC)Reply
for this case, it is would certainly be lowercased as "prédio" is not a proper noun, it is just the word for building and describing the given address, for that reason I suggest using an informal approach for these items. JnpoJuwan (talk) 21:50, 9 July 2024 (UTC)Reply
In this case this is certainly uppercase as this is a proper name of this building, as stated in two different sources databases of portuguese Património Cultural, IP (former DGPC) , that talk and describe specifically this building. in one source is clearly stated "Designação:Prédio na Rua Joaquim António de Aguiar, 45" or "Name\designation:Prédio na Rua Joaquim António de Aguiar, the same as other source. These is a name with not one but two sources. Tm (talk) 01:34, 10 July 2024 (UTC)Reply
Also im portuguese one capitalizes the proper names of buildings as stated in Ciberdúvidas da Língua Portuguesa "A maiúscula é obrigatória apenas para os nomes próprios (dos edifícios, das vias, dos bairros, das localidades...)." or in english "Capital letters are mandatory only for proper nouns (of buildings, roads, neighborhoods, towns...)". Tm (talk) 01:44, 10 July 2024 (UTC)Reply
Another page on Ciberdúvidas da Língua Portuguesa states that "Como geralmente é expressão referente a um edifício histórico importante, escreve-se com maiúsculas iniciais" or in english "As it is generally an expression referring to an important historical building, it is written with initial capital letters". This also applies to this building as is also an important historical building, as is described, with this same capitalized name, in three different databases of the Património Cultural, IP (former DGPC), the department of the portuguese Ministry of Culture responsible for the listing of the portuguese immovable cultural heritage, besides another database of the portuguese Ministry of Culture, so showing that this is a clear important historical building. Tm (talk) 02:00, 10 July 2024 (UTC)Reply
And, if any there is any doubt the Portuguese Language Orthographic Agreement of 1990 as "SÍNTESE DO USO DA MAIÚSCULA INICIAL E DA MINÚSCULA INICIAL [I A letra inicial maiúscula é utilizada: (...) 11.º Na letra inicial de palavras usadas em categorizações de logradouros públicos, de templos e de edifícios: Bairro de Alvalade; Rossio; a Alta de Lisboa; (...) Rua Augusta; Rua da Palma; Pátio do Tijolo; Basílica da Estrela; Capelas Imperfeitas; Convento dos Capuchos; Igreja de Santa Maria Maior; Igreja do Bonfim; Templo do Apostolado Positivista; Mosteiro de Santa Maria(...); Edifício Azevedo Cunha. or in english ""SUMMARY OF THE USE OF INITIAL CAPITAL AND INITIAL LOWERCASE The initial capital letter is used: (...) 11th In the initial letter of words used in categorizations of public places, temples and buildings" Tm (talk) 02:17, 10 July 2024 (UTC)Reply
all in all, I will respect Tm's decision and keep the labels as is, as they have made good arguments in regards to this. I am so sorry if this was a headache for you. --JnpoJuwan (talk) 10:47, 10 July 2024 (UTC)Reply
It's a complex question and it partially depends on the language. I'm not sure for Portuguese but in French, proper names often start with a lowercase. For English, I would like a confirmation (ping ArthurPSmith) but cases like building at 73 Mansion Street (Q1003019) should probably be begin with a lowercase too (like in the Wikipedia article). Cheers, VIGNERON (talk) 12:53, 10 July 2024 (UTC)Reply
Yes, given that the associated enwiki article starts "The building at 73 Mansion Street [...]" the wikidata entry should be labeled "building at 73 Mansion Street" in English. I've fixed it. ArthurPSmith (talk) 12:39, 11 July 2024 (UTC)Reply
pinging Portuguese users @DiogoBaptista, @GoEThe to see this. JnpoJuwan (talk) 12:48, 12 July 2024 (UTC)Reply
I am Portuguese, and quite familiar with that documentation, constantly working with it for almost 20 years. Thinks like "building in street x" are mere descriptions for effects of listing of the heritage, and not official names of anything. They are just a way that allows some identification (often not even that precise) of the listing. They are not intended to be used as official names, nor should be used as such. As for the SIPA database, it's a expert sourced mixed with crowdsourced repository with many mistakes, some of them egregious. Can be used with care, but definitely is not a source of official names, being even worst on that subject than the documentation itself. In any case, those are mere descriptions, and they are not necessarily, by any stretch of imagination, intended as official names. Darwin Ahoy! 15:04, 13 July 2024 (UTC)Reply
Como referiste e bem há erros graves de nomes na SIPA e até na DGPM, pelo que não são fontes totalmente confiáveis especialmente em matéria de nomes, caso que me parece grave e que está a gerar conflito é o do Bairro das Estacas ou Bairro de habitações económicas de São João de Deus e não de São José situação que eu corrigi e que foi revertida sem qualquer justificação pelo utilizador @Tm. Fontes que suportam essa denominação. DiogoBaptista (talk) 16:18, 13 July 2024 (UTC)Reply
JnpoJuwan (talk) 16:39, 13 July 2024 (UTC)Reply
Ping @GualdimG Darwin Ahoy! 15:06, 13 July 2024 (UTC)Reply
Não sei quem anda a copiar os nomes todos da antiga DGPC inclusive fazendo-o ignorando paginas e categorias wikidata e wikicommons que ja existiam duplicando assim paginas sobre o mesmo assunto.
É um absurdo o nome da Confeiteria Nacional ser “Loja Confeitaria Nacional, piso térreo e primeiro andar, incluindo o património móvel integrado” ou o Banco de Angola e Metrópole ser "Edifício do Banco de Fomento Nacional na Rua da Conceição, n.º 134-136" este ultimo caso duplicou paginas ignorando a já existente. Ainda um pior, o edificio Almirante Reis, 2 a 2-K foi denominado de "Prédio situado no gaveto formado pela Avenida do Almirante Reis, 2 a 2-K, e Largo do Intendente Pina Manique, 1 a 6"
A DGPC não tem qualquer poder em alterar os nomes comuns ou oficiais dos lugares, esses nomes são técnicos e meramente da DGPC para fins de classificação patrimonial e não tem qualquer correspondência com a realidade ou com o nome oficial de certo lugar. Em certos casos esse nome da DGPC agrupa vários objectos num só não sendo possível assim a distinção de cada um de forma individual. Aliás, penso até que o nome das paginas da wikidepia deve prevalecer a denominação mais comum e popular havendo espaço reservado para outros nomes (wikidata por exemplo) ou redirecionamentos. DiogoBaptista (talk) 16:08, 13 July 2024 (UTC)Reply
JnpoJuwan (talk) 16:26, 13 July 2024 (UTC)Reply

Do buildings (properties, in general) have a "proper name" (official designation) in Portugal? Yes, they do. This first name is what is registered at the Land Registry Office (Conservatória do Registo Predial) to which corresponds a Land Registry (Caderneta Predial) (like people, who are registered in the Identification File (Arquivo de Identificação) and who have a Citizen Card). The buildings are also registered with "Finance" (Taxes Department), where they have a matrix registration number (people also have a tax identification number). Then, the buildings have other designations, some official, others more common. In Portugal, there are buildings (castles, palaces, manor houses, churches, chapels, etc.) that are subject to cultural heritage classification and by that obtain another official designation by law (laws, decrees, ordinances, etc.). This official designation is reflected in two state databases (which overlap) which we can call one DGPC and the other SIPA (there are other unofficial databases such as /patrimonio/ e-cultura, for example). The DGPC database uses the official designation of the classification process more specifically, while SIPA is not as strict regarding the use of the legal designation. It is interesting to note that, for the example already given of Confeitaria Nacional in Lisbon, the DGPC indicates "Loja Confeitaria Nacional, piso térreo e primeiro andar, incluindo o património móvel integrado" while SIPA indicates "Edifício na Praça da Figueira, n.º 18/ Edifício da Confeitaria Nacional". It should be noted that the object of classification was only the ground floor and the first floor, which is expressed in the DGPC db, while in the SIPA db both designations point to the entire building, being certain that the ground floor and the 1st floor are obviously part of the set.

Then the problem arises of distinguishing the property itself from the use/user given to it. In this case they still coincide, and Confeitaria Nacional can indicate both the property and the use given to it. Since in Wikidata there are two elements (and well), one for the property (Q90315021), and another for the user (Q2992412), although in this case it is wrong to say that the user is "part of" a property, when the correct thing would be that has "headquarters" in that property. But, for me, the Wikidata element referring to the property (Q90315021) could just have the designation "Confeitaria Nacional", for the sake of simplicity (and without risk of confusion), as long as it should had a correct "Description", which could be "building in Lisbon where Confeitaria Nacional is located, ground floor and first floor, including the integrated movable assets".

In summary. The rule that has been followed should continue to be applied, that the designation Wikidata/Commons is the legal designation whenever it exists, that is, the designation of the legal instrument that classifies the property (or the classification process that has not been completed), and should be simplified whenever possible and without the possibility of error, as in the case mentioned, in which the Wikidata elements Q90315021 and Q2992412 could both have the same first name, "Confeitaria Nacional", the first for the building and the second for the user (confectionery).GualdimG (talk) 10:23, 14 July 2024 (UTC)Reply

The Community Wishlist is reopening July 15, 2024


Here’s what to expect, and how to prepare.

Hello everyone, the new Community Wishlist (formerly Community Wishlist Survey) opens on 15 July for piloting. I will jump straight into an FAQ to help with some questions you may have:

Q: How long do I have to submit wishes?

A: As part of the changes, Wishlist will remain open. There is no deadline for wish submission.

Q: What is this ‘Focus Area’ thing?

A: The Foundation will identify patterns with wishes that share a collective problem and group them into areas known as ‘Focus Areas’. The grouping of wishes will begin in August 2024.

Q: At what point do we vote? Are we even still voting?

A: Contributors are encouraged to discuss and vote on Focus Areas to highlight the areas.

Q: How will this new system move wishes forward for addressing?

A: The Foundation, affiliates, and volunteer developers can adopt Focus Areas. The Wikimedia Foundation is committed to integrating Focus Areas into our Annual Planning for 2025-26.

Focus Areas align to hypotheses (specific projects, typically taking up to one quarter) and/or Key Results (broader projects taking up to one year).

Q: How do I submit a wish? Has anything changed about submissions?

A: Yes there are some changes. Please have a look at the guide.

I hope the FAQ helped. You can read more about the launch.

You are encouraged to start drafting your wishes at your pace. Please consult the guide as you do so. Also if you have an earlier unfulfilled wish that you want to re-submit, we are happy to assist you draft.

You can start your draft (see an example) and don't hesitate to ask for support when drafting, please notify me via the Drafts List.

–– STei (WMF) (talk) 13:01, 9 July 2024 (UTC)Reply

U4C Special Election - Call for Candidates

You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello all,

A special election has been called to fill additional vacancies on the U4C. The call for candidates phase is open from now through July 19, 2024.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. Community members are invited to submit their applications in the special election for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

In this special election, according to chapter 2 of the U4C charter, there are 9 seats available on the U4C: four community-at-large seats and five regional seats to ensure the U4C represents the diversity of the movement. No more than two members of the U4C can be elected from the same home wiki. Therefore, candidates must not have English Wikipedia, German Wikipedia, or Italian Wikipedia as their home wiki.

Read more and submit your application on Meta-wiki.

In cooperation with the U4C,

-- Keegan (WMF) (talk) 00:02, 10 July 2024 (UTC)Reply

HDS ID (P902) having value-requires-statement constraint (Q21510864) with GND ID (P227)


I'm new to Wikidata specific practices, sorry if I screw anything up or asked in the wrong place. I don't think HDS should require a GND ID, considering there are many topics with an HDS article that do not have a GND ID. For example, Journal du Jura (Q633032). Unless I am horrifically misunderstanding something. PARAKANYAA (talk) 05:40, 10 July 2024 (UTC)Reply

I agree, I have removed; too many topics don't have GND ID (P227), so having this constraint isn't worthwhile. Epìdosis 08:36, 10 July 2024 (UTC)Reply
@Epìdosis Thank you very much :) PARAKANYAA (talk) 08:53, 10 July 2024 (UTC)Reply

Spelling convention for labels and descriptions in English: Request for comment


Hello everyone, just a heads up that a new Request for comment has been created to discuss a standard approach for labelling in Wikidata. If you're interested, please take a look and share your thoughts. Carbonaro. (talk) 08:48, 10 July 2024 (UTC)Reply

Proposed Changes to personal pronoun (P6553)




Wikidata: WikiProject Personal Pronouns has set out to clean up Wikidata’s modeling and implementation of personal pronoun data. This data is currently inconsistent, difficult to query, and frequently inaccurate. What follows is our detailed proposal to remedy this situation, which we hope to implement on July 24, 2024.


  • Messy data modeling and false statements:
    • Personal pronouns are modeled as individual lemmas, as pronoun set items, and as items representing individual pronouns
    • Values exist which are not third person pronouns at all, but things like honorifics
  • Individual pronouns as lexemes don’t account for cases where a principal pronoun isn’t enough to go on to identify a pronoun set (for instance, “ze/zir” vs. “ze/hir”). Therefore, lexemes cannot be consistently implemented with accuracy
  • Inferring gender identity based on personal pronouns, and vice versa, is inaccurate and causes disproportionate harm to marginalized groups

Proposed Changes


Use Cases


The following use cases support the need for the proposed data structure. Many more can be provided.

Implementation Plan


Scope of Use


5,945 items in Wikidata use P6553 (as of 2024-05-29 using this query) ~60 items have more than one statement/value pair for P6553, so there are a total of 6,005 statements using P6553 (as of 2024-05-29 using this query)

5,920 of these pronoun statements have values that are actually pronouns rather than honorifics, etc. (as of 2024-05-29 using this query)

2,296 of these statements have a value of “he” (as of 2024-05-29 using this query), 2,595 have a value of “she” (as of 2024-05-29 using this query), and 701 have a value of “they” (as of 2024-05-29 using this query) leaving 328 statements with other values

All valid P6553 statements have values from a small group of 63 lemmas (as of 2024-05-29 using this query) from sixteen languages (as of 2024-05-29 using this query)

Language-Lemma count chart:

Language-Lemma Count breakdown:
Bokmål/Nynorsk = 4
Catalan = 3
Dutch = 5
English = 14
Esperanto = 8
French = 4
German = 7
Japanese = 4
Latin = 1
Portuguese = 3
Spanish = 5
Swedish = 3
Yiddish = 1
Yoruba = 1



Data Model


Building Pronoun Sets


Data Cleanup


Rodriguez.UW (talk) 21:50, 10 July 2024 (UTC)Reply

  Strong support I fully support these changes and am committed to participating in their implementation. --Crystal Yragui, University of Washington Libraries (talk) 23:25, 10 July 2024 (UTC)Reply
This is a great idea, I fully support it. Brimwats (talk) 01:25, 11 July 2024 (UTC)Reply
@Clements.UWLib, are you now changing other people's comments to include {{Strong support}} templates? I recommend that you revert your modifications, and cease that activity, which is imposing your own interpretations on someone else's contextual words. @Brimwats and the others can speak for themselves, whether their support/opposition is full/strong/weak/whatever, okay? Elizium23 (talk) 20:39, 11 July 2024 (UTC)Reply
@Brimwats hi, trying to make it clearer how many supports/opposes we have. Would you make it clear (if you choose)? --Crystal Yragui, University of Washington Libraries (talk) 21:00, 11 July 2024 (UTC)Reply
Forgot to add:   Strong support Brimwats (talk) 21:38, 11 July 2024 (UTC)Reply
  Oppose while its a thread on this page. It needs to be a RFC, and the proposers need to address the concerns raised here when posting one. Vicarage (talk) 21:51, 11 July 2024 (UTC)Reply
I also support this project and will be ale to assist in implementing the proposal. Mferpc (talk) 21:52, 12 July 2024 (UTC)Reply
This seems like a bad idea. Pronouns are lexicographical data and should exist as lexemes. If the lexeme data is inconsistent, it can and should be improved. Items are not inherently more consistent than lexemes, and creating new entities instead of fixing the existing ones won't make the data better - it will actually result in duplication of data, which then leads to problems with data getting out of sync.
It's completely possible to have multiple lexemes with the same subject form and different object forms (e.g. sier (L304659) vs sier (L304660)). If your objection is that the links don't display the object form, that is a data display issue, not a problem with the data itself.
Lexemes have forms with grammatical features, allowing machines to select the correct form in different sentences (e.g. "I see them" versus "They see me"). You haven't explained how that will work with your proposal.
I don't think it makes sense to remove all mentions of gender. Whether you like it or not, people do associate pronouns with gender and there is a lot of correlation between someone's gender identity and the gender of the pronouns they use. Removing links to other properties and aliases for terms that people do use makes things harder to find, and makes it more likely that they will do things like add sex or gender (P21) based on pronouns, because they are more likely to be unaware that we even have a separate property for pronouns.
The existence of languages which don't have gendered pronouns does not seem relevant. If a language doesn't have multiple pronouns for the same grammatical person/number, then I don't see how personal pronoun (P6553) would be useful. If you know of another distinction used for pronouns referring to other people, other than gender and formality, I would love to know about it (and it would be relevant to Wikidata:Lexicographical data in general).
I don't think unsourced statements for a property should be mass removed before making an effort to add sources. Creating lists of statements with issues and encouraging people to help fix the issues would be a perfect task for a wikiproject.
- Nikki (talk) 04:31, 11 July 2024 (UTC)Reply
Also pinging @BlaueBlüte who already responded to your proposal on Wikidata talk:WikiProject Personal Pronouns back in May. - Nikki (talk) 04:38, 11 July 2024 (UTC)Reply
Thanks for pointing out that we missed this question. I just answered it (late). The reason why we want to change this property datatype from Lexeme to Item is in order to facilitate personal pronoun sets that use pronouns from different lexemes. For example, "they/xe" in the use case of Dua Saleh. Lexemes cannot represent this pronoun set, but a Wikidata item can. It can also point to the appropriate (distinct) lexemes as parts. --Crystal Yragui, University of Washington Libraries (talk) 00:37, 12 July 2024 (UTC)Reply
@Nikki Lexemes could be linked from pronoun set items as parts, but as we stated in this proposal, individual lexemes are not enough to go on much of the time to identify pronoun sets. We gave examples and fully explained why lexemes are not appropriate or sufficient for personal pronoun sets. These examples aren't different senses of the same word, but often distinct words in different senses. Lexemes would still exist, but would not be used as values for this particular property. Rather, they would be parts of sets. Which is how people use them. --Crystal Yragui, University of Washington Libraries (talk) 19:52, 11 July 2024 (UTC)Reply
You have not clearly demonstrated why lexemes are not appropriate or sufficient though. It is possible to link to multiple lexemes. It is possible to use qualifiers such as object form (P5548) if it's really necessary. If you don't know how to model something in Wikidata, it would be a better idea to ask us how it can be modelled, before deciding it's not possible and the entire model needs to be changed.
Dua Saleh (Q84766127) already has links to lexemes for they and xe, Mel Baggs (Q4080459) already has links to lexemes for sie/hir and ze/zer. Conchita Wurst (Q113581) could link to he (L485) and she (L484) with qualifiers (I'm not sure which property would fit best off the top of my head, but we can create more properties if necessary).
You should explain how machines are going to be able to use the data with your model. Projects such as Abstract Wikipedia need to be able to select the right pronouns for someone, which means saying things like "they" is the subject form and "them" is the object form in a machine-readable way.
- Nikki (talk) 08:20, 13 July 2024 (UTC)Reply
  Support I support the goals of this project. Wikidata editors should not be supplying sex or gender (P21) based on a person's pronouns. And sex or gender (P21) should not be used to supply personal pronoun (P6553) without references that document a person's choice of their pronouns. The more that can be done to prevent misgendering people in Wikidata, the better. AdamSeattle (talk) 06:11, 11 July 2024 (UTC)Reply
Hey Adam, for the sake of clearly seeing who supports and opposes, an oppose/support would be useful in your comment. --Crystal Yragui, University of Washington Libraries (talk) 21:00, 11 July 2024 (UTC)Reply
Discussions on Project Chat (or any other project pages) aren't decided by counting "votes". Instead we try to reach consensus. Pestering people into using a voting template isn't the best look. William Graham (talk) 21:16, 11 July 2024 (UTC)Reply
Thanks. Are there guidelines for consensus on contentious topics where everyone does not agree on the best course of action that you can point me to? This has always been a murky area of Wikidata governance for me, and envisioning what "consensus" looks like in a conversation where you have two camps who do not and probably won't see eye to eye is really difficult. Any help would be greatly appreciated. --Crystal Yragui, University of Washington Libraries (talk) 23:27, 11 July 2024 (UTC)Reply
  Strong oppose I don't understand why "Change data type from Lexeme to Wikidata Item", it would be a lot of work for no gain (I would even say it would be a loss, as the data would be poorer). Cheers, VIGNERON (talk) 11:59, 11 July 2024 (UTC)Reply
The gain would be solving the problem we point out here: "Individual pronouns as lexemes don’t account for cases where a principal pronoun isn’t enough to go on to identify a pronoun set (for instance, “ze/zir” vs. “ze/hir”). Therefore, lexemes cannot be consistently implemented with accuracy". It would not be very much work, and we laid out a very detailed implementation plan for doing the work. --Crystal Yragui, University of Washington Libraries (talk) 19:37, 11 July 2024 (UTC)Reply
Presumably the Items would link to Lexemes, which brings the benefit of rich-data quality.
But, as Crystal described, the issue here is that, while he (L485) then provides him (L485-F2), but an Item can more easily make visually clear the distinction between ze (L304664) (which uses zer (L304664-F2)) and ze (L1230597) (which uses hir (L1230597-F2)).
The Item would then, presumably, have a label of "ze/hir" and Properties aligning with
and so on.
This doesn't feel like there'd be any data-quality loss here, merely adding an extra — more detailed — layer between the property on a biography Item and the Lexeme entries OwenBlacker (talk; please {{ping}} me in replies) 13:10, 12 July 2024 (UTC)Reply
@Clements.UWLib: I'm sorry but I still don't understand. Could you point to one item where there is problem with the current model? « It would not be very much work » you seem over-optismistic, creating a property is at least a month, deleting a property can take years (and all the mess in between of having two competing properties), plus you'll need to create thousands of items (for what: just to replicate data we already have on Lexemes?), that really seems like a lot of works. @OwenBlacker: I'm even more confused. Maybe there is a problem with the current lexemes, their content and how their used but I don't see the problem with the model itself. Cheers, VIGNERON (talk) 08:18, 13 July 2024 (UTC)Reply
(1) this should be an RFC, not an announcement on (English) Project Chat
(2) In principle I think the item datatype may make sense here, but I don't understand how you would label or make consistent across languages. That needs to be discussed: would a person with "ze/zer" in English have a consistent label in every other language, or might different people make different choices in other languages? If consistent translations are expected then an item seems fine, otherwise I think this needs to stick with lexeme datatype.
(3) Technically I don't believe the datatype can be just "replaced" - a new property would need to be created for the new datatype, and data migrated etc. As User:VIGNERON notes this would be considerable work fixing the ~6000 statements.
ArthurPSmith (talk) 12:48, 11 July 2024 (UTC)Reply
We just asked in the Administrators' noticeboard about the process for requesting changes to properties, and you were one of the people who gave us feedback saying this was a good way to go and gave us further suggestions for how to go about this properly. I am confused about why you are now saying it should be done differently @ArthurPSmith. Is it because you don't agree with the proposed changes? --Crystal Yragui, University of Washington Libraries (talk) 19:40, 11 July 2024 (UTC)Reply
@Clements.UWLib, only two people replied to you in that discussion. @Ymblanter and @ArthurPSmith. It is not clear whether they were aware of the massive scope and depth of your intended proposal (because you were asking about a generality and not linking to specifics.) You implied that you wanted to change a single property or something. Indeed, the scope of your proposal appeared quite trivial there, compared to the overhaul you're actually hatching in this proposal. Elizium23 (talk) 19:45, 11 July 2024 (UTC)Reply
@Clements.UWLib: To be clear, I wasn't trying to imply that you shouldn't have posted this in Project Chat; I'm glad you did. But the scope of the change is more than we would normally handle this way. Particularly as it most likely will heavily involve data concerning living people, and the lexeme-related aspect implies significant cross-language synchronization which I don't see covered here yet. And technically because it requires creating a new property, not just changing an existing one. ArthurPSmith (talk) 20:26, 11 July 2024 (UTC)Reply
How and where does one post an RFC? And how does this proposal require creating a new property? --Crystal Yragui, University of Washington Libraries (talk) 20:28, 11 July 2024 (UTC)Reply
To create an RFC, follow the instructions on the "Requests for comment" link at the top of this page. The data type change from Lexeme to Item value means it can't just be altered, a new property is needed. ArthurPSmith (talk) 20:32, 11 July 2024 (UTC)Reply
Oh, I didn't realize that data type changes weren't possible. So, is what we are suggesting in fact the cancellation of one property in favor of a new one? How does that work? Thank you for the feedback. Crystal Yragui, University of Washington Libraries (talk) 23:22, 11 July 2024 (UTC)Reply
@Clements.UWLib: When you have a consensus on the change (ideally determined by an admin or other non-involved person closing the RFC with an assessment in favor of the change) then a property proposal for the new property should be straightforward, and the property can usually be created in a week or so. Then migration of the old values to the new values (to the extent that is wanted). And then a proposal for deletion of the old property would be needed, on the Properties for Deletion page. ArthurPSmith (talk) 00:37, 13 July 2024 (UTC)Reply
We do want to change a single property. This doesn't have massive scope or depth beyond the single property we're talking about and the cleanup work we and our project partners would complete. The data is already a messy mix of items and lemmas I don't understand why this is being perceived as some sort of overhaul. This would be a cleanup and implementation of a coherent data model in place of no coherent data model. --Crystal Yragui, University of Washington Libraries (talk) 19:55, 11 July 2024 (UTC)Reply
It's also worth mentioning that a fair amount of the cleanup work could be automated. It's not especially complex and ~6000 records for cleanup frankly isn't a huge amount. — OwenBlacker (talk; please {{ping}} me in replies) 13:17, 12 July 2024 (UTC)Reply
+1 on VIGNERON's and Arthur's points. Most importantly, let's not discuss it here. A dedicated RfC or conversation at the property's discussion page will be better suited for a proposal like this. Vojtěch Dostál (talk) 12:58, 11 July 2024 (UTC)Reply
Conversation has been ongoing on the property's discussion page for quite some time, and we believe reflects consensus on the proposed changes. We brought it here because we thought the broader community should have input before we moved ahead with the changes. --Crystal Yragui, University of Washington Libraries (talk) 20:10, 11 July 2024 (UTC)Reply
  Info AFAICT, the recent conversation on Property talk:P6553 has consistently been about whether personal pronoun (P6553) should ever be added to historical bio items (such as George Washington (Q23)) based solely on socially ascribed sex-or-gender, as opposed to self-usage by the item's subject (as might be readily ascertained even for some historical people, e.g. by referencing the subject's own writings). For what it's worth, I agree that adding P6553 claims based solely on such inferences would be quite inappropriate, disrespectful and, in a way, even silly. Inferences in the reverse direction are a different story however: there seems to be a de-facto consensus that recording even inferred sex-or-gender data about especially obscure historical people, such may only be known from their contributions to academic research or creative works, may in fact be valuable, since it can enhance our understanding of structural biases that may still be very relevant in the present day. --Hupaleju (talk) 18:01, 12 July 2024 (UTC)Reply
  Leaning oppose Inferring sex or gender from gender-specific pronouns or styles (i.e. the "Mr."/"Mstr." vs. "Mrs."/"Miss" or whatever) comes up all the time when dealing with obscure historical people, including e.g. people involved in research or contributors to creative works. The gold standard will always be self-identification of preferred gender of course, but realistically that's going to be exceedingly rare for pre-20th century humans, and still somewhat uncommon even afterwards. I'm all for explicitly disclaiming this practice wrt. Wikidata:Living people where concerns about both individual privacy and harmful misrepresentation of marginalized gender-non-conforming groups will be rather more relevant; but recording sex-or-gender inferences about people in history is widely seen as useful for, e.g. extracting gender representation statistics wrt. Wikidata itself or subsets thereof. --Hupaleju (talk) 18:14, 11 July 2024 (UTC)Reply
The problem with this that we see is that people's gender identities, past and present, do not always align with the gender identities others attach to personal pronoun sets. This leads to misgendering, and the erasure of gender identities outside the "male/female" binary in the way it's been applied in Wikidata. This misgendering disproportionately affects people who fall outside the gender binary. For living people, that can be dangerous. For historical people, it's disrespectful. We're not asking for historical data not to be recorded. Just for binary gender information not to be assumed based on a person's personal pronouns. Extracting gender representation statistics is important, but shouldn't they include gender non-binary folks? Shouldn't they be accurate? These inferences create biased, inaccurate data that skews towards erasure of gender identities outside the gender binary. That matters a lot, even for people no longer living. --Crystal Yragui, University of Washington Libraries (talk) Crystal Yragui, University of Washington Libraries (talk) 23:18, 11 July 2024 (UTC)Reply
  Oppose Per the reasoning above, please convert this from an announcement into an RFC for debate and discussion. I am concerned with data loss or loss of precision in moving from lexemes to items. I concur with the fact that inferred sex happens routinely from historical documents. I am also concerned with the proliferation of en:Neopronouns and their associated burden of maintenance. The English Wikipedia tends not to indulge these neopronouns in article prose. Is it Wikidata's intent to catalog, document, and apply neopronouns in a completely credulous fashion? It is a fact that neopronouns can and will be used to troll and disrupt communications. It would be inadvisable for us to take them always at face value. Lastly, I am concerned about the size and scope of these changes. This is a large proposal, and difficult for us to digest as a monolith. Perhaps itemize it, prioritize elements of it, and propose options/choices within each major decision. A proper RFC should have a central and identifiable proposal for debate, and not a lot of moving parts! Elizium23 (talk) 19:40, 11 July 2024 (UTC)Reply
Yes, of course it is advisable to take people's pronouns at face value. This is not what we came here to debate, and it's not up for debate in this community as far as I know. This is not a moving part. We suggested five bullet-pointed changes to a single property. The rest is supporting information. Your comments about neopronouns make it difficult for me to think you are engaging with this proposal in good faith. --Crystal Yragui, University of Washington Libraries (talk) 20:05, 11 July 2024 (UTC)Reply
I don't agree with the whole aspect about trolling and disrupting. Wikidata is a database that still takes references from journalism/academia. I assume we will be adding neopronouns that have been recorded in such capacity, and not anything bad faith coming out of the "My pronouns are your/mom" type disruptive usage. Anything sincere and well-recorded does deserve to be on Wikidata. Egezort (talk) 07:05, 12 July 2024 (UTC)Reply
  Support per nomination. I've also updated the wording above to reflect the broad support that has previously been discussed with the Wikimedia LGBT+ User Group. — OwenBlacker (talk; please {{ping}} me in replies)
  Strong support As AdamSeattle says above, sex and gender should not be linked to or inferred from pronouns. I support this project and am happy to help implement. --Emwille (talk) 14:24, 12 July 2024 (UTC)Reply
Alright folks, I'm becoming a bit concerned about the appearance of consensus here, while we're still at the level of an informal discussion/proposal.
It has come to light that several of the editors commenting here are personally affiliated with the University of Washington, and/or Crystal Yragui (@Clements.UWLib).
While these affiliations and coordination may be perfectly permissible under Wikidata policies and guidelines, it would be helpful if all editors would clearly and plainly state their affiliations, and any conflicts of interest which may arise from them.
It would not be good to establish a false consensus on the basis of support by a network of interrelated editors, while discounting the opinions of disinterested and editors who are independent and unaffiliated with UW and one another.
Yragui has already informed me that the comments which they modified belong to editors who they know personally. If y'all are so personally involved that you're putting words in one another's mouths, then you're too close to express separate opinions on any such topic. Thank you. Elizium23 (talk) 22:11, 12 July 2024 (UTC)Reply
  Strong support I think this is really important, and the proposed changes look good to me. I'm especially supportive of providing references to support both gender and pronouns, as others have said one does not neccessarily imply the other, either in contmeporary society, or with increasing understanding of how historical figures configured their genders. A more nuanced model, which this provides, is neccessary to better represent humanity Lajmmoore (talk) 12:28, 13 July 2024 (UTC)Reply
  Strong oppose
on formal grounds (needs more careful and more multilingual consideration than it can be given in the (exclusively-English-language!) Project Chat; needlessly ties together at most tangentially related changes),
on methodological/pragmatic grounds (lacks discussion of how sources state pronouns (e.g., what does “they/xe” mean?); of the needs of query authors, data re-users, WP-infobox-template authors, etc.), and
on data-modeling/semantic grounds (supposed rationale for proposed data-type change has already been refuted multiple times; fails to take into account modeling of pronouns in languages other than English; and there may well be reasons to state a relationship between personal pronoun (P6553) and sex or gender (P21) of some sort (to be discussed) rather than removing it altogether).
Please break up this proposal into separate issues so far as they can usefully be discussed separately (e.g., (a) how to model a pronoun, (b) statements relating personal pronoun (P6553) to other sex-or-gender-related/-correlated properties, (c) data cleanup (which, incidentally, I   Conditional support), (d) …) and initiate a multilingual discussion of these issues—put to use the non-English language competencies among WikiProject Personal Pronouns participants and try to recruit additional non-English (native) speakers. ―BlaueBlüte (talk) 18:55, 13 July 2024 (UTC); amended 19:40, 13 July 2024 (UTC)Reply

Suggestion for Wikidata property to identify online accounts


i did already create this before posting (whoops) because i am still kind of new (i can't figure out how/if i could delete it,double whoops, sorry!) basically i've noted several authors who have "official" archive of our own (AO3) accounts and I feel we should be able to note this, so now archive of our own username exists, and i would like to actively use it. Honeybeeandtea (talk) 01:52, 11 July 2024 (UTC)Reply

by "official" i mean linked to on their official websites, but aren't offical in the sense that their publishers are involved Honeybeeandtea (talk) 01:53, 11 July 2024 (UTC)Reply
You have rather jumped the gun. You should use Archive of Our Own tag (P8419) with qualifiers, and ask for your item Archive of Our Own (AO3) Username (Q127358232) to be deleted. Vicarage (talk) 03:32, 11 July 2024 (UTC)Reply
i don't disagree with you on the fact that i jumped the gun, but in the case of AO3, tags have a specific purpose that is separate from that of a username. using the the "ao3 tag" and then amending it to "but actually i mean the username" feels like an ineloquent and roundabout way to express a relationship as linear as "this is that person's username" Honeybeeandtea (talk) 15:55, 11 July 2024 (UTC)Reply
There's currently no dedicated property for AO3 accounts. You can use website account on (P553) instead (see the property examples on that page for how to use it). Additionally, you could propose a new property specifically for AO3 accounts (see Wikidata:Property proposal) - but those are usually only succesfull if there's a significant number of potential items for persons with such accounts. --2A02:810B:580:11D4:D5AC:53B7:B54E:983E 19:14, 11 July 2024 (UTC)Reply
I tend to use described by source (P1343) with URL and other qualifiers for non-property relations to external sites. Vicarage (talk) 19:48, 11 July 2024 (UTC)Reply
I'd say described by source (P1343) is more for webpages that are about the thing/concept (and preferably actually contain some in-depth information). While accounts/user profiles are IMO better suited for website account on (P553), since that's the whole purpose of the property. Using more specific properties makes it much easier to evaluate the exact nature and potential use of the linked pages. --2A02:810B:580:11D4:9156:3944:B752:5BF9 12:38, 12 July 2024 (UTC)Reply
Good point, but I'm surprised how unused it is, only 25 records for British authors, and 2500 for all humans. Vicarage (talk) 12:52, 12 July 2024 (UTC)Reply
maybe it's a sign we have good coverage over must sites people have accounts on BrokenSegue (talk) 23:11, 12 July 2024 (UTC)Reply

not sure what transcluded means in new property proposal


I have tried to propose a new property Wikidata:Property proposal/ artist id but somehow messed it up. it says "You have not transcluded your proposal on Wikidata:Property proposal/Person yet. Please do it." but I'm not sure what this means, and it's not obvious what to do when clicking the "Please do it" link Please could someone help me Thanks. QWER9875 (talk) 16:24, 11 July 2024 (UTC)Reply

This was the desired action. --Matěj Suchánek (talk) 13:58, 12 July 2024 (UTC)Reply

set confirm user


i contribute in wp/fa with 1300 edits. in wiki data i cant change semi protected pages, so im gonna ask you for give me this level. thank you میسانو (talk) 00:41, 13 July 2024 (UTC)Reply

  Done Infrastruktur (talk) 14:14, 13 July 2024 (UTC)Reply
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Infrastruktur (talk) 14:14, 13 July 2024 (UTC)Reply
no problem. first i didn't know where i can issue that میسانو (talk) 14:20, 13 July 2024 (UTC)Reply

Q3281534 ("modern history") has a misleading name


I tried to find instructions on how to request renaming of an item but couldn't find anything, so I'm posting here.

The object in question is incorrectly named. As a historical period, the term is "modern period" or "modern era". Calling it "modern history" would be like naming Q12554 "medieval history" or Q9903 "Ming history".

The term "modern period" or "modern era" are the standard terms among English-language academic sources. Peter Isotalo (talk) 01:30, 13 July 2024 (UTC)Reply

I don't disagree, but please don't leave the en-gb label with the old name, just delete it Vicarage (talk) 12:36, 13 July 2024 (UTC)Reply
I thought it strange when I tried to add "Modern History" as an academic major (P812) to an item earlier today and it wasn't appearing in the search. I've re-added "modern history" as an alias as this item is used for the academic discipline (Q11862829) and is the widely used term: See also for example, and Piecesofuk (talk) 14:00, 13 July 2024 (UTC)Reply
@Vicarage, I'm not really that handy with Wikidata. To change the name of something, do I just edit the label?
@Piecesofuk, I'm not sure I understand the logic here. Is a historical period the same as the discipline studying that historical period? Isn't that like saying that "gender studies" has to be an alias of "gender"?
Note that the English Wikipedia article has never been located at "modern history". It's just a redirect. Peter Isotalo (talk) 16:46, 13 July 2024 (UTC)Reply
Yes, I agree, it probably should be split into two. But at the moment there are hundreds of items that link to modern period (Q3281534) assuming it's an academic discipline (Q11862829). English Wikipedia is using "modern history" as an alias, for example see in and the link in the sentence "In 1901, Attlee went up to University College, Oxford, reading modern history." Unless someone creates a new item for the academic discipline and moves all the linking items then I think the "modern history" alias should remain. Piecesofuk (talk) 17:08, 13 July 2024 (UTC)Reply
Yes, just edit the label section and make the en-gb line blank. I think it needs to be split, like early modern history is.
SELECT DISTINCT ?item WHERE {?item wdt:P69 ?place;p:P69 [ pq:P812 wd:Q3281534].}
Try it!
Shows 44 the people for which is was an academic major. Vicarage (talk) 17:52, 13 July 2024 (UTC)Reply
Okay, thanks for the clarifications. I see the logic in keeping the alias. I'm trying to work to improve the coverage of this and adjacent topics over at English Wikipedia. I think that needs to be dealt with before sorting things out here.
But very good pointers for the future. Thanks! Peter Isotalo (talk) 21:48, 13 July 2024 (UTC)Reply
One thing, you made the change before allowing people to comment here. Its always tempting to leap ahead, but you need to allow people to comment on a proposed change, rather than persuade you to revert it. Vicarage (talk) 21:52, 13 July 2024 (UTC)Reply

Wikidata qualifier (Q15720608)


By the time of now, this label is `Mahfuja`, but the evidences are this was `Wikidata qualifier`, that you and I knew well. Is this a joke or something? JuguangXiao (talk) 13:40, 13 July 2024 (UTC)Reply

The item had been vandalised. Peter James (talk) 14:05, 13 July 2024 (UTC)Reply
Yet another valuable IP contribution. Darwin Ahoy! 14:52, 13 July 2024 (UTC)Reply