Wikidata:Project chat

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

(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é https://www.wikidata.org/wiki/Q25418835 situação que eu corrigi e que foi revertida sem qualquer justificação pelo utilizador @Tm. Fontes que suportam essa denominação. https://dre.tretas.org/dre/4454194/anuncio-51-2021-de-17-de-marco https://amensagem.pt/2021/07/12/a-vida-entre-estacas-alvalade/ https://www.publico.pt/2021/03/17/local/noticia/bairro-estacas-alvalade-vias-classificacao-1954810 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

what is your opinion on labeling other items such as Trees of Public Interest? these all are named like Q98444561, which is less than useful. in the history, you can see how I did it.

• label: <tree species> in <place>
• description: Tree of Public Interest in <place>, <city>

none of these are really proper names but one is more descriptive. JnpoJuwan (talk) 15:22, 15 July 2024 (UTC)Reply

another option is adding info from their sources, such as numbers. this states that the tree above is "Árvore Classificada de Interesse Público D.R. 2.ªsérie – N. º169 de 03/09/2018". the label could perhaps include that for distinction and descriptiveness. JnpoJuwan (talk) 15:31, 15 July 2024 (UTC)Reply

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.

• personal pronoun (P6553) is:
  
  • instance of (P31):
    
    • Wikidata property for items about people (Q18608871)
      
    • Wikidata property related to LGBT (Q63870987)
      
  • Wikidata item of this property (P1629): personal pronoun set (Q65067284)
    
  • Data type: lexeme (Q111352)
    
  • related property (P1659): sex or gender (P21)
    
  • living people protection class (P8274)
    
    • property likely to be challenged (Q44597997)
      
    • property that may violate privacy (Q44601380)
      
  • citation-needed constraint (Q54554025): not mandatory
    
  • allowed-entity-types constraint (Q52004125): Wikibase item (Q29934200)
    
• The Property talk:P6553 has brought important points to light and we believe reflects consensus on the following proposed changes
  

• 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
  • Including “gender” in pronoun property leads to inferring gender based on pronouns
  • Wikidata includes heuristic (Q201413) (“problem-solving method that is sufficient for quick, short-term solutions/approximations”) related to personal pronoun (P6553) which expressly encourage inferring gender based on personal pronouns or other unrelated data points: inferred from pronoun used (Q73168402) and inferred from given name, image and pronoun used (Q123757526)
  • The idea that personal pronouns are associated with gender identity is not consistently true (see gender neutrality in genderless languages)
  • There is not consensus that gender can be inferred from personal pronouns

• Change data type from Lexeme to Wikidata Item
• Change allowed value type to instance of (P31) personal pronoun set (Q65067284)
• Remove relationship with sex or gender (P21)
• Remove references to gender in aliases and descriptions of property, because the concepts are not related (gender and pronouns need not agree)
• Delete heuristics inferred from pronoun used (Q73168402) and inferred from given name, image and pronoun used (Q123757526)

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

• Dua Saleh (Q84766127) they/xe; see Oct 2020 Tweet
• Mel Baggs (Q4080459) – sie/hir, ze/zer
• Conchita Wurst (Q113581) – she/her (in drag) he/him (out of drag)

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

• Initial working hours with the Wikidata:WikiProject_LD4_Wikidata_Affinity_Group are planned for July and September 2024
• This proposal has previously been discussed with the Wikimedia LGBT+ User Group and has their broad support
• This would be a project of Wikidata: WikiProject Personal Pronouns

• Make changes to Wikidata Property subclass of (P279) (proposed above)
• Delete heuristics inferred from pronoun used (Q73168402) inferred from given name, image and pronoun used (Q123757526)

• Create Wikidata items for personal pronoun sets based on well-modeled metadata in source datasets:
  • Homosaurus
  • GSSO
  • Ensure that all pronouns which are used as values of personal pronoun (P6553) are covered
• Use resources to describe and accurately identify pronoun sets:
  • Other Wikis, such as Pronoun Wiki, Nonbinary Wiki, Nonbinary Database, Gender Wiki
  • Pronoun generators, which include examples of use, such as Pronoun Island, Pronouns.page, and Pronouny.

• Export all personal pronoun (P6553) statements from Wikidata into OpenRefine
• Divide into several spreadsheets based on the type of issues encountered
• Remove statements without references
• Remove invalid statements, replacing with other properties as feasible (for example, when a value is an honorific, replace with honorific prefix (P511))
• For referenced statements:
  • Change value from lexeme or item for a single pronoun to a personal pronoun set based on references given
  • Add on focus list of Wikimedia project (P5008): WikiProject Personal Pronouns (Q118382780) to track activity

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

Thanks for this feedback. We do need to learn more about lexemes; BlaueBlüte has been generous with their knowledge and explained that they are more flexible than we previously understood them to be. We truly did not know that distinct declension patterns for the same word could be reflected in different lemmas, or that a lemma could include a declension pattern sourced from multiple words. This information was really encouraging to learn and would have been useful to know, but we just didn't know it. When you say to "ask us" how something should be modelled, whom do you mean, @User:Nikki? I have questions all the time about how things are or ought to be modeled in Wikidata. Often questions in Telegram go unanswered or get buried quickly, and I don't see data modeling questions on the email listserv. It would be great to know where to ask. --Crystal Yragui, University of Washington Libraries (talk) 00:03, 17 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

• nominative case (Q131105): ze (L1230597)
• oblique case (Q1233197): hir (L1230597-F2)
• possessive pronoun (Q1502460): hirs (L1230597-F3)

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

•   Strong oppose Formally, we have "Requests for comment" for proposals like this. Making such a long proposal on the project chat is bad given archiving. Changing a datatype as proposed is not something that's possible in the Wikidata UI. While we have done String->External ID conversions before, those are easier given that both are essentially strings. It would need some manual editing of the database done by WMDE which is against previous WMDE policy. We make promises about data stability and switching datatypes in this way violates them. If there's a desire to change the datatype, proposing a new property with the item datatype and deleting the one with the lexeme datatype would be the straightforward way to go.

While I agree that adding values based on the heuristics is undesirable, I don't think simply deleting all existing values is a straightforward way to solve the problem on a permanent basis. Adding citation-needed constraint (Q54554025) and then deleting values that are based on heuristics and not citations seems to me like a better solution.

It's unclear to me what the proposal even means with "relationship with sex or gender (P21)". related property (P1659) does seem fitting to me. ChristianKl ❪✉❫ 22:59, 14 July 2024 (UTC)Reply

I can confirm that changing the datatype of the existing property is not going to happen. I’m not sure if changing the content of existing revisions in the database is merely extremely difficult or completely impossible, but it’s certainly not feasible at the scale that would be needed for this proposal (changing heaven knows how many historical revisions of thousands of items). If the proposal is otherwise sound, the correct way to effectively “change the datatype” is to create a new replacement property, migrate all the data to it using normal edits, and then eventually deleting the old property once it’s no longer used, as Christian said. Lucas Werkmeister (WMDE) (talk) 15:28, 15 July 2024 (UTC)Reply

  Support Big support for the goal of decoupling pronouns from sex and gender (P21) in heuristics. We already have best practices for racial and ethnic group data (see P172) that reject an editor's inference as insufficient proof of ethnic identity, and I don't see why we shouldn't model this standard of proof with gender properties. Marcae16 (talk) 15:31, 16 July 2024 (UTC)Reply

  Comment I'm not sure why there has been a reluctance here to create an RFC; perhaps it's in the works. I would note that "changes to a single property" are indeed a frequent reason for RFC's, when that property is widely used or has other implications. Current open RFC's include at least five that are primarily concerned with just 1-3 properties (either existing or proposed). ArthurPSmith (talk) 19:00, 16 July 2024 (UTC)Reply

Hi @ArthurPSmith! An RFC will be in the works soon, since many have called for one and we've got a lot to talk about. We're just taking a beat to read the feedback we've gotten and pivot. We took a lot of time and care putting this proposal together, and re-working it into a new RFC is taking a minute too. It will take into account the concerns folks have expressed about data modeling, some of which may change our approach. When an RFC is created I will make sure we link to it from here and from the property discussion page.

Is there a policy/policies surrounding RFCs and changes to existing properties we should be aware of at this point? There seems to be some knowledge about the "way things are done" that we have not been privy to, and I'd love to be able to constructively discuss possible changes and ways forward while respecting community norms and expectations. When we posted this proposal to the project chat, we were sure that this was "the way". I've been editing in Wikidata for a few years now but I don't have any experience with this sort of decisionmaking/debate in Wikidata outside of discussing new property proposals others have made. Thank you for answering questions and providing guidance, both here and on the admin noticeboard. --Crystal Yragui, University of Washington Libraries (talk) 00:37, 17 July 2024 (UTC)Reply

I'd like to chime in again, since there's been a dearth of comments or replies to the concerns I raised upthread about personal affiliations and consensus.

You keep saying "we" as if you're running a shared account, or more than one account, or you represent more than one person when you post from your account. While that's not prohibited at Wikidata, it'd be helpful for you to disclose the identity of "we".

Following on from that, it's apparent that other commenters/supporters in this thread are directly affiliated with you, or collaborating with you in a way that's not apparent to all of us. So when people come on here to support your ideas, these are not independently-formed opinions, and that's a problematic way to represent consensus, IMHO, I don't know about other Wikidata editors, but personally, I'd prefer to know who's been canvassed, who's connected, and who's truly independent and offering an unbiased opinion.

So going forward I hope that an RFC can be conducted in a transparent and just manner. It's also important to really break it down and simplify it into components that we can all easily digest and consider, rather than this monolithic thing. It seems that many people who came here to support you wholeheartedly didn't even notice or heed expert comments that components of the proposal were unworkable/technically impossible from the outset. Elizium23 (talk) 00:44, 17 July 2024 (UTC)Reply

I mean WikiProject Personal Pronouns, which was openly stated in the introduction as the source of this proposal. I'm openly listed on that page as a participant in the project. When I say "we" here, I mean the participants in that project, and I wasn't speaking for anyone else who expressed support outside of that WikiProject which collectively raised this proposal. I'm one person running a single account trying to improve Wikidata in good faith. Your tone reads as hostile, and I am concerned that it may drive away people with relevant expertise on this subject matter who may want to contribute to a RFC once we've had some time to breathe and put one together. --Crystal Yragui, University of Washington Libraries (talk) 18:09, 17 July 2024 (UTC)Reply

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

I have tried to propose a new property Wikidata:Property proposal/africanmusiclibrary.org 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

thank you! QWER9875 (talk) 12:50, 16 July 2024 (UTC)Reply

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: https://www.st-andrews.ac.uk/subjects/history/modern-history-ma/ https://www.lincoln.ac.uk/course/modhstub/ https://courses.aber.ac.uk/postgraduate/modern-history-masters/ See also for example, https://en.wikipedia.org/wiki/Modern_History and https://simple.wikipedia.org/wiki/Modern_history 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 https://en.wikipedia.org/wiki/Clement_Attlee 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

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

There has been an influx of links using described at URL (P973) to add links to tekstowo.pl (Q126379084) such as this example. This looks like link spam, since the web address is a Web Portal, and not a database. --EncycloPetey (talk) 02:32, 15 July 2024 (UTC)Reply

This issue has been raised in the past at https://www.wikidata.org/wiki/User_talk:Reinheitsgebot#Please_stop, but is still continuing. They're very low-value links, often with nothing but low-quality user-submitted photos (if even that), and certainly should not be included using described at URL (P973). — Huntster (t @ c) 02:51, 15 July 2024 (UTC)Reply

How about we just add the URL to the blacklist? Trade (talk) 21:22, 15 July 2024 (UTC)Reply

Yes, that might be the better solution. Not sure what the process for that is here. — Huntster (t @ c) 22:12, 15 July 2024 (UTC)Reply

Not if it's just the bot, which can be blocked if it continues (and if there are additions by other users of Mix'n'match, the data can be deleted there). Peter James (talk) 00:09, 16 July 2024 (UTC)Reply

Could you please add the URL to the blacklist @Lymantria:--Trade (talk) 17:21, 16 July 2024 (UTC)Reply

  Done --Lymantria (talk) 20:07, 16 July 2024 (UTC) P.S. Requests can be made at MediaWiki talk:Spam-blacklist.Reply

Addition of the links had already stopped. The blacklist entry is likely to only have one effect - to make it impossible to revert an old version after vandalism or other incorrect edits. Peter James (talk) 20:29, 16 July 2024 (UTC)Reply

Check that, indeed too many false positives. I've removed it from the spam blacklist again. --Lymantria (talk) 05:55, 17 July 2024 (UTC)Reply

There are still many instances added round that date, including [1], [2], and [3]. The ones I've found are all the result of mix-n-match, but none are from the same batch. --EncycloPetey (talk) 06:01, 17 July 2024 (UTC)Reply

I'm working on The New Zealand Annual Review of Education (Q96737379) and would link to add links to the three kinds of RSS feed provided and the OAI-PMH feed. How do I do this? I can see the RSS (Q45432) Atom (Q267956) and Open Archives Initiative Protocol for Metadata Harvesting (Q2430433) but not associated properties. Stuartyeates (talk) 08:28, 15 July 2024 (UTC)Reply

There is web feed URL (P1019), which I believe is what you want. —Justin (koavf)❤T☮C☺M☯ 08:40, 15 July 2024 (UTC)Reply

Thank you, User:Koavf, that was the answer I was looking for. Stuartyeates (talk) 07:53, 16 July 2024 (UTC)Reply

Genuinely amazing when I get something correct. Glad I could help, Stuart. —Justin (koavf)❤T☮C☺M☯ 08:51, 16 July 2024 (UTC)Reply

A 94.176.18.80 02:21, 16 July 2024 (UTC)Reply

Greetings editors, I just want to raise this issue in a centralized location for your attention. It would seem that the most controversial element of last weekend's Trump rally is its location. Reliable sources and editors are bitterly divided on this issue. Therefore I've put in some research, and proposed some compromises and a path forward.

Please keep the peace! Contribute any opinions or suggestions at Talk:Q127421251#Location suggestions. Thank you! Elizium23 (talk) 02:43, 16 July 2024 (UTC)Reply

I am rather new to Wikidata so forgive me. How are images selected for items? If it is just up to random volunteers, how are disputes resolved? I am looking at Menhera (Q126181232). Commander Keane (talk) 03:07, 16 July 2024 (UTC)Reply

It is up to random volunteers, if there is edit-warring it should be resolved via usual means. Ymblanter (talk) 18:53, 16 July 2024 (UTC)Reply

Hello! Many part-time overseas Japanese schools (schools for Japanese citizens living overseas which hold classes on weekends) have a setup where they have the school office in one location, but use a rented facility (usually another school) to actually hold the classes. For example, Columbus Japanese Language School (Q97216986) has its administrative office in Worthington, but it uses a middle school in Marysville to conduct its classes.

I set the primary location to be the administrative office and not the classroom location. Would this be OK?

As for the one in Princeton, New Jersey (Q19840596), it has an office from Tuesday to Friday in Princeton, New Jersey, but its Sunday office and classroom space is at Rider University in Lawrence Township. Should the Princeton location be the primary location, or should it be the Rider University one? WhisperToMe (talk) 03:09, 16 July 2024 (UTC)Reply

I have been working on a scholia-derived scraper (code at https://github.com/stuartyeates/scholia) which rather than being doi-centric is journal centric. That is it understands that journals have issues and issues have items in a hierarchy and crawls and links them appropriately. I'm aware that there are rules around bots and I'm a long way from running the scraper in a even a semi-automated fashion. I've got to to the point where I'm generating what look like good quick statement batches, but I've not actually tried executing them. My question really relates to testing the thing as I hand crank it: are people going to object if I import and then revert a couple of batches a dozen times as I iron out issues and get the coverage I'm looking for? My code is reasonably complex, because where items already exist for journals (which is where I'm starting) I'm trying to enhance them with proper RSS feeds, OAI-PMH info, etc, etc. Stuartyeates (talk) 08:28, 16 July 2024 (UTC)Reply

@Stuartyeates: If I understand what you're asking, you probably should post this on Wikidata:Requests for permissions/Bot. Typically 50-100 edits are fine before approval of a new bot task. ArthurPSmith (talk) 13:52, 16 July 2024 (UTC)Reply

I am not sure I understand what you want to do. Do you suggest items to be created for the journal volumes and issues, or do you suggest to pull in full issues? Egon Willighagen (talk) 18:46, 16 July 2024 (UTC)Reply

The OJS software (which has >10000 installs and is the software I'm targeting), is issue-focused so provides clear, consistent and reliable metadata for issues, but not so much for volumes, so I'm creating items for issues but not volumes. Stuartyeates (talk) 19:15, 16 July 2024 (UTC)Reply

I wasted like 45 minutes looking up guides and FAQs in order to figure out how to make a simple change, turns out it just doesn't work and you have to go on the desktop site. Sorry if this is the wrong place for such feedback but that's kind of bad. Asdf433 (talk) 14:44, 16 July 2024 (UTC)Reply

I thought this was settled years ago, but it has cropped up again. See the argument at Wikidata:Requests_for_deletions#Q126936162 as a rationale for deletion. Please contribute to the debate at Property_talk:P1343#Encyclopedias_and_dictionaries_only. While the property was created for encyclopedias and dictionaries in 2014 it has been expanded to other reliable sources that we have Wikidata entries for. The rationale for expanding its use was to make it unnecessary to create hyper-specific properties for news articles and books and obituaries. RAN (talk) 17:06, 16 July 2024 (UTC)Reply

The way that we handle genes in Wikidata is different from how they are handled on Wikipedia. For example, for the COX1 gene, Wikidata has items for:

• COX1 (Q14865314) - COX1 in Homo sapiens
• COX1 (Q14865315) - COX1 in Mus musculus
• COX1 (Q27543918) - COX1 in Saccharomyces cerevisiae S288c
• COX1 (Q24395071) - COX1 in Rattus norvegicus
• COX1 (Q29763558) - COX1 in Danio rerio
• COX1 (Q68073820) - COX1 in Caenorhabditis elegans

But we don't have an item for the COX1 gene in general, a gene that is present in all eukaryotes (plants, animals, fungi, etc.). The Wikipedia article is about the gene in all eukaryotes, but it is linked only to COX1 (Q14865314) (the gene in humans). Every gene I've checked on Wikidata is set-up in the same way, with items for the genes in specific species, but no items for the genes in general. Should we create items for the genes in general and link those to the Wikipedia articles? If so, what properties should be used to connect the general items to the species-specific items? And I realize some genes are only known from specific groups of organisms or species, so this wouldn't necessarily apply to every gene. Nosferattus (talk) 20:33, 16 July 2024 (UTC)Reply

It does indeed sound like overkill, especially as found in taxon (P703) allows a list of species for the rarer ones. I'd ask in Wikidata_talk:WikiProject_Biology, which is active. Vicarage (talk) 21:27, 16 July 2024 (UTC)Reply

At John Moncreiffe, 7th of that Ilk (Q75663418) it looks like there was a bad merge of two people with similar names. Anyone want to take on the challenge of sorting them out? RAN (talk) 22:35, 16 July 2024 (UTC)Reply

• Thanks for fixing! --RAN (talk) 05:37, 17 July 2024 (UTC)Reply

Greetings,

Over on Talk:Q127421251#Casualty count I'm questioning our method of tallying the count of victims/casualties/injuries. Currently over there (and other items such as Orlando nightclub shooting (Q24561572), the casualties are tallied with both excluding (P1011) and including (P1012) qualifiers. Personally, I feel this is somewhat unwieldy that we're maintaining and referencing two parallel datasets, where one value can be inferred from the others.

Is there consensus, or a lack thereof, on how to count these? Has there been any prior discussion or dispute in this area? Should we take cues from established decisions such as enwiki's? Elizium23 (talk) 23:12, 16 July 2024 (UTC)Reply

Hi,

I came across this entity and noticed that every identifier comes from the original entity (City of Brussels (Q239)).
This issue has been raised on the talk page. But I'm not convinced this is the right way to do things. RVA2869 (talk) 08:49, 17 July 2024 (UTC)Reply

Basically this is the issue I described in Wikidata:Project_chat/Archive/2023/01#natural_locality_vs_administrative_division.--GZWDer (talk) 12:00, 17 July 2024 (UTC)Reply

Hej, I stumbled upon San Pedro de Atacama (Q42897945), which describes a national monument of Chile. The monument classifies the whole town of San Pedro de Atacama (Q187893) as a Zona Típica, i.e. a traditional village. Should these be two seperate entities or should the two items be merged?

I reckon the classification should be similar to e.g. UNESCO heritage sites. Hence, we could use heritage designation (P1435)? (See Giza pyramid complex (Q12508) for an example.) Writing this out, I have actually become quite confident that this would be the correct process but since Wikidata still is an enigma to me at most times, I want to make sure :) Fallen Sheep (talk) 14:16, 17 July 2024 (UTC)Reply

No, they should not be merged, this would result in a bunch of constraint violations. Ymblanter (talk) 19:00, 17 July 2024 (UTC)Reply