Wikidata:Project chat: Difference between revisions

Content deleted Content added

Inline

Revision as of 12:04, 3 December 2021

Wikidata project chat

A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

Start a new discussion

Edit

On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/07.

Property for nationality

Is there a property representing national identity, or nationality? This is not citizenship, ethnic group, or a legal status. It is what a living person typically answers when asked their nationality. It is the nation that a historical persons identified as, is claimed by, or is defined as in sources. In the Soviet Union, nationality was noted in a person’s government ID (internal passport). —Michael Z. 20:50, 7 November 2021 (UTC)[reply]

No, but there have been several failed attempts to create such a property. Emu (talk) 23:27, 7 November 2021 (UTC)[reply]

Such Wikidata:Property proposal/Nationality in 2017 and Wikidata:Property proposal/nationality (cultural identity) in 2020. 2A01:CB14:D52:1200:E4F5:D635:3E0C:5849 18:40, 8 November 2021 (UTC)[reply]

Thank you. —Michael Z. 22:13, 13 November 2021 (UTC)[reply]

The absence of such a property is a serious problem.

It’s a problem of data representation. We have kludges like René Lévesque (Q381007) having ethnicity Quebeckers (Q245507), which is not defined as an ethnic group, but a residency status. But Quebec is officially a nation of Canada, and Quebeckers can live anywhere. It is a national identity, not necessarily a residency nor an ethnic group (in one poll, over half of Quebec residents named their ethnicity as Canadian, about a quarter French, and only 2.3% Québécois).

But much more importantly, this lack creates a systemic bias against members of stateless nations and formerly stateless nations, Indigenous nations, and nations and individuals whose identities are not defined strictly by a citizenship, a country, a faith, or an ethnicity (see w:WP:BIAS). It privileges, for example, historical empires, by forcing us to use citizenship as a proxy for national identity. It prevents us from respecting living persons’ own self-identification, and also many nations’ claims to historical figures important to their own identities.

Wikidata phase 1 regression

Is this is just an impression of mine or has navigating between language version of Wikipedia gotten more complicated recently?

Initially Wikidata was designed to help with interwikis between languages, but it seems the UI in some Wikipedia no longer uses them, thus making it more complicated.

Sample: try to switch from French to fr:Wikidata to en:Wikidata by navigating on Wikipedia.

How could this be corrected? --- Jura 11:47, 2 November 2021 (UTC)[reply]

Somebody thought it might be a good idea to move interwiki links to the upper right corner. -- Emu (talk) 12:00, 2 November 2021 (UTC)[reply]

The thing is that they are no longer on the page. --- Jura 12:04, 2 November 2021 (UTC)[reply]

I've seen more and more wikis having their "interlanguage links" moving from simple links in the left side bar to a "new switch language button". Bouzinac ^{💬●✒️●💛} 12:10, 2 November 2021 (UTC)[reply]

It has nothing to do with Wikidata, really, it’s a Mediawiki User Interface design choice, see for example mw:Reading/Web/Desktop_Improvements author TomT0m / talk page 12:33, 2 November 2021 (UTC)[reply]

Interwikis are just the initial usecase for Wikidata at Wikipedia .. --- Jura 12:45, 2 November 2021 (UTC)[reply]

TomT0m is right. Wikidata provides the data for the sitelinks but how they are displayed is an entirely separate matter and up to the skin. That is being changed as part of the Desktop Improvements project, which is independent of Wikidata. Lydia Pintscher (WMDE) (talk) 13:50, 2 November 2021 (UTC)[reply]

With "Wikidata" in this context, I suppose you mean Wikimedia Germany Development Team. I understand that you personally and your team might not have been involved in this.

Obviously, it's still data from Wikidata this is displayed (or rather no longer displayed) on it's primary usecase: Wikipedia and for which it was developed (by WMDE I guess) and from which it now regresses.

From a user and contributor perspective, it doesn't matter that much who did it and how it happened (WMF/WMDE should be able to sort this out internally), but it's obviously something that needs fixing. --- Jura 16:21, 2 November 2021 (UTC)[reply]

A better place to discuss/complain is fr:Discussion_Projet:Amélioration_de_l'interface_par_la_WMF. There has already been discussions about this on frwiki, with not so much complains actually. author TomT0m / talk page 19:34, 2 November 2021 (UTC)[reply]

It's actually unrelated to frwiki. The problem doesn't even affect users of a single wiki at all. --- Jura 08:30, 9 November 2021 (UTC)[reply]

The specific page for this exact change is at mw:Reading/Web/Desktop_Improvements/Features/Language_switching. It's not quite clear if the individual wikis have any choice in (eventually) adopting the change. But wikidata has about as much to do with it as it has with the layout Google chooses for the data snippets it extracts. Karl Oblique (talk) 08:23, 16 November 2021 (UTC)[reply]

I left a note there, but somehow it's unclear where this point is being discussed. The talk page redirects to a more general one. --- Jura 13:09, 23 November 2021 (UTC)[reply]

Seems @Theklan: commented there about frwiki: mw:Talk:Reading/Web/Desktop_Improvements#Impact_on_other_languages_in_France_of_burying_the_interwiki_link_in_the_bottom. --- Jura 13:10, 23 November 2021 (UTC)[reply]

Tracked in Phabricator
Task T290480

You can try in Phabricator. I just solved it for Basque Wikipedia here. But the developers are just closed to any critic in this sense, even if they broke the interwiki linking system, the contenttransation link and the buried it in the main page because they didn't ever make a design of how this should fit in the main page. Theklan (talk) 06:36, 24 November 2021 (UTC)[reply]

That's just the title page, but minority languages disappear from all articles. --- Jura 20:37, 1 December 2021 (UTC)[reply]

[Feedback Requested] Introducing a dedicated section on Wikidata Item pages for classifying properties

Hi all,

We had a lot of conversations about the Wikidata ontology during Wikidata Data Quality Days and WikidataCon. One issue came up again and again: New users unintentionally modifying the Wikidata ontology leads to errors and inconsistency. We would like to get your input about a first step that we propose to improve this situation.

What we are proposing

We are proposing to introduce a dedicated section on Item pages for classifying Properties. This section, named "Classification", will live below the Termbox and above the “Statements” section. The new section will make it more obvious that some Properties are special and modify the ontology. For consistency we will also have this section on Property pages.

This first step will only involve the display of statements after saving. We might consider making deeper changes to the UI and recommendation system at a later time, based on your experience with this change.

Please add your input directly to this ticket so that we can collect all of your thoughts in one place.

If you have any questions please do not hesitate to ask.

Cheers, - Mohammed Sadat (WMDE) (talk) 11:58, 15 November 2021 (UTC)[reply]

The proposed section will contain the following properties:

P279 (subclass of)
P31 (instance of)
P361 (part of)
P1647 (subproperty of)

Origin: https://www.wikidata.org/wiki/Wikidata:Item_classification

P1709 (equivalent class)
P3950 (narrower external class)
P2888 (exact match)
P1382 (partially coincident with)
P2670 (has parts of the class)
P527 (has part)
P3113 (does not have part)
P2737 (union of)
P2738 (disjoint union of)
P2445 (metasubclass of)
P1963 (properties for this type)
P3176 (uses property)
P1889 (different from)
P460 (said to be the same as)
P2959 (permanent duplicated item)
P1269 (facet of)
P2860 (cites work)

Sounds good. Above the properties listed in the ticket as "classifying properties". First group seems fine. The second could probably use some improvement. --- Jura 12:17, 15 November 2021 (UTC)[reply]

I'm sorry if my questions seem unconstructive. They're not meant that way, and they're genuine questions, not criticism.

As far as I can tell, this proposal is based on the premise that "some Properties are special" "classifying properties" and form "the ontology", as opposed, it seems, to other properties which are not considered to be part of this ontology.

I don't think that's reflected in the Wikibase data model, which has at some point made what I assume is a deliberate decision not to special-case even instance of (P31).
If it's reflected in the documentation, I haven't been able to find it.
As some of the other comments show, it's not immediately obvious to people which properties are special and which ones aren't.

Just to be clear: I'm not asking for a formal, legalistic, or mathematical definition of what makes properties "special". An approximate guideline is quite enough for me (but it should go beyond defining "special" in terms of "the ontology" and vice versa).

But I am asking for that rough-and-ready "I know it when I see it" sense: what makes properties special?

Once we've decided on that, we can create an item Qwhatever representing special properties, mark the special properties as instances of it, and then we can modify the Wikibase software to display properties which are instance of (P31) Qwhatever differently. Is that how the proposed feature would be implemented? Streetmathematician (talk) 15:59, 15 November 2021 (UTC)[reply]

@Streetmathematician Thank you for your questions!

Yes, all Properties are equal in the Wikibase data model. This is to allow for a maximum of flexibility and Community control. As a side effect however, this currently means that the Wikidata ontology can only be defined bottom-up (in each Item) and not top down (at a central place). The worst thing about this is that it often happens unintentionally. It is very hard for new editors to wrap their head around what exactly is the right thing to do. It also makes it really difficult for the Community to define and maintain a consistent ontology through all of Wikidata. This in turn makes it really hard to actually use Wikidata’s data in practice. This proposal is trying to make things a little better and to learn from the discussions, without making any fundamental changes for now. This is why in terms of implementing this, we will choose an option that needs minimal developer resources for now (e.g. simply changing the existing configuration setting).

We totally agree that it’s not immediately obvious to people (including us) which properties are special and which ones aren't. That’s natural as there was no need to reach consensus about this until now. But it’s also a major problem because of all the described bad side effects that come with this. To solve this, a clarifying discussion (this call for feedback) and a place to codify the results (the proposed change in UI for now) seem important. So we really hope that we will be able to answer your questions about a useful guideline together in the ticket. - Mohammed Sadat (WMDE) (talk) 11:39, 16 November 2021 (UTC)[reply]

Thanks for your response! It didn't quite answer my question, but it did answer enough of it for me to form an opinion on whether it's a good idea to do anything like this without first (discussing and) documenting the fundamental aspects.

Oppose. This proposal is a test balloon for fundamental and far-reaching changes to the Wikidata data model, trading "flexibility and Community control" for benefits which can be achieved less invasively.

The technical solution proposed (hard-code certain properties as "special" in the Wikibase configuration files) is inflexible, inconsistent, and unnecessary.

I strongly support documenting (and, in the process, discussing) policy proposals on "special" statements, then suggesting technical changes based on such if consensus appears stable. Starting with an ad-hoc technical proposal is not how to do that. Streetmathematician (talk) 19:48, 19 November 2021 (UTC)[reply]

I have some second thoughts on this. Depending on the types of items, would it really be an improvement?

Currently P31 and P279 are already shown above and this can easily be configured.

For items about people (P31=human (Q5)), what would it help to show all those other properties above others? I don't really see that.

Even for items like Tempelhofer Ufer 23–24 (Q15260574), would we want to see has part(s) of the class (P2670)=column (Q4817) above more essentially things? The general tendency is to add these below everything else.

Given the backlog with other layout questions, maybe it's better to spend development time, resources and funds on features actually requested by the Wikimedia community. --- Jura 10:51, 16 November 2021 (UTC)[reply]

I agree. Many improvements are expected by the community (not to mention Citoid integration for example). This change do not seem urgent at all. Ayack (talk) 11:30, 17 November 2021 (UTC)[reply]

Do we know who the user in the usecase is? Or is a fictional one? --- Jura 13:45, 23 November 2021 (UTC)[reply]
- Any luck with identifying the user? --- Jura 20:37, 1 December 2021 (UTC)[reply]

A sub-class for media and/or medium

Hello,

I've been looking for a root sub-class that could be used to group together all types of media. An example of how this root sub-class would be:

 - media (our root sub-class)
   - print
     - newspaper
     - book
     - ...
   - broadcasting
     - television
     - radio
     - movie
   - internet
     - podcast
     - ...

The closest thing I've found is https://www.wikidata.org/wiki/Q340169 but the items associated with Q340169 don't quite match with the above intent with instance associations like:

 - SMS
 - Internet Relay Chat
 - Ethernet
 - etc.

any help would be greatly appreciated.

"Cameroon" as unit

It seems to be a notorious problem with Wikidata's GUI. When trying to enter units as cm one gets Q1009 as unit.

"cm" is a valid alias for Cameroon (Q1009), but that it isn't useful as a unit.

Maybe I'm just the only one who still finds it odd. --- Jura 08:10, 17 November 2021 (UTC)[reply]

One could imagine various improvement to the unit search box:

1) It could prefer instance of unit of measurement (Q47574).

2) It could search inside unit symbol (P5061).

3) Long term, it could use lexemes for language-specific, grammatical forms of units.

Point 2) would reduce the need to include unit symbols as item aliases.

Point 3) would reduce the need to include plural (in some languages) or other forms as item aliases. Toni 001 (talk) 15:57, 17 November 2021 (UTC)[reply]

It could work like values for P31: while many are possible, one can easily pick "human" as value.

Of 608000 statements with width (P2049), 85% use Q174728. A further 11% m or mm. --- Jura 11:49, 18 November 2021 (UTC)[reply]

phab:T244856.--GZWDer (talk) 18:04, 20 November 2021 (UTC)[reply]

That seems to be a ticket for SDC, isn't it? Is there anything being done for Wikidata? --- Jura 12:11, 27 November 2021 (UTC)[reply]

A similar issue needing improvement is to prioritize suggestions that are instances or subclasses of the property. Thus, for family name (P734), instances of family name (Q101352) (e.g. Jackson (Q2732758)) should be prioritized over non-family name items like Jackson (Q3446260), Jackson (Q28198), or Jackson (Q959843). And for geographical properties, the inverse should be true, such that human names, disambiguation pages, etc. are not suggested for place names. -Animalparty (talk) 20:32, 26 November 2021 (UTC)[reply]

It seems to be more complicated to solve. For units (e.g. of P2049), 85% are Q174728. --- Jura 16:21, 27 November 2021 (UTC)[reply]

Nominating MoveClaim to become a Special:Gadget

Following recent proposal and enaction of Compact View becoming a member of Special:Gadgets, I thought I'd also nominate User:Matěj_Suchánek/moveClaim.js which is currently used by many (~492) users. It seems sensible as a very commonly convenient operation and since there already exists a special gadget for moving sitelinks. --SilentSpike (talk) 00:46, 24 November 2021 (UTC)[reply]

+1 Salgo60 (talk) 01:10, 24 November 2021 (UTC)[reply]

Maybe ask @Matěj_Suchánek: if he is ok with it? (I use it and I highly recommend it) --- Jura 10:06, 24 November 2021 (UTC)[reply]
- A good point, my apologies for assuming, but would you be in favour of this @Matěj_Suchánek: ? --SilentSpike (talk) 11:21, 24 November 2021 (UTC)[reply]
  - I support the move. Thierry Caro (talk) 12:18, 24 November 2021 (UTC)[reply]
  Sure, if there is support, I have no problem and will install it as a gadget. --Matěj Suchánek (talk) 11:14, 28 November 2021 (UTC)[reply]
  Support MoveClaim is a brilliant, essential tool that I use all day, everyday. People who don't know about it are severely missing out, making it a gadget will help with discoverability. Moebeus (talk) 01:48, 29 November 2021 (UTC)[reply]
  
  Support MoveClaim is a great tool. I use it regularly when disentangling conflated items. Fjjulien (talk) 04:55, 30 November 2021 (UTC)[reply]

Property for dates of talks of a conference?

Let's suppose there's a conference focused on engineering. In this conference, talks will be presented on

Monday 6 December 2021(10:00-15:00 UTC)
Wednesday 8 December 2021 (10:00-20:00 UTC)
Thursday 9 December 2021 (08:00-13:00 UTC)
Friday 10 December 2021 (15:00-18:00 UTC)

Which property should I use for storing those days and hours?

I would use start time (P580) for storing the date in which the first talk is presented on Monday and end time (P582) for storing the date in which the last talk is presented on Friday. However, I don't know a property for storing the information on Wednesday or Thursday. Any help is appreciated.

Rdrg109 (talk) 05:53, 25 November 2021 (UTC)[reply]

See Help:Dates#Precision, unfortunately at the moment maximum precision of time is day. Jklamo (talk) 10:15, 26 November 2021 (UTC)[reply]

I don't think Wikidata is suitable for this type of info. --- Jura 09:25, 27 November 2021 (UTC)[reply]

Blais

Hello fellow wikipedians, I was trying to link the french (fr) page Blais to the english (en) one. It is already linked to the german (de) and italian (it) pages for Blais however it does not work, because "the same name linked to pagename Blais and in a property p1889 is mentioned as different" as reported to me by phabricator. Thank you for your attention --Ricercastorica (talk) 14:13, 25 November 2021 (UTC)[reply]

@Ricercastorica: I've moved the en wiki sitelink from Blais (Q21482871) to Blais (Q15989234), which sorts out the identified problem. different from (P1889) is doing what it says on the tin: specifying that an item for a disambiguation page is not the same as the item for a family name. It would be good, btw, to provide links when reporting issues here or elsewhere. --Tagishsimon (talk) 09:08, 26 November 2021 (UTC)[reply]

Talk to the Community Tech: The future of the Community Wishlist Survey

Hello!

We, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on 30 November (Tuesday), 17:00 UTC on Zoom, and will last an hour. Click here to join.

Agenda

Changes to the Community Wishlist Survey 2022. Help us decide.
Become a Community Wishlist Survey Ambassador. Help us spread the word about the CWS in your community.
Questions and answers

Format

The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (all points in the agenda except for the questions and answers) will be given in English.

We can answer questions asked in English, French, Polish, Spanish, German, and Italian. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to sgrabarczuk@wikimedia.org.

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

Join online
Meeting ID: 82035401393
Dial by your location

We hope to see you! SGrabarczuk (WMF) (talk) 20:03, 26 November 2021 (UTC)[reply]

P1476 (title)

Many movies have their original title in English language, even when it's, let's say, German produced movies. For example Knockin' on Heaven's Door (Q166355). Should the property title (P1476) then show as language German or English? And if English is correct, would it be the same for Korean movies and series. Many of them have English titles, but they are almost always written in Korean alphabet Hangul (Q8222), e.g. Glitch (Q107646135). --Christian140 (talk) 07:26, 27 November 2021 (UTC)[reply]

Are these situations where the film is redubbed in a new language? If so, create one item to hold the original version details and then a second item with the details of the translation. The two items can be linked by has edition or translation (P747). See Snow White and the Seven Dwarfs (Q134430) as an example. From Hill To Shore (talk) 09:15, 27 November 2021 (UTC)[reply]

For films and similar works, the original title should be in title (P1476). Localized titles in the corresponding labels. --- Jura 09:24, 27 November 2021 (UTC)[reply]

As I understand the question, this is about which language code to set for title (P1476): should it be the language of the original version or the language of the title. Should Knockin' on Heaven's Door (Q166355) have title (P1476)Knockin’ on Heaven’s Door@en or title (P1476)Knockin’ on Heaven’s Door@de. The title is in English, but it is the title of the (original) German version of the film. - Valentina.Anitnelav (talk) 11:45, 28 November 2021 (UTC)[reply]
- Yes, that is exactly my question. --Christian140 (talk) 07:30, 29 November 2021 (UTC)[reply]

In my view title (P1476)Knockin’ on Heaven’s Door@en is correct; the language code denotes the language of the title value string and has no real relationship with the country of production nor the country in which the film is marketed under that title. If you wish to show the location in which a particular title was used, there is presumably a qualifier available. If you want to show the country of production, there is a property for that. And obvs, the item can have more than one title value.

In other news, I've changed the heading of this question. Christian140, if you use a template for a heading, then it is not possible to navigate to the thread directly from a watchlist, and indeed the watchlist does not show the resolved header, and so one needs to remember or lookup P1476 in order to figure out which index entry to select to get to the thread; or use a diff. It's hideous & wrong. --Tagishsimon (talk) 08:13, 29 November 2021 (UTC)[reply]

And then with Korean films? Many Korean films (or books or TV series) have English titles, but are spelled in Korean letters. Should they also be shown as English. I sometimes did it like that. Like, the original title of Glitch (Q107646135) is just the English word "glitch", but spelled in Korean instead of Latin letters. --Christian140 (talk) 19:43, 29 November 2021 (UTC)[reply]

Bot work for Cleveland Museum of Art

Hi, Thousands of files from the Cleveland Museum of Art were uploaded by Madreiling (not active since August 2019), and Wikidata items created for them. However,

Wikidata item is not added in the Artwork template;
The Wikidata item is incomplete (creator not mentioned, medium and size missing, etc.);
Sometimes a JPEG version, but with a lower resolution, was uploaded in addition to the TIFF file (e.g. File:Baron A. Faÿs - Santa Maria della Salute, View of the Grand Canal, Venice - 1997.40 - Cleveland Museum of Art.jpg);

Could it be possible to fix that with a bot? i.e.

Add the WD Q number in the Artwork template;
Complete the WD item with information on Commons (at least the creator);
Upload a JPEG version with the highest possible resolution;
Add the JPEG version to the P18 property;
Mark the JPEG version as preferred rank in WD;
Use a Creator template for the Artist in Commons.

The list of item can be accessed via [1], [2], etc. See also related discussion at c:Commons talk:Structured data#CC-0 conflicts with PD statement. Thanks, Yann (talk) 09:30, 27 November 2021 (UTC)[reply]

(ec) Is this for c:Category:Images from Cleveland Museum of Art?

Points #1, #3, #5 seems to be a matter for Commons.

Maybe it's worth creating a status of the available SDC data and complete it from the template on the files.

SDC then allows easy sync with Wikidata items. A dedicated property could be used instead of "described by url".

Here is what's available on Wikidata: https://w.wiki/4TYk

Depending on the type of work, Wikidata's model is more or less developed and maintained.

Some of the items still have Q18593264 that should eventually be removed. --- Jura 10:01, 27 November 2021 (UTC)[reply]

Yes, all images from this category. Yann (talk) 12:48, 28 November 2021 (UTC)[reply]

When fixing a few painting items, I noticed that they were mostly created by @Dominic: part of some project.

Maybe ask them before adding unfinished Wikidata parts to Wikidata:Bot request. --- Jura 08:37, 29 November 2021 (UTC)[reply]

Could a new constraint help dealing with conflation issues?

It is frequent for items automatically created from Wikipedia articles to conflate conceptually distinct P31 values. In the performing arts and in the GLAM domains, the most common cases are items stated to be instances of both a building (Q41176) and an organization (Q43229). As these items are enriched with more statements and identifiers, it becomes very difficult to distinguish which statements or identifiers refer to which entity. For example, an inception (P571) statement could refer either to the date when an organization was founded or to the date when construction for a building began.

This problem has been documented in the Wikiproject Performing arts. It was brought up multiple times during workshops with the international performing arts community - in order to raise awareness of the issue and to reduce its occurence - but to no avail. For each conflated item that is manually and painfully disentangled, another conflated item is created.

This problem was discussed at WikidataCon 2021 during a session entitled "How can we prevent conflictual P31 values?", which I facilitated along with Simon Villeneuve. 39 Wikimedians participated in the discussion and all attested of experiencing this problem in their respective field.

Over the course of the discussion, @Ahoerstemeier: brought to our attention the Wikipedia article covering multiple topics (Q21484471) class. This class makes it possible to flag a conflation issue, to keep a single interwiki link, and to use main subject (P921) to point Wikidata users to all distinct items described in the Wikipedia article (as an example, see left and right (Q542952). This is an elegant and somewhat efficient solution : among other things, it does raise awareness of the issue. However, this solution requires manual intervention (oftentimes, after conflation has already occurred). Besides, this solution is of no use for occurrences of conflation that doesn't originate from Wikipedias.

By the end of the discussion, there was growing consensus among participants that a new kind of value-type constraint was needed to trigger a warning when conceptually distinct classes are stated as P31 values in the same item. This constraint could follow this kind of logic: constraint violation if ?item wdt:P31/wdt:P279 wd:Y AND wdt:P31/wdt:P279 wd:Z - where Y and Z are conceptually distinct classes that shouldn't be instantiated on on the same item. For the particular challenge cited above, the constraint should be triggered if item X is an instance of BOTH building (Q41176) (and subclasses of) AND organization (Q43229) (and subclasses of).

Question 1. Do others agree that such a constraint would reduce the occurrences of conflation?

Question 2. How difficult would it be to implement from a technical and operational point of view? @Emu: pointed out that individual constraints would need to be created for each dyad of conceptually distinct classes.

Question 3. Are there other solutions that should be considered (in addition or in place of the proposed constraint)?

Note: If you are unfamiliar with Wikidata constraints, please check the Property constraints portal.

Fjjulien (talk) 15:05, 27 November 2021 (UTC)[reply]

It sounds theoretically appealing, so it's frequently proposed by people who rarely contribute to Wikidata.

Depending on the field, it's not clear if there are a lot of benefits for Wikidata itself. We might just end up creating countless additional, hard to maintain items: a few for each operating or owning organization, one for every building part hosting the organization.

Wikipedia articles might still end up being linked from one consolidating most of that.

Projects where this is an issue generally have specialized queries to monitor it. Does yours? --- Jura 15:22, 27 November 2021 (UTC)[reply]

The WikiProject does have multiple queries to monitor the issue, at WikiProject_Performing_arts/Data_structure/Data_modelling_issues. The most important query (https://w.wiki/4U3h) however often times out. As far as I know, no member of the Wikiproject has kept records of these query results over time. Fjjulien (talk) 04:09, 29 November 2021 (UTC)[reply]

In response to: "We might just end up creating countless additional, hard to maintain items: a few for each operating or owning organization, one for every building part hosting the organization."

The goal of the WikiProject Performing arts community isn't to create distinct organization and venue items just for the sake of stating operator or owner relationships. In the performing arts, both the organization item and the building item fulfill distinct structural needs - beyond the operator or owner relationships. The organization that operates a building often acts as a producer and/or a presenter of performing arts productions. And then, those productions have representations (i.e. performances) that take place in venues. Those representations can take place in the venue operated by the organization, and they can also take place in other venues: a producing company can go on tour; a presenting organization may choose to present performances in different venues in order to reach different audiences. The WikiProject performing arts community's goal is to be able to represent accurately all of these core activities of the performing arts value chain. And in order to do achieve this goal, we need external IDs to be attached to distinct organization and venue items. Fjjulien (talk) 04:37, 29 November 2021 (UTC)[reply]

It seems to be meet that your problem statement conflates several questions and isn't directly focused on the problem you are facing.

Ideally, your project would create a series of Listeria reports or complex constraints with the queries you developed. Any constraint, model etc, requires contributors to follow up on it. A constraint isn't magically solving it for you. --- Jura 10:04, 2 December 2021 (UTC)[reply]

Ghouston asked some interesting questions about it at Wikidata:Project_chat/Archive/2019/11#Restaurants_etc.. --- Jura 16:14, 27 November 2021 (UTC)[reply]
@Jura1: Thank you. This is an interesting discussion. The analogy between eating places/restaurants and performing arts buildings/organizations seems correct. Yet, this discussion appears to be concerned primarily with conceptual exactitude. The goal pursued by the performing arts community isn't just conceptual correctness for conceptual correctness's sake. We need distinct items to meet distinct structural needs for representing core performing arts activities. Perhaps I missed something, but I don't understand how this other discussion informs this one. Fjjulien (talk) 04:44, 30 November 2021 (UTC)[reply]
Maybe you should try to formulate your problem statement more closer to your usecase. --- Jura 10:00, 2 December 2021 (UTC)[reply]
I don't know about the constraint proposal, that does sound like it could be useful. However, on buildings vs organizations - for the most part I would think that the vast majority of buildings are less notable than the organizations that use them, so perhaps we could generally advise that if there's only one item it should be about the organization. Wikidata is not the place to store information about every building in the world. ArthurPSmith (talk) 16:28, 27 November 2021 (UTC)[reply]
I agree that not every building is necessary for Wikidata – that’s especially true for many of the more recent businesses. This doesn’t hold true for many (or indeed most) buildings that host GLAM institutions. That was the main focus of the session. Emu (talk) 20:20, 27 November 2021 (UTC)[reply]

I agree with Emu. GLAM and performing arts buildings are public places. Information about these buildings is likely to be used by quite a range of stakeholders, beyond the GLAM sector: municipalities, tourism associations, visitors, etc. Wikidata is the perfect place to make information about these buildings reusable by all stakeholders. Fjjulien (talk) 04:43, 29 November 2021 (UTC)[reply]

I believe it might be more efficient, and immediately possible, to do this with just regular property constraints? If I'm not mistaken, Help:Property_constraints_portal/Conflicts_with could be used to to exclude items with organization-specific properties (legal form (P1454) etc) from also having instance of (P31)building (Q41176) and vice-versa. Karl Oblique (talk) 20:27, 27 November 2021 (UTC)[reply]

@Karl Oblique It is indeed a solution that participants in the WikiProject Performing arts have considered. The problem is that defining/exclusive properties - that can only relate to either the organization or the building - have a low level of completeness (i.e. they are not used very often). For example legal form (P1454) is only stated on 98 of 6780 theatre company (Q742421) items (see the query: https://w.wiki/4UDd). That's hardly more than 1%. Now, there are 60 performing arts building (Q57660343) that have a legal form (and on which we could signal a "Conflicts_with" constraint violation, which is significant considering how seldom legal form is stated), but they only represent 2.2% of 2790 items conflating performing arts building and performing arts group (Q105815710) (see the query: https://w.wiki/4UDq). Unless we can identify a defining/exclusive property that is used on a larger proportion of conflated items, I'm afraid this solution would do little to improve the situation. Fjjulien (talk) 14:36, 29 November 2021 (UTC)[reply]

@Karl Oblique Further to my previous reply, I would like to flag that there are a few building properties that are used on a greater number of items, and which might be used as "Conflicts with" properties to trigger warnings on conflated items. These include: date of official opening (P1619) (stated in 5474 performing arts buildings items, 131 of which are conflated items), architect (P84) (4303, 111), and heritage designation (P1435) (4164, 62). These would be better contenders for testing the effectiveness of the "Conflicts with" constraint as a solution to reduce conflation.

List of properties used on performing arts building items: https://w.wiki/4UET.

List of properties used on conflated items: https://w.wiki/4UEb. Fjjulien (talk) 15:27, 29 November 2021 (UTC)[reply]

Given that this discussion follows a WikidataCon session, which many of us probably did not attend, it would be really nice if we could watch the recording before contributing to the discussion, any idea of when it will be available? DrThneed (talk) 22:05, 27 November 2021 (UTC)[reply]
None of the WikidataCon 2021 recordings have been made available yet in the event documentation. This being said the chat transcript is available in Etherpad. Fjjulien (talk) 03:51, 29 November 2021 (UTC)[reply]

Is it really so bad for an item to represent a building and an organization? I mean yes it is suboptimal but what practical problems does it create? BrokenSegue (talk) 03:48, 28 November 2021 (UTC)[reply]
@BrokenSegue: That depends on the use case. It doesn’t really matter in cases where Wikidata is nothing more than a glorified interwiki linking base. It’s more problematic in other cases:
- Fjjulien already mentioned problems with date values such as inception (P571).
- location of first performance (P4647) gets messy when there is only one item for the theatre and the theatre building and the theatre changed its location in the meantime. There are many similar cases.
- And then there is the general problem with unclear modeling which makes it harder for automatic checks, for MnM (see Vladimir Alexiev’s comment from above and generally for maintaining. Emu (talk) 16:23, 28 November 2021 (UTC)[reply]
Thank you. @Emu Fjjulien (talk) 04:13, 30 November 2021 (UTC)[reply]
@BrokenSegue Please see my reply to @Jura1 above, in which I explain the kind of use cases that require distinct organization and building items. A live performance is the outcome of several interactions between various agents. It can take place in a given building, and then the same production can go on tour. You can't hope to represent all of these relationships accurately with conflated items. Fjjulien (talk) 04:52, 29 November 2021 (UTC)[reply]

@Fjjulien: OWL has such constructs at the class level: owl:AllDisjointClasses, owl:disjointWith. WD currently has disjoint union of (P2738) (see P2738#P1855 for an example of use), this is to be used at a parent class all of whose children are disjoint.
- This is a more systematic way of expressing such constraints, rather than the point-to-point "Conflicts_with" suggested by @Karl Oblique:
- A new constraint to enforce disjoint union of (P2738) would need to be added.
- However, in line with what @Jura1: said, I'm afraid that will create a huge number of violations and people will be inclined to ignore them.
- You are ontologically correct to say "a building is not the organization owning/headquartered there", and there are many other examples eg "a research grant is not the project that it funds", "a port is not the city where it's located", etc. But when you ask the proponent "ok then, please go ahead and make a second item for each violation of your rule", they go mum ;-)
- So it's not so much about flagging such conceptual problems, it's the data engineering effort needed to overcome them. --Vladimir Alexiev (talk) 08:28, 28 November 2021 (UTC)[reply]
@Vladimir Alexiev: Thanks a lot for pointing out the notion of class disjointness in OWL. That's precisely what we would need to signal occurrences of conflation between performing arts buildings and performing arts organizations in Wikidata. I'm however unclear about how disjoint union of (P2738) could help: performing arts buildings and performing arts organizations do not have the same parent class. I would appreciate more detailed explanations about this solution. Fjjulien (talk) 04:00, 30 November 2021 (UTC)[reply]

@Vladimir Alexiev: I should clarify that my performing arts (and GLAM) colleagues and I aren't making a fuss just for ontological correctness. As I answered to @Jura1 above, performing arts building items and performing arts organization items are meant to serve distinct structural needs within the performing arts ontology. Unless we find a means of reducing occurrences of conflation, we will add messy data production data over messy organization and venue data. Fjjulien (talk) 04:10, 30 November 2021 (UTC)[reply]

I want to point out to another, perhaps more productive manifestation of this problem: how to tell Mix-n-Match what classes of items to use when matching against a catalog (external dataset). That's easy for Person datasets (eg Getty ULAN), but hard for conceptual ones (eg Getty AAT) because you can't easily distinguish instances (eg Picasso) from classes (eg painter, expressionist) and limit only to the latter --Vladimir Alexiev (talk) 08:28, 28 November 2021 (UTC)[reply]

I totally agree that we need a better way of flagging and tackling the conflicting class issue. In practice, the problem sometimes arises not only on the level of individual items, but also in the class tree, when people create classes with conflicting super-classes. E.g. center (Q68773434), which is currently defined as a sub-class of "facility" (place) and a subclass of "organization". Having flags on such class items would certainly be helpful to solve the problem in many instances. --Beat Estermann (talk) 08:30, 2 December 2021 (UTC)[reply]
It seems that the performing arts project doesn't make use of existing features. Really regrettable. --- Jura 10:06, 2 December 2021 (UTC)[reply]

need alternative for "parent organization" property

Civil Air Patrol (Q781210) currently contains the parent organization (P749) property with the value Air Combat Command (Q407015). But it's not that simple. CAP is a not-for-profit organization chartered by Congress, and is able to conduct many operations on its own authority. Certain operations and policies, such as searching for downed aircraft and setting a policy for wearing uniforms, require approval from Q108444184, which is indeed part of Air Combat Command (Q407015). Is there any property that covers this kind of relationship? Jc3s5h (talk) 16:53, 27 November 2021 (UTC)[reply]

regulated by (P3719) maybe? Karl Oblique (talk) 19:51, 27 November 2021 (UTC)[reply]

So far "regulated by" seems better than "parent organization", but I'll give some time for others to respond. Jc3s5h (talk) 20:10, 27 November 2021 (UTC)[reply]

General alternatives might be owned by (P127) or operator (P137) but they don't seem applicable here. ArthurPSmith (talk) 17:56, 29 November 2021 (UTC)[reply]

Catalonian republics

Did all these partially/fully unrecognized states have Barcelona (Q1492) as their capital? If so, should Barcelona (Q1492) have inverse claims (as Property:P1376#P2302 implies)? Please judge whose version is correct in our conflict with User:Lopezsuarez. --Infovarius (talk) 21:16, 27 November 2021 (UTC)[reply]

There is no conflict. It is totally absurd to say that Barcelona was the "capital of the Catalan Republic" in 2017, when Catalonia has never been a republic, not in 2017 or ever. Lopezsuarez (talk) 21:57, 27 November 2021 (UTC)[reply]

Is the claim

⟨ Catalan Republic (Q138837)  

 ⟩ capital (P36) ⟨ Barcelona (Q1492)  

 ⟩

ok? I am talking about property constraints too. --Infovarius (talk) 11:43, 28 November 2021 (UTC)[reply]

If there is a reference supporting one claim, it's applicable to the other as well. One can then set appropriate ranks. --- Jura 08:48, 29 November 2021 (UTC)[reply]

Help! My Mullvad (Q47008412) VPN ip got through(I did not expect this), you need to block my IP. Please replace it with Oduci, please scrub my IP and replace it with Oduci. Thank you.

I was in the process of creating a new item for Wikiversity lesson (Q109794522) when I realized I was allowed by the system to create the item using an IP address by Mullvad (Q47008412) VPN service provider. The reason this mistake happened was because I was confused and thought I was using a browser I use for Clearnet (Q20706905) browsing, but instead I was using the browser that is connected through my Mullvad (Q47008412) VPN. The edit was allowed and the rest is history. I am not a researcher, I am just reporting my IP in knowledge that your policies when I last read them regarding proxies and VPNs that they are not allowed to make edits with.

Is it possible to replace the Mullvad (Q47008412) IP with my username that was used in this edit at https://www.wikidata.org/w/index.php?title=Q109794522&oldid=1535729837 ? There is no privacy issue and I feel no need for any urgency on a personal level as I am not ashamed that I am using a VPN provider to browse the net with(not make edits with! How was I to know that an edit would be allowed, but I assume this happens rarely anyway...).

To my knowledge Wikimedia has policies against proxies and VPNs and if one wants to make real change maybe contribute to Wikiversity projects and research projects which do research on finding solutions to combat spam so that one day maybe VPNs can go through a filter that is strong enough that most bad edits will be impractical to perform. VPN service providers could also potentially find technical solutions(ie. allowing editors with possession of accounts with a good history of edits to use a special IP that is not given to most VPN users for Wikimedia edits) and VPN customers can demand from their VPN providers that this is a need they have = to make edits on Wikimedia projects and asking for solutions. I am also aware that users can apply for special permissions from Wikimedia personnel but I assumed that is only in special cases where one might be in danger from a government in case one contributes to Wikimedia projects and I live in Sweden and I consider Sweden to not be such a country where I need to fear for my life when I make edits here so I do not think things like check-user exemption applies to my situation.

P.S. I am making this edit using Mullvad (Q47008412) for it to be easier for you to block. If something has changed in the policy that now allows edits from VPNs that will be news to me but I think I would know if a change had happened because I have much interest in any developments in this area.

If there is an easier and maybe better way to report such occurrences in the future please enlighten me as most words I wrote as part of this text was more about my self conscious shock that this could happen.(an ip "slipping through"). I hope this of help and not a bother. Thanks again! Oduci (talk) 20:27, 28 November 2021 (UTC)[reply]

@Oduci: I've hidden the IP address but we cannot reattribute the edit to your account. In the future please follow the directions at Wikidata:Oversight rather than posting about it in public. If you have a compelling need to have Wikidata:IP block exemption, then please file a request at WD:RFP accordingly.--Jasper Deng (talk) 19:45, 30 November 2021 (UTC)[reply]

Latin language Label

Hello,

Currently Pons Aelius (Q7227963) lack a Latin language Label. Could somebody correct this? Also do the same for every Roman military base, item with Digital Atlas of the Roman Empire ID (P1936), item with vici.org ID (P1481). 2A01:CB14:D52:1200:3950:38ED:E8B2:4846 20:58, 28 November 2021 (UTC)[reply]

You can edit the label at Special:SetLabel/Q7227963/la. --- Jura 08:45, 29 November 2021 (UTC)[reply]

Wikidata weekly summary #496

Here's your quick overview of what has been happening around Wikidata over the last week.

Discussions
- Project chat: Wikidata phase 1 regression (interwikis no longer visible in new layout used by some Wikipedias and its impact on minority languages)

Events
- Upcoming
  - Working with Siegfried, Wikidata, and Wikibase. December 2, 2021 4:00 pm CET
  - Next Linked Data for Libraries LD4 Wikidata Affinity Group call: Jan Ainali on WikiProject Govdirectory, a tool and associated Wikiproject for building a user-friendly directory of government agencies and their online presence. Agenda with call link, November 30.
  - Next LD4 Wikibase Working Hour. Thurs. 16 December 2021, 11AM-12PM Eastern, (time zone converter). "We will continue work developing our WBStack sandbox which seeks to explore how Wikibase could help track the usage of alternate labels for terms in vocabularies like LCSH"
  - LIVE Wikidata editing #64 - YouTube, Facebook, December 4 at 19:00 UTC
  - Online Wikidata meetup in Swedish #89, December 5 at 13.00 UTC
- Ongoing
  - Weekly Lexemes Challenge #18, Horse
- Past
  - Wikibase Live session log, month of November 2021
  - Introduction to Wikibase (part 1), ISKO UK Hands-on Meetup (replay)

Press, articles, blog posts, videos
- Blogs
  - Blog post on how Wikimedia Sweden has worked with two museums to open up their data and make it available on Wikidata (in Swedish)
  - Indigenous knowledge on Wikipedia and Wikidata
- Videos
  - Video tutorial for Wikidata Scraping, data processing and import (Open Refine) (in Czech) - YouTube
  - (Wikidata intro) how it acts as one of the levers for the discoverability of cultural content in dance (in French) - YouTube
  - Archive and register of sound art / sound artists with Wikipedia, Wikidata and Wikimedia (in Spanish) - YouTube
  - Reconciliation server demonstration against Wikidata - YouTube
  - Wikidata: A Magic Portal for Siegfried and Roy - YouTube

Tool of the week
- New gadget available in the preferences: "compact items" makes the interface on item pages more compact (it was previously a gadget for common.css)

Other Noteworthy Stuff
- Wikimedia Deutschland is looking for a Full-Stack Developer to join the Wikidata team.
- Are you doing research around Wikidata? There is a new fund to support research work around the Wikimedia projects that you can apply to.
- New strategies for Wikidata and the Wikibase Ecosystem published and waiting for your feedback. Add your comments!

Did you know?
- Newest properties:
  - General datatypes: death rate, image with color chart
  - External identifiers: Australian Prints + Printmaking artist ID, Australian Prints + Printmaking work ID, Dissernet institution ID, DHAC ID, Bildatlas-Künstler-ID, AHPRA registration number, FRACS Find a Surgeon profile ID, Databáze her ID, 7 Days person ID, Oùvoir.ça film ID
- New property proposals to review:
  - General datatypes: Corruption Perceptions Index, surrounds the enclave, Harvard Art Museums ID, GISAID identifier, Nextstrain identifier, homophone lexeme, Numista
  - External identifiers: identifiant base Enluminures, The World of Shakespeare ID, oKino.ua film ID, kinobaza.com.ua film ID, kinobaza.com.ua actor ID, oKino.ua actor ID, Natural History Museum (London) person ID, svpressa.ru ID, Russian Academy of Sciences person ID, The Parliamentary Newspaper ID, Lib.ru author ID, politika-crimea.ru person ID, Institute of the History of Ukraine scientist ID, centrasia.org person ID, Music of Armenia ID, Encyclopedia of Transbaikalia ID
- Query examples:

Development
- Mismatch Finder: Continued working on last remaining tickets for the first version. Added a footer to the site, improved documentation and added ability to delete a batch of mismatches.
- Made good progress on migrating our on-wiki Vue apps to support the new Vue.createMwApp compatibility layer in MediaWiki core (phab:T294465)
- Continued work on making it possible to define a custom ordering of grammatical features on Lexemes (phab:T232557)
- More research and discussion on mul language code (phab:T285156)
- Discussing with data re-users about their views on the ontology issue classification we worked on earlier this year to get their input (slides from Data Quality Days session)

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.

Monthly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Comment on property proposals: all open proposals
- Contribute to a Showcase item.
- Help translate or proofread the interface and documentation pages, in your own language!
- Help merge identical items across Wikimedia projects.
- Help write the next summary!

Read the full report · Unsubscribe · Mohammed Sadat (WMDE) 14:54, 29 November 2021 (UTC)[reply]

Pages (per category) for suggested databases to link out to

When you have been around Wikidata for a while, you learn what linked datasource each type of entry should have for example a podcast needs links out to the major players and directory as well as social media links. A politician made needs links to various political listing sites. An actor should be linked to IMDB etc etc. Should we (or do we have) wiki pages that suggest the various places to look for links for different types of wikidata entrys? Back ache (talk) 10:28, 30 November 2021 (UTC)[reply]

Yes. Wikiprojects often have a list of properties that pertain to types of items they work with. For an example, see Wikiproject Music. There is also Wikidata:Schemas, which is a long-term in-progress solution that offers significant benefits over these lists of properties. Lectrician1 (talk) 14:12, 30 November 2021 (UTC)[reply]

Once you’ve set a instance of (P31), suggestions for further properties adapt, although I am not sure if it’s specific enough to then further adapt to, say, musicians vs. politicians.

Theres also recoin, which you can enable in your gadget settings which gives you similar information in a list above the item. Karl Oblique (talk) 21:08, 30 November 2021 (UTC)[reply]

Q1758677 (oeuve)

Q1758677 is described as a disambiguation page but that's only true for the English Wikipedia page; the other five are no dps. The item should be split but I am not sure about the best way to do this. Is removing the link to the enwiki, blanking the remaining descriptions and deleting the disambiguation statement an acceptable solution?

Btw, WikiData has no Helpdesk? Not sure where to post questions. A redirect from 'Helpdesk' to 'Project chat' could be, well… helpful. →bertux 14:27, 30 November 2021 (UTC)[reply]

No, one shouldn't repurpose Wikidata items. Just move stuff that belongs elsewhere to another item, new or existing. --- Jura 17:25, 30 November 2021 (UTC)[reply]

So which part should be moved, enwiki or the other ones? →bertux 17:44, 30 November 2021 (UTC)[reply]

Check the P31 value to determine. --- Jura 17:49, 30 November 2021 (UTC)[reply]

(EC) Sitelinks to any pages that are not disambiguation pages should be moved elsewhere. Perusing the history of the item, its first (& only?) P31 value was disambiguation (even though the item may have started with only a sitelink to a non-dab page). So, it's a dab item and as Jura rightly says, such things should never be changed. --Tagishsimon (talk) 17:50, 30 November 2021 (UTC)[reply]

Low-quality references by Magnus and his bot - can we fix them?

Magnus has for years been producing items with low-quality references - they usually only have reference URL (P854) - see Štefan Leonard Kostelničák (Q109833604) and several hundred more created a few minutes ago. Without stated in (P248) and retrieved (P813), it is very difficult to work with these references or cite them in Wikipedia modules. Is someone willing to take on the task of improving them at least a little bit? It would mean processing some URLs with RegEx (either via queries or with dumps) and then assigning stated in (P248) to them. Assigning retrieved (P813) is likely impossible. Thanks for your thoughts on this, Vojtěch Dostál (talk) 16:52, 30 November 2021 (UTC)[reply]

seems to me that getting him to improve his additions is a better use of time. At the very least adding a retrieved date. BrokenSegue (talk) 17:02, 30 November 2021 (UTC)[reply]

It seems to me that generally they are better than that. Not sure how a toolforge link ended up in there. Retrieved time might be complicated, as the age of MxM catalogues tends to be unknown. --- Jura 17:23, 30 November 2021 (UTC)[reply]

@BrokenSegue Yes that would be best - I've tagged him here and I had also written him about it some time ago on his talk page (Topic:Vit29jh9tlbjpzt3) - but Magnus is of course very busy and hasn't had time to do this. I find it very difficult to ask anything of him, knowing that he is bombarded by requests like this from all sides. Vojtěch Dostál (talk) 17:24, 30 November 2021 (UTC)[reply]

The problem is that even if one fixes stuff for others, the person (or bot) will likely add more of the same .. so it's preferable to go to the source and add a cleanup request to Wikidata:Bot_requests. --- Jura 17:30, 30 November 2021 (UTC)[reply]

@Jura1 Yeah, but what do you suggest? We can either keep the errors accumulating or try to fix at least some of them ourselves. I could write on Magnus's talk page every day, each time with a different bug request on one of his tools. It's just not possible to do for one person. Vojtěch Dostál (talk) 17:35, 30 November 2021 (UTC)[reply]

The sample you mentioned seems to be a bug. If so, the bot should be blocked until it's fixed.

Eventually, we should also try to get all bots up to current standard.

There are a lot of references that could benefit from normalization, but we haven't really developed a nice way to do that. Understandably, bot operators who were up-to-date before don't necessarily want to update their past uploads. --- Jura 17:47, 30 November 2021 (UTC)[reply]

I've seen much worse from other bots. I don't want to excuse low quality items but we shouldn't single out Magnus when there are far worse offenders. Gamaliel (talk) 17:38, 30 November 2021 (UTC)[reply]

@Gamaliel There are certainly much more serious offenders but few of them are such prolific item creators as him. So any problem, however small, suddenly becomes more visible and more difficult to fix. To tell the truth, I have not seen any other large-dataset bot producing items which merge several URL-only references into one instead of inserting distinct references to each statement. That will be nearly impossible to disentangle - and it's been happening for years so it's likely tens of thousands of statements that we cannot possibly query for using a standard Wikidata Query Service. Vojtěch Dostál (talk) 13:21, 1 December 2021 (UTC)[reply]

Even without the toolserver url, Q109857092#P569 has three different "references" as one reference. Can someone stop it? --- Jura 20:25, 1 December 2021 (UTC)[reply]
Noted at Topic:Wlfqvryhy9d1jr6z and requested at Wikidata:Administrators'_noticeboard#User:Reinheitsgebot. --- Jura 15:05, 2 December 2021 (UTC)[reply]

Replied here, thanks all! --Magnus Manske (talk) 09:01, 3 December 2021 (UTC)[reply]

merging two item is complicated

1. Q1811179 and Q3485434 should be merged because: (a) common sense, the two concepts are both referring to a Fossil Site, using the same depiction; (b) authority suggested so, see [1] (c) english wikipedia pages simply redirects

2. none of the item use the official English name (see [1][2]). One redirection was done in English wikipedia[3], but it would be better to stick to official name.

3. conflicting label/descriptions in several language that I'm not familiar. help:Merge is not enough, guess conflict will be resolved using google translate and commons sense.

4. conflicting sitelinks in two items, which one to keep will depends on common sense again.

Hello Dkyd, please remember to sign your posts on discussion pages and the like. Regarding the items you mentioned, they appear to refer to slightly different concepts, i. e. to a group of fossils and to the site of their discovery, respectively. Karl Oblique (talk) 21:39, 30 November 2021 (UTC)[reply]

thanks @Karl Oblique, I updated signature.

your suggestion is reasonable, and my investigation shows four different concepts

(1.1) Chengjiang Biota (biota, i.e. the flora and fauna of a region), supported by "The Chengjiang Biota, from Yunnan, China, is the most diverse assemblage of Early Cambrian marine fossils known. "[4];
(1.2) Maotianshan Shale (fossils group, geological formation) , supported by "The fossil material studied here (Supp. Table 1) comes from the Maotianshan Shale Member of the Yu'anshan Formation" [5]. note that shale and biota are different "The biota of the Burgess Shale appears to be typical of middle Cambrian deposits" [8]
(1.3) Chengjiang Fossil Site (a place, a UNESCO World Heritage Site), supported by "The Chengjiang Fossil Site, located in the Province of Yunnan, China, conserves fossil remains which are of exceptional significance. ... The fossils and rocks of the Chengjiang Fossil Site, together, present a complete record of an early Cambrian marine community. ... The Chengjiang Fossil Site is state-owned and protected ..." [2]. criteria viii, "to be outstanding examples representing major stages of earth's history, including the record of life, significant on-going geological processes in the development of landforms, or significant geomorphic or physiographic features;" [6] similarily, "The "Burgess Shale" property, which was previously inscribed on the World Heritage List, is part of the "Canadian Rocky Mountain Parks". " [9]
(1.4) The Chengjiang Fossil National Geopark (a poi, national park where the heritage site was protected), supported by "Map showing relationship of the Chengjiang Fossil Site to the Chengjiang Fossil National Geopark" [7]

therefore, several issues to be fixed (looks like there will be a lot of editing effort, so we need to reach some agreement before editing)

(2.1) English wikipedia pages corresponding to the two items are linked by redirection, see https://en.wikipedia.org/w/index.php?title=Chengjiang_biota&redirect=no, the question is how many wikipedia pages should we maintain for the above four concepts? should this be treated similar to Q4998607 Burgess Shale type fauna, Q852085 Burgess Shale [8] [9] .
(2.2) Note that Q852085 use Property:P1435 to specify Burgess Shale's relation to UNESCO Heritage Site (national park), how to proceed
(2.3) Britannica's definition seems mistaken, "Chengjiang fossil site, also called Chengjiang Maotianshan Shales, formation in China containing fossils dating to the Terreneuvian Epoch of the Cambrian Period (541 million to 521 million years ago). " [1]
(2.4) further fix wikipedia language sitelinks
(2.5) further fix incoming links

references

[1] https://www.britannica.com/place/Chengjiang-fossil-site
[2] https://whc.unesco.org/en/list/1388
[4] The Chengjiang Biota: Record of the Early Cambrian Diversification of Life and Clues to Exceptional Preservation of Fossils, GSA Today 11(2), February 2001 , https://www.geosociety.org/gsatoday/archive/11/2/pdf/i1052-5173-11-2-4.pdf,
[5] Worm-lobopodian assemblages from the early Cambrian Chengjiang biota: insight into the "pre-arthropodan ecology"? Jean Vannier* , Emmanuel L. O. Martin, https://hal.archives-ouvertes.fr/hal-02329513/
[6] https://whc.unesco.org/en/criteria/
[7] https://whc.unesco.org/uploads/nominations/1388.pdf
[8] https://en.wikipedia.org/wiki/Burgess_Shale
[9] Canadian Rocky Mountain Parks https://whc.unesco.org/en/list/304

-- Dkyd (talk) 05:48, 1 December 2021 (UTC)[reply]

Yeah, no, you';; have to take it up with the articles on enwiki and hope for someone to do the same on dewiki. Karl Oblique (talk) 03:44, 2 December 2021 (UTC)[reply]

L'Hospitalet de Llobregat train station / Rambla Just Oliveras metrostation

Q2536322 is confusing. Most wiki's only describe the metrostation, while others only describe the train station. The two stations are not fysically connected and have different names. Passengers have to go to the street, to change. I suggest that a new item be created for only the train station. L'Hospitalet de Llobregat train station. Smiley.toerist (talk) 10:38, 1 December 2021 (UTC)[reply]

There is also Q9303809 used bij the PL wiki.Smiley.toerist (talk) 10:59, 1 December 2021 (UTC)[reply]

Metro and railway stations should probably be separated into indiviual items even if passengers would not have to cross the street. Thierry Caro (talk) 17:09, 1 December 2021 (UTC)[reply]

OK: Q9303809 becomes the metrostation and Q2536322 the train station.Smiley.toerist (talk) 23:18, 1 December 2021 (UTC)[reply]

Done. Please check the results. There are a few things left over:

The creation date for the train station is problably not 1987 (metro extention)
I cant read the Korean script, zo I dont know if they refer to the metro or train station.
I did not go into the identification codes
It would be nice if there are metrostation pictures, but unfortunatly not, so in some wiki's the pictures dont match the text.Smiley.toerist (talk) 10:25, 2 December 2021 (UTC)[reply]

P106

Hello everyone. In Hebrew Wikipedia we are voting for keeping or removing importing occupation (P106) from Wikidata to Template:Infobox person (Q6249834). Many times the occupation (P106) includs too many occupations which part of them are main occupation/s and part minor occupations and some only hobbies. How I can use the reason for preferred rank (P7452) (which item from the list of Wikidata reasons for preferred rank (Q76637123) is suitable)?
For example Benjamin Franklin (Q34969) have only two main occupations which olready marked as preferred rank. Which qualifier should be added her for reason for preferred rank (P7452) from the list of Wikidata reasons for preferred rank (Q76637123). Geagea (talk) 10:47, 1 December 2021 (UTC)[reply]

You should not do any such thing. In general, we do not editorially promote certain occupation values to preferred and keep others normal because there is no source establishing that preferred/normal differentiation, and because although it might be convenient for a handful of applications such as yours, it complicates and frustrates other applications which have a dependency on the same data. There are ways in which Hebrew wiki's template could deal with the situation, such as sampling the occupations, or choosing the most used occupations across wikidata from the set of occupations on a single item. I really cannot overstress the point that your proposal would be a great abuse of wikidata. --Tagishsimon (talk) 13:23, 1 December 2021 (UTC)[reply]

@Geagea This is very important, I wonder if the Wikidata community is in favor of enabling such inherently subjective choosing of most important occupation (P106). Actually I'd be in favor of allowing that, because occupation (P106) really is a dumping ground for all sorts of occupations and many of our largest content users including Wikipedias will be interested in just a hand-picked selection of the most importent ones. Vojtěch Dostál (talk) 13:29, 1 December 2021 (UTC)[reply]

If the Wikidata community is in favor of enabling such inherently subjective choosing, then it should get in the sea. No question about that. --Tagishsimon (talk) 13:33, 1 December 2021 (UTC)[reply]

@Tagishsimon I'm being a devil's advocate here, but... We already allow subjective selection of statements for preferred rank, even if we pretend we're completely objective. Help:Ranking#Preferred rank gives one example - choosing "the result of the most commonly used or scientifically valid method"; isn't that personal choice too? We'd have to be really careful here but this sort of data curation isn't something completely new. Vojtěch Dostál (talk) 13:41, 1 December 2021 (UTC)[reply]

Sure, but in effect there's a rational basis for that; and we're talking the difference between one measurement, or another, of the same thing, rather than (from a truthy standpoint) throwing out a whole raft of occupations to make some rudimentary template work. --Tagishsimon (talk) 13:50, 1 December 2021 (UTC)[reply]

I don't think it's subjective. wiki projects want to use P106 in the main template of Infobox person. There are main occupation and there are minor. For example it is a ridiculous to add chess player (Q10873124) for Benjamin Franklin (Q34969). Does freemason (Q23305046) is a suitable occupation for Benjamin Franklin or slave owner (Q10076267) or postmaster (Q1416611) All the occupations should be shown in the main Infobox template? Geagea (talk) 13:53, 1 December 2021 (UTC)[reply]

I'm sure there is some extremely objective way in which Benjamin Franklin's roles as statesperson (Q372436) and inventor (Q205375) differ from his work as a musician (Q639669), dilettante (Q1225491), chess player (Q10873124), or freemason (Q23305046). The use of that information to consumers of the data, including the wikipedias, is obvious. If the current model does not allow for that, it is flawed and the discussion should be how to fix it: is there, for example, a set of facts that could be added that demonstrate the difference instead of merely asserting the priority? Something like total time spend would work, alas we don't have that data.

In any case I find the reqest entirely reasonable even if it cannot be accommodated and don't quite see the neccessaity for the level of hostility in the response. Karl Oblique (talk) 04:01, 2 December 2021 (UTC)[reply]

I do think that sorting the data in P106 serves both:

a. make the data to be used in Wiki projects and in external applications. it's one of Wikidata goals as far as I remember.

b. It's improve the data in Wikidata itself. Few occupations are main (the best would be to research criterias why it's main like Karl Oblique suggested: total time spend) and other simply not the main occupation. Geagea (talk) 10:32, 2 December 2021 (UTC)[reply]

You might be looking for professions in the occupation field (a frequent confusion). If so, you should attempt to filter by value type. --- Jura 10:43, 2 December 2021 (UTC)[reply]

Capturing heuristics was my first thought upon reading this too. Total time spend is a good one, but obviously hard to accurately source. Another that would be easier to achieve is the number of references supporting a statement (which statistically you'd imagine would prioritise the most relevant). In a way it would be a useful incentive for editors to add plenty of references to the statements they want to appear in infoboxoes. SilentSpike (talk) 11:44, 2 December 2021 (UTC)[reply]

I'm not active at Hebrew Wikipedia, but I would advise any project to be highly critical of the data drawn from Wikidata, and allow common sense (local control) to override blind importation of data. Local infoboxes should be modified/customized as appropriate, not Wikidata items. Wikidata items can have enormous amounts of indiscriminate data; usually only a select portion is relevant for any given use. There is no good way to harmonize data usage or priority across different projects, infoboxes, and purposes. Wikidata is messy and primarily for robots. Anything that's intended to be viewed and read by humans should have heavy human oversight and discretion. (And as an aside, I think slave owner (Q10076267) should systematically be moved to social classification (P3716) and discouraged from occupation (P106), similar to enslaved person (Q12773225): while slave trader (Q17769800) is an occupation, slave owner is a social role more akin to owner-occupier (Q4993251).) -Animalparty (talk) 20:01, 1 December 2021 (UTC)[reply]

do not follow sitelink redirects when redirect badge is used

Tracked in Phabricator
Task T278962

Redirect pages on Wikimedia projects can still not be connected to Wikidata items as sitelinks even when redirect badge is used. This force users to use an ugly workaround. The last task which I found is here, but existed many tasked before, one of them was initiated on 5 August 2013!

@Ladsgroup, AKlapper (WMF), Lydia Pintscher (WMDE): this is not solved for many years, is there any hope that this will be solve soon given all the importance of this task for all wikipedias? I'm a software developer myself, even though my main language is python, I can try to contribute to this issue. The main problem for me is where can I test my code? I need to set up first a development environment with both Wikibase Client and Wikibase Repository? Or someone will do this issue in the next few months? --Northumber (talk) 14:52, 1 December 2021 (UTC)[reply]

Hi, I don't work for WMDE (and Wikidata team) anymore and this is my volunteer account. So I'm not the right person for this discussion. Amir (talk) 15:04, 1 December 2021 (UTC)[reply]

Hi, I don't know (or even define) the priorities of the Wikidata team - mw:Bug management/Development prioritization might only provide some general hints. :-/ --89.103.185.228 21:02, 1 December 2021 (UTC)[reply]

meeting and list of meetings mixup

At https://www.wikidata.org/w/index.php?title=Q50877551&action=history there seems to be mixup of the two. Can someone kindly unmerged them and revert the corresponding Krbot task. I'd do it myself, but apparently it's preferred that people read about it here and do it themselves. @Congolandia.g:--- Jura 17:49, 1 December 2021 (UTC)[reply]

Sorry, but where's the mixup? All the linked articles are lists of the meetings of the European Council... Which ones should be unmerged in your opinion? --Congolandia.g (talk) 17:57, 1 December 2021 (UTC)[reply]

IMHO Q2993919 should be (an instance of) a meeting (even if it went on for several days) and not a list of meetings.

Accordingly, this https://www.wikidata.org/w/index.php?title=Q50877551&diff=973600102&oldid=973600044 merger should be undo --- Jura 18:26, 1 December 2021 (UTC)[reply]

I see what do you need. So I should undo the merge, but then move the link to the page in French to the list, because it lists the meetings... -Congolandia.g (talk) 19:27, 1 December 2021 (UTC)[reply]

Done. Check if it works like you wanted. -Congolandia.g (talk) 19:36, 1 December 2021 (UTC)[reply]

Looks ok, but most if not all others on https://www.wikidata.org/w/index.php?title=Special:WhatLinksHere&target=Q1526506&uselang=fr should be changed too. Apparently the Krbot task is too old to be reverted. --- Jura 20:31, 1 December 2021 (UTC)[reply]

Cleaning up some Mites

Hi everyone. https://www.wikidata.org/wiki/Q2441993 and https://www.wikidata.org/wiki/Q19137 are on the same subject. There is an issue with some languages though, with the German https://de.wikipedia.org/wiki/Milben not being linked on the English https://en.wikipedia.org/wiki/Mite, but indeed vice versa.

I wanted to merge the items with the gadget, but it did not let me. I think I am not qualified to continue with this, so I would be grateful if someone with more experience could pick this up. This issue has persisted since at least 2015, since that is when someone else had complained in the 'talk' Section of the english article. -- Banvd (talk) 21:30, 1 December 2021 (UTC)[reply]

They're on the same subject, but they are not the same thing. In essence, Q2441993 are a set of organisms commonly called 'mites'. These are asserted to be a subclass of Q19137 'Acari'. Q19137 'Acari' is a formally recognised taxon. A number of wikipedias have articles on both subjects. You can be certain sure that these two items will not ever be merged. It's possible that language wikipedia articles may be linked to the wrong one of the two items; if so, that can be remedied. --Tagishsimon (talk) 21:35, 1 December 2021 (UTC)[reply]

mite (Q2441993) is for mites. Acari (Q19137) is for mites and ticks. Nosferattus (talk) 01:40, 3 December 2021 (UTC)[reply]

Q17405793 vs Q62627163

What is the difference between racewalker (Q17405793) and pedestrian (Q62627163)? --HarryNº2 (talk) 12:50, 2 December 2021 (UTC)[reply]

@Gamaliel: who created pedestrian (Q62627163) - person who engages in pedestrianism, or competitive walking.

I first thought you were asking about pedestrian (Q221488). --- Jura 13:02, 2 December 2021 (UTC)[reply]

::I'm afraid I don't know enough about the subject to know if there is a distinction between those two terms. Gamaliel (talk) 15:40, 2 December 2021 (UTC)[reply]

Perhaps this article can help clarify the situation pedestrianism (Q7159160) (en:Pedestrianism). --HarryNº2 (talk) 13:24, 2 December 2021 (UTC)[reply]

@HarryNº2: pedestrian (Q62627163) is the historical term and racewalker (Q17405793) is the modern term (for the modern version of the sport). Nosferattus (talk) 01:45, 3 December 2021 (UTC)[reply]

In the meantime I have read the English article about it. Thanks!

It would be nice if someone with sports knowledge could add the related properties. HarryNº2 (talk) 07:49, 3 December 2021 (UTC)[reply]

items for redirects with subject has role (P2868) = Wikimedia redirect page (Q21528878)

The other I noticed such statements and, as I can't see its use, I added a corresponding constraint at subject has role (P2868) (see Property_talk:P2868).

Items: Wikimedia redirect (Q21528878)  

Properties: subject has role (P2868)  

, instance of (P31)  

SELECT ?item ?itemLabel ?itemDescription ?sls ?sts ?inst ?instLabel
{
	?item wdt:P2868 wd:Q21528878 ; wikibase:sitelinks ?sls ; wikibase:statements ?sts .
    OPTIONAL { ?item wdt:P31 ?inst }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

The question is now what to do with these items, at least with the ones that only link to redirect pages and are instances of "duplicate".

Apparently no other P31 was found, so I suggest we delete these items.

@Fidoez, Paine_Ellsworth: who edited some. --- Jura 12:50, 2 December 2021 (UTC)[reply]

URL update request

At DSSTox substance ID (P3117), could someone take a look at the URLs? Here I've made an update request. -DePiep (talk) 16:08, 2 December 2021 (UTC)[reply]

I think you already made the correct change on the property itself. It just takes some time to propagate to each item. --- Jura 16:11, 2 December 2021 (UTC)[reply]

OK. Thx. I couldn't get it working so thought better not touch it & ask a more experienced editor :-) -DePiep (talk) 18:59, 2 December 2021 (UTC)[reply]

Linking specific plant/animal individuals to their species

Hello, I'm having hard time understanding how specific plants or animals (often long-lived or otherwise famous specimen) are linked to their species. Here are some examples I gathered:

Moja (Q12038481) has instance of (P31) : western lowland gorilla (Q876500), which has subclass of (P279) : animal (Q729). Sounds straightforward but are really all animal taxa supposed to be subclass of (P279) : animal (Q729)?
Borovice u Žibřidic (Q26789614) has instance of (P31) : Pinus sylvestris (Q133128) but that isn't subclass of anything, it's just a taxon item, and it triggers a constraint warning. What would be a proper step there?
Sunny (Q14744025) has instance of (P31) : Portuguese water dog (Q38559) which has subclass of (P279) : dog (Q144), which is however not a taxon item at all and is not linked to Canis familiaris (Q20717272) or Canis lupus familiaris (Q26972265)
Methuselah (Q590039) isn't linked to Pinus longaeva (Q1116374) at all as far as I can see.

I'm wondering if we can come up with a way of labelling specific animal or plant individuals which will enable us to query for "individual's items" per taxon Vojtěch Dostál (talk) 16:53, 2 December 2021 (UTC)[reply]

There are also remarkable tree (Q811534), individual animal (Q26401003) and animal breed (P4743). --- Jura 17:11, 2 December 2021 (UTC)[reply]

Global ban for 1Goldberg2

Per the Global bans policy, I’m informing the project of this request for comment: RfC/Global ban for 1Goldberg2. – Mrakia 12:04, 3 December 2021 (UTC)[reply]

@@ Line 706: / Line 706: @@
 :There are also {{q|Q811534}}, {{Q|Q26401003}} and {{P|4743}}. --- [[User talk:Jura1|<span style="display:inline-block;transform:rotate(-8deg);-moz-transform:rotate(-8deg);-webkit-transform:rotate(-8deg);-o-transform:rotate(-8deg);">Jura</span>]] 17:11, 2 December 2021 (UTC)
+== Global ban for 1Goldberg2 ==
+Per the [[m:Global bans|Global bans]] policy, I’m informing the project of this request for comment: [[m:Requests for comment/Global ban for 1Goldberg2|RfC/Global ban for 1Goldberg2]]. – [[User:Mrakia|<span style="text-decoration: inherit; color: #f47fff;">Mrakia</span>]] 12:04, 3 December 2021 (UTC)

Wikidata:Project chat: Difference between revisions

Revision as of 12:04, 3 December 2021

Contents

Property for nationality

Wikidata phase 1 regression

[Feedback Requested] Introducing a dedicated section on Wikidata Item pages for classifying properties

A sub-class for media and/or medium

"Cameroon" as unit

Nominating MoveClaim to become a Special:Gadget

Property for dates of talks of a conference?

Blais

Talk to the Community Tech: The future of the Community Wishlist Survey

P1476 (title)

Bot work for Cleveland Museum of Art

Could a new constraint help dealing with conflation issues?

need alternative for "parent organization" property

Catalonian republics

Help! My Mullvad (Q47008412) VPN ip got through(I did not expect this), you need to block my IP. Please replace it with Oduci, please scrub my IP and replace it with Oduci. Thank you.

Latin language Label

Wikidata weekly summary #496

Pages (per category) for suggested databases to link out to

Q1758677 (oeuve)

Low-quality references by Magnus and his bot - can we fix them?

merging two item is complicated

L'Hospitalet de Llobregat train station / Rambla Just Oliveras metrostation

P106

do not follow sitelink redirects when redirect badge is used

meeting and list of meetings mixup

Cleaning up some Mites

Q17405793 vs Q62627163

items for redirects with subject has role (P2868) = Wikimedia redirect page (Q21528878)

URL update request

Linking specific plant/animal individuals to their species

Global ban for 1Goldberg2

Navigation menu

Wikidata:Project chat: Difference between revisions

Revision as of 12:04, 3 December 2021

Property for nationality

Wikidata phase 1 regression

[Feedback Requested] Introducing a dedicated section on Wikidata Item pages for classifying properties

A sub-class for media and/or medium

"Cameroon" as unit

Nominating MoveClaim to become a Special:Gadget

Property for dates of talks of a conference?

Blais

Talk to the Community Tech: The future of the Community Wishlist Survey

P1476 (title)

Bot work for Cleveland Museum of Art

Could a new constraint help dealing with conflation issues?

need alternative for "parent organization" property

Catalonian republics

Help! My Mullvad (Q47008412) VPN ip got through(I did not expect this), you need to block my IP. Please replace it with Oduci, please scrub my IP and replace it with Oduci. Thank you.

Latin language Label

Wikidata weekly summary #496

Pages (per category) for suggested databases to link out to

Q1758677 (oeuve)

Low-quality references by Magnus and his bot - can we fix them?

merging two item is complicated

L'Hospitalet de Llobregat train station / Rambla Just Oliveras metrostation

P106

do not follow sitelink redirects when redirect badge is used

meeting and list of meetings mixup

Cleaning up some Mites

Q17405793 vs Q62627163

items for redirects with subject has role (P2868) = Wikimedia redirect page (Q21528878)

URL update request

Linking specific plant/animal individuals to their species

Global ban for 1Goldberg2

Navigation menu

Search