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

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/06.


forced pregnancy (Q5467540)

Do we really want to list every death from lack of access to abortion on Wikidata? Trade (talk) 12:49, 25 July 2022 (UTC)[reply]

Before looking at the history I was wondering if LAP959 found a new subject to work on. Sure looks like it. This user has a pattern of using significant event (P793), notable work (P800), depicts (P180) in the wrong way, see User talk:LAP959 for more examples. Just remove it. Multichill (talk) 14:03, 25 July 2022 (UTC)[reply]
To Trade (talk) and Multichill (talk) : These are women whose deaths caused a public outcry and, in some cases, resulted in a major change in a country's legislation, for example Ireland, which changed its laws due the scandal.
Each cases is thoroughly documented in newspaper articles. I think that rather than simply eliminating the information, a better, more inclusive approach might be to add sources that make it clear why these particular deaths of girls and women are historically significant.
In 2012, Savita Halappanavar, age 31 and 17 weeks pregnant, went to a hospital in Galway, Ireland. Doctors there determined that she was having a miscarriage. However, because the fetus still had a detectable heartbeat, it was protected by the Eighth Amendment. Doctors could not intervene – in legal terms, ending its life – even to save the mother. So she was admitted to the hospital for pain management while awaiting the miscarriage to progress naturally. Over the course of three days, as her pain increased and signs of infection grew, she and her husband pleaded with hospital officialsto terminate the pregnancy because of the health risk. The request was denied because the fetus still had a heartbeat. By the time the fetal heartbeat could no longer be detected, Halappanavar had developed a massive infection in her uterus, which spread to her blood. After suffering organ failure and four days in intensive care, she died. This was likely not the only time someone had suffered, or even died, as a result of being denied abortion in Ireland. But the publicity surrounding the case prompted a new wave of activism aimed at repealing the Eighth Amendment. In 2013, the Protection of Life During Pregnancy Act was signed into law, which did not fully repeal the Eighth Amendment but legalized abortions that would protect the mother’s life. - https://www.pbs.org/newshour/health/what-irelands-history-with-abortion-might-teach-us-about-a-post-roe-america
Please see:
Wikipedia's Hostility to Women (The Atlantic)
"Some female editors have been the target of harassment from their male colleagues—and the gender bias has spilled over into the site’s content, too."
https://www.theatlantic.com/technology/archive/2015/10/how-wikipedia-is-hostile-to-women/411619/ LAP959 (talk) 16:25, 25 July 2022 (UTC)[reply]
How is this related to the Atlantic article? --Trade (talk) 16:38, 25 July 2022 (UTC)[reply]
@LAP959 I reverted your edits. This is not the right way of using this item. Ayack (talk) 16:45, 25 July 2022 (UTC)[reply]
*** Ayack (talk) , please suggest the proper way to link the significant changes in Irish law (in 2013 and in 2018) to the death of Savita Halappanavar, which was caused by forced pregnancy in 2012. In 2018 the Eighth Amendment was repealed. There is a Wikipedia article about it. (https://en.wikipedia.org/wiki/Death_of_Savita_Halappanavar)
"On 25 May 2018, the Irish people voted by 66.4% to 33.6% in a referendum to repeal the Eighth Amendment. They approved the Thirty-sixth Amendment of the Constitution Bill 2018 to delete the current provisions of Article 40.3."
Death and Suffering: The Story Behind Ireland’s Abortion Ban and its Reversal
"The death of Savita Halappanavar in an Irish hospital in 2012 after she was denied an abortion during a miscarriage caused outrage across Ireland."
Thank you. *** LAP959 (talk) 16:54, 25 July 2022 (UTC)[reply]
One could to model it using cause of death (P509) at Savita Halappanavar (Q5247527). But this gives a constraint violation, currently. You could also use significant event (P793) at Savita Halappanavar (Q5247527), I think. - Valentina.Anitnelav (talk) 17:38, 25 July 2022 (UTC)[reply]
Thank you. Should be better now. LAP959 (talk) 05:35, 26 July 2022 (UTC)[reply]
I think manner of death (P1196) would be the right property. ChristianKl ❪✉❫ 10:27, 1 August 2022 (UTC)[reply]
@ChristianKl . Following up on your suggestion, I tried to use manner of death (forced pregnancy) but it returns a constraint error:
one-of constraintHelp Discuss
The value for manner of death should be one of the following:
Could manner of death constraints be updated to include the consequences of a forced pregnancy? Thank you. LAP959 (talk) 07:32, 3 August 2022 (UTC)[reply]
I added it to the list of values. I can't see a good reason why it shouldn't belong there. ChristianKl ❪✉❫ 08:12, 6 August 2022 (UTC)[reply]
Thank you! LAP959 (talk) 16:52, 11 August 2022 (UTC)[reply]

Wikidata as repository of study results?

Hello! Wikidata has an extensive coverage of scientific publications, and I am wondering if it may be an interesting idea to also develop a framework for adding the study results in a structured manner? Say I perform a meta-analysis, charting the results (e.g., regression coefficients or risk estimates or concentrations) from ten studies. To make my data available for others, I add the results in a structured manner to Wikidata, including meta-data such as study group charactertics and methods and time point (if repeated design). If someone later wants to repeat my meta-analysis, or just want to compare results related to a specific subject, they can now query Wikidata and get the data directly. Would this be an interesting idea to explore in Wikidata, or would it be better to make a separate Wikibase? Ajarmund (talk) 18:55, 3 August 2022 (UTC)[reply]

I don't believe Wikidata is an appropriate venue for publishing original research. I encourage you to submit the results of your meta-analysis for publication in an appropriate scientific journal. When it gets published, an item about the article can be added to Wikidata, and any statements describing the results of the research can be added to the appropriate items as well, with reference to the article item. Possibly even the details of the study as well, although I'm not sure whether that would be notable. Silver hr (talk) 19:25, 3 August 2022 (UTC)[reply]
Thank you for your quick reply; just to clarify: the idea would be to add the results of existing studies already published (and already being Wikidata items). For example, to add the actually measured cytokine levels that are reported in Male fetal sex is associated with low maternal plasma anti-inflammatory cytokine profile in the first trimester of healthy pregnancies (Q99590222) as statements with qualifiers. Ajarmund (talk) 19:40, 3 August 2022 (UTC)[reply]
I just happened to be online :). I suppose in the case of research studies that produced articles describing them, the studies themselves would be notable under criterion 2 of Wikidata:Notability. And it seems we already have such items, e.g. 18F-PM-PBB3 PET Study in Tauopathy Including Alzheimer's Disease, Other Dementias and Normal Controls (Q61902219). So I see no reason that items that are instance of (P31)clinical trial (Q30612) or a related class couldn't have statements describing them in detail.
There is the problem of reliability, though. Wikidata is a wiki that anyone can edit, which implies that any statement it contains at any point in time can be incorrect. So if your goal is to have a repository of reliable study data that scientists can use, I don't think that goal can achieved through Wikidata. Silver hr (talk) 20:31, 3 August 2022 (UTC)[reply]
Generally, listing study results in the items of the relevant scientific papers is a good idea if they can be listed in a structured way where multiple people are likely noting them in the same structure.
It's worth thinking about whether study results should belong to the item of the clinical trial or the item of the academic paper. ChristianKl ❪✉❫ 07:26, 4 August 2022 (UTC)[reply]
Seems to me a very poor idea indeed, for at least a number of reasons: WD is not designed for tabular data, and I'd presume 'study results' would tend to be exactly that. 'Study results' shorn of their context & qualifiers, seems plain wrong - the presentation of a partial picture. The diversity of forms of 'study results' would also seem to be an enormous ontological challenge; really, in my experience, no two papers have the same sort of content and I cannot imagine how data would be collected in WD in a way which made any real sense. --Tagishsimon (talk) 09:12, 4 August 2022 (UTC)[reply]
Thank you for pointing out important issues. I agree with you that study results need context, such as in the form of qualifiers. I would say that wikidata offers a unique platform to do exactly this as concepts can be referenced quite precisely across entries. I am not exactly sure what you mean by tabular as I associate it with data presentation rather than the data itself (e.g., long vs wide table formats); columns in a table are generally translatable to qualifiers? Another thought is that study results are already prevalent in wikidata - they are just associated with specific items and having the study source as reference. For example, the reference range of serum potassium level (Q658883) is kind of a study result which may have benefitted from more context/metadata (method, info about study population; human, adults, number of participants, sex ratio, ...). The question, then, is how this information is best organized; as part of the item of the source or as separate and more specific items? How can context best be preserved? How can the results be queried in a useful way? How can they be organized so that contributions can be made efficiently? -- Ajarmund (talk) 00:31, 8 August 2022 (UTC)[reply]
@Ajarmund How about you create an example item of how you expect this to be modeled? ChristianKl ❪✉❫ 09:03, 10 August 2022 (UTC)[reply]
Good idea! Here is an example https://test.wikidata.org/wiki/Q225956 -- Ajarmund (talk) 10:17, 10 August 2022 (UTC)[reply]
I can't say I'm in favor of conflating research studies and articles that describe them in the same item. We should generally err in the direction of more granularity. Also, I'm not enthused about having 3 maternal age properties; having the study populations as instances would enable the use of mean, Q1, and Q3 as qualifiers for maternal age (BTW, why maternal age and not just age?). Finally, the properties study population, reference group and outcome should have the item type. Other than that, I suppose I don't see a reason why this couldn't be in Wikidata, especially if someone finds it useful. Silver hr (talk) 16:50, 10 August 2022 (UTC)[reply]
Thank you for valuable feedback, @Silver hr! I agree with you and guess there are at least three strategies then that may produce "clearly identifiable conceptual or material" entities, with various degrees of granularity;
Example: three outcomes (say crp, BMI, cholesterol) measured in two study groups at two time points
  • Option 1: 16 items
    • One item for each study group (i.e., two items)
    • One item for each condition (i.e., time points -> two items)
    • One item for each measurement (i.e., 3x2x2=12 items)
  • Option 2: 5 items
    • One item for each study group (i.e., two items)
    • One item for each condition (i.e., time points -> two items)
    • One item collecting the study outcomes (i.e., one item)
  • Option 3: 7 items
    • One item for each study group (i.e., two items)
    • One item for each condition (i.e., time points -> two items)
    • One item for each "type" of study outcomes (i.e., crp, BMI, cholesterol -> three items)
Option 1 results in the most granularity, whereas option 3 perhaps is closest to how we conceptually think about results (i.e., the measurement of something where the focus is on something). In general, it will produce items with duplicated names, but as far as I know, that's not a problem in itself
-- Ajarmund (talk) 12:34, 12 August 2022 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ As long as fields can be edited by academic rivals, ideologically-motivated bad actors, or random bozos who just want to cause trouble, keeping study results on WD is far more dangerous than just having entries on the articles themselves. DS (talk) 13:29, 12 August 2022 (UTC)[reply]

A large number of proposed properties

Hello. There are 60 properties waiting to be created on Wikidata, which is a lot, especially with the activity of some of the project's contributors growing. The lag in this situation is unacceptable, since individual pages no longer display properties and now only text links to them. Can this situation be resolved? MasterRus21thCentury (talk) 20:26, 3 August 2022 (UTC)[reply]

There are also quite a few proposals which have been around for months & are clearly not going to be passed; they should be put out of their misery. And other proposals for which properties have been created, but which still linger as proposals. I couldn't see any guidance on when & how to close down stalled proposals having sufficient opposes to make it unlikely they'll ever be passed, nor on how archiving proposals works. --Tagishsimon (talk) 09:15, 4 August 2022 (UTC)[reply]
Looks like we ought to make the rules a bit more clear/complete, wouldn't you say? Silver hr (talk) 14:34, 4 August 2022 (UTC)[reply]
If there's no consensus and the proposal seems stale (certainly if it's been 6 months since last comments, or probably generally when it's been over a year since first proposed), then edit the proposal: put "not done" in the status field and ping all those who commented on the proposal to let them know what you've done. That automatically archives them. "withdrawn" status is also appropriate if the original proposer no longer supports the proposal, that also should automatically archive them. ArthurPSmith (talk) 19:04, 4 August 2022 (UTC)[reply]
Yes, in such a situation, a new order of creation of properties is needed in order to eliminate the queue. For example, with active voting, the creation time is reduced, and with a long one, it is increased. This also happens when discussing candidates for good and featured Wikipedia articles, whose discussion period is at least a month. MasterRus21thCentury (talk) 20:01, 4 August 2022 (UTC)[reply]
Marking proposals as done or not done is the task of people with the property creator right. User with that right are supposed to understand our current defacto norms. There's no need for formal rules. There's just a need for property creators to do the work. ChristianKl ❪✉❫ 20:57, 4 August 2022 (UTC)[reply]
That's right, but they themselves are inactive. Now they need a significant increase in activity in order to eliminate the growing debt. I could have helped, but I was stripped of my property creator flag in May and told to reapply in November. MasterRus21thCentury (talk) 06:32, 10 August 2022 (UTC)[reply]
Almost 1/2 of the properties in the queue right now have been marked as "ready" since last week. So the number of waiting properties looks the same as one week ago, but actually dozens of properties have been created in the meantime. It may not be as bad as it looks. Vojtěch Dostál (talk) 07:18, 10 August 2022 (UTC)[reply]
Another thing is that some properties are on the shelf for creation after reaching a consensus since April-May-June and have not yet been created by any of their authorized participants. Moreover, the same problem applies to the situation when a large number of properties on the topic of a particular country. Currently, 12 out of 55 "waiters" are sources for Russian sites. Since last year, I have been placing special emphasis on the development of properties related to Russia - now there are 116 more than in August 2021, that is, 137 against 253. Therefore, at present, it is necessary to limit the number of waiting lists at the level of 20-30 properties, so that there are no visible lines. MasterRus21thCentury (talk) 08:27, 10 August 2022 (UTC)[reply]
@MasterRus21thCentury Right now, there seems to be only 6 ready properties which were created in May or earlier Vojtěch Dostál (talk) 09:05, 10 August 2022 (UTC)[reply]
While a bunch of those are marked as ready I consider it questionable to label a property without an English description as 'ready' and wouldn't have created it when I was a property creator. I believe that properties should have an English description that explains what a source.
Putting things that are not Wikiprojects in Wikidata into the Wikiproject tab also makes things harder for property creators. ChristianKl ❪✉❫ 09:18, 10 August 2022 (UTC)[reply]

statements for places / qualifiers for countries

There is a disagreement between HarryNº2 and myself concerning statements of the following nature:

place of death
Preferred rank Linz edit
located in the administrative territorial entity Upper Austria
country Austria
0 references
add reference


add value

The question concerns the qualifiers. I consider them to be redundant. The modeling should be done within the object, in this case Linz (Q41329).

My esteemed colleague disagrees and wants to have a “general discussion”, hence this topic. --Emu (talk) 21:06, 5 August 2022 (UTC)[reply]

They're redundant. Using values as qualifiers when the same values are represented in the main statement value item should be done very sparingly and for good reason. There does not seem to be a good reason here. HarryNº2 is wrong in this matter. --Tagishsimon (talk) 21:14, 5 August 2022 (UTC)[reply]
I agree that this is redundant. In my opinion, it's also easier to query for it without using qualifiers. Ainali (talk) 21:34, 5 August 2022 (UTC)[reply]
Some Wikimedia projects use this information in their infoboxes. Smaller Wikipedias in particular do not have an article on each location that they can link to it. The information is even more important if the place of birth or the place of death is a certain street or hospital, for which there is no article in most Wikipedias. Therefore, the information on P131 and P17 is necessary, also due to the changeable history of many countries and municipalities, whose borders have shifted continuously and will shift in the future. Linz, for example, was not always in Austria, but sometimes in the Austrian Empire. The same applies to almost all European places, whose affiliation has constantly changed. Besides, it was not about Linz, but about a small unknown place in Austria called Seewalchen am Attersee. --HarryNº2 (talk) 22:09, 5 August 2022 (UTC)[reply]
Grateful that you've thrown all of the arguments against the wall on the off chance one will stick. Looking at the first 300,000 P20 statements on WD, P17 is a qualifier on ~1% of them, and P131 is used as a qualifier on 0.6% - https://w.wiki/5YNZ . Smaller wikipedias alleged to have a dependency on these qualifiers are going to be sorely disappointed. You talk about "the information on P131 and P17 is necessary" and we say: yes; they would be much better off getting their P131 & P17 data from the value item. It is the case that borders move, and that is a fair argument for qualifiers when that has occurred; on the other hand, in this instance, Lisa-Maria Kellermayr (Q113344024), I'm unaware of Austria's borders having moved. Seewalchen am Attersee is not unknown to WD. It has valid P17 and P131 data in it - Seewalchen am Attersee (Q876227) - and in each case, only a single statement, so there is no room for ambiguity in this case. Good try, but you still lack a good reason and are going against the established pattern b/c it is your whim, not b/c it is neccesary or helpful. --Tagishsimon (talk) 22:51, 5 August 2022 (UTC)[reply]
What are the numbers supposed to tell us? That a bot has created most of the articles in Wikidata, which is not able to insert the data on country (P17) and located in the administrative territorial entity (P131), as this requires a lot of research work. And Austria-Hungary (Q28513) used to divide itself into Cisleithania (Q533534) and Lands of the Crown of Saint Stephen (Q696970). Before that the country was called Austrian Empire (Q131964). There are heaps of errors in Wikidata with this information, especially about Austria (Q40). And this is exactly the problem with people who were born or died in the past, or when it comes to nationality in the past. If you study the history of Austria and its individual states, you will understand my point. And that is just one of many examples, especially when it comes to a European country. --HarryNº2 (talk) 08:45, 7 August 2022 (UTC)[reply]
I changed Seewalchen am Attersee to Linz because the immediate reason we are having this conversation is a very tragic one. I didn’t want to implicitely associate this tragedy with some technical question about modeling. Especially as you yourself said that this is about the general principle. --Emu (talk) 22:56, 5 August 2022 (UTC)[reply]
Where should one draw the line as to when the disclosures should be made and when they should not. The fact that often no information is given is also due to the fact that it is sometimes very difficult to name the affiliation of a place to a certain time, which sometimes requires a lot of research work. Even in the actually good articles on places in the German-language Wikipedia, it is often not stated when the place belonged to which area or country. For example, on Commons, the place of birth and death are displayed in the info boxes with the information from Wikidata with the details P17 and P131. If the place has no pictures, it has no category and is not linked on Commons. --HarryNº2 (talk) 23:10, 5 August 2022 (UTC)[reply]
Your sentence 1 question is hard to answer. But then you go back to throwing stuff against the wall. Neither "no information is given is also due to the fact that it is sometimes very difficult to name the affiliation of a place to a certain time" nor "it is often not stated when the place belonged to which area or country" are causes to add qualifiers to P20, but instead invite the value item's data to be improved. And I'm not seeing any place of birth or death info in the commons infobox for Douglas Adams (Q42) - https://commons.wikimedia.org/wiki/Category:Douglas_Adams - nor any chasing back of P131/P17 trees from e.g. his 'educated at' locations.
Dealing with, shall we say, the Schleswig–Holstein question where the P131 and/or P17 for a place of birth or death has changed since the birth or death, there appear to be two main options: use the date of birth or death to estabish which P131 and P17 value from the place item should be used; or denormalise the data as qualifiers in the place of birth/death statement. It's reasonable to say that for WD, the priority should be in ensuring that the place item has a dated history of P131 and P17 data - benefitting all items using that place item - rather than 'improving' a single statement in a single item. However a case can certainly be made for the qualifier approach, and a suggested test is: that the P17 or P131 value has changed since the date of birth or death and that the change is material. And so that means probably not trying to reflect UK local government reorganisations, for instance, through P20 qualifiers, b/c it's immaterial if it was this urban council or that unitary authority. Given the stats I produced above, I think the mission looks Sisyphean and the probability it will be used is small, because who wants a dependency on data values found in such a tiny fraction of items? --Tagishsimon (talk) 23:45, 5 August 2022 (UTC)[reply]
And even in those cases, the qualifiers would just compensate for a shortfall in programming as (in theory) the necessary information could be extracted from the dated information on the location item. --Emu (talk) 23:50, 5 August 2022 (UTC)[reply]
Just passing by. Is there transitive information exploited by any infobox in a query way? Eg if someone is born in year Y in the town T, can infobox query and show the country where he was born ? I'd be curious about how the infobox can implement transitive informations. Bouzinac 💬●✒️●💛 07:47, 6 August 2022 (UTC)[reply]
@Bouzinac: Look at eg infoboxes on Commons, and the library they call on. Something like c:Category:Belvoir Castle can trace an entire chain of administrative units in its location line (and link them to Commons categories where available), even though P131 on the corresponding item only gives a value for the local parish. This could be extended to other properties with a place value. Jheald (talk) 10:44, 6 August 2022 (UTC)[reply]
Interesting. I tried to find where in the code did the Q816295#P131 be transformed into Belvoir, Melton, Leicestershire, Midlands de l'Est, Angleterre, Royaume-Uni ...? Bouzinac 💬●✒️●💛 11:42, 6 August 2022 (UTC)[reply]
Makes me think of Tagging for the renderer on OpenStreetMap. Don't. Fix your infobox. Multichill (talk) 17:26, 6 August 2022 (UTC)[reply]
People can't fix their infoboxes unless they know how to. Bouzinac would like to look at some existing code but has not found it yet. If you can help with that, please do. (I can't, unfortunately, because I also have no idea how/where it's done) - Nikki (talk) 00:11, 7 August 2022 (UTC)[reply]
It is in here: https://commons.wikimedia.org/wiki/Module:WikidataIB - Utility function number 25. But this function does not help with displaying the correct country for the specific time period when an event occured. Since that module can take into account qualifiers, it could possibly be added. Sotho Tal Ker (talk) 17:40, 7 August 2022 (UTC)[reply]
I indeed see a (very complicated) function location. What I was thinking about (but I'm not skilled enough in Lua...) is how to show a calculated continent (P30).
Let's say there is an infobox about rivers, eg that one https://fr.wikipedia.org/wiki/Module:Infobox/Rivi%C3%A8re.
How should the infobox be calculating what continent is the river in, as there are almost no direct P30 statements on rivers' items as many WD people did remove it from items ?
So that frwiki infobox does not show any continent eg in Veauvre whilst this one does Petite Rivière Saint-Jean (because of direct P30), the both having the same infobox module. Bouzinac 💬●✒️●💛 13:01, 8 August 2022 (UTC)[reply]
How should the infobox be calculating what continent is the river in, as there are almost no direct P30 statements on rivers' items as many WD people did remove it from items ?
The most obvious way would be to follow located in the administrative territorial entity (P131) until you find a value for continent (P30).
That being said, the semantics of all the properties should ideally be formally specified as part of an entailment regime for Wikidata, instead of having to code their semantics across numerous infobox modules. I hope that's on the development team's roadmap. Silver hr (talk) 19:31, 11 August 2022 (UTC)[reply]
@HarryNº2 Whether or not there is an article in a Wikipedia for a place is totally irrelevant to Wikidata as we can model it here independently of any articles and I'm surprised why you even are bringing it up here. Could you please expand on why you think that would have relevance? Ainali (talk) 19:18, 6 August 2022 (UTC)[reply]
The data are often taken from Wikipedia and are thus related. Moreover, I have only mentioned the German Wikipedia as an example in order to refer to the personal data there, see de:Hilfe:Personendaten. --HarryNº2 (talk) 19:34, 6 August 2022 (UTC)[reply]
@HarryNº2 Well, data should have external references and that is where the actual relation is. Wikipedia only acts like a middleman, and should be cut out of the information transaction if possible. So that argument falls flat to the ground. Ainali (talk) 07:52, 7 August 2022 (UTC)[reply]
Be realistic and look at the data sets for the countries, the information is mostly taken from the Wikipedia articles. That Potsdam today is in Brandenburg in Germany is undisputed. In 1933, Potsdam was in Prussia in the German Reich, that is also a fact. --HarryNº2 (talk) 08:04, 7 August 2022 (UTC)[reply]
The argument is that articles should have both location and country to speed access, else the system has to chase the tree though a hierachy of places. But for a qualifier like this, it does seem overkill, as we wont have searches on people dying in Austria. And for places switching countries, omission is better as you could use the date to deduce the country Linz was in at the time. Vicarage (talk) 18:02, 6 August 2022 (UTC)[reply]
It is redundant and unnecessary. Silver hr (talk) 18:50, 6 August 2022 (UTC)[reply]

Wikimedians with Commons Creator pages

I always see deletions of entries for Wikimedians with Commons Creator pages. I think we should keep people with Commons Creator pages. One day their images will fall into the public domain and be free from the restrictions of the creative commons license. The only way to track that, will be through their Wikidata entry which has information on birth and residence, to match them to an obituary when they die and calculate their post mortem auctoris (pma). Or is it so far into the future that Wikidata and Wiki Commons will not be around by then? For comparison, look at how many authors we have information on, where we only have a name, and no birth and death information. I think if contributors want to be identified by their real names and not their login ID, we should be tracking that. RAN (talk) 18:13, 6 August 2022 (UTC)[reply]

That’s not the only way, people do find out about the expiration of copyrights even without Wikidata. They have managed to do so for many decades.
In any case, we have discussed similar ideas many, many times. If we create a Wikidata item for every person that manages to create something on Commons, this would effectively mean that we could eliminate WD:N and accept uselessness of our data. We already tolerate a significant number of items about Wikimedians that are in violation of our own guidelines (mostly probably because no admin wants to be the bad guy). Let’s apply the same standard we use for people from other volunteer projects: “serious and publicly available references”. Self-reported information and meta stuff within Wikimedia project can never meet that criterion. --Emu (talk) 23:16, 6 August 2022 (UTC)[reply]
If having a Commons Creator page automatically means that we keep the page of a person, that would make it very easy for spammers to create a Common Creator page to get notability and the SEO guides will recommend doing so to get a Wikidata entry to stick. ChristianKl ❪✉❫ 07:59, 7 August 2022 (UTC)[reply]
Exactly. Lymantria (talk) 08:50, 7 August 2022 (UTC)[reply]
So you can then nominate things on Commons for deletion, then get things deleted here? It really isn't difficult to do. Thanks. Mike Peel (talk) 13:09, 7 August 2022 (UTC)[reply]
@Mike Peel: The amount of work a SEO person has to do to create a Common Creator page that won't get deleted when nominated for deletiong relatively small. ChristianKl ❪✉❫ 08:57, 8 August 2022 (UTC)[reply]
@ChristianKl: Not sure I understood, but a) it's not trivial, particularly discovering how to do so, and b) I would expect that it would be deleted quite quickly if it really is spam? Thanks. Mike Peel (talk) 09:56, 8 August 2022 (UTC)[reply]
Wikimedia Commons have massive backlogs. Assumption "would be deleted quite quickly if it really is spam" is wrong Mateusz Konieczny (talk) 10:48, 8 August 2022 (UTC)[reply]
@Mike_Peel: Discovering how to do so stays hard till one of the SEO people writes a guide of "Here's what you need to do to get on Wikidata" and people offer the service on Fiverr. ChristianKl ❪✉❫ 11:47, 8 August 2022 (UTC)[reply]
  • I think some nuance is missing here. It seems that the comments here are going for two extremes, neither of which will work:
    • If we have a blanket rule to keep all Wikidata items for creators with Commons creator pages, we have a big open door for spam.
    • If we have a blanket rule to delete all Wikidata items that rely on Commons creator pages for their Wikidata notability, we will break many Commons creator pages that pass Commons inclusion criteria.
    The solution will need to be somewhere in between: deletion requests should be handled on a case by case basis, and both Wikidata and Commons should accept such deletion requests. The decision to keep or delete the Wikidata item / Commons creator page should consider incoming links to both the item and the page. The outcome of a deletion discussion on Wikidata or Commons should inform but not prejudice the outcome of the other deletion discussion. (I came here off the back of an off-wiki discussion with Mike Peel.) Deryck Chan (talk) 11:11, 8 August 2022 (UTC)[reply]
    I just looked at Commons own description about who is supposed to get a creator page:
    "Anybody who is an author or creator of works hosted on Commons and meets notability requirements for Wikidata items, Commons categories or for Wikipedia articles. In most cases creator templates should be linked with Wikidata items."
    If there's no external link to a commons category or a Wikipedia article and we think that an item doesn't qualify under Wikidata notability requirements, any commons creators page that exists seems to be in violation of the Commons policy. ChristianKl ❪✉❫ 11:57, 8 August 2022 (UTC)[reply]
    You wrote: "I just looked at Commons own description", but that is marked as a proposal and doesn't have the authority of Wikilaw. Now is the time to discuss our options. Some people are worried that having a Creator_template/Wikidata_entry pair will become a backdoor for spammers and bots. What is we had a minimum number of Commons entries before you got a Creator_template? We often encounter people loading a single image of themselves and creating a wikidata entry, but they quickly get deleted. --RAN (talk) 20:00, 8 August 2022 (UTC)[reply]
    Wouldn’t that result in even more spam on Commons (if you need 50 pictures, well, just upload 50 pictures)?
    In any case, this doesn’t solve the problem that we would favor Wikimedians and effectively hand out Wikidata items for contributions. As I have said before, this is tantamount to nepotism. It hurts our credibility and also our data quality because most information on Wikimedians is 100% self-reported. This kind of data is problematic in many ways. --Emu (talk) 20:15, 8 August 2022 (UTC)[reply]
Every movie I have seen lists all the production people, I have never thought of it as a form of nepotism. --RAN (talk) 05:38, 12 August 2022 (UTC)[reply]
We do, too. At the appropriate location: In the history. --Emu (talk) 05:43, 12 August 2022 (UTC)[reply]
  • If you would limit the items to non-self reported data, that may help? If death dates are not publicly reported someplace, it would be tricky for privacy reasons anyway. If you use the same logic across Wikidata that may have wider implications of course... Effeietsanders (talk) 20:59, 8 August 2022 (UTC)[reply]
    @Effeietsanders You mean items with little more than instance of (P31)human (Q5)? Hm, that kinda might defeat the purpose of Wikidata. I’m not sure we have to keep this kind of information on a general-purpose database anyway. If I understand MisterSynergy correctly, structured information of Wikimedians could be stored in another database (yet to be developed). The alternative would be to allow only well-sourced items about Wikimedians. (Sidenote: It’s probably not that hard for a prolific Wikimedian to give an interview in the local newspaper about their contributions – at least in some parts of the world. If the newspaper is serious, this would create WD:N #2 notability anyway. Not to mention authority records, etc.). --Emu (talk) 22:18, 8 August 2022 (UTC)[reply]
    Note that there is no need to develop anything new, Commons already has its own wikibase instance, where structured information about (non-notable) authors can be stored.--Jklamo (talk) 08:21, 10 August 2022 (UTC)[reply]
    This sounds like the solution. Commons has its own rules about notability and its own Wikibase instance where it can keep structured data about things it finds notable. Win-win. Silver hr (talk) 16:41, 11 August 2022 (UTC)[reply]
    @RAN I don’t know if that’s true but this seems to be a solution for you copyright expiry problems? --Emu (talk) 10:22, 13 August 2022 (UTC)[reply]
    Maybe XX uploads AND accound old YY years. This would eliminate contemporary spammers (Item about creator will be notable after YY years ;-) JAn Dudík (talk) 21:04, 8 August 2022 (UTC)[reply]
    If it's not a policy and Commons currently lacks a policy to decide who deserves a Commons creator page that would be a strong reason currently not to use that information for our decisions about notability at Wikidata. ChristianKl ❪✉❫ 07:22, 9 August 2022 (UTC)[reply]
    @ChristianKl: You've raised a great point. We can't let "fulfils an interwiki structural need" be an unlimited notability criterion. WD:N should make an exception for situations where it is found that the concerned interwiki link goes to a part of a sister project with zero inclusion criterion (or zero enforcement thereof), and deletion from Wikidata should be permitted. Deryck Chan (talk) 22:00, 10 August 2022 (UTC)[reply]
    I do see "fulfills a structural" need as a statement that's about a structural need of Wikidata. Otherwise it wouldn't make sense to have the point about sitelinks separately. ChristianKl ❪✉❫ 08:28, 13 August 2022 (UTC)[reply]

Wikidata weekly summary #532

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Upcoming
      • Wikimania 2022, August 11 to 14, online event. The Hackathon will take place August 12-14. On this page you can find a summary of sessions and community gatherings related to Wikidata and Wikibase.
      • Next Linked Data for Libraries LD4 Wikidata Affinity Group call August 9, 2022: Pieter Vander Vennet on MapComplete, a thematic OpenStreetMap viewer and editor which uses species, language, and image data from Wikidata. Agenda.
      • The Wikimania Hackathon starts next Friday, August 16-22! There are still lots of spots in the schedule to add your Wikidata related sessions or project ideas (anyone can present a session)
    • Ongoing
      • Wikimedia Indonesia's Wikidata edit-a-thon (datathon) for the 77th anniversary of the Indnesian Independence Day started on 5th August and will be held until 12th August. Participants are instructed to edit items containing the statement country of origin (P495): Indonesia (Q252).
      • Toolhub is a catalog of 1500+ tools used every day in a wide variety of workflows across many Wiki projects. We are currently improving the search functionality and need your input – whether you are already familiar with Toolhub or not. Please take 5-10 minutes to leave feedback.
    • Ongoing
      • Weekly Lexemes Challenge #53, Sheep
    • Past
      • First online meet-up fully organized by volunteers of the Indonesian Wikidata Community has been held on 30th July where we edited items on Indonesian ethnic groups.
  • Tool of the week
    • Wiki tools - adds dozens of Wikipedia and Wikidata functions to your Google sheets.
  • Development
    • Lexicographical data:
      • Continuing to address feedback from the testing (e.g. phab:T312292, phab:T313113, phab:T313466)
      • We have pushed back replacing Special:NewLexeme with the new Special:NewLexemeAlpha a bit to address more of the testing feedback.
    • Continuing to tackle allowing sitelinks to redirects under some circumstances (phab:T278962)
    • REST API:
      • Finishing up the endpoints for removing and replacing statements and adding authentication and authorization to them
      • Looking into feedback from first testing

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

Stale import from wikipedia?

https://m.wikidata.org/wiki/Q16972633 claims it's named after a town in Japan but the cited section claims otherwise. Was this imported automatically at some point and is there some facility to quality check this? Nivekuil (talk) 22:59, 9 August 2022 (UTC)[reply]

The imported claim value had been changed by an IP user here. Now undone. —MisterSynergy (talk) 23:05, 9 August 2022 (UTC)[reply]

Functional program data type

For data such as power series, there is currently only mathematical notation supported to represent these, and unfortunately these are not strictly machine-interpretable; notations such as superscripts and subscripts are ambiguous, and have different meanings in different contexts. For algorithms, there is nothing other than string types, and including arbitrary code fragments in general-purpose programming languages in Wikidata would be actively dangerous, as people will be tempted to execute them, and code in pseudocode is less than useful, as it is not machine-interpretable or capable of being manipulated by systems such as program provers.

Functional programs in a LISP-like language such as Scheme are unambiguous, and meaningful for machine interpretation. If they are constrained to a safe subset of those languages, they are also safe to interpret directly, offering other potential uses, such as following the general approach of Structure and Interpretation of Computer Programs and Structure and Interpretation of Classical Mechanics. They could also be converted into TeX notation automatically, in much the same was a GNU Lilypond notation can be converted into MIDI or sound files.

Implementation would be relatively simple: all that is needed is an S-expression parser with an post-pass that checks the parsed forms against a allow-list of symbols and syntax productions. Although the general case of proving safety (including, of course, program termination!) is insoluble, we don't need to be able to define all Turing-complete functions, just relatively small subsets (for example, consider only a subset restricted to numbers and keywords such as let, letrec, lambda, *, -, +, /, expt, one-letter variable names, cons, first, last, simple conditionals and logic expressions -- trivially safe). I'd be happy to write the parser and safety-checker, in any reasonable language of the dev team's choice, if the proposal is accepted.

Note also that the programs can also be pretty-printed for output.

Oh, and lazy semantics (such as in https://docs.racket-lang.org/lazy/index.html) can be used to represent infinite series and so on... The Anome (talk) 11:43, 10 August 2022 (UTC)[reply]

WikiFunctions is currently in development. ChristianKl ❪✉❫ 15:00, 10 August 2022 (UTC)[reply]
@ChristianKl: Sounds fantastic. Will it eventually be fully integrated with Wikidata? The Anome (talk) 13:57, 14 August 2022 (UTC)[reply]

How to express that an entity (technology, language etc. etc. ) was used during a period of the history?

I would like to express that an entity was used during a period of the history. For instance, that lead tin yellow pigment was used from the 13th century until 18th century. I could use https://www.wikidata.org/wiki/Property:P2754 but for the end of the period I could only find discontinued https://www.wikidata.org/wiki/Property:P2669 I was wondering if I could use something more general like inception for the start, so I can use it also for other entities like for instance uncial script https://www.wikidata.org/wiki/Q784235. MRCGCM53 (talk) 11:55, 10 August 2022 (UTC)[reply]

I think start time (P580) and end time (P582) would be appropriate. Silver hr (talk) 16:57, 10 August 2022 (UTC)[reply]

How do you change your default observations from Cc-by-NC to cc0 or cc-by-Sa

Asking for iNaturalist iNaturalist (Q16958215) users, thks Jane023 (talk) 14:07, 10 August 2022 (UTC)[reply]

It is unclear what you're asking. In the absense of a clarification, I can only point you to the text at the bottom of every page: All structured data from the main, Property, Lexeme, and EntitySchema namespaces is available under the Creative Commons CC0 License; text in the other namespaces is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. Silver hr (talk) 15:38, 13 August 2022 (UTC)[reply]

items for individual birth / death certificates / registries

Notability of individual birth / death certificates

After several months of open discussion, the RfD for five items at Wikidata:Requests_for_deletions#birth_certificates still aren’t resolved:

Users have requested a general discussion that doesn’t seem to have happened yet, so let’s have it! Personally, I would limit the notability of items like these to exceptions like Barack Obama birth certificate (Q14527788).

ping User:Nomen ad hoc, RAN, VIGNERON, Hsarrazin --Emu (talk) 15:58, 10 August 2022 (UTC)[reply]

To me it seems they are notable if they are used on another item via the structural need provision of our policies. Wikibase works in a way where it's useful to have information spread over multiple items instead of having a lot of information in a single item. ChristianKl ❪✉❫ 16:15, 10 August 2022 (UTC)[reply]
I don't think structural need applies here because the item isn't needed to be able add the reference. I don't think we should create an item for any/every document used as a reference. I would limit it to cases where lots of items reference the same document and there is a clear benefit to having a separate item that outweighs the downsides of having a separate item. - Nikki (talk) 10:22, 14 August 2022 (UTC)[reply]
  •  Keep I don't think we need a Wikidata entry for every document stored at Commons, but I can see the use for some, so that we can use them as references for statements like birth and death dates. We aren't being overwhelmed with them, we have 5, and we should be experimenting with different ways of referencing statements. I have seen examples of people adding the image of the birth and death certificate as a reference, and I have seen more like the above, where they create a Wikidata entry, both are good experiments. --RAN (talk) 05:31, 12 August 2022 (UTC)[reply]

Notability of individual registries

Connected with those cases but also different are other cases such as Berlin death register (Q104508368) or death record of the Lutheran City Church of Vienna (Q99896173) (see this query – they aren’t about individual certificates but rather about (death registry of a specific church or within a city). Most were created by myself before this discussion. The modeling is bad at the moment, but before fixing it to something like in birth registry of the Jewish Community of Vienna (Q99662601), I’d like to have some input. Should we keep those? Should we get rid of them? --Emu (talk) 15:58, 10 August 2022 (UTC)[reply]

Ping Sapfan, Jura, Jc3s5h from the last discussion. To be perfectly honest, I don’t fully understand if you agreed on an all encompassing back then … --Emu (talk) 16:09, 10 August 2022 (UTC)[reply]

Wikidata integration in OpenRefine: could this be your project?

Hello Wikidata community!

For the past five years I have been maintaining the Wikidata integration in OpenRefine. I am really grateful for the amazing things the community has done with it. Still, there are plenty of things to improve in this integration.

After all these years, I now want to focus my attention in other building sites of OpenRefine. The reconciliation functionality is calling for many improvements. I also want to continue my work on the scalability and reproducibility of OpenRefine. Those are features which will of course benefit the Wikimedia community, but also users coming from other horizons.

Therefore I am looking for someone else to maintain the Wikibase integration in OpenRefine. This means that I am willing to really let go of it and let someone else be in charge. Of course I would still help onboard new developers and keep reviewing pull requests in this area for a while, but I will soon stop developing new features and fixing bugs there myself. This applies to the following projects:

I honestly think this is an enjoyable thing to be in charge of! Among the perks:

  • You get to work on a project that is used by a lot of people, and that's really gratifying!
  • The OpenRefine team is small, so expect low bureaucracy and a lot of freedom. It is however full of passionate Wikimedians who will support your work: Spinster, Antoine2711, Loz.ross, Thadguidry, Owenpatel, Abbe98, Ainali… and myself!
  • I claim we are now pretty good at onboarding people, thanks to various rounds of Outreachy and Google Summer of Code internships, among others
  • There are opportunities to get your work funded, for instance from the Wikimedia Foundation, Wikimedia chapters, or other Wikibase stakeholders.

So the floor is yours! Do you dream about a five-star lexeme support in OpenRefine? Do you think a ShEx integration is overdue? Or maybe you just want to move that crucial button somewhere more accessible and also fix the layout of this dialog? Be my guest! You don't need to be a Java wizard or to write Javascript like you breathe - if you already have programming experience, you will be able to pick this up as you go.

Feel free to respond here, on OpenRefine's dev mailing list, or even by opening issues and pull requests already! Also, Antoine2711 and I are hosting a session at the Wikimania hackathon to give you an overview of the situation of Wikidata integration in OpenRefine - join us there! − Pintoch (talk) 19:22, 10 August 2022 (UTC)[reply]

Question about P968

Hello there, Wikidata editors.

I am new to Wikidata and don't have much experience, but I have a question.

Shouldn't there be a property formatter URL mailto:$1? Why do I have to write mailto: before the email address? I am new here, correct me if I am wrong, QuickQuokka (talk) 23:30, 10 August 2022 (UTC)[reply]

Also, shouldn't it use the official RFC 5322 email regex, (?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\]) or official W3C RegEx, /^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/ QuickQuokka (talk) 23:48, 10 August 2022 (UTC)[reply]
As to the first question/suggestion, it has been discussed but failed to raise any interest; subsequently an objection was raised that all consumers of WD P968 data - such as language wiki templates - would need to be changed should WD change its data format. See property talk & an RfC. --Tagishsimon (talk) 00:04, 11 August 2022 (UTC)[reply]
@Tagishsimon: Again, I am new to Wikidata and this may be a stupid question: Is it possible to use 1 formatter url if it matches the current regex and another if it uses my proposed regex? QuickQuokka (talk) 08:50, 11 August 2022 (UTC)[reply]
No, not possible to do that afaik. --Tagishsimon (talk) 08:56, 11 August 2022 (UTC)[reply]
I don't see that RFC 5322 specifies a regular expression directly, however, the W3C page does, and obviously we should defer to the standard instead of making up our own email regex. Silver hr (talk) 15:59, 13 August 2022 (UTC)[reply]
In my opinion, we shouldn't keep an inferior solution just because some work is needed to adapt to a better solution, so I would support this change if there is a good reason for it. At first glance, the mailto: part seems redundant. Silver hr (talk) 15:53, 13 August 2022 (UTC)[reply]

Undeletion request for Alan MacMasters (Q15994606)

I recently added three BBC references to this item. It's notable because it's a hoax Piecesofuk (talk) 06:24, 12 August 2022 (UTC)[reply]

Ping Ymblanter as deleting admin. --Emu (talk) 06:44, 12 August 2022 (UTC)[reply]
The only sitelink, the English Wikipedia one, was deleted after discussion as a hoax. I would recommend to try undeleting it there first, we are not in a good position to investigate references. Ymblanter (talk) 06:52, 12 August 2022 (UTC)[reply]
BBC References: https://www.bbc.co.uk/programmes/articles/1D0xzxYf9ykH9gcYp9BnYW4/5-everyday-objects-with-curious-histories, https://www.bbc.co.uk/bitesize/topics/zxwxvcw/articles/zjm4bdm, https://www.bbc.co.uk/newsround/56192812; The Scotsman: https://www.scotsman.com/lifestyle/food-and-drink/scottish-fact-week-electric-toaster-1548627; Daily Mirror: https://www.mirror.co.uk/news/uk-news/made-in-the-uk-the-life-changing-everyday-innovations-1294240
There'e plenty more. They're all repeating the hoax which apparently originated in the Wikipedia article. The item needs to be undeleted and flagged as a hoax to 1) record the fact that this is a hoax and help prevent it from being re-added to Wikidata/Wikipedia and 2) record that all these supposedly reliable sources were taken in by a fake Wikipedia article Piecesofuk (talk) 07:15, 12 August 2022 (UTC)[reply]
I would say the item should be undeleted, and possibly flagged as an instance of human whose existence is disputed (Q21070568). Do we have credible sources confirming it is in fact a hoax? To be honest, just because a gang of Wikipedians declares something false or a hoax, that doesn't mean it's necessarily so (this should be blatantly obvious), and obviously things can be Wikidata notable even if not Wikipedia notable. There's also a conceptual difference between a person being a hoax and an alleged picture of them being a hoax, which appears more likely. In addition to the news items above, one can find claims of an Alan MacMasters having invented the toaster in a 2015 book published by Amberley Publishing (Q47653625) and a 2016 book published by Dorling Kindersley (Q1245484). Now, since all of these sources are younger than the alleged hoax, it's quite possible that subsequent sources have perpetuated a fiction that originated on Wikipedia. That would be unfortunate. But Mr. MacMasters, real or not, remains a clearly identifiable conceptual or material entity that can be described using serious and publicly available references, and so meets Wikidata's lilliputian notability threshold. And I don't think I've ever seen anyone on Wikidata argue that truth is more important than verifiability (although that might be nice). Wikidata fundamentally ONLY cares about data, good or bad. A pile of dog turds with an external identifier is grounds for import. -Animalparty (talk) 07:45, 12 August 2022 (UTC)[reply]
Not sure how credible this site is but this was posted yesterday https://wikipediocracy.com/2022/08/11/wikipedias-credibility-is-toast/. I think we should have an item "longstanding Wikipedia hoax" and anything listed at https://en.wikipedia.org/wiki/Wikipedia:List_of_hoaxes_on_Wikipedia should be an instance of that; I expect most of these have been deleted from Wikidata, might be worth looking at undeleting them? Piecesofuk (talk) 10:02, 12 August 2022 (UTC)[reply]
Also I couldn't find any record of Alan Macmasters in any newspaper archives or genealogy websites, as far as I can see he never existed. Piecesofuk (talk) 10:04, 12 August 2022 (UTC)[reply]
I restored the item and changed the first property.--Ymblanter (talk) 19:14, 12 August 2022 (UTC)[reply]
Thanks for that. However, none of the original references support the claim of "human who may be fictional" (they all presume the human to be real). I added hoax (Q190084) based on this posting, and there may be more reliable press in the near future to plant a further nail in the coffin of this likely hoax. Other claims like humanness or birth date should probably be deprecated and/or qualified appropriately, so that it's clear this was a hoax that several credible sources perpetuated as real. -Animalparty (talk) 20:51, 12 August 2022 (UTC)[reply]
Thanks for undeleting. I agree that the references support the claim that he was an instance of human and not fictional human. Every statement apart from the hoax statement should be deprecated, not sure what an appropriate reason for deprecation should be, is there an existing one or should a new one be created? Piecesofuk (talk) 04:35, 13 August 2022 (UTC)[reply]

decentralized identification products

i'm working on a review of decentralized identification products https://www.wikidata.org/wiki/Q95350968 and would like to get some help

https://docs.google.com/document/d/1AaqMxO467xzg7_Z7bMen8I75XJgmMPheaf-QcZtIyvE/edit#

we've been working on a schema and have a list of open source products, would be great to have a pro help us with this

Proposed Schema: Transferable or delegatable? Pseudonymous, KYC etc… : type of classification Network availability : eth, btc, sol etc Token Utility: description Dynamic metadata : y/n Supply limit: is there one y/n if yes how much Decentralized metadata: y/n Unique per wallet : y/n Known integrations : list Security Audit Status : date Repository : url Wallet integration : list Proof mechanism : proof of ??? Ansondparker (talk) 13:55, 12 August 2022 (UTC)[reply]

Wikidata works in terms of properties and not in terms of whatever natural language terms you can think of for your schema. If you want to engage with Wikidata it makes sense to read through our existing properties and try to express what you want to express in those. ChristianKl ❪✉❫ 09:00, 13 August 2022 (UTC)[reply]

How does merging from a connected Wiki work?

The Viscount Who Loved Me (Q112061793) and The Viscount Who Loved Me (Q111190660) have Tag: Sitelink Change from Connected Wiki. What creates that merge? Is there a tool that's running on other Wiki's that does unclean merges on Wikidata? ChristianKl ❪✉❫ 08:10, 13 August 2022 (UTC)[reply]

How to properly reference the fact the height of Marcus Rashford is disputed

On 14 September 2019 at about 12:00 local Q5214544 (Daniel Meirion Walker) on Q5465835 (Football Focus) claimed the height given on the English Wikipedia of 180cm (or 5' 11" / 180cm) did not seem credible. With regards to a statement of his height (P2048), 180cm, which is referenced, I have managed to add a property P1310 that this height is disputed, but my expertised does not go beyond how to model or add a reference to the P1310 property. Before I make a complete mess of this it is time for me to back off and ask for help. thankyou. Djm-leighpark (talk) 09:00, 13 August 2022 (UTC)[reply]

@Djm-leighpark: supports qualifier (P10551) is the property you are looking for, I guess. I would model this like this: Q22951255#P2048 (reference section) - Valentina.Anitnelav (talk) 10:12, 14 August 2022 (UTC)[reply]
Thanks for sorting that. Djm-leighpark (talk) 14:05, 14 August 2022 (UTC)[reply]

SPARQL query times out

The following simple SPARQL query succeeds: 

SELECT ?item ?itemLabel 
WHERE 
{
  ?item wdt:P31 wd:Q55983715.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

However, I want to further constrain the results to instances of Q729 or one of its subclasses: 

SELECT ?item ?itemLabel 
WHERE 
{
  ?item wdt:P31 wd:Q55983715;
        wdt:P31/wdt:P279* wd:Q729.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

This query times out. What am I doing wrong? --2A02:8108:50BF:C694:9542:45CE:E09E:3014 21:28, 13 August 2022 (UTC)[reply]

1. Asking the question on the wrong forum - use Wikidata:Request a query for SPARQL queries 2. The optimizer sometimes makes poor choices and needs to be given a hint or two; see Wikidata:SPARQL query service/query optimization:
SELECT ?item ?itemLabel 
WHERE 
{
  ?item wdt:P31 wd:Q55983715. hint:Prior hint:runFirst true.
  ?item wdt:P31/wdt:P279* wd:Q729. hint:Prior hint:gearing "forward".
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!
--Tagishsimon (talk) 21:33, 13 August 2022 (UTC)[reply]
Thank you! – Unfortunately I find it very cumbersome to find the right forum here at Wikidata (it’s even tricky to find Project chat given that searches prefer items over meta pages). --2A02:8108:50BF:C694:9542:45CE:E09E:3014 21:39, 13 August 2022 (UTC)[reply]
No problem. If you had an account you could watchlist them both, but if you want to continue as an IP user - which is fine - then not so much. Project chat is the third link on the left side menu (I guess, for computer users, maybe not mobile.) Request a Query slightly more obscure, navigation-wise. --Tagishsimon (talk) 21:43, 13 August 2022 (UTC)[reply]

Removing an Identifier for unscientific reasons

Hey everyone. I am just importing an Arabic Wikipedia discussion, w:ar:ويكيبيديا:الميدان/سياسات#ضبط استنادي, to here, where it's related. An Arabic Wikipedia user requested that. Briefly : "Do we can remove National Library of Israel J9U ID from Identifiers of the articles related to Arab people?" Looks like they resent when see that ID in Authority control of Arab people, or find it mocking. I don't know why exactly, but looks like it related to 74 years, 2 months, 3 weeks and 5 days of mutual conflict, or w:International recognition of Israel? Anyways, It seems unscientific reason. I will translate any answer, or ping that user to see comments. With Regards. Ruwaym (talk) 00:48, 14 August 2022 (UTC)[reply]

We cannot. Whatever is going on between Israel and Arabic countries, it is not a conflict which should influence WDs data. Arabic wikipedia is quite capable of taking decisions about what wikidata they import into their wikipedia, without seeking to influence the data held at source. It would, obvs, be appalling were Arabic wikipedia to start censoring Israeli IDs, but whatever, it is a decision for them. WD absolutely will not interest itself in the user's request, which is completely antithetical to pretty much everything the wikimedia movement stands for. --Tagishsimon (talk) 01:45, 14 August 2022 (UTC)[reply]
Arab Wikipedia is free to decide in their authority control template which properties they want to import and could also write logic to make that decision based on other Wikidata properties to make the template behave differently for Arab people.
Wikidata itself is pluralistic and won't remove data on those grounds. ChristianKl ❪✉❫ 08:26, 14 August 2022 (UTC)[reply]
Hello everyone,
I am an admin from Arabic Wikipedia.
In the Arabic version, we do not add or remove information based on personal opinions. This is a pillar, and it is out of the discussion. Any Israelian-sourced information is welcomed as long as its source is reliable.
The person who proposed this got the following answer:
Hi Ramy,

Just a comment that what you are proposing is contrary and unacceptable in Arabic Wikipedia, because it collides with one of the five pillars of the encyclopedia: Wikipedia adopts a neutral point of view.

Please note that we, in the Arabic Wikipedia, do not consider editors's opinions or their orientations regarding conflicts and disputes, whatever their form: political, religious, ethnic, cultural, economic or sportive. We simply present the well-documented information with its sources (except for fringe theories).

So, if you have a personal opinion of a conflict, whatever that opinion is, whatever that conflict is, Wikipedia is not the place for it. We simply don't discuss our personal thoughts or allow them to influence our contributions here.
I am just wondering why Ruwaym did not translate this. I am also referring to the block he got on English Wikipedia for "Disruptive editing: competence issues as well as repeated ethno-nationalist aggression and personal attack". He is also got blocked in Arabic Wikipedias (twice) for dishonesty when delivering others' opinions, exactly as he did above.--Michel Bakni (talk) 10:42, 14 August 2022 (UTC)[reply]
@ChristianKl @Tagishsimon Do i said i translated anything from anyone? Do i said i repsenet the Arabic Wikipedia? Do i said at all I'm an "Arab" or "Jewish"? Do i did any wrong? Wait, there is a value judgment based on block log. Do you know Michel Bakni accused me for "Lack of honesty and distorting the image of the Arab community in a foreign forum". Do you know it's not the first time that Micheal Bakni falsely accused me? Ruwaym (talk) 14:36, 14 August 2022 (UTC)[reply]
Michel Bakni is right on this. Your use of "they" made it seem like the discussion has already reached consensus on Arabic Wikipedia. Moreover, the discussion has nothing to do with Wikidata. Every language project is free to display whatever identifiers they want from Wikidata. Please stop this meaningless discussion here as it has nothing to do with Wikidata. Vojtěch Dostál (talk) 15:07, 14 August 2022 (UTC)[reply]
Yeah, Please stop unscientific methods of talking. Ruwaym (talk) 15:46, 14 August 2022 (UTC)[reply]
This "meaningless " discusion is done some hours ago. I got infinite block in Ar wk because of "Lack of honesty and distorting the image of the Arab community in a foreign forum", and labled as a "vandalism-only account". Time to celebrate it! Ruwaym (talk) 18:49, 14 August 2022 (UTC)[reply]
@Michel Bakni You requested blocking me for ininite and you said w:ar:ويكيبيديا:إخطار الإداريين/منع/الحالية#منع: Ruwaym "...In an irrelevant foreign forum, Wikidata, which resulted in a clear insult to the image of the Arab community as a whole, and the appearance of the Arabic version of the encyclopedia in a fanatical and unacceptable appearance (and this can be seen from the responses to his question)." Do you think I'ts not a clear insult or a fanatical and unacceptable behavior if this "foreign forum" knows i got blocked infinite just because of this "meaningless " discusion? and your prejudice, value judgment and cross-wiki hounding users? Why a user blocked in Ar wk because of a Wikidata talk?!
@-revi, Nikki, Mahir256: Feel free to block me here too or ask a global lock/block for my account. I am R W of telegram groups. Ruwaym (talk) 10:15, 15 August 2022 (UTC)[reply]

Merge

Please, merge Q28874524 and Q3181354. There are 2 name of 1 species of bird. Thanks. Zagrebin Ilya (Talk page) 07:48, 14 August 2022 (UTC)[reply]

Merging is not appropriate for such pairs of homotypic names. See Wikidata:WikiProject Taxonomy/Tutorial § Homotypic names for details. William Avery (talk) 12:04, 14 August 2022 (UTC)[reply]
William Avery, OK. Zagrebin Ilya (Talk page) 08:14, 15 August 2022 (UTC)[reply]

How to get the langwiki-link from QID?

Given a QID, how can I retrieve its langwiki link? For example, phosphorus (Q674) on dewiki is de:Phosphor. ])] ] DePiep (talk) 08:37, 15 August 2022 (UTC)[reply]

Something like one of these; depends if you are interested in de wiki only, or all language wikis.
SELECT ?item ?itemLabel ?sitelink ?article WHERE 
{
  VALUES ?item {wd:Q674}
  ?article schema:about ?item ;
  schema:isPartOf <https://de.wikipedia.org/> ; 
  schema:name ?sitelink .
  SERVICE wikibase:label { bd:serviceParam wikibase:language 'en' }
}
Try it! 
SELECT ?item ?itemLabel ?lang ?sitelink ?article WHERE 
{
  VALUES ?item {wd:Q674}
  ?article schema:about ?item ;
  schema:inLanguage ?lang ; 
  schema:name ?sitelink ;
  schema:isPartOf/wikibase:wikiGroup "wikipedia" .
  SERVICE wikibase:label { bd:serviceParam wikibase:language 'en' }
}
Try it!
--Tagishsimon (talk) 10:09, 15 August 2022 (UTC)[reply]
You can also simply parse https://www.wikidata.org/wiki/Special:EntityData/Q674.json and extract it from there. In the future, the REST API might perhaps provide direct access—but it's not ready yet, see Wikidata:REST API feedback round. —MisterSynergy (talk) 10:31, 15 August 2022 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=1704549920"