Wikidata:Project chat/Archive/2022/09

From Wikidata
Jump to navigation Jump to search
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.


Being buried in one's own grave - relevance and logic...

Moved from Talk:Q2042

Good evening, or something...

First: I come to this from Wikipedia, just so that background info is mentioned. Second, it was as I was looking at Charles de Gaulle's article on my "home turf" that I noticed, in the infobox no less, the highly surprising information that Charles de Gaulle was buried in Charles de Gaulle's grave (!) ...

In short, here is my reaction that I misplaced on his talkpage here, and I paste a copy of here:

quote begins:

Quite frankly, and seriously, asked: WTH do people register that somebody is buried in their OWN grave ????

In some cases, yes, there is a special mausoleum, and so that needs to be described somehow - but frankly, when this guy was interred besides his daughter in the village cemetery, and this is no surprise to anybody older than, say, 18, ... Frankly, if WD is going to be taken seriously, you guys need to do something about this kind of ridiculous statements. Let the information be the field that says "Cimetiere de ...", and let people figure out for themselves that General Charles de Gaulle is buried beneath the stone that reads "Charles de Gaulle"!

Honestly, this is a complete waste of everybody's time, but unfortunately, once the flaw is introduced, somebody has to waste more time correcting it - so please DO!

Exasperatedly yours,

quote ends.

Now that my exasperation is down to a simmer, could I ask that somebody try to explain to themselves what the logic of such datapoints(/whatever you call these fields) actually IS ? I mean, is it surprising to anyone to read that a European statesman of the twentieth century was buried in a grave ???

Still somewhat exasperatedly yours, Autokefal Dialytiker (talk) 18:12, 27 August 2022 (UTC) (PS: I am grateful for WD's existence - I think... Items like this make me question the validity of WD; please assume that I won't be the only one to react to such - I can't even find a useful word for this kind of folly...)

Excellent rant, Autokefal Dialytiker, most enjoyable.
WD tends to use the item having the smallest granularity for a place of burial (P119) value; so region not country, locality not region, cemetery not locality, &c. And this continues through to the level of a grave. WD has - or at least uses as a place of burial (P119) value - very few graves - 328 of them in fact, out of ~200k such values [1]. It is well within the powers of an infobox code author to check the P31 value of a P119 statement value used in the template for place of birth, and to reject a value having a P31 of 'grave' and instead choose the location of that grave. Whoever wrote the template on whichever wikipedia boiled your piss did not do this. Unfortunate. Now, you could argue that WD should exclude the use of 'grave of x' items as values for P119, but I suspect that would enrage pharaoh Khufu, who went to the trouble of having the Great Pyramid of Giza built as his grave. And WD, as a matter of policy, refrains from enraging pharaohs. So right now it is really a case of caveat utilitor, or whatever the hieroglyphic translation of that is. --Tagishsimon (talk) 18:45, 27 August 2022 (UTC)
@Tagishsimon, @Autokefal Dialytiker: I agree that there is nothing wrong with such a statement. He was buried in a grave and since the grave itself is notable, we mention it. If the grave was not notable, but the cemetery was, we would use the cemetery's item. If the cemetery was not notable, we would use the city item, and so on.
Just like if a person X was riding an unnamed, but notable horse, there would be a "mount (P3091): X's horse" statement. You might find it ridiculous to say that "X was riding X's horse", but remember that treating sequences of labels like sentences is not the point of Wikidata. Wikidata is not meant to be a database of human readable sentences, but of machine-readable statements. And de Gaulle was in fact buried in that grave. If you are creating human-readable content and want to display e.g. the country of burial, you should extract that info from the item of the grave (or other burial place) instead of e.g. adding place of burial (P119): France (Q142) to Charles de Gaulle (Q2042).
@Emu: Personally, I think the change of place of burial (P119) from the grave to the cemetery should be reverted as the statement about the cemetery is less precise and informative than the statement about the grave. I see you left the link to the grave as a statement is subject of (P805) qualifier, but this is only suitable for human consumption. A computer is not going to expect that it has to skip the main value and use the value from the qualifier instead. Wikidata is explicitly intended to be machine-readable. For human-readable content, just use Wikipedia. --Tengwar (talk) 12:50, 29 August 2022 (UTC)
@Tengwar Are you sure? The Commons Wikidata infobox sure knows how to use the information properly. --Emu (talk) 16:48, 29 August 2022 (UTC)
You are right, apparently this infobox adds the statement is subject of (P805) qualifier value label in parentheses, resulting in an output that is useful to humans. But IMHO the main value should be the grave and the cemetery should be in a qualifier. (Not sure if P805 would be applicable in this case. Likely another property would be better.) This should result in reasonable treatment both in the Commons infobox and when the location is extracted from the main value. --Tengwar (talk) 20:21, 29 August 2022 (UTC)

I changed the statement because there seems to be some sort of a pattern for similar cases: 

SELECT ?type ?typeLabel (COUNT(?subjof) AS ?count)
WHERE
{
     ?item p:P119 [ pq:P805 ?subjof;
                  ].
     ?subjof wdt:P31 ?type.
     SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
GROUP BY ?type ?typeLabel
ORDER BY DESC(?count)
Try it!

@Tagishsimon: Feel free to change it if you don’t consider this pattern correct. --Emu (talk) 18:48, 27 August 2022 (UTC)

I don't follow why looking at the handful of items that have p:P119/pq:P805 is responsive to the issue raised by the OP. --Tagishsimon (talk) 19:28, 27 August 2022 (UTC)
As I wrote, it seems to be a pattern that is employed in similar cases. --Emu (talk) 19:38, 27 August 2022 (UTC)
Yes. Saying the same thing twice does not explain it. Some P119 values are graves. Meanwhile some P119 values have pq:P805 (statement is subject of (P805)). Unsure how pq:P805 or the P31 value of the pq:P805 value bears on the complaint that templates should not display grave items as place of burial. --Tagishsimon (talk) 19:44, 27 August 2022 (UTC)
I’m not exactly sure what you are trying to say. Do you consider the modeling of these statements to be incorrect? Then you should change them, at least for Charles de Gaulle (Q2042) as I have asked you to do if you so please for some reason or the other. --Emu (talk) 20:10, 27 August 2022 (UTC)
This edit is incorrect. place of burial (P119), just like location (P276) should contain the most specific item. Choosing something higher in the location chain is arbitrary and incorrect. So yes all of these are incorrect.
OpenStreetMap has the concept don't tag for the renderer. Here we can say: Don't model for the infobox. Multichill (talk) 16:38, 29 August 2022 (UTC)
@Multichill I’m not so sure if place of burial (P119) is really the same as location (P276) (or place of birth (P19) or place of death (P20)) but I won’t fight you on this (and I had certainly no intention to model for the infobox). Anyway, the right course of action would be to disallow statement is subject of (P805) as qualifier and change the German description of place of burial (P119)? --Emu (talk) 16:55, 29 August 2022 (UTC)
@Emu: the German description does seem quite brief compared to English (or Dutch) so probably needs updating. For statement is subject of (P805) I would first do the clean up before updating any constraints.
This can be quite the rabbit hole to go down. We have a couple enthusiastic grave diggers on Commons (pun intended) and ended up with quite a few individual grave items here. I have some notes on what is done and still needs doing. From the person you can link to the grave and from the grave back to the person. Still a lot of these links missing. Multichill (talk) 17:15, 29 August 2022 (UTC)
@Multichill I adjusted the German description to conform with place of birth (P19) and place of death (P20) --Emu (talk) 17:31, 29 August 2022 (UTC)
The examples in place of burial (P119) are quite clear about the property being about the actual item of the grave. Tomb of Paracelsus (Q19971847) is in one of the examples. Having a clear link between the item of the person and the grave makes a lot of sense to me. In a case like grave of Charles de Gaulle (Q100998916) it gives easy access to the images of the gravestone. ChristianKl ❪✉❫ 13:32, 1 September 2022 (UTC)

Q708514

Please see this edit in housekeeping (Q708514). does it's ok? Geagea (talk) 14:11, 31 August 2022 (UTC)

IMHO it is. Lymantria (talk) 17:33, 1 September 2022 (UTC)

SAGE Publishing Journals Data Donation

Hello,

I am an Editorial Specialist working at SAGE Publishing in US Journals. We are interested in providing data to Wikidata on our journals. We are interested in doing so on an annual basis. Examples of the type of data we want to provide includes editor/editor-in-chief information, Impact Factors and other indexing information.

I would like to discuss best options for donating this data.

Thanks, Lauren

SAGE Publishing Editorial (talk) 12:58, 1 September 2022 (UTC)

Hi Lauren! Of course, such contribution will be highly welcome.

You can read https://www.wikidata.org/wiki/Wikidata:Data_donation.
A crucial concern is to match your items to existing WD items.
Matching is done with tools like OpenRefine and Mix-n-Match. Once you have a strategy how to match your items, you should describe how you want to map the data, and solicit feedback,
  • I don't know how to model Impact Factor and I'd guess there have been discussions about this in the community (impact factor (Q5330)'s Wikipedia page says "While frequently used by universities and funding bodies to decide on promotion and research proposals, it has come under attack for distorting good scientific practices.")
  • There's Danish Bibliometric Research Indicator level (P1240) but I don't think it's what you are looking for
  • @UWashPrincipalCataloger: can you add some advice?

BTW, you may want to move this discussion to your talk page, since Project Chat is archived often. --Vladimir Alexiev (talk) 13:49, 1 September 2022 (UTC)

Hi Vladimir,
Thanks for your quick response. I had looked over the wikidata donation page before, hence why I reached out, since it said this was the first step!
It does appear that most (if not all) SAGE Publishing journals are up, I did a random spot check earlier.
As for editor-in-chief and editor information, it should be possible that we can grab the ORCIDs for them, but it may be a bit time intensive (with how we store this information internally). But I will check to see if this is something would could easily grab for our editors.
Apologies for not being more clear about what I meant in terms of impact factor and indexing information. This information would be part of a category that you see in other academic journals called "indexed in bibliographic review". This section for other journals includes indexing information from scopus, and SCIE, etc. Impact Factors, provided via JCR (journal citation report) from Clarivate, are another piece of indexing information. Hopefully this helps to clarify.
There is a possibility that there is other data they we could hope to donate, and preferably on an annual basis as well. I will get back on a full list of information we would like to provide soon.
Thanks,
Lauren
SAGE Publishing Editorial (talk) 14:22, 1 September 2022 (UTC)
For why there is no impact factor in Wikidata, see Wikidata:Property_proposal/Impact_factor. GZWDer (talk) 15:26, 1 September 2022 (UTC)

Capturing later print information for a previously online-only scholarly article.

(Alerting @Pigsonthewing, the creator of the item via quickstatements.)

I am hoping that someone can point me to a good example of a scholarly article item that was originally online-only then for which we added the print information. I would like to add the print information for Q109321060, Resolving the “muddle in the middle”: The case for Homo bodoensis sp. nov & am wondering what the SOP is. I am wondering how to resolve two different publication dates, among other property values. Peaceray (talk) 16:11, 1 September 2022 (UTC)

Radiesthesia, dowsing, dowser, dowsing rod

The recent creation of radiesthesia has caused a lot of mess. Prior to that dowsing (Q64434026) was considered a synonym of radiesthésie/Radiästhesie thus radiesthesia (Q304787) but now is separated and contains instance of who practices it i.e. a dowser (Q113624647) and some identifiers are also placed at dowsing rod (Q1071985). Could you please help me fix this issue? Thanks a lot.-- Carnby (talk) 06:35, 26 August 2022 (UTC)

From the description of dowsing (Dowsing is a type of divination employed in attempts to locate ground water, buried metals or ores, gemstones, oil, claimed radiations (radiesthesia), gravesites, malign 'earth vibrations' and many other objects and materials without the use of a scientific apparatus.), it seems radiesthesia is a kind of dowsing that attempts to detect so-called radiations, so radiesthesia (Q304787)subclass of (P279)dowsing (Q64434026). Or they could simply be exactly the same thing, in which case radiesthesia (Q304787)permanent duplicated item (P2959)dowsing (Q64434026). Silver hr (talk) 01:02, 2 September 2022 (UTC)

edit protected - author citation as instance of author, instance of information, subclass of human

author citation (Q669585) as

  1. instance of author Q482980
  2. instance of information Q11028
  3. subclass of human Q5

a citation isn't an author, nor a subclass of human. 77.183.4.252 11:54, 26 August 2022 (UTC)

It might be beneficial to register an account so you can do these kinds of edits yourself. Silver hr (talk) 01:13, 2 September 2022 (UTC)

Piscina ~ lavabo

Are lavabo (Q13446365), piscina (Q111311191) and piscina (Q423944) the same thing? Or is piscina (Q423944) a superclass of the others?-- Carnby (talk) 12:40, 30 August 2022 (UTC)

piscina (Q111311191) should be merged into piscina (Q423944). From the description of lavabo, it seems a piscina (Q423944) is a kind of lavabo (Q13446365). Silver hr (talk) 01:59, 2 September 2022 (UTC)

Brig Delight 1824

I am looking for a picture of a ship that my relative arrived on in the Port of Philadephia on or about 24 October 1824. I do not think it was a passenger ship for the manifest if quite short; just 7 persons listed. The ships captain was David J. Conyingham, and the owners were Stephen Rupett and Henry Nixon. It ported in Philadephia and came from Hamburg, Germany. I am interested in seeing a picture of this ship to include in my Family Book. Any help in locating more records on this sailing would be greatly appreciated. I have documentation of the arrival so it is a valid ship and there are quite a few Brig Delights but just one on that date. Thank you in advance, Cheryl Hanline. 100.34.79.221 13:19, 2 September 2022 (UTC)

Is there a property to say that something still exists?

When a organization or recurring event doesn't have an end date, it might still exist, or it might be long gone but no one has added an end date. Is there a property I could use to say that it still exists as of 2022? My only idea is to add end time (P582) = "no_value" with qualifier point in time (P585); is that the best way to do it? --Arctic.gnome (talk) 15:38, 31 August 2022 (UTC)

For buildings, museums, infrastructure, etc there's state of use (P5817) which can take values such as in use (Q55654238), open to the public (Q55570821), in partial operation (Q109551035) to show that something is functioning or accessible as of a particular point in time. Jheald (talk) 16:43, 31 August 2022 (UTC)
There's also state of conservation (P5816) which could maybe take a value along the lines of "still exists", or something like that -- though there aren't any examples of it being used in that way currently https://w.wiki/33ZC (and I couldn't spot an item for "extant", "exists", "still exists", etc, but I may have just not seen it; it would be straightforward to create, if there really isn't an item for that). -- Jheald (talk) 16:53, 31 August 2022 (UTC)
This is of interest to me producing a website about fortifications, when I get results for castles that aren't merely ruins, as most are to a degree, but are merely bumps in the ground, or even in some cases things that a wiki editor thinks are are castle, but are featured in castle databases as "thought to be a castle, but isn't". I can possibly deprecate the castle claim for the latter, but for the former I wish I had a de minimis measure.
Special:WhatLinksHere/Q55553838 for state of conservation (P5816) does seem the best bet for buildings. For people we have unknown_value for date_of_death, for organisations/events I'd do the same for dissolved, abolished or demolished date (P576), with an earliest_date qualifier for the last time they were around. dissolved, abolished or demolished date (P576) is not good for buildings if their archaeological remains are significant, as old buildings but not new buildings are. Vicarage (talk) 20:41, 31 August 2022 (UTC)
@Arctic.gnome Don't solve the problem that some items are missing data by adding requirements for more data on the items you care about. If something is lacking an end date (or another appropriate property that indicates something is not in use anymore in that topic space), it should be enough to indicate that it is still in use. The correct way to solve this, in my opinion, is to add end dates on all the items that are long gone. (And if you don't know the exact date, there are ways to indicate it with unknown value and possibly some qualifiers.) Ainali (talk) 21:34, 31 August 2022 (UTC)
The default state of Wikidata is incompleteness. If some item doesn't have some statement, it might be because that statement doesn't apply, or it does apply but no one has added it yet. You seem to come at this with a closed-world mindset, which I sympathize with, but that just doesn't work on a wiki. Silver hr (talk) 02:19, 2 September 2022 (UTC)
end time (P582) = "no_value" with qualifier point in time (P585); does seem to me like a good way. ChristianKl ❪✉❫ 13:52, 3 September 2022 (UTC)

Please help to clean the deprecated language codes in all wiki projects

According to this, zh-classical has been replaced by lzh. However there are still lots of wiki projects still use the deprecated language code "zh-classical" like Category:User zh-classical (Q7229580) rather than right Category:User lzh (Q9117977). Some projects even have "Category:User zh-classical" and "Category:User lzh" at the same time, with their child categories and corresponding userboxes. Other deprecated lang code like "bat-smg", "be-x-old", "fiu-vro", "roa-rup", "zh-min-nan", "zh-yue", "zh-cn", "zh-sg", "zh-my", "zh-tw", "zh-hk", "zh-mo" and the others mentioned in the url above. Please help, thanks.--迴廊彼端 (talk) 13:49, 2 September 2022 (UTC)

Similarly, there are Category:Wikidata-zh-hant and Category:Wikidata-zh-hans. According to ISO 15924 they should be "Category:Wikidata-zh-Hant" and "Category:Wikidata-zh-Hans". Is this naming convention from existing rules or mistakes?--迴廊彼端 (talk) 04:20, 3 September 2022 (UTC)

Merge request (Viçosa)

Hello. Can anyone please merge Viçosa, Minas Gerais (Q1780182) and Viçosa (Q22031062)? They're the same city. Thank you! Mateussf (talk) 14:13, 3 September 2022 (UTC)

@Mateussf We can’t. There are two sitelinks to ceb.wp and sv.wp. Sorry, it’s a common problem caused by w:en:Lsjbot. --Emu (talk) 16:42, 3 September 2022 (UTC)

The 2022 Board of Trustees election Community Voting is about to close

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

Hello,

The Community Voting period of the 2022 Board of Trustees election started on August 23, 2022, and will close on September 6, 2022 23:59 UTC. There’s still a chance to participate in this election. If you did not vote, please visit the SecurePoll voting page to vote now. To see about your voter eligibility, please visit the voter eligibility page. If you need help in making your decision, here are some helpful links:

Best,

Movement Strategy and Governance

MNadzikiewicz (WMF) (talk) 17:56, 3 September 2022 (UTC)

Josef Fränkel items

There are THREE of them and they all seem to refer to the same guy, a German Jew who was an engineer that survived the Holocaust. Any chance someone wants to merge these or knows of a better way than fusing 2 and then merging the remaining one? If not just reply with the bot tag to have it done and I suppose I will get it done. Bgrus22 (talk) 01:29, 4 September 2022 (UTC)

I suppose a couple of things, @Bgrus22:. First, if you have found candidates for merge, and you know how to merge, then you doing the merge is probably the best way forwards. Next, if you are uncertain about the need to merge, or the merge process, and must bring the issue here, then please specify the QIds of the items you are talking about, ideally within a Q template for ease of our clicking. It is not uncommon and certainly is not noteworthy that a triplet of items having the same subject has been found. --Tagishsimon (talk) 01:47, 4 September 2022 (UTC)
@Bgrus22 We have three Josef Fränkel in the database:
All of them seem different – am I missing something? --Emu (talk) 09:24, 4 September 2022 (UTC)
Looks like you're right. I saw the same name for a page I had written in the English wiki and hadn't seen any other people's info for other survivors. Im used to seeing copies of unwritten pages in wikidata and the skimmed similarities left me assuming things. Thanks for clarifying! Bgrus22 (talk) 18:07, 4 September 2022 (UTC)

UTF8 strike again

UTF8 strike again: Special:diff/1719268039 2A01:CB14:D52:1200:FC59:E65B:5949:2E42 14:21, 4 September 2022 (UTC)

CC @Horcrux Bovlb (talk) 14:48, 4 September 2022 (UTC)
Sorry, I'll check that batch. @Bovlb: Thank you for the notification. --Horcrux (talk) 15:04, 4 September 2022 (UTC)
Anyway, I think this edit could be considered correct, since the subject is actually named like that on the website. The following edit instead is definitely wrong. --Horcrux (talk) 15:06, 4 September 2022 (UTC)

Imports of classification schemes turning Wikidata into a weird place

I started noticing an emerging phenomenon in Wikidata and I'd like community's input on it. There are more and more imports of what I would call classification schemes, but with little or no effort to reconcile them with the existing taxonomy in Wikidata. Take for example Books > Fiction & Literature > African American (Q110593300) by Germartin1 or Military demobilization (Q104699311) by Jneubert. Are these valid items we should encourage? My opinion is that the first should be turned into subclass of (P279) book (Q571) and African American literature (Q388170) and the latter should be subclass of demobilization (Q934433) (or maybe even merged). What is the purpose of importing whole classification schemes into Wikidata as "standalone" ontological systems? Aren't we overdoing this? Vojtěch Dostál (talk) 16:03, 30 August 2022 (UTC)

I agree, much better to use combinations of existing terms or qualifiers. Vicarage (talk) 16:52, 30 August 2022 (UTC)
The purpose should be to link to existing items, not to create new ones, I think in most situations. Wikidata is most useful when different identifiers for the same concept are linked together. Standalone stuff for classifications shouldn't generally be added, though I might be persuaded it's helpful in some cases. ArthurPSmith (talk) 17:27, 30 August 2022 (UTC)
@Vojtěch Dostál, Vicarage, ArthurPSmith: But it's an interesting and worth-discussing question, I think. In the last few days I have been looking at the ISCO/ESCO classification of occupations (query https://w.wiki/5dSW for what is in place so far).
One of the problems I think we have in general is that our ontology is often rather weak, or under-structured, so I think there is a lot to be said for looking at external thesauruses, and wondering when and whether it may make sense to reflect a bit more of their structure here.
In the case of ISCO/ESCO, the lower-level ESCO Occupation ID (P4652) classifications (with a decimal point) tend to match particular job titles, so so far people seem mostly to have been able to match existing items to them as external IDs. (A huge amount still to do, but watch this space). The higher level ISCO-08 occupation class (P8283) classes can be more specific to the particular classification, and many of the levels have had entries created for them by users such as User:Daniel Baránek in very much the manner you talk about. (In the report linked above these tend to be recognisable as having typically 0 sitelinks and typically 3 statements)
To what extent should we try to merge these with items we already have, when there are such items that appear appropriate?
I think (as per Arthur and Vicarage) we probably should try to merge these, when we have items already existing or from other classifications that appear to be a "close match".
But it depends how much people like their items fuzzy or sharp, inclusive or distinct, whether people are lumpers or splitters. There are people who believe passionately that our items need to be as sharply defined as possible, so that if two concepts are not exactly equivalent (in respect of both meaning and scope), then to be clean they need to be in different items. Myself, I tend to be more of a "lumper". I tend to think that with only a finite number of items, that means there is only going to be a finite resolution with which we (wikidata) can describe the world, and with finite resolution some degree of fuzziness is inevitable -- we're not going to have an infinite amount of items; and also, if we separate things out too much, we're going to lose important co-referencing between things that are pretty close.
And there are mechanisms that we have evolved to deal with a certain amount of that fuzziness. For example, suppose an item is instance of (P31) occupation group according to ISCO-08 (Q108300140) (an important statement to indicate that this is the fundamental item for the particular ISCO class, since many items may share the P8283 classification). Yet even when that statement is present, we know to expect that (due to a degree to potential item fuzziness) there may be statements that may not be exactly true for the ISCO class; or IDs for other classification systems that may not be quite exactly equivalent; or subclasses that may be outwith the ISCO class. We know that if we want an authoritative name for the ISCO class we should look to its subject named as (P1810) qualifier, not the wikidata item label; and that if we want an authoritative definition and explanation of that ISCO class specifically then we should follow the ISCO link, rather than just rely on the item statements and wikidata description. The wikidata item should IMO be a "close match" to an external analogue, but it may not be exact.
And yet, and yet. There is a spectrum. How "close" is close enough? When does it become not close enough?
Yesterday I merged existing item allied health professional (Q55071047) with Q108305364 "paramedical practitioners" created for ISCO class 2240 and Q108289389 "Paramedical practitioners" created for ISCO class 224. I think this is correct, and the two (or three) describe broadly the same thing -- but looking at eg the MESH tree [2] and comparing it to the ISCO class 224 / 2240 there are differences: many of the MESH subclasses are elsewhere in the ISCO classification, eg medical secretary (Q12325328) (ISCO 3344 = medical secretaries (Q108290444), which I would combine, though User:UWashPrincipalCataloger didn't diff), or community health worker (Q5154968) (ISCO 3253 / ESCO 3253.1), or (more examples) ...
So did I get this one wrong? Are "allied health professional" / "paramedical practitioner" authoritatively defined sharply different concepts, that we should therefore have different items for? Or are they essentially a way of saying the same thing (eg MESH gives "paramedical personnel" as a synonym), perhaps in its very nature slightly open-ended, that it does make sense to have a single item for, albeit that different classification schemes differ on what to include within it? For me, this is the kind of case which goes to the heart of what Vojtěch Dostál raises: when should we have separate items for classes in particular classification schemes? When should combine them? When should we lump, and when should we split? Jheald (talk) 18:15, 30 August 2022 (UTC)
cc also @Jeblad, Teolemon: who've been involved with this hierarchy; and also @PKM: who's done a lot of work on how to follow or integrate with thesauruses (eg AAT), and when to go our own waym particularly in the area of costume. Jheald (talk) 19:25, 30 August 2022 (UTC)
Very good points, and I largely agree with all you said there. One challenge implicit in your comments is that different classification systems come with differing hierarchies. Should each classification hierarchy be also adopted by the associated Wikidata items, or should we just leave that up to each classification system? Certainly the hierarchy a classification includes can suggest what the associated Wikidata item relationships might be, but I don't think such external determinations should force their view of the world on Wikidata. ArthurPSmith (talk) 18:33, 30 August 2022 (UTC)
There is a big danger in going for too high a granularity before the basics have been done. WD is full of holes in the areas I've looked at, we need to ensure that broad definitions apply to 95% of the items before even considering narrower definitions. And I doubt anyone who proposes a split actually goes through all the affected items reassessing them, they just update the ontology and expect others to implement it. Vicarage (talk) 18:58, 30 August 2022 (UTC)
Can you spell out what exactly the danger is? Presumably it'll be easy for you to do b/c it is big. For my part, that fact that domain B has holes is not a good argument against narrower terms in domain A. --Tagishsimon (talk) 19:18, 30 August 2022 (UTC)
The perfect being the enemy of the good. Vicarage (talk) 20:16, 30 August 2022 (UTC)
Nice idiom, but in this context it makes no sense. In what way does my improving things over here emperil anything over there? --Tagishsimon (talk) 20:20, 30 August 2022 (UTC)
Uneven development of a database means that queries aren't complete. Adding a new feature for a few items without the expectation that it applied to the rest in a reasonable timeframe gives a false impression as to WD's competency. A SPARQL query that only picks up 20% of the items it should is not a lot of use. Vicarage (talk) 20:46, 30 August 2022 (UTC)
*
Akuckartz (talk) 07:29, 9 August 2020 (UTC) JakobVoss (talk) Vladimir Alexiev (talk) 09:27, 5 July 2016 (UTC) TomT0m author  TomT0m / talk page 20:15, 21 September 2016 (UTC) Jneubert (talk) 09:22, 29 January 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) ElanHR (talk) 10:01, 17 March 2019 (UTC) Dcflyer (talk) 19:46, 29 March 2019 (UTC) ArthurPSmith (talk) 16:32, 1 September 2022 (UTC) Melmakko (talk) 17:34, 4 November 2022 (UTC) Maxime
Notified participants of WikiProject KOS for additional perspectives -- Jheald (talk) 23:41, 30 August 2022 (UTC)
@Germartin1, Jneubert: I completely agree with @Vojtěch Dostál:.
In addition to questions how this meshes with existing WD items, I'd also like to question the rationale and description of these items: "iTunes Books genre" and "subject category of the 20th Century Press Archives". Wikidata should describe "real-world things" and relate them to specific databases and catalogs using external-id. Wikidata should not copy items from external cataloging systems blindly.
Eg "African-American" is a genre in literature, music, visual arts, etc. Therefore "iTunes Books genre: Books > Fiction & Literature > African American" is terribly over-specific and should not exist. Vladimir Alexiev (talk) 08:00, 1 September 2022 (UTC)
These iTunes categories are specifically meant for iTunes genre (P10150) for podcasts see example Lex Fridman Podcast (Q109248984), as the genre property could be literally anything, and the iTunes genre is limited to two items set by the publisher. Germartin1 (talk) 09:15, 1 September 2022 (UTC)
Wikidata can accommodate literally anything, so there's no reason to create iTunes items that duplicate perfectly good existing items. For Lex Fridman Podcast (Q109248984), we have:
  • instance of: podcast
  • distribution format: audio podcast
  • genre: technology podcast, AI and data science podcast
  • iTunes genre: Podcasts - Technology, Podcasts - Science
How many times do you need to say this is a podcast? Isn't it better to say it in "instance of" and "distribution format", and then state "genre" or "main subject" as:
  • genre: technology, AI, data science, science
Why do you need these 4 genre items, and the 2 genre properties? If you made all these items, you are guilty of too much pre-coordination, which has multiple down-sides:
  • Pre-coordination leads to combinatorial explosion, eg "Italian love poetry, 16th century": where do you stop?
  • It leads to disconnected items. These 4 genres are not connected to relevant existing Wikidata items (technology, AI, data science, science).
I see at technology podcast (Q105012442) that you have useful lists of podcasts: you can make such combination pages when needed, but you still need to connect them to Wikidata, eg by using props like:
  • genre: technology
  • distribution format: podcast
-- Vladimir Alexiev (talk) 13:23, 1 September 2022 (UTC)
I am uncomfortable too with the current use of iTunes genre (P10150), and with items whose only reason for existing is to mirror the (for example) iTunes classification ; but at least I can somewhat see the reasoning for these things to exist. Conversely, I don’t understand at all things like AI and data science podcast (Q106882415) − to me “AI and science” is not a genre, it’s clearly something for main subject (P921) − Just because some outlet out there put together some list with arbitrary criteria does not make something a genre. Jean-Fred (talk) 14:56, 4 September 2022 (UTC)
@Vojtěch Dostál, @Jheald - This is a problem I have struggled with. The FISH archaeological vocabulary (and Portable Antiquities Scheme) has a classification Clothing Fastening, which has a high but not 100% overlap with Nomenclature for Museum Cataloging's Textile Fastener. After several days of wrangling possible solutions, I ended up making two items clothing fastener (Q111525943) and textile fastener (Q111525964) and linking them with partially coincident with (P1382). I didn't use either one in the class trees for the subitems, since plain "fastener" will serve. Not a perfect solution, and I still wonder if it makes more sense to merge clothing fastener (Q111525943) and textile fastener (Q111525964) as "close match". (But does that cause more or less confusion outside of Wikidata?)
This is a challenge I find frequently with Nomenclature, which has a slightly different view of the world than Wikidata. We organize sports clothing & equipment by type and then tag with <sport> = "baseball" or whatever. NOM has classes for "baseball equipment", "tennis equipment", etc. So far I haven't taken action on this latter issue. PKM (talk) 22:48, 3 September 2022 (UTC)
Items that aren't about exactly the same concept should not be merged. Wikidata's not going to run out of space. Silver hr (talk) 23:24, 4 September 2022 (UTC)
There isn't a single correct answer to this since each classification is organized on different principles, and has slightly different granularity (even in its various branches). Pre-coordination in general is bad, but in practice is used often anyway. Modeling with a second prop <sport> = "baseball" is certainly a valid approach and avoids pre-coordination.
Well-constructed hierarchies like AAT and Nomenclature can teach WD useful lessons about its class hierarchy.
The important point is that WD should not blindly copy private classification schemes (eg I see no useful lesson that can be taken from the iTunes classification) without giving some thought, and especially leaving them disconnected from other WD items. Vladimir Alexiev (talk) 11:14, 19 September 2022 (UTC)

@Vicarage, ArthurPSmith, Jheald, Vladimir Alexiev: Thanks for your thoughts on this. I am happy to see that most of the comments seem to acknowledge that this is a significant issue. I agree that it may be useful in some limited cases to keep the original nomenclature and classification scheme, but mostly it's just laziness on the importer's part, or misunderstanding of the import process. Now, what do we do about it? Would it make sense to start a list of Wikidata imports which went too far in blindly copying the original data model? That way, we could discuss the individual cases and make appropriate changes in a more systematic way. I often stumble upon an item like Books > Fiction & Literature > African American (Q110593300), but merging it or remodelling it makes no sense if we do not correct the whole import. Do you have other ideas which could help us label and correct imports which we see as problematic? Vojtěch Dostál (talk) 15:34, 3 September 2022 (UTC)

Racecourses getting listed as roads

Currently horse racing venue (Q11822917) -> race track (Q1777138) -> road (Q34442)

But it's not really ideal that racecourses for horse-racing (and also greyhound tracks, and goodness knows what other sorts of tracks too) are coming back from a query for eg Roads in Ireland.

There's a different subclass motorsport racing track (Q2338524), that we could limit the statement subclass of (P279) = road (Q34442) to (though do we think that even that is correct, generally?)

But is there an an appropriate class that could replace road (Q34442) on race track (Q1777138), to indicate that this is some sort of feature that one can progress along (whether by sportscar, bike, horse, or bobsleigh) ? Any thoughts ? Jheald (talk) 14:05, 31 August 2022 (UTC)

Curiously athletics track (Q1004435) isn't currently subclass of (P279) race track (Q1777138), but probably should be. Jheald (talk) 14:07, 31 August 2022 (UTC)
@Jheald: From my point of view, track and field facilities should not be a subclass of race track. An athletics facility consists of a racetrack, but also of other parts, such as a shot put and discus throwing facility. --Gymnicus (talk) 15:49, 4 September 2022 (UTC)
But an athletics track isn't the whole facility, it's just the track, and it is made for racing, so logically it's a race track. Silver hr (talk) 23:22, 4 September 2022 (UTC)

Cognates? Words that are pretty similar in 2 or more languages?

Hi, coming in from cognitive sciences, these language learning apps like Anki. I was actually looking for a datafile with the cognates of Netherlands/Dutch and Deutsch-German, but I can't find any on google. Here neither. What's going on? Thy and greetings from Belgium :) , SvenAERTS (talk) 13:12, 4 September 2022 (UTC)

Wikidata is about linked data and not about giving you a data file for certain subjects. You could however download the lexeme data and create the list yourself. It likely won't be complete given that our lexemes database is still developing but it gives you some cognates. ChristianKl ❪✉❫ 08:37, 5 September 2022 (UTC)

"Also known as" needs "add reference" to source aka claims

Can a way to add reference(s) to support claims of "also known as" at the top of Wikidata pages? One common source are the millions of maps, photographs and other files found at commons.wikimedia.org. Thanks -- Ooligan (talk) 18:13, 4 September 2022 (UTC)

No. There are properties enabling names and their references to be held as statements within the item. The main purpose of the alias is, in effect, as a foreign key, which is to say, a means by which users searching for data can find the item. --Tagishsimon (talk) 20:58, 4 September 2022 (UTC)
@Ooligan We have a few different subproperties of name (P2561). Use those to state the names and then add reference to those statements. ChristianKl ❪✉❫ 08:32, 5 September 2022 (UTC)

Removing topical categories in Wikidata

I suggest not to start devoloping topical category system in Wikidata. The parent category category:Topics was started on 1 August 2022, by user:Terrickisaiah555. Topical Wikiprojects should be enough for Wikidata (parent category Category:WikiProjects) Estopedist1 (talk) 12:35, 2 September 2022 (UTC)

I agree. Categories are a pre-Wikidata attempt at creating hierarchies, and they're vastly inferior to Wikidata. Silver hr (talk) 04:02, 3 September 2022 (UTC)
Agree. Delete. Category:WikiProjects serves the purpose. Vojtěch Dostál (talk) 16:46, 4 September 2022 (UTC)
I'm not sure I understand what you are getting at here. Categories are just another form of classification. Essentially a class of category. May as well use the built-in system for navigation within the wiki where possible and then use the item data properties to supplement or go beyond that as needed. Terrickisaiah555 (talk) 18:16, 4 September 2022 (UTC)
The Wikiprojects are designed more for connecting people who wish to improve items related to a topic or to perform a task such as bulk imports. I don't see how having the ability to categorize the data items would be to anyone's disadvantage. The categorization system is there for just that purpose. We may as well utilize it. We could continue to have the WikiProjects separate to allow easy navigation between the items as the projects that serve those items. The projects are often archived after having fulfilled their purpose, others are declined to be created for various reasons, and others are more specific than a Wikiproject would be created for. For all the various reasons cited above I recommend we keep the categories and continue building in a logical manner. Terrickisaiah555 (talk) 18:11, 4 September 2022 (UTC)
@Terrickisaiah555 I think that en:Category:Main topic classifications is clearly redundant in Wikidata. In addition, categorization of items is only possible via theirs talk pages, but it is nonsense. Categorization of properties is possible and maybe relevant and something is done here, see Category:Properties by subject‎. Nota bene! before you starting your solo project with category:Topics, then you must find consensus, or at least clear compromise. If this thread is not enough for you, then you can start Wikidata:Requests for comment Estopedist1 (talk) 18:55, 4 September 2022 (UTC)
@Estopedist1 I would have agreed with your perspective in a completely structured data context (just with P..., L..., Q..., ES... pages). But as long as there is textual information, I feel that we may need some form of classification of pages since some users may use it to find relevant information. I see no harm in their use. John Samuel (talk) 19:07, 4 September 2022 (UTC)
Oy, I didn't realize we have two redundant ways of grouping categories by subject. Category:Properties by subject and Instances of type of Wikidata property (Q107649491). We should ... probably not do that. JesseW (talk) 13:18, 5 September 2022 (UTC)
The categorization system is a relic of the MediaWiki software. Wikidata items are already categorized by their class or by any other of their property/value pairs, and anyone wanting to explore or focus on something can do so using SPARQL queries or tools like Reasonator. Trying to manually structure items with categories is a waste of time. Silver hr (talk) 23:11, 4 September 2022 (UTC)

I also discourage the expansion (and encourage the deletion) of Category:Topics, as redundant with organization that already exists. JesseW (talk) 13:22, 5 September 2022 (UTC)

Do I need bot permission when using OpenRefine + QuickStatments ?

I started doing reconciliation between Wikidata (Q2013) and Nintendo64EVER (Q109589665) games using OpenRefine (Q5583871) (and a custom crawler using Scrapy (Q368367)). Do I need to ask bot permission when used in combinaison to QuickStatements 2 (Q29032512)? (if it is needed, I will. Already asked permission once for something else, even if I eventually never did it). Marius851000 (talk) 07:47, 3 September 2022 (UTC)

How many edits do you want to make? GZWDer (talk) 08:26, 3 September 2022 (UTC)
Given there are 398 unique id, it should be something about that. I’ll first make sure to import the ID and making sure linking is right, before doing additional data import (which include avalaible language, published, developer, genre, publication date, barcode and serial number) Marius851000 (talk) 10:12, 5 September 2022 (UTC)
@Marius851000 I'd personally reserve Bot permissions for large scale imports (hundreds of thousands of entries) or regularly running jobs. Also potentially controversial jobs. If you want to do your diligence, start a discussion on a dedicated wikiproject and wait a few days if you receive any sort of suggestion. Vojtěch Dostál (talk) 11:14, 5 September 2022 (UTC)

New Personal profile page creation

Hi I want a little guidance of yours as I am new to this platform. Please tell me, is it possible to create a personal profile on this platform, if yes then how can I start creating it. Iamambika (talk) 11:47, 5 September 2022 (UTC)

In short, no, not really. Please do not even think of doing so, until you have learned enough about WD to understand why it is most likely inappropriate. thx. --Tagishsimon (talk) 12:28, 5 September 2022 (UTC)

Retraction notices for scientific articles

What is the proper model for items being retraction notices ? Like e.g. Retraction for Gilkes et al., Hypoxia-inducible factors mediate coordinated RhoA-ROCK1 expression and signaling in breast cancer cells (Q113732499).

I guess @Trilotat: might also be interested in this topic. Kpjas (talk) 15:36, 5 September 2022 (UTC)

https://www.wikidata.org/wiki/Wikidata:WikiProject_Source_MetaData would likely be a better place for such data model than the project chat. ChristianKl ❪✉❫ 18:21, 5 September 2022 (UTC)
Thank you, @Kpjas: for your interest. My method is to include both retraction notice (Q7316896) and scholarly article (Q13442814) to ensure the searches that are limited to scholarly article (Q13442814) will see the retraction item - but that reason might not be sound. I have included the retracted article as the main subject (P921). If the the retraction cites the retracted article, certainly one could/should add that cited article (if you can). If your workflow can manage it, I'd ask that you also add these to the retracted article:

Thanks for inviting my thoughts. I hope I've helped. Trilotat (talk) 16:30, 5 September 2022 (UTC)

@Trilotat: Thanks for your comments and helpful advice.
I suppose Wikipedia might benefit from data about retracted scientific papers from https://retractionwatch.com/. I think having up-to-date information about the retracted research in Wikidata would be an important aspect of the quality control. Kpjas (talk) 16:59, 5 September 2022 (UTC)

BTW

Daniel Mietchen (talk) 09:49, 5 September 2018 (UTC) Jodi.a.schneider (talk) 10:17, 5 September 2018 (UTC) DarTar (talk) 10:58, 5 September 2018 (UTC) Egon Willighagen (talk) 11:18, 5 September 2018 (UTC) John Samuel John Samuel 19:17, 5 September 2018 (UTC) Metacladistics (talk) 08:56, 6 September 2018 (UTC) User:TrWd2 (talk) 08:36, 8 September 2018 (UTC) GerardM (talk) 08:41, 29 September 2018 (UTC) Trilotat Trilotat (talk) 12:55, 14 February 2019 (UTC)

Notified participants of WikiProject Retractions Kpjas (talk) 17:02, 5 September 2022 (UTC)

Wikidata weekly summary #536

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • New requests for permissions/Bot:
      • MsynBot 9. Task/s: manage existing GND ID (P227) identifier claims
      • DL2204bot. Task/s: Add ExternalID values, edit/create items, add/edit lexemes, senses, forms
  • Events
    • Upcoming:
      • Wikidata's 10th birthday is coming up soon: you can contribute to the celebration video, prepare an event or a birthday present.
      • Next Linked Data for Libraries LD4 Wikidata Affinity Group call September 6, 2022: Dominic Byrd-McDevitt will talk about the Digital Public Library's Wikimedia program, an effort to provide national leadership around access and discoverability of digital collections by leveraging Wikipedia and its sister projects. 2 years ago, DPLA launched a digital asset pipeline to enable participating institutions in the DPLA network to share their collections with Wikimedia Commons. DPLA is continuing to innovate by taking advantage of Wikidata entities and Structured Data on Commons to continually synchronize data and improve discoverability. We'll discuss issues around large datasets, aggregation, reconciliation, and other challenges DPLA has faced. Agenda
      • Talk to the Search Platform / Query Service Team—September 7th, 2022 Date: Wednesday, September 7th, 2022. Time: 15:00-16:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CEST / 19:00 GST
    • Ongoing:
  • Development
    • REST API:
      • We are continuing to work on the PATCH endpoint to make it possible to edit existing statements (phab:T306934)
      • We started the security review process for one of the libraries we are using. Until that is finished this part of the REST API can unfortunately not be tested on beta Wikidata. (phab:T316523)
      • For anything but the PATCH endpoint, you can follow along development on beta Wikidata and see the latest docs. More details at Wikidata:REST API feedback round.
    • Lexicographical data: Continued addressing remaining issues found during testing (phab:T314064, phab:T312633, phab:T312652)
    • Continuing work on supporting sitelinks to redirects under some special conditions (phab:T278962)

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.

Very basic question about linking and unlinking Wikidata elements

Moved from Wikidata:Report_a_technical_problem#Very_basic_question_about_linking_and_unlinking_Wikidata_elements: Bovlb (talk) 15:19, 3 September 2022 (UTC)

Hi - long time Wikipedia Help Desk and Teahouse volunteer here that knows almost nothing about Wikidata. At the Wikipedia Help Desk, two Wikidata questions just came up. The first: two companies, Acxiom and Liveramp basically switched names, and their Wikidata files are not pointing to the right articles. This may be affecting what shows in the Google Knowledge Graph. See [[3]]. When you google LiveRamp, the LiveRamp Knowledge Graph comes up, but when you Google Acxiom, the LiveRamp Knowledge Graph also comes up. Might this be a mixup with the Wikidata? The second issue is about Emplifi. They bought a company called Socialbakers, and took them private, but Socialbakers' publicly posted financial data from their Wikidata still populates the financials fields of the Emplifi infobox. Is there an easy way to decouple the data so we can blank those infobox fields out? See [[4]]. Thanks in advance. Timtempleton (talk) 00:59, 2 September 2022 (UTC)

I assume we're talking about the items Acxiom (Q65119377) and Acxiom (Q344935). We have no control over what Google does, all we can do is ensure the information in Wikidata is as correct as possible. I notice that Acxiom (Q344935) seems to have the name "Acxiom" in other languages, and sitelinks to the pages for "Acxiom" in most languages, so there's definitely something that needs to be sorted out there. Sitelinks can be moved, or labels changed, but if the same organizations switched names then some historical record of that should also be present on the items, for example official name (P1448) with start time (P580) and end time (P582) qualifiers as appropriate. And references! On the second case, there's only one Wikidata item Socialbakers (Q13512460); Emplify (Q30672390) appears to be something different? It looks like you need a new item for Emplifi (the company that bought Socialbakers), or otherwise to correct the relationships. ArthurPSmith (talk) 15:45, 3 September 2022 (UTC)
@ ArthurPSmith: - thanks – yes, you are correct. I don’t have a lot of expertise with Wikidata so I was hoping somebody more skilled could fix whatever the problems are. I usually fix problems myself when I know how, on Wikipedia. If not, I will take some time to learn the details to see what needs to happen. Are you sure there’s no way to just simply decouple the incorrect Wikidata file from the Emplify article? That seems the simplest path. Timtempleton (talk) 00:39, 4 September 2022 (UTC)
Well, I'd be happy to help, but I don't know anything about these companies and your explanations have not been entirely clear here on what is needed. For example, are you talking about en:Emplify or en:Emplifi? What are the specific English-language articles that have issues - you can link to English wikipedia articles directly here using the [[:en:xxxx]] pattern. Are any of the other-language-wikipedia sitelinks correct for these items? ArthurPSmith (talk) 21:19, 5 September 2022 (UTC)
@ArthurPSmith: My bad - I typed Emplify instead of Emplifi. It looks like the incorrect financial data is no longer appearing by default. Timtempleton (talk) 00:01, 6 September 2022 (UTC)

Browse and search 2,400 SPARQL queries

SPARQL queries are hard to write. You often need inspirations and examples. Yet SPARQL queries are scattered in many wiki pages and so it is not easy to search for a given queries.

I have written a small script which extract SPARQL queries from wiki pages (https://public.paws.wmcloud.org/User:PAC2/SPARQLdataset.ipynb). My script creates a dataset of 2,400 queries :https://public.paws.wmcloud.org/User:PAC2/sparql_queries.csv. Last but not least I've written a small interactive notebook to browse and search in this dataset : https://observablehq.com/@pac02/hello-sparql-queries-dataset.

This is work in progress and may be improved over time. All your feedbacks and contributions are welcome.

Right now I extract queries from the following pages :

If you know more pages with many queries, tell me. PAC2 (talk) 17:42, 4 September 2022 (UTC)

No Wikidata:Request a query & its archive? --Tagishsimon (talk) 17:52, 4 September 2022 (UTC)
Oh great idea ! PAC2 (talk) 18:15, 4 September 2022 (UTC)
@PAC2: Nice initiative, but please remember that all text including SPARQL code from the Wikidata namespace on Wikidata is under thee CC BY-SA 3.0 License and you must credit the author(s) when distributing the code. --Dipsacus fullonum (talk) 21:20, 4 September 2022 (UTC)
You're right. I will add the good license. However, I'm not sure that original authors are always credited in the query of the week section. Wikidata:SPARQL query service/qotw/2022 doesn't credit authors of the queries. PAC2 (talk) 05:50, 5 September 2022 (UTC)
My humble contribution: User:Bovlb/queries. Consider also Special:WhatLinksHere/Template:SPARQL Bovlb (talk) 15:38, 6 September 2022 (UTC)
Thanks @Bovlb: PAC2 (talk) 20:08, 6 September 2022 (UTC)

Double entry

There appear to be two entries for "Reuleaux polygon", Q104840617 and Q4298917. I'm not sure who to raise this to or what proper procedure is, because I have no experience with Wikidata, so what is supposed to be done in this situation, if anything? MEisSCAMMER (talk) 20:16, 6 September 2022 (UTC)

@MEisSCAMMER: Good catch, thank you. They've been merged into regular Reuleaux polygon (Q4298917). --Tagishsimon (talk) 20:26, 6 September 2022 (UTC)

Question about item

Hi everyone! I was trying to define instance of (Q21503252) in Political Constitution of the Republic of Chile, 2022 proposal (Q100921333) but I couldn't decide what value it was. I thought of constitution (Q7755) but it is a "proposed constitution", and I don't know if textualism (Q7708515) fits. Do you have another idea? I would appreciate the help :-) Soylacarli (talk) 01:28, 6 September 2022 (UTC)

@Soylacarli: you could make a new subclass of proposed legislation (Q110548223) for "proposed constitution". I don't think also making it an entity of constitution (Q7755) would be totally out of place. I marked it up a little myself. BrokenSegue (talk) 02:29, 6 September 2022 (UTC)
Thank you! I'll do what you suggested :-). Soylacarli (talk) 22:13, 6 September 2022 (UTC)

Platform vs Operating system

Bundle ID (P7429) requires operating system (P306) to be set to iOS (Q48493) (among other options). However, for items like Psycholonials (Q108170641), platform (P400) is used instead of operating system (P306) for pretty much the same statement. Can Bundle ID (P7429) be modified to allow for this? If not, then is there a meaningful difference between the two properties (operating system & platform)? –MJL ‐Tauk‐☖ 20:35, 2 September 2022 (UTC)

Either operating system (P306) should be a subproperty of platform (P400), or User:Ghouston's suggestion from Wikidata:Project_chat/Archive/2018/06#relation_between_platform_(P400)_and_operating_system_(P306) should be implemented. Either way, that would resolve this problem. Silver hr (talk) 04:24, 3 September 2022 (UTC)
It was also discussed at Property talk:P306#Restrict to devices, but there was never a lot of enthusiasm for my suggestion. However, it still makes sense to me. Ghouston (talk) 05:32, 5 September 2022 (UTC)
I took a closer look, and it seems that like with a number of properties without a verb (such as country (P17)), the meaning of operating system (P306) is muddled. Specifically, it conflates two different properties: runs operating system (for hardware devices) and runs on operating system (for software). Since we should strive for semantic clarity, I agree with you that this property should be untangled.
As for how to untangle it, I think the key is in the following: hardware can run software, and software can run (i.e. be essential to the running of) software. So, both hardware and software can be a platform. Thus, logically, there is only a single property, runs on, and its inverse, can run. For example, Minesweeper (Q126194) runs on Microsoft Windows (Q1406) runs on IBM PC compatible (Q751046). From what I see, that's what platform (P400) already does, which would leave operating system (P306) with the possibility of being the inverse property at best, but since I'm against explicit inverse properties, I'd say it's unnecessary altogether. Silver hr (talk) 06:10, 6 September 2022 (UTC)
That would make sense. The inverse properties would generally be used by Wikipedia templates, e.g., a template for hardware devices that includes an operating system field. Ghouston (talk) 09:56, 8 September 2022 (UTC)

Redundant subclasses?

I'm new to Wikidata and have a question about subclasses that a search didn't answer. Is there a consensus as to whether is is desirable to specify subclasses that could also be derived from a more specific subclass? For example, Toy Story (Q171048) is classified as both animated feature film (Q29168811) and feature film (Q24869). But we can see that every animated feature film is necessarily a feature film (per https://www.wikidata.org/wiki/Q29168811). Would it be cleaner to omit the feature film subclass from the Toy Story entry, as for example with the movie The Lion King https://www.wikidata.org/wiki/Q36479? Jimblackler (talk) 09:36, 7 September 2022 (UTC)

@Jimblackler In my opinion, no, we shouldn't remove all redundant subclasses. Each statement can be derived from a different source, and maybe the less specific source (feature film reference) would disagree about the more specific class (animated feature film). Here, the statements are not referenced at all (just imported from Wikimedia project (P143) which is not a proper reference) and so I would not revert you if you removed the less specific class. Vojtěch Dostál (talk) 10:36, 7 September 2022 (UTC)
@Vojtěch Dostál: if there was a good reference for animated feature film (Q29168811) do you agree that any statement for feature film (Q24869) would be redundant? — Martin (MSGJ · talk) 12:21, 7 September 2022 (UTC)
@MSGJ No. In my humble opinion, it is useful to know which source classifies a given subject as Q24869 and which as Q29168811. Wikidata collect information from many sources and allow comparison between them. The other source can state that it is a feature movie, but disagree with the first one on the animated nature of it. That's why I think that both statements can be useful. Vojtěch Dostál (talk) 12:48, 7 September 2022 (UTC)
@Vojtěch Dostál: So, un-referenced redundant instance of/subclass of statements can and should be removed (I agree with that). As for referenced statements -- while I agree that in theory the redundancy (in the sense of the superclass hierarchy) of two such (referenced) statements is not a problem, I think it's generally harder to properly reference such statements than is widely understood. Specifically, unlike most properties, where the reference needs merely to confirm the statement on its face (i.e. date of death (P570) can be referenced by a source that says the item died on the stated date), in my view, a reference for a instance of (P31) statement needs to confirm that all the features implied by the whole of the superclass hierarchy above the value of the instance of (P31) statement are true. And a subclass of (P279) statement reference has to confirm that every instance of the item has all the features of the whole superclass hierarchy. It is very rare to find a source that makes such claims, and it is difficult to confirm (not least because the hierarchy on Wikidata shifts so often). It seems like people sometimes think all that is needed is for the reference to state that the item is an instance of the current label (in some language) for the value -- but that's not at all sufficient, and such a reference is, in my view at least, incorrect, and shouldn't bar removal of a redundant statement. JesseW (talk) 12:14, 8 September 2022 (UTC)
@JesseW Yes I agree that theory is nice but reality can be different (more complex). This is why P31 statements often do not have references. Vojtěch Dostál (talk) 12:21, 8 September 2022 (UTC)
Yep! And I think that's (mostly) fine, but it makes the case of two referenced instance of (P31) statements a very rare situation. JesseW (talk) 12:34, 8 September 2022 (UTC)
I would remove redundant subclasses to remove clutter and encourage accurate classification. A battlecruiser is a warship is a ship is a watercraft, but I'd hope only the first were used. And a reference that said it was a ship wouldn't be that helpful. Its like the location argument, where the administrative divisions are deduced, with the noted exception of country for access speed. Vicarage (talk) 10:46, 7 September 2022 (UTC)
It depends. IMHO: When there are two statements and one is direct subclass with reference and upper class without reference, it should be removed. When both have reference, keep both. JAn Dudík (talk) 14:38, 7 September 2022 (UTC)
Jimblackler is absolutely right. It's simply against Occam's razor (Q131012) to have redundant subclasses. A real ontology project (unlike everybody's favourite data dumpster) would not even think about it.--Jamy Oliver (talk) 17:18, 7 September 2022 (UTC)
That's entirely to ignore Vojtěch Dostál's fairly fundamental point about WD reflecting the diverse sources which may be used to define items, and reflects a failure to appreciate the use of rank in decluttering truthy values. Talk of "a real ontology project" is just bullshit posturing & completely unhelpful. --Tagishsimon (talk) 20:12, 7 September 2022 (UTC)

Bids for more than sporting events

bid for sporting event (Q51081147) is described as a bid for a sporting event, and has a category for sporting events. Obviously there are many more types of bids, from cities of culture, world heritage, commercial contracts and conventions. Should this term be broadened, or should separate entities be created for all the other types, which I'm not keen on as they are probably not a closed set. Vicarage (talk) 10:40, 7 September 2022 (UTC)

Sounds a bit like application (Q10413040)? I have added "bid" as an alias. — Martin (MSGJ · talk) 12:43, 7 September 2022 (UTC)
bid for sporting event (Q51081147) should likely subclass a more general item for bids. Either application (Q10413040) or something else. ChristianKl ❪✉❫ 17:00, 7 September 2022 (UTC)
I have changed the en label of bid for sporting event (Q51081147) — Martin (MSGJ · talk) 10:24, 8 September 2022 (UTC)

viaf, worldcat, or ??

I was trying to be a good netizen and semantically describe my book collection. Examples at schema.org often quote viaf.org and WorldCat (to terminate the endless rabbit hole of defining). Trying viaf I immediately find a specific author of interest, but they list only one associated work whereas I have at least 5 books by them. If I go to WorldCat, search by author name shows most of the other books, but many of them don't have cover images and the search brings up other people with the same name with no way (??) to narrow it down to the one specific individual. Neither of those are publicly editable, and viaf takes contributions from WikiData? Searching here, my test author does not show up at all. Should I try to contribute book, author, book covers scans, etc here or am I barking up the wrong tree? Arghc (talk) 20:06, 8 September 2022 (UTC)

@Arghc: Our book data here is woefully incomplete and it would definitely be nice to have it improved. The Inventaire project I believe updates Wikidata with book information when you add your books to it, so I think that might be a nice approach to get started. It's been a long time since I looked at that so not quite sure on status. In general yes there are issues with VIAF and WorldCat and Wikidata having multiple records for the same author and one record that is really multiple authors; disambiguating is hard. ArthurPSmith (talk) 20:26, 8 September 2022 (UTC)

We've got nearly 200 uncategorized Properties

I was looking at Wikidata:List of properties and wondered if all the properties were included in it. Turns out they aren't. There are around 200 that are only identified as instance of (P31) of

Wikidata property (Q18616576), not any subclasses of that. This query will show the full list -- let's work on reducing it!

I looked into this because I'd like a list of "general" properties, i.e. ones that aren't specific to a particular subject; we have quite a few of those, but I haven't found a good page documenting them. JesseW (talk) 05:01, 17 August 2022 (UTC)

Made a better query to try and flush out the "general" properties (or, to be more specific, add subject type constraint (Q21503250) to non-general properties lacking them, so only actually general properties lack that constraint, and can be identified that way): Wikidata:SPARQL_query_service/queries/examples#Properties_likely_missing_type_constraints. Currently has 94 results; I'll likely work to reduce that. JesseW (talk) 03:10, 21 August 2022 (UTC)
I've brought it down to 76; would be glad for help... JesseW (talk) 01:50, 25 August 2022 (UTC)

Now down to 163 -- thanks to whoever else has been helping with this. JesseW (talk) 01:47, 19 August 2022 (UTC)

And now 136. JesseW (talk) 16:08, 19 August 2022 (UTC)

Now 126. Thanks again! JesseW (talk) 03:10, 21 August 2022 (UTC)

User:JesseW re https://w.wiki/5aeP - can you add a column for the datatype? 89.14.54.216 17:32, 27 August 2022 (UTC)

@89.14.54.216 Sure, good idea. Done now. https://w.wiki/5dG5 JesseW (talk) 17:44, 27 August 2022 (UTC)

Now at 119 uncategorized properties, and 67 on maybe-should-have-a-type-constraint list. Let's keep going! JesseW (talk) 20:02, 30 August 2022 (UTC)

Sigh. I just learned that there is another, entirely independent hierarchy categorizing properties by subject starting from Category:Properties by subject. These should really be merged together... JesseW (talk) 13:24, 5 September 2022 (UTC)

It's possible that hierarchy is (mostly?) populated by navigational templates (which are at least somewhat useful) and which are found under Category:Property by topic navigation templates. So that's less terrible, but still -- we don't need two. JesseW (talk) 13:29, 5 September 2022 (UTC)
I'm a bit lost here. The top of this thread seems to be about whether or not property items have certain statements. The bottom has suddenly switched to the categorisation system - which properly starts at Category:Properties - which is to do with category tags on property item talkpages. Although arguably these two things are in one sense redundant, they are not redundant in terms of providing different UI views. Unclear how, or why "should really be merged together" should happen / should be done. --Tagishsimon (talk) 13:35, 5 September 2022 (UTC)
Sorry, I agree, this got somewhat confused. As I understand it now, there are multiple ways that our ~10k properties are grouped by subject. One is thru the instance of (P31)/subclass of (P279) system, with the root at Wikidata property (Q18616576) (there is also a metaclass at type of Wikidata property (Q107649491) but that doesn't matter much). This system is reflected into the subpages of Wikidata:List of properties by User:PLbot.
There is another, independent, way that properties are grouped by subject: navigational templates, like {{Music properties}} (most (or all) of which are in Category:Property by topic navigation templates. These templates are placed on the talk pages of the properties included in them (along with various other pages), and automatically add those talk pages to a different hierarchy of Categories, rooted at Category:Properties by subject (also, some property talk pages may be manually added to these categories, I'm not sure). There are also some non-subject groupings under the parent category, Category:Properties).
As for merging these two systems (which seems like a good idea, as they both serve the same purpose, just displayed in different ways), it would need to start with by manually reconciling the systems (making sure there were exactly the same set of items, templates, and Categories, and that they all contained the same properties; then it could be maintained with a regularly running bot job (maybe an expansion of that already done by PLbot) that kept them in sync. We could also drop the Categories (unless people really found that UI useful) and only keep the navigation templates and items (and List of properties subpages) in sync.
@Tagishsimon: Does that make more sense now? JesseW (talk) 19:34, 6 September 2022 (UTC)

Does anyone know where would be a good place to get more comments on the idea of merging the property Categories and subclass items? JesseW (talk) 01:26, 9 September 2022 (UTC)

If you have a concrete proposal then maybe an RfC? I don't see this problem as especially pressing since my understanding is that one set of categorization is generated using the other. Right? I would want to know who is using the categories and to what end. BrokenSegue (talk) 01:36, 9 September 2022 (UTC)
No, the two systems are independent, and both partial, and mislead people into thinking they are complete. You may have been thinking of the fact that both of the systems are used to generate one alternate display (each) -- the nav templates generate the Categories (mostly), and the subclass items generate the List of Properties. I'll see about putting together an RfC. JesseW (talk) 13:24, 9 September 2022 (UTC)

Looking for Commons & Wikidata wizards

Apologies if this message isn't in your native language and/or you've seen it somewhere else. Feel free to translate, distribute further, etc.

Hey all. I need to hire soon a contractor who is knowledgeable about these 2 beloved projects, which as you may recall are pretty high on the list of Foundation's priorities for this fiscal year. To be clear: you don't have to have, like, millions of contributions across both of them: we do need you to know a fair bit about the projects and their communities, and how they work. (This means that people who do not necessarily consider themselves Wikimedians, but do have GLAM or research experience on these 2 projects, may also apply.) Please see details on Greenhouse. If this message isn't for you, maybe you do know someone who would be a great fit! I think we may close our call in a week or so, FYI. Thanks for reading. Have a lovely rest of your week. --Elitre (WMF) (talk) 11:01, 8 September 2022 (UTC)

PS: Bonus link about getting a job at WMF generally speaking, one never knows...

@Elitre (WMF): are pay bands posted for this position? I don't see them anywhere. BrokenSegue (talk) 01:11, 9 September 2022 (UTC)

Thanks for asking, BrokenSegue. I don't think we do that - pay will vary hugely based on location. (I do believe that the topic is addressed by the recruiter during the interview process.) --Elitre (WMF) (talk) 09:34, 9 September 2022 (UTC)

Mandarin rollback

Can someone else look here: Special:Contributions/SCP-2000 at the rollback of descriptions in Mandarin. The rationale was "Mass rollback Nonsense + Cross-wiki abuse", but they all appear correct to me, am I missing something? RAN (talk) 22:24, 9 September 2022 (UTC)

Instance of=County seat

See Somerville (Q1088776) and all others "Instance of=County seat" that now give an error message, how should they be modeled? RAN (talk) 23:49, 9 September 2022 (UTC)

As already is: Q1088776#P1376. --Tagishsimon (talk) 00:12, 10 September 2022 (UTC)
Well, according to whoever put that constraint together, delete them, presuming P1376 has been populated. One could presumably add a qualifier subject has role (P2868) 'county seat' to the #P1376 value. That value as a P31 is just so much cruft if the established pattern is P1376. --Tagishsimon (talk) 00:59, 10 September 2022 (UTC)
@Richard Arthur Norton (1958- ), Tagishsimon: You don't necessarily have to delete it, you can also put it on the deprecated rank. There are different possibilities. --Gymnicus (talk) 14:00, 10 September 2022 (UTC)
Deprecated is not a good choice: suggests it is not the country seat, rather than suggesting that WD convention does not like 'country seat' as a P31. --Tagishsimon (talk) 15:25, 10 September 2022 (UTC)
  • I see about half of the entries have "county seat" in the description, I think if we standardize on that and P1376 we can delete the instance_of=county seat and not loose any valuable information. --RAN (talk) 15:12, 10 September 2022 (UTC)
Valuable information is/should always contained in statements. Whether 'country seat' deserves a mention in the description is not very clear. There are attributes of settlements to be expected in desciptions - e.g. country, state, &c. Less clear that 'country seat' is such an attribute. --Tagishsimon (talk) 15:25, 10 September 2022 (UTC)

Issue with Q1354775

There is a problem with the subclass tree, leading Silk Road (Q36288) to be an instance of a subclass of song (Q7366):

Silk Road (Q36288) > instance of (P31) > historic road (Q445741) > subclass of (P279) > memory space (Q1354775) > subclass of (P279) > song (Q7366)

This was created last month with a series of edits to memory space (Q1354775) by @Suna no onna:. The subclass edits seem to be ontologically incorrect, but the information is useful and I don’t know how best to model what is intended there. Dogfennydd (talk) 15:30, 10 September 2022 (UTC)

I'm not sure if I understood the issue, but, a "memory space" (lieu de memoire), is not a subclase of "song". A "Lieu de mémoire" can be a song, a geografical place (so as a road), a painting... so, you are right: memory space isn't a subclase of "song" and I erased it. Men (talk) 17:17, 10 September 2022 (UTC)

Revised Enforcement Draft Guidelines for the Universal Code of Conduct

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

Hello everyone,

The Universal Code of Conduct Enforcement Guidelines Revisions committee is requesting comments regarding the Revised Enforcement Draft Guidelines for the Universal Code of Conduct (UCoC). This review period will be open from 8 September 2022 until 8 October 2022.

The Committee collaborated to revise these draft guidelines based on input gathered from the community discussion period from May through July, as well as the community vote that concluded in March 2022. The revisions are focused on the following four areas:

  1. To identify the type, purpose, and applicability of the UCoC training;
  2. To simplify the language for more accessible translation and comprehension by non-experts;
  3. To explore the concept of affirmation, including its pros and cons;
  4. To review the balancing of the privacy of the accuser and the accused

The Committee requests comments and suggestions about these revisions by 8 October 2022. From there, the Revisions Committee anticipates further revising the guidelines based on community input.

Find the Revised Guidelines on Meta, and a comparison page in some languages.

Everyone may share comments in a number of places. Facilitators welcome comments in any language on the Revised Enforcement Guidelines talk page. Comments can also be shared on talk pages of translations, at local discussions, or during conversation hours. There are a series of conversation hours planned about the Revised Enforcement Guidelines; please see Meta for the times and details.

The facilitation team supporting this review period hopes to reach a large number of communities. If you do not see a conversation happening in your community, please organize a discussion. Facilitators can assist you in setting up the conversations. Discussions will be summarized and presented to the drafting committee every two weeks. The summaries will be published here.

MNadzikiewicz (WMF) (talk) 08:39, 11 September 2022 (UTC)

Parkinson's law still holding, I see. --Tagishsimon (talk) 08:42, 11 September 2022 (UTC)

Short dash to long dash

See Special:Contributions/2A02:3030:40F:8E3B:1:0:53AB:10CC where someone is just changing our standard short dashes to long dashes, should they be rolled back? RAN (talk) 13:23, 8 September 2022 (UTC)

It's worth a) getting the user to stop and b) confirming here that short dashes is the standard (my !vote: yes). After that we can think about reverting. --Tagishsimon (talk) 13:39, 8 September 2022 (UTC)
Most of those birth and death years were added unilaterally at the end of 2021/start of 2022 by a single user, so I don't think changing them to en dashes is doing any harm considering it's the correct way to show a range in dates. You could also argue for removing them all except in the rare occasions where name + description is ambiguous. —Xezbeth (talk) 11:58, 9 September 2022 (UTC)
I personally agree that the en dash is correct (even the notoriously typographically wrong en.wp seems to see it that way, w:en:MOS:RANGE) and that those lifedates shouldn’t be there in the first place. But this batch doesn’t do any good at all, it’s just tampering with details without any real benefit to anybody. --Emu (talk) 12:26, 9 September 2022 (UTC)
Life dates are one of the best means of disambiguation this Jane Smth from that Jane Smith, and descriptions are all about disambiguation. Talk of 'there should not be life-dates' is a) for the birds b) for people who do not spend hundreds of hours trying to link language wiki articles to WD items. In my personal experience, people who do spend hundreds of hours trying to link language wiki articles to WD items appreciate life dates above all other disambiguation strings. Nor do I agree than en dashes are "correct" in what is, mainly, a machine-readable environment. --Tagishsimon (talk) 15:12, 9 September 2022 (UTC)
Arguably we should solve the life dates problem with a javascript extension that adds it to the description based on the data. That said the reason the dates were stopped was because it was unilateral not that it was necessarily a bad idea. BrokenSegue (talk) 17:37, 9 September 2022 (UTC)
I don't see what the unilateral basis has to do with anything. Pretty much everything done on WD is unilateral, but ideally following sensible patterns. To the extent there is a question here, it is whether anyone can argue against the very widespread convention that DoB & DoD provide one of the most robust disambiguators within a summary description of a person. We observe Dob & DoD with few exceptions, in ODNB, VIAF, Project Gutenberg, IA and pretty much any serious source of data on humans. A pattern for WD person item description which omits Dob & DoD is just broken. --Tagishsimon (talk) 17:53, 9 September 2022 (UTC)
I agree that DoB and DoD are useful for disambiguation. And indeed you can use them for disambiguation in Mix’n’Match and OpenRefine. If your workflow doesn’t allow for that, then you should call for a software solution such as the one BrokenSegue described and not keep “tagging for the renderer” as our OSM friends would say. And as for the “widespread convention”: There is none. There are a few isolated examples that mostly are leftovers from a world without today’s databases technology. The “sensible pattern” here is not to duplicate data.
And on a personal note: I have disambiguated people for many hundreds of hours, this was actually my first contact with Wikidata. It’s more the other way around: Nobody who has spent hundreds of hours of their life figuring out the correct DoB or DoD, adding sources, setting ranks would consider it a good idea to have to correct dozens of descriptions in more or less obscure languages to reflect our current understanding of the best obtainable version of the truth. --Emu (talk) 18:30, 9 September 2022 (UTC)
  • Let me suggest again my format: There has been a push recently to add birth and death years (1900-2000) in descriptions to aid in disambiguation, but it has led to confusing label-description combinations like "John Smith husband of Jane Doe (1862-1939)" and "John Smith Mayor of Wikiland (1862-1939)" where the dates appear to be for the spouse in the first case, and the term of office in the second case. My suggestion is to move the dates to the start of the description field so they appear as "John Smith (1862-1939) husband of Jane Doe" and "John Smith (1862-1939) Mayor of Wikiland". That way they will match the order used in almost every encyclopedia, including Wikipedia. For example: "Abraham Lincoln (1809-1865), sixteenth president of the United States of America". --RAN (talk) 22:32, 9 September 2022 (UTC)
Yes, sensible. --Tagishsimon (talk) 22:58, 9 September 2022 (UTC)
if we are going to have the date ranges then yes we should do it this way. but that means we cannot do it automatically as was being done. but again it would be better in my mind not to put this in the description and modify the preview to extract this from the structured data. BrokenSegue (talk) 22:59, 9 September 2022 (UTC)
I have a similar problem with ships, where the name pool is smaller, and reuse is encouraged to reflect naval traditions. I like my solution with a ship name, and description <year> <class> <type>, ie HMS Hood (Q220239) is HMS Hood, 1918 Admiral-class battlecruiser. But its merely convenient that HMS normally means Royal Navy, otherwise do you add country/navy etc, do I chose date of launch, completion or commission, ships change class and country and it goes against wikipedia tradition which use (1918) or (51) as they are forced to have unique names. And while I advertise this in the relevant Project_Ships, no-one replies. I could generate these names automatically, either for my 3rd party site or to feed back, but edge cases abound and the data full of holes. Lots of questions in a backwater of the site, and I doubt I have the authority to impose my views.
For people different 3rd party users have different ideas of uniqueness and are best allowed to create their own patterns rather than impose a UI system, so it comes down to what's best for people inspecting the database on WD itself, and the key fact that all people are born and then die, so "John Smith", "(1862-1939) lawyer, Mayor of Wikiland" has least ambiguity, but imposes a parsing burden to remote the dates for general use.
BTW I wrestled with uniqueness for my 3rd party wiki, and ending up reusing Q values, DISPLAYTITLE and adding redirects with friendlier names. Vicarage (talk) 12:47, 10 September 2022 (UTC)


  • Have we ever considered creating a field that displays (YOB-YOD) and is displayed after the name to aid in disambiguation, it wouldn't be a field you fill in, it would be synthesized from existing data, like we occasionally do with "age at death". As we enter more and more people, we are going to need better disambiguation. I imagine one day we upload FAG and VIAF and LCCN, even though it would be exhausting to match and merge. --RAN (talk) 00:51, 10 September 2022 (UTC)
So again I disagree. Dates in the description = good, b\c the description is a commodity which can be reused elsewhere - on WPs and by 3rd parties; in OpenRefine &c &c. Let's just aim for high quality standard pattern descriptions. --Tagishsimon (talk) 01:14, 10 September 2022 (UTC)
the problem is that if the YOB/YOD changes in the structured data the description won't update. so this increases the maintenance burden. We should change the API to return an enriched description that is easy to fetch/generate by third parties BrokenSegue (talk) 01:44, 10 September 2022 (UTC)
I agree it's an unwelcome additional maintenance task / trap for the unwary. But I have no belief in an imagined technical fix. We fix the UI and the API and frig schema:description and there are probably ten other things to fix to make things consistent. And this against a historical backdrop of treacle-slow development of WD/wikibase. If we could back off a bit, to the position that dates in a sensible place in the description are considered normal & expected; and support not criticism is extended to users who take the trouble to implement same. --Tagishsimon (talk) 01:58, 10 September 2022 (UTC)
Again: Mix’n’Match already has the capability to do this. It’s not rocket science. Yes, the Wikibase developers seem to have very different ideas about priorities but that’s hardly a good reason to duplicate data. --Emu (talk) 09:30, 10 September 2022 (UTC)

Removal of lifespan in description, claim "no person by the same name, no need for lifedates in description"

Removal of lifespan [5] - I see no commonly accepted method to determine "need". And how can one proof "no person by the same name"? 78.55.155.134 19:29, 10 September 2022 (UTC)

either way the date range should go at the end so reverting was right. whether it's needed is an open question in the community BrokenSegue (talk) 19:34, 10 September 2022 (UTC)
I can partly see the reason. Having those dates at the front, but in a different form to the (XXXX-YYYY) we discussed above, does look clumsy for all the different languages, but then having all the descriptions is clumsy when its a trivial translation issue in this case. A more sophisticated system would have description and disambiguation fields and the expectation of automatic translation, but that's not what we have now with wikibase. Better to fix the format to a standard than do a petty removal. Vicarage (talk) 20:13, 10 September 2022 (UTC)
True: but equally, pointy & petty vandalism. It does not matter if the subject is the only person by that name on WD. A user comparing that subject with another person of the same name will likely benefit from DoB & DoD. It's really stupid: entering into a holy war to remove useful information because why? You lack the imagination to see that others value it even when they tell you that they do? --Tagishsimon (talk) 19:37, 10 September 2022 (UTC)
I think it's been made clear why people don't want to include the dates and it's not just a "holy war" or "not seeing the value". I see the value. I've benefited from the years being there. I just want us to do it in a more sustainable way. Basically we disagree on the practicality of implementing this in a better way vs. doing it manually in the description. BrokenSegue (talk) 20:19, 10 September 2022 (UTC)
@Tagishsimon I’m not really sure whom you are talking to. But it might be a good idea to tone down your language. --Emu (talk) 23:11, 10 September 2022 (UTC)

To have it in front is the most standard way. The span in most cases will have 9 characters, so if you have a table with one columne for the description the span will be aligned. And it is the only value that a) is the same in many languages b) is used in other catalogues. The () makes it longer, what for? It is weird, you may find it in flowing text, including in article titles, but here it is a dedicated field, the whole description can be put into (). When titles are imported from WP the disambiguator - without () - is often imported into the description field. For the technical aspect, tools can easily look into the dedicated fields for birth and death and copy/compare the data to the description. And maybe then the VIAF texts for WD items get better, they often stick out from all the others by lengthy texts in random languages - and no date, which is *the* number one cross-lingual disambiguator for probably each other VIAF-source. 78.55.155.134 21:14, 10 September 2022 (UTC)

it is just not true that wikidata has standardized on putting the dates upfront. if anything the standard is to put it at the end. but generally there is no consensus on including/not including. BrokenSegue (talk) 21:49, 10 September 2022 (UTC)
Standard is no DoB/DoD at all in descriptions. Simplicity has its value as well. —MisterSynergy (talk) 21:54, 10 September 2022 (UTC)
To the extend that we have a standard, I would say that it's what's done in the relevant model items. Before making any edits 4/6 of English descriptions had had the date and had it in the end. ChristianKl ❪✉❫ 09:18, 12 September 2022 (UTC)

Grazing ES translation

I translated the article Grazing from EN to ES (Pastoreo) but I can't add the spanish version of the article because the entry in wikidata is protected. Could someone add it for me? Thank you. Wyatt Abernathy (talk) 11:09, 11 September 2022 (UTC)

✓ added @Wyatt Abernathy Estopedist1 (talk) 14:15, 11 September 2022 (UTC)
Thank you! Wyatt Abernathy (talk) 14:29, 11 September 2022 (UTC)
@Wyatt Abernathy: Welcome to Wikidata! As you appear to be an established editor in good standing at your home project, I have granted you "confirmed" status. This should allow you to edit semi-protected pages for yourself in the future. Bovlb (talk) 23:40, 11 September 2022 (UTC)
Thank you very much! Boblb! Wyatt Abernathy (talk) 07:17, 12 September 2022 (UTC)

Raw data

Hello, world! How can I get raw data through {{#property:NAME}} parser function? Not "510 metre", but just "510". For example, {{#property:P2044}} (P2044). 178.121.20.191 05:54, 12 September 2022 (UTC)

I don't think there is a parser function that can return quantities with the units stripped away. The unit is part of the quantity so it would in my opinion be unlogical to remove it from #property results. You can use text manipulating parser functions like #replace or others to remove the unit after retrieving the value with its unit. Or you can use a module to get the data. Most Wikimedia wikis have one or more general purpose Wikidata modules that you can use for this, or you can write a new module for this in very few lines. --Dipsacus fullonum (talk) 09:52, 12 September 2022 (UTC)

Wikidata weekly summary #537

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Events
    • Upcoming
      • Next Linked Data for Libraries LD4 Wikidata Affinity Group Wikidata Working Hour September 12, 2022: Sixth session of our summer/fall project working with diverse children's book metadata. We'll be creating items for books (works and editions) in Wikidata. You are, as always, welcome to bring your own data to work on. All sessions in our project series will be recorded for those who cannot attend. Links will be added to the event page when available. Wikidata Working Hour Event page
      • Webinar: Querying Wikidata: All the Knowledge in the World. Sep 15, 2022 5:00 PM Central European Summer Time
    • Ongoing:
      • Weekly Lexemes Challenge #58, City
  • Tool of the week
    • View it! Tool - (based on Wikidata) allows viewing a multitude of images that depicts a given topic on Wikipedia.
  • Development
    • REST API: Continued work on the endpoint for changing a statement (phab:T306934)
    • Lexicographical data: Made sure that the new Lexeme creation page also is shown in older browsers (phab:T311157), which was one of the last remaining issues before we can switch out the existing page (phab:T307866)
    • Continued work on enabling sitelinks for redirects under certain conditions (phab:T278962)
    • Spend a few days with people from Wikimedia Indonesia to discuss our partnership

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.


Raions in Lviv Oblast (Ukraine)

In Lviv Oblast (and possibly in other oblasts in Ukraine, too, I haven't checked that), there was a reform of administrative divisions in 2020. Many of the old raions (districts) were merged and ceased to exist; others were divided. I random picked a small number of Wikidata objects (towns and villages) and found that they were not updated yet. Possibly the whole field will need attention. Stilfehler (talk) 03:21, 12 September 2022 (UTC)

This was in the whole country. When I am done updating the English Wikipedia, I will start doing this here (unless someone else has done it by the time). Ymblanter (talk) 14:38, 12 September 2022 (UTC)
This is quite an endeavour, big compliments for your work (I didn't expect a single contributor doing this)! Thanks for the quick feedback, too. --Stilfehler (talk) 15:05, 12 September 2022 (UTC)
Sure. This is indeed quite some work, and it will take a lot of time. Ymblanter (talk) 18:28, 12 September 2022 (UTC)

Help

Hi. Could someone please help me merge Q66817533 into Q21505319. The second one (Q21505319) is the one that should remain. Thanks in advance. Rubpe19 (talk) 13:36, 13 September 2022 (UTC)

@Rubpe19: Done. --Tagishsimon (talk) 14:08, 13 September 2022 (UTC)

Confusion with psychopathy (Q366886)

Pardon me but how can something both be a personality trait and a personality disorder at the same time? Doesn't personality trait imply something non-pathologic? Trade (talk) 19:35, 13 September 2022 (UTC)

Psychoticism and Obsessionality are listed as traits at en:w:Trait theory, so I don't see a stretch in psychopathy being a trait and a disorder. It would be ideal if both statements at Q366886#P31 had references. --Tagishsimon (talk) 21:28, 13 September 2022 (UTC)

Contemporary constraint comparing a year with an exact date uses start of the year

Albacon 98 (Q111976591) has an exact date in September 1998, but it is part of a 10 year series that is quoted as 1988 to 1998. It generates a contemporary date range warning, when I believe that specifying just the year part should be considered to be the whole year for such comparisons. Certainly the message "The entities Albacon 98 and Albacon should be contemporary to be linked through instance of, but the latest end value of Albacon is 1998 and the earliest start value of Albacon 98 is 25 September 1998" is confusing. Vicarage (talk) 13:31, 12 September 2022 (UTC)

The problem is that dissolved, abolished or demolished date (P576)1998 isn't specific enough. It could mean January 1st 1998 or December 31st 1998, so there is a number of dates for which Albacon 98 (Q111976591) is not contemporary. I suggest putting in a specific dissolved, abolished or demolished date (P576) date in Albacon (Q111974124) so that it covers Albacon 98 (Q111976591). Silver hr (talk) 22:30, 12 September 2022 (UTC)
As we have a mechanism for storing fuzzy dates, internal comparisons like this should only use the elements provided by both. Quoting only a year for something should mean any time in that year, and not throw to 1st Jan Vicarage (talk) 03:16, 13 September 2022 (UTC)
Quoting only a year for something should mean any time in that year
I disagree. While that might make sense in some cases, in the case of dissolved, abolished or demolished date (P576) that would be clearly wrong. The event of dissolving something symbolically happens at a specific point in time (even if technically it might sometimes happen over a period of time). It doesn't make sense to say something was dissolved at any time in some year. At best you could say you don't know at what specific time in the year it happened, but that specific time exists regardless. Silver hr (talk) 07:02, 13 September 2022 (UTC)
Well, that's a point of view, deeply wrong though it is. We use a year precision date to mean that something happened in that year. It makes no sense to raise a flag as if that year meant 1 Jan. 1 Jan is not the year. This is probably something that should be raised on phab, although per Silver hr's intervention, good luck with that. --Tagishsimon (talk) 08:08, 13 September 2022 (UTC)
Care to elaborate on why you think my point of view is wrong (and "deeply", no less)? Many events don't happen over the course of a whole year, they happen in one specific moment of that year.
Also, what intervention? Silver hr (talk) 00:35, 14 September 2022 (UTC)
I explained that "We use a year precision date to mean that something happened in that year" and went on to say "It makes no sense to raise a flag as if that year meant 1 Jan. 1 Jan is not the year.". I don't think that requires any elaboration. Your intervention was the deeply wrong one I replied to, two or three posts up from this one. --Tagishsimon (talk) 00:41, 14 September 2022 (UTC)
And since I've asked you to elaborate, it should be clear I don't consider those two sentences adequate in that respect. Which of my statements do you consider incorrect (including the one in my previous answer), and why (and why "deeply")?
Also, I wouldn't call posts on a forum "interventions". Silver hr (talk) 00:52, 14 September 2022 (UTC)
Albacon (Q111974124) says that Albacon ran from 1980 to 1998. That's a conventional way of expressing the span of a recurring annual event: it happened in every year from 1980 to 1998. Albacon 98 (Q111976591) specifies that the earliest start value of Albacon 98 is 25 September 1998. That is completely consistent with the expression that Albacon ran from 1980 to 1998. Meanwhile the error message says "but the latest end value of Albacon is 1998 and the earliest start value of Albacon 98 is 25 September 1998." Yet there is no error there. A date precision 11 of 1998-09-25 is within a date precision 9 of 1998-01-01; see the precision definitions at Help:Dates#Precision. Which of your statements do I consider wrong and/or deeply wrong? These:
  • The problem is that dissolved, abolished or demolished date (P576) 1998 isn't specific enough. Deeply wrong. Per Help:Dates#Precision, 1998-01-01T00:00:00/9 is the full year, not just Jan 01; it is very conventional to use year date ranges for annual recurring events; and it works perfectly well in RDFland so long as date calculations take account of date precision - something the constraint being discussed does not seem to do.
  • It could mean January 1st 1998 or December 31st 1998, so there is a number of dates for which Albacon 98 (Q111976591) is not contemporary. Deeply wrong again, despite having an element of rightness. The key here is that there is a number of dates for which Albacon 98 (Q111976591) is contemporary
  • While that might make sense in some cases, in the case of dissolved, abolished or demolished date (P576) that would be clearly wrong. That's a deeply wrong statement. It is not clearly wrong to say that an annual recurring event was dissolved, abolished or demolished in a particular calendar year.
  • The event of dissolving something symbolically happens at a specific point in time (even if technically it might sometimes happen over a period of time). is just a muddle of words, although I think I grok what you are trying to say: that a more precise date could be used. Yes. A more precise date could be used. But the less precise date is still accurate, and a less precise date is still capable of being used in a contemporary date calculation without throwing an unnecessary error.
  • It doesn't make sense to say something was dissolved at any time in some year. It does make sense to say that. We say it all the time. And it is workable in RDF.
  • At best you could say you don't know at what specific time in the year it happened, but that specific time exists regardless. Again, another muddle, not adding any light. --Tagishsimon (talk) 01:26, 14 September 2022 (UTC)
I agree that this is a bug which should be fixed. — Martin (MSGJ · talk) 08:36, 13 September 2022 (UTC)

how to model a "latest start date"

Hi, I created a Wikidata item for a periodical called the Utah Monthly Magazine. I know that it had started by 1890, but I also know that it started before that, because the 1890 issue is "volume 7". How do I model that data? Rachel Helps (BYU) (talk) 21:12, 12 September 2022 (UTC)

Okay. There is a wrinkle in this, in that before volume 7, it was known as "Parry's monthly magazine." Is there a way to convey a title change in a periodical? If there is a periodical help page, I'm happy to read about it. Rachel Helps (BYU) (talk) 21:44, 12 September 2022 (UTC)
@Rachel Helps (BYU): inception (P571) = '1800s', qualifier latest date (P1326) = 1890. Then official name (P1448) qualified by start & end times for the various names of the publication. --Tagishsimon (talk) 21:50, 12 September 2022 (UTC)
thanks, @Tagishsimon:--would I also add the other names as aliases? And not create other Q items for them? Rachel Helps (BYU) (talk) 17:49, 13 September 2022 (UTC)
@Rachel Helps (BYU): adding as aliases would be a good idea. AFAIK the full-text search will find the P1448 values, but why take the risk; plus users may search by label & alias & should be rewarded. Whether & when to split an item into a series of item is a bit of a value judgement. If the subject is substantially the same thing, but renaming has occurred, then a single item probably best. If you think the renaming is one corner of a more substantial change, then perhaps another item. A reliable source treating the Utah Monthly Magazine as being distinct from Parry's monthly magazine would be a firmer pointer to the need for two items. --Tagishsimon (talk) 18:10, 13 September 2022 (UTC)
great, thank you! Rachel Helps (BYU) (talk) 21:47, 13 September 2022 (UTC)

Mix'n'Match catalog editor

Hi. Any idea why when I try to add a property to Mix'n'match catalog editor it doesn't save it (see this video)? No matter what I do when updating, I constantly get This catalog has no Wikidata property!. Question: Is there any guide on how to properly save a property in the Mix'n'match catalog editor? Regards Kirilloparma (talk) 19:53, 13 September 2022 (UTC)

Hi, did you already create a new Property for your catalog? If not there is a more rigorous process for creating a property (which you need to do on Wikidata before doing mix'n'match)--a property proposal. Rachel Helps (BYU) (talk) 21:55, 13 September 2022 (UTC)
The property has been created - Game World Navigator ID (P10383). I had a similar issue with failure to add a property after creation of the catalog, but it's not clear whether this was a) a bug in MnM or b) b/c Magnus created a duplicate catalog to which he attached the property. I was having issues with https://mix-n-match.toolforge.org/?#/catalog/5312 and Magnus created https://mix-n-match.toolforge.org/?#/catalog/5335 but it's not clear whether 5335 was his cure for the 'property won't stick' issue I reported w.r.t. 5312 (if so, then trashing your existing catalog and making a new one, specifying the property at the time of catalog creation, may be a cure here), or whether he has coincidently created a catalog which caused the 'property won't stick' issue. (all at, roughly, this thread: https://twitter.com/MagnusManske/status/1551605856697040898 ) --Tagishsimon (talk) 22:06, 13 September 2022 (UTC)
You can’t. You need to have some special MnM rights that only some users have. User:Gerwoman often helped me with updating catalogues but some changes are possible only for Magnus.. --Emu (talk) 22:16, 13 September 2022 (UTC)
In which case, I've pinged Magnus [6]. --Tagishsimon (talk) 22:21, 13 September 2022 (UTC)
Simple answer, you need to be a "Mix'n'match admin" to do that. The interface on that should be better, I'll have a look. I can make you admin if you want. --Magnus Manske (talk) 09:39, 14 September 2022 (UTC)
The "you are not a catalog admin" warning message had a bug, fixed now. I will also link the catalog to the property. --Magnus Manske (talk)

Help

Hi, I need someone's help. I would need you to merge Q113961434 into Q106708340. The second one (Q106708340) is the one that should remain. Thanks. Rubpe19 (talk) 05:39, 14 September 2022 (UTC)

@Rubpe19: I'll do the merge but you should probably take a look at Help:Merge#Gadget. Merging is really quite easy. BrokenSegue (talk)
Thanks, @BrokenSegue: will do. Rubpe19 (talk) 06:00, 14 September 2022 (UTC)

Resolving conflation with the "centre (Q68773434)" class item

center (Q68773434) is stated to be a subclass of (P279) of both facility (Q13226383) and organization (Q43229). This is a case of conflation: an item belonging to two conceptually different classes. Conflation is not uncommon in Wikidata. However, center (Q68773434) is rather important class item: it is currently a direct superclass to 12 other classes (https://w.wiki/5g9i) and more than 2,000 items are instances of these classes.

Because of this conflation at a high class level, more than 2,000 items that are instances of this class (or subclass of) are also conflated. This makes it difficult to monitor and resolve conflation at the named entity level (as pointed out in this project chat discussion).

Recently, Vojtěch Dostál (talk • contribs • logs) resolved more than 6,000 cases of conflation by removing the statement community center (Q77115)subclass of (P279)center (Q68773434). He also did this same on cultural center (Q1329623) (almost 500 instances). This is nice, but further conflation is bound to reoccur when, sooner or later, someone else reinserts subclass claims with the problematic "center" class.

I suggest that we resolve this issue at the root by resolving the conflation with the "centre (Q68773434)" class item.

Solution 1: removing the statement center (Q68773434)subclass of (P279)organization (Q43229).

Here's what this change would entail:

  • 10 out of 12 subclasses of center (Q68773434) are described as a "facility" (4 items), "place" (2 items), "location", "space", "premise", "center" (3 items). These subclasses could maintain their relationship with Q68773434.
  • Two subclasses of center (Q68773434) are defined or stated as an organization and would require edits:
  • The three Finnish authority files describing organizations would need to be moved to a new item describing a center as an organization.

Solution 2: removing the statement center (Q68773434)subclass of (P279)facility (Q13226383) and stop using this item to describe facilities.

This change would require:

  • Editing the different language descriptions of Q68773434.
  • Editing all 10 subclasses defined as places to make them subclasses of facility (Q13226383) instead.

WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Newt713 (talk) Bogger (talk) PantherStrix (talk) PKM (talk) Jklamo (talk) Nw520 (talk) Olyammon (talk) 03:46, 2 August 2022 (UTC)

Notified participants of WikiProject Nonprofit Organizations What are your thought? Fjjulien (talk) 02:25, 9 September 2022 (UTC)

I think a "center", in english at least, is a facility and not an organization. But this kind of conflation is very common and I almost think it's unfixable. BrokenSegue (talk)
In the UK we have many organisations called "centre"s that aren't tied to a specific facility. These can include think tanks such as the "Centre for cities" (the first Google search result on "centre for"). From Hill To Shore (talk) 06:30, 9 September 2022 (UTC)
Hi Fjjulien, you are right that this is a problem. However, I think that the root of the problem is that center (Q68773434) is not a relevant class at all. I see no sources on center (Q68773434), only links to a Finnish-only relevant concept, and the above commentaries suggest it has no clear definition. There are also no references for its subclasses. For exemple youth center (Q1302299) is about a class of facilities, but I see no reason why it would be a subclass of center (Q68773434), apart from its English label. They are not called centers in other languages. Classifications based on one language seem like bad practice to me. I think Vojtěch Dostál (talk • contribs • logs) was right about removing community center (Q77115)subclass of (P279)center (Q68773434). I would suggest:

Solution 3 : Each of the 12 subclasses should be changed to either subclass of facility (Q13226383) or organization (Q43229). Stop using center (Q68773434) as a class, don't make it a subclass of organizations nor facilities, and delete it or, more realistically, keep it within the scope of its Finnish definition.

Arpyia (talk) 14:46, 9 September 2022 (UTC)
This suggestion seems sensible. If an item represents a concept that is not clearly defined (and in this case, the word centre merely seems to be a name arbitrarily given to some organizations or facilities), then we shouldn't have other items depending on such a vague item. Silver hr (talk) 18:32, 10 September 2022 (UTC)
@Arpyia  Support Your solution makes so much more sense than the two options I had identified. Presuming we go ahead with your solution, what would you recommend to minimize the risk that users re-insert a statement subclass of subclass of (P279)center (Q68773434) in a frequently used (and conceptually clear) class item such as community center (Q77115)? Adding usage instructions? Deprecating the statement center (Q68773434)subclass of (P279)facility (Q13226383) (in order to maintain scope with the Finnish authority files) with the reason conflation (Q14946528)? Any other suggestion for ensuring the ontology remains tidy after we've cleaned it up? Fjjulien (talk) 21:54, 12 September 2022 (UTC)
@Fjjulien I don't know. Find someone who can read Finnish and fill the center (Q68773434) item with necessary info (I still don't know what it's supposed to be about). Check once a year if someone changed something and tell them if they're wrong. More generally I'm concerned that class structures without references, and unsourced concepts, wont'be very useful in the long term because they are just opinions. For example, what constitues a youth center (Q1302299) is not clear either and it may vary according to different sources (and different times and places). I'd like to see serious sources about its definition, and then sources for why any particular place should be classified as such. We still have much work to do! Arpyia (talk) 08:08, 14 September 2022 (UTC)

✓ Done Thanks for your inputs; I have implemented solution 3. --Beat Estermann (talk) 16:17, 14 September 2022 (UTC)

EU VAT formatter URL broken

VIES changed their site and now EU VAT number (P3608) links are broken. Can someone help?

Discussion at https://www.wikidata.org/wiki/Property_talk:P3608#formatter_URL_broken Vladimir Alexiev (talk) 11:32, 14 September 2022 (UTC)

When we have a pdf or a djvu file where add it?

When we have a pdf or a djvu file at Commons where add it? Should it be added to "image=" or "full work available at URL=" or both? A pdf is both the cover art and the text. Ideally it should be migrated to Wikisource and then no need for "full work available at URL=". See: A Documentary History of Het (the) Nederdeutsche Gemeente (Q44079428) RAN (talk) 17:47, 14 September 2022 (UTC)

Probably document file on Wikimedia Commons (P996) - example: Q99954718#P996 --Tagishsimon (talk) 18:18, 14 September 2022 (UTC)
  • Perfect, thanks, I never came across that before. Should we switch all the documents that use "image=" ? I have been loading obituaries for years with "image=". --RAN (talk) 21:06, 14 September 2022 (UTC)
Yes, we should get around to that. Are you aware of https://hay.toolforge.org/propbrowse/ ... so many properties (many unknown to me); it does a good text search. --Tagishsimon (talk) 21:25, 14 September 2022 (UTC)

Francophone WikiConvention registration is open until the November 10 - two week banner on wikidata

Hi everyone, The francophone annual meeting is coming back from November 17 to 20. It will be held in person only, in Paris. The programm is available on meta and registration is open until November 10.
I would like to ask central notice for a banner that would show to french speaking users with more than 100 edits. Would that be ok with you ?
I asked the same question on wikipedia, the fr.wiktionnary, wikisource, and commons.
>Best regards, Adélaïde Calais WMFr (talk) 15:38, 15 September 2022 (UTC)

Linking to Kiwi Farm on Wikidata

On English Wikipedia there was a discussion which ended with the removal of Kiwi Farms URL from the article due to the the sheer amount of leaked deeply personal information (work place, adress, phone number, etc) published on the site (including two editors) and due to the site's long history of swatting and doxxing vulnerable individuals

The question is: Should Wikidata take the same step? Accoring to PBZE, linking to the site is a violation of global Wikimedia policy. Whether or not that is the case i will leave to someone more qualified @AntisocialRyan, Mahir256, PBZE:--Trade (talk) 02:38, 5 September 2022 (UTC)

Not sure whether to keep or remove the URL. I would prefer to keep and deprecate the URL that was blocked by Cloudflare, but I assume it will be operational again soon, so I'm conflicted. Thanks for making this discussion! AntisocialRyan (Talk) 02:43, 5 September 2022 (UTC)
can someone generate a SPARQL query so we can see how often it is being used? Are we talking about banning from all fields? Or just references? BrokenSegue (talk) 03:23, 5 September 2022 (UTC)
Just removing the URLs from Kiwi Farms (Q63225180). The URL isn't really used on Wikidata outside their item @BrokenSegue: --Trade (talk) 03:34, 5 September 2022 (UTC)
The entry on Wikidata was how the URL got listed on Wikipedia. If it gets erased off of Wikidata, that can't happen again unless someone manually adds the URL to Wikipedia, which is thankfully impossible now that Kiwi Farms is on Wikipedia's spam blacklist. PBZE (talk) 03:44, 5 September 2022 (UTC)
Hmm, the official website property is the one I'd most not want to remove (compared to references). We link to The Daily Stormer (Q19867869) for example. I'd want to see the Wikimedia policy that is being referenced. @PBZE: do you have a citation? Can we, for example, leave the dead URL and just not link the .ru domain? (Also it really shouldn't be marked deprecated but I guess I'm waging a losing war on the proper use of rank on wikidata if advanced wikidata users are using it in this way) BrokenSegue (talk) 03:47, 5 September 2022 (UTC)
I think the Internet Archive may have solved this issue in a better way--by restricting the material rather than permanently deleting it. Restrictions could include needing an accepted reason for accessing the material (for example, student studying online crime and writing about their observations, information needed for legal proceedings) and/or restricting access for a period of time until the potential harm has subsided and the matter becomes an event in history. Practically this isn't possible for Wikidata though. If this discussion leads to banning specific URLs, at the very least, the URL properties should remain but have perhaps <unknown> as the value, and a reason supplied by qualifier clearly stating the reason why the URLs have been omitted. Having no URL property at all is a wide open invitation for others to add it back again, thinking that no one has gotten around to adding the URL yet. There could also be follow on problems with trying to block URLs including people linking to websites (even legitimate ones such as court records) that contain URLs for blocked websites. Should these be blocked too? --Dhx1 (talk) 07:55, 5 September 2022 (UTC)
I tried modelling access restrictions and URL <no value> ideas at Tank Man (Q61775619) for consideration here as well. --Dhx1 (talk) 08:17, 5 September 2022 (UTC)
@Dhx1: I'm not sure I agree with this modeling. Either the Tank Man full work URL exists or it doesn't. It doesn't cease to exist in some jurisdiction. Now for kiwi farms we may want to model it as "no value" with a new "omitted/censored" reason for rank qualifier but that doesn't have this jurisdictional nature. BrokenSegue (talk) 18:30, 5 September 2022 (UTC)
My thoughts were along the lines of a person in country1 clicking a link may be breaking a law in country1, whereas a person in country2 clicking the same link may not be breaking a law in country2. How would we model the implications of a user in country1 clicking the link so they are made aware before they inadvertently click the link? On Commons, it is possible to add banners such as that present on [7] to advise users of jurisdiction-by-jurisdiction restrictions. I suppose we have access restriction status (P7228) / use restriction status (P7261) that could possibly be used on an item, with users expected to check these properties before using any URLs on the item. Thus URL properties wouldn't need any additional qualifiers--the information on implications of clicking such URLs is stored in access restriction status (P7228) / use restriction status (P7261) or similar instead. Dhx1 (talk) 04:01, 6 September 2022 (UTC)
If the website warrents a global ban, then it would make sense to put it on the global banlist. I don't really see a good reason of why we would think that not having the website on the global banlist but removing the informaiton from Wikidata is a good decision. ChristianKl ❪✉❫ 08:19, 5 September 2022 (UTC)
I agree, if it can be added to Wikidata then it should. The URL should be added to the banlist instead. AntisocialRyan (Talk) 15:08, 5 September 2022 (UTC)
None of the locally blacklisted URLs are globally listed. This reasoning is nonsensical @ChristianKl:--Trade (talk) 14:16, 6 September 2022 (UTC)
Didn't know that. Is there not a global banlist? AntisocialRyan (Talk) 16:14, 6 September 2022 (UTC)
There's https://meta.wikimedia.org/wiki/Spam_blacklist . If nobody on Wikimedia projects should link to a website the name of the website belongs on that site. ChristianKl ❪✉❫ 22:04, 6 September 2022 (UTC)
We generally URLs on the "spam blacklist" because they're used in abuse, not because they're a valid official site that we prefer not to provide because we don't like the website. I'm not aware of any local policy that would have us omit official websites. I'm not saying I like this website, but a clear policy would let us be consistent. Bovlb (talk) 01:08, 7 September 2022 (UTC)
given that none of the URLs we list right now even work I definitely don't think we need to take action. that said I generally agree with you if it does come back up. BrokenSegue (talk) 02:16, 7 September 2022 (UTC)
I agree that we don't have a process not to link to valid official sites because we don't like the website and I don't think we should have such a process. ChristianKl ❪✉❫ 20:48, 7 September 2022 (UTC)
I have been participating in the English Wikipedia discussion. I also participate in English Wikipedia in general. I do not think English Wikipedia currently has a policy or process for blocking sites for harassment. We block for spam, and we block for low-quality media like fake new and copyvio, but there is not a process in place for identifying whatever Kiwi Farms is and blocking such content. Bluerasberry (talk) 18:49, 12 September 2022 (UTC)
I have also participated in the RfC on WPen. My position is the same: we normaly give links to extremist, shady, or even illegal websites, most of the time without hesitation. I do not see blacklisting KiwiFarm as justifiable. Veverve (talk) 18:10, 16 September 2022 (UTC)

How to flag something needing correction/updating

Not a Wikidatan (and not interested in being one), but a Wikipedian of some experience. How do I best flag an item that is clearly out of date, or just plain wrong, and is in need of updating? (I'm right now looking at Q11643, but may have other candidates. I've left details at Talk:Q11643 on its problems.) 130.44.170.161 18:29, 16 September 2022 (UTC)

Putting the details on the talk page is great, and if it's more urgent or you just want to get broader/quicker response, posting here is fine. Thanks for the updates! JesseW (talk) 19:04, 16 September 2022 (UTC)

Missing selection options for occupation (P106)

It used to be when adding a new person to Wikidata, after selecting instance of (P31) human (Q5) that occupation (P106) could be selected as the next statement and would have a list of common options. The options list seems to have disappeared. The options list is there for other properties (human (Q5) for example for instance of (P31)) so I'm wondering if something happened? Or is this just something I'm seeing and not affecting other people? ArthurPSmith (talk) 18:41, 14 September 2022 (UTC)

Looks like https://phabricator.wikimedia.org/project/profile/2796/ is a hub for property suggester (Q86989962), and on mediawiki, mw:Extension:PropertySuggester. FWIW I checked on an item with P31=Q5 only; the UI next offered P21, and P21 suggested values, and next offered occupation, but no occupation value suggestions. Unlike you, I can't remember if it ever did offer occupation value suggestions. Might want to move this q. to Wikidata:Report a technical problem; possibly more likely to get informed answer there? --Tagishsimon (talk) 21:43, 14 September 2022 (UTC)
Property suggester suggests properties, not values. The value suggestions are based on constraints – occupation (P106) no longer suggests values because Lockal removed the one-of constraint (Q21510859) which specified the values. (Perhaps the practice of using deprecated constraints as pure suggestions should be documented better on Help:Property constraints portal; I think it arose organically a few years ago, we didn’t foresee it during development as far as I recall.) Lucas Werkmeister (WMDE) (talk) 09:20, 15 September 2022 (UTC)
My comment about this removal: User talk:Multichill#Clarification about removal of deprecated one-of constraints. I did not know that removing this statement affects someone's workflow though. As a short-term measure I agree with revert, but instead of documenting the practice of using deprecated constraints I still suggest to use a separate new property for autosuggestion system (or even Wikidata SPARQL query equivalent (P3921)). --Lockal (talk) 09:56, 15 September 2022 (UTC)
Ha, I never knew that about deprecated one-of constraints! But it's really not a big impact on my workflow - in fact I'm probably putting in better values now that I don't have the easy auto-suggested list to select from. But a dedicated property for this would make sense I think. ArthurPSmith (talk) 12:41, 15 September 2022 (UTC)
I proposed a new property to store the information: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#autosuggest_value ChristianKl ❪✉❫ 21:49, 16 September 2022 (UTC)

Global mess in Latindex identifiers

Hello.

Apparently in last April, the Latindex Portal (https://latindex.org/latindex/) changed its whole indexing system. Not only the url scheme, but also the identifiers themselves, and without any redirection (Yeah, very bad practice). Moreover, the new identifiers remain simple integers, so the old regexp remains valid and we have no way to distinguish old and new identifiers.

In Wikidata, Latindex ID (P3127) has been updated for the url scheme, but without any update for the identifiers. So, wikidata now provides a bunch of false links. For example, Nuevo Mundo, Mundos Nuevos (Q3346085) links to https://www.latindex.org/latindex/ficha/15703 instead of https://www.latindex.org/latindex/ficha/11055. I think that an automatic fix is possible but rather complex. FYI, a colleague of mine fixed the Mir@bel database (https://reseau-mirabel.info/) using the Latindex API :

  1. Retrieve the JSON data from the export of advanced research with no criteria (~15 MB) : https://www.latindex.org/latindex/exportar/busquedaAvanzada/json/%7B%22idMod%22:%220%22%7D.
  2. For each json block, retrieve the numeric identifier and ISSNs (ISSN-E and ISSN-P) as the external key.

I don't know if there is an existing script or robot able to fix this problem without writing a bunch of ad-hoc code. GAllegre (talk) 17:40, 12 September 2022 (UTC)

After 5 days of reflection, I think that the clearest solution is to add a new Latindex Property, and to deprecate P3127. I just added a proposal for that. Feel free to contribute to the discussion:
Wikidata:Property proposal/Latindex 2022 ID GAllegre (talk) 18:53, 17 September 2022 (UTC)

Property "Creates/Becomes"

I'm looking for a property that represents one text creating another. The main example is a Bill when passed, it becomes an Act. I'm not sure "replaces/replaced by" is the right fit, because it's not really being replaced. I would see "replaced by" being used in situations where an act has been rewritten in later years and completely replaces the Act of its name in a previous year.

On the inverse, an act should be linked to the Bill that gave rise to it. Would foundational text (P457) be the right fit?

Am I overthinking this distinction? Supertrinko (talk) 07:16, 16 September 2022 (UTC)

@Supertrinko Seems that has immediate cause (P1478) and immediate cause of (P1536) are used in this sense. See eg. Q98129062, ping creator - @Popperipopp:. Vojtěch Dostál (talk) 08:32, 16 September 2022 (UTC)
Perhaps Bill followed by (P156) Act. But if so, is it Act follows (P155) Bill, or Act foundational text (P457) Bill. Or both? fwiw, I've used foundational text (P457) for Statutory Instruments which arise out of Acts - https://w.wiki/5hwi . I see no evidence of P155 or P156 being used w.r.t. legislative items - https://w.wiki/5hwk - but that is not to say that the approach is wrong, merely that it has not been implemented?
However looking at a count of properties associated with Bills - https://w.wiki/5hwm - we see immediate cause of (P1536), but that arises mainly out of a huge import of Swedish legislative stuff and what is produced by the Bill does not seem to be Acts, but motions and committees - https://w.wiki/5hwo ... in the UK little or nothing relevant using P1536 - https://w.wiki/5hwt
For my money: Bill followed by (P156) Act, Act follows (P155) Bill AND Act foundational text (P457) Bill, and P1536 reserved for the thing which was caused by the Act, so Death Star Act 1999 immediate cause of (P1536) Death Star. --Tagishsimon (talk) 08:37, 16 September 2022 (UTC)
To explain the "Swedish legislative stuff and what is produced by the Bill does not seem to be Acts, but motions and committees" a bit: in the Swedish case, any bill commonly causes a flurry of counter motions and also committees to investigate the matter. And then we actually have modeled the legislative process in such detail so that we can see all intermediary steps before a bill becomes an act. For an example, see this image (sorry for not putting it on Commons yet) where we have a bill in blue in the middle and an act in grey on the right side (and also other related items). Ainali (talk) 10:12, 16 September 2022 (UTC)
@Ainali: Image link kaput, I think - "Oops! That page can’t be found." --Tagishsimon (talk) 10:24, 16 September 2022 (UTC)
@Tagishsimon Link fixed! Ainali (talk) 12:52, 16 September 2022 (UTC)
Fair enough, It just means every Act will follow to objects. The Bill that established it, and the Act that was passed immediately prior in the series. However to differentiate, the latter would be a qualifier against legislated by (P467) New Zealand Parliament (Q1520966), along with other qualifiers such as series ordinal (P1545). So there should only be one top level "follows". Supertrinko (talk) 20:56, 17 September 2022 (UTC)
has immediate cause (P1478) could work. I think it would make the most sense to use it as a qualifier against royal assent (Q1070654), because it is specifically the royal assent that gave immediate cause. Supertrinko (talk) 11:10, 16 September 2022 (UTC)

Image property showing weird label, rather than "image"

I added image (P18) to Scottnema lindsayae (Q21299221) and it has a label "Hieronim Kieniewicz (1867-1925) - Tygodnik Ilustrowany-1918 AD.jpg". (See https://www.wikidata.org/wiki/Q21299221#P18). I notice the same is visible at https://www.wikidata.org/wiki/Q60766070#P18, and no doubt in other places. I this a known bug? What is so special about c:Hieronim_Kieniewicz_(1867-1925)_-_Tygodnik_Ilustrowany-1918_AD.jpg? William Avery (talk) 09:32, 17 September 2022 (UTC)

It's a caching issue after this edit was made yesterday on Property:P18. —MisterSynergy (talk) 09:51, 17 September 2022 (UTC)
Thank you. The fact that edit was only in place for ten minutes and then affected edits made hours later is definitely "an issue". Even if that edit was accidental, it shows there is considerable scope for intentional disruption. William Avery (talk) 11:06, 17 September 2022 (UTC)
image (P18) should probably get a higher level of protection, given that. JesseW (talk) 13:18, 17 September 2022 (UTC)
Why? This is a one-off accident, by the looks of it. The property has no great history of vandalism; 2019 seems to be the last occurrence. Nor, bar a fairly strict protection, would it have prevented the autoconfirmed user who erred from erring. --Tagishsimon (talk) 13:32, 17 September 2022 (UTC)
A user just today removed a bunch of properties, and there was a similar mistake with the label back in June of this year. My main reason for suggesting a high level of protection (beyond autoconfirmed) is that the property is so very widely used that accidental changes to the label take a long time to make it thru the cache. JesseW (talk) 18:22, 17 September 2022 (UTC)
The next protection level would be full protection, i.e. admin-only editing. We do not do this with any other property page—even the most used ones—and also not with highly used item pages. Besides this, we do not have enough admin workforce to leave all this work to admins. Mistakes sometimes happen (as in this case), and if an autoconfirmed user intentionally disrupts via this method, they will receive a permanent block quickly. —MisterSynergy (talk) 18:51, 17 September 2022 (UTC)

Broken property

Property:P4169 is broken, in that Yale changed both the name of the server ("collection" => "collections") and, apparently, the naming schema ("Graham Sutherland" used to be "904" but is now, as best I can tell, "Graham+Sutherland%2C+1903–1980%2C+British"). These several thousand entries will need to be changed, probably by hand unless someone can figure out a way to automate this. DS (talk) 17:14, 17 September 2022 (UTC)

@Rob Lowe - Smartify: ^^
Please don't change anything because I still see the id in the data. It's probably a mistake on their side. Multichill (talk) 18:12, 17 September 2022 (UTC)
Are you suggesting we contact Yale and get them to fix things? DS (talk) 18:31, 17 September 2022 (UTC)
That seems like a plan. I've pinged them - https://twitter.com/Tagishsimon/status/1571273586245083136 - but if someone would like to email them, that, too, would be good. First step, after your report, is to find out what's going on / whether they're inclined to help. --Tagishsimon (talk) 23:04, 17 September 2022 (UTC)

Please explain

Why Delete My User page, I need a valid explain. I don't think you should just delete my message entirely, You shouldn't take away my freedom of speech, I think it's very unreasonable. please explain. [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 05:01, 18 September 2022 (UTC)

@A2569875: what page was deleted? Special:DeletedContributions/A2569875 shows only really old pages. Also your message looks very spammy and a little rude so I'm not surprised it was removed. BrokenSegue (talk) 05:26, 18 September 2022 (UTC)
@BrokenSegue: https://www.wikidata.org/w/index.php?title=Special:Log&logid=666774350 --[雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 05:34, 18 September 2022 (UTC)
already undeleted. Rationale "at first glance seems to be a test edit, mixing two separate user names". But my bad, we have also similar cases, e.g. User:Atcovi/User SWMT Estopedist1 (talk) 05:39, 18 September 2022 (UTC)

Preferred flag image for Bermuda

https://www.wikidata.org/wiki/Q23635 seems to have no preferred flag image; I cannot fix this myself because the page is semi-protected and I am not an autoconfirmed user. Any chance to get this fixed? Straight-ahead-dd (talk) 07:33, 18 September 2022 (UTC)

✓ Done - Mbch331 (talk) 10:03, 18 September 2022 (UTC)

Importing names of relations from OSM

Hi. I would like to import only the names and relations-ids of all hiking relations in Sweden to Wikidata. (we are missing 95% right now) I would like to hear if anyone here believes that copyright is a restriction to doing this. Under US law a name of something cannot itself be copyrighted because it is considered a fact (names can be trademarked and have certain protections through that, but I have never seen a trademarked trail in Sweden). The same goes for the relation-id. So those two I would like to import. So9q (talk) 13:06, 14 September 2022 (UTC)

It might fall under "A particular expression/presentation of the data that is represented in the form of a chart or table in a publication for example is protected under US copyright." [8] OSM's particular expression/presentation of the data is the name allied to the relations-id, which is to say, exactly what you wish to import. But IINAL &c. --Tagishsimon (talk) 13:15, 14 September 2022 (UTC)
Their copyright conditions are here: https://www.openstreetmap.org/copyright
It seems likely that the credit requirement is incompatible with CC0, but you make a good argument about names.
It might be better to discuss this with the OSM folk first. @bhousel Bovlb (talk) 16:25, 14 September 2022 (UTC)
You could ask at Wikidata_talk:OpenStreetMap, but it doesn't seem very active. Bovlb (talk) 16:27, 14 September 2022 (UTC)
A name itself is not copyrighted. If the source however comes from the EU there are suis genesis rights to the database. After Brexit the UK is not in the EU anymore so it's unclear to me whether or not the Open Street Map foundation has suis genisis rights for the database. The fact that they don't claim that they have any suis genesis rights on their copyright page also suggests that they don't feel that their data is protected by those.
Copyright comes through a creative act. Recently courts argued that AI generated art is not protected by copyright. I would expect that IDs are similar in nature. They are automatically generated by the computer and not created through a creative act by a human being.
If a human author lists information in a table, than the creative choice about the ordering of those items is protected by copyright provided there was a creative act. If you run a computer query giving you all the hiking trials in Sweden, then there's no creative act by a human that gives you the ordering of the resulting table.
Information about the exact point where a hikinh trial starts are more likely to be protected by copyright when a human makes a decision to pick a particular point as the official starting point but it's also debatable whether or not that constitutes a creative act. ChristianKl ❪✉❫ 16:34, 18 September 2022 (UTC)
Almost all of EU law applicable pre-Brexit has been retained in UK law and is applicable post-Brexit. The Copyright and Rights in Databases Regulations 1997 (Q99870938), which implemented Database Directive (Q3708968) in UK law, is still in force in the UK and I believe that Brexit withdrawal agreement (Q60476704) grants reciprocal recognition of rights to databased created in either the UK or the EU/EEA prior to 2021.
There's also the fact that one need not have to claim to have rights over a database to actually have those rights. Like all other property rights in UK law, one cannot simply waive the database right; it is property and therefore must be owned by somebody. This principal is (one of the reasons) why CC-0 exists rather than, for example, simply having people to put the copyright to things in the public domain (because they can't). --M2Ys4U (talk) 20:42, 18 September 2022 (UTC)

Merge subjective wellbeing (Q9208267) and well-being (Q7981051)?

It appears that subjective wellbeing (Q9208267) and well-being (Q7981051) are the same concept. Should they be merged? If not, what is the difference? — The Erinaceous One 🦔 05:30, 18 September 2022 (UTC)

It looks like subjective wellbeing (Q9208267) is about general prosperity (and differs from prosperity (Q1760011) in that that one is about economic prosperity), and well-being (Q7981051) is more about general mental and physical health etc. So, not merged, I think. I'm not sure how to clarify what the differences are though. Sam Wilson 05:42, 18 September 2022 (UTC)
Just because the English language has doesn't have different words for the two different concepts doesn't mean it's the same concept. One way to check whether it's the same concept is to look at the Wiki links. The German Wikipedia has an article about both concepts and as a general principle we don't merge items if there's any Wikipedia that makes a distinction between the concepts. That said, having good descriptions that make the concepts clearer without looking at the Wiki articles would be helpful. ChristianKl ❪✉❫ 16:00, 18 September 2022 (UTC)

Should we create a new property

Currently, has part(s) of the class (P2670) is used to describe the composition of a polyhedron (e.g. a cube has 6 faces, 12 edges and 8 vertices → cube (Q812880)has part(s) of the class (P2670)vertex (Q26401)quantity (P1114)8 (Q23355)), but has part(s) of the class (P2670) gives some warning: "conflicts-with constraint: An entity should not have statements for both has part(s) of the class and subclass of" and "item-requires-statement constraint: An entity with has part(s) of the class should also have a statement instance of".

And, I think "cube has 8 vertices" using has part(s) of the class (P2670) to express is not so appropriate. First, vertex (Q26401) and cube (Q812880) is not a class. Second, similar property(e.g. has characteristic (P1552), has part(s) (P527), instance of (P31)) do not seem to be available for use.

All in all, do we need a new property? [雪菲🐉蛋糕🎂] >梓< [娜娜奇🐰鮮果茶☕]（☎️·☘️） 07:53, 18 September 2022 (UTC)

Lord no, we do not need another property. Help:Basic membership properties documents that class items should use has part(s) (P527) and not has part(s) of the class (P2670) to point to other class items. Cube, vertex &c are all class items. --Tagishsimon (talk) 19:26, 18 September 2022 (UTC)
That's not to say, btw, that the current arrangements are well-thought-out, sane, or consistent with other WD modelling conventions; merely that this is what the Help page specifies, and the constraints try to enforce. --Tagishsimon (talk) 20:30, 18 September 2022 (UTC)

1900

In 2017, user:Reinheitsgebot added to the entry on John Rozum the statement that Rozum was born in 1900, citing SNAC. This is a result of SNAC's decision to use "1900" when they actually meant "we don't know". Is there a way to quickly find how many entries have this error, to fix them, and to prevent it from recurring? DS (talk) 18:21, 18 September 2022 (UTC)

If is is just 1900 we're concerned about, then the following identifies 148 items to check. The proper procedure would be to change the rank of the erroneous date statements to 'depricated' with a reason for deprecated rank (P2241) qualifier taking a value such as error in referenced source or sources (Q29998666); this helps to prevent the same wrong data being reintroduced in the future. I think that'd be a job I'd use wikibase-CLI to do. There is a q.: what does this source do with people who were actually born on 1900-01-01? There's little prospect of stopping it from happening on other items, bar someone running a bot to periodically check for the problem.
SELECT ?item ?itemLabel WITH {
  SELECT ?item ?date WHERE 
{

  ?item p:P569 ?stat . 
  ?stat prov:wasDerivedFrom/pr:P248 wd:Q29861311.
  ?stat ps:P569 "1900-01-01T00:00:00"^^xsd:dateTime
} } as %i
WHERE
 {
  INCLUDE %i
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". } 
}
Try it!
--Tagishsimon (talk) 19:15, 18 September 2022 (UTC)

Original purpose?

The Defense of Cadiz Against the English (Q5801323) was commissioned to decorate the Buen Retiro Palace (Q962117). Is there any way to express this relationship? I've added Buen Retiro Palace (Q962117) as the location for the initial time period, but that's not quite the same. I'm not seeing any helpful properties. Thanks! Calliopejen1 (talk) 05:47, 17 September 2022 (UTC)

@Calliopejen1 I don't want to get over-creative with properties I barely know, but what about created for (P9883)? Vojtěch Dostál (talk) 20:10, 18 September 2022 (UTC)
Vojtěch Dostál That seems reasonably close at least! Thanks! Calliopejen1 (talk) 00:58, 19 September 2022 (UTC)

aliases for species

Should Felis catus (Q20980826) have the common name "cat" as an alias? I would prefer that these only be included in house cat (Q146) as I need an unambiguous entity to show up in a text search for "cat". Nivekuil (talk) 17:54, 13 September 2022 (UTC)

It probably should, yes. It is not advisable to have a dependency on an alias being unique, pretty much for this reason. --Tagishsimon (talk) 17:58, 13 September 2022 (UTC)
@Nivekuil Why do you need an unambiguous entity to show up in a text search for "cat"? ChristianKl ❪✉❫ 17:45, 16 September 2022 (UTC)
I'm using Wikidata entities as tags for content, as opposed to the typical system of strings (hashtags). Easier to show than tell, so here's a link to the entry in question: https://dev.catablog.org/entry/66c1c2b5-5552-5600-870d-b52c5d6e5ddd/
You can see the tag interface after expanding the entry. In theory both cat entities should be related and searches should be smart enough to understand semantic relevance/locality such that using the "wrong" tag doesn't matter, but I don't have a system for that yet and am generally a bit skeptical of Wikidata's data quality so far. Nivekuil (talk) 23:53, 18 September 2022 (UTC)
@Nivekuil This isn't a problem that's special to cat. human (Q5) and Homo sapiens (Q15978631) show for example the same pattern. In general we frequently have the case in Wikidata where multiple items share an alias. If you want unambiguous entities for your tagging it makes sense to solve the problem on another level. When you search for your tagging you could decide that if there's a match in the label of items like finding "house cat" when you type "cat" you don't show the user any items that aren't matches in the label but are matches in the alias. ChristianKl ❪✉❫ 10:19, 19 September 2022 (UTC)
Sounds like a decent heuristic. Another one I've noticed is that lower QID numbers tend to be more relevant. Nivekuil (talk) 10:36, 19 September 2022 (UTC)

Qualifier for plate

Is there a qualifier for "plate" (as in a numbered illustration) or something like that? I am trying to add the bibliography for a painting using described by source (P1343). For some books, there is no page number (only a plate number), so I can't use the qualifier page(s) (P304). (Or technically I can, but it generates a regex error when I write page(s) (P304)="plate 367".) Is there some other way to deal with this? Or should I just do it with page(s) (P304)="plate 367" despite the regex error? Calliopejen1 (talk) Calliopejen1 (talk) 02:43, 19 September 2022 (UTC)

Perhaps section, verse, paragraph, or clause (P958)? (see also P304#P1659). --Tagishsimon (talk) 10:26, 19 September 2022 (UTC)

how to model a serial work

Hi, Q113952654 is a story first published in two parts in the Young Women's Journal. I have listed both of the references in "published in." Is there a way to distinguish between it being two parts of a serial work and a simple reprinting? I also put two different URLS in "full work available at URL" (the full work is available, but it is in two URLs). TIA for your advice. Rachel Helps (BYU) (talk) 21:48, 19 September 2022 (UTC)

@Rachel Helps (BYU): There are probably three main ways to handle this:

Article with broken label

If we search M?ssbauer, there are a lot of scholarly articles with broken titles. How we can fix them automatically? ChoKukSuho (talk) 03:39, 20 September 2022 (UTC)

looks like they were made with quickstatements. In my experience QS doesn't handle unicode well. BrokenSegue (talk) 03:48, 20 September 2022 (UTC)
You are quite welcome to ask for a query to find all the offending labels and produce a QuickStatements search&replace job from it. You will still need to review the changes before you make them however. People are usually quick to answer requests in the "Request a query" forum. Infrastruktur (talk) 00:14, 21 September 2022 (UTC)

how to edit category

I come up as "unmarried partner" on Peter Lodwicks Wikidatapage. We have been married for 30 years and I dont know how to change this category to "Married" or something. Can someone help with this please? Makro63 (talk) 10:33, 21 September 2022 (UTC)

I fixed it. It's now shows as spouse. ChristianKl ❪✉❫ 10:47, 21 September 2022 (UTC)
Oh - thank you so much!!:) Makro63 (talk) 13:16, 21 September 2022 (UTC)

Help of Farsi speaker needed

Concerning User talk:Arnikprintstand#September_2022 I believe that it wouldn't make a lot of sense if I were to explain the Notability criteria to that user in English again. Can someone explain it to them in their mother tongue? -- Dr.üsenfieber (talk) 13:00, 21 September 2022 (UTC)

Can reverting a quickstatements batch damage pre-existing information

My https://www.wikidata.org/wiki/Wikidata:Edit_groups/QSv2T/1663790467872 is full of errors, and I want to revert it, but I just wanted to check that if a QuickStatement replicates an existing claim, undoing the batch (which I guess did nothing for the repeat claim) it doesn't do any damage to the existing claim. Vicarage (talk) 21:30, 21 September 2022 (UTC)

@Vicarage: My understanding is, QS batches use Wikidata:Edit groups, and reverting the batch will indeed revert the edits your batch made, and not the pre-existing statement that your batch might have modified. No damage anticipated. --Tagishsimon (talk) 23:26, 21 September 2022 (UTC)

The other side

I've been wondering why so many people think that creating a wikidata item about themselves (again and again and again) is the key to fame and fortune. In my researches, I found the following articles. Some of the advice is good, and some is not (at least, from our perspective).

  • WikiData - How and Why to Set Up a WikiData Page for Your Brand: "All of this may sound like a lot to set up and maintain, and it certainly takes a bit of time. A partnership with a digital services company can help take a lot of this work off your plate. From the opening stages of finding out if you’re eligible for a Wikipedia page to the granular work of making sure your WikiData entry is optimized, uniting with a digitally savvy SEO company is a good way to ensure your Wiki content is up to snuff."
  • How to Create a Wikidata Page and Why it Matters for SEO: "As a member of a collaborative, anonymous, worldwide project, you're going to need to be social -- and that includes playing politics a bit, embracing the medium, and even working with a few jerks along the way. ... Marketers and SEO's are particularly unwelcome on Wikimedia Commons, whether our intentions are good or not. Things are a bit more lax on Wikidata than they are on Wikipedia, but I rarely make an change without a different editor checking in on my work. They are watching closely. ... Ease yourself into Wikidata; the editors take note of new, extremely active users, and also when radical changes are happening to entries. Build trust and credibility in the community before drawing too much attention to yourself. ... Create at least one backup account. This way, if your core account is banned or goes under scrutiny, you have a backup to fall back to. However, be aware that multiple accounts, if detected, will be deemed sockpuppets, in violation of Wikimedia's guidelines, and likely removed."
  • Why and How to Create a Wikidata Page for Your Company: "In order to fit into Wikidata’s culture, it will be necessary to interact with the community. Many are suspicious of newcomers and especially know-it-all’s that add too much information right away. So ease into it. Explore areas that interest you and contribute to things you are absolutely certain are correct. ... It’s best to gain trust and credibility by adding value not directly related to your company first."

Bovlb (talk) 21:20, 21 September 2022 (UTC)

  • That is not new, such blog articles are available for years now.
  • There have also been talks on "SEO and Wikidata" on several SEO-related conferences, followed by hands-on practice sessions to make new items about the participants. They sometimes even train to engage in undeletion discussions on conferences because they anticipate this step.
  • Marketers and SEO folks are usually not really interested in the Wikidata item itself; however, there is the idea out there that a Wikidata item directly feeds their Google Knowlegde Graph entry and boosts their search ranking generally (I am not sure how much both of that actually is the case).
  • In my opinion, seeking active engagement with creators of obviously out-of-scope content such as self-promotion (here unrelated, but also: vandalism) is not the best option. If the content is clearly unfit for Wikidata, delete it without further comment and only talk back to them if they show up by themselves. We otherwise raise false hopes and encourage them to try again.
—MisterSynergy (talk) 22:57, 21 September 2022 (UTC)
I'm starting to wonder if we should only entertain undeletion requests from established users. Bovlb (talk) 22:59, 21 September 2022 (UTC)
If there is a request, we should respond. But we do not need to feel bad for removing clearly out-of-scope, unfit data from this project in order to protect its integrity. This also means that in many situations we do not need to apologize, or help and encourage users who got their content deleted. On the opposite side of the spectrum, potentially permanent new users deserve a welcoming interaction if something goes wrong with their new items. —MisterSynergy (talk) 23:23, 21 September 2022 (UTC)
"Entertain undeletion requests from established users" is a really bad idea. Since community is seldom involved in deletion of items, at least a chance for community to review them is required. GZWDer (talk) 13:57, 22 September 2022 (UTC)
@GZWDer: I'm afraid I don't really understand your reply and how it relates to my comment, but I should explain that I was only being half-serious with my comment above. I entirely agree that our processes need to be transparent and open.
I was reacting to the fact that I see a lot of item creations, item recreations, and undeletion requests from new users whose only apparent purpose here is to create an item for a specific entity, and who do not exhibit any respect for the project, its goals, rules, and norms. I put a lot of effort into welcoming and mentoring new users, but when I encounter a string of people who have no interest in working with us, I find that very discouraging.
It was in that spirit of personal discouragement that I made my remark. I apologise for not anticipating how poorly my flippancy would come across in writing. Bovlb (talk) 16:11, 22 September 2022 (UTC)

Sitelinks to Redirects are now available for testing on test.wikidata.org

Hi everyone,

The community has long requested the ability to allow Wikidata to use Redirects and the target article as independent sitelinks, so that Wikidata and Wikipedia can be matched more appropriately in complicated cases.

As you may know, you can include sitelinks (also known as interwiki links or interlanguage links) on Wikidata Items that link to Wikipedia pages. Many Wikipedia pages cover more than one subject, so a Redirect may be created to a particular point on the target page, like a section header or an anchor. There is a workaround to do this: You can link to a Redirect page on Wikidata if the page was not a Redirect at the time the link was created. However, you cannot create links to pages that are currently Redirects. Our goal was to provide an official way to solve this. Implementing a solution has unfortunately taken us way longer than we hoped for, mostly because we struggled with the complexity of this topic and a fear of ripple effects.

Based on all the input that we got from you, we have now implemented the following functionality:

  • After testing is complete, you will be able to directly add a sitelink to a Redirect to an Item if you also add a Redirect badge (sitelink to Redirect (Q70893996), intentional sitelink to Redirect (Q70894304)) in the same edit.
  • It is possible to add a Redirect badge to an existing redirect sitelink. But if you try to remove a Redirect badge from a sitelink that points to a redirected page the edit is rejected.
  • Without using a Redirect badge the default behavior stays unchanged: If a Redirect is in place for a sitelink, the default behavior is still to normalize the sitelink (by following the Redirect). If the target of the Redirect is already a sitelink, the sitelink is rejected.

This new functionality is now available for testing on test.wikidata.org. Please let us know if the current functionality is sufficient, or if the feature needs more work before it can be enabled on Wikidata proper. If you encounter any issues or want to provide feedback, feel free to use this Phabricator ticket.

Cheers, Mohammed Sadat (WMDE) (talk) 12:39, 19 September 2022 (UTC)

(ec) @BrokenSegue: Sitelinks to redirects can be (or have been) created automatically when two articles on a wikipedia get merged, that each have a sitelinked wikidata item: one of those sitelinks will become a sitelink to a redirect. Having the two badges should let us be systematic in going through the current sitelinks to redirects and seeing which ones are actually wanted, compared to those which indicate a merge on wikipedia that ought to be matched by a merge here. HTH, Jheald (talk) 18:46, 19 September 2022 (UTC)
@MisterSynergy: It would also make sense to finally close the open RfC for https://www.wikidata.org/wiki/Wikidata:Sitelinks_to_redirects and make it into an actual policy. ChristianKl ❪✉❫ 09:35, 21 September 2022 (UTC)
I don't think we have an RfC to make that page a policy, right? Anyways, I think Wikidata:Sitelinks to redirects can and should still be improved, maybe even with experience we gather after the feature was actually rolled out at some point in the future. I am also not sure whether this should have policy status at all since it has pretty much the character of a simple help page. —MisterSynergy (talk) 09:44, 21 September 2022 (UTC)
I do think that it's useful to be able to say in discussion about redirect 'we do X because the policy says so'. I created the RfC back in 2020 https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Adopt_Help:SitelinksToRedirects_as_policy . It has nine people in favor and one against. ChristianKl ❪✉❫ 13:42, 21 September 2022 (UTC)
Oh I see. Seems my position hasn't changed in two years.
Anyways, the RfC needs an internal backlink to Wikidata:Sitelinks to redirects. It is otherwise difficult to find. Likewise, we should link internally to Wikidata:Requests for comment/Adopt Help:SitelinksToRedirects as policy from here. —MisterSynergy (talk) 16:52, 21 September 2022 (UTC)
It would probably make sense to generally adopt the {{proposed}} template to accept a parameter for the link to an RfC where the policy page gets proposed. ChristianKl ❪✉❫ 21:29, 21 September 2022 (UTC)
@Infovarius: See paragraphs immediately above? Jheald (talk) 21:21, 20 September 2022 (UTC)
The paragraphs do explain the difference and https://www.wikidata.org/wiki/Wikidata:Sitelinks_to_redirects does as well in more detail. On the other hand, it's an issue that currently the naming and description of the badges doesn't make it obvious to users what the difference is.
It's worth thinking about whether we can choose improved labels/descriptions that make it easier for users to understand the system. ChristianKl ❪✉❫ 09:38, 21 September 2022 (UTC)
Perhaps something like "sitelink which is now a redirect" would make the distinction clearer. - Nikki (talk) 05:29, 23 September 2022 (UTC)

Make the "Also known as" column wider

Cheers,

the default percentages of the columns of the standard view are:

15% Language 25% Label 35% Description 25% Also known as

Because it's a hassle to be unable to read the full name of an abbreviated organization or computer standard I would prefer:

5% lang-code 20% Label 35% Description 40% Also known as

with {| class="wikitable" width="75%" – unnessary to waste white space on the right.

Can this be achieved through Special:Mypage/common.js?

@SilentSpike: Ping to the expert.

Thanks in advance.--I take the Fifth (talk) 14:43, 19 September 2022 (UTC)

I prefer the status quo as well, but I think it's likely that you can get this through adding your own css. ChristianKl ❪✉❫ 10:17, 21 September 2022 (UTC)
@ChristianKl: I would also like to customize my UI. Are there somewhere example from other users?--雅人本田 (talk) 14:27, 21 September 2022 (UTC)
My own css is https://www.wikidata.org/wiki/User:ChristianKl/vector.css ChristianKl ❪✉❫ 14:39, 21 September 2022 (UTC)
@ChristianKl: Thank you very much for your CSS, I've borrowed it! It is possible override the widths

.wikibase-entitytermsforlanguagelistview .wikibase-entitytermsforlanguagelistview-header .wikibase-entitytermsforlanguagelistview-header-row .wikibase-entitytermsforlanguagelistview-aliases { 

   width: 25%;

} with .wikibase-entitytermsforlanguagelistview-aliases { 

   width: 30% !important;

}

Sorry for bothering you, but is it possible to string-replace e.g. English with en by using a user-js?--雅人本田 (talk) 15:33, 21 September 2022 (UTC)

@雅人本田: This should work:
function replace_termbox_language_names() {
	$(".wikibase-entitytermsforlanguageview").each(function() {
		var m = this.className.match(/wikibase-entitytermsforlanguageview-([^ ]+)/);
		if (m)
			this.querySelector(".wikibase-entitytermsforlanguageview-language").textContent = m[1];
	});
}
mw.hook("wikibase.entityPage.entityView.rendered").add(replace_termbox_language_names);
$(".wikibase-entitytermsforlanguagelistview-more a").click(replace_termbox_language_names);

- Nikki (talk) 05:52, 23 September 2022 (UTC)

Should we merge Joseph Powell (Q48977543) and Joseph Powell (Q18759351)

I think these items should either be merged together or linked somehow, as they refer to the same artist who is called "John" and "Joseph" in different sources. Can anyone please help?

Joseph Powell (Q48977543)

Joseph Powell (Q18759351) Ficaia (talk) 02:02, 23 September 2022 (UTC)

✓ Done by @Arlo Barnes — Martin (MSGJ · talk) 07:25, 23 September 2022 (UTC)

Migrate Help:Description into translation extension

Currently, a Template:DescriptionLanguages is placed atop the Help:Description page, with most of the links red. It would be a good idea to integrate the page into the translation workflow and replace the template with the language selector provided by the translation extension. After then we can delete the DescriptionLanguages template, which serves solely for this purpose. U.T. 03:10, 23 September 2022 (UTC)

Why did you try to unify the different guidelines in each language into an English version? For example, the guidelines for Latin characters are not applicable to kanji and kana. Afaz (talk) 07:47, 23 September 2022 (UTC)
This proposal has been rejected many times, For example read Help talk:Description#Change to translatable page? or Help talk:Description#Make translatable. Each language has its own rules and tradition, it's not possible to make rules valid worldwide. --β16 - (talk) 08:06, 23 September 2022 (UTC)

Announcing the preliminary results of the 2022 Board of Trustees election Community Voting period

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

Hi everyone,

Thank you to everyone who participated in the 2022 Board of Trustees election process. Your participation helps seat the trustees the community seeks on the Wikimedia Foundation Board of Trustees.

These are the preliminary results of the 2022 Board of Trustees election:

You may see more information about the Results and Statistics of this Board election.

The Board will complete their review of the most voted candidates, including conducting background checks. The Board plans to appoint new trustees at their meeting in December.

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee

MNadzikiewicz (WMF) (talk) 06:17, 23 September 2022 (UTC)

Occupation=slaveholder

See for example James K. Polk (Q11891) where Occupation=slaveholder, which gives an error flag because it isn't really an occupation. Is there a better way standardize it? Or should we make slaveholder an occupation? We want a single way to model so a query will pick them all up. RAN (talk) 20:44, 18 September 2022 (UTC)

position held (P39) springs to mind but it’s not really suitable. The most generic property would probably be subject has role (P2868), absent a more specific property this might be a good idea. --Emu (talk) 20:54, 18 September 2022 (UTC)
Probably worth trying to model land owner (Q1483709) and slave owner (Q10076267) along the same lines as eachother; there may be other role/occupation edge cases to consider. Ping @DrThneed: who was, iirc, one of the more active adders of slaveholder, based on the Legacies of British Slave-ownership person ID (P3023) source. --Tagishsimon (talk) 21:22, 18 September 2022 (UTC)
Thanks for the ping Tagishsimon. It isn't an area I've worked in for a couple of years - I added slaveholder as occupation as it seemed the most obvious way to model it at the time. I was working my way through people with an LBS identifier, trying to pick out those who held slaves (as not everyone in the database did) and then link them to all the things they owned, statues or paintings of them, buildings they commissioned, that sort of thing. My thoughts at the time were that while slaveholder isn't really an occupation it fits well there as it is a source of income that benefits the slaveholder. I was also anxious to stick relatively close to the way the data was modelled in the source - if the LBS calls someone a slaveholder or a slavetrader then I was comfortable modelling the data the same way in Wikidata. But as I say I haven't worked on this sort of data in a while, and it would be good for there to be a discussion and an agreed way of modelling it. Pinging @MassiveEartha: who has worked I believe much more in this area and might have some good suggestions. DrThneed (talk) 22:10, 18 September 2022 (UTC)
I thought social classification (P3716) was more appropriate than occupation (P106) for this item. I hope I don't sound like a slavery apologist, but owning something (be it a person or a house or a vehicle or a tool) seems rarely considered an occupation or profession in itself, but generally a means to a occupation or task (be it farming, construction, waging war, etc.): slave trader (Q17769800) is an occupation; slaveowner is not; homemaker (Q1934684) is an occupation, owner-occupier (Q4993251) is not; racing automobile driver (Q10349745) or auto mechanic (Q706835) are occupations, car-haver is not; farmer (Q131512) is an occupation, tractor owner is not. And on the flipside: enslaved person (Q12773225) is not classified as an occupation (rightly I think), but it might be a social class or a role in conjunction with occupations (involuntary though they may be) like laborer (Q19862215) or warrior (Q1250916) or whatever. I believe, especially in the US politics arena, many instances of Q10076267 were semi-bot added based on this Washington Post database (some editors also rather clumsily mass-appended "and slaveowner" to hundreds of descriptions, without regard for the prominence of the ownership). Perhaps there could be automated or periodic moves of Q10076267 from P106 to P3716, in a fashion similar to how certain described at URL (P973) strings get converted into their corresponding External identifier property. -Animalparty (talk) 00:17, 19 September 2022 (UTC)
My preference has always been for P106. It's easier to deal with from a logistical standpoint, and it is quite appropriate as slave ownership consists of both commercial and managerial actions and thus is well within the realm of occupation. Gamaliel (talk) 00:52, 19 September 2022 (UTC)
P106 is arguaby simpler, but is misleading for many of the LBS entries I recall reading; folk who had ownership interests in plantations, but were very far removed from any commercial or management activities, beyond cashing dividend cheques; often the widows or family of men who had gone to and died in far flung places. social classification (P3716) does look appropriate; not least, two of its three examples are 'enslaved person' and 'freedman', which is to say at the other end of the social spectrum from the slave-owner. --Tagishsimon (talk) 00:59, 19 September 2022 (UTC)
@DrThneed: and @Tagishsimon: thanks for drawing my attention to this. The most appropriate property WD currently has to model a person who is an enslaver is social classification (P3716). It's a similar to the controlled vocabularies used by Wikibase-built project enslaved.org, which uses 'Person Status' (p. 7) to express legal or social standing and 'Relationship' (p. 6) to express a legal connection such as "ownership" of the 'body, labour or reproductive rights' of another person. I'll add, having a Legacies of British Slave-ownership person ID (P3023) doesn't mean that person is an enslaver, the database includes a significant number of enslaved people and people who may have familial or other relationships to enslavers. And finally, owned by (P127) is highly inappropriate to demonstrate a legal relationship between an enslaved person and their enslaver, also it further encodes the dehumanisation and "thingification" of tens of millions of victims. MassiveEartha (talk) 20:27, 20 September 2022 (UTC)

 Info I believe that consensus has been reached for the use of social classification (P3716)slave owner (Q10076267). I have changed occupation (P106) accordingly. If you disagree, please feel free to undo my edits. --Emu (talk) 19:49, 23 September 2022 (UTC)

Merging should be intentional but currently happens without users being aware

On Wikidata we don't give users access to the merge gadget by default. It seems that someone at the Wikimedia Foundation decided that it's a good idea to merge Wikidata items in some cases without the user being aware of what they are doing. It's hard to understand what's exactly happening given but I asked one user who did a merge and who didn't seem to be aware that he did anything involving Wikidata.

https://phabricator.wikimedia.org/T236893 seems to suggest that those edits (tagged with "Sitelink Change from Connected Wiki") are made by something called "Wikibase Client linkitem (the jQuery UI thing)" but in my search I didn't found the phabricator ticket where it got discussed that deciding to merge Wikidata item without the user being aware is a good idea. ChristianKl ❪✉❫ 13:35, 22 September 2022 (UTC)

Adding a sitelink (which is what happened at bony labyrinth (Q262489)) is not merging ... — Martin (MSGJ · talk) 13:44, 22 September 2022 (UTC)
Yes, if you add sitelink from a connected wiki, you will do a merge of items if the pages you are linking from and to both previous had connected items. I think it been that way since the start of Wikidata. --Dipsacus fullonum (talk) 08:25, 23 September 2022 (UTC)
Vojtěch Dostál (talk) 08:34, 23 September 2022 (UTC)
I first saw "Sitelink Change from Connected Wiki" in cases where there actually was a merge, so I mistakenly assumed that it happened here as well. https://www.wikidata.org/w/index.php?title=Q25698031&oldid=828633164 and metropolis (Q200250) is the better example.
I started looking into this after reading https://www.wikidata.org/wiki/Wikidata:Bot_requests#Request_to_mass-merge_items_(2022-07-03) where this tool produced a lot of failed merges and there was a request to complete those failed merges.
Even if we believe that those merges are valid and should happen, the fact that they do happen should likely be document on help:merge. ChristianKl ❪✉❫ 10:03, 23 September 2022 (UTC)
Ah well, in that case I didn't know that either! But I don't see a problem with it, as it is definitely an intentional action by a human editor — Martin (MSGJ · talk) 10:16, 23 September 2022 (UTC)
It's a decision by an author that two Wikipedia pages are about the same topic. There are plenty of cases where we have two Wikidata items that exist separately and should not be merged even if Wikipedia editors want the sitelinks. One controversy we had a while ago was Wikidata distinction between pages that are about a fruit like "apple" and the species that produces them "apple tree". The only way to understand that the two shouldn't be merged is to look at the actual Wikidata items. We don't give new users access to the merge-gadget because we don't want people who don't really understand Wikidata to just merge items in cases like that. If Wikipedia allow the automatic creation of merges without the user having checked the Wikidata items to see if they actually deserve to be merged that's problematic. ChristianKl ❪✉❫ 10:53, 23 September 2022 (UTC)
I agree that allowing Wikipedia users to effectively merge items, without checking the items first, is a hazard. Vojtěch Dostál (talk) 12:33, 23 September 2022 (UTC)

please undelete work of new contributor

Hi! Is it possible to undelete work of new contributor, who was in the start of Wikidata training but before first review all of their edits were already deleted and invisible. https://www.wikidata.org/wiki/Special%3ADeletedContributions%2FMmargherita97

Thank you very much! --Zblace (talk) 09:23, 21 September 2022 (UTC)

What do you mean with "start of Wikidata training". Who trained them? ChristianKl ❪✉❫ 09:39, 21 September 2022 (UTC)
@ChristianKl - there was nothing problematic with content types for sure, just cultural info that needed to be better connected and referenced. They are not trained, but were just starting with @Tajkula as a content mentor and me for tech. I was to help but was busy with travel until yesterday, then I see it was all gone. --Zblace (talk) 09:50, 22 September 2022 (UTC)
The deletion rationale of Ymblanter was “Some kind of Croatian workshops, projects, concerts. Probably fails WD:Notability.” At first glance I would agree, nothing to restore here. Note however a (somewhat) related discussion here: Wikidata:Administrators' noticeboard#RfD_Wikidata_talks. --Emu (talk) 11:44, 22 September 2022 (UTC)
I must be patrolling Request for Deletion and was convinced by the rationale. If someone things the item is notable just undelete it. Ymblanter (talk) 11:59, 22 September 2022 (UTC)
@Zblace please give some evidence(s) that these Croatian workshops, projects, concerts meet WD:Notability Estopedist1 (talk) 08:09, 23 September 2022 (UTC)
@Estopedist1 I honestly can not understand why this attitude... It is 10 years of Wikidata, we should be celebrating and welcoming new users, especially those who fill in content gaps and instead you choose to delete without any feedback to the person who obviously just started contributing. Now you ask me to present evidence of notability without even making the effort to temporary undelete so I can see what has been deleted. This feels super alienating and bordering bot-like behavior. I kindly ask you once more to undelete items so I can check what was deleted and argue for their notability or not depending on what has been done and how. I might agree with you fully and partially but my priority is checking if anything is useful and worth saving, not to burn one new user who had good intentions of learning and contributing. Please assume good faith. --Zblace (talk) 14:00, 23 September 2022 (UTC)
✓ Done @Zblace special request fulfilled, items can be seen here Wikidata:Requests_for_deletions/Archive/2022/09/13#Bulk_deletion_request Estopedist1 (talk) 17:31, 23 September 2022 (UTC)
Now that they're undeleted, I've googled a couple of them and they seem eminently notable. References aside, they are well formed items. Given this, “Some kind of Croatian workshops, projects, concerts. Probably fails WD:Notability” (my emphasis) is very poor and somewhat abusive. --Tagishsimon (talk) 17:42, 23 September 2022 (UTC)
@Tagishsimon I beg your pardon? Once again, please watch your language. Calling legitimate RfD “somewhat abusive” is unacceptable. --Emu (talk) 19:39, 23 September 2022 (UTC)
It was not legitimate. It was abusive. These items appear to be notable. WD should not be deleting notable items based on a "probably". --Tagishsimon (talk) 19:45, 23 September 2022 (UTC)
Abuse is a serious allegation. Please provide evidence beyond your gut feeling or retract your allegation. Your current reasoning seems flawed, to put it mildly. WD:RfD is here precisely to determine if items are notable. How can it be “abusive” and “not legitimate” to use this page exactly the way it is supposed to work? --Emu (talk) 20:09, 23 September 2022 (UTC)
When a quick google search, such as for 'Art za zajednicu 2021' provides multiple hits, and the item is well formed, what, exactly, was your rationale for its deletion? how exactly is this a WD:N fail? Rinse & repeat * 7. --Tagishsimon (talk) 20:14, 23 September 2022 (UTC)
I take your answer as an implicit conformation that there indeed hasn’t been any abuse at all and WD:RFD has been used in a correct way (albeit in a way that you somehow don’t fancy). I’m gonna let this slide. Again. --Emu (talk) 20:28, 23 September 2022 (UTC)


Thank you @Estopedist1!
I quickly went through them and added few references so that original contributor can follow the pattern.
I agree with @Tagishsimon work done is far from bad and most link to prominent NGOs.
Hope this is enough not to delete them and also not to be as harsh to new contributor in the future...
--Zblace (talk) 18:38, 23 September 2022 (UTC)
@Zblace I disagree. At the current state of the items, they do not seem notable and should probably be deleted again. Some don’t even follow Help:Description. Please add sources to establish notability beyond doubt. --Emu (talk) 19:36, 23 September 2022 (UTC)
@Emu please feel free to delete if you think that action (probably) advances the goals of Wikidata.org as a Wikimedia project. I have next to zero interest in arguing over what kind of relations and reputation that kind of actions of administrators are being established among new contributors and those working on the content gaps. --Zblace (talk) 10:55, 24 September 2022 (UTC)
@Zblace I didn’t ask you to argue with me, I asked you to improve the items. You have about 4.000 live edits and have been active since 2020, so you are hardly a newcomer. --Emu (talk) 16:47, 24 September 2022 (UTC)
@Emu not sure how to communicate this better, but here it goes again: My goal is to support new contributors like @Mmargherita97 to get better at this and not to just keep saving content that is casually deleted without notices and care for newbies. --Zblace (talk) 16:58, 24 September 2022 (UTC)

Ethnicity statements again

Hello, there's a long-standing request at Wikidata:Bot_requests#request_to_depreciated_ethnic_group_only_sourced_with_P143_(2021-10-23) to remove unsourced ethnic group (P172) statements and deprecate those only sourced from Wikimedia projects. Since this could be controversial and pertains to many items, I'm notifying the community here that I'll do the job if there's not any significant opposition. Currently, most users are in favor of this change (see linked request page).

Link to queries for statements to be removed/deprecated:

thanks Vojtěch Dostál (talk) 09:18, 24 September 2022 (UTC)

SPARQL looks okay to me. --Tagishsimon (talk) 09:43, 24 September 2022 (UTC)
If you want to exclude the 100+ statements which are already deprecated, you can add
{ ?s wikibase:rank wikibase:PreferredRank } UNION { ?s wikibase:rank wikibase:NormalRank }
to the second query. --Dipsacus fullonum (talk) 10:50, 24 September 2022 (UTC)
I support the removal/deprecation from items for humans. Please exclude fictional and mythical entities from the removal/deprecation (see property description - even though better sourcing is very welcome, these statements are not as problematic in the case of a fictional person as in the case of a real person, I think). I spotted some other uses, as in the case of Aduana (Q20117809) (a clan). Wikidata:WikiProject_Ethnicity uses ethnic group (P172) for ethnic diasporas (see Belarusians in Armenia (Q26790703), for example). I think these should be excluded from removal, too. There are also some (1741) village (Q532) with a ethnic group (P172) statement (see for instance Bägäräktamaq (Q4478355)). - Valentina.Anitnelav (talk) 17:12, 24 September 2022 (UTC)
@Valentina.Anitnelav OK! Vojtěch Dostál (talk) 17:15, 24 September 2022 (UTC)

Question about "Frank van der Linden"

Frank Van der Linden (Q64021783) is connected with

He must have been 12 years old when writing about Nixon – I doubt it.--Holly Flax (talk) 18:05, 24 September 2022 (UTC)

@Holly Flax Good catch! I disentangled the entries. --Emu (talk) 19:00, 24 September 2022 (UTC)

New users not allowed to connect items in Wikidata?

Hello! I'm an admin in SqWiki. A new user in that project is trying to connect a new article in Wikidata (through the Wikipedia form) with the English homologue (and subsequently with the other languages) however the said user says it is not allowed to do so by the system. I tried it myself as an anonymous user and it appears to allow me (the procedure goes fine overall, didn't try to save). What could be going on? Any help would be appreciated. - Klein Muçi (talk) 19:16, 20 September 2022 (UTC)

Which Wikipedia form do you mean? ChristianKl ❪✉❫ 09:23, 21 September 2022 (UTC)
Some item may be (semi-)protected and can only be edited by (auto)confirmed users. GZWDer (talk) 14:59, 21 September 2022 (UTC)
@GZWDer, the page the said user wanted to link to is item Q477089. Is it protected somehow? I actually see it is now connected. I wonder who exactly did it.
@ChristianKl, the classical way on Wikipedia where you connect an article with its homologues in other languages. - Klein Muçi (talk) 23:35, 22 September 2022 (UTC)
@Klein Muçi yeah, in the top right of the item's page you can see it has a lock icon, meaning it's protected. Nicereddy (talk) 18:30, 24 September 2022 (UTC)
@Nicereddy, oh, yes, right. Well, that explains it then. I had never encountered protected items before. Thank you! :) - Klein Muçi (talk) 23:27, 24 September 2022 (UTC)

reopened railway stations

Hi folks, I noticed we have quite a few railway stations in the Netherlands that are currently open, but have a date of official closure (P3999) set to a date. Take for example Zoetermeer Oost railway station (Q13479616). This station opened in 1870, closed in 1938 and reopened in 1965. How to model this?

  1. Just have date of official opening (P1619) set to 1870 and no date of official closure (P3999). It's just a matter of time before bots or user scripts will add the date of official closure (P3999).
  2. Have date of official opening (P1619) set to 1870 and a deprecated date of official closure (P3999) set to 1938. This prevents the automated processes from adding date of official closure (P3999), but not sure if this is the best approach.
  3. Have a preferred date of official opening (P1619) set to 1870, a date of official opening (P1619) set to 1965, a date of official closure (P3999) set to 1938 & a preferred date of official closure (P3999) set to no value. Most complete, but maybe too complicated?

Any opinions? Multichill (talk) 18:29, 24 September 2022 (UTC)

Why can not we just have two values for P1619 and one value for P3999? Ymblanter (talk) 19:12, 24 September 2022 (UTC)
How can something that is open have a closing date? That seems a bit weird (and also triggers a bunch of constraints). Multichill (talk) 20:29, 24 September 2022 (UTC)
Probably 1938 closing date, rank normal; <no value> closing date, rank preferred -> truthy answer to 'is it closed' = no. Right now the closing date is deprecated; that's wrong. --Tagishsimon (talk) 20:34, 24 September 2022 (UTC)
I've come across this pb very often (current working stations but with closure dates because bots add closure dates). Just have the closure date as deprecated, so that bot will no longer add ... Bouzinac 💬●✒️●💛 20:55, 24 September 2022 (UTC)
No. That's a completely wrong use of deprecated; see Help:Ranking#Deprecated_rank - "The deprecated rank is used for statements that are known to include errors". Here, it is not erroneous to specify that the station closed in 1938. Rank allows us to specify that although the truthy situation w.r.t. closure is that there is not a closing date, there has been a closing date. I've already set out, above, how that is done. --Tagishsimon (talk) 06:59, 25 September 2022 (UTC)
I agree with Tagishsimon here. If the station was closed 1938, then that statement should not be deprecated. I like them also prefer Multichill's alternative 3. It will allow for simple searches for currently open stations and still indicate that it closed for a period. --Dipsacus fullonum (talk) 07:54, 25 September 2022 (UTC)
Yes, noted that Multichill 3 suggested this handling for the close date. I'm not sure I'm persuaded by M3's preferred rank for the original opening date, although since all options here seem problematic, and preferred 1870 opening mirrors preferred <no value> closing, it's probably a sensible way forwards. --Tagishsimon (talk) 10:20, 25 September 2022 (UTC)
Should the closure date NOT to be deprecated, then there should be a splitting...
  • The existed thing from date X to date of closure Y
  • The "new" thing existing from new date Z with a statement follows (P155) = the once existed thing from X to Y dates
I really don't like qualifyers such as applies to part (P518) because you cannot guess when they might happen. And if you query with a   MINUS { ?item wdt:P576|wdt:P3999 ?end_date. } , whilst hoping to find anything currently open, you might get false friends. Bouzinac 💬●✒️●💛 11:52, 25 September 2022 (UTC)
@Bouzinac: The point of adding date of official closure (P3999) with value "novalue" and preferred rank is that a query with 
   MINUS { ?item wdt:P3999 ?end_date }
will not exclude the station from the query results because the statement for the closing date in 1938 will not be the highest ranked P3999 statement, and because queries with the wdt: prefix will not match statements with a "novalue" snak either. --Dipsacus fullonum (talk) 12:19, 25 September 2022 (UTC)
@Multichill, another option is adding the closure and re-opening dates as items of significant event (P793) = closure (Q5135520) and opening (Q15051339) with point in time (P585) as qualifiers. Michgrig (talk) 11:05, 25 September 2022 (UTC)
  • @Multichill: Another way to model it, is as a building. The original brick building was demolished in 1938 and then a cider block and glass replacement was built, as seen in the current photo. You can create two entries, one for each building with appropriate inception and end times. Then only use the new building as the entry for the "railway station" in the various infoboxes and other visual aids we have for active railroads. Use replaces and replaced_by in each entry for the old and new station. We do that for hospitals and churches that occupy the same site, but demolish the old building (or it burns down). You can call the second entry "old Zoetermeer Oost railway station" or "Zoetermeer Oost railway station (1870-1938)". This would not work if the train no longer stopped there, and later restarted without a change to the physical infrastructure --RAN (talk) 19:57, 25 September 2022 (UTC)

Language labels for concepts which don't exist in that language

double-entry bookkeeping (Q192803) and Double-entry bookkeeping system (Q10783677) have the same label but apparently a distinction between the two concepts only exists according to the Vietnamese Wikipedia. Assuming that two concepts of double-entry accounting don't exist in English (or else there would be an English-language reference) does it make sense to have an English label for this uniquely Vietnamese concept? Nivekuil (talk) 06:16, 25 September 2022 (UTC)

First, yes, it does make sense for WD to carry an EN label for a concept alien to English speaking countries. You can haggle about exactly what the label is, but not about the need for a label. Second, I'm unconvinced that the two VI articles express different concepts, rather than being duplicate articles that need merging. --Tagishsimon (talk) 07:05, 25 September 2022 (UTC)
How would such a merge work? I'm not comfortable editing an article in a foreign language and I think Wikidata is one of the only cases where this need may arise. Nivekuil (talk) 10:07, 25 September 2022 (UTC)
It is for someone familiar with the language and concepts in the two articles, to merge them. It's not uncommon for language wikis to have duplicate articles; the need does not arise out of wikidata, particularly, so much as out of the observation that they seem to be about the same subject. Where I don't feel comfortable doing a merge in a language I don't speak, I've found that dropping an English language note on a forum on the language wiki concerned tends to work; at least, the merge happens, or someone explains why the merge should not happen or, (not often) nothing happens. --Tagishsimon (talk) 10:15, 25 September 2022 (UTC)
question asked. --Tagishsimon (talk) 10:25, 25 September 2022 (UTC)

Nephila clavata and Trichonephila clavata

Spider species: Nephila clavata (Q136925) was renamed to Trichonephila clavata (Q104386227). Nephila clavata is listed as basionym (P566) for Trichonephila clavata. Do these get merged or should they stay separate? Lights and freedom (talk) 18:55, 25 September 2022 (UTC)

@Lights and freedom: They should not be merged. Each taxon that is or have been used get separate items. You can see more about this at Wikidata:WikiProject Taxonomy and subpages. --Dipsacus fullonum (talk) 02:09, 26 September 2022 (UTC)

Graph documentation - defaultView:Graph

Do we have any good documentation what is shown in a graph like https://w.wiki/WBU that is generated with the tool EasyQuery:

  • the color of the circle yellow/blue
  • sometimes I feel a line is dashed
  • ...

Salgo60 (talk) 20:21, 25 September 2022 (UTC)

Think Wikidata:SPARQL query service/Wikidata Query Help/Result Views#Graph might be the best that's out there. --Tagishsimon (talk) 09:00, 26 September 2022 (UTC)

Economic Conditions of Costs or Prices

Hi,

Is it possible to store the economic conditions of a cost (P2130) or a price (P2284) or price (Q160151)? For example the cost of World Trade Center (Q11235) is listed as "900,000,000 United States dollar" but without knowing when that cost was incurred we can't understand the cost in comparison to other costs. 185.13.50.214 10:57, 26 September 2022 (UTC)

Agreed. Such statements should be qualified with point in time (P585). --Tagishsimon (talk) 11:17, 26 September 2022 (UTC)
great, thanks for the pointer, is it possible to link a point in time (P585) with another property i.e. price (P2284)
Yes. point in time (P585) is a general property useful as a qualifier for specifying the point in time that anything occurred. So, highly appropriate, and indeed prettymuch required for the reason you suggested, for uses of cost (P2130), price (P2284) or price (Q160151), and much besides. --Tagishsimon (talk) 11:40, 26 September 2022 (UTC)
brilliant, thanks for the help. 185.13.50.210 11:44, 26 September 2022 (UTC)

Wikidata weekly summary #538

Here's your quick overview of what has been happening around Wikidata over the last week.
  • Discussions
    • New requests for permissions/Bot:
      • بوٹ دا عثمان
        • Task/s:
          • Dual script support for Punjabi Wikidata labels and descriptions in Gurmukhi (pa) and Shahmukhi (pnb), taking a conservative approach (only making "obvious" transliterations).
          • Addition of labels and descriptions entirely consistent of information which can be inferred from other language labels (again, only for "obvious" cases).
  • Tool of the week
    • WD-FIST is a userscript that checks Wikipedia pages for available images if the item doesn't have one (automatically or manually via sidebar link).
  • Development
    • REST API:
      • Finished the endpoint for editing statements (phab:T306934)
      • Working on automated edit summaries (phab:T312811)
      • Making small modifications to the response format for statements (phab:T317866)
    • Lexicographical data:
      • Special:NewLexemeAlpha now uses the new search profile for languages, which makes it easier to select a language Item for the language of the new Lexeme (phab:T312853)
      • Finished the work on making sure that the example Lexeme falls back to other locally defined examples for languages other than English instead of the pre-set example Lexeme (phab:T313599)
      • Working on making sure that only *-x-Q123, not *-x-q123, can be used as a Lexeme language code (phab:T317863)
    • Sitelinks to Redirects are now available for testing on test.wikidata.org
    • Improved the wrapping and selection behavior of aliases in the header of an Item (phab:T315991) Thanks Fomafix for the patch!
    • Improved the translations of the Lexeme and EntitySchema namespaces (phab:T316770) Thanks to Amire80 for the patch!
    • Started supporting Codex work for some Wikidata-specific work needed in the new design system (phab:T306932)

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.


Thank you for mentionning the YouTube channel of Wikimédia France. I'm working on it since the beginning of the month. There is a playlist dedicated to Wikidata, but I still not yet have a clear view of what to put inside (as there is also a channel for our MOOC dedicated to Wikidata). Pyb (talk) 09:02, 20 September 2022 (UTC)
Hi Pyb :)
I left a suggestion on Facebook. Mohammed Sadat (WMDE) (talk) 15:17, 26 September 2022 (UTC)

Being smarter by using domain specific tools

Too often do we recommend people basically download tabular data from Wikidata and do whatever they need to do in MS Excel, Libreoffice Calc, or maybe you are one of the cool kids who process CVS through Python?


But rather than operating in the domain of tabular data, you could operate in the domain of triples, and the conversion is not that hard either. In fact if you need an AWK script to do just that, I'm more than happy to supply you. So how does that work flow look like exactly? Well, it means you now get your working set using a CONSTRUCT query and if you need to combine this with a CSV you need to convert it. OpenRefine has an extension for that as I understand it. The rest of the data processing you can then do in SPARQL locally, which is my key point. You don't need to install Apache Jena Fuseki, ARQ does not need installation and is perfectly happy to take a TURTLE formatted file and use it as it's input data. You can then utilize the projection to turn this into say a QuickStatements job.

Question #2: Is this how most people operate? I could write a tutorial for "working smarter" I suppose. Infrastruktur (talk) 20:06, 26 September 2022 (UTC)

I ended up downloading complete Q pages as json and doing local jq queries on them to produce my own json files for mediawiki's ExternalData to read. I also wrote SPARQL queries for the tabular cross-item data and download that as CSV, convert to my CSV format again for ExternalData to read. sed rather than awk is my friend. I found SPARQL poor for getting lots of different information from a single entity, and ExternalData poor for json arrays, hence my hybrid solution. I didn't look for cleverer solutions before I set out, so I've not heard of the tools you mention. Vicarage (talk) 20:20, 26 September 2022 (UTC)

request to link from P8214 to another Wikidata-item, not only external URL

In property P8214 (curriculum vitae) one can currently only link external website URLs, but not link to already existing items. For example: We have the item for person (Q55905242) and the item for the their CV (Q113678766). Now we want to add the statement (P8214) to (Q55905242) and link (Q113678766) as the value. This is not yet possible. MKNetwork (talk) 12:54, 23 September 2022 (UTC)

WD has less than 9 CV items in it - https://w.wiki/5jbx . I question whether Lebenslauf des verwitweten Bruders Friedrich Ludwig Kölbing, Bischofs der evangelischen Brüderkirche und Mitgliedes der Unitäts-Aeltesten-Conferenz, heimgegangen am 13. December 1840 in Berthelsdorf (Q113678766), despite its title, is a CV (as we would know it) or an obituary. In general, CVs fail WD:N and so WD does not anticipate items for them, and so has no property to point from the person to their CV. If CV items are added, they can point to the person using main subject (P921); there is no clear need for a reciprocal link. --Tagishsimon (talk) 13:03, 23 September 2022 (UTC)
We are planing to create objects for over 1000 CVs from the 19th c. There are a number of history profs who could confirm that they are exactly that. Frankly, I would like to know on what grounds you could possibly question that. Some of these Moravian "Lebensläufe" were even re-published precisely as obituaries.
These texts - there will also be other genres - fulfil WD:N in at least two ways. The Moravians were engaged in worldwide mission and wrote important texts (and created important buildings, social structures) in many languages beyond German - not least crucial studies in langagues decimated by colonialism. Their activites were global and forged in no small way the European understanding of the world. Hence these texts are crucial to a general knowledge base of global history.
I am not wedded to the reciprocal link since the links could be reconstructed as statements attached to the texts, for example. MKNetwork (talk) 13:25, 23 September 2022 (UTC)
@MKNetwork These documents can be interesting for Wikidata (and fulfill WD:N) if they have been published or are part of some collection or are a chapter in book. For instance, Lebenslauf des verwitweten Bruders Friedrich Ludwig Kölbing, Bischofs der evangelischen Brüderkirche und Mitgliedes der Unitäts-Aeltesten-Conferenz, heimgegangen am 13. December 1840 in Berthelsdorf (Q113678766) is correctly labelled as an article forming part (chapter) of a serial publication. I'd suggest using described by source (P1343) if you really think that the link in the other direction is necessary, but I agree with Tagishsimon that one direction is usually enough. Please note that the links can be already recovered from Wikidata in any direction (see eg. https://w.wiki/5jd5) Vojtěch Dostál (talk) 13:51, 23 September 2022 (UTC)
Looking at the property proposal and current uses, it seems curriculum vitae URL (P8214) is meant for the kind of C.V. you'd typically see on the webpages of researchers, scientists or businesspeople - showing the persons' education, employers, projects and/or publications. The kind of document you'd include in a job application. While the one you linked is a biographical article or obituary - written by someone else about the person's whole life. While it fits one of the definitions of "Lebenslauf", it's not really the kind of document that this property is intended for. There are many items for all kinds of biographical articles and obituaries already on Wikidata and they usually simply use main subject (P921) to state which person is described in it. --2A02:810B:580:11D4:64D6:DD8B:4F93:E0E2 17:12, 23 September 2022 (UTC)
It's not possible to have multiple datatypes for one property. What you can do is to use P8214 with <somevalue> and then use statement is subject of (P805) as qualifier. ChristianKl ❪✉❫ 17:23, 23 September 2022 (UTC)
I take your point and have now created the entity "Biography (text genre)" (Q114237167). This point is, however, immaterial to my proposal. I would simply want to state: "This text (whatever genre - the examples happen to be (auto)biographies) mentions x". P805 actually works pretty well from a person to a text. I want to make a statement on a text to persons, places etc. MKNetwork (talk) 14:25, 26 September 2022 (UTC)
Thank you. Could you point me to where in the proposal I should change that and what data type you would recommend? MKNetwork (talk) 15:41, 26 September 2022 (UTC)
biography (Q114237167): text genre, mainly describing the life of one or more persons looks incorrect and looks like you're using it in instance of (P31) where you should probably use genre (P136) set to biography (Q36279). Multichill (talk) 20:05, 26 September 2022 (UTC)
You're right, that would work. I changed to two statements Thank you! :) How would I go about removing Q114237167? I seem to be the only one who used it... MKNetwork (talk) 10:29, 27 September 2022 (UTC)

associating many "created by" properties

There are a lot of properties with the same general flavor of "person/organization responsible for creating", like creator (P170), author (P50), and developer (P178). How can I formally group these properties together? Nivekuil (talk) 22:51, 26 September 2022 (UTC)

If you take a closer look at author (P50) and developer (P178), you'll see that they are already subproperty of (P1647)creator (P170). Silver hr (talk) 01:53, 27 September 2022 (UTC)
There are others like performer (P175) and real estate developer (P6237) and discoverer or inventor (P61) and so on. Nivekuil (talk) 04:21, 27 September 2022 (UTC)

Wikidata weekly summary #539

Here's your quick overview of what has been happening around Wikidata over the last week.
  • 🧵 Discussions
    • New requests for permissions/Bot:
      • JhsBot 6
        • Task/s: Add sitelinks to newly created wikis after wikis have been created and exported from the Wikimedia Incubator.
  • 🎊 Events
    • Upcoming
      • Live editing session on Twitch, in French, by Vigneron, September 26 at 18:00 CEST (UTC+2)
      • Next Linked Data for Libraries LD4 Wikidata Affinity Group Wikidata Working Hour September 30, 2022: the seventh Wikidata Working Hour in the series will be a review session of creating contributor and publisher items in Wikidata. The primary goal of this session is to generate as many contributor and publisher items as we can in advance of the two following sessions which have to do with batch editing -- we want enough to make a good batch! We will review how to add items, but then reserve the bulk of the session for open editing, kind of like a mini-editathon! Naturally, participants can ask questions and share thoughts at any point during the editing! You are, as always, welcome to bring your own data to work on. All sessions in the project series will be recorded. Links will be added when available. Event page
    • Ongoing
      • Weekly Lexemes Challenge #60, Cows
  • 🧰 Tool of the week
    • User:Bovlb/notability.js is a userscript that adds a small notability indicator to the top right of an item showing how well the item satisfies the three notability criteria. Left to right, the three columns indicate sitelinks, identifiers and references, and structural need.
  • 🧑🏿‍💻 Development
    • Continuing work on making the mul language code work.
    • Continuing work on making Special:UnconnectedPages scale (phab:T300770)
    • Ensuring that Lexeme language codes using mis use uppercase Q consistently in the Item IDs (phab:T317863)
    • REST API: Working on automated edit summaries (phab:T312811)

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.

@Mohammed Sadat (WMDE): https://phabricator.wikimedia.org/T300770 - referred to above in the development section - gives (me) 'Access Denied: Restricted Task - You do not have permission to view this object'. --Tagishsimon (talk) 20:55, 26 September 2022 (UTC)
@Tagishsimon: We totally missed that it was a security task. I'm sorry, but we can't grant you access because it's security-relevant. The ticket will be made public when the issue is resolved. -Mohammed Sadat (WMDE) (talk) 15:12, 27 September 2022 (UTC)
Bang goes my plan for world domination. Oh well. :) --Tagishsimon (talk) 15:30, 27 September 2022 (UTC)

New Medical project - ICD

Hi, I'm a neurosurgeon and App developer, my App was a Big medical Code Dictionary with all medical Codes from Brazil, it's 54 tables and is used per 15000 Health Professionals. I would like to contribute with you to insert and organize an indexing project of the ICD OMS both the newest version and the one currently used. I already have the data both in JSON, SQL or CSV we just have to organise the hierarchy since some items have a level of up to 5 because of the groups created, Tell me that I can enter and relate the data Ericneuro (talk) 03:17, 27 September 2022 (UTC)

I forgot my app is MEDcodigos TUSS SUS CID CBHPM is in PT but I have a database for ICD in 5 languages Ericneuro (talk) 03:20, 27 September 2022 (UTC)
Wikidata rests on items and we have existing items about illnesses. When adding new data it's important to connect that data with the existing Wikidata items. Do you already have an idea about how you want to connect to the existing items? ChristianKl ❪✉❫ 16:58, 28 September 2022 (UTC)

Imported people from ORCID with an empty profile there

Jeffrey Byrne (Q104739787) was created as ORCID import, but has an empty profile there. There are at least 10 academics worldwide with this very name.

What shall be done with such an "honeypot for wrong conflation"?-- Dakota Halverson (talk) 19:40, 27 September 2022 (UTC)

I imagine it will sit there for all of time, undisturbed. An item created from an ORCID import, where ORCID has a blank profile, is not IMO a "honeypot for wrong conflation". Beyond the item's label, there's nothing in the item which would predispose any moderately cautious user to add conflated data to it. Incautious users are as likely to conflate data anywhere they please, such as to any Jeffrey Byrne item on WD, whether not it has an ORCID ID, and whether or not that ORCID ID's profile is blank. Items corresponding to blank ORCID IDs are always a bit of a disappointment, but they don't seem to be a problem. --Tagishsimon (talk) 20:05, 27 September 2022 (UTC)
@Tagishsimon: Don't you think that there should some onus on bot developers not to import useless items?--Dakota Halverson (talk) 21:11, 27 September 2022 (UTC)
I would not wish users creating items that fulfil WD:N to have to think, additionally, about the utility or lack thereof of the subjects they're adding. Orcid is not alone here; consider Mathematics Genealogy Project ID (P549), The Peerage person ID (P4638) and CBDB ID (P497) people - WD has hundreds of thousands of them, many of which are thin gruel. I somewhat see where you're coming from, but it does seem to be antithetical to the prevailing WD ethos, policy & practice. And I reiterate that I've not observed them to be a problem or hazard, so, nothing being broken, suggestions of a fix seem inappropriate. --Tagishsimon (talk) 23:09, 27 September 2022 (UTC)
The claim that this item was created as a ORCID import is questionable and you provided no evidence for it. This item isn't useless. ORCID IDs are used to specify the exact author of scientific papers. The ID allows to link Listening to the HysterSisters: A Retrospective Keyword Frequency Analysis of Conversations About Hysterectomy Recovery (Q104739788) to an item about a specific person and both the item about the person and was created at the same day by the same bot. If you look at the paper in question you find that he worked at "W2O Group, Austin, TX, United States". It's easily possible to tell whether or not another author is the same person that worked at "W2O Group, Austin, TX, United States". ChristianKl ❪✉❫ 13:59, 28 September 2022 (UTC)

@Tagishsimon: You've just epitomized the prevailing WD ethos, policy & practice (what a trifecta!): data, not knowledge. Thanks for the clarification.--木米 (talk) 12:37, 28 September 2022 (UTC)

I’m not so sure. Kolja21’s troubles (as I’ve come to understand them over the years) aren’t items that contain few statements. It’s items that are conflated, poorly modeled or where it’s impossible to discern what they are supposed to mean. It’s the lack of accountability and the unwillingness to improve that is shared by some within the community. While the item in question isn’t really stellar and the ORCID imports certainly aren’t a shining city on a hill, the item in question is hardly a good example for the problems Wikidata is facing. --Emu (talk) 14:13, 28 September 2022 (UTC)
The public profile available at ORCID is not the only piece of information available publicly that makes use of ORCID id's - in particular Crossref now regularly publishes links between articles and their authors using the DOI (to identify the article) and ORCID (to identify the author), so no matter what is in the ORCID profile for that identifier, the id is valid and useful. ArthurPSmith (talk) 21:17, 28 September 2022 (UTC)

New to Wikidata. Adding books that are not in system, tips for beginner?

I added Starve Acre (Q114246926) to the system as my first attempt. I looked at some existing book entries for guidance, but ran into questions right away. Should I have used instance of "book" or "literary work"? Why is Q1115619 a "written work" instead of Literary work? Do I have to next add a second new Q item for an Edition of the book so I can then put the ISBN-13 on the edition? Thank you. BitOneZero (talk) 21:01, 27 September 2022 (UTC)

@BitOneZero: You might want to look at Wikidata:WikiProject_Books. We typically use a subclass of written work (Q47461344) to represent the work. A individual copy of a book (Q53731850) is a concrete object that has an ISBN and is from a particular edition of a work. Generally I don't think we should use book (Q571) but wikidata isn't very consistent. And yes you want to make an edition item and attach an ISBN to that. BrokenSegue (talk) 23:05, 27 September 2022 (UTC)
Years ago, when I used Library Thing, I just need to click on a book in one of the mayor library catalogs and the data was imported. It would be great if there would be a similar tool in Wikidata. Kolja21 (talk) 14:38, 28 September 2022 (UTC)

Karl Friedrich Schinkel

I'm having trouble editing Q151759 Do I need to be more than an autoconfirmed user? Thanks. Just trying to link Karl Friedrich Schinkel. Merry Tyler Moore (talk) 06:21, 29 September 2022 (UTC)

You need to have autoconfirmed status, but not more (see protection log: https://www.wikidata.org/w/index.php?title=Special:Log&type=protect&page=Q151759) You will get that when you have made 50 edits and your account is 4 days old. The former is already fulfilled, and the latter will happen tonight at 20:23 UTC (user log: https://www.wikidata.org/wiki/Special:Log/Merry_Tyler_Moore). --Dipsacus fullonum (talk) 07:36, 29 September 2022 (UTC)

P31 Instance of use of Q5119 Captial seems to be causing an issue

instance of (P31) use of capital city (Q5119) seems to be causing an issue with violation of none-of constraint (Q52558054). Noted problem at Dublin (Q1761). However seems to occur for London (Q84), and Paris (Q90) as well so problem seems more widespread. How to fix this? Thankyou. -- Deirge Ó Dhaoinebeaga(a)talk 21:01, 22 September 2022 (UTC)

WD represents that a place is a Capital by use of the property capital (P36) (i.e. the subject is the capital of the object). WD does not use the formulation subject instance of capital. --Tagishsimon (talk) 08:38, 23 September 2022 (UTC)
I don't really understand these seemingly arbitrary rules. Yes we should encourage use of capital (P36) but using instance of (P31) capital city (Q5119) is not incorrect and gives slightly more information than instance of (P31) city (Q515) — Martin (MSGJ · talk) 10:14, 23 September 2022 (UTC)
It gives more information in the P31 domain, but if P36 is used, then overall no additional information has been provided; P31=capital is redundant. If P31=capital is used, then it begs the question, what is it the capital of & what qualifier do we use to answer the question: capital (P36)? of (P642)? (And for the avoidance of doubt, city and capital should not be conflated; they're distinct concepts.) Right now:
So, if those represent a trend you want to buck, you probably have to convince us that the modelling decision is for some reason flawed, and your proposed solution an improvement. --Tagishsimon (talk) 11:24, 23 September 2022 (UTC)
Not necessarily flawed, just somewhat arbitrary and perhaps hard for new editors to learn/understand. Are these "rules" even written down anywhere? I would prefer a constraint which was more helpful: when using instance of (P31) capital city (Q5119) it pops up and suggests "you should also define capital (P36)" which would recognise that adding correct information is not actually wrong, just that some additional structure is desirable. — Martin (MSGJ · talk) 13:07, 29 September 2022 (UTC)
Property constraints are documented on the talk page of the property (and may or may not be explained somewhere in the discussions on the talk page - not in the case of Capital). The constraint we're dealing with here seems to have been added to P31 by @Lectrician1: on 24 Jan 2022, following a discussion at Wikidata talk:WikiProject Cities and Towns#Modelling cities. This decision is, in a sense, arbitrary and difficult to understand. Equally, in another sense, it's not difficult to intuit - despite the stray 'also', the source of which I've not tracked down' - that the constraint is flagging up a problem with the value in P31 and flagging P36 as the preferred venue. I notice that state capital (Q11271835) is an exception to the P31 none-of constraint, which seems doubly arbitrary. It is common for wikiprojects to define modelling conventions in their domain; in this instance, documentation on Wikidata talk:WikiProject Cities and Towns does not reflect this constraint, and so could be improved. Not, I suspect, that that would help many users who are unaware that wikiprojects define modelling conventions. --Tagishsimon (talk) 13:42, 29 September 2022 (UTC)

@Tagishsimon @Deirge Ó Dhaoinebeaga @MSGJ Using capital city (Q5119) in instance of (P31) is not done for the following reasons:

Tagishsimon, I don't know what I was thinking to add state capital (Q11271835) as an exception. It has been removed. Lectrician1 (talk) 15:27, 29 September 2022 (UTC)

How to use MixNMatch?

This catalog was made before the property for it was created. How do I tell it to "go" and write out the fully matched statements now that the property exists? Do I have to export it and use QS? Do I need to bug the catalog creator User:Magnus_Manske (who is generally impossible to reach)? BrokenSegue (talk) 19:22, 28 September 2022 (UTC)

In short, yes, you need to get Magnus's help; adding the property requires a MnM admin role. I'll ping him & see if he'll do that. Presume it's Chess.com player ID (P11065)? --Tagishsimon (talk) 20:04, 28 September 2022 (UTC)
@Tagishsimon: I think it has already since been linked to Chess.com player ID (P11065) since if you go to "actions" then that property is already listed. Maybe I just need to go to "manually sync" and click update wikidata? BrokenSegue (talk) 21:01, 28 September 2022 (UTC)
I had a quick look. There are many which are likely to be the same person as existing items but none that I could definitively link. There simply is not enough information in the chess.com profile to attempt to match any of these. The year of birth and nationality, where present, is insufficient. — Martin (MSGJ · talk) 13:31, 29 September 2022 (UTC)
A lot of them were matched on FIDE player ID (P1440) which should be reliable BrokenSegue (talk) 19:19, 29 September 2022 (UTC)
Ah yes. Then indeed, manually sync. 23519 connections here, but not on Wikidata; nice big QS job. --Tagishsimon (talk) 21:39, 28 September 2022 (UTC)

Talk:Q114245504#Instance of - gas leak, sabotage, gas explosion, terrorist attack

Please fix Q114245504, see Talk:Q114245504#Instance of - gas leak, sabotage, gas explosion, terrorist attack 77.13.51.177 20:22, 29 September 2022 (UTC)

Format of pages in (Main) namespace

Hello, I was browsing Wikidata and am curious about how the software here works. Is it impossible to "create" a page in main namespace? - by impossible I don't mean literally impossible, I mean not in the normal way (e.g. on Wikipedia.) I noticed that there was no redirect on [[Main Page]] to Wikidata:Main Page, and I know that editing pages (the way on other wikiprojects e.g. Wikipedia) can't be done in that way here, neither can they be created or moved. Is the right not accessible to users, or is it a limitation of the MediaWiki software? Taiwanrailtransportfan (talk) 03:29, 30 September 2022 (UTC)

The ability to create new pages in the main namespace is disabled for obvious reasons. But there are nothing special about the pages and they are handled for the most part like regular pages on Mediawiki. If you look at the info for an example page, you'll see the page has content model 'Wikibase Item' which is equivalent to a JSON text file, but under version control.
With the proper permissions you might be able to create a Mediawiki markup page in a different namespace and then move it to the main namespace. This is permitted on vanilla Mediawiki, but I suspect the Wikibase extension has safeguards that will prevent you from doing this. Changing content model is also possible with the right permissions, so in theory you could move a Wikibase item to a different namespace and change the content model to a JSON file and it should display as JSON as you'd expect. Again, the Wikibase extension might prevent you from doing some or all of this. Infrastruktur (talk) 04:32, 30 September 2022 (UTC)
Yes, Wikibase prevents moving pages in or out of entity namespaces, or changing the content model to or from Wikibase content models. Lucas Werkmeister (WMDE) (talk) 08:40, 30 September 2022 (UTC)

Google Knowledge Graph ID

How do I access my Google knowledge panel? Morad AL-Teibi (talk) 11:37, 30 September 2022 (UTC)

@Morad AL-Teibi I’m not sure what you mean by “access”. If you want to search for Google knowledge panels, the mreid-resolver tool might be useful. --Emu (talk) 12:42, 30 September 2022 (UTC)
Thank you so much Morad AL-Teibi (talk) 12:53, 30 September 2022 (UTC)

Animal disease model

It seems animal disease model (Q64732998) and animal model (Q264024) are describing the same concept, and should probably be merged.

However, I'd like to be sure that the links within those two are not instead relevant for the related but quite distinct concept described at model organism (Q213907) (I made the confusion recently by suggesting a merger on the french wikipedia and I think it's an easy mistake to make). Typhoeus (talk) 12:33, 30 September 2022 (UTC)

I think that animal disease model (Q64732998) is properly a subclass of animal model (Q264024), and that they should not be merged. I presume there are animal models which do not pertain to disease. Equally, it looks at a glance, that at least the EN sitelink on the animal model item should instead by on the animal disease model item; and perhaps this is the case for other language links. I note that both items have heaps of incoming links - https://www.wikidata.org/wiki/Special:WhatLinksHere/Q64732998 & https://www.wikidata.org/wiki/Special:WhatLinksHere/Q264024 and so extra care would need to be taken lest a merge does very widespread damage. (And for completeness, model organism (Q213907) is properly a superclass for animal model (Q264024).) --Tagishsimon (talk) 12:58, 30 September 2022 (UTC)
For at least the french and english language wikipedia, the links at animal model (Q264024) should instead point to animal disease model (Q64732998) if we keep them distinct. I have no strong opinion on whether it's a good idea to have animal disease model (Q64732998) subclassing animal model (Q264024), itself subclassing model organism (Q213907), or whether the latters makes animal model (Q264024) redundant. In any case I know some people use "animal model" specifically to refer to an animal model of disease, and others to animals that are model organisms, the terminology is kind of confusing. Typhoeus (talk) 13:07, 30 September 2022 (UTC)
Hi @Tagishsimon and Re-bonjour @Typhoeus, as said in the french bistro, animal models are not exclusively disease linked. A lot of animal model are used for PK (pharmacokinetic) of the compounds, there are also, animal models to predict secondary effects of the compounds (example any beauty cream or Shampoo tested rabbit skins, etc). Regards GF38storic (talk) 14:00, 30 September 2022 (UTC)

Fork of QuickPresets userscript

If you use the QuickPresets userscript, you might be interested in my fork of it: https://www.wikidata.org/wiki/User:Nicereddy/quickpresets.js

The main improvements are:

  • Adding a link to the config you're using in the header of the fieldset.
  • Moving the confirmation messages below the fieldset so it doesn't jump around and cause misclicks when the confirmation messages appear (previously they appeared above, which moved the links down every time).
  • Slightly better usage of space (changing "Add X" to just "X" to allow more options to render without bleeding into the next line.

These were all pretty simple/minor updates to the script, but if anyone has any small improvements they want to suggest, feel free.

I'll leave a message for the original author, MichaelSchoenitzer, on his talk page to see if he'd like to include these improvements in the main userscript.

Thanks, Nicereddy (talk) 18:21, 24 September 2022 (UTC)

Could you maybe also fix this issue? Thanks a lot in advance! --Marsupium (talk) 20:03, 1 October 2022 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2022/09&oldid=2035988059"