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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Please use {{Q}} or {{P}}, the first time you mention an item, or property, respectively.
Requests for deletions can be made here. Merging instructions can be found here.
IRC channel: #wikidataconnect
Wikidata Telegram group
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.

Wikidata:Requests for comment/General semi protection for all property pages partially closed

I have closed the above RfC as consensus to semi-protect all properties. Currently, all properties older than a year can (and should) be semi-protected. However, I feel that a proposal to have a grace period between creation and protection of a property (which I now arbitrarily set to a year) has not been sufficiently explored. I opened a new section on this RfC in which I request all of you to come up with the ideas on the duration of this grace period. Thank you in advance.--Ymblanter (talk) 20:02, 25 September 2020 (UTC)[reply]

Now closed. All property pages must be semi-protected. I assume this will be realized in an automatic regime via the Phabricator ticket which has already been open.--Ymblanter (talk) 20:55, 2 October 2020 (UTC)[reply]

VIAF and KrBot

This is potentially a serious problem. You might recall a discussion (here for one) about how best to to indicate that VIAF clusters contain authority records for multiple different people, and how best to stop bots from taking those VIAF clusters as reason to add the authority IDs to the wrong Wikidata items. We settled on putting the erroneous IDs in the item with a deprecated rank in hope this would block the bots from adding them again. But it doesn't seem to work, at least in the case of KrBot. Have a look at the history of James B. Baker (Q96925509) (silviculturist) and James B. Baker (Q60438918) (architect). Not only did KrBot re-add the deprecated VIAF ID, but worse, the confusion seems to have travelled back to VIAF again. Earlier this summer, VIAF separated out the architect's Getty ID from the silviculturist's LoC ID, but now they've combined them again. I am having a hard time figuring out what exactly the bots did to VIAF, but it anyhow appears that our attempts to be a source of correct and clear data for other authorities may not be working. There can't be unrestricted bidirectional bot-editing, because then bots "correct" Record B according to the erroneous Record A and take the second version of Record B as confirmation that Record A is correct and if someone fixes Record A, they "correct" Record A according to Record B, and and and — Levana Taylor (talk) 15:37, 29 September 2020 (UTC)[reply]

Can you check with Ivan? I think it should have ignored the deprecated statement. --- Jura 15:49, 29 September 2020 (UTC)[reply]
The problem's not just KrBot really -- that isn't what's editing VIAF, is it? Even if we figure out what happened in this case, what's to stop it happening in some other form? We need to block bidirectionality and I'm not sure that deprecated rank does that effectively. — Levana Taylor (talk) 15:55, 29 September 2020 (UTC)[reply]
If I understand you the issue is that KrBot doesn't check for deprecated entries before writing back. BrokenSegue (talk) 15:57, 29 September 2020 (UTC)[reply]
maybe we need a software change to prevent bots from adding entries that already exist and are deprecated? Optimally the authors of these bots would be "doing the right thing" and we would have common software libraries that make doing the right thing the default. Looking at KrBot it seems they haven't actually been approved to do what they are doing? I thought bots needed approval per-task? Why did @Ivan A. Krestinin: not need such re-approval. Also, the lack of open source code for this and similar bots makes checking they are doing the right thing hard. BrokenSegue (talk) 15:57, 29 September 2020 (UTC)[reply]
If a change is needed at VIAF, it's something that needs to be discussed with them. Still, I don't quite get why you add conflated identifiers to a clean item. This specifically not what Help:Conflation_of_two_people#Keep suggests to do. --- Jura 16:00, 29 September 2020 (UTC)[reply]
Adding the conflated identifiers, deprecated, was an attempt at a kluge solution to stop bots adding them -- suggested in the previous discussion but apparently not the right answer. — Levana Taylor (talk) 16:04, 29 September 2020 (UTC)[reply]
If you think Help:Conflation_of_two_people should be revised, please suggest updates. If you follow some other approach, you can just hope VIAF and bot operators guess it, but that is somewhat unlikely. --- Jura 16:08, 29 September 2020 (UTC)[reply]
Oh, I agree. Luckily the proposal from the previous discussion hasn't been used much yet. The question is what to do instead. — Levana Taylor (talk) 16:12, 29 September 2020 (UTC)[reply]
VIAF bots are unlikely to work with your kludges nor should they rely on emails from Wikidata contributors .. Strange that people suggested that approach to you while I think it's known that it isn't working. --- Jura 16:27, 29 September 2020 (UTC)[reply]
Help:Conflation of two people doesn’t necessarily apply here as it handles cases of Wikidata entries that are conflated and need to be untangled. Generally, it is useful information to know that an identifier appears to be about a given person but really is not, so the deprecation serves a purpose beyond locking out bots. VIAF is a special case, though, I stopped to try to make VIAF happy as it is too erratic. The time is better spent trying to correct other identifiers (that mostly aren’t that much conflated which makes flagging the odd one out even more useful). --Emu (talk) 20:05, 29 September 2020 (UTC)[reply]


Bots and circularity

Could there be a hand-setting that means "I notice there are errors in external authorities' values for this statement, I have made Wikidata correct to the best of my ability, and I am now blocking bots from changing it on the basis of those external authorities" -- i.e. a "human editing only" setting? — Levana Taylor (talk) 16:21, 29 September 2020 (UTC)[reply]

Although that still isn't a general solution to the problem of bidirectional bot editing. Let me put this another way: If Wikidata bots took data from elsewhere but others didn't take data from us, we'd constantly be fighting errors but at least we wouldn't be the means of propagating those errors back to external sources. Conversely, if we didn't take data from outside but others took from us, we'd have a smaller dataset but the others could rely on us to try to make it correct. Whereas if the dataflow is both ways, not only do errors go round and round forever, but no one knows who to rely on. Being able to manually block the back-and-forth in specific cases would be better than nothing. — Levana Taylor (talk) 17:26, 29 September 2020 (UTC)[reply]

Yet further thought: We don't want to have a blanket ban on Wikidata taking any data from external sources that in turn take data from Wikidata, because those external sources in many cases have multiple ways of getting information and contain a lot that is useful for Wikidata. But would it be a good idea to find out at least some of the major ones that use Wikidata as a source, fr'ex VIAF, and ban bot imports from them altogrther, rather than just case by case like I suggested in the paragraphs above? — Levana Taylor (talk)

@Levana Taylor: That's throwing out the baby with the bathwater. There is a huge amount of valuable information on VIAF etc that we don't have, that we should import. The problem is making sure that information doesn't get re-imported that has already been identified as incorrect. The way to do that is, first, to make sure that information that is incorrect but widespread should be visible here and marked as deprecated (ideally with a reason spelling out why); and, second, to require the major bot platforms not to add a statement to an item, if the statement is already here with deprecated rank. Jheald (talk) 19:38, 29 September 2020 (UTC)[reply]
But above, Jura was arguing that adding incorrect external identifiers deprecated was not the way to deal with the VIAF-conflation issue. — Levana Taylor (talk) 19:51, 29 September 2020 (UTC)[reply]
We should be aware of Citogenesis. Multichill (talk) 19:43, 29 September 2020 (UTC)[reply]
Yup, I should've known that XKCD would already have found a name for the process. And yes, humans can do it just as well as bots can, merely not on quite such a massive scale. — Levana Taylor (talk) 19:48, 29 September 2020 (UTC)[reply]
Property_talk:P214/Archive_1#synchronize_with_VIAF has some discussion about it from 2016. --- Jura 09:08, 30 September 2020 (UTC)[reply]
That's informative, but besides that discussion being more concerned with initial imports than maintenance, it was assumed back then that VIAF would be working fairly closely with Wikidata. Is there currently any human being at VIAF who is actively responding to correspondence? If not, then that makes it very hard to presently set up WD in any way that's useful to VIAF, since we wouldn't know much about how VIAF is reading and using WD data and how it is responding to changes here. It's more important, I think, to just protect WD statements that have been hand-corrected from being re-altered by a bot, which would pretty much solve our end of the VIAF problem. As to whether that's best done by adding deprecated statements and making sure bots don't duplicate them ... aren't there quite a few external processes and even Wikimedia gadgets that have trouble interpreting deprecation? Maybe it's best, then, to avoid as much as possible proliferating deprecated statements, using them only in cases where they'd be informative to humans, and elaborately tracking VIAF cluster errors probably isn't such a case. — Levana Taylor (talk) 18:43, 30 September 2020 (UTC)[reply]

Deprecated rank mechanics

Maybe I haven't read thoroughly above. What are good reasons not to declare it a bug that deprecated values don't prevent the same value being added with a different rank, or added at all? It would be the first real database feature preventing bot stupidity, for which there is no good other remedy. --SCIdude (talk) 15:18, 1 October 2020 (UTC)[reply]

a bug in what? i agree it is a bug in the bots doing the mirroring. BrokenSegue (talk) 15:27, 1 October 2020 (UTC)[reply]
A bug in that the attempt to add the same value should produce an error. --SCIdude (talk) 15:39, 1 October 2020 (UTC)[reply]
Ah, so a bug in wikibase/wikidata. I'm not sure it should always be prohibited. Could produce a bad user experience if someone was about to add a new qualifier or change the rank. I would suggest only enforcing it for bots. BrokenSegue (talk) 15:48, 1 October 2020 (UTC)[reply]

"years old"

Could anyone elucidate why there is an item years old (Q24564698) and why one should use it over year (Q577)? It seems to me that "years old" is not a unit but a strange concotation of property and unit. It also causes quite a few constraint violations, such as a few hundred on age estimated by a dating method (P7584) alone.

I can see how it might make sense to people in the context of countries, i. e. Portugal (Q45)age of majority (P2997)18 years old. It's most often used in qualifiers, such Spiros Kyprianou (Q552389)candidacy in election (P3602)1978 Cypriot presidential election (Q4502497)age of subject at event (P3629)46 years old, where I would argue the phrasing as read already feels odd.

And while we're on the subject, is there a reason for the margin of error in years old (Q24564698)conversion to standard unit (P2442)1±0.1 years? Is that why years old (Q24564698)instance of (P31)unit without standard conversion to SI (Q21684377)? --Matthias Winkelmann (talk) 17:16, 29 September 2020 (UTC)[reply]

The phrase "x is 3 years old" can be rephrased as "age of x = 3 years". The unit is year, the quantity is age. Therefore, Q24564698 should be eliminated (or merged into the appropriate year item). Toni 001 (talk) 09:40, 30 September 2020 (UTC)[reply]
I agree with Toni 001, Q24564698 can be merged into Q577. Ainali (talk) 21:02, 2 October 2020 (UTC)[reply]
The phrase years old (Q24564698) have different meaning of use than year (Q577). 'Years old' is more specially used for showing age of a human or organism. This entity is used in Infobox person template in Catalan Wikipedia for showing the age of a person. ie it will show '5 years old' right now. If these two items are merged the template will show just '5 year'. In different language the meaning of these two are different and uses different terms for both. In Malayalam years old and year have different meaning.-❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 04:14, 3 October 2020 (UTC)[reply]
That sounds like a presentation issue that could and should be solved by the lua module importing the value. It still just stores a number of time units, which in this case is the same. Ainali (talk) 12:46, 3 October 2020 (UTC)[reply]

Comments and endorsements open for WikiCite plugin for Zotero grant proposal

I have posted a draft grant proposal to develop a WikiCite plugin for the open source reference management software Zotero. The idea is to add citations support to Zotero, retrieve citations data from WikiData, provide an easy way for users to fill in missing citation information and contribute it back to WikiData, and offer citation graph visualizations. I would very much appreciate it if you could post your questions/comments in the proposal discussion page. Please, endorse the proposal if you think it may be worth it. Thanks! --Diegodlh (talk)

Goodreads subscriber counts?

I noticed this edit on Euripides (Q48305).

Is the data that is being added suitable for Wikidata, or is it site advertising? Is it relevant for the person whose data item is carrying this information? Nothing in the property proposal or description indicates that these kinds of data would be imported.

So, is the number of subscribers to a millenia-long-dead author on a website relevant data for that author's data item?

And is this simply data, or is it advertising for the author's page on the website? --EncycloPetey (talk) 02:10, 30 September 2020 (UTC)[reply]

Wikidata has no standards. Only data matters. If it's data, it's fair game. Resistance is futile. Trivia is the only truth. -Animalparty (talk) 02:56, 30 September 2020 (UTC)[reply]
@EncycloPetey: I was importing data for all goodreads authors. There is value in being able to tie authors items here to that database as it has further metadata. Pulling in subscriber counts in addition to everything else was easy so I did it. We already often do the same thing for e.g. youtube and twitter accounts. I cannot imagine how you would think this is advertising. I have no connection to goodreads and am planning to do the same thing again. BrokenSegue (talk) 03:09, 30 September 2020 (UTC)[reply]
I share your doubts. I am not sure about the relevancy of these data, mainly for old authors from a non-english area with actually tiny numbers (example), also in a case of popular items too frequent updates may cover vandalism easily. What are the plans for the frequency of updates? --Jklamo (talk) 12:16, 30 September 2020 (UTC)[reply]
@Jklamo: How will this cover for vandalism? The edits are done on a bot account. I was thinking annual updates but really had no concrete plans. I don't see why I would import this data for new authors but not all authors given it's literally easier to do the former. Maybe you all misunderstand what "following" someone on goodreads means. It just means that person likes their works. The fact someone is dead or ancient is irrelevant. BrokenSegue (talk) 12:46, 30 September 2020 (UTC)[reply]
@BrokenSegue: Frequent update edits may "hide" vandalism edits, as people see only the last edit in their watchlist. But annual updates are OK from this point of view.
I understand the following concept, but still not sure about the relevancy of a small number of followers for old authors from a non-English area.--Jklamo (talk) 13:20, 4 October 2020 (UTC)[reply]

Heads of state/government up to date

Is there a system for keeping heads of state and heads of government up to date, after new elections or deaths? Systems depending on wikidata tend to get a lot of queries regarding new leaders immediately after they're designated.

Currently Kuwait (Q817), Togo (Q945), and Somalia (Q1045) are out of date.  – The preceding unsigned comment was added by High surv (talk • contribs).

where would we source that data from? unless volunteers do it manually which I believe is what we rely on BrokenSegue (talk) 20:02, 30 September 2020 (UTC)[reply]
Apparently volunteers like the person who commented above can't edit country items. --- Jura 07:36, 1 October 2020 (UTC)[reply]
To be fair, asking for a "system" to do it is a lot easier than monitoring the political changes in 200 or so states and updating it yourself. The data also tends to be stored redundantly on multiple items, so you'd likely have to make several edits in each case, as well as creating items for any missing politicians. Ghouston (talk) 22:36, 1 October 2020 (UTC)[reply]
Here's the new prime minister of Somalia, we don't know much about him at the moment: Mohamed Hussein Roble (Q99605101). He replaced somebody else who was acting for a few months. Ghouston (talk) 22:45, 1 October 2020 (UTC)[reply]
I have completed the information for "prime minister of Somalia", also added a picture for the new PM.. On the talk page for many office holders like these, you find what Wikidata knows for that office. This is the one for the Somali prime minister.
For a long time I manually added information about people who died in Wikidata. I stopped doing this when adequate software was added that makes it easy to maintain date of death information. It is linked to many Wikipedias. A similar job can be done for office holders. It will make the information that we hold that much more useful. It will also make it easier to include the information in info boxes like they do on the French Wikipedia.. Thanks, GerardM (talk) 11:32, 6 October 2020 (UTC)[reply]

Brackets in labels of scientific articles

Hi, I noticed that these 2 [2] [3] have superfluous brackets and full stop in the labels and titles. It should be fixed IMO and the bot owners should be contacted to clean the data better before import. Any takers?--So9q (talk) 07:32, 1 October 2020 (UTC)[reply]

Wikidata:Property_proposal/translated_title proposes a solution. --- Jura 07:35, 1 October 2020 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ From which, "To do... remove brackets from English label". They should indeed be removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:59, 3 October 2020 (UTC)[reply]

  • It's a step after the info was added in a structured way.
Ideally we would need a property to add the title as well. Somehow I doubt pubmed does literal translations. I wonder led people to conclude that. Sounds somewhat offensive. --- Jura 11:14, 8 October 2020 (UTC)[reply]

Backs of postcards

See Commons:Category:Backs of postcards. It would be quite usefull to have data-item for structured data. We have Q192425 and Q68345931 but not the combination wich have functional properties, such as handwritten text and poststamps.Smiley.toerist (talk) 12:52, 1 October 2020 (UTC)[reply]

PS:I dont seem to able to use Q68345931 as a property of Q192425. P31 can only have one value. Smiley.toerist (talk) 13:06, 1 October 2020 (UTC)[reply]

I tried to apply this property to File:AK - Fröhliche Weihnachten - 1914 A (cropped).jpg, I could not add a qualification to the postcard. Another problem is that there date-item: 'posted on'. This is not the same as a publication date.Smiley.toerist (talk) 19:24, 2 October 2020 (UTC)[reply]

  • You need to ask on Commons to have the datatype of P7417 made available. Currently, I think they started only with string-, date-, and item-datatype properties. --- Jura 06:25, 3 October 2020 (UTC)[reply]

I created a new Wikidata-item: Q100140585 Smiley.toerist (talk) 16:21, 6 October 2020 (UTC)[reply]

Should these be merged or one be the building and the other be the defunct organization that used to own the building?

Should these be merged? We have University Medical Center of Princeton at Plainsboro (Q7894826) and we have Penn Medicine Princeton Medical Center (Q89034988). University Medical Center of Princeton at Plainsboro (Q7894826) became Penn Medicine Princeton Medical Center (Q89034988) in the same building when a larger organization bought out the hospital. Do we need a separate entry for the defunct organization? Is a hospital an organization or a building? --RAN (talk) 23:51, 1 October 2020 (UTC)[reply]

My opinion is, separate items. Not only do you need to distinguish between organization and building (an event happened in the building, a policy was adopted by the organization) but it is often necessary to specify which exact organization -- pre- or post-acquisition -- did some activity. There are plenty of properties like followed by (P156) and merged into (P7888) to link them. — Levana Taylor (talk) 01:43, 2 October 2020 (UTC)[reply]
I changed the descriptions to distinguish them, and the instances_of. --RAN (talk) 03:07, 2 October 2020 (UTC)[reply]

John McCain: senator * 10

Last time we discussed this, the preference of some seems to be the use multiple statements with position held (P39) = United States senator (Q4416090) on its item e.g. at [4], see Wikidata:Project_chat/Archive/2018/12#John_McCain_(Q10390)_and_position_held_(P39). While I still think this is useless, at least it had the advantage of being consistent for that position (US senator).

In the meantime, a newbie user changed one of these statements to use Q98077491 instead. See Q10853588#P39. I don't think this was discussed or proposed anywhere prior to these edits. The clean solution seems to be to delete Q98077491 and restore Q4416090 there. This was proposed at Wikidata:Requests_for_deletions/Archive/2020/08/20#Q98077491, but after the debate carefully avoided to address the issue with Q98077491, admin DannyS712 (talk • contribs • logs) closed the discussed on RfD and suggested to discuss the deletion first elsewhere. Thus this post. I will leave a note on the relevant WikiProject.

An explanation at Wikidata:Project_chat/Archive/2020/08#Special_subclass_with_"identity_of_subject_in_context"_(P4649)_qualifier concludes that the qualifier identity of subject in context (P4649) isn't used correctly on Q98082336#P31, so Q98082336 is malformed anyways. To clean this up, I suggest we restore Kamala Harris etc, to the John McCain format and then delete Q98082336 and (any similar malformed and unused items). --- Jura 04:44, 2 October 2020 (UTC)[reply]

Usually we use such specific items as values of parliamentary term (P2937), which is in turn a qualifier.--GZWDer (talk) 05:06, 2 October 2020 (UTC)[reply]
I think that would be 116th United States Congress (Q28227688), not Q98077491.
Maybe a simpler way would be to use parliamentary term (P2937) directly on items .. so position statements remain manageable. --- Jura 05:09, 2 October 2020 (UTC)[reply]
@Gettinwikiwidit: are you still planning to finish making all US Senator P39s consistent? If so, do you have an expected timeframe or list of steps to take, or can you provide any details on anything that's blocking that? I agree that we should remove the identity of subject in context (P4649) qualifiers on the instance of (P31) statements, but I don't believe that those statements being poorly modelled in that regard means that the items as a whole aren't valid (especially considering the circumstances under which those qualifiers were added.) It is already well established that such term-specific items can be useful, and if someone (whether Gettinwikiwidit or someone else) is using these as a way to get complete and consistent information on all historic Senators, then continually erecting roadblocks to that seems less than helpful. If this has stalled, however, and no else is going to finish off this process, then I agree that reverting back to a position held (P39):United States senator (Q4416090) approach is probably best. --Oravrattas (talk) 05:19, 2 October 2020 (UTC)[reply]
It's not welcome to do such changes in uncoordinated way. --- Jura 05:24, 2 October 2020 (UTC)[reply]
It's not welcome to harass and harangue people who are trying to improve the data. Please be more kind and welcoming. --Oravrattas (talk) 05:27, 2 October 2020 (UTC)[reply]
I don't think your comments, advice to the new editor, self-repetitions and accusations in this matter are helpful. It's still a mistery to me why WMF paid your then employer to improve the data model which lead to a result that doesn't seem to be working. --- Jura 05:34, 2 October 2020 (UTC)[reply]
@Jura1:, it's not clear what you mean by "coordinated". You've never made clear your interest or your concerns, so in my mind you're not interested in contributing meaningfully to this project. @Oravrattas:, I was planning on finishing this up. I had been in contact with the Assistant Senate Historian to clarify some discrepancies between their data and what was already in Wikipedia and had been waiting on a reply. I'm now inclined to simply upload the data in the state it is in and simply edit it later pending that discussion. As I've mentioned here and elsewhere I'm happy to discuss my work. The data and a short description of it can be found here: wikidata project Gettinwikiwidit (talk) 20:14, 2 October 2020 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

  • Uncoordinated, means that this wasn't discussed or proposed onwiki to Wikidata contributors before. Furthermore, it explicitly breaks the existing, previously discussed structure for this position. Do not expect people to read posts on other websites.
Please re-read my cleanup proposal above. If there are any specific points that aren't clear to you, please say so explicitly (e.g. please help me correctly format labels, please help me input this reference for that statement, despite reading Help:Label and Help:Sources, I didn't manage to do so in this or that edit). --- Jura 09:21, 2 October 2020 (UTC)[reply]
@Jura1: Again, you have not engaged with the discussion of the data at all beyond seeking to rollback changes. Focusing on a "clean up" is more of the same. The data will be consistent and complete once my project is complete and the advice will be irrelevant at that point. If you want to discuss what the data should look like then please frame the discussion that way. Gettinwikiwidit (talk) 06:40, 3 October 2020 (UTC)[reply]
  • @Gettinwikiwidit: It's great that you're going to continue with this. I agree that it would probably be best to go ahead with getting the data as complete as possible for now, and then make any corrections later based on comments from the Assistant Senate Historian. Having the P39 data for all Senators entered in a consistent manner should be the primary goal. Any cleanup of that should relatively straightforward to automate later if there is consensus for that. --Oravrattas (talk) 13:18, 2 October 2020 (UTC)[reply]
    • @Jura1: this is clear-cut bullying and harassment of a new user who is trying to improve our data substantially. You have no consensus whatsoever for your approach. Please stop. --Oravrattas (talk) 07:18, 3 October 2020 (UTC)[reply]
      • Please refrain from your accusations. Your activity here has already brought sufficient problems and lead the foundation to spend money something that hasn't worked out. If you can't help the new user outline how they should proceed, you are not helping. We need to move ahead and clean this up. --- Jura 07:27, 3 October 2020 (UTC)[reply]

Problem with Wikidata:Project_chat/Archive/2020/08

Somehow this edit makes that this section isn't available on the next revision of the archive .. I don't quite know how. Possibly some odd formatting in the post that is being archived. Any idea what causes it?

I left a note for operator of the bot that happened to archive it (@Revibot:, but I don't think it's problem of the bot as such. --- Jura 05:17, 2 October 2020 (UTC)[reply]

There was a {{P}} with one of the closing brackets missing.[5] When a section with JSON code was archived, the brackets at the end closed the template. Peter James (talk) 14:48, 2 October 2020 (UTC)[reply]

Problem with Q1716419

It is attached to https://commons.wikimedia.org/wiki/Category:Lathe_operators -- but it explicitly says that it's "Different from: lathe operators". But I can't figure out how to detach this item from that Commons category. Can someone please do that? Thanks. -- Wesha (talk) 07:46, 2 October 2020 (UTC)[reply]

Problem with QuickStatements V1

I always used QuickStatements V1 to create items in the past. When I use it today, it does not response properly, so I have to switch and learn how to use QuickStatements V2.

However, I did not know QuickStatements V1 is actually malfunctioning. Although it does not response properly, it still keeps creating blank items in the background, and I realize that after about half an hour. I have tried my best to reuse some of the blank items, but there are still around 400 blank items unused (between Q99899213 and Q99900750). Fell free to reuse these blank items. --Myerbee (talk) 16:26, 3 October 2020 (UTC) (Updated: All blank items have been used or deleted. --Myerbee (talk) 02:58, 4 October 2020 (UTC))[reply]

There is no country of citizenship (P27) of Austria-Hungary (Q28513)

Tobias1984 Mfchris84 Katjos phaebz Jean-Frédéric PeterTheOne Gittenburg M2k~dewiki emu Haansn08 Maincomb

Notified participants of WikiProject Austria @Peyerk: As of this moment, Wikidata has 12731 items with a country of citizenship (P27) statement of Austria-Hungary (Q28513). There’s only a slight problem: There has never been an Austrian-Hungarian citizenship. (In fact, citizens from the other half of the Austrian-Hungarian Empire were considered aliens.) How should we deal with this problem? Can we set a constraint? Should we delete the faulty data with a bot job? --Emu (talk) 20:55, 3 October 2020 (UTC)[reply]

Tobias1984 Vojtěch Dostál YjM Jklamo Walter Klosse Sintakso Matěj Suchánek JAn Dudík Skim Frettie Jura1913 Mormegil Jedudedek marv1N Sapfan Daniel Baránek Draceane Michal Josef Špaček (WMCZ) The photonaut Hartasek Zelenymuzik Gumruch Shadster Dænča M.Rejha Janek Jan Kameníček Eva Vele Linda.jansova Lukša Packa Fukejs Hugo Xmorave2 J.Broukal Lenkakrizova Steam Flow Pavel Bednařík Sanqui

Notified participants of WikiProject Czech Republic

Powerek38 Wostr Wiklol Witia Holek Pit rock Yarl Kpjas 99kerob Matlin masti Upior_polnocy Darellur Bogic

Notified participants of WikiProject Poland --Emu (talk) 21:05, 3 October 2020

@Emu: of course "citizenship" in our current understandig is quite inappropriate in a lot of historic cases, where country of citizenship (P27) is already set by linking to the historic country. i think there is a slight common opinion, that this statement should describe a "relationship" of an human to a specific (historic) country. the german alias "Land der 'Bürger'rechte" tries to describe this. whether there weren't our current rights of citizenship, different citizen rights already exists at least for a small number of people. so i would say, country of citizenship (P27)Q28513{{{3}}} is ok. --Mfchris84 (talk) 21:57, 3 October 2020 (UTC)[reply]
I’m well aware that there has been a lot of discussion on P27 in the last years. And yes, there are some major problems before the creation of the modern Nation state. But Austria-Hungary is a clear-cut case as the modern notion of citizenship existed in 1867 (and was arguably one of the reasons for the messy creation of said state). Bürgerrechte doesn’t really help here as it was linked to a municipality. We might of course define P27 in another way, but we never tried to resolve that mess ... --Emu (talk) 22:38, 3 October 2020 (UTC)[reply]
Constraints on country of citizenship (P27) also permit using a dependent territory (Q161243) as a value; it was added during a previous discussion at Wikidata:Project_chat/Archive/2018/09#Puerto_Rican_nationality. Ghouston (talk) 22:41, 3 October 2020 (UTC)[reply]
Thank you for pointing that out! However, I’m not sure that this is a precedent as there was and is (and arguably has been) such a thing as Puerto Rican citizenship. There has never been such a thing as Austrian-Hungarian citizenship. (On a sidenote: Joseph Roth (Q78509) would have probably preferred to have this P27 but alas he doesn’t have on Wikidata …) --Emu (talk) 23:11, 3 October 2020 (UTC)[reply]
What I mean is that the citizenship could potentially be switched to one of the constituent countries of Austria-Hungary (Q28513). Ghouston (talk) 23:27, 3 October 2020 (UTC)[reply]
Maybe it helps, but there is a (possibly inaccurate) list of "Austrian" crown lands at lists/crown lands.--- Jura 09:25, 4 October 2020 (UTC)[reply]
I am not sure if it is appropriate to label these data as "faulty" and delete them without substitution. Also, I am not sure if it is appropriate to use country of citizenship (P27) Austria (Q40) for prewar citizenship, as it is more likely related to Cisleithania (Q533534) (and home law (Q680977) of each municipality) than Austria (Q40). --Jklamo (talk) 13:44, 4 October 2020 (UTC)[reply]
You are right, country of citizenship (P27)Austria (Q40) is inappropriate for pre-war citizens. But there’s at least a constraint giving a warning about that – that’s what is missing for country of citizenship (P27)Austria-Hungary (Q28513) (as there doesn’t seem to be a way to forbid a specific value via normal constraints). We do not have a Property for home law (Q680977) – place of origin (Switzerland) (P1321) could handle it but is defined as Switzerland-specific for some reason. --Emu (talk) 15:34, 4 October 2020 (UTC)[reply]
Definitely Austria-Hungary (Q28513) has ("more or less...") two national citizenship (Q42138) (so, country of citizenship (P27) of Austria-Hungary (Q28513) is not quite correct). There is this problem with vaguely defined "State" Cisleithania (Q533534) and its citizenship (on the other hand I believe we are not forced to go to the level of crown land of Austria (Q681026), because there was defined some kind of united citizenship in Allgemeines bürgerliches Gesetzbuch (Q698262)). It seems to me, that we can claim, that residents of Austria-Hungary has citizenship Cisleithania (Q533534) or Kingdom of Hungary (Q171150) (? Transleithania (Q1879239)). --marv1N (talk) 16:04, 4 October 2020 (UTC)[reply]
Cisleithania never managed to have a modern citizenship law, but it did have a unitary citizenship. Hungary had a modern citizenship law (and a unitary citizenship in principle and discrimination against non-Magyars in practice). Residency won’t suffice though as the citizenship depended mostly on ius sanguinis. In the majority of cases residence can act as a heuristic though – country of citizenship (P27) is genereally heavily unsourced and mostly relies on guesswork. A (very) long-term goal should be to make clear where it’s guesswork (and on what grounds) with based on heuristic (P887) and where we do know it. --Emu (talk) 19:09, 4 October 2020 (UTC)[reply]
You wrote it precisely: It is slightly better to claim, that anybody with citizenship within Austria-Hungary has either asutrian or hungarian citizenship (than "austrian-hungarian citizenship"). For austrian part after 1867 we can use Cisleithania (Cisleithania (Q533534) - this sounds to me a little strange, but I hope correct), not sure what to use for hungarian part. And - as always - there would be lack of sources in lot of cases. --marv1N (talk) 07:25, 6 October 2020 (UTC)[reply]

From Wikidata how do I view what is linked to Commons by "depicts"?

From Wikidata how do I view what is linked to Commons by "depicts"? Can I click on the equivalent of what_links_here and see what what is all the way over in Commons? I had a few Wikidata entries deleted that were sparsely filled in, but were created because the entry depicted a person or thing at Commons. I want to know if someone deletes here are they aware of what is linked at Commons. --RAN (talk) 01:42, 4 October 2020 (UTC)[reply]

Wikidata item use in structured data at Commons (SDC) does not show up in any Special:WhatLinksHere or Special:EntityUsage pages, neither here nor at Commons. Since July this year there is the Wikimedia Commons Query Service (WCQS) which has this data available. However, most admins probably do not look there for item usage. Simply ask for undeletion if something went missing. —MisterSynergy (talk) 07:44, 4 October 2020 (UTC)[reply]

follows/followed by (P155/156) as qualifiers only

Have a look here for some suggestions for the migration of these properties from main statements to qualifiers.

On 11 July 2019 @Matěj Suchánek: added a property scope constraint to followed by (P156) (copied over shortly after to follows (P155)) that establishes that these should only be used as main statements or as qualifiers. This, however, appeared to contradict discussion on the latter property's talk page that suggested that it should only be used as a qualifier, and so a few days back I removed the "as main statement" qualifier on that constraint. At present, however, these removals have been questioned and reverted. What follows is an elaborated version of an argument I made in favor of the mandatory requirement of use as a qualifier four years ago:

To detach the ordering of any of these items from the sequences to which they are with respect (by not having P155 or P156 as qualifiers to some other clarifying property) seems rather disingenuous. Numerous other sequences (of recurring events, of multiple series of texts, of story arcs in TV shows, or of really anything else) may be adjusted in exactly this same fashion. A rather similar argument can be made with respect to the use of similar sequence properties such as replaces (P1365)/replaced by (P1366) as qualifiers only (and in fact has likely been made before).

I thus ask what circumstances from a data modeling standpoint (we all know that badly modeled data on Wikidata hurts its users) prevent the adoption of a constraint on these properties requiring them to be used as qualifiers on some other property. @Infovarius, Jon Harald Søby, Jklamo, Billinghurst: as active users from the linked talk page discussion, @Hjart: who has taken issue with my line of reasoning recently, and @Multichill: if you want to pummel den pummel again. Mahir256 (talk) 05:06, 4 October 2020 (UTC)[reply]

From my PoV if it follows et al, then logically it has to be as a qualifier as there is always some criteria for it to be following. What is it doing otherwise? If someone writes spy novels and film scripts and children's book, then something could have multiple follows, so unless you are specifying the item it is ambiguous. Sure sometimes it is obvious what it follows, however, that doesn't mean that it still shouldn't be as a qualifier.  — billinghurst sDrewth 07:13, 4 October 2020 (UTC)[reply]
There are currently roughly 1M uses as main statements and ~550k uses as qualifiers for both properties. In other words: direct use as main values is pretty wide-spread, in fact more than use as qualifiers. Before restricting the property to qualifier-only use, I would like to see a migration plan. In many situations it is not that obvious where the main statements should be moved to. It does not help to consider two times 1M statements as constraint violations when nobody cares about them anyways. —MisterSynergy (talk) 07:59, 4 October 2020 (UTC)[reply]
See Property_talk:P156#Constraint . -- MovieFex (talk) 08:34, 4 October 2020 (UTC)[reply]
@Billinghurst, MisterSynergy, MovieFex: Here are some suggestions for the migration of such statements. I am open to modifications, though probably not outright shelvings, of the proposals therein. (@Jura1, Bouzinac, Ghouston, Jane023, Jklamo: as others who have opined in this thread who may be interested.) Mahir256 (talk) 21:38, 4 October 2020 (UTC)[reply]
As a general note, I will leave you to fix up the problematic uses, I was more stating that I saw them as qualifiers for how we direct people to use them and the constraints that we consider appropriate.  — billinghurst sDrewth 00:35, 5 October 2020 (UTC)[reply]
As I wrote in Special:Diff/1281493739, my intention was just to track invalid use of these properties in references (often confused with qualifiers). If there is a consensus for qualifiers-only, no problem with it, the constraint can be updated. But as MisterSynergy says, there is still usage of both. --Matěj Suchánek (talk) 08:43, 4 October 2020 (UTC)[reply]
  • There are cases where this works well as main property, but frequently it's preferable to use this as qualifier only. In the way Wikidata works, I don't think we are able to sort between the two efficiently without having properties for each usecase type of use. --- Jura 09:20, 4 October 2020 (UTC)[reply]
Was also puzzled when modelling for instance that item Fallon (Q98506059) : depending on USA/UK PoV, it is followed either by Banon (Q98505191) or Jara (Q98506539)... Bouzinac 💬●✒️●💛 09:28, 4 October 2020 (UTC)[reply]
In some cases it may not be clear which statement you'd attach the qualifer to. E.g., on Never Gonna Give You Up (Q57) the followed by (P156) is apparently the next single performed by Rick Astley. To generate that as a list, you don't need a P156, just select the items using instance of (P31) and performer (P175) and order by publication date (P577), but it couldn't be used for an infobox, like on en:Never Gonna Give You Up. Presumably you'd delete the P156, on the grounds that it's meaningless without context and there's no place for it as a qualifier, and since the infobox isn't using Wikidata anyway. Ghouston (talk) 10:32, 4 October 2020 (UTC)[reply]
I use follows/followed by for paintings that considered to be related but only specifically separate in time (still don't know how to relate similar paintings not considered to be separate in time). So if the time sequence is A,B in which B is either copied from A or inspired by A, or strongly similar to A without being a strong copy of any aspect, then I use these properties. If however, B is documented as a copy of A, then B is based on A and is a derivative work of A (note the difference). If B is documented as inspired by A (because it could be inspired by some other "C" that is inspired by A or came before A), then I do not add B as a derivative work of A, but I say B is inspired by A and A is followed by B. In any case I agree that these should not only be qualifiers, but admit that I often ignore constraints because I can't even. Jane023 (talk) 10:50, 4 October 2020 (UTC)[reply]
We are using P155/156 as main statement at Wikidata:WikiProject Companies/Properties for mergers, demergers and spin-offs, as there is no special property (except merged into (P7888)). --Jklamo (talk) 13:12, 4 October 2020 (UTC)[reply]
@Jklamo: Isn't it a qualifier to instance of (P31)? Yes, some of these cases where it has been considered "obvious" it is that they are meant to be qualifiers of the base property. FWIW I find companies, especially book publishers problematic from 18th -> 19th -> 20th -> 21st they end up being a bit of a gludge in the allocation.  — billinghurst sDrewth 00:23, 5 October 2020 (UTC)[reply]
Qualifiers to instance of (P31) are not generally a good idea as far as I'm aware. The case of organizations seems a very clear use for these properties as main statements. I don't understand this push to prevent such obvious use. ArthurPSmith (talk) 15:01, 5 October 2020 (UTC)[reply]
@Jklamo: In the case of individual organizations, there is certainly a good argument for having properties for organizational spin-offs (we already have has spin-off (P2512)) just as there are for mergers; the relationships between such legal predecessors/successors deserves to be made more unambiguous in those cases. @ArthurPSmith: A specific organization by itself is not inherently part of a specific sequence for which "follows"/"followed by" is needed, but forms part of it with relation to some property/facet/quality/(whatever you want to call it) of the item, and I don't understand what's wrong with making "[the] series of which the subject is a part" (i.e. this relationship between these two) more explicit. Have a look at the migration suggestions linked in my reply to MisterSynergy/MovieFex's comments above. Mahir256 (talk) 15:23, 5 October 2020 (UTC)[reply]
@Mahir256: You know I think I was confused - we generally use replaces (P1365) and replaced by (P1366) for organizations (or merged into (P7888) where applicable), not P155/P156. Though I think the semantics is quite similar. But see for example the sequence of departments of agriculture in Australia - Department of Agriculture, Fisheries and Forestry (Q17000710) replaced by Department of Agriculture (Q21533128), replaced by Department of Agriculture and Water Resources (Q4294668) replaced by Department of Agriculture (Q65044771), replaced by Department of Agriculture, Water and the Environment (Q85756401). Those seem like they definitely belong as main statements, not qualifiers. ArthurPSmith (talk) 15:38, 5 October 2020 (UTC)[reply]
@ArthurPSmith: Couldn't these qualify instance of (P31) ministry of agriculture (Q1364302) (qualified with of (P642)/applies to jurisdiction (P1001) Australia (Q408))? I'm pushing less for every P1365/P1366 use to be moved to qualifiers (hence why my suggestions on Property talk:P156 do not mention those properties), but still contend that many situations in which they are used can be clarified with a move to qualifiers. Mahir256 (talk) 15:50, 5 October 2020 (UTC)[reply]
I generally support the idea that where possible succession information should be moved to qualifiers, rather than having them as main statements, but I also agree with ArthurPSmith that instance of (P31) is almost always going to be a bad place for these. If nothing but P31 seems reasonable, then that's probably a sign that we're missing a more useful property. For things like government departments/ministers, using P31 (and often multiple P31 statements) to essentially denote the make-up of the 'portfolio' is already at its limits in many cases, and has caused some rather contorted histories where key elements have been shunted around different departments. Having a distinct property for these would make it easier to be more explicit what actually happened when a "Department for Culture, Art, and Sport" was replaced by a "Department for Culture and Heritage", and a "Department for Sport and Leisure", for example. --Oravrattas (talk) 16:23, 5 October 2020 (UTC)[reply]
@ArthurPSmith, Mahir256: replaces (P1365)+replaced by (P1366) combinations don't always work for territories, especially for items that are about Crimea, Palestine, etc. Because they can be replaced each other by several billion times, and wasting memories of Wikidata servers to save all values of both may cause fatal errors when visiting those items. --Liuxinyu970226 (talk) 23:17, 5 October 2020 (UTC)[reply]
Spontaneous idea: has anyone already considered doing this the other way, i.e. P155/P156 only as main statements, and an optional qualifier to indicate which series this main value refers to? This would avoid the difficulty that we would need to find some property where P155/P156 fit as qualifiers. I also think that the P155/P156 claims would be much more visible and accessible that way. —MisterSynergy (talk) 09:46, 6 October 2020 (UTC)[reply]
Recently I had the same idea but forgot to share... --Matěj Suchánek (talk) 09:50, 6 October 2020 (UTC)[reply]
That could become pretty unreadable if there are multiple statements that each have their own "followed by". position held (P39) more often takes replaced by (P1366) as a qualifier than followed by (P156), but nevertheless consider Q9576#P39 as an example of just how many sequencing qualifiers an item might take. Jheald (talk) 10:15, 6 October 2020 (UTC)[reply]
I think P39 should NEVER use P155/156. --- Jura 10:22, 6 October 2020 (UTC)[reply]
Here's a query for items with the largest number of genuine followed by (P156) qualifiers: https://w.wiki/fMt
I am not sure what I think about its use to qualify properties has part(s) (P527) and has part(s) of the class (P2670), but it's evidently something we need to take into consideration. Jheald (talk) 10:36, 6 October 2020 (UTC)[reply]
Thanks for that query; here is a modified version that takes into consideration the main statement property where the P155/P156 qualifiers are sitting. I would say they are either select special cases, or poorly modeled anyways. —MisterSynergy (talk) 11:15, 6 October 2020 (UTC)[reply]
Some of them maybe could be better modelled. But the uses with part of (P361) look appropriate, eg for letters which occur in different versions of the alphabet (with different conventional orderings). It also highlights that the 'followed by' may be naturally associated with other qualifiers, eg series ordinal (P1545), that may make sense to keep together with each other. (Most commonly co-occurring qualifiers: https://w.wiki/fQ3 ) Jheald (talk) 14:48, 6 October 2020 (UTC)[reply]
This seems like it could get awkward if someone has held exactly the same position multiple times — e.g. it's not uncommon for someone to be Prime Minister of a country, lose the next election, and then win the one after that again. So they would replace / be replaced by someone else in the same office multiple times (sometimes even succeeding and being succeeded by the same person in turn multiple times). We would thus need to further qualify each of those replaces/replaced statements somehow to know which is being referred to each time, and I'm not sure how we would distinguish those other than by copying the dates across, which gets unwieldy and repetitive quite quickly. (Norodom Sihanouk is an especially extreme case here.) --Oravrattas (talk) 14:04, 6 October 2020 (UTC)[reply]
@Jheald, Oravrattas, MisterSynergy: While this seems to pertain to P1365/P1366 main statements (the movement of which as I noted to Arthur above I am pushing less for compared to P155/P156, which titles this talk page section and my suggestions on the talk page of which have not attracted much attention as yet), I also find this rather unworkable for two reasons: 1) it decouples a sequence (noted by a main statement with a given property) to which an item belongs from the items in that sequence (qualified with that same property or something similar), making it prone to desynchronization (avoiding which is the whole point of my proposals in the first place), and 2) it appears to suggest that an item inherently has some position in an ordering (indicated by P155/P156 being more prominent than the sequence property qualifying it) that end users (no matter how much you inform them about any qualifiers that might be present) may well mis(s/interpret), whereas confining the scope of P155/P156 to a particular property will generally avoid this problem. Mahir256 (talk) 14:45, 6 October 2020 (UTC)[reply]

Three different image-related text tasks in structured data in Commons

I was looking at an image that had a visible caption in it on Commons and wanted to add that text as structured data. So I tried adding a media legend (P2096) statement, but got a warning that the property should only be used as a qualifier. Then I tried adding depicts: text (Q234460) instead with a media legend qualifier containing the text in the image, but got a warning that P2096 isn't included in the allowed qualifiers constraint (Q21510851) of depicts (P180) even though media legend says that the "subject item of this property" is "depiction".

But thinking about it, for most images on Commons the caption would have been cropped out and would be purely metadata, so in those instances attaching it through depicts:text would not seem to be appropriate.

Then a third case I'm considering is text that's in an image but is not a caption, rather is part of the image. For images of certain objects there's inscription (P1684), for text inscribed on an object being depicted, but I'm not seeing a property that would correspond to text within the image itself, or text on a road sign or printed label or something like that.

So how would I go about doing each of these three things? Or should I just not do one or more of them? Thanks, --Struthious Bandersnatch (talk) 11:47, 4 October 2020 (UTC)[reply]

  • Constraints for properties at Wikidata mainly reflect how they should be used on Wikidata itself. This may be useful for Commons, but in some cases it may not. Eventually, divergent requirements should be modeled with different property constraints, see Wikidata:Property_proposal/property_constraint_for_Commons.
How existing Wikidata properties should be used would generally be discussed on Commons, e.g. at c:Commons talk:Structured data/Modeling and subpages.
On a side note, there is also identified in image by (P7380) for some aspects of text in images. --- Jura 11:56, 4 October 2020 (UTC)[reply]
Thanks Jura! I've copied my question into the Commons Modeling discussion. Hopefully someone can point me in the right direction there, or we can start making any decisions that need to be made. --Struthious Bandersnatch (talk) 23:25, 4 October 2020 (UTC)[reply]

Q68258272

Can someone familiar with recurring_sporting_events/sports _season look at 1931 National Air Races (Q68258272) that I created. It is further broken down into the two events that make up the races in each year. I want to make sure it is modeled properly before I do the other years. --RAN (talk) 13:59, 4 October 2020 (UTC)[reply]

Model number property?

Is there any property for the model number of devices?

I could not find one.  – The preceding unsigned comment was added by 84.147.38.26 (talk • contribs).

Periodicals' start and end

Some works published over a period time use start time (P580) for the publication date of its first part and end time (P582) for its last part. Obviously, one could also use additional inception date for when the work was first conceived.

Periodicals currently use either start time (P580)+end time (P582) or inception (P571)+dissolved, abolished or demolished date (P576) for the date of publication of the first and the last issue. #Venue item properties suggests the later. To harmonize them in one way or the other, I'd use just the first group also for periodicals. --- Jura 09:29, 5 October 2020 (UTC)[reply]

I would just focus on why there are still peoples that use P580/582 as main statements, what are they reflecting? --Liuxinyu970226 (talk) 13:46, 6 October 2020 (UTC)[reply]

Wikidata weekly summary #436

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
  • Events
    • Upcoming: Next Linked Data for Libraries LD4 Wikidata Affinity Group call: Professor Toby Hudson on Entity Explosion, a browser extension which allows you to get information about entities on the web page you’re visiting, 06 October. Agenda
    • Upcoming: Wikidata & Wikibase office hour, October 27th at 17:00 CEST (15:00 GMT)
    • Upcoming: plenty of events for the Wikidata birthday, check the calendar and feel free to organise one!
  • Tool of the week
    • IllWill.js is a userscript that searches Wikidata for foreign-language sitelinks, to populate Template:ill and replace plain red links on other Wikimedia projects.
  • Other Noteworthy Stuff
    • omeka-s-wikidata is a new module for the open source GLAM collection management software Omeka, that allows cataloguers to use Wikidata as a vocabulary for persons, places, subjects, etc.
  • Development
    • First pieces of the Query Builder are coming together and we are working towards making it generate the first dumb query
    • Talking to people about their thoughts on checking Wikidata's data against other databases. If you're interested reach out to Mohammed.
    • Got some first internal feedback for the REST API specification draft. We'll publish it for feedback in the next days.
    • Fixing an issue with certain language codes no longer being available (phab:T264294)
    • Working on making sure blocked bots don't waste Item IDs when trying to create new Items (phab:T232620)

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.

Merge request

Is there someone that can kindly merge Category:Zecchino d'Oro singers (Q65626334) and Category:Zecchino d'Oro singers (Q9201295)? Thanks in advance!!! --2001:B07:6442:8903:212F:CE8C:ABB7:9A15 16:44, 5 October 2020 (UTC)[reply]

✓ Done--Ymblanter (talk) 20:22, 5 October 2020 (UTC)[reply]

Almost to 100,000,000

Tracked in Phabricator
Task T44362

Entity Q99000000 was created two days ago. At the current rate, we'll hit Q100000000 somewhere around October 6. (Or sooner than that if any importation bots start up such as were running last Spring.) But if anyone has any code or schemas that assume that Q numbers are smaller than that, that they will always fit in 9 characters, now would be a good time to fix that! —Scs (talk) 21:41, 11 September 2020 (UTC)[reply]

Looks like it's about an hour away. —Scs (talk) 03:48, 6 October 2020 (UTC)[reply]
We missed Q100000000 and the first item ID over 100 million is Franklin School (Q100000001) and was created by 99of9. — The Erinaceous One 🦔 05:08, 6 October 2020 (UTC)[reply]
How do numbers get missed? (Q99999999 was also missed) Were they pre-protected? I'll try to fill out Franklin School (Q100000001) as well as I can. --99of9 (talk) 05:21, 6 October 2020 (UTC)[reply]
@99of9: There's some discussion of skipped items in a Phabricator task (linked at the top of this talk page section) and its subtasks. Mahir256 (talk) 05:26, 6 October 2020 (UTC)[reply]
Also recently discussed in this previous project chat thread (which incidentally mentions a different Phabricator task). —Scs (talk) 14:31, 6 October 2020 (UTC)[reply]
I sent an email to Franklin Early Childhood School to let them know of their involvement in this milestone. — The Erinaceous One 🦔 09:01, 7 October 2020 (UTC)[reply]

I tried to edit the news section what is then showed at the main page. I wanted to add the following text:

2020-10-06 Q100000001 is created. After Q100000000 was missed, this is the first Item in Wikidata consisting out of nine numbers.

Do you think that this text is good or how would you write that and can someone please add it at the page when it is good. I dont know how I can put the oldest news to the noninclude tag. This dont worked and so I dont saved the page.--Hogü-456 (talk) 19:54, 6 October 2020 (UTC)[reply]

When will this project get a working ClueBot?

From March to today (when it was reported to en-WP's administrator noticeboard), our project's description of the New York Yankees (Q213417) was baseball team and Major League Baseball franchise in the Bronx, New York, United States, buttheads, cheaters who have won too many World Series. I'll state the issue bluntly: the incompetence of this project with handling vandalism is an utter embarrassment, and it provides a 100% valid rationale for the Wikimedia projects that decide not to integrate with us.

A few of us were chatting about this issue on the Wikidata Discord chat a little while back, and it seems that there really aren't any active bots that have been tuned for operation on Wikidata. Does anyone want to work on this problem? It seems like it ought to be literally the #1 priority for this project (improving the references system being the only other real contender), yet I can't find any other discussion on it and my query back in May died after a single reply and remains the most recent post on the vandalism talk page. {{u|Sdkb}} talk 06:59, 7 October 2020 (UTC)[reply]

  • If you think it's needed, add it to Wikidata:Bot requests. --- Jura 07:35, 7 October 2020 (UTC)[reply]
    @Jura1: I'm unfortunately not technical enough to know how to create a well-formed bot request, other than to know that we need something. {{u|Sdkb}} talk 08:02, 7 October 2020 (UTC)[reply]
  • It is quite embarrassing for Wikidata that vandalism is not detected. I think this an aspect of the general data quality problems of Wikidata. Right now Wikidata does not seem to have the number of editors it needs, given the scope of the project, to address problems. There are long to-do lists, like the constraint violation reports or the unpatrolled recent changes, but they grow faster than they are resolved.
    If there is serious interest in such a bot I can help with drafting the requirements. There are different kinds of vandalism in Wikidata, changing labels or descriptions and vandalizing statements. Which kind of vandalism do you think is doing the most damage right now? Pyfisch (talk) 16:23, 7 October 2020 (UTC)[reply]
  • I dunno, seems like an accurate description to me ... (Joking, I was joking!). But it is not clear to me what sort of "bot" could help with the many varied kinds of vandalism possible here. We have Wikidata:WikiProject Counter-Vandalism with a variety of tools for humans to patrol recent changes that need it, but the number of those seems to be much higher than what we can handle. And yet not insurmountably high - the numbers are on the order of 6000 per day. I patrol my watchlist items and it doesn't take long, so 100/day per helper seems doable. Can we recruit/organize a group of 60 or so to handle this somehow? ArthurPSmith (talk) 17:56, 7 October 2020 (UTC)[reply]
    • It is not that simple. Part of the difficulty with patrolling and countervandalism activities here at Wikidata is the inherent multilingual nature of the project. For terms (labels/descriptions/aliases) vandalism, you basically need to understand the language in which the changes where made; for statements, you quite often need to have a look into sources in languages you do not understand. I do not think that the problem can be solved by simply gathering 60 editors who do 100 patrols a day each. I also think that this language diversity is the main obstacle for a countervandalism bot, because from a purely technical perspective it should be much simpler to check Wikidata edits than changes to unstructured Wikipedia pages. —MisterSynergy (talk) 18:27, 7 October 2020 (UTC)[reply]
    • I think the most effective approach to instances where we don't have enough editors is not to just ask for them but to make the project more welcoming to them so that they come. Wikidata inherently has some elements that are harder to learn for humans, but better documentation and instructions could go a long way. I've been engaged in a long and hard battle to improve newcomer resources and improve the user interface at en-WP, and perhaps someone should take on a similar effort here. {{u|Sdkb}} talk 06:52, 8 October 2020 (UTC)[reply]
  • I do not know exactly how ClueBot works, but from what I understand there are two issues: (i) there is no context on Wikidata, vandalism is when a description is changed to another description, or a value of a property to another value, but there no such thing as for example removing a part of the sentence including a period at the end, I guess this is the kind of things what ClueBot is trained for. If in the English Wikipedia someone changes the name of mayor of Pryluky, Chernihiv Oblast, Ukraine, no bot would be ever able to catch this, unless the name of the new mayor is Donald Trump or Michael Jackson. This is kind of vandalism were are predominantly dealing with here, and it is not well suitable to be caught by the bot; (ii) whereas it would be great if we could have some progress in vandalism in English, we also have other major languages with their share of vandalism, and ClueBot for these languages has never been developed.--Ymblanter (talk) 19:26, 7 October 2020 (UTC)[reply]
  • Writing a good anti-vandal for wikidata would be hard. I think it's doable but it'd be many many hours of work. For example, I think I have the knowledge to do it but who has the time or money for infrastructure to do it right? Not me. BrokenSegue (talk) 19:31, 7 October 2020 (UTC)[reply]
    @BrokenSegue: Have you or others considered meta:Grants:Project? Sophivorus recently used it to get compensation for working on excerpts at en-WP and might be able to provide feedback on the process. {{u|Sdkb}} talk 06:47, 8 October 2020 (UTC)[reply]
  • Out of curiosity, is there anybody to respond on my remark from the query: I am sure we had one. But I don't know what the name was and if it's still working.? It might have been connected to the ORES service. --Matěj Suchánek (talk) 07:49, 8 October 2020 (UTC)[reply]

Adding values for another language in constraint clarification (P6607) as a qualifier

Does anyone know how to add more values for constraint clarification (P6607) as a qualifier in another language? For example, in typically sells (P7163), there is one constraint clarification (P6607) value in English as property generally should have just 1 or a few values. But if you change your interface language to, say French, and open an item with "Suggestions" in typically sells (P7163) (like flea market (Q385870)), you would retrieve the French value of it Cette propriété contient généralement une seule valeur if you click on the flag. But if you open the page for typically sells (P7163) you would only read the English value for constraint clarification (P6607) and I think I also can't find how to add another language. RXerself (talk) 09:53, 7 October 2020 (UTC)[reply]

@RXerself: The message you see on flea market (Q385870) is an interface message of the WikibaseQualityConstraints extension, not the constraint clarification (P6607) of the constraint. (Even in English, you’ll see This property is generally expected to contain only a single value., whereas the constraint clarification (P6607) is property generally should have just 1 or a few values.) Translations of the message (wbqc-violation-message-single-value) are maintained on TranslateWiki.net. --Lucas Werkmeister (WMDE) (talk) 10:25, 7 October 2020 (UTC)[reply]
@Lucas Werkmeister (WMDE): Thank you! The message group also turns out to be the one I was looking for a month ago. RXerself (talk) 11:17, 7 October 2020 (UTC)[reply]

Sindhi Language Improve to Survive

i am a sindhi and want to submit any project about our sindhi language.  – The preceding unsigned comment was added by 42.201.234.34 (talk • contribs).

Welcome on Wikidata! It would be very helpful if you add Sindhi language labels and descriptions to items. (guide) --Pyfisch (talk) 13:28, 7 October 2020 (UTC)[reply]

Advice

Guys

so apparently me personally adding data about myself to Wikidata has been flagged as spam and self promotion?

Surely if i have a wikidata profile, and i add my social media links, or an article ive been featured in which is factual information, that cant be seen as spam.

How does that even work?  – The preceding unsigned comment was added by Craigcampbell0302 (talk • contribs).

Update database report

Wikidata:Database reports/Constraint violations/P4633 is clearly not up-to-date. Section "violations of Q7777570 and Q204854" should list a lot of stuff, for example Iron Man 3 (Q209538), but it doesn't. How to force the update of report? --Kanzat (talk) 13:01, 7 October 2020 (UTC)[reply]

subject type constraint (Q21503250) does only work for as main value (Q54828448).[6] But I have made a query for number of "violations of Q7777570 and Q204854" if you are interested. https://w.wiki/fmi -Premeditated (talk) 12:16, 8 October 2020 (UTC)[reply]

Link to list of showcase items in Main page

The main page of Wikidata has a link to Douglas Adams (Q42) as a showcase item. Is there a list of showcase items for every item type? (or at least for the most popular ones) If not, need to create it. I.e. showcase movie, politician, football player, book etc.. Once it's ready - we can mention it in the Main page, it would be very helpful, because Wikidata is still too complex for most users. --Kanzat (talk) 13:40, 7 October 2020 (UTC)[reply]

First, there are no showcases promoted since 2018. Second, we need a clear rule of how to promote (or demote) a showcase.--GZWDer (talk) 14:56, 7 October 2020 (UTC)[reply]
There's model item (P5869) which has a lower standard than showcase item but may give you more examples to work with.
The following query uses these:
  • Properties: model item (P5869)  View with Reasonator View with SQID
    SELECT ?type ?typeLabel ?item ?itemLabel
WHERE 
{
  ?type wdt:P5869 ?item.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

- cdo256 16:32, 7 October 2020 (UTC)[reply]

  • Given the dynamic nature of Wikidata, what may be showcase today wont be a month later.
A regularly updated, random selection might work better, e.g. for films: Wikidata:WikiProject Movies/reports/random/film/samples. --- Jura 11:23, 8 October 2020 (UTC)[reply]

Call for feedback about Wikimedia Foundation Bylaws changes and Board candidate rubric

Hello. Apologies if you are not reading this message in your native language. Please help translate to your language.

Today the Wikimedia Foundation Board of Trustees starts two calls for feedback. One is about changes to the Bylaws mainly to increase the Board size from 10 to 16 members. The other one is about a trustee candidate rubric to introduce new, more effective ways to evaluate new Board candidates. The Board welcomes your comments through 26 October. For more details, check the full announcement.

Thank you! Qgil-WMF (talk) 17:09, 7 October 2020 (UTC)[reply]

Modelizing Scrabble (Q170436)

How to state one can play Scrabble (Q170436) in French (Q150), Arabic (Q13955), German (Q188), English (Q1860), etc + numbers of letters ? More info on Scrabble languages can be found https://en.wikipedia.org/wiki/Scrabble_letter_distributions here Bouzinac 💬●✒️●💛 19:11, 7 October 2020 (UTC)[reply]

Advice on importing information on the devil recorded in historical Scottish witchcraft records.

Hi all, am working with Data Science students at the University of Edinburgh this semester and am again looking at a 6-7 week project to import some of the rich historical data in the Survey of Scottish Witchcraft database into Wikidata. As we have done in creating this Map of Scottish Accused Witches website.
As we have added temporal and geographical data previously, it would be interesting to depict the mentions of the devil as recorded in the historical documents in witchcraft investigations, and visualise that over time and location. The appearance of the devil is variously recorded in meeting notes and the types of demonic pact also. we have previously added items of data on the accused witches, the trials, and persons involved with the trials (judges, prosecutors, sheriffs, lairds, witnesses etc.) so trying to work out to model the information.
e.g. Property = Demonic_Type (refers to the type or motif of demonic pact that was described in the witchcraft documents)
Example values:

  • Anti-baptism: renunciation of Christian baptism, apostasy
  • Body and soul: giving oneself over to the Devil, body and soul
  • Bond/Band: an agreement with the Devil
  • Devil's Mark: mark received from the Devil as a sign of pact (often described as not sensible to feeling)
  • Head and foot: touching of the head and foot with opposite hands – all between was given to the Devil
  • Kisses Devil's bottom: worship of the Devil by inversion/perversion of Christian symbolism
  • New name: new name given to a witch by the Devil indicating a rejection of Christian baptism – a re-naming by the Devil
  • Paction: general, non-specific pact made with the Devil
  • Possession: the accused witch claimed to be possessed by the Devil
  • Servant: indicates that the accused had agreed to be the Devil’s servant
  • Sex: indicated that the accused had sexual relations with the Devil
  • Tacit pact: the accused used power of the pact but did not describe any specific features
  • Want nothing: the accused confessed that the Devil promised to provide everything for them and that they ‘should never want’

Not sure about putting forward a property proposal for 'demonic pact' but maybe significant event (P793) Significant event > pact with the devil (Q1506690) added to the accused witch's item with the values above as a qualifier? Any help gratefully appreciated. Stinglehammer (talk) 20:04, 7 October 2020 (UTC)[reply]

Devil's appearance in Scottish witchcraft records

Additionally, we also have records on: Property: Devil_Type – This field refers to the type of non-natural being that was mentioned or described in the documents. Example values:

  • Animal Devil: the Devil appeared in animal form
  • Baby: the Devil appeared in the form of a baby
  • Child Devil: the Devil appeared in the form of a child
  • Fairy: non-natural being appeared in the form of a fairy, gender not specified
  • Female: the Devil appeared in the form of a female
  • Female Fairy: non-natural being appeared in the form of a female fairy
  • Ghost: non-natural being appeared in the form of a ghost or dead person
  • Inanimate Object Devil: the Devil appeared in the form of an inanimate object
  • Insect Devil: the Devil appeared in the form of an insect
  • Male: the Devil appeared in the form of a man
  • Male Fairy: non-natural being appeared in the form of a man
  • Other Demon: non-natural being appeared in the form of another non-specified demon
  • Spirit: non-natural being appeared in the form of a non-specified spirit
  • Unspecified Devil: non-natural being appeared in the form of a non-specified Devil

Looking at potentially adding appears in the form of (P4675) and adding these as values but need to think how to model that they were recorded as meeting with the devil and have appears in the form of (P4675) as a qualifier? And potentially add participant in (P1344) > witches meeting too. Working things out but let me know if you have any thoughts. Stinglehammer (talk) 20:13, 7 October 2020 (UTC)[reply]

Stone lanterns

Would someone have a look at stone lantern (Q24577890)? Doesn't look well modeled, especially has part(s) (P527). - Jmabel (talk) 01:21, 8 October 2020 (UTC)[reply]

I added made from material (P186) stone (Q22731), but I'm not sure about the other part building stone (Q11250576). Ghouston (talk) 01:50, 8 October 2020 (UTC)[reply]

The "requirement" of references on individual awards

Many items are created because someone by that name received a particular award. The objective is that we have a full list of awardees at Wikidata, the source is a black or red link in a Wikipedia. When there is no article for that award, there is a website for that award where this person is mentioned.

What I find is that a newly instatement for "requirment of a reference" is abused by people to delete these items. They are not interested in the completeness of lists, they have the Wikipedia attitude towards notability and for them no reference is good enough.

I am completely aware that this is an unintended consequence of what is in and of itself not a bad idea. But we have to deal with the consequences and for me a these consequences undo the integrity that is one of the reasons for notability of an item. We cannot change people and their attitude but we can remove this requirement. Thanks, GerardM (talk) 06:06, 8 October 2020 (UTC)[reply]

Russian: Merge Q427948 and Q4456859?

Is the Russian article about the same subject as the others? The English label is the same ("scope statement"). Pyfisch (talk) 11:28, 8 October 2020 (UTC)[reply]

Remove noratelimit for bots

Hello all,

As you may know, over the past months we’ve been struggling with more and more bots editing Wikidata at a very high rate, causing infrastructure issues having an impact on the Query Service that couldn’t keep up with the changes and on tools such as Pywikibot.

Over the years, we tried different things (like Add Wikidata query service lag to Wikidata maxlag, increase maxlag or factor, limit the edit rate for all accounts). Wikidata admins also approached individual bot owners to ask them to comply with the bot policy’s limit, sometimes without success.

Recently, we discussed removing the noratelimit feature for the bots group. This would have as an effect to limit the edits to 90 edits/min for most of the bots ; the few bots that need an unlimited rate to function (for example MassMessage) can be added to the existing accountcreator group (with the possibility to rename this group).

Many thanks to bot owners who gave input in the comments of the ticket and helped us frame this solution. If you want to continue the discussion, please have a look at these comments, so we can build from them and avoid restarting the discussion from scratch.

We hope that this solution will allow a fair access to mass editing Wikidata, while preserving the existing infrastructure and avoiding hitting too hard on the Query Service. In the meantime we are working together with the Search Team at the WMF and others on improvements to the Query Service scalability and alternatives to it so some load can be redirected to other systems, as well as general infrastructure improvements.

Unless there’s a strong opposition from the community to this change, we will implement it on October 20th.

If you have any questions or need more information, feel free to add a comment below or in the ticket. Thanks, Lea Lacroix (WMDE) (talk) 11:44, 8 October 2020 (UTC)[reply]

Thanks Lea, it is nice to see that this issue is being addressed. Vojtěch Dostál (talk) 13:33, 8 October 2020 (UTC)[reply]
  • I think I would prefer this not to be bundled with the account creator right but into a new right, so that it's more obvious to people that the right has something to do with the ability of a bot to go over the edit limit. ChristianKl ❪✉❫ 14:00, 8 October 2020 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=1288309977"