Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

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.
Start a new discussion
Edit
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.

Proposed Changes to personal pronoun (P6553)

[edit]

Introduction

[edit]

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.

Background

[edit]

Problems with personal pronoun (P6553)

[edit]
  • 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

[edit]

Use Cases

[edit]

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

Implementation Plan

[edit]

Scope of Use

[edit]

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:
Count on left, language on right

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

Partnerships

[edit]

Data Model

[edit]

Building Pronoun Sets

[edit]

Data Cleanup

[edit]

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]
+1 to Crystals question--where am I supposed to send students and editors with questions about Lexemes? The documentation is sorely lacking. Brimwats (talk) 22:40, 18 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]
I strongly reject the bias accusation implied in your comment. I'm not affiliated with UW at all & I've personally taught over 300 students how to use Wikidata at another institution entirely. @Clements.UWLib's proposal is sensible and would correct obviously incorrect data. Brimwats (talk) 22:33, 18 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]
Yes, I see that your introduction was quite clear about the Wikiproject representation.
I was honestly confused by the situation. Your username contains "Clements" but you seem to be named "Crystal" so I wasn't sure whose account it was. You're also from the University of Washington Libraries and so I sort of logically assumed that "we" referred to all UWLib Wikidata editors, is that crazy? This discussion is not on the Wikiproject page but a public noticeboard. It surprises me that a representative should be chosen by a WP to represent them and speak on their behalf; nobody would dare take this authority on enwiki. WikiProjects are egalitarian and cooperative places to establish consensus and work out disputes, and this is the first time I've seen one with a leader and representative who speaks and makes decisions on their behalf. Would I be permitted to join such a project and offer my own opinions?
And then you went around changing other editors' comments. That is strange behavior, if you ask me, and I'm sorry if I came up hostile at that point, but I honestly did not know what to think; as a longtime editor of other projects, a lot of this behavior would've been unacceptable and grounds for suspicion and blocking.
I know Wikidata works a lot differently and so I was just trying to sort out the truth of your account status, your group affiliation with the "we" statements, and your relationships with other commenters who appeared to be totally independently sharing their opinions, until you added "{{Strong support}}" on their behalf.
I'm sorry to cause offense here, but honestly, it was a bit of a dumpster fire already, being out-of-process and technically infeasible, and we still have "strong supporters" of an impossible proposal, so can we please shut this down, reset and start off on better footing please? Elizium23 (talk) 20:34, 19 July 2024 (UTC)[reply]
To be clear to others: I'm not a representative or a leader of WikiProject Personal Pronouns, I've just been fielding questions and responding to feedback, which anyone else can also do. @Elizium23, nobody in the WikiProject makes unilateral decisions and I strongly resent your accusation that I am doing so just because I've posted a few updates and responses to questions here. My username reflects a name change which is frankly none of your business. Crystal Yragui, University of Washington Libraries (talk) 00:15, 24 July 2024 (UTC)[reply]
I disagree that this has been a "dumpster fire". Most people have lodged valid criticisms without questioning editors motivations or trying to sleuth out who they are and who they may or may not be affiliated with. WikiProject Personal Pronouns is a collective of editors who have varying affiliations and cross affiliations with other WikiProjects. Affiliations with people who have a shared interest (Wikidata) doesn't mean individual people cannot come to and express there own opinions. Certainly, people can support the spirit of a project or idea, but not have clear agreement on how and if it can be accomplished. I think your accusations were unfounded and uncalled for. It serves as a means to deter current and future editors from trying to contribute more to Wikidata and its governance structure. Rodriguez.UW (talk) 17:01, 24 July 2024 (UTC)[reply]
This, and your abovethread comments are unduly hostile and aggressive and not in the cooperative and kind nature of Wikidata. I'm really disappointed to see this level of rudeness and suspicion-throwing towards fellow editors. Brimwats (talk) 22:35, 18 July 2024 (UTC)[reply]
So am I. But who in hell are you? Elizium23 (talk) 19:46, 19 July 2024 (UTC)[reply]
@Elizium23: Presumably @Brimwats is just another Wikidata contributor. There is no requirement for hierarchy before suggesting that someone's tone and approach is coming across as pretty hostile and aggressive — whether that is intended or not.
Can I suggest you take another look at the Universal Code of Conduct terms around Mutual respect, around Civility and around Assuming Good Faith. This isn't an argument over whether a thing should be done, it's a discussion on how best to address something that a group of users have identified as being problematic.
Once you're in a more collaborative mood, perhaps you could rephrase your outstanding concerns so that they can be more easily responded to. — OwenBlacker (talk; please {{ping}} me in replies) 16:33, 24 July 2024 (UTC)[reply]
@Elizium23I have to agree with @OwenBlacker even outside of the context of the proposal. There is no need for language to be escalated and questioning of motives or positions of other editors. We should all wish to keep things collegial. We all have an interest in Wikidata and the assumption of good faith is a fundamental principle in maintaining community here. Rodriguez.UW (talk) 16:49, 24 July 2024 (UTC)[reply]
Why are you accusing me of being rude if you're the one swearing at me? I fail to see any warrant or need for that level of hostility. Furthermore, what is your question supposed to mean?? Are you asking me who I am on an epistemic level? I'm probably Q5 then (if you need a link: https://www.wikidata.org/wiki/Q5)... or maybe you mean here, in this context? Then I'm probably Q28859215 or Q37226? Do you mean personally? Q109757168 would work--how about you? Brimwats (talk) 18:51, 24 July 2024 (UTC)[reply]
 Strong oppose Wrong venue for this proposal. Needs to be broken up into one or more RFCs and a property for creation proposal. William Graham (talk) 03:27, 19 July 2024 (UTC)[reply]

How are images selected?

[edit]

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]
See related discussion, at c:Commons:Deletion requests/File:Bupuro-chan.png. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:16, 21 July 2024 (UTC)[reply]

Lack of collaboration regarding historical periods

[edit]

What on earth is going on with the gatekeeping at Q6495391 ("late modern period")? I've tried to explain very clearly how this term is a Wikipedia-peddled neologism that isn't actually used by historians. The term itself fails the criteria for notability and original research and the majority of the links here are further extensions of this. I've tried to removed links to articles that obviously don't translate to "early modern" or simply doesn't match the period. Or both! I have been repeatedly reverted purely on unexplained procedural grounds.

I've been told[1] by @CFA1877 to "find a solution" before removing errors and that is just bonkers behavior in my book. I'm trying to correct false equivalents, which is a perfectly natural way of working with Wikimedia projects. If someone tries to translate "lion" as "tiger" here and links the two objects, I can't imagine anyone protesting. I have no idea what problems could be caused by removing objects, but it certainly is a problem if WikiData is hosting false information. If there are problems, it's obviously something that users can suggest their own solutions for.

@Olea and @Sofie Geneea, you're party to this conflict as well. Neither of you have bothered to motivate why you are restoring bad info. How are you justifying your approach to this? Peter Isotalo (talk) 12:20, 18 July 2024 (UTC)[reply]

Taking into account that Q6495391 is used profusely, every time you have deleted all the information from the wikidata item, that information disappeared too in the Commons infoboxes and only "Q6495391" appeared. In the case of Spain, the mention of "Contemporary Age" disappeared. Regarding the historiographical question, I think it can be easily resolved by changing "late modern period" to "Contemporary Age", which is the most used element in Q6495391. But the solution cannot be, in any way, a mass deletion, creating more problems and conflicting with many users. CFA1877 (talk) 12:35, 18 July 2024 (UTC)[reply]
What Commons infoboxes? Be specific rather than just allude at the issues. Peter Isotalo (talk) 16:20, 18 July 2024 (UTC)[reply]
Any of the pages listed at commons:Special:EntityUsage/Q6495391 of which there are over 1000. William Graham (talk) 16:45, 18 July 2024 (UTC)[reply]
Are all of these assigned to Q6495391 directly? Has it been done manually for all of them? Peter Isotalo (talk) 17:32, 18 July 2024 (UTC)[reply]
Because Wikidata is structured, sometimes it has more than one item about what some would regard as different definitions of the same thing. For example the subject of Modern History MA (Honours) is the "modern period", and the subject of Themes in Late Modern History (c. 1776 - 2001) is the "modern period", of which the "early modern period" is a part? Although that example is not from Wikidata, there could be statements in Wikidata for which a second item is useful (as well as being necessary for the sitelinks), and although they can have the same label and be distinguished by description, an alternative name can be less confusing whether it's this or another name. Examples of use:[2][3][4][5]. The false information I found was the description of various articles as being about the period starting in 1945 and that was the result of moving the sitelinks without changing the descriptions and statements to match the changed scope of the items. The Commons infoboxes affected are many of the items in Special:WhatLinksHere/Q6495391; some are buildings and other structures where it is a qualifier in instance of (P31) (example: Q1862973#P31, which was added to Q97641882 before that item was merged to Q1862973), where it is probably not necessary and would be better not displayed in Commons if years are present (there was also an incorrect end time (P582) qualifier added at the same time) but there are other statements such as field of work (P101) where a label is useful. Peter James (talk) 16:57, 18 July 2024 (UTC)[reply]
Historians these days (and probably since the late 1990s) use "modern period" for anything after the early modern period. In other words "the period we live in now". It's possible that some historians still use "modern period" to everything after the Middle Ages until now, but it's probably quite rare.
I've never seen a historian describe the early modern period as being "part" of the modern period. Again, that's a Wikipedia-generated misunderstanding. Peter Isotalo (talk) 17:40, 18 July 2024 (UTC)[reply]
Let us not omit major schools of thought which propose late modernity (Q4346302) as well as postmodernity (Q2249769); these items do not appear to be infected with the conflation of concepts which has caused this dispute. Elizium23 (talk) 20:53, 20 July 2024 (UTC)[reply]
I agree. Late modernity and postmodernity are perfectly valid and widely recognized topics in their own right. They just don't correspond to the term "late modern period". Peter Isotalo (talk) 13:53, 23 July 2024 (UTC)[reply]
If we asked ten different scholars what defines these periods, what comprises them, what differentiates them, etc. it seems like we would receive ten different answers. Not only would we have different labels for the same thing--we'd have the same labels for different things, and so on.
It's a multidisciplinary concern, and so we can't simply consider history, but any scholarship that deals with changes over time, so I can't see a way to satisfy everyone with every need.
Perhaps it would help to sample these definitions, get an overview of how they're defined, and work out some diagrams, schemas of how they could be represented through Wikidata. It may result in the restructuring of many items across many wikis, but only a minority of the stakeholders are active here on this project, so a wider/more central venue for discussion would be appropriate. Elizium23 (talk) 01:16, 24 July 2024 (UTC)[reply]

Start time/end time of logos

[edit]

Special:Diff/2208054935 gave a single-value constraint warning. Should it be done some other way? The logo was used, then replaced, then changed back again. Jonteemil (talk) 12:56, 19 July 2024 (UTC)[reply]

@Jonteemil there are two start time (P580) RVA2869 (talk) 13:36, 19 July 2024 (UTC)[reply]
Well, yeah? There are. Jonteemil (talk) 13:41, 19 July 2024 (UTC)[reply]
@Jonteemil: Constraint violation warnings are advisory, not mandatory. If you are aware of a small number of exceptions to a constraint you can add them I think in property documentation to remove the warning. If there are a large number of violations then maybe the constraint is wrong and should be removed - discuss on the property talk page. ArthurPSmith (talk) 14:15, 19 July 2024 (UTC)[reply]
The question was if I had done it correctly, because the display isn't really that optimal. It should be more like: 1905-2017, 2022-, the first end time should be shown before the second start time, otherwise it looks weird, like it does now. Jonteemil (talk) 15:48, 19 July 2024 (UTC)[reply]
Just have two statements about the same logo with different time. --Matěj Suchánek (talk) 16:19, 19 July 2024 (UTC)[reply]
Wasn't that what I tried to do? Jonteemil (talk) 23:41, 19 July 2024 (UTC)[reply]
This is what I mean: Special:PermaLink/2208672948#P154. Free of any warnings. --Matěj Suchánek (talk) 10:10, 20 July 2024 (UTC)[reply]

Bug: Facebook pages URL are wrong

[edit]

Every politian (and maybe every popular person) that has a Facebook page there is the field to add the username, let's say "myusername". The bug is that Wikidata is adding "/page" in the URL so it's pointing to facebook.com/page/myusername and it's a 404 not found error. Example: Q4137510

I don't know how to get rid of "/page/" in the URL. I might be wrong but I think this is a global Wikidata bug. 2802:8012:5319:FF00:ECA1:37BC:3D5D:99CE 07:50, 20 July 2024 (UTC)[reply]

Verification of your claim failed in my case. The corresponding URL formater is correct and does not seem to have been changed recently. —Mykhal (talk) 08:02, 20 July 2024 (UTC)[reply]
… and if you mean at eswiki(pedia) for the example (here), it's not related to wikidata; and I also cannot confirm trailing slash being a problem. —Mykhal (talk) 08:10, 20 July 2024 (UTC)[reply]
There are five properties with "Facebook" in the name, and the identifier in Q4137510 correctly uses Facebook username (P2013), but Q4137510#P856 had Facebook page ID (P4003) (with "/pages/" in the URL) in the references, which I changed to Facebook username (P2013). Peter James (talk) 10:03, 20 July 2024 (UTC)[reply]
Thank you very much. I confirm that now is working correctly. 190.176.187.23 10:21, 21 July 2024 (UTC)[reply]

Question about properties

[edit]

Are we now creating properties to reference aspirational projects with no more that a few hundred links, but with the intention of having more? Because I always assumed about a thousand was sort of the bottom limit. I opposed this one and just received a notice it was created Women in Resistance ID (P12902) Jane023 (talk) 09:36, 20 July 2024 (UTC)[reply]

The recommendation is to decline properties that can't be used on more than 100 items. If it's not above this, then votes doesn't matter. Infrastruktur (talk) 10:19, 20 July 2024 (UTC)[reply]
Thanks I thought the limit was 1000. I will try to remember 100 from now on. Jane023 (talk) 11:03, 20 July 2024 (UTC)[reply]

Preventing bad merges

[edit]

I patrol Wikidata:Database reports/items with P569 greater than P570 and reverse bad merges where the birth and death dates do not match triggering an entry in the report. Is there any way we can add a warning during the merge process when the birth, and or, the death dates are off by at least 3 years? It would cause the person merging to double check that they have the correct person. At Familysearch you get a warning when this occurs, it would be helpful here. RAN (talk) 17:20, 20 July 2024 (UTC)[reply]

[edit]

Wanted to share the result of some work I recently undertook to link all UEFA teams (eg Spain at the UEFA European Championship 2024 (Q124150793)) since the championship began in 1960 to the players that played on their teams. This was a semi-automated approach where I copied player tables on the French or German Wikipedia pages, used a custom little interface to convert them to QuickStatements which added the links to Wikidata. Some were already there, but in total there are now 4695 linkages! Besides the player themselves, some teams also have extra information, like player position, number of games played, goals scored, or jersey number. But these weren't consistently present on the Wikipedia pages themselves, so aren't always present.

Here are some SPARQL queries to explore the results:

There is one team which I haven't completed, Czech Republic at the UEFA European Championship 2004 (Q115647657), which is peculiarly the only team that does not have a French or German Wikipedia page! If I can find data for that somewhere, will import it as well.

Cheers, Hardwigg (talk) 18:21, 20 July 2024 (UTC)[reply]

It's the only team with no French article, but there is Czech Republic at the UEFA European Championship 2004 (Q1318209) in German and Ukrainian. Peter James (talk) 20:30, 20 July 2024 (UTC)[reply]
Oh fantastic, thank you for merging! Just ran the quickstatement import; now it's all! Hardwigg (talk) 13:18, 21 July 2024 (UTC)[reply]

Multiple national versions of one name - how to manage iwiki

[edit]

Hello, I made today Czech Wikipedia article Q127686635 (and Wikidata item) but on Wikidata is unclear situation. This name has Slavic equivalents: Q11763130, Q13566215, Q100376113, Q100376283, maybe even more. I got it, every variant should have its own Wikidata item because it has its own transliteration, language, script etc. But what I didnt got - How to manage iwiki? Its not possible to have for example in Czech Wikipedia own article for every single variant of this name. We have one common article for all wariants. So how to manage iwiki? Now I made it by adding all of Wikipedia pages to only one Wikidata item of only one name variant: Q13566215. But is it correct? Does exist any more clear, systematic solution? For example I feel the best way would be to leave all Wikipedia links in correct Wikidata item, but have possibility to say to system "these items are iwiki related" and then more Wikidata items will be connected in iwiki section on Wikipedia. Thank you for your opinions and experiences. Palu (talk) 13:08, 21 July 2024 (UTC)[reply]

Adding links to different variants to one item is simply not correct. Revert these changes, simply use old style interwiki. See Wikidata:WikiProject Names for more insight. Jklamo (talk) 18:02, 21 July 2024 (UTC)[reply]
Yes, not correct, but have no iwiki is also not correct. OK, old-style wiki is possible, but for me also not correct (not systematic). But it looks there is no better solution. Maybe later will arise...? --Palu (talk) 18:06, 21 July 2024 (UTC)[reply]
@Jklamo: Old style interwiki should be considered deprecated way to represent the information. Instead, it should be solved via sitelinks to redirects.--GZWDer (talk) 15:37, 22 July 2024 (UTC)[reply]
Yes, thank you very much. Here is example and works great. --Palu (talk) 16:06, 22 July 2024 (UTC)[reply]
GZWDer: But what I have to say - its pity that you have to make it for every one wikipedia extra. Now Czech works well, you can see links to others, but from others you cant. If you want, you have add every redirect links to every Wikidata item. And it is quite hard to manage, especially when there is many linked Wikidata items. And it is hard to maintain in time (pages are changing and you have to change every single Wikidata item extra). --Palu (talk) 16:09, 22 July 2024 (UTC)[reply]

Same situation: Q58710354. 3 different Wikidata item, each has own Wikipedia article, iwiki not working. --Palu (talk) 17:51, 21 July 2024 (UTC)[reply]

Gabon - description

[edit]

Hello everyone, can you change the description of Gabon. It's a country located in central Africa not in Western Africa. Thanks ! Apipo1907 (talk) 21:59, 21 July 2024 (UTC)[reply]

New "mul" term language code on Wikidata

[edit]

(This [SIGNIFICANT Change Announcement] is relevant for all Wikidata users working with Labels and Aliases.)

Hello,

You may recall our previous announcement inviting you to test out the “default values for all languages” feature, introducing the language code "mul" for labels and aliases, on https://test.wikidata.org. I'm pleased to announce that we are now proceeding with a limited release on Wikidata. This feature will be available for testing starting July 29.

Note of Caution and Tips for Testing

  • To try out the new feature during this limited release, you need to add the language code “mul” to your Babel boxes. A full release will follow on the week of August 12, displaying default values to everyone by default.
  • Please refrain from starting any Bot-runs for mul during the limited release. We will use this limited release to test the performance and verify that everything works as planned. Bot-runs for mul should only commence after the full feature is released.
  • Please also test the help page explaining how to use the feature. It will be important to get this help page right, as the full release will initially contain an onboarding element that guides people to this help page.

I would like to thank everyone who has participated in the previous testing phases or provided feedback thus far. We are eager to hear more from you during this limited release. Please do not hesitate to reach out with questions or concerns on the talk page of the Help page, or for technical details, in this Phabricator ticket (phab:T356169)

There has also been some discussion on the help page regarding the copy used for the language. We would like to reach a consensus before the full release. Join the discussion to add your thoughts and input on the thread. This week, a survey will be included in the Weekly Summary for those who prefer to provide anonymous feedback.

Cheers! -Mohammed Abdulai (WMDE) (talk) 08:00, 22 July 2024 (UTC)[reply]

Qualifier value violations?

[edit]

I fail to understand what the issue is with these Qualifier value violations. What is expected for the number of members of an organization? Judging from the fairly large number of violations something is going really wrong here, or the expected entries are counter intuitive or... I cannot tell. Anyhow, any insight on this is welcome. Cheers [[kgh]] (talk) 15:22, 22 July 2024 (UTC)[reply]

Wow, nobody with a clue? [[kgh]] (talk) 07:58, 26 July 2024 (UTC)[reply]

Datatype-change proposal

[edit]

I would like to propose changing the data type of NIOSH Pocket Guide ID (P1931) to external identifier. The current data type is string. Janhrach (talk) 15:38, 22 July 2024 (UTC)[reply]

  • @Janhrach: At the time of the initial datatype conversions for external id's this property was listed as disputed due to the same id being applied to multiple items - "only 94.17% unique out of 720 uses". This should probably be cleaned up if it hasn't been in the meantime, or clarified in how the property should be used. ArthurPSmith (talk) 13:59, 23 July 2024 (UTC)[reply]

How to model crimes

[edit]

See: Lindbergh kidnapping (Q844495) where the crime is modeled multiple ways, what is the standard way we are going to harmonize on? RAN (talk) 16:03, 22 July 2024 (UTC)[reply]

Wikidata weekly summary #637

[edit]
Here's your quick overview of what has been happening around Wikidata over the last week.
This is the Wikidata summary of the week before 2024-07-22. Please help Translate.

Discussions

  • New requests for permissions/Bot:
    • DannyS712 bot - Task/s: I want to get approval for a bot with translation admin rights that will automatically mark pages for translations if and only if the latest version is identical to the version that is already in the translation system, i.e. only pages with no "net" changes in the pending edits.
    • DerIchBot - Task/s: Adding data about schools provided by the German and Austrian governments to wikidata.
    • DifoolBot 5 - Task/s: Change reference URLs into the related ID property and merge references with the same ID property.
    • AroundTheBot - Task/s: Automated import of Albanian nouns with IPA from Wiktionary, with the long-term goal of using this data to do pronunciation-based comparison/word evolution between languages.

Events

  • Past: Wikimedia Indonesia hosted the 2024 Data Visualization Competition from June 5 to 18. The event featured data visualizations (posters and graphics) and short essays using data from Wikidata. Visit the competition page (in Indonesian) to view the winning entries.
  • Upcoming: Wikidata's 12th birthday decentralized events will take place in October and November 2024. Feel free to browse the documentation pages to learn how to organize an event in your area, get funding, and get in touch with other organizers.

Press, articles, blog posts, videos

Tool of the week

  • Paulina, a new tool for exploring public domain works.

Other Noteworthy Stuff

  • WMF Product and Technology Advisory Council (PTAC) invites interested volunteers to apply. As part of the movement strategy recommendation for "Coordinating Across Stakeholders," the PTAC will bring technical contributors and the Wikimedia Foundation together to co-define a more resilient, future-proof technological platform.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • mul: We fixed the last blocker for the limited MUL rollout to Wikidata on July 29th (phab:T362917)
  • EntitySchemas:
  • Query Service: preparation for the graph split is continuing by the Search Platform Team. We started looking into adapting the constraints checks for it (phab:T369079)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

How to express that one source qualifies a date as latest possible

[edit]

For Carrer dels Domenics, 26 (Q127697124), one of my sources points out that the 1936 date given by several official sources (including [6], which postdates that first source) is really a latest possible date: "Consulté también el catastro (es que una es así de cabezota) y la fecha que consta es 1936 y está declarada como vivienda. Sin embargo, teniendo en cuenta que la urbanización esta zona de la calle Quatre Camis es de esa fecha, no sé hasta qué punto la casa no será anterior," not easily translated but basically saying that it first shows up on property records in 1936, but there is no guarantee that it might not be older. Any reasonable way to express that qualification? - Jmabel (talk) 01:56, 23 July 2024 (UTC)[reply]

I would further mention that the architect (Eusebi Climent Viñola) died in 1917, so it would be odd for a building of his to be completed decades after his death, so I'm pretty skeptical about the one source we have, even if it is an official government source. - Jmabel (talk) 04:58, 23 July 2024 (UTC)[reply]
@Jmabel, I'm not sure which of latest start date (P8555), latest date (P1326), or ‎latest end date (P12506) would apply in this specific case.
If you want to say the latest date that Carrer dels Domenics, 26 (Q127697124) starting being a building, I'd do
Carrer dels Domenics, 26 (Q127697124)instance of (P31)building (Q41176)latest start date (P8555)1936 Lovelano (talk) 20:34, 26 July 2024 (UTC)[reply]

Conflation

[edit]

The IP 83.28.217.24 seems to add whatever is connected with a name. I've just marked Wendy McMahon (Q121437661): American television executive mixed with a lecturer in American Studies as conflation. (I haven't corrected all errors yet.) Now I've checked Randy Petersen (Q7292360): American publisher, the founder of FlyerTalk, and the conflation seems even worse. IdRef for an educator, VIAF 10083800 with 100 Bible verses that changed the world etc. Can someone have a look? --Kolja21 (talk) 11:30, 23 July 2024 (UTC)[reply]

I reverted the recent additions. The links are at https://snaccooperative.org/ark:/99166/w6sp2nn0 but they seem to be at least three different people. Peter James (talk) 19:35, 25 July 2024 (UTC)[reply]
✓ Done Thanks. Conflation solved. Kolja21 (talk) 12:31, 26 July 2024 (UTC)[reply]

Invalid none-of constraint on owned_by

[edit]

owned by (P127) has a none-of constraint (Q52558054) with item of property constraint (P2305)Government of India (Q2767140) and replacement value (P9729)India (Q668) qualifier. I think it is incorrect and should be the other way around. DaxServer (talk) 12:17, 23 July 2024 (UTC)[reply]

Sovereign countries

[edit]

There are several items denoted as 'sovereign countries' http://www.wikidata.org/entity/Q3624078 which are probably not, or collide with other entries:

http://www.wikidata.org/entity/Q756617

http://www.wikidata.org/entity/Q127424576

http://www.wikidata.org/entity/Q100748892

http://www.wikidata.org/entity/Q124653007

What is the policiy about such items? AridOcean (talk) 12:20, 23 July 2024 (UTC)[reply]

countries are a can of worms, not only in their definition, and historical layering, but people's strongly held views that the world's power structures should be different to how they are. BTW If you use the Q template you can get the names in the message, as in Kingdom of Denmark (Q756617) Vicarage (talk) 13:01, 23 July 2024 (UTC)[reply]

Q15722637

[edit]

Hi! I wonder if Category:GFDL works (Q15722637) matches any other Q here. What about Category:Wikipedia articles licensed under the GNU Free Document License (Q8109484)? It is stated to be different from Category:GFDL files (Q7237102) but it links to the category on Commons that links to Category:GFDL files (Q7237102). MGA73 (talk) 20:57, 23 July 2024 (UTC) fixed to use template Vicarage (talk) 21:13, 23 July 2024 (UTC)[reply]

I am a wikidata virgin (male) , and I need help to post some data there.

[edit]

I created a complete bibliography list of works by a recent Nobel prize winner John B. Goodenough, and I posted my list to https://en.wikipedia.org/wiki/John_B._Goodenough. Another editor suggested, that I move this list to wikidata, and provide a link to wikipedia. Since I have never used wikidata ( and do not plan to use it much to justify the learning time), I am asking someone to place my list to wikidata. Walter Tau (talk) 00:46, 24 July 2024 (UTC)[reply]

Hello Walter Tau, Wikidata objects related to d:Q906529 can be found for example at:
M2k~dewiki (talk) 12:07, 24 July 2024 (UTC)[reply]
If you want to generate static wiki pages from a collection of wikidata items, you could also use Wikidata:Listeria.--5628785a (talk) 14:50, 24 July 2024 (UTC)[reply]

Is there a property of the "last public appearance in a photograph" of a person, such as actor, politician or other persons?

[edit]

I notice this Property:P12878 = last appearance (P12878) "last work featuring a fictional character or item"

Thank you, -- Ooligan (talk) 16:08, 24 July 2024 (UTC)[reply]

Journal Issues

[edit]

Would like to create item for journal issue and post table of contents I.e. list of titles of all articles with author details for all the articles. Please post any help page or link document. Thanks.

Vjsuseela Vjsuseela (talk) 16:28, 24 July 2024 (UTC)[reply]

@Vjsuseela The Wikidata:WikiCite group/project and Wikidata talk:WikiCite should be able to help you. They're the project that focuses on this scholarly and scientific journals. William Graham (talk) 16:38, 24 July 2024 (UTC)[reply]

EU Commission - European electronic health record exchange format - (EEHRxF)

[edit]

I'm coming in via the EU Health Union, Priority 8: eHealthRecord, Patient Data Vault, eHealthKiosks, Smartwatches & sensors, storing and sharing health data. Anybody working on this or any advise/vision on this? Most EU member states have implemented the EEHR. Implementation of the EEHRxF - so that eHealthKiosks, Smartwatches & sensors directly write data into citizen's eHealthRecords starts november 2024 and compliance to be implemented by 2027 - from then on there will be penalties. It is not normal that +60.000 Power people in the Brussels power bubble and politicians everywhere in Europe have their smartphones register how many hours they slept, if they slept well, if they are struggling with fatigue, etc - idem their family members and that those data are via their iPhones somewhere with the secret services of the USA, Huawei - with their Chinese counterparts smiling because they know exactly how fatigues you are and that you will be inclined to give in into a negotiation if they just strech it, Samsung - no idea where that data ends up, etc. More: https://xpandh-project.iscte-iul.pt Looking forward, SvenAERTS (talk) 17:09, 24 July 2024 (UTC)[reply]

The connection between this and Wikidata completely escapes me. - Jmabel (talk) 23:24, 26 July 2024 (UTC)[reply]

Statements for suspended then cancelled event

[edit]

Which statements to add for suspended then cancelled event? Eurohunter (talk) 12:59, 25 July 2024 (UTC)[reply]

If nothing else, there's
⟨ FOO ⟩ significant event (P793) View with SQID ⟨ suspended (Q115754746)  View with Reasonator View with SQID ⟩
and
⟨ FOO ⟩ significant event (P793) View with SQID ⟨ cancelled (Q30108381)  View with Reasonator View with SQID ⟩
with dates as qualifiers. (This assumes that FOO is an item for the event.) - Jmabel (talk) 23:32, 26 July 2024 (UTC)[reply]

Office_holder or has_part

[edit]

Noble titles appear to be split between two ways of modelling. See: Lord Lovat (Q1869887) where I include both. Which model should we harmonize on? RAN (talk) 15:52, 25 July 2024 (UTC)[reply]

Discographies

[edit]

Are entries like Lord Lovat (Q1869887) Bennie Moten's Kansas City Orchestra discography (Q96159078) and Bennie Moten's Kansas City Orchestra's albums in chronological order (Q96159307) suppose to link to an actual discography that we store somewhere internally or stored externally? Or do we create discography entries for every musical group? RAN (talk) 16:30, 25 July 2024 (UTC)[reply]

Sorry, I can’t understand the question. Did you link the right item? --Geohakkeri (talk) 16:55, 25 July 2024 (UTC)[reply]
I'm generally of the opinion that items of type Wikimedia list article (Q13406463) and subclasses, including Wikimedia artist discography (Q104635718), shouldn't have any statements of has part(s) (P527) when those relationships can already be determined with data that is already exists in the constituent member items. For discographies we already have the ability to search items that have the musician/group in the performer/artist statements. For the same reasons I don't think it would make sense to add a part of (P361) statement to a song/recording/album linking to a discography item.
But that is just my opinion and I'm sure that the folks at Wikidata:WikiProject Music have thought more about it and might even have some good showcase/exemplar items. Celine Dion discography (Q50638) was linked on their project page and it looks like a reasonable approach/how I would expect it. William Graham (talk) 18:59, 25 July 2024 (UTC)[reply]
Sorry and to circle back to the question asked, for those same reasons (can already determine discography by inference from existing items) I don't think it is needed to create a discography for every musician/group unless there is a discography page on a Wikimedia project. William Graham (talk) 19:50, 25 July 2024 (UTC)[reply]
Copypasta error? Looking like Q1869887 points to the "noble title" mentioned in the post above, not really relevant to discographies (unless I'm missing some context). Moebeus (talk) 19:41, 25 July 2024 (UTC)[reply]
  • Sorry! My fault. I corrected it above. I do not see a point having them, we can link to Discogs or DAHR from the discography link but we already point to it from the main Wikidata entry. They provide nothing useful unless there was a separate Wikimedia entry. --RAN (talk) 21:30, 25 July 2024 (UTC)[reply]
    Simplifying it a little I would say the reason we have them is threefold:
    1. Consistency. A large amount of discografies exist on WP and therefore on WD, so a large amount of recording artists will have these statements anyways, whether we like them or not. Discography articles on Wikipedia tend to get added and deleted, split and merged, all the time, so "let's just make them all conform to the norm and move on to more pressing things".
    2. Structure. Among other things they provide a way to link to Wikipedia Categories, which we don't like cluttering up our main items more than necessary.
    3. Compromise. A common pattern on Wikipedias are "Infoboxes", and these infoboxes often have a "<previous record><this record><next record>" navigation element. These keep getting added to Wikidata in the form of follows and followed by statements in the hundreds of thousands. This is to be avoided, so a practise has developed where discografies are used to model the infox chronologies, extending an olive branch to our sometimes very insistent editor collegues on the Wikipedia side of the fence, while pruning excessive main statements. Several Wikipedias who are not English Wikipedia actually use Wikidata to automate parts of these Infoxes, so we're making an effort to not just yank stuff out, but provide a way to transition.
    None of these are very good arguments from a purist standpoint, personally I would say it's mostly fair if we're trying to be pragmatic about it. However, as is frequently pointed out to me, this is just like, my opinion, man, and not the official position of Wikidata:WikiProject_Music.
    Is there a smarter way to go about it? Discographical chronologies are not as straightforward as one might intially think, but I would still say 100% yes there is. It would require copious amounts of both elbow grease and consensus, two of the most sought after rare earth minerals on planet Wikidata, but it could for sure be done. Moebeus (talk) 11:44, 26 July 2024 (UTC)[reply]

Non-unique statement id in Q85046372

[edit]

According to Wikidata documentation: [stmt_id is] An arbitrary identifier for the Statement, which is unique across the repository.

But going to the Wikidata webpage for Secondary limb lymphedema (Q85046372) and looking in the page source, we can see that Q85046372$70E829CD-2D80-48D1-BB71-8EE2B5C22051 is referenced twice, every time with a different underlying data: 

<div id="Q85046372$70E829CD-2D80-48D1-BB71-8EE2B5C22051" class="wikibase-statementview wikibase-statement-Q85046372$70E829CD-2D80-48D1-BB71-8EE2B5C22051 wb-normal">...</div>
...
<div id="Q85046372$70E829CD-2D80-48D1-BB71-8EE2B5C22051" class="wikibase-statementview wikibase-statement-Q85046372$70E829CD-2D80-48D1-BB71-8EE2B5C22051 wb-normal">...</div>

Both ids show up in cites work (P2860): Arm morbidity after sector resection and axillary dissection with or without postoperative radiotherapy in breast cancer stage I. Results from a randomised trial. Uppsala-Orebro Breast Cancer Study Group (Q73307092) and Case-control study to evaluate predictors of lymphedema after breast cancer surgery (Q37410695). 195.191.163.76 07:26, 26 July 2024 (UTC)[reply]

Vote now to fill vacancies of the first U4C

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

Dear all,

I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through August 10, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.

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 were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.

Please share this message with members of your community so they can participate as well.

In cooperation with the U4C,

RamzyM (WMF) 02:46, 27 July 2024 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2213607194"