Wikidata

Wikidata:Project chat/Archive/2019/02

< Wikidata:Project chat‎ | Archive‎ | 2019
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

i18n hell

How are folks supposed to add a missing language to a description? I tried the documented {{#babel:ru-0}} configuration, but that did not work for me. –84.46.53.94 11:10, 1 February 2019 (UTC)

It didn’t work because you are not logged in. – Máté (talk) 11:20, 1 February 2019 (UTC)
Noted under Errata, thanks. Should I also add an {{edit request}} on the talk page? –84.46.53.94 12:56, 1 February 2019 (UTC)

Re-purposing United States Armed Forces service number (P2028)

On-going discussion about repurposing the scope of United States Armed Forces service number (P2028) at Property_talk:P2028#Repurposing_for_wider_coverage, welcoming more participation there. KCVelaga (talk) 12:33, 1 February 2019 (UTC)

duplicate items created from Cebuano/Swedish Wikipedia pages

There are numerous duplicate items in Wikidata created from Cebuano and Swedish Wikipedia pages. Please note:

  • São Francisco do Conde: Q1648073 vs. Q22035151
  • Cachoeira: Q985576 vs. Q22063160
  • Lauro de Freitas: Q905164 vs. Q32089629

Thanks. Prburley (talk)

Prburley, none of them are duplicated items. . São Francisco do Conde (Q1648073) refers to a municipality and São Francisco do Conde (Q22035151) is a place within it. The same for Cachoeira (Q985576) (municipality) and Cachoeira (Q22063160) (place), and Lauro de Freitas (Q905164) with Lauro de Freitas (Q32089629). However, some of the entries where in the wrong item (I think that is what you meant) and I have placed them where they belong. Esteban16 (talk) 14:30, 1 February 2019 (UTC)
I think this is just auto-generated data, of what use, I'm not sure. The municipality of Cachoeira (Q985576) is different than the human settlement of Cachoeira (Q22063160)? We don't have separate items for the city of Chicago (Q1297) and the human settlement of Chicago. Important side note: Cachoeira does have a district called Cachoeira (Sede), but that's not described in the Wikipedia page for Cachoeira (Q22063160). Prburley (talk)
They are different indeed. Cachoeira (Q985576) is a municipality, has a higher population and area than Cachoeira (Q22063160), which belongs to it. The same applies to the other items. You can think of it as a town/city in a county with the same name. Esteban16 (talk) 18:34, 1 February 2019 (UTC)

Archives in Wikidata

There's a problem concerning archives of some Wikidata pages. There's a text on this page: On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2019/01. In fact the page Wikidata:Project chat/Archive/2019 really exist and it's in the Category:Project chat archive, but on the main page of Wikidata:Project chat/Archive 2019 is absent. The same situation with Wikidata:Properties for deletion: Wikidata:Requests for deletions/Archive/2019 exist in Category:Archived requests for deletion and 2019 is not in Wikidata:Project chat/Archive. Can somebody fix it? --Ksc~ruwiki (talk) 19:46, 31 January 2019 (UTC)

done. --Pasleim (talk) 09:48, 1 February 2019 (UTC)
Thank you very much. --Ksc~ruwiki (talk) 19:59, 1 February 2019 (UTC)

Russian help?

I ran across computer science (Q16665201) - which is an item for a ru:wp term that currently redirects to the entry for computer science, Информатика, which shows up in the item for computer science (Q21198). Компьютерные науки is identified as a permanently duplicated item, but it looks like a redirect to me...Just curious what this is all about, and whether it should be merged with the main computer science item. -- Phoebe (talk) 15:52, 1 February 2019 (UTC)

I've seen other cases like that. Delete the ruwiki sitelink and merge them! ArthurPSmith (talk) 16:04, 1 February 2019 (UTC)
It appears I have to delete everything - it looks like the "permanently duplicated" property blocks merges? I'm not familiar with this -- Phoebe (talk) 16:53, 1 February 2019 (UTC)
Sorry, yes, that property needs to be removed on both items as well. I took care of it. ArthurPSmith (talk) 18:23, 1 February 2019 (UTC)
Yes, it was just redirect. --Ksc~ruwiki (talk) 20:06, 1 February 2019 (UTC)

Place of birth (P19) constraint

I wonder if this is a reasonable constraint to require sex or gender (P21) while entering place of birth (P19). P31 → Q5 E.g. Q58426257. Kpjas (talk) 10:16, 29 January 2019 (UTC)

  • Why would this be desirable? Why, for example, if there is an individual such as [[Q|863253}} and someone might not be sure how to address the gender issue would we want that person to be unable to enter place of birth? - Jmabel (talk) 16:24, 29 January 2019 (UTC)
    • Yes, we have plenty of these logging constraints that don't really point out false information, I think constraints aren't the right place for that. Thanks for asking and please remove it! --Marsupium (talk) 17:18, 29 January 2019 (UTC)
  • On the more general issue, there seem to be a lot of these weird inconsistencies around for people. At the moment, place of birth requires gender (but not date of birth); place of death requires date of death; date of birth/death has no limits; military rank and residence (!) require gender; and so on. There's also a weird mismash with what's required for identifiers, so eg Oxford Dictionary of National Biography ID (P1415) needs gender, birth, & death; but Australian Dictionary of Biography ID (P1907) needs gender, birthdate, & given name. A standard set of "this item is about a human" constraints might be worth thinking about. Andrew Gray (talk) 21:07, 29 January 2019 (UTC)
    • If all entries of an authority have information about "gender, birth, & death" then it makes sense to have the constraint for those as every item that has the authority reference should be able to be filled with that information.
Different authorities have different information for all their entries. On the other hand, I see no reason why residence should require gender as it's possible to know someone's residence without knowing their gender.
In general most sources that tell you where someone died also tell you when they died. On the other hand, plenty of sources that tell you where someone was born don't tell you when they were born. ChristianKl ❪✉❫ 22:54, 29 January 2019 (UTC)
Please correct me if I got that wrong, but most sounds like SHOULD, while constraint sounds like MUST. –84.46.53.126 08:33, 30 January 2019 (UTC)
No. Every constraint has a text that tells you what the constraint means. The text of is item-requires-statement constraint (Q21503247) "type of constraint for Wikidata properties: used to specify that an item with this statement should also have another given property" and the template says "Item: items with this property should also have". It's worth noting that single-value constraint (Q19474404) uses by design a wording that's even weaker then should.
Constraints on Wikidata are things that produce lists of constraint-violations that make it easy for a user who wants to work on items with a particular problem to find items that have the problem. The same value constraint on VIAF ID (P214) makes it easy for a VIAF employee to go through all items on Wikidata that have multiple VIAF IDs. The constraint isn't supposed to be understood that in cases where VIAF has to separate numbers for the same person, that we shouldn't list all the numbers.
Constraints also graphically alert a user who looks at an item that the constraint was violated to direct attention. ChristianKl ❪✉❫ 10:49, 30 January 2019 (UTC)
It's worth noting that single-value constraint (Q19474404) uses by design a wording that's even weaker then should. NB: by ChristianKl’s design. By default the software uses “should” like on all other constraint types (see phabricator:T192563). --Lucas Werkmeister (WMDE) (talk) 17:49, 30 January 2019 (UTC)
It's not my design. It was designed that way before I registered an account on Wikidata. The fact that you tried to change the existing policy when you designed your software and I saw to restoring the original meaning of the constraint doesn't make it my design. ChristianKl ❪✉❫ 20:05, 30 January 2019 (UTC)
The design decision happened in 2013 by Doco. ChristianKl ❪✉❫ 20:09, 30 January 2019 (UTC)
Thanks, so far I only stumbled over mandatory stuff like regular expressions, and just assumed that constraint is some kind of MUSTard, where any violations flood maintenance categories or trigger auto-bans.  –84.46.53.94 13:17, 1 February 2019 (UTC)

Magazine covers/cover pages imported as scholarly articles?

I haven't investigated in depth, but it look like a whole bunch of magazine/journal covers have been imported as standalone "scholarly articles" (see Q59686497, Q59686853, Q59686707, Q58797909, etc.). Is this intended/common practise? I started editing one (Q57773826) but figured this might be better handled by a script or something. Moebeus (talk) 19:16, 30 January 2019 (UTC)

@Moebeus: They're probably individually notable because of the structural notability criterion. I think a bot run would be useful, given the large number of items (including ones with titles like AAQ volume 27 issue 3 Cover and Back matter (Q59230083)).
@Richard Nevell, Daniel Mietchen: Would it be possible/desirable to use QuickStatements or another tool to update the relevant items with the approach used by Moebeus at Cover (Q57773826)? (The constraint violations are because cover (Q44532723) doesn't have the correct subclass.) Jc86035 (talk) 10:48, 3 February 2019 (UTC)
Front matter and covers probably shouldn't be classed as scholarly articles. Finding a way to represent them would be useful and the Moebeus did at Cover (Q57773826) looks sensible. Richard Nevell (talk) 17:17, 3 February 2019 (UTC)

Alexander and Александр

Both Alexander (Q923) and Aleksandr (Q17501806) seem to be the same entity (a given name, Alexander), just different languages. Note that both have "Александр" in the Russian translation. Is it standard practice to have both (and if so, why?), or should they be merged? -Animalparty (talk) 00:06, 1 February 2019 (UTC)

They have the property said to be the same as, so their equiality is debatable. Besides the labels are not all the same, for example Q923 is "Alexander" for Catalan, while Q17501806 is "Aleksandr". Esteban16 (talk) 02:42, 1 February 2019 (UTC)
Alexander (Q923) is in latin script, Aleksandr (Q17501806) in cyrilic, so definitely different entities and nothing to merge. But I am not sure if it is wise to fill latin transliteration as Aleksandr (Q17501806) label, as it is causing a bit mess.--Jklamo (talk) 23:22, 1 February 2019 (UTC)
Labels should always be in their own language, so using the most frequent transliteration in the language when the name is using another writing system. The description is here to disambiguate what the item is about. --Harmonia Amanda (talk) 12:50, 2 February 2019 (UTC)
Jklamo So does that mean that every script variant of every name needs its own item/entitiy? The name "Jonathon" in Korean is "조나단", in Persian is جاناتان in Russian is Ионафан, in Armenian is Հովնաթան, etc. Seems a bit silly, but to be honest much of the and hair-splitting and bean-counting at Wikidata is beyond me. Animalparty (talk) 04:51, 3 February 2019 (UTC)
Apparently yes, but the problem with items that differ by transliteration is how do you know which item to use for a particular person? Do you just take the language of the country where they are born? Or do you have to consider what language their parents were using when they named them? If you can even guess. Ghouston (talk) 08:40, 3 February 2019 (UTC)

officeholder (P1308)

Property:P1308 is sometimes used to hold the incumbent for an office and the previous holders are deleted and in some entries all holders are listed along with their series ordinal, sometimes with the dates of holding the office. Is there a preference? It can duplicate data held at the record for the person that held the office. I can't find the records that caused me to ask, so I created a demo here: Choir leader of Ytterlännäs parish (Q25916691) --RAN (talk) 19:27, 1 February 2019 (UTC)

  • My take:
    • Past holders should be listed with start & end dates as qualifiers.
    • Not so sure of the importance of the ordinal, but if it's known, great. (Often we will not have completed data on holders of an office.)
    • If the same person held it twice, that's two different statements.
    • I'm guessing we should mark the current holder of the office as having preferred rank.
Jmabel (talk) 20:31, 1 February 2019 (UTC)
Excellent, thanks! Preferred rank a great way to designate the incumbent. --RAN (talk) 23:20, 1 February 2019 (UTC)
  • Data shouldn't be deleted. Marking the current office holder is standard practice to allow templates that want to query for the current office holder to easily get it. ChristianKl ❪✉❫ 09:09, 2 February 2019 (UTC)
  • In general listing past officeholders on their own items is probably "best", and you should always do that one if you can, but there's no real reason not to put data on the main item as well (assuming the numbers are reasonable). One advantage to using the item is that you can explicitly model gaps this way - "from 1940 to 1944 no-one held the office of President of France" can be represented as officeholder: no value, dates 1940-44. I am not sure how often you would want to do this, but it might be useful in some circumstances to clearly state an absence, especially as you can add a qualifier to say why. Andrew Gray (talk) 10:45, 2 February 2019 (UTC)
Yes, it is always difficult to determine if a gap is an error in the data or there was no one in office until a new election could be held, or no one was in office while a search was taking place for an appointee. I see this all the time in lists of mayors. Perhaps there should be a better way to designate an incumbent for the wikidata_infobox. Do you think we need a separate field called incumbent_officeholder or does the deprecation of ex-officeholders work best? --RAN (talk) 15:26, 2 February 2019 (UTC)
Marking the current one as preferred is always a good approach - that means a simple wdt:P39 search query or a WP infobox lookup will get them and only them. Don't deprecate the old ones, though, just leave them as normal rank (since they're old data, but not "wrong").
The other approach (which is a bit more sophisticated and so may not be useful for infoboxes) is to rely on all entries having start/end qualifiers, and assuming that (logically) any with a start but no end is current. Of course, there are obvious pitfalls here if the data is incomplete. Andrew Gray (talk) 16:33, 2 February 2019 (UTC)
  • It's possibly worth noting here that as well as the duplication of data caused by having this information on both the item for the position itself (with officeholder (P1308)), and for the person (with position held (P39)), if the office in question is that of the head of government or the head of state, then it will also be repeated again on the item for the country/territory/state etc, with head of government (P6) or head of state (P35). Personally I think that's quite useful, and comparing where these values differ is a useful check for both missing and mis-entered data, but I also know that others see that as more problematic. The other complaint I've seen previously about having historical data on the position or the place is that that can run to potentially hundreds of past officeholders. That rarely happens in practice at the minute, as it's currently rare for people to actively add lots of past officeholders: the usual pattern is more incremental, when the current holder leaves office, and their replacement gets added. But if we were to add all historic heads of state and heads of government to the items for each country, for example, that could get a little overwhelming. --Oravrattas (talk) 19:16, 2 February 2019 (UTC)
My understanding of the practice is: only the current one is registered as an office holder on the item of the position. All previous office holders are expressed as "position held" "position" with date and time. It is expressed well in Reasonator on either. Thanks, GerardM (talk) 20:50, 2 February 2019 (UTC)

Where to translate these words of Module pages?

"Code Discussion Links Link count Subpages: Documentation Tests Results Sandbox Live code All modules" --125.38.13.232 08:20, 3 February 2019 (UTC)

Template:Module-nav/i18n. Sjoerd de Bruin (talk) 10:01, 3 February 2019 (UTC)

New Tool: SpeedPatrolling

Commentated screencast demonstrating the tool.

Hi everyone! I’m announcing a tool I’ve been writing over the past month: SpeedPatrolling (documentation). It’s intended to make patrolling easier, especially on mobile – it doesn’t replace other tools (like reCh), but it should allow you to handle some common simple cases, leaving other patrollers free to take care of other things. Please try it out! --Lucas Werkmeister (talk) 18:09, 3 February 2019 (UTC)

Delete statements

genre (P136)film adaptation (Q1257444) can be deleted here, I added genre (P136)film based on literature (Q52162262) from dewiki based on Category:Films based on literature (Q8126322): [1] thx Queryzo (talk) 19:54, 5 February 2019 (UTC)

@Queryzo: Done in An deiner Seite (Q50824526), but in futute you can do it yourself by clicking on "Edit" and "remove". Bovlb (talk) 21:37, 5 February 2019 (UTC)
yes, but this are 100+ items and PetScan seems to have a problem with -P136:Q1257444. So I hoped somebody can do this job with bot help. Queryzo (talk) 23:01, 5 February 2019 (UTC)
@Queryzo: Aha! I somehow missed the SPARQL link in your original comment and misinterpreted what you were asking for. Bovlb (talk) 17:35, 6 February 2019 (UTC)
@Queryzo: Done. Bovlb (talk) 17:44, 6 February 2019 (UTC)
This section was archived on a request by: Queryzo (talk) 17:23, 8 February 2019 (UTC)

Referencing question

Obviously, URLs have their limitations as citations because they can eventually go bad. For Saint Francis Xavier Mission (Q61238391) I've used http://community.seattletimes.nwsource.com/archive/?date=19960617&slug=2335023 as a reference for country (P17) and located in the administrative territorial entity (P131). Is there some way to indicate that that is 'Jenkins, Don. "Western Washington To Lose Last Friar, Franciscan Mission". Seattle Times. Retrieved 2019-01-29'? - Jmabel (talk) 00:25, 31 January 2019 (UTC)

@Jmabel: If you are looking for information about referencing, have a look at Help:Sources. There is a section for newspaper articles. Snipre (talk) 07:43, 31 January 2019 (UTC)
@Jmabel: I can heartily recommend using one of the CiteTool variants for this type of referncing. See the discussion at Wikidata:Project_chat/Archive/2019/01#CiteTool_(autofill_for_references). The tool crreates an "autofill" button when you create a "reference URL" statement. - PKM (talk) 19:15, 31 January 2019 (UTC)
Perhaps I don't understand what to do. Following that, I edited User:Jmabel/common.js (previously blank) but this doesn't seem to do anything when I enter a reference URL. - Jmabel (talk) 01:32, 1 February 2019 (UTC)
@Jmabel: It should add an “autofill” link next to the “remove” link for the reference URL when it’s open for editing. Very subtle - I didn’t see it at first. - PKM (talk) 04:12, 2 February 2019 (UTC)
@PKM: Nope, not happening for me. Should I have to do anything else besides what I did at User:Jmabel/common.js? - Jmabel (talk) 06:04, 2 February 2019 (UTC)
@Jmabel: It looks like you've got the original (now broken) version in your common.js. Try the one here: User:Mvolz (WMF)/CiteTool.js (or grab it from my common.js page - it's the last entry). - PKM (talk) 23:27, 2 February 2019 (UTC)
@PKM: Closer, but doesn't seem to work right either. It put up a modal popup "Generating Citation/Generating a reference for you.... please wait...", filled in quite a few properties, but 2 minutes later the modal popup was still there so I couldn't save them! Couldn'tscroll, couldn't save: basically the page locked up on me. So I tried to refresh the page, and now the "autofill" isn't there at all. So while I would love to have this feature, in its current state it seems to be a liability rather than an asset. - Jmabel (talk) 01:09, 3 February 2019 (UTC)
@PKM, Mvolz (WMF): I can also verify that it doesn't actually work and just freezes the page (Firefox 65). It's technically usable if the overlay is deleted with the browser element inspector, but still... Jc86035 (talk) 11:04, 3 February 2019 (UTC)
I've only seen the pop-up ~3 times out of about 100 uses (and I believe hitting ESC will clear it and preserve the data). I've only had one error that I couldn't salvage (and notified Mvolz). FWIW I'm using Chrome on Windows 10. - PKM (talk) 20:09, 3 February 2019 (UTC)
just a data point - I’ve confirmed that hitting ESC stops a long-running operation and saves what has been collected so far. And linking to Google Books URLs throws an unrecoverable error on “number of pages”, though I was able to copy all of the returned fields and use them in QS to create the work/edition(probably not worth the trouble of converting fields to Properties). - PKM (talk) 23:42, 3 February 2019 (UTC)
Thanks, I'll try that. - Jmabel (talk) 01:20, 4 February 2019 (UTC)
That's certainly a lot better. Still, I don't like at all that you seem to have to either accept all or none of the edits it makes. It turned "The Daily Chronicle" (a newspaper in Lewis County, Washington) into The Chronicle (Q7722795)! - Jmabel (talk) 01:35, 4 February 2019 (UTC)

Generating a list of all items

Hello everyone,

I'm new here, so apologies for my lack of knowledge. I'm trying to create a simple database table with the Q-ID, English Label, and English description of every (applicable) item in Wikidata. Right now I'm using PyWikibot to query IDs 1-100,000,000. I know this is a very naïve approach, and I'm currently working on writing a Pywikibot generator.

Is there an easier way? Here are a couple things I've tried:

  • SPARQL Queries - query.wikidata.org gives me a timeout when I ask for every item with a P31.
  • Downloading the JSON dump - This option is difficult but might be something I have to revisit. I can't load the 120GB file into memory, but I tried splitting the 120GB into chunks. I stopped working on this option after discovering the API.

Thanks!  – The preceding unsigned comment was added by Wordball (talk • contribs).

If you are only interested in retrieving labels and descriptions have a look at the wb_terms SQL table. You can query that table with Quarry or with an own account on Toolforge. --Pasleim (talk) 14:50, 4 February 2019 (UTC)
@Wordball: You might also want to start from the dumps - see https://dumps.wikimedia.org/wikidatawiki/entities/ for example. ArthurPSmith (talk) 15:43, 4 February 2019 (UTC)

Ontology import into Wikibase

I would like to import an ontology into a new Wikibase instance, in the sense that it prepopulates classes (as items), properties and (ideally) constraints. I was wondering if there was anything better than what is described here. Pdehaye (talk) 12:57, 4 February 2019 (UTC)

Daty Wikidata Editor alpha release

Hi everyone,

I am Pellegrino Prevete, aka Ogoorcs and I am proud to officially announce the alpha version (Q2122918) release of Daty (Daty (Q60949478)), the native Wikidata editor I proposed at the Ideathon of itWikiCon 2018 (Q43527331), which aims to hugely simplify Wikidata UX for new and old advanced users.

During this first development month, as hoped, Daty has found approvals outside of wiki communities, too: the GNOME (Q44316) project has in fact accepted to host it on its development platform and the software has already been published on Flathub (Q43089335), the free software GNU/Linux app store in Flatpak (Q22661286) format.

Unfortunately I was not able to pack all planned features in this first release, although I hope that, trying it, you will agree that the work done has been adequate.

Set up sound foundations for the program was where it took longer than expected, i.e. make it work on all supported platforms and on all screen format factors. In fact at the time of writing Daty is one of the few responsive GTK (Q189464) applications and the only cross-platform one.

To calm down the potential storm of people fearing for vandalisms caused by a simpler editor, I must warn you that until an adequate revert tool for mass edits made with the program will be made available, Daty will browse the database *read-only*. At this time already it has been made so (not specifically in Daty but in Pywikibot) that only registered users will be able to edit entities.

Download

Installer links are available for Microsoft Windows (64 bit) and GNU/Linux (all architectures).

You can read a more complete changelog on my blog; bug reports can be sent on the issues page.

Note for GNU/Linux users

If you use a Flathub-integrating distribution (Linux Mint, Endless OS and others), you can directly install the software from your graphical package manager. If your distribution preinstalls GNOME and GNOME Software (Q15968880), you will just need to open the *Activities* screen and search for "Daty", as seen in this picture.

In any case you can install flatpak on your distribution by visiting this page or follow the distro specific installation istructions on the Daty homepage.

If you already installed a previous flatpak of the software, I advice you to wait for the update of tomorrow (build already scheduled), because of a last-minute bug in the configuration directory permission settings which has been corrected this morning.

Note for Ubuntu users

Since at this time Ubuntu has decided to support by default only the Snap (Q22908866) package format, you will not directly find the program in the software center. If there are enough requests though, I will make a snap version of Daty.

In any case deb (Q305976) packages will be made available in due time.

Note for Mac users

The software works on Mac, but since I do not own one I could not create the executable file. Again, if there are enough requests, we can find a way to solve this.

Thanks

First of all I want to thank Wikimedia CH for trusting the idea; without them Daty would still be a mockup this day. I hope that the global community, as the Italian one already did at the ItWikiCon Ideathon, will see the impact and the usefulness of a native editor, to please advanced users and greet new ones.

Of course I have to thank the GNOME project, which accepted the project on its infrastructure, and its developers, volunteers and contributors, who saved me from many headaches this month and before. I think it is a really great community.

Ogoorcs (talk) 01:36, 30 January 2019 (UTC)

Discussion

  • Before I put any time at all into looking at this; what (if anything) can you do with and editing tool that is read-only? Is this just so people can get a chance to get an advance look at it, or is there something where it is already a useful tool? - Jmabel (talk) 03:56, 30 January 2019 (UTC)
@Jmabel: Of course this is just a preview version, as specified in the package description. The list of planned features, aka the temporary roadmap is linked above at the second line. Of course it will have read-write access. How could I call it "editor" otherwise? :D
In any case at the moment you already got with the program a more compact and (way) faster Wikidata reader. With it you can keep open over ten Wikidata pages without your browser severely lagging and see more than 4 values without scrolling the page. Awesome, am I right?
On the flatpak you can already type to start filtering properties. Of course in-page filtering will not be limited to entitiy labels but will be extended to whatever I can extract from entities (descriptions, statements, etc).
January development has been made possible by the Ideathon prize; this release has been made to let the wiki and FOSS communities know and discuss the project and let Wikimedia see how much could be made in a one-man month. The idea is to get the project financed some way through the stable release, which I hope it will happen next month or so. Ogoorcs (talk) 09:39, 30 January 2019 (UTC)
Does it support lexemes? KaMan (talk) 15:17, 30 January 2019 (UTC)
@KaMan: Daty uses Pywikibot (Q15169668) as backend, which currently does not support them. If the project will get funds to continue development I plan to either add support for them in pywikibot itself or implementing the parsing myself. Ogoorcs (talk) 19:08, 30 January 2019 (UTC)
Interesting concept. I just checked it and it doesn't seem to support dates or geographic coordinates yet. The interface seems a bit convoluted to me, maybe there might be reasons for that.--Micru (talk) 10:08, 31 January 2019 (UTC)
@Micru: Yes, I plan to support those using native GTK+ widgets for those. They are of course in the todo list. What do you refer when you say "convoluted"? Ogoorcs (talk) 03:29, 1 February 2019 (UTC)
@Ogoorcs: The choice of buttons, the arrangement of the layout, the choice of vocabulary, etc. didn't come natural for me as a first time user. I would recommend spending some time improving the user experience, perhaps by analyzing how users react to your software the first time they use it, in order to make it more intuitive.--Micru (talk) 23:18, 1 February 2019 (UTC)
@Micru: I suppose you are talking about the intro/open dialog because:
  • the editor window has the same identical layout of many official Android/GNOME/Mac OS application and I guess everyone these times find those "intuitive";
  • there is no text in the UI there, also the symbolic icons on the buttons are used with the same meaning as in the aforementioned platforms.
So, I have already received an overwhelming amount of negative feedback on the "type to search" intro screen: you still find it in this alpha probably because I didn't want to let bygones be bygones until getting bad feedback here too.
I found the results amazing though:
  • almost no one of the 30 or so people I interviewed in-person actually read what was written in the window before clicking the blue button;
  • of those who did it, only two or three followed the instructions on the screen and actually typed the first letter of their query, making the free text search interface appear;
  • the rest just stared the screen waiting for an input form and blinking cursor to appear because (of course) habit has more power than symbolic icons and bold text.
Of ocourse those pressing the blue button had to select the "Label search" tab because the constraint box is empty due to the entire dialog being rewritten.
Ogoorcs (talk) 02:36, 2 February 2019 (UTC)
UPDATE: @Micru: do you prefer the new style? Intro screen, intro screen with results.
Given that it works much faster then the webinterface I think the editor has promise and hope it will get additional funding. ChristianKl ❪✉❫ 10:15, 2 February 2019 (UTC)

@Ogoorcs: I'm using a Mac. For what it's worth, I successfully installed the package with pypi but encountered the error "ValueError: Namespace Gtk not available" upon launching daty. Jc86035 (talk) 05:36, 5 February 2019 (UTC)

"Layette" and "Childbed linen"

I have made separate items for layette (Q3219968) and childbed linen (Q61436446). The distinction between these concepts is pretty clear in English (to me, anyway), but that may be more a case of different lexemes for the same core concept over time. I don't know how these items are conceptualized in other languages. Any thoughts on whether they should be merged? - PKM (talk) 22:06, 3 February 2019 (UTC)

@PKM: Not that the differences strikes me immediately, but I guess it's good the way you've modelled it with different time period (P2348), proper sourcing, replaces (P1365)/replaced by (P1366) and also the said to be the same as (P460)s, it's understandable. --Marsupium (talk) 19:58, 4 February 2019 (UTC)

A kind of systemic person duplication problem

Hi,

For a while I have been working on Polish scientists. Now and again I'm stumbling on a certain kind of duplication of items. I believe this is not a serious or urgent matter. Just to let you know.

For example:

  • Artur R Stefankiewicz Q60883799 2 statements no sitelinks
  • Artur Stefankiewicz Q26973283 11 statements plwiki sitelink → Artur Ryszard Stefankiewicz

I have observed the same pattern in other cases. I have been merging these items as appropriate but perhaps this could be avoided somehow in the first place ? @Daniel Mietchen:

Kpjas (talk) 09:09, 4 February 2019 (UTC)

We had a doppleganger search at one point that looked for people with the same names and the same birth and death years. Duplicates were merged and actual dopplegangers were marked as "different from" with a qualifier of doppleganger. I had a list at one point and the query, but can't find it. Does anyone know where that search is so it can be run again, or create it again? --RAN (talk) 17:48, 4 February 2019 (UTC)
@Richard Arthur Norton (1958- ): Category:Merge candidates has some lists. I've written queries for that, if you seek high specificity and sensitivity you quickly get WDQS timeouts :/ --Marsupium (talk) 20:04, 4 February 2019 (UTC)

Wikidata weekly summary #350

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

Species items

Some edits by Vanessalozano came up in my watchlist. I don't know if they're correct, although some of them are definitely wrong (e.g. country of origin (P495) with non-country values).

Jc86035 (talk) 15:03, 29 January 2019 (UTC)

endemic to (P183) and invasive to (P5588) should be used, instead of country of origin (P495) and instance of (P31)invasive species (Q183368). --Okkn (talk) 16:23, 29 January 2019 (UTC)
@User:Vanessalozano: Mind to comment? --Succu (talk) 22:35, 30 January 2019 (UTC)
No, "instance of (P31) → plant (Q756)" is never appropiate. (Parenthetically, animal (Q729) and plant (Q756) are defined the same, but have different descriptions, and both have the wrong label. They are high profile items, so this seems inevitable). - Brya (talk) 06:23, 3 February 2019 (UTC)
  • I have this warning in the section taxon name (P225) - qualifier taxon author (P405): "Could not save due to an error. The save has failed. Warning: The value for taxon name (P225) in this (or any) item shouldn't be changed (except for spelling corrections). If a taxonomic paper or book introduces a name change, create a new item for the new name (if needed) and add a statement with taxon synonym (P1420) to that item." I just wanted to add a new qualifier to an existing property as taxon name (P225). Vanessalozano (talk) 09:00, 6 February 2019 (UTC)
What exactly do you want to do? Please do not add the basionym authors like here to P225. --Succu (talk) 09:53, 6 February 2019 (UTC)
endemic to (P183) only applies to living taxa. What should be used as an equivalent for extinct taxa and fossil taxa? --EncycloPetey (talk) 16:33, 4 February 2019 (UTC)

BioRuby releases in github from 1970

This query returns the oldest software in Wikidata. However, there are a lot of spurious results, particularly BioRuby (Q4914654), which has many releases on its Github from Jan 1, 1970. I highly doubt this software existed back then considering that Ruby was created in 1995. The data seems to come from a Github releases page - how would you go about fixing something like this? I've got a related question - what gives with dates given like "t436458995"? I've seen it a few times and don't understand what it is. 

SELECT ?software ?softwareLabel ?date (ROUND((NOW() - ?date)/365.2425) AS ?age)
{
  ?software wdt:P31/wdt:P139* wd:Q7397.
  OPTIONAL { ?software wdt:P571 ?date. }
  OPTIONAL { ?software p:P348/pq:P577 ?date. }
  FILTER(BOUND(?date)).
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
ORDER BY ?date
LIMIT 30
Try it!

Hebejebelus (talk) 12:55, 2 February 2019 (UTC)

Things like "t436458995" are usually unknown values. See BSch (Q11191767) for an example (snaktype: "somevalue" in the JSON). I'm not sure why it's useful to enter them. Bovlb (talk) 20:28, 2 February 2019 (UTC)
And Jan 1, 1970 is zero in epoch seconds. Sounds like someone is using it to mean unknown or unset. Bovlb (talk) 20:30, 2 February 2019 (UTC)
I have filed a bug report with Github. Bovlb (talk) 21:55, 2 February 2019 (UTC)
@Bovlb: Jan 1, 1970 is the date of the Git tags corresponding to their older releases (you can verify this in a local clone) – not GitHub’s fault. —Galaktos (talk) 11:32, 3 February 2019 (UTC)
@Galaktos: You may well be right, and I'm not saying that Github necessarily injected the problem, but the number of git events that genuinely occurred in that second in 1970 must be pretty small (even allowing for imports from older source control systems) and their UI could usefully reflect that. Bovlb (talk) 17:25, 4 February 2019 (UTC)
S/pretty small/zero/, C and the oldest SCCS go back to 1972, and using 0 as unknown is perfectly normal. If there's a problem with that it has to be solved here, there are various other suspicious timestamps, e.g., 0000-03-01 00:00:00. –84.46.53.72 10:07, 5 February 2019 (UTC)
The indendent meaning of filling a date to be 0 epoch, is likely that the value is unknown. I think it makes sense to mark the BioRuby release as having an unknown value. Maybe add deprecated values of the other values in addition to prevent a bot from readding them. ChristianKl ❪✉❫ 11:33, 3 February 2019 (UTC)

Contemporary constraint

If you add in citizenship as say, USA for someone born before 1776 you get a contemporary constraint error "The entities Jacobus Stoutenburgh and United States of America should be contemporary to be linked through country of citizenship, but the latest end value of Jacobus Stoutenburgh is 19 December 1772 Gregorian and the earliest start value of United States of America is 4 July 1776 Gregorian." Can the message be modified so that it suggests you the proper country name? This will require us to create a linkage between successor states and previous entities such as: Kingdom of Prussia > Weimar Republic > Nazi Germany > Germany. --RAN (talk) 17:55, 4 February 2019 (UTC)

I fear that it's not as simple as that, e.g., LOC claims that he was born 1696 and lived in NYC until 1724. If that means "born 1696 in NYC" Kingdom of Great Britain should be okay. For 1673 or before 1667 it could have been Kingdom of the Netherlands for NYC.
This could also depend on the citizenship of the parents, "place of birth" is only good enough for US law. Third update, even your example doesn't work for me, legally Nazi Germany is the same entity as Weimarer Republik, and after WW2 there were 4 occupied zones, then 3+1, and finally two states until 1990, with Berlin as special case (not affecting citizenship.) –84.46.53.72 11:13, 5 February 2019 (UTC)
I never liked "Contemporary constraints" since it does not reflect how we use country of citizenship (P27). country of citizenship (P27) stores both information about specific contry that existed at some place and time but also stores nationality of the people, since we decided not to store nationality in specialized property. For example if a source says that Yunus Emre (Q378902) was of "Turkish" nationality than you store that data either in country of citizenship (P27) or in ethnic group (P172). Since the source does not say anything about his ethnic group, you store info about his "Turkish" nationality as country of citizenship (P27)=Turkey (Q43) than you have "Contemporary constraints" which can not be resolved. --Jarekt (talk) 14:54, 5 February 2019 (UTC)
The property is by design not about nationality but about citizenship in a country. That has the advantage that we citizenship is a lot more objective then nationality and you don't have thousands of conflicts for Catalan or Krimean nationals. There were multiple proposals of a property for nationality but without sufficient support. The fact that some people try to put information that's outside of the intention of the property into it doesn't imply that the constraint shouldn't tell them, that they are doing it wrong. ChristianKl ❪✉❫ 21:50, 5 February 2019 (UTC)
User:ChristianKl Infoboxes like c:template:Creator need "nationality" and plenty of sources list nationality. The decision was not to never store it, but to use country of citizenship (P27) and ethnic group (P172) for it. So although that might be outside the original intention of the property, we chose to extend them to dual-purpose. But that dual purpose triggers "Contemporary constraints". --Jarekt (talk) 02:37, 6 February 2019 (UTC)
I'm not aware a decision to store nationality in country of citizenship (P27). I think storing it in ethnic group (P172) was prefered in the nationality discussions.
If we would store nationality in country of citizenship (P27) the link should go an an item about a nation and not about a country. ChristianKl ❪✉❫ 15:12, 6 February 2019 (UTC)

How to enter statement about pseudonym

I apologize for asking a basic question, but I couldn't find this in the help. How do I indicate that the writer Louis Sand (Q61550626) is possibly (uncertainly) a pseudonym of Lucy Toulmin Smith (Q15439811)? I have created a separate item for Louis Sand because the two authors might not be the same; but what is the statement I should add to Sand's page to link them? Levana Taylor (talk) 06:44, 6 February 2019 (UTC)

Phlomis tschimganica (Q15352498) and Phlomoides tschimganica (Q27690057) are same.

But I can't merge--Хомелка (talk) 11:34, 6 February 2019 (UTC)

I moved the viwiki sitelink form Phlomis tschimganica (Q15352498) to Phlomoides tschimganica (Q27690057). --Succu (talk) 12:46, 6 February 2019 (UTC)

Merge request

Could someone please merge Q56315810 with Q228268 please? I don't know how to do that. L293D (talk) 14:57, 11 February 2019 (UTC)

@L293D: For the sake of learning experience, here is how you can merge items Special:MergeItems. If you really want I can do it for you though. --SilentSpike (talk) 17:07, 11 February 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 09:10, 12 February 2019 (UTC)

Death at sea

Did we ever finalize a way to mark a death-at-sea? We were looking for a way to harmonize all the deaths at sea and which ones had the bodies recovered and which ones did not. We created death at sea (Q46998267) but did not agree on how best to utilize it, so it was never populated beyond a few demo records ... did it progress any since I left the conversation? We have a category for deaths at sea in English Wikipedia ... but how best to mark them here so we can get a comprehensive count and a comprehensive list. --RAN (talk) 23:58, 5 February 2019 (UTC)

The problem with death at sea (Q46998267) is that it's an event, not a location, so it's inconsistent to use it as a value of place of death (P20). However, at sea (Q55438959) can be used instead, so it seems to me that death at sea (Q46998267) can be deleted. It won't be possible to make a comprehensive count without also considering more specific values like North Atlantic Ocean (Q350134) which are used as a death locations, e.g., for Thomas Andrews (Q275937). Ghouston (talk) 03:27, 6 February 2019 (UTC)
As a way to harmonize, what about populating "manner of death" with death at sea (Q46998267) or at sea (Q55438959) in addition to accident?
I don't think that would be the way "manner of death" is supposed to be used. It would be like having "death on a train" or "death in Germany" as values. Ghouston (talk) 23:34, 6 February 2019 (UTC)
If the desire is just to make it easy to find all the deaths at sea, it's really no different to wanting to find all deaths in any other geographical area, like Germany. You can only do it by traversing the hierarchy of locations. That would mean ideally fitting "at sea" into the same hierarchy as "North Atlantic Ocean" or "Tasman Sea". Ghouston (talk) 23:37, 6 February 2019 (UTC)

Help with a bug stopping CC licensed data being stored on Commons

We can nearly use CC licensed datasets stored on Commons in our Wikidata queries and maps and graphs on Wikimedia projects using Wikidata data. YAAAYYY

We can't quite yet because of a bug that was started over two years ago. BOOOO

https://phabricator.wikimedia.org/T155290?fbclid=IwAR3FYWU8eTHOzf_R3_bni93Sx7wjFg4571j2WxbqiKc5-4ip-KWKMawqzSY

  • Wizards: please could you help fix the bug?
  • Muggles: please subscribe to the task to let people know its important to you

I've written some instructions to help people make maps on Wikimedia projects using Wikidata data but its not usable till this gets fixed...

Thanks

--John Cummings (talk) 10:22, 6 February 2019 (UTC)

What's also annoying - why is it limited to CC? A lot of official German map data is licensed by "Datenlizenz Deutschland Namensnennung" [2], which de fakto is the same as cc-by, but not legally. Ahoerstemeier (talk) 11:24, 6 February 2019 (UTC)
Hi @Ahoerstemeier:, the issue is there is currently no way to attribute datasets at all, I guess once it has been fixed for other licenses then it could expanded to these other special licenses (if Commons agrees), but for all licenses this bug needs to be addressed first. John Cummings (talk) 12:13, 6 February 2019 (UTC)
"We can nearly use CC licensed datasets" - can we, legally? CC-by licenses clash with Wikidata's CC-0 license and database rights are a thing. I thought import of datasets under different licenses were at least discouraged because of that. --Kam Solusar (talk) 16:38, 6 February 2019 (UTC)
Hi @Kam Solusar:, the non CC0 datasets are planned to be stored on Commons not Wikidata, so the licensing is not all CC0, like Wikidata is. This is mainly for things that don't fit in Wikidata e.g very granular data on subjects and data in files like shape files for maps. The ability to reuse data from Commons in the Wikidata query service already exists and is also used by things like Kartographer to make maps. --John Cummings (talk) 17:54, 6 February 2019 (UTC)
Ah, right. Seems I misunderstood. --Kam Solusar (talk) 22:42, 6 February 2019 (UTC)

Julian or Gregorian calendar

I have date of birth (P569) with two values (of course with references): one from Julian calendar (Q11184) and one from Gregorian calendar (Q12138).

Which date: Julian or Gregorian should have "preferred rank", to be showed primarily? Maybe none of them? I see also: "normal rank" is "valid, though possibly historic": I can carefully say, that is Julian calendar present not in widespread use - but I might be wrong. Anyway, modern encyclopedias such as Wikipedia show us two dates, with explicit distinction. But some of Wikimedia tools, f. e. Creator template in Commons, polish Wikisource Author page don't distinguish calendars and use two dates with no further informations (when I add two dates).

I hope that you will understand my questions. :-)

--Matlin (talk) 17:24, 3 February 2019 (UTC)

Property date of birth (P569) should have a single value - you can watch at the documentation on it's Property talk:P569. It must be saved in calendar that was in use that time. See here about calendars. "When a date in 2019 is entered, e.g. 2019-02-03, the calendar model is set by default to Proleptic Gregorian calendar. For current dates, this works fine. For earlier dates, the applicable calendar should be determined: - The Gregorian calendar was first introduced in 1582 replacing the Julian calendar. - The last countries to convert from the Julian to the Gregorian calendar did so in the 1920s." --Ksc~ruwiki (talk) 18:39, 3 February 2019 (UTC)
I forgot to add. If any project in Wikipedia can't show and transform dates Julian calendar (Q11184) into Gregorian calendar (Q12138) it means that template or module are used should be corrected. --Ksc~ruwiki (talk) 18:45, 3 February 2019 (UTC)
Matlin I was always confused about this too: should I combine them into a single item, since they both specify the same date just using 2 different calendars or should they be in separate statements with one being preferred. Same issue could arise if painting size or mountain height is expressed in metric or English units or even in centimeters vs. meters. We do want to stick closely to the way source phrases it, but it gets tricky if multiple sources express the same info using different systems. In case of Julian and Gregorian calendar dates I would keep them separately and elevate Gregorian as preferred, but I am not sure if we ever decided if that is the correct way. By the way, Module:Calendar (Q59263842) provides codes for converting between two calendars. --Jarekt (talk) 15:21, 5 February 2019 (UTC)
@Jarekt: When wikidata will be updated and consumed only by software, there will be nothing wrong in having more than one value even for things like birthplace, birthdate or height based on various sources. But the project is still very much in infancy period, items are frequently updated manually and infobox software (the major consumer of wikidata) is far from perfect. So it looks like we should apply some common sense here. Fyodor Dostoyevsky (Q991) died in St.Petersburg, Joseph Brodsky (Q862) was born in Leningrad, but it is the same city - Q656 and we reflect it in wikidata. If some islamic sources specify Muharram (Q1952053) 1, 1435 we do convert it to Nov 5, 2013 before importing it in wikidata (the same applies for Thai solar calendar (Q1130398)). Please note that in all examples above is only one way to transform source value to target and vice versa. Metric vs. imperial is a bit different, because although formula exists, we don't know for sure how to round values (e.g. Lake Fremont Township (Q1907666)area (P2046)36 square miles is 93239571.972096 m²? or 93 km²?). So I guess for numeric values with units jury is still out, but I'd suggest that if we have julian and gregorian dates (either specified date of both Julian and Gregorian calendar (Q27055388) or in 2 different sources) and they are the same, we should stick with julian only. --Ghuron (talk) 08:43, 7 February 2019 (UTC)
@Ghuron:, I was just looking at Fyodor Dostoyevsky (Q991) and Anton Chekhov (Q5685) both have julian and gregorian dates of birth and death one with julian as preferred rank and the other gregorian. So it seems like we usually have both dates but one has higher rank. We should add something about it in Help:Dates. --Jarekt (talk) 14:10, 7 February 2019 (UTC)
  • 1) I have noticed the problem in Commons. I don't know it's reason but different templates work both correctly with dates on both calendars (on page Creator everything is right, including the Polish language) and correctly and wrong at the same time on page category. I wrote to the administrator of Commons and hope he fix it. 2) The problem in Polish Wikisource I suppose either in template Autorinfo or in module Wikibase because template Autor takes data from Wikidata using them. --Ksc~ruwiki (talk) 21:18, 5 February 2019 (UTC)
Ksc~ruwiki I looked at c:Creator:Anton_Chekhov, which is correct, in c:Category:Anton_Pavlovich_Chekhov the c:template:Wikidata Infobox does not indicate calendar used which is an issue. s:pl:Autor:Anton Czechow uses manually filled dates and is also missing calendar indication, but hat has to be fixed at that page. --Jarekt (talk) 14:32, 7 February 2019 (UTC)

Wrong display/conversion of coordinates

In case of the Sohag stadium, two coordinates are given:

  1. 26.5578°, 31.7092°, GeoHack DMS = 26° 33′ 28.08″ N, 31° 42′ 33.12″ E, Wikidata display: 26°36'N, 31°42'E
  2. 26.557754°, 31.709276°, GeoHack DMS = 26° 33′ 27.91″ N, 31° 42′ 33.4″ E, Wikidata display: 26°33'27.914"N, 31°42'33.394"E

Both coordinates differ only by a few meters. The coordinates shown at GeoHack differ only slightly but the latitude coordinates shown at Wikidata differ by 3 minutes! This should not happen. I assume that there is a conversion failure at Wikidata. --RolandUnger (talk) 15:30, 7 February 2019 (UTC)

When entering a coordinate on Wikidata, you have to specify a precision. For the first coordinate, the precision is set to 0.1°. When doing the conversion from decimal numbers to DMS, Wikidata takes the precision into account while GeoHack doesn't. --Pasleim (talk) 17:54, 7 February 2019 (UTC)

Hippolyte Peragallo (Q21390773) and Hippolyte Peragallo (Q21522800)

Aren't those the same?  – The preceding unsigned comment was added by 185.8.50.21 (talk • contribs) at 02:37, 14 January 2019 (UTC).

names and occupations are different.  – The preceding unsigned comment was added by 151.49.74.230 (talk • contribs) at 20:45, 30 January 2019 (UTC).
Who unsigned here?! --Liuxinyu970226 (talk) 11:29, 31 January 2019 (UTC)

They're most probably the same person. Hypollyte is a typo, the botanist (Q21522800) was also named Hippolyte according to the BNF. —capmo (talk) 03:26, 5 February 2019 (UTC)

The two items are now merged into Hippolyte Peragallo (Q21390773). –Tommy Kronkvist (talk), 12:56, 8 February 2019 (UTC).

Sport events editions and P3450

I was involved in a dispute with folks maintaining items about cycling.

A user from my wiki complained that DeltaBot is moving follows (P155) and followed by (P156) to qualifiers of sports season of league or competition (P3450) on items about sport events. This is supported by constraints on P3450 and a discussion about P155 and P156. I fixed the infobox where the data was missing and started fixing this inconsistency on Wikidata by moving P31/P279 to P3450 (around 12k new statements). However, the members of WikiProject Cycling are disappointed about this (because of their templates). And it seems there wasn't really strong concensus on creating and using P3450.

Previous discussions:

In my opinion, having a specific property is better than using P31 for everything. Similarly, there is P31: human (Q5) and then specific properties like sex or gender (P21), occupation (P106) etc.

@Xaris333, Pasleim, Jura1, TomT0m: What classification system should be adopted? Is it correct to migrate P31 to P3450 and use P31: sports season (Q27020041) or similar? Or should P3450 be deleted? Matěj Suchánek (talk) 10:32, 2 February 2019 (UTC)

  • There is a distinction being made between individual instances of a sports competition which takes place annualy or every some years on the one hand side (like a tournament, or a week-long event and so on), and sports seasons which consist of a series of related events typically over a year or so on the other hand. Individual instances use instance of (P31) only with a value that repesents a class item of the event, seasons use instance of (P31): sports season (Q27020041) (or a similar item) + sports season of league or competition (P3450). The instance of (P31) only approach does not really work for sports seasons, as it would have to use values which are rather of league type.
  • The cycling project people were early adopters of data use in Wikipedias via modules. When they started their modelling, many of the properties we have nowadays were not available, and by far not all statements have been refined to today's standards due to the use. When data is in use like in this case, I think all improvements should be discussed first, adopted in the code, and then improved.
—MisterSynergy (talk) 11:23, 2 February 2019 (UTC)
It’s true that there is in common language a metonymy between the periodic competition and the organization that organises it. But there is a very more generic way to handle the link, for example « organized by ». It’s definitely possible to create say « Ligue 1 season » for the professional soccer top ligue in France, to have an item « Ligue 1 » for the group of teams in that ligue, and to link « 
⟨ Ligue 1 season ⟩ organized by Search ⟨ Ligue 1 ⟩
 » (with
⟨ Ligue 1 ⟩ sport (P641)   ⟨ football ⟩
-
⟨ Ligue 1 ⟩ instance of (P31)   ⟨ football ligue ⟩
… ) and statements about the season-class item :
⟨ Ligue 1 season ⟩ subclass of (P279)   ⟨ sport (or football) season ⟩
. author  TomT0m / talk page 12:11, 2 February 2019 (UTC)
I’m kind of tired of these disputes, so I’ll back of and tell you to do whatever you like.
Anyway for a real answer, to dig a little more into the details : What is the real value added by the constraints ? If it’s a constraint to say that any items with « P31: sports season (Q27020041) » should have a « P3450 » it’s not of much use, and « P31 : [the value P3450 could have] » is more parsimonious, spares a constraint to check.
Now the only problem with this in my opinion is that Wikidata constraint system is property based, and that the type of an entity in such a system is supposed to be hinted by the presence or absence of some property, I guess a reason for this is to avoid the risk of a huge class tree with over specific classes (« intersected », like in commons), because of the potential combinatorial explosion. I think such classes could be very useful in some situations - for example in film classification there is often some mix between the thematic and form classifications of movies, and the instance of (P31) system is definitely flexible enough to handle those kind of cases by creating a class not bothering if we should put the information on « genre » or in « work main topic ». A few hygienic rules and common sense should be enough to maintain
In another direction, another problem that was totally foreseeable is the problem of the stability of the model, and the way we transmit the changes to the consumers. But the Wikidata community may not be structured enough to handle correctly something like the « stable interfaces policy » for the model. We change the constraints based on local discussions on a regular basis without consulting and telling anyone else . That’s why flexibility should be something we value on Wikidata, solutions that works in a lot of situations, and in that regard the property creation process is really not flexible in my opinion. Creating a lot of properties when a more generic could do the work introduce some kind of rigidity, if you want to do the same in another very close domain you have to start over, write new code to consume the datas while you could maybe just reuse the same infobox in the clients. With all the trouble that comes with maintaining some code if some subdomain of sport suddenly decide to handle the seasons in a totally different way than the other sports … while he could do the same as the others with no change in the code needed by the clients. That’s why I’m definitely not convinced with arguments such as having a specific property is better than using P31 for everything . It should be thought the other way around : why should we not use P31 in this case, while it can definitely be seen as a sport seasons classification problem, and classification is something very very common in Wikidata. If we could maintain some kind of consistency in the way we classify stuffs, it could be beneficial for a lot of things. author  TomT0m / talk page 11:59, 2 February 2019 (UTC)

, and not

Xaris333 (talk) 14:38, 2 February 2019 (UTC)

season of club or team (P5138) was a good idea. The main problem comes from the fact the changes occur but in the same time the code must be adapted. Cycling race is potentially active in around 20 Wikipedias, it is not nothing. Other similars problems occurred by the past when beginning (Q529711) and end (Q12769393) changed due to merges. I remember have spend time to correct program and update the local copies on Wikipedias. It suppose also changes in the documentations. So the problem is a bot pass but there is no contact or discussions before. I also think sports season of league or competition (P3450) has not the best translations in French, maybe. I also add that races had a class, that can change with editions. I remember having proposed the the creations of properties by the past (years ago) but generally the response was take this property and do that. Now, we have property, but there is a very big work to do to integrate them with the existant algorithm. Jérémy-Günther-Heinz Jähnick (talk) 17:11, 2 February 2019 (UTC) PS : I also remember the very long time to obtain the creation of properties for classifications, and now we use them to display tables in Wikipedias. So sometimes all is not perfect in the Wikidata World. Personnally, I am not opposed by principle at some modifications, just all must be planned before. Example we display cards with locator map image (P242) where route map (P15) should be the best option. But if a day a bot come to make the change, the code should be first adapted, idem for documentations. Jérémy-Günther-Heinz Jähnick (talk) 17:15, 2 February 2019 (UTC)
First, thanks to Matěj Suchánek, who proved to be open-minded and to act for the community transparently. I can only repeat what MisterSynergy and Jérémy already wrote: we use already all those properties to display information in wikipedia, therefore, a bit of caution is requested before modifying everything. Actually in cycling project, it is more the module that define the property to use than any logical reason. Most important thing is that all users use the same structure. In addition, as I already wrote there is a problem of definition: a season is not an edition. Nevertheless, assuming "sports season of league or competition" is renamed in "edition of" then we could also implement structure like introduced from Matěj Suchánek. It just has to be clarified first. Still, I would advocate for a "revert" now, waiting for a consens to be found. Psemdel (talk) 11:27, 3 February 2019 (UTC)
Actually in cycling project, it is more the module that define the property to use than any logical reason. — Well, I think we should fix this approach. We did already move the module from length (P2043) to event distance (P3157) with prior discussion, and I have some more ideas what to improve. Maybe I show up on the module talk page soon again :-) —MisterSynergy (talk) 21:29, 3 February 2019 (UTC)
We have to start somewhere. It is not forbiden to improve afterwards. The introduction of event distance (P3157) was a good idea. We are also starting using cycling team season (Q53534649). So it is not frozen. The module makes a standardization essential otherwise no display. Psemdel (talk) 22:42, 4 February 2019 (UTC)
  • A problem with the field (sports other than cycling) is that we have plenty of items created mainly due to pages existing in one or the other Wikipedia. Even in tenniS, a field that has a fair number of active contributors, the numbers were in the tens of thousands. While we could simply ignore the surplus items when trying to build a reasonable structure at Wikidata, practically these need to be included in one way or the other. The properties mentioned above helped sorting this out (even though what one considers a season may vary). I think MisterSynergy brought quite a lot of improvements. Personally, I find the question about the use of P155/P156 fairly secondary, but I think it actually worked out well with the deltabot changes. --- Jura 13:35, 3 February 2019 (UTC)
Just to be sure, I looked in the Collins. Season : "You can use season to refer to a fixed period during each year when a particular sport is played." Edition : "countable noun, An edition is a particular version of a book, magazine, or newspaper that is printed at one time." It is not perfect for sport, but it is also used as in French for cycling event. So season = period, edition = number. Paris-Roubaix 2018 is not a period of Paris-Roubaix. There is already a property edition number edition number (P393). We could create a property "edition of" which would do the same as sports season of league or competition (P3450). At least it would make some sense. I just wonder, what I will then put in instance of (P31) and what is the advantage compared to present solution... Psemdel (talk) 21:22, 3 February 2019 (UTC)
  • One more stuff : this seems to be an instance of a generic problem : the WikiProject Recurring events, so I’d like if we could summarize the thoughts in that central place :) . In that case, I don’t really think it’s always necessary for follows (P155) and followed by (P156) to be qualifier/qualified by to indicate the series of events in which it is true : if it’s an instance of a recurring event, the « default » series is known by the class. For example, if it’s an instance of « Summer Olympic games », it’s naturally this sequence that « followed by » and « preceded by » (as unqualified main statements). The problem arise if we want to indicate that the « Summer Olympics 1994 » were preceded by the « Winter Olympics 1996 ». Note that this problem is very similar to the sport seasons one, except it cannot be solved by « sport season of ». author  TomT0m / talk page 09:48, 6 February 2019 (UTC)
There is a strong relation between the fact of entering datas and the module : if we work on our side it is to enter datas that will be displayed in articles. It is crucial to always maintain the display. Jérémy-Günther-Heinz Jähnick (talk) 12:43, 8 February 2019 (UTC)

Institutions headquartered in historic buildings

I've come across a couple of situations in which an institution is located in a historic building, and the related wikidata item mixes properties related to the institution with those related to the building. This is bad, in my opinion: we have two very different concepts mixed in a single item. The building can have sometimes a long history of its own and be many centuries older than the institution, and that information can't be added to the item. Some time ago I started a RfC on this topic, and was informed that here would be a better place to discuss it. So, comments are welcome! Here are two examples:

  • Villa I Tatti (Q3558578) vs The Harvard University Center for Italian Renaissance Studies (Q45134760) (once separated, now merged)
  • Château Perrier (Q22979594) vs Le Musée Régional d'Archéologie et du Vin de Champagne (Q28003614) (a merger was proposed last year but not done)

Pinging @Pintoch, Sp!ros, Sabas88, Gérald Garitan, Cycn, Giaccai: who took part in the discussions (RfC and merger). —capmo (talk) 02:55, 6 February 2019 (UTC)

  • I think the difficulty in those cases is that a thing like a museum, hotel, school, hospital etc., is seen as a building first and an organization as an afterthought. The reality is probably the other way around; institutions can occupy multiple buildings, or parts of buildings, which can change over time. Also, institutions have additional things, like staff. I split Old War Office Building (Q58454576) from War Office (Q2060703) and nobody complained. After all, the War Office disappeared through merger in 1964, but the building is still there. Ghouston (talk) 03:47, 6 February 2019 (UTC)
We have in Italy many similar situations; I live in Florence and know very well Villa i Tatti; I think that example offers the occasion to sustain not only the opportunity to create 2 different item, one for the Villa and one for the Harward University Center, but also one more item for Berenson library and one for [Art collection which are inside of the Villa. --Susanna Giaccai (talk) 08:10, 6 February 2019 (UTC)
Considering still Florence, the Uffizi Gallery is the building, but the Uffizi institution runs also Palazzo Pitti and the Boboli Gardens. In Genoa, Italy I can suggest museum of the world cultures (Q3868144) which is housed in Albertis Castle (Q3662403) --Sabas88 (talk) 10:24, 6 February 2019 (UTC)
Definitely two different items, as these are two different concepts. Although these are mostly covered in one wiki article, we are more precise and more granular. We have main building of National Museum in Prague (Q43755714) and main building of National Museum in Prague (Q43755714) or Faculty of Arts, Charles University in Prague (Q3563550) and main building of the Faculty of Arts of Charles University (Q26878498), both were mingled in one item, but divided later, also in both cases, the building was built for the institution.--Jklamo (talk) 12:49, 6 February 2019 (UTC)
  • It's better practice to have separate items but at the same time, I don't see a problem when someone who creates a new item about an organisation keeps it simple and stores information in one item. If later someone thinks more graniuality is appropriate, they can increase it. ChristianKl ❪✉❫ 15:16, 6 February 2019 (UTC)
  • Thanks for bringing that here @Capmo:. I was thinking a lot again of this in the last few days and I think it would be better to have two different records. I understand the reasons why having two different entries (one for each entity) makes more sense. But I see that in many other cases there are lots of errors when adding identifiers to that records. Look for instance the Louvre Museum (Q19675) and Louvre Palace (Q1075988). The VIAF records that are linked to these look quite inconsistent. Is there any way to resolve that?--Sp!ros (talk) 07:29, 7 February 2019 (UTC)
  • Yes, best to split it into two items. Unfortunately, that usually leaves the problem of how to divide the sitelinks between them, as Wikipedia articles are not always confined to a single concept. And then, after such a division, Wikipedia readers will see an incomplete list of languages.
I have encountered a similar problem with people who are primarily notable for the manner of their death. Some Wikipedias write a biography of the person that includes information about their death; others write articles about the death event and then might add a biography of the person much later (e.g. en:Trayvon Martin. In Wikidata, we tend to get a single item that conflates details of the person and the event. Bovlb (talk) 19:28, 7 February 2019 (UTC)
Wikipedia article covering multiple topics (Q21484471) could be used, although that requires creating yet another item on Wikidata. Ghouston (talk) 23:16, 7 February 2019 (UTC)
Another solution in these cases is to use old-style interwiki.--Jklamo (talk) 17:31, 8 February 2019 (UTC)

Wikidata ... rating for "science awards"

Does wikidata rate "science awards"? According to @GerardM:, yes - https://ultimategerardm.blogspot.com/2019/02/wikidata-naomi-ellemers-and-relevance.html

Could we get some more details on that, please? Where? What? --Tagishsimon (talk) 16:43, 7 February 2019 (UTC)

@Tagishsimon: Hrm... Perhaps they mean review score (P444), see e.g. Q28835#P444... -- Luitzen (talk) 17:28, 7 February 2019 (UTC)\
According to Professor Naomi Ellemers, awards and the attention to awards lead to a bias that favours American scholars and studies. This is true for European scholars and studies, this bias is even stronger for African studies. (This bias is alive and well in our data in Wikidata anyway). As far as I am concerned, these "ratings" are not what we need to incude (technically the way these ratings are registered is problematic as well). When we want these ratings to be known, we could link to their websites .. Personally I think it is a bad idea to strenghten an unjustified bias. Thanks, GerardM (talk) 17:40, 7 February 2019 (UTC)
Thanks both. Interesting questions raised. --Tagishsimon (talk) 19:12, 7 February 2019 (UTC)

Family tree from Wikidata

For people who doesn't want to use ahnentafel templates family to draw family trees (including ancesors and descendats) there is a Lua-based template to draw family tree. Original source: ruwiki (1, 2, check links for examples). Quick example: 

{{Wikidata/FamilyTree|entityId=Q7200|title={{Q|Q7200}}|ancestors=3|descendants=1|compact=true|invert=1|decorate=by-generation}}

(note, that on local wiki most titles would be red or blue links and on Wikidata all titles are just black plain text due to title.exists() behaviour on Wikidata ) -- VlSergey (трёп) 14:25, 5 February 2019 (UTC)

Excellent! --RAN (talk) 16:41, 5 February 2019 (UTC)
That is very good. --Jarekt (talk) 16:58, 5 February 2019 (UTC)
Are there plans to use it anywhere? English Wikipedia will not allow back links to Wikidata. I got banned just for arguing for them and creating a demo page with a list of mayors. --RAN (talk) 00:01, 6 February 2019 (UTC)
It is widely used in ruwiki and ukwiki already. For example it is used as drop-in replacement for manual ascendants trees created with ahnentafel-top / ahnentafel-compact5 / ahnentafel-bottom templates family: [3], [4], [5] -- Vlsergey (talk) 08:23, 6 February 2019 (UTC)
Thanks, very nice. I was trying to create something like that on cswiki, but never finished it.--Jklamo (talk) 10:05, 6 February 2019 (UTC)
ChristianKl (talk) 15:11, 24 June 2017 (UTC) Melderick (talk) 12:22, 25 July 2017 (UTC) Richard Arthur Norton Jklamo (talk) 20:21, 14 October 2017 (UTC) Sam Wilson Gap9551 (talk) 18:41, 5 November 2017 (UTC) Jrm03063 (talk) 15:46, 22 May 2018 (UTC) Salgo60 (talk) 18:10, 18 June 2018 (UTC) Egbe Eugene (talk) Eugene233 (talk) 03:40, 19 June 2018 (UTC) Dcflyer (talk) 07:45, 9 September 2018 (UTC) Gamaliel (talk) 13:01, 12 July 2019 (UTC) Pablo Busatto (talk) 11:51, 24 August 2019 (UTC) Theklan (talk) 19:25, 20 December 2019 (UTC) SM5POR (talk) 20:17, 29 May 2020 (UTC) Pmt (talk) 23:22, 27 June 2020 (UTC) CarlJohanSveningsson (talk) 12:13, 30 July 2020 (UTC) Ayack (talk) 14:39, 12 October 2020 (UTC) EthanRobertLee (talk) 19:17, 20 December 2020 (UTC) -- Darwin Ahoy! 18:20, 25 December 2020 (UTC) Germartin1 (talk) 03:13, 30 December 2020 (UTC) Skim (talk) 00:13, 10 January 2021 (UTC) El Dubs (talk) 21:55, 29 April 2021 (UTC) CAFLibrarian (talk) 16:36, 30 September 2021 (UTC) Jheald (talk) 18:50, 23 December 2021 (UTC)

  Notified participants of WikiProject Genealogy --Jklamo (talk) 13:28, 6 February 2019 (UTC)

Great. I'll probably use it on Commons for tombstones. Eg. c:Category:Grave of Lafargue (Père-Lachaise, division 76). Pyb (talk) 04:22, 7 February 2019 (UTC)
I know we have a ban on displaying synthesized data like age-at-death, but anyone considering displaying this in the Wikidata entry? --RAN (talk) 22:58, 8 February 2019 (UTC)

Relationship between Wikidata, VIAF, Getty (ULAN, CONA, etc)

I am part of a university library project (at University of Texas at Austin) tasked with developing local authority data about architects and their built work. We would like to contribute this data to the linked data community. We are currently talking with Getty Vocabularies about contributing to their ULAN and CONA programs, but we are also curious about contributing to VIAF and Wikidata. My questions: what is the relationship between Wikidata, VIAF, and Getty? Does Wikidata pull updates directly from Getty, or does Wikidata pull updates from VIAF which in turn pulls from Getty? Which bots are involved and how often do they run?--Dzahsh (talk) 19:19, 6 February 2019 (UTC)

en:Virtual International Authority File aggregates the data from its contributors, which includes Wikidata. So if you can get your data into Wikidata, or any other source that contributes to VIAF, it should show up there eventually. I think transfer of data from VIAF to Wikidata takes place on an adhoc manner rather than systematically. I don't know anything about Getty. Ghouston (talk) 03:35, 7 February 2019 (UTC)
I'm not sure if the Wikidata connection with VIAF goes so far as to create new items on VIAF when they are only found on Wikidata. I've only noticed it occurring when an existing VIAF ID has been added to a Wikidata item. Ghouston (talk) 03:38, 7 February 2019 (UTC)
When Wikidata has an item with no links, it may find its way into VIAF even when we do not know the VIAF or any other library identifier. I have found such things several times. Thanks, GerardM (talk) 06:28, 7 February 2019 (UTC)
Yes, I've noticed that happening. But I've never seen a VIAF item which has only a Wikidata connection. No VIAF item has been created for Vivianne C. Smith (Q56700731), for example. Ghouston (talk) 11:23, 7 February 2019 (UTC)
VIAF once stated that it required 2 sources. But I have seen entities that have only one. That doesn't mean that it didn't have two at one point in time, it only means that today there is only one source. Also, they state that sometimes they reject sources if they have multiple identities on them, meaning:
Someone uses one name to write songs and one name write novels. If ISNI has a number for each, and then Wikidata includes both numbers on one, VIAF will reject the Wikidata entry. Lazypub (talk) 21:56, 8 February 2019 (UTC)
I reviewed my email history with VIAF. Their exact words were With Wikidata we harvest that metadata ourselves to see if there are any entries that match the names we have in the VIAF database. If we do have a match then we add it to the database. If a name doesn’t already exist in our database then we do not add it from Wikidata. Basically, VIAF needs to already have your name before it considers using Wikidata for your name.Lazypub (talk)
@Dzahsh: Hello and welcome!
“what is the relationship between Wikidata, VIAF, and Getty?”
Wikidata links to all Getty vocabularies with the properties Getty Thesaurus of Geographic Names ID (P1667), Art & Architecture Thesaurus ID (P1014), Union List of Artist Names ID (P245), Cultural Objects Names Authority ID (P1669) and Getty Iconography Authority ID (P5986) respectively and pulls more or less data from all of them, especially from ULAN and irregularly reports errors to Getty (see esp. here; more cooperation is planned); Wikidata links to VIAF with VIAF ID (P214) and partly pulls some data from VIAF; VIAF links to ULAN and Wikidata.
“Does Wikidata pull updates directly from Getty, or does Wikidata pull updates from VIAF which in turn pulls from Getty?”
Wikidata unsystematically pulls data from Getty, currently ~32k statements are referenced with ULAN; most of them (dates of birth and death) came over some way via Mix'n'match, I am working on channeling the pulling from the Getty vocabularies, the work in progress is (perhaps a bit cryptically) documented at Wikidata:WikiProject Visual arts/Getty Vocabularies.
“Which bots are involved and how often do they run?”
The biggest import of dates of birth and death is performed by User:Reinheitsgebot, but already imported dates don't get updated from ULAN at the moment (but I don't notice much change in existing ULAN records anyway, unlike e.g. at RKDartists). User:BotMultichillT imports labels from ULAN continuously.
Compared with ULAN, Wikidata will have some easier and harder parts for you I guess:
  • Documentation here is not in some single document as easy findable as for the Getty vocabularies.
  • for persons: ULAN is probably more comprehensive for architects than Wikidata. The Getty vocabularies are probably better documented and more clearly structured.
  • for buildings: in Wikidata there is already a start, CONA probably won't have many buildings yet.
  • Availability for all kinds of tools at Wikidata is probably better.
  • Data quality for persons I'd say is better at Wikidata, especially for dates of birth and death, for relationships between persons on the other hand ULAN is probably still more comprehensive.
I hope this helps. Feel free to ask here or at my user talk page if you have any further questions! I'll be glad to provide any help I can with getting along here, modeling, importing data or whatever. Best, --Marsupium (talk) 01:44, 9 February 2019 (UTC)

Quadruplication?

The last two seem to share the VIAF ID (P214), could be the same person --Magnus Manske (talk) 09:05, 7 February 2019 (UTC)

Thanks for spotting this! The first three are the same person – I've merged them. The fourth is another person, I've removed the VIAF ID from Giorgio Duranti (Q5563473) since there it seemed to be a slip, most of the ACs linked from VIAF belong to Francesco Durante (Q314221). Best, --Marsupium (talk) 23:41, 8 February 2019 (UTC)

Delete P973 statements

I added statements for Swiss Films ID (P6474) from described at URL (P973): 

SELECT ?item ?value ?swiss WHERE {
  ?item wdt:P31/wdt:P279* wd:Q11424 .
  ?item wdt:P973 ?value .
  FILTER(REGEX(STR(?value), "swiss")) .
  OPTIONAL { ?item wdt:P6474 ?swiss }
} ORDER BY ?value
Try it!

Can somebody delete the P973 statements automatically, just them for Swiss Films, not eventually existing others? Queryzo (talk) 17:26, 8 February 2019 (UTC)

@Queryzo: Will be done in 15 minutes. Done. -- Luitzen (talk) 20:00, 8 February 2019 (UTC)

  Done Queryzo (talk) 22:38, 8 February 2019 (UTC)

Google Knowledge Graph

Can someone look at Friedlieb Ferdinand Runge (Q77535) and see if Google Knowledge Graph is doing what it is supposed to? --RAN (talk) 20:23, 8 February 2019 (UTC)

I added a missing slash in the two values. Internet Archive is giving an error, but it may be doing that for all freebase.com URLs. Ghouston (talk) 21:39, 8 February 2019 (UTC)
I have added many knowledge graphs. It usually takes me a few tries to get it right. But here is the real reason for commenting - some knowledge graphs change over time. The address you add today (and verify that it works) may not be there tomorrow even though a knowledge graph for the entity still exists. Lazypub (talk) 21:46, 8 February 2019 (UTC)
Is this a temporary error or a long term error? Any thoughts? --RAN (talk) 22:56, 8 February 2019 (UTC)

main subject

Are there appropriate items which could be used as main subject (P921) for Article 1 of the European Convention on Human Rights (Q2865737) and Article 18 of the European Convention on Human Rights (Q4800872)? I've added values for the other sixteen, although only some of the values are "right to x", and none of them are "prohibition of x" (as opposed to simply "x"). Jc86035 (talk) 17:03, 2 February 2019 (UTC)

That's tricky, I added German to articles 1, 18, and 2 without getting an inspiration for the main subject of 1+18. And in 3 that experiment failed, you had main subject torture, I ended up with The prohibition of torture, cruel, inhuman and degrading treatment or punishment in international law. My idea would be to have (en) main subject roughly like (en) description based on the actual (en) convention, or on whatever is quoted in enwiki. Ditto for other languages, I only checked frwiki + dewiki for 1+2+3+18. –84.46.53.72 10:47, 5 February 2019 (UTC)
Discussion about the descriptions (not the main topic / subject statements) of articles 1+2+3 started on Talk:Q2865737, Talk:Q2061452, Talk:Q2865584. –84.46.53.198 11:11, 6 February 2019 (UTC)
As noted on one of the talk pages, my issue was that the descriptions couldn't be interpreted without the context provided by the labels. Jc86035 (talk) 16:14, 9 February 2019 (UTC)

Constraint for duplicate statements

Hello. Is there a constraint for statement that is dublicate? For, example, if I have hundrends of statements with participant in (P1344) in an item, is there a constraint that showed that the statement was added (by mistake) two times? (Of course, this constraint can apply only to some properties). Xaris333 (talk) 11:43, 9 February 2019 (UTC)

There is no constraint for such a task. You can however use the query service and have a look at this query result which lists all value duplication cases for P1344. —MisterSynergy (talk) 13:20, 9 February 2019 (UTC)
So, we are telling that we don't need sush a constraint? Xaris333 (talk) 14:44, 9 February 2019 (UTC)
It is not up to me to define what we need or not; it was just a statement that a duplication constraint is not available until now. There are some bots (e.g. User:KrBot) which remove duplicated values under certain circumstances without a formal constraint. —MisterSynergy (talk) 14:53, 9 February 2019 (UTC)
Ok, thanks. I just asked your opinion. Xaris333 (talk) 15:07, 9 February 2019 (UTC)
I also remember PLbot removed such duplicate statements once. Queryzo (talk) 16:55, 9 February 2019 (UTC)

Suitability of property "Boobpedia article"

Boobpedia: Big Tits is as its website advertizes: "Boobpedia is a user-editable encyclopedia of women with big tits. Look up your favourite busty nude models and porn stars, or discover new favourites." Here in Wikidata on December 19 the property P6270 (P6270) was created "to enhance our coverage of pornographic actor (Q488111)".

That site does not require that articles be only about women in those categories and their 30,000+ articles are limited only by their editors' interest. For any somewhat "busty" woman in the entertainment industry Wikidata is now able to provide an identifier ungraciously named "Boobpedia article" providing a link to user-generated material headed by the spiciest picture the Boobpedia editors have been able to locate. In December the item for the wife of the president of the United States received this treatment, along with 3563 other women. Only 1329 of them have pornographic actor as their occupation. The rest are women in many areas of the entertainment industry: Jennifer Aniston (Q32522), Rosanna Arquette, Samantha Cole (Q7408640), Joan Collins (Q152843), Melissa Etheridge (Q270669), Jayne Mansfield (Q229507), Molly Ringwald, Winona Ryder (Q101797), and Princess Beatrice of York (Q165657). While the site is adult only and requires one to certify age over 18 to enter, this is conveniently bypassed if you click on the links Wikidata provides.

I am planning to nominate the property for deletion but would be interested in comments here first. StarryGrandma (talk) 07:20, 28 January 2019 (UTC)

I agree, that the value that the link provides isn't worth the potential alienation of convervatively minded people and women who find sexualized material offputting. ChristianKl ❪✉❫ 09:28, 28 January 2019 (UTC)
How about a mandatory constraint that it can only be added to people with certain occupations? E.g., pornographic actor (Q488111). Ghouston (talk) 10:43, 28 January 2019 (UTC)
+1 to a mandatory constraint for certain occupations. It is not the role of Wikidata to prevent alienation of people or to judge the world, but to reflect what there is in it.--Micru (talk) 23:24, 30 January 2019 (UTC)
+1, get rid of the property: While the Boobpedia link on Q3621587 makes more sense for me than the enwiki AfD, it's a can of worms, what next, a WikiFeet "ID" Yurizan_Beltrán, a hostile take over of LMGTFY? –84.46.53.126 08:10, 30 January 2019 (UTC)
If you want to propose it, go ahead. I am not very familiar with the field, but other editors might find it interesting.--Micru (talk) 23:29, 30 January 2019 (UTC)
I don't think Boobpedia should be used to prove notability. But I find it no worse of a site than many of the others we have available. Lazypub (talk) 23:42, 30 January 2019 (UTC)
Absolutely. Boobpedia's notability standards are (ahem) solely based on bust size. Th. Hon. 15:27, 2 February 2019 (UTC)
I also don't think this site should be used to prove notability, in much the same way that a long list of user-generated social media identifiers does not automatically make someone notable, but I wonder whether any action to suppress use of this property on our end will border on something contradicting WP:NOTCENSORED (bearing in mind that we lack a content disclaimer and any substance similar to WP:NOTCENSORED on Wikidata:What Wikidata is not). @Robin van der Vliet, The Honorable, Gerwoman: as the property's proposer, an admin of the site who is also on Wikidata, and the only oppose vote on the property proposal. Mahir256 (talk) 23:57, 30 January 2019 (UTC)
@Thierry Caro: If we want to successfully censor Wikidata we should also delete all those NSFW properties, all items about adult actors and adult movies. I am opposed against the idea of censoring Wikidata of NSFW content. Robin van der Vliet (talk) (contribs) 00:39, 31 January 2019 (UTC)
This identifier is not problematic because it is related to pornographic/erotic content, but because it is mainly used on persons that are not in the pornographic/erotic field. While assumptions about the breasts of women in the pornographic/erotic field could be considered as part of their professional biography it tends to be rather degrading towards women who don't center their career on erotic performance. To restrict the use of the identifier to people with certain occupations may be an option that prevents the impression of censorship in certain fields. Btw: there were two people opposing the creation of this property: Gerwoman and The Honorable. - Valentina.Anitnelav (talk) 09:18, 31 January 2019 (UTC)
@Robin van der Vliet: It seems that you engage in making a slippery slope argument. Nobody here calls for general censorship of NSFW content. In addition, Wikipedia policy doesn't apply directly to Wikidata. Decisions about which properties to create are curative decisions and we have no rule accordin to which every UGC website with 30,000 entries deserves it's own property (and should get that against the opposition of admins of the website; especially in a way that bypasses their consent polices on underage visitors). ChristianKl ❪✉❫ 10:53, 31 January 2019 (UTC)
This is not about censorship or sexuality. This is about respect for the women whose data we collect and the women editors (few as they are) who contribute here. A site that treats women's body parts as objects to be collected should not be available as a named link. Given the wide-ranging nature of that site (any woman in public view who is ample enough), having such an ID is far too open to abuse, even if efforts are made to limit it to professionals.
As far as sexuality is concerned Wikidata already provides links to the major professionally managed sites covering pornography and erotic models: Adult Film Database actor ID (P3351), IAFD female performer ID (P3869), Pornhub star ID (P5246), RedTube ID (P5540), YouPorn performer ID (P5267). Their coverage is far more explicit than Boobpedia's and provides plenty of flesh in still pictures and in action. They may also provide height, weight, and measurements. What they do not provide is information about their subjects as people. Boobpedia, on the other hand, is not a pornography site in the same way. It is lovingly devoted to ample women with articles as well as images. Some of the material is from Wikipedia (acknowledged in large print at the bottom) and other material is editor provided. @Robin van der Vliet: proposed the ID in good faith because the site provides so much information. As far as I can tell Boobpedia is the only such site that cares enough about its subjects as people to do so. I suggest that the ID be converted to a reference URL (P854) for the occupations erotic photography model (Q3286043) and pornographic actor (Q488111).
Wikidata is a major database, not a hobby site, and we need to mindful of the dignity of both our subjects and the women editors we are trying to attract. An ID link to a site labeled "Boobpedia" has no place here. StarryGrandma (talk) 16:51, 31 January 2019 (UTC)
I'm not sure we have data about the fact that such a name is detrimental to our recruiting effort (and I'm not sure either that this recruiting effort should have an impact on our content, by the way). Maybe it does attract more female contributors. Who knows? The world's complicated (and that is why we sometimes need strange properties to cover certain aspects of what happens down here). Thierry Caro (talk) 17:26, 31 January 2019 (UTC)
IIRC Pornhub + RedTube + YouPorn belong to one network of related sites, and Pornhub star ID (P5246) should be good enough for methis zoo. After checking Boobpedia for a few other celebs:
At the moment this site appears to be strict about their topic, no slim models (ignoring red links), and up to date with references for what they cover, better than what I'd expect from, say, RedTube or YouPorn. And if they cover any kind of current or former celebrity, then limiting their efforts to "erotic" here is suspicious, cf. NOTCENSORED already mentioned above. OTOH, what does WikiData offer for male celebs, sport / wrestler / actor / model / whatever? Nothing would be also suspicious, or rather, unfair. –84.46.53.94 12:00, 1 February 2019 (UTC)

I'm an administrator at the site. When the property was originally proposed I expressed misgivings about it. Besides the possible BLP issues of a wiki about (mostly) living people, I wouldn't characterize our information quality as being worthy of Wikidata. It's a hobbyist site edited by fetishists who may not be concerned with accuracy. Having a property for something named "Boobpedia," frankly, does not help Wikidata's credibility. @StarryGrandma: I would support any deletion request. Th. Hon. 15:20, 2 February 2019 (UTC)

I would support as well the proposal of @StarryGrandma:. --Gerwoman (talk) 17:27, 8 February 2019 (UTC)

A request can be submitted at Wikidata:Properties for deletion. Ghouston (talk) 00:46, 10 February 2019 (UTC)

Manual language add to a item

How can I manually add a language to a item, for example Japanese to Q25209781? --151.49.66.30 14:01, 8 February 2019 (UTC)

Register an account and add that language to the babel box. ChristianKl ❪✉❫ 15:55, 8 February 2019 (UTC)
Alternatively, go to Special:SetLabelDescriptionAliases. Jc86035 (talk) 15:58, 8 February 2019 (UTC)
Why not labelLister gadget? --Liuxinyu970226 (talk) 16:25, 9 February 2019 (UTC)
When you aren't logged in...? Matěj Suchánek (talk) 19:37, 9 February 2019 (UTC)

Could use a hand structuring this source

Essentially I want to be able to provide a credible source for instances of Munro (Q1320721). I found that the original (partially incorrect) list written by Sir Hugh Munro, 4th Baronet (Q1347890) is found in The Scottish Mountaineering Club Journal (Volume 1 Number 6) which can be accessed via the Glasgow Digital Library or viewed in this archived scan.

So far I've created the following items (trying to follow WikiProject Periodicals):

However, it's fairly confusing to me whether I'm understanding and correctly structuring this data (especially with a lack of model item (P5869) to go by). Could use a more experienced eye to look these over and point me in the right direction (or feel free to help add the necessary items/info as it would still provide me with good example). --SilentSpike (talk) 12:48, 9 February 2019 (UTC)

@SilentSpike: See Help:Sources#Scientific,_newspaper_or_magazine_article.
In general, do create an item for the actual article, and do create an item for the periodical as a whole. But don't create an item for a particular volume of the periodical, and don't create an item for a particular issue of a particular volume.
On the item for the article, use published in (P1433) to specify the periodical it appeared in. volume (P478), issue (P433), and page(s) (P304) can be used to specify the remainder of the article's bibliographic reference information. Jheald (talk) 22:52, 9 February 2019 (UTC)
@Jheald: Thank you, this is the perfect answer for me. That was the main thing tripping me up (thinking I had to create items for every intermediate step before finally getting to the source I want). One follow up question: Is there a way to connect the archived scans of historic volumes to the item for the periodical as a whole (as you can see I'm using Internet Archive ID (P724) on the volume item). --SilentSpike (talk) 23:37, 9 February 2019 (UTC)
@SilentSpike: One approach is to use Internet Archive ID (P724) several times with different values on the periodical item, qualified by volume (P478) on each use, see for example Zoologisches Zentralblatt (Q51428439).
Possibly some may frown on this and say there should be different items for different volumes, but for most purposes this seems to me to be good enough. I might create separate volume items if there were separate categories on Commons, but even then it may make sense to keep some information concentrated on the item for the periodical as a whole. Jheald (talk) 23:59, 9 February 2019 (UTC)

Canadian Geographical Names Data Base

Is Canadian Geographical Names Database (Q14934367) considered a good data source for coordinate location (P625)? Has it been used to add data to Wikidata? Abductive (talk) 07:15, 10 February 2019 (UTC)

Patrol with tagfilter

I visit the recent changes page for a particular tagfilter every few days. Unfortunately on that page I can not mark edits as "patrolled".

On the opposite, at https://tools.wmflabs.org/pltools/rech/ I can mark edits as patrolled, but it shows all edits, only 1 in a 1000 has the tag that I want to patrol.

Question: What tool or setting can I use to efficiently patrol and mark as patrolled all edits that have a particular tag? Thanks! Syced (talk) 11:40, 10 February 2019 (UTC)

In preferences, enable "Mark as patrolled: Adds a [Mark as patrolled] link to change list items, which have the red exclamation mark." Matěj Suchánek (talk) 11:52, 10 February 2019 (UTC)
Wonderful, it works, thanks! :-) Syced (talk) 12:05, 10 February 2019 (UTC)

Triplication?

Robert Craig Wallace (Q61483178), Robert Craig Wallace (Q21545053), Robert Craig Wallace (Q21545049)? --Magnus Manske (talk) 09:34, 5 February 2019 (UTC)

Robert Craig Wallace (Q21545049) was well defined while Robert Craig Wallace (Q61483178) and Robert Craig Wallace (Q21545053) were based on RKD record with minimal info. They all had in common that it was british painter and etcher with unusual name painting marine themes and landscapes in the same time period. I merged them. --Jarekt (talk) 14:15, 5 February 2019 (UTC)
I'm afraid that Wikimedia permanent duplicate item (Q21286738) applies here. --117.13.95.87 06:35, 11 February 2019 (UTC)

Stadium that is not belong to the team

If a team is using as home ground a stadium that is not belong to the team (for example, the stadium is belong to the goverment), then to add the team that is using the stadium should we use occupant (P466) or operator (P137)? Xaris333 (talk) 12:43, 9 February 2019 (UTC)

Buildings and structures are generally occupied, not operated. Ghouston (talk) 00:32, 10 February 2019 (UTC)
You could also have used by (P1535), but I've seen occupant (P466) on such items. Ghouston (talk) 00:35, 10 February 2019 (UTC)
One of the examples on operator (P137) is , but I would have used occupant (P466) in that case too. Ghouston (talk) 00:38, 10 February 2019 (UTC)
I suppose embassy (Q3917681) is another instance of confusion between a building and an organisation, but in neither case does "operator" seem like the right concept. Ghouston (talk) 00:40, 10 February 2019 (UTC)
@Ghouston: Why operator (P137) People's Republic of China (Q148)? Can't we batch change them to operator (P137) Ministry of Foreign Affairs of the People's Republic of China (Q1155502)? Don't we know that after 19th National Congress of the Chinese Communist Party (Q23791320), the PRC Central Government no longer directly operates all overseas embassy (Q3917681) and consulate (Q7843791) around the world at all (they indeed fully transfered all rights to operate to the PRC's MFA)? --Liuxinyu970226 (talk) 04:34, 11 February 2019 (UTC)
I don't know anything about that. However, parent organizations don't really "operate" their subsidiaries. Ghouston (talk) 05:33, 11 February 2019 (UTC)

Does "different from" prevent two items from being merged?

Does "different from" prevent two items from being merged? If not can we implement that? After I reverse bad merges or we get consensus that two entries are not the same, I always add "different from" to each other. Will that prevent a merge in the future? I don't want to test it to find out. --RAN (talk) 20:24, 9 February 2019 (UTC)

Yes, it will. Matěj Suchánek (talk) 20:27, 9 February 2019 (UTC)
Use do not confuse with different from (P1889) : it will automatically prevent false merges. Bouzinac (talk) 20:30, 9 February 2019 (UTC)
Doesn't any link between the two items prevent a merge? Even said to be the same as (P460)? Ghouston (talk) 00:26, 10 February 2019 (UTC)
It does. Matěj Suchánek (talk) 09:43, 10 February 2019 (UTC)
@Ghouston, Matěj Suchánek: IMHO Some said to be the same as (P460) linked pairs should better check if they're Wikimedia duplicated page (Q17362920)-suitable or not, then Wikimedia permanent duplicate item (Q21286738)-suitable or not. --Liuxinyu970226 (talk) 04:28, 11 February 2019 (UTC)

Linking library systems and branch libraries

When linking a branch library to its library system, do we prefer parent/subsidiary, part of/has part, operator, or some other properties? - PKM (talk) 21:54, 10 February 2019 (UTC)

I’m inclined to say a library branch is part of a library system, and the library system has parts that are branches. This allows for the fact that in some cases libraries are collections of books and in other cases they are buildings (especially former libraries), which may be separated in the future. I too have seen parent/subsidiary, but that implies a degree of autonomy at the branch level which may not be correct. There are ~80 branches in the Los Angeles Public Library system, plus a handful of former buildings now demolished but of historical significance in their day.
I suppose if I keep my QuickStatements spreadsheet, I can always change it later if there’s a consensus to go a different way.  :-) - PKM (talk) 06:45, 11 February 2019 (UTC)

"Dual linking" Commonswiki links

"Dual linking"

Maybe this could also open the doors for what I'd like to call "Dual linking" where a Commonswiki category page could be both linked on the main subject's page and the "Wikimedia category" page, this could increase the discoverability of both Wikimedia categories (including related subjects) and help organise related pages which are about the same subject. Let's say that two (2) panamed "Numerius Negidius" one links to "the main subject" including Wikipedia pages and Wikisource entries related to it while the other links to its Wikimedia category, Commonswiki galleries are typically placed on the former while Commonswiki categories are typically placed on the latter, as the set of images relates to both (including related subjects), would this technically possible? The benefits is the discoverability of images for subjects. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 20:30, 7 February 2019 (UTC)

I would merge every "commons category" item with the item of the topic of the category. There is no reason for have an item just for the category and one item that describes the content and topic of the category. --GPSLeo (talk) 08:17, 8 February 2019 (UTC)
So what would be the item for the topic "2019 in Seattle"? - Jmabel (talk) 16:22, 8 February 2019 (UTC)
@Donald Trung: I had a similar idea (that I called "one link per Wikimedia project, per namespace"). No thecnical possible right now but it is definitely something we should look into!
@Jmabel: in this idea, there wouldn't be any more items for topic and items for category. So "2019 in Seattle" (that doesn't exist?) and Category:2019 in Seattle (Q60971509) would be merged into one item.
That make some sense; maybe I'm just not correctly understanding what you originally wrote. I'm especially thrown by "panamed" (not a word I've ever seen). Could you maybe reword?
Also, if there "wouldn't be any more items for topic and items for category" wouldn't that have major effects beyond Commons? E.g. Gilbert du Motier, Marquis de Lafayette (Q186652) vs. Category:Gilbert du Motier, Marquis de Lafayette (Q9013148), the latter being on de-wiki and fr-wiki as well as Commons. - Jmabel (talk) 17:41, 9 February 2019 (UTC)
Cdlt, VIGNERON (talk) 10:52, 9 February 2019 (UTC)
what about category contains (P4224); category's main topic (P301)...? Those ones would be merged into the topic items? What a mess. The solution that makes more sense to me is deleting every commonsgallery sitelink from wikidata (after migrating them to Commons gallery (P935). Then, storing commonscategory sitelinks in the "topic-item" when a "category-item" doesn't exist, and with the "category-item" when it does. strakhov (talk) 18:40, 9 February 2019 (UTC)
  Weak oppose Where there are categories on both Wikipedias and Commons for a particular subject, they should be sitelinked. I don't believe the dev team is going to go out of its way to allow sitelinks from the same item to multiple namespaces on the same wiki -- too much is hardwired with the assumption "1 wiki - 1 sitelink". Also, as per comments above, I don't think we probably want to have regular items for typical complex/intersection categories, though it is useful to have category-type items for them here. IMO the existing category's main topic (P301) / topic's main category (P910) mechanism works well enough, so I don't see an existing problem here that really needs to be solved. Jheald (talk) 22:41, 9 February 2019 (UTC)
  Support This is what Wikimedia Incubator users e.g. @Liuxinyu970226, Koavf, StevenJ81: also want. --117.13.95.87 06:37, 11 February 2019 (UTC)
Don't presume what I want. StevenJ81 (talk) 11:32, 11 February 2019 (UTC)
  Weak oppose This is necessary at incubator: or mul:ws: but really the solution here in my opinion is that a bot should mass-create galleries to mirror the category structure. On (e.g.) en.wp, there is both R.E.M. and Category:R.E.M. Those two pieces of the encyclopedia have two different items at d: and so the content at c: should mirror that structure. —Justin (koavf)❤T☮C☺M☯ 07:15, 11 February 2019 (UTC)
  Support This should be considered as "we can", not "we can't". --Liuxinyu970226 (talk) 14:49, 11 February 2019 (UTC)

Wikipedia ids

Is there the way to add Wikipedia id by names of languages (by "Language" column)? For example if there is label in "English", "German" and "French" there could be shown their ids "en", "de" and "fr". Currently on language name is shown on the left side and language id is shown on the right side (interwiki list). In case of pages with labels in many languages and/or many interwikis it's impossible to realise if both match. Eurohunter (talk) 18:29, 10 February 2019 (UTC)

There were rumors of development work being done on that labels & descriptions entry box, there are a number of issues there. You might want to try the "Contact the Developers" page for this. ArthurPSmith (talk) 15:14, 11 February 2019 (UTC)

ISO 639-3 Change Requests

I’d like to add Wikidata items for Change Requests on ISO 639-3 language codes. These are useful references for claims on language items, especially for rare languages. See ISO 639-3 change request 2008-040 (Q61639834) for an accepted request, and ISO 639-3 change request 2014-053 (Q61686517) for one that has been rejected. See number of speakers, writers, or signers (P1098) of

Romagnol (Q1641543) for an example claim backed by Request for New Language Code Element [rgn] in ISO 639-3 (Q61685511) which is part of an ISO 639-3 Change Request. Before writing a bot to create the ~1500 items, I’d like to get people’s feedback on the general modeling. (For the request IDs, I’ve proposed a new property, but there’s other aspects beyond the ID). Thanks for having a look at the two example items, and for pointing out things to improve. — Sascha (talk) 13:08, 11 February 2019 (UTC)

+1 --Liuxinyu970226 (talk) 14:51, 11 February 2019 (UTC)
@Sascha: I’m not sure if has effect (P1542) is the right property to use for the outcome – perhaps use significant event (P793) instead? (I think this also fits well with the point in time (P585) qualifier.) --Lucas Werkmeister (talk) 15:15, 11 February 2019 (UTC)
@Lucas Werkmeister: Thank you! Like this? Acceptance: significant event (P793) of

ISO 639-3 change request 2008-040 (Q61639834); Refusal: significant event (P793) of ISO 639-3 change request 2014-053 (Q61686517) — Sascha (talk) 15:32, 11 February 2019 (UTC)

@Sascha: yes, that looks good to me :) --Lucas Werkmeister (talk) 18:27, 11 February 2019 (UTC)

MWAPI against de.wikipedia.org

The following is working: 

SELECT * WHERE {
    SERVICE wikibase:mwapi {
     bd:serviceParam wikibase:api "Categories" .
     bd:serviceParam wikibase:endpoint "en.wikipedia.org" .
     bd:serviceParam mwapi:titles "Albert Einstein" .
     ?cat wikibase:apiOutput mwapi:category .
    }
}
Try it!

The following is not working (or at least unstable): 

SELECT * WHERE {
    SERVICE wikibase:mwapi {
     bd:serviceParam wikibase:api "Categories" .
     bd:serviceParam wikibase:endpoint "de.wikipedia.org" .
     bd:serviceParam mwapi:titles "Albert Einstein" .
     ?cat wikibase:apiOutput mwapi:category .
    }
}
Try it!

The following is also working: https://de.wikipedia.org/w/api.php?action=query&prop=categories&titles=Albert%20Einstein&cllimit=max&format=xml

-- Luitzen (talk) 17:24, 7 February 2019 (UTC)

@Smalyshev (WMF): --Pasleim (talk) 17:59, 7 February 2019 (UTC)
Very weird, it looks like any MWAPI query against de.wikipedia.org doesn’t work? But it’s working on my local query service install. --Lucas Werkmeister (WMDE) (talk) 11:04, 8 February 2019 (UTC)
Just tried it, worked just fine for me. Temporary issue? Smalyshev (WMF) (talk) 19:30, 8 February 2019 (UTC)
@Smalyshev (WMF): This still doesn't work for me: https://yadi.sk/i/tv8rqueN-9XCgw -- Luitzen (talk) 18:22, 11 February 2019 (UTC)
Now it works. Thanks! -- Luitzen (talk) 08:51, 12 February 2019 (UTC)

Question regarding Commons Categories

I notice that when a Commons category is moved/retitled on Commons (e.g "Category:John Smith to "Category:John P. Smith"), the "other sites" item here on Wikidata automatically updates immediately, yet the property Commons category (P373) does not. Does this get automatically fixed by a bot within a short time, or does it need to be manually updated? For a recent example, see Maxi Schafroth (Q1608370). Animalparty (talk) 19:55, 10 February 2019 (UTC)

I think it needs to be updated manually. I haven't noticed any bot doing it. Ghouston (talk) 06:08, 11 February 2019 (UTC)
That is very, very unfortunate if true. Seems like something that should be made automatic, in the same fashion as Wikipedia articles and Commons categories. The ever-present, ever-growing Wikidata infobox on Commons apparently uses Commons category (P373) for navigation: when I moved c:Category:John Alexander McDougall to c:Category:John Alexander McDougall (artist), turning the former into a disambiguation page, incoming links (e.g. from c:Category:Walt McDougall) were not updated accordingly until I manually changed the property in Wikidata. Since the WikiD-infobox is on over 2 million categories, who knows how many dead ends this has created? Animalparty (talk) 08:12, 11 February 2019 (UTC)
If anything does it, it would be Pi bot by Mike Peel. I vaguely remember there's some reason why it doesn't. Ghouston (talk) 08:57, 11 February 2019 (UTC)
Pi bot runs a query to find cases where P373 and the sitelink don't match, and checks to see if that's because the P373 value is a category redirect to the sitelink - and if so, it fixes the P373 value. That will not work for cases like c:Category:John Alexander McDougall where the old category is now a disambiguation category, though, those need to be sorted out manually. Also, it looks like the query's been timing out, so the bot hasn't been running this task recently, I'll investigate this. Thanks. Mike Peel (talk) 09:45, 11 February 2019 (UTC)
It's running again, but only for the first 5,000 items that the query returns (it seems there are a lot of discrepant values...). I'll rework the code soon to split the query up into multiple ones. Thanks. Mike Peel (talk) 10:00, 11 February 2019 (UTC)
Great! I think it may have trouble with cases where the sitelink is on a category item and the bad P373 on a main item? One of the first items it fixed was Piarist High School, Timișoara (Q1413977), where the Commons category was renamed back in 2015. Ghouston (talk) 10:34, 11 February 2019 (UTC)
@Ghouston: In that case, the problem was that there were two P373 values until 25 November 2018, see [6] and the next edit. The bot excludes any cases with multiple P373 values. You're probably right that it has problems with the sitelink being in a category item, though. The bigger issue is that there's still quite a lot of bad P373 values around that aren't linked to a redirect, try running this query:
SELECT ?item ?commonscat ?sitelink ?name WHERE { ?item wdt:P373 ?commonscat. ?sitelink schema:about ?item; schema:isPartOf <https://commons.wikimedia.org/>; schema:name ?name . FILTER( CONTAINS(STR(?sitelink), 'Category:') = true ) . FILTER( ?commonscat != SUBSTR(STR(?name), 10) ) .} LIMIT 1000
Thanks. Mike Peel (talk) 11:25, 11 February 2019 (UTC)
@Ghouston, Mike Peel: Pardon my ignorance, but why doesn't P373 update automatically following moves on Commons? If I move a category or a Wikpedia article, the connectivity to all other linked entities (foreign language articles, etc.) is corrected within seconds. Why not P373? And for that matter, why does the value for Commons category appear twice, once as the property and once as an "other site"? If there's a 1:1 correlation between the two, but only one does its job linking entities, it seems like a hugely inefficient redundancy. Animalparty (talk) 20:02, 11 February 2019 (UTC)
@Animalparty: P373 is basically a bit of text, it's not actually attached to the category. While the link under 'other sites' is a sitelink, which links commons to wikidata (and is what the infobox uses to find the topic for that category). The advantage of P373 is that it lets you link multiple items to a single commons category, while the sitelink is one-to-one. The disadvantages of it are legion, but we're stuck with it for now, for a variety of reasons as discussed at Wikidata:Properties_for_deletion#Commons_category_(P373). Thanks. Mike Peel (talk) 20:42, 11 February 2019 (UTC)
@Mike Peel: So, just so I'm clear, does the Wikidata infobox use P373 or the 'external link' when displaying links on Commons? From anecdotal experience it appeared that the infobox was relying on P373 (thus linking to the wrong category until P373 was manually updated), but perhaps there was just a lag in cache clearing. Animalparty (talk) 20:54, 11 February 2019 (UTC)
I think both are currently used, I'm not sure about the ordering. @RexxS: can you help? Thanks. Mike Peel (talk) 21:30, 11 February 2019 (UTC)
@Mike Peel, Animalparty: The logic in Module:WikidataIB when used on Commons for any linked item is to first look for values of Commons category (P373) for that item. If any are found, it uses the first value to construct the link to the category, and uses the item's label as its sort key. If there's no P373 value, it tries to construct a link using the item's sitelink to Commons, and uses the label as its displayed text. If there's no sitelink, it just displays the label unlinked. If there's no label either, it displays the Wikidata entity-id (Qnnnn) and puts the page in a tracking category for missing Wikidata label. All of that does require some manual maintenance on Wikidata to keep the information useful, as I've yet to find a way of automating those processes. HTH --RexxS (talk) 01:04, 12 February 2019 (UTC)
This is getting a bit specific, so I've followed up on this at c:Template_talk:Wikidata_Infobox#Linking. Thanks. Mike Peel (talk) 09:39, 12 February 2019 (UTC)

Apostasy in Catholicism/Apostasy in Christianity

Hi, could someone please merge back Special:Contributions/Dlom's edits to Apostasy in Christianity and Apostasy in Catholicism. These are two mutually exclusive acts. Furthermore, there was a long list of people included in Apostasy in Catholicism. - 108.71.133.201 07:27, 11 February 2019 (UTC)

It seems you already undid the merge. Esteban16 (talk) 16:43, 11 February 2019 (UTC)

The reverts did not work properly since the original edits were merges. Could someone merge them back to the original? - 108.71.133.201 21:51, 11 February 2019 (UTC)

There is really nothing to revert now. Matěj Suchánek (talk) 09:11, 12 February 2019 (UTC)

@Matěj Suchánek: Whoops, I see what the problem is now. The Special:Contributions/KrBot moved all of the uses of apostasy in Catholicism (Q55004488) to apostasy in Christianity (Q864968). Could you please run a bot to revert these changes back? - 2600:1702:31B0:9CE0:7CD0:212A:BD0C:7A47 14:52, 12 February 2019 (UTC)

  Done Matěj Suchánek (talk) 15:56, 12 February 2019 (UTC)

Wikidata weekly summary #351

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Development
    • Working on the "in more languages" and "all entered languages" parts of the termbox on mobile
    • Working on making undo, revert, edit summaries and more work for Shape Expressions
    • Fixed an error when detecting the same label and description in another Item (phabricator:T194770, thanks Matěj)
    • Making Lemma input on Lexeme pages save your input when you press enter (phabricator:T206140)
    • Making QuickStatements work more easily for other Docker-powered Wikibase instances (phabricator:T205606)
    • Worked more on making Federation work for making Statements on Wikimedia Commons (phabricator:T214557)
    • Working on stripping whitespaces at the beginning and end of Glosses when saving them (phabricator:T212019)
    • Looking into adding more signals to ORES' vandalism detection model so we can detect bad edits more accurately (phabricator:T194737)
    • Preventing a redirect of an Entity onto itself (phabricator:T214775)
    • Fixed an issue with adding sitelinks from Wikimedia Commons (phabricator:T213975)
    • Unified the separators between language and lexical category in different places (phabricator:T201808)
> There is now an experimental SPARQL service to query Wikidata history
Great! Thanks!! -- Luitzen (talk) 08:43, 12 February 2019 (UTC)
Out of curiosity, at how many thousands of weird wannabe-IDs will folks here decide that this is a massive DDOS link spam attack, or is it only me? All IDs y of the form x/y at site x should be left to search engines. –84.46.53.230 16:22, 13 February 2019 (UTC)

Request for Comment regarding the notability of Commonswiki categories

Please see "Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion)" for a discussion related to the inclusion of Wikidata items whose only (Wikimedia) sitelinks link yo Wikimedia Commons. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 19:18, 12 February 2019 (UTC)

CMS Collaboration as author

Observation of a new boson at a mass of 125 GeV with the CMS experiment at the LHC (Q21481859) and Observation of a new boson at a mass of 125 GeV with the CMS experiment at the LHC (Q42302346) seem to be duplicates, however the authors in the first item are listed in full (there are thousands of them), but are stated as only "CMS Collaboration" in the second. I assume only one should be kept: either the first, with authors linked in the conventional way, or the second, with a new item created for "CMS Collaboration" as a pseudo-organization and authors added as members of that. I think the first would be preferred? Ghouston (talk) 01:11, 13 February 2019 (UTC)

This "CMS Collaboration" or "The CMS Collaboration" can also be found as the author of other articles, not all of which have duplicates. Ghouston (talk) 01:14, 13 February 2019 (UTC)
These had identical DOI's and arXiv id's. I have merged them (after removing the collaboration "author name string", also the wrong publication date). What to do with collaborations as authors is an interesting question; I think we should try to follow whatever the original source does, but it might actually be useful to have a new property for this ("collective author" or something?) In this case we do have an item that represents the collaboration (as an "experiment") - CMS experiment (Q659478). ArthurPSmith (talk) 15:41, 13 February 2019 (UTC)

Q179637

prisoner of war (Q179637) is listed as a military classification of death. But it is also used to label ordinary prisoners of war. Should I separate the two? Should we have "prisoner of war" and "death while prisoner of war"? --RAN (talk) 17:57, 12 February 2019 (UTC)

It's listed as a casualty classification, not a death one - "casualty" is a broad term and can indicate people who are wounded or missing as well as killed; see w:Casualty (person). So it doesn't really imply "died in captivity", I think.
Looking at how it's currently used, there are 100 items using {{P|1347)):prisoner of war (Q179637), of which the majority (86) have a time qualifier (start/end/point-in-time), which seems to make sense - it is used to indicate that they had a status of POW between dates X and Y. See eg Otto Kretschmer (Q57253). There's potentially some conflict between using this and using place of detention (P2632) (which IIRC is the normal model for civilian prisoners), though. Andrew Gray (talk) 23:37, 13 February 2019 (UTC)

Duplicate links to Commons categories

I've noticed that there are two places in a Wikidata item where there could be a link to Commons category - in the 'statements' section and in the 'other sites' section at the end. Example: Q61710295. I think it's redundant to have the same information twice on the same page. Is there any (practical) reason for this? Could the tools/projects that use this info just get it from a single entry? JiriMatejicek (talk) 21:04, 13 February 2019 (UTC)

  • Yes there are practical reasons for this, yes it is redundant and annoying but it isn't going to change soon. If you put a Commons category in the sitelink, a bot will eventually fill in the property; it's a long story.
  • Question to others: is there some one place where there is a good summary of this? I certainly don't have the patience to rehash it all. - Jmabel (talk) 01:20, 14 February 2019 (UTC)

Watch new links to an item

Is there a way to be notified whenever new links are made to an item? Evolution and evolvability (talk) 03:20, 12 February 2019 (UTC)

Evolution and evolvability, it is not possible to do that. You still can watch general changes made (not just links added) and even watch those changes on other wikis. Esteban16 (talk) 04:19, 12 February 2019 (UTC)
@Esteban16: Thanks for the info. A pity it's not possible, since it'd be a useful to check new items related to an interest. I get such notifications for Wikipedia articles that I created, but no idea how to add/remove items from that list! Evolution and evolvability (talk) 04:25, 12 February 2019 (UTC)
@Evolution and evolvability, Esteban16: Perhaps it might be possible by using ListeriaBot/{{Wikidata list}} to automatically generate a list? It wouldn't generate notifications but you would still be able to keep track of changes. Jc86035 (talk) 11:47, 14 February 2019 (UTC)
@Jc86035: Interesting idea! I also asked over at MediaWiki (link) and it turns out that there's a Phab task open for pretty much this (link), so there is some interest in the capability. Evolution and evolvability (talk) 22:29, 14 February 2019 (UTC)

Tool to extract from Wikipedia categories

I am looking for tools that leverage Wikipedia categories to add structured information into Wikidata. Example: Categories such as "All companies in <this sector of activity> in this <country>" contain a lot of information about which industry a company is operating in. Can anyone point me to such a tool? Thanks! Pdehaye (talk) 13:21, 13 February 2019 (UTC)

You can use PetScan for this, be sure to select Wikidata as "use wiki" under "other sources". Sjoerd de Bruin (talk) 13:29, 13 February 2019 (UTC)
Would Harvest templates tool meet your expectations ? Kpjas (talk) 21:03, 14 February 2019 (UTC)

Marriage end causes

Infoboxes in the English Wikipedia have the reason for the end of marriages (divorce or death of one of the parties), is their any plan to do that here? See for example Elizabeth Taylor (Q34851) with multiple marriages here at Wikidata and at Wikipedia w:Elizabeth Taylor. --RAN (talk) 23:31, 14 February 2019 (UTC)

end cause (P1534)? Circeus (talk) 06:25, 15 February 2019 (UTC)

Hide quickstatement edits from the watchlist

Is there a way to remove Quickstatement edits from my watchlist? I fumbled around to try and do b/c while they are good edits... they are useless for me to see and making it dwnright impossible to see the edits I do want to see. Circeus (talk) 06:23, 15 February 2019 (UTC)

Q57879255: shouldn't items about the same topic or same name be merged?

Recently somebody keeps demerging Q57879255 into different items (including Q174098, Q57878989, Q57879426 and Q61057659). I've checked the 9 entries (bar:Nationalpolizei, ca:Policia Nacional, de:Nationalpolizei, en:National police, es:Policía Nacional, fr:Police nationale, ja:国家警察, pt:Polícia Nacional and zh:國家警察) merged into Q57879255, and I've found that all of the 9 entries are disambiguation pages (Wikimedia disambiguation page (Q4167410)) about the exact same topic (National police, translated into several languages including German, France, Spanish, Portuguese, Japanese and Chinese language). Is there anything wrong to merge items with the exact same topic? Why should these entries be split into different items? --Howard61313 (talk) 14:38, 29 January 2019 (UTC)

@Howard61313 : Generally speaking, I have to say I think it's good practise to split them up and using "said to be the same as" to interlink where appropriate - same as we do for given names and family names. The reason being there are other items, like (titles of) books, films, band names, night clubs, fashion brands, etc. that might need to be "different from" one language disambiguation page but not the others. Moebeus (talk) 15:57, 29 January 2019 (UTC)
@Moebeus: These are not the most appropriate examples here, "national police" is not like the name of works or people, but government agencies shared by several countries instead. The example of Q20901295 (Ministry of Foreign Affairs) would be better, which doesn't need to be "different from" other pages although they have different ways to be referred to in different languages, for example, "Außenministerium" (roughly "Ministry of the Exterior" in German) and "Ministério das Relações Exteriores" (roughly "Ministry for Foreign Relations" in Portuguese) are called differently in their respective languages, but they're still the same thing as "Ministry of Foreign Affairs". Instead of "said to be the same as", they're "already the same as".--Howard61313 (talk) 04:02, 30 January 2019 (UTC)
They are all different items: the french page is a list, all the other page are disambiguation, but all these disambiguation have different spelling so they are different disambiguation that we must keep separated. If next time you ping me I can answer more quickly --ValterVB (talk) 18:17, 29 January 2019 (UTC)
@ValterVB: They are all the same items, for Christ's sake. The French page is a "page d’homonymie " (disambiguation page) instead of a list, didn't you read it on the top of the page? And different spelling in different languages doesn't make things different. For example, Police nationale (France) on fr.wikipedia is exactly the same as National Police (France) on en.wikipedia and Policía Nacional (Francia) on es.wikipedia, which are all referring to the national police force of France. By the way, your reason doesn't justify your act to split 国家警察 on ja.wikipedia and 國家警察 on zh.wikipedia into different items, which are both disambiguation pages about national police, even written in almost the same way with Han characters ("Hànzì" in Chinese/"Kanji" in Japanese. By the way, this is another good case showing that different spelling makes the same topic, which are not separated. Another good example can be seen above, concerning "Ministry of Foreign Affairs" in different languages. The difference between the spelling of "Außenministerium" and "Ministério das Relações Exteriores" is even larger than the difference between "National police", "Nationalpolizei", "Police nationale" and "Policia Nacional"!) And this act doesn't justify your edition to remove labels in other languages as well (for example, "Polis Kebangsaan" in Malay, "Cảnh sát Quốc gia" in Vietnamese and "국가경찰" in Korean, which are all corresponding translations for "national police". There's no point to remove them).--Howard61313 (talk) 03:44, 30 January 2019 (UTC)
See Wikidata:WikiProject Disambiguation pages/guidelines, and discussions on its Talk page. Ghouston (talk) 05:06, 30 January 2019 (UTC)
Disambiguation pages aren't about a topic but about multiple separate topics that have the same name. As a result, we merge Disambiguation pages when they have the same name and not by topic (by definition each Disambiguation page is about more then one topic). You could create a redirect ":en:Nationalpolizei" that points to ":en:National police" and link that ":en:Nationalpolizei" item from the same item as ":de:Nationalpolizei". This redirect creation at the moment isn't as comfortable as possible but it gives you interwiki-links if your intention is to have interwiki-links on the corresponding Wikipedia pages. ChristianKl ❪✉❫ 11:00, 30 January 2019 (UTC)
Thank you for correcting my words. Compare to "same topic", now I think that "same name" is more appropriate for the case of "national police" (which are disambiguation pages for police forces in several countries that can be translated as "national police" from their respective languages).--Howard61313 (talk) 04:22, 31 January 2019 (UTC)

Sorry for late replay, I was busy in RL.
The page in French is not a page of disambiguation, in fact you can not find it in fr:Spécial: DisambiguationPage. it is more like a "(en) set index" page where the meaning of words is crucial. All the other pages are, instead, real disambiguation page, the meaning is irrelevant.
The rules for the disambiguations are clear: the only thing that matters is the spelling, the meaning is irrelevant, so if the spelling is different, different elements will be created.
For different alphabets there is not a precise rule, normally it is linked to the English one because it's the biggest wiki and it's normally done this way, if I have separated Chinese and Japanese it was a mistake but with all the movements you did it is difficult to reconstruct how the elements were before.
Now I restore the situation to before your changes. If you want to change the situation first look for consent then you can make that kind of changes. --ValterVB (talk) 09:38, 1 February 2019 (UTC)

Not only fr:Police nationale, nothing can't be found in fr:Spécial: DisambiguationPage as we speak. Anyway, the page is categorized under fr:Catégorie:Homonymie (corresponding page for en:Category:Disambiguation pages) with a template called fr:Modèle:Internationalisation on the top, which is set for disambiguation pages. I think that there's no doubt that the page is a disambiguous one. Besides, the precedent of Q20901295 (Ministry of Foreign Affairs) and Q223603 (Republican Party, differently spelled as "Republikanische Partei" "Parti républicain", etc.) already justified that interlanguage link between disambiguation pages concerning organizations can be existed based on their meaning instead of the consistency on spelling. I'm sorry that I just don't see why the reasons you mentioned can ever stop the interlanguage link between them, and those reasons didn't justify why labels in other languages (for example, "Cảnh sát Quốc gia" in Vietnamese and "국가경찰" in Korean) should be removed.--Howard61313 (talk) 06:13, 8 February 2019 (UTC)
There's a slight typo in the link. You'll get the correct link if you lose the blank space after Spécial: i.e. fr:Spécial:DisambiguationPages. Then again that page is capped to only list 10,000 pages and fr:Police nationale isn't one of them, so I guess it doesn't really matter... Tommy Kronkvist (talk), 07:40, 8 February 2019 (UTC).
There're 130,247 pages contained in fr:Catégorie:Homonymie, and fr:Police nationale is one of them. It's obvious that fr:Spécial:DisambiguationPages contains only a part of all disambiguation pages on fr.wikipedia.--Howard61313 (talk) 11:49, 10 February 2019 (UTC)
No,fr:Police nationale isn't in fr:Catégorie:Homonymie because it isn't a disambiguation. Maybe isn't clear what is a disambiguation page for mediawiki software. I suggest you to read mw:Extension:Disambiguator and Wikidata:WikiProject Disambiguation pages/guidelines and stop to revert, until you don't understand this simple rules used in Wikidata. --ValterVB (talk) 17:03, 13 February 2019 (UTC)
The reason you provide didn't persuade. It's indeed in fr:Catégorie:Homonymie, see here for Christ's sake. Besides, different spelling, which is a weak reason in this case, can't stop interwiki-links between items with the same meaning, otherwise precedents like Q353135, Q20901295, Q223603 wouldn't have been existed. I strongly suggest you to stop blocking interlinks based on irrelevant grounds. --Howard61313 (talk) 12:37, 15 February 2019 (UTC)

Wikidata used by Jura1, MisterSynergy, Succu, Mahir256 as a tool to spread fake information

The current label for Property:P2580 is "Baltisches Biographisches Lexikon Digital ID (former scheme)".

  1. The name "Baltisches Biographisches Lexikon Digital ID" has never been used by the BBLD nor any other source, prior to Wikidata editors making it up
  2. The claim "(former scheme)" as part of the name has never been used by the BBLD nor any other source, prior to User:MisterSynergy making it up 2019-01-04 [7]
  3. The claim "(former scheme)" as part of the description for the ID has never been used by the BBLD nor any other source, prior to User:Jura1 making it up 2018-09-12 [8]
  4. "[A-Za-z0-9][-.0-9A-Za-z]+" reference URL http://bbld.de/web/isni - The stated reference URL returns 404, and that regex has never been used by the BBLD nor any other source, prior to Wikidata editors making it up.

The two most recent insertions of fake information are by User:Succu [9] and User:Mahir256 [10], the latter invoked by Jura1 at the Admininistrators' noticeboard [11]

The authoritative and primary source is https://bbld.de/info/id stating

  1. name = "BBLD ID" and
  2. regex = "/^[A-Z0-9][-.0-9A-Za-z]{1,62}[.0-9Xa-z]$/".

There is no credible secondary source for these IDs.

The users that inserted the fake information or helped to keep it all have more than 1 million edits on wikidata.org, two are admins, one a rollbacker and propertycreator:

In a recent discussion in the project chat (Wikidata:Project_chat/Archive/2019/01#BBLD claims Wikidata contains false info) 2019-01-19 User:Strobilomyces wrote:

"These parenthetic comments do not come from the BBLD and have now been removed. So as long as those changes are OK, I think that the allegation in the link that Wikimedia is spreading false information about the BBLD should now be answered." That was only true for seven more days.

User:Jura1 has not been editing for 18 days [12] and on resume the second edit with the edit summary "Vandalism" was statement including a libelous claim about IP contributors ("problem IPs") and using that to have the fake information restored and protected.

User:Mahir256 protected the property page [13] and the property talk page [14].

Additionally the rights to edit the values have been taken away for IPs in 2018.

What can be done to correct the information and prevent users from re-adding and protect fake information? 77.191.29.20 17:34, 6 February 2019 (UTC)

I guess blocking this IP would be a good start.--Ymblanter (talk) 21:49, 6 February 2019 (UTC)
For the people new here, let me introduce the user known as Tobias Conradi here also known as Tamawashi. His modus operandi: Contribute from an Telefónica Deutschland (Q2401561) ipaddress. Usually quite constructive for a while and at some point the user derails completely and starts attacking people. We seem to be at this point now. Looks like it's time for some blocks. Multichill (talk) 21:59, 6 February 2019 (UTC)
Content at de:Baltisches Biographisches Lexikon Digital is not trustable. --Succu (talk)
FWIW forwarded to dewiki talk BHK, but as we know they do tolerate obscure (student) fraternities and similar topics.  –84.46.53.230 15:58, 13 February 2019 (UTC)
Uhps: de:Diskussion:Baltisches_Biographisches_Lexikon_Digital#Vandalismus durch Benutzer:Succu. --Succu (talk) 22:23, 13 February 2019 (UTC)
  • Maybe we should delete the existing property as well: even the website thinks the globally banned user had swamped us with fake information. ISNI is generally available anyways. --- Jura 17:31, 15 February 2019 (UTC)

Wikipedias and use of wikidata

I have been asked what language wikipedia is using information/templates from wikidata most into their wikipedia. (if possible to measure???) Pmt (talk) 20:29, 13 February 2019 (UTC)

You can see some charts at Grafana. Moreover, some wikis track this via Category:Templates using data from Wikidata (Q11985372). Matěj Suchánek (talk) 08:52, 14 February 2019 (UTC)
In addition also have a look at https://wdcm.wmflabs.org/WD_percentUsageDashboard/. It shows you the percentage of articles on a wiki that make some use of Wikidata's data. --Lydia Pintscher (WMDE) (talk) 18:24, 14 February 2019 (UTC)
@Lydia Pintscher (WMDE): Hello! Would it make sense to have references to use on other Wikimedia projects of data from an item on the item itself on Wikidata? This is no different from what we have on Commons, where uses of media files on other projects are listed. Thanks! --Joalpe (talk) 18:44, 14 February 2019 (UTC)
That already exists :) You just have to go to "page information". It's linked in the sidebar of every Item. There at the bottom you will see which wikis use data from that Item. And if you do the same on a Wikipedia article you will see which Items it takes data from. --Lydia Pintscher (WMDE) (talk) 19:40, 14 February 2019 (UTC)
@Lydia Pintscher (WMDE):. Cool! I didn't know :p One thing we might consider is to have some sort of warning when a change is made on an item that will reverberate on another project. Just to give an example, today a mass change on items have had a huge impact on a table on Wikipedia in Portuguese, as information was being queried and fed via Listeria on a table: [15]. As I was watching the page, I could just change the query [16], and no lasting damage was made, but a way to signal caution, i.e. a warning notice, could be helpful in situations like this one. Is this feasible? Thanks! --Joalpe (talk) 15:00, 15 February 2019 (UTC)

Communist Party of the Balearic Islands (Q11940275) and Communist Party of the Balearic Islands (Q5154465)

Same items？42.3.123.148 07:45, 15 February 2019 (UTC)

Seems like it. Thank you for letting us know! Mahir256 (talk) 08:03, 15 February 2019 (UTC)

Vandalism in Sergio Goyri (Q2263688)

Due to a controversy, actor's template has been target of a series of vandalism edits by IP users. It must be protected. --Link58 (talk) 22:07, 15 February 2019 (UTC)

Has been protected for two weeks. Sjoerd de Bruin (talk) 22:14, 15 February 2019 (UTC)

Duplicate

The item Q60769107 ist identical to the item Q42650745. They should be merged together.--Carl Ha (talk) 00:01, 16 February 2019 (UTC)

Done!  – The preceding unsigned comment was added by Richard Arthur Norton (1958- ) (talk • contribs) at 01:03, 16 February 2019‎ (UTC).

"Bookshop neighbourhood"

Is bookshop neighbourhood (Q27095194) really a valid item? I ran across it because The Ave (Q7715010) was described as being such. Perhaps there is such a thing and it is just poorly applied here. For starters, I live in Seattle, and The Ave—officially University Way NE—is a street, not a neighborhood; the neighborhood is the University District (as shown on the OpenStreetMap map at Q7715010!). Beyond that, though, I know the neighborhood pretty well and I don't think it has as many as five bookshops along the kilometer-long shopping strip, even if we allow for ones that are as much as a block off the street itself. It once had more, probably as many as ten, but that was decades ago. That is in contrast to perhaps 15-20 places serving espresso and/or bubble tea, and well over 30 places to eat, probably more like 50. So what makes a "Bookshop neighbourhood"? And how is a street a "neighbourhood" of any sort? What then is the neighborhood it is in?

This came up because I encountered what seems to me as dubious content in the Infobox generated from this on Commons. - Jmabel (talk) 01:10, 16 February 2019 (UTC)

I assume it was created as the main item for Category:Bookstore neighborhoods (Q8306867). The enwiki category contains a mixture of streets and neighbourhoods. Ghouston (talk) 03:33, 16 February 2019 (UTC)
If The Ave is not best described as a "bookshop neighbourhood", which I guess would be a neighbourhood consisting primarily of bookshops, then it should be fine to remove it from the category in enwiki and change the instance of statement in Wikidata. Ghouston (talk) 03:49, 16 February 2019 (UTC)
I'm not taking on the recategorization in en-wiki, but I will change the instance of (P31) value to shopping street (Q21000333), which has a lot more basis in reality. - Jmabel (talk) 06:08, 16 February 2019 (UTC)

QuickStatements not working

QuickStatements is not working for me this afternoon. I got logged out and loging in always get me to https://tools.wmflabs.org/quickstatements/api.php?action=oauth_redirect with "500 - Internal Server Error". Anybody else is having similar issues? --Jarekt (talk) 03:20, 15 February 2019 (UTC)

Tracked in Phabricator
Task T216208
You are most certainly not alone, and the problem is not specific to QS as far as I am aware. Mahir256 (talk) 03:37, 15 February 2019 (UTC)
Not only QuickStatements. Listeria is not working either. --Derzno (talk) 05:02, 15 February 2019 (UTC)
@Magnus Manske: for keep him posted on the current issues. --Derzno (talk) 06:03, 15 February 2019 (UTC)
Day 2 of the outage: crickets. --Tagishsimon (talk) 11:05, 16 February 2019 (UTC)

Mentorship, or similar

I'm unaccustomed to Wikidata but have recently created

The last-listed was only intended to provide a reference for assertions in the Eauclaire item. The Eauclaire item was only intended for the American Independents item (although Eauclaire has written other books and might conceivably get a Wikipedia article). The 1st ed item is only there because, rightly or wrongly, I believe that WD mandates a distinction between (i) a book (independent of its publication details) and (ii) a specific edition thereof, even if (a) it is absolutely clear that there has only been one edition and (b) it's inconceivable that there'll ever be a second. I only bother with Independents because I felt a need to provide a reference for various assertions in the Harding item. (And I only created the Harding item because I'd just created an article on him in en:WP.)

All of this was rather tiresome. If it was constructive, then OK, no complaints. But I have a queasy feeling that I might have gone about the whole business in the wrong way, written unnecessarily ambiguous values, used inapplicable properties, etc etc. Would some experienced person like to give these creations of mine a quick look-over and provide me (whether here, on my talk page, or elsewhere) with a sanity check?

As an example, American Independents is a book in which Sally Eauclaire presents the work of 18 photographers. She provides an introduction to the whole book and to each of the 18 sections. Is she an author, the editor, or both? (Or should I just parrot what's on the title and/or copyright page?) Each of the 18 photographers writes nothing but instead provides photos; are they authors? The book both anthologizes and is about then-new American color photography. It's not at all about the techniques thereof; it's instead about the art. (Use of color for "art" photography was then still unconventional, though growing fast.) I thought I'd say that its main subject was 20th century (or postwar) US color photography; however, I could only find color photography as an existing item: no American photography or 20th-century photography. I didn't create the latter pair, not only out of lack of stamina but also because I feared such an effort might be totally misguided. -- Hoary (talk) 03:28, 16 February 2019 (UTC) .....reworded a bit 12:18, 16 February 2019 (UTC)

Listeria, Quickstatements et al - dead for the next week

In the absence of any accessible announcement from WMF - because why would you bother informing users on a mainstream noticeboard like this of an outage to a critical service on which heavily used tools depend - let it be known that toolsdb is kaput and will not be repaired until, perhaps, Tuesday 26/02/2019. [17] --Tagishsimon (talk) 18:03, 16 February 2019 (UTC)

Today's update: "ToolsDB should now be fully operational". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:45, 18 February 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 08:47, 22 February 2019 (UTC)

Request for merge

Could someone please merge Jibril Hodges (Q51293965) and Jibril Hodges (Q29002736)? - 2600:1702:31B0:9CE0:8C1E:478D:4467:793E 09:16, 18 February 2019 (UTC)

  OK--Derzno (talk) 13:43, 18 February 2019 (UTC)

Thank you. - 108.71.133.201 17:13, 18 February 2019 (UTC)

This section was archived on a request by: Matěj Suchánek (talk) 08:47, 22 February 2019 (UTC)

Excessive vandalism - "Jean-Baptiste de Lamarck" (Q82122)

Maybe an administrator could have a look at protecting the item for a while. I don't know what this Frenchman did to tick people off, but the majority of edits lately seem to be high-school type vandalism. Moebeus (talk) 12:17, 19 February 2019 (UTC)

  Done Ayack (talk) 16:31, 19 February 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 08:47, 22 February 2019 (UTC)

Merge request

Could someone please merge Dean Smith (Q61781708) and Dean Smith (Q5246474)? - 108.71.133.201 17:07, 21 February 2019 (UTC)

  Done. --Epìdosis 17:10, 21 February 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 08:47, 22 February 2019 (UTC)

Merge Grace (Q20381153) and Grace (Q535220)?

Hi all,

I'm not very experience in merging items. The two items Grace (Q20381153) and Grace (Q535220) look like they describe the same topic just in arabic, respectively spanish. Could you please help me to check? In case they shouldn't be merged, I would be happy to know why not. Many thanks and best regards --Hundsrose (talk) 20:24, 21 February 2019 (UTC)

Hundsrose: They are the same, indeed, so I have merged them. You can learn about merging on Help:Merge. Esteban16 (talk) 00:41, 22 February 2019 (UTC)
@Esteban16: Thank you so much. :) --Hundsrose (talk) 07:46, 22 February 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 08:47, 22 February 2019 (UTC)

Can someone fix Q58620846

The name for Q58620846 is Cryptocurrencies but that clearly isn't what the item is about. It's official name is listed as "Africahead Ipparts" so maybe that's what it's supposed to be? The official website is just odd and doesn't seem to fit anything. Can someone please fix this for me because I am extremely confused on what this item is actually supposed to be. --TB5ivVaO1y55FkAogw1X (talk) 02:00, 17 February 2019 (UTC)

I nominated it at Wikidata:Requests for deletions. Ghouston (talk) 02:50, 17 February 2019 (UTC)

Observe deletion of statements in items

How to monitor the removal of a statement. Example here [18] - after removal of Upper Lusatian house (Q1362233) I can't use my watchlist [19] to observe. Thanks for Help, Conny (talk) 06:06, 17 February 2019 (UTC). (de)

Empty entries?

Q61717459 and Q61707372 appear to have no significant content at all: they have birth date, birth place, occupation, title (for the first one), and Instagram account name (for the second one), plus a photograph, but no pages on any other WMF sites are associated with either one, and they obviously aren't some sort of intermediate part of any data structure/thesaurus/etc. Can these be deleted, or does WD accept items like this? I almost never come here, so I'm not familiar with the process. Nyttend (talk) 00:04, 14 February 2019 (UTC)

The first seems to be the mayor of a town in Turkey, and it looks OK (I fixed it up a bit). The second is a user who created the two items (and the photos on Commons.) Ghouston (talk) 01:16, 14 February 2019 (UTC)
c:Commons:Deletion requests/File:Ozguroz2.jpg. –84.46.53.251 13:11, 17 February 2019 (UTC)

Is this bug already tracked in Phabricator?

SELECT DISTINCT ?item {
  hint:Query hint:optimizer "None"
  SERVICE wikibase:mwapi {
	 bd:serviceParam wikibase:api "Generator" .
     bd:serviceParam wikibase:endpoint "commons.wikimedia.org" .
     bd:serviceParam mwapi:gcmtitle "Category:Commons_licensing_help_by_country" .
     bd:serviceParam mwapi:generator "categorymembers" .
     bd:serviceParam mwapi:gcmtype "page" .
     bd:serviceParam mwapi:gcmlimit "max" .
     ?item wikibase:apiOutputItem mwapi:item .
  } 
# ?item wikibase:sitelinks [] .
  ?article schema:about ?item 
} LIMIT 5
Try it!

It seems that join is not performed when variable appears in the object position of the nearest triple pattern.

Wrapping ?article schema:about ?item into SELECT helps . -- Luitzen (talk) 13:02, 15 February 2019 (UTC)

Oops, the problem was that ?item is not always bound. One should add FILTER(BOUND(?item)). -- Luitzen (talk) 12:40, 17 February 2019 (UTC)

RfC about semi-protection of some Items based on usage

I just opened Wikidata:Requests for comment/semi-protection to prevent vandalism on most used Items. This RfC aims to compile the community's position on using semi-protection as a way of preventing vandalism on the most used Items on Wikimedia pages. Thanks in advance for your comments! --abián 13:44, 16 February 2019 (UTC)

Recycle: Real attackers use throw-away accounts. Recycle: "Edit review" (or its dewiki variant) is less work than semi-protect for all involved parties. –84.46.53.251 13:48, 17 February 2019 (UTC)

How should sitelinks be updated when a linked page is moved/deleted?

Hi! I talked to Lydia Pintscher about phab:T143486. She would like to know what the community thinks is best for updating sitelinks in those cases where such an update is currently not possible (because the user's account is blocked on Wikidata, because the account isn't yet created locally, because the user account isn't confirmed on Wikidata and therefore can't edit a semi-protected entity, etc.). What do you think? --abián 16:49, 17 February 2019 (UTC)

  • To avoid disrupting Wikidata, please unprotect any items you protected recently. In the meantime, please go through all items you prematurely protected and update manually links that didn't get updated due to your use of inappropriate page protection. --- Jura 17:08, 17 February 2019 (UTC)
  • Do we have numbers of cases how often sitelink updates after page moves fail due to non-existing local accounts, account blocks, and page protections? For me, this does not appear to be an urgent problem at all. —MisterSynergy (talk) 17:31, 17 February 2019 (UTC)
    • The problem is not primarily the lack of update(s), but the second item that ends up getting created with the new page name. Maybe a review of mergers can help. --- Jura 17:37, 17 February 2019 (UTC)

Help solve the village problem

For place of birth and death we are supposed to add in the most local available entity, even the hospital, when it is known. Place of death and birth require they be an "administrative entity", but when we use an entity labeled a "village" we get an error that it is not an "administrative entity". I made village an "administrative entity" but it was reversed and the editor pointed out that many villages are no longer administrative entities since they have been consolidated into larger townships over the years and no longer legally are administrative entities ... so how best to solve this conundrum? Is the definition of an "administrative entity" loose enough to contain a location that does not not have its own governing body? Or is there another way to solve the downstream error messages? Any thoughts? --RAN (talk) 14:54, 19 February 2019 (UTC)

If this is what people are doing I expect the best solution is to fix the constraint on the properties to require only an instance of a subclass of geographic location (Q2221906) as the location. ArthurPSmith (talk) 15:34, 19 February 2019 (UTC)
What are the exact constraints that cause problems? Because both place of birth (P19) and place of death (P20) don't have an "administrative entity" constraint. --Pasleim (talk) 15:41, 19 February 2019 (UTC)
Best solution appears to be using "village in the United States" instead of village, it eliminates the error messages downstream. Thanks all. --RAN (talk) 16:05, 19 February 2019 (UTC)
Which, um, only works in the United States, but also: assuming you mean village (Q751708), that is specific to an incorporated municipal entity that has the legal status of a "village" in some U.S. state. It has to do with how the municipality is organized, not (for example) its size. New York State has "villages" with over 50,000 people and "cities" less than half that size. - Jmabel (talk) 16:33, 19 February 2019 (UTC)
@Richard Arthur Norton (1958- ): where does « Place of death and birth require they be an "administrative entity" » come from? And what « error messages » are you talking about? (as Pasleim said there is apparently no constraint) Cheers, VIGNERON (talk) 18:30, 19 February 2019 (UTC)
Sorry, my fault! I conflated two issues, the problem was for cemetery location, not birth and death location. The US village trick worked and I corrected all instances I could find. --RAN (talk) 20:29, 22 February 2019 (UTC)
This section was archived on a request by: Ghouston (talk) 23:04, 23 February 2019 (UTC)

partner (P451)

Should we ever use Property:P451 to mean a business partner? Most times we have things like Abbott and Costello (Q23679) where people are long term business partners. What if people are paired up for a less notable/long standing relationships that do not have an entry, say Ginger Rogers and Fred Astaire? Could they be marked as partners without creating a combined entry? --RAN (talk) 20:23, 22 February 2019 (UTC)

For "business partner" clearly not, unmarried partner (P451) is for love partner (qv. the aliases). For Rogers and Astaire, AFAIK the romance was only on screen, I'm not sure unmarried partner (P451) is appropriate (and there is already Fred Astaire and Ginger Rogers (Q5494490)). Cheers, VIGNERON (talk) 20:50, 22 February 2019 (UTC)
So should we create a property Business partner/Event partner or always create the event. Lets say two pilots set a record crossing the Atlantic together. I can add one as the "event partner" to the other or create "1920 Atlantic crossing by air". Another example would be a two person relay race that won an award. Which is best? --RAN (talk) 22:12, 22 February 2019 (UTC)
Not sure, both solutions have pros and cons but I guess a new property is maybe a bit better because, it's not always appropriate or meaningful to create a third event item. Plus, property proposal goes through a discussion so more people can weigh in to reach a stronger consensus. Cheers, VIGNERON (talk) 23:14, 22 February 2019 (UTC)
Use partner in business or sport (P1327). Sjoerd de Bruin (talk) 23:16, 22 February 2019 (UTC)
Exactly what I was looking for, thank you!  – The preceding unsigned comment was added by Richard Arthur Norton (1958- ) (talk • contribs).
This section was archived on a request by: Ghouston (talk) 23:05, 23 February 2019 (UTC)

Expanding what a property can be used on?

I opened a discussion on Wikidata talk:WikiProject Video games but didn't get a response, so I figured I'd ask here. How does one go about expanding the types of Wikidata items a property can be used to cover? I'd like to expand PCGamingWiki ID (P6337) to include game engines, game series', and companies. How should I propose that? Should these be under the same property or should they be new properties?

Thanks, Nicereddy (talk)

In general, is there some consensus/guideline on whether it is better to have “wide” or “narrow” properties? To stay in the topic of video games, sometimes we have several narrow properties for one source website (eg 4 properties for Linux Game Database (Q56462477) or GameFAQs (Q693757), 5 for MobyGames (Q612975)…), sometimes one wide property for one source website (Giant Bomb ID (P5247) covers 10 different concepts, Metacritic ID (P1712) 5 concepts…)
Some of the downsides of “wide” properties, in my view, are harder to make and less-actionable property constraints (having tried to clean-up P5247 constraint violations, it’s a bit of a pain ^_^), but I guess that’s not necessarily a good argument. The downside of narrow properties is a proliferation of properties, but I wonder how frowned-upon that actually is (or the opposite).
Has there been previous discussions on that topic?
Jean-Fred (talk) 08:46, 8 February 2019 (UTC)
I guess the problems with constraints for Giant Bomb ID (P5247) might be because of me to quite some extent, since I've been adding lots of IDs from Giant Bomb while working my way through various franchises, including characters, locations, concepts and objects. The latter two categories include such a vast array of topics that it's probably very difficult to come up with fitting class constraints.
In general, I think in the past, properties were often created with a broader scope (like IMDb ID (P345) for films, people, companies and characters). But more recently, creating separate properties for the same external source instead seems to be preferred. Depends of course on how the source is structured, sometimes it's unfeasible or doesn't provide an advantage. I think it's most often done when there's no real ID and a part of the URL is used instead. When it's the same kind of ID with the same formatter URL for all types of topics, then usually only one property is used. With Giant Bomb ID (P5247) and its cousin Comic Vine ID (P5905), only two digits in the ID differ for different types of topics (character, work, person, etc.), while the formatter URL is the same. So in theory you could separate them into a handful of distinct properties (games, franchises, companies, people, characters, locations, concepts and objects). But maybe complex constraint might also do the trick instead. --Kam Solusar (talk) 22:19, 11 February 2019 (UTC)
@Kam Solusar: For PCGamingWiki specifically the URLs are all https://pcgamingwiki.com/wiki/$1, where $1 is “Half-Life” or “Series:Half-Life”, or “Company:Valve”. So series, companies, and engines have different but similar URLs. Would you say that’d fit better as a generic property or various specific properties? Nicereddy (talk)
@Nicereddy:: Personally, I lean a bit towards creating separate properties - even though there's no strict technical need for it. Something else worth considering: PCGamingWiki uses MediaWiki (Q83), just like Wikipedia, which means every page has a stable Page ID: Half-Life (Q279744) → 467. That ID doesn't change when a page is moved/renamed, so it would require less maintenance. --Kam Solusar (talk) 09:25, 14 February 2019 (UTC)
@Kam Solusar: I think there's an argument to be made for ease of adding the PCGW ID to a Wikidata item. Similarly, I'm fairly certain Archive.org only keeps the page at the full-name URL rather than the MediaWiki ID, so there's also that downside to consider. Ideally it'd be a perfectly stable ID, but I'm not sure the benefits outweigh the drawbacks.
Regarding the separate IDs/monolith ID, it seems like there's not a solid consensus on this. I lean toward a monolithic ID just because that'd be easier to get started with than needing to open 3 new property proposals, plus the IDs are similar enough that it shouldn't matter RE: URL formatting, although it would have the downside of requiring the user to add, e.g. "Company:" at the start of every company ID. Nicereddy (talk) 20:02, 15 February 2019 (UTC)
I’d lean towards having 3 additional properties as well ; but I can go either way.
Regarding MediaWiki IDs: when creating Wikidata:Property_proposal/RegiowikiAT_ID, I had a look through all MediaWiki-powered properties, and using the Page title was the most common case.
Jean-Fred (talk) 20:19, 17 February 2019 (UTC)

Bot changing precise date of death with death year because it is better referenced

@Anders-sandholm: Can someone look at this edit and then check to see if the bot is doing this more often. It appears to be changing overwriting a precise date_of_death with a less precise year of death because the year alone has more references. The edit summary seems to say it is adding a more precise date, but it is adding a less precise date. I have restored the more precise date in the most current edit. --RAN (talk) 16:58, 16 February 2019 (UTC)

  • Also, shouldn't we be able to have multiple citations for the (less precise) year as well as having a citation for the (precise) day? - Jmabel (talk) 17:27, 16 February 2019 (UTC)
  • The bot previously did this date refinement from year to day precision in the same item, but concerns were raised and the operator was asked to undo the edits (see topics on User talk:Anders-sandholm). Problem was that (some of) the references provided for the year-precision statement do not support the day-precision date, so a refinement seems inappropriate. You should not undo the bot's edit, but add another, second statement with the day-precision date instead. —MisterSynergy (talk) 20:21, 16 February 2019 (UTC)
When I asked previously, I was told not to keep the year-only date. Keep dates that conflict, but eliminate the year-only date. VIAF and LCCN only use years of birth and years of death, so we would have to populate EVERY person with the year-only date. What purpose would that serve? It gives the appearance that there is some question as to the correct date. Why add the year-only to say George Washington (Q23) --RAN (talk) 21:19, 16 February 2019 (UTC)
You can additionally prefer the more precise date with ranks, assuming you have high confidence in the value (maybe supported by a reference). We do not collect "the one and only correct value"; we map values found in various sources, and if they differ, there are multiple statements to be stored in the item for the different values. Ranks can to a sufficient extent control which values are visible to data users, as they can request "best rank" values (which is kind of the default behavior), all non-deprecated values, or all values. —MisterSynergy (talk) 21:39, 16 February 2019 (UTC)
We could do the same for a lot of facts ... where someone is born in Manhattan, we can import New York City and even New York state or even USA. --RAN (talk) 23:12, 16 February 2019 (UTC)
  • Again that goes back to actual practices and the example of George Washington. We have over 1,000,000 records where we can import the year-of-death from VIAF in addition to the exact date-of-death, but we do not. And in this very specific case the reference for the exact date was the American National Biography which was also one of the references for the year-only date. As always, I will abide by whatever rule we decide on globally, but I do not see any utility in adding in imprecision just because we have it. As I said before, when we have two conflicting dates or years, than yes, we need both. And of course we should not be overwriting the precise dates just because they are currently unreferenced or only referenced to Wikipedia, we should be adding in references, not deleting the data. What do others think? --RAN (talk) 22:20, 16 February 2019 (UTC)
Also look at Victor Clarence Vaughan (Q18912741) where both precise and imprecise have the same ranking so that Wikipedia and Wikimedia Commons do not know which one to use where the infobox imports the data. Go to his Commons page and see where it imports both dates. This should have been more thought out before implemented. --RAN (talk) 23:08, 16 February 2019 (UTC)
Dates and precision is very complicated for humans, let alone for bots. You should generally don't use bots to change the precision of dates. Bots should:
  • Add dates (with sources)
  • Add sources to already added date statements
Changing existing dates will just mess up with the sources. About the year versus more precise date problem. Let's take Michael Jackson (Q2831). Date of birth very well documented and sources. Would be a bit weird to add 1958 just because viaf and friends only document the year. Interesting is that GND just shows the year in their web interface, but if you open the raw data, you'll get the full dates. So I guess the only valid situation to remove the year statement is when you have a very well not-contested more precise statement. Multichill (talk) 21:57, 17 February 2019 (UTC)
I agree, and minimally stop overwriting the precise-date with the year-only date ... do we know how many data points were deleted, and can they be restored? I only noticed because one showed up on my watchlist. --RAN (talk) 04:36, 18 February 2019 (UTC)

Restriction problem

In Q1588017#P18, we have a problem. The model of the dulcimer (the instrument depicted) is called Dizzy Signature and because of that it activates this restriction, the restriction thinks that the image is actually a signature. Which is the best solution?

  1. Change the restriction?
  2. Rename the file?
  3. Forget about it and let the issue be?

Thanks in advance, Paucabot (talk) 06:20, 17 February 2019 (UTC)

I added an exception for it on Property:P18. Ghouston (talk) 22:10, 17 February 2019 (UTC)

business vs. enterprise

Can someone please explain to me the difference between 'business' (Q4830453) and 'enterprise' (Q6881511)? While they are described in different words, I cannot think of anything that would be an instance of one but not the other. More often than not, I see Wikidata items that have both statements (e.g. Q1593113), which seems to me redundant. JiriMatejicek (talk) 08:12, 14 February 2019 (UTC)

business (Q4830453) and enterprise (Q6881511). For some reason, business (Q4830453) is stated to be a subclass of company (Q783794), while enterprise (Q6881511) is an organization (Q43229). However, the real issue with merging them would be that some Wikipedias have articles for both. These would need some study. Ghouston (talk) 10:02, 14 February 2019 (UTC)
I'd say sole proprietorship (Q2912172), general partnership (Q646164), and company (Q783794) would all be subclasses of business (Q4830453) / enterprise (Q6881511). Ghouston (talk) 10:12, 14 February 2019 (UTC)
There's a wikiproject related to this - ArthurPSmith (talk) 12:09, 14 February 2019 (UTC)
  Notified participants of WikiProject Companies
Taking from the related articles in de.wiki and en.wiki, business (Q4830453) is defined by the activity of doing business while enterprise (Q6881511) is always a distinct organizational and legal entity. I would assume, that most companies are both, but there are cases, where a business (Q4830453) is not a legal entity and vice versa an enterprise (Q6881511) is not actually doing any business (e.g. shelf company (Q2534287)). --MB-one (talk) 12:20, 14 February 2019 (UTC)
There's actually a separate item for "the activity of doing business", business activity (Q19862406). Ghouston (talk) 21:54, 14 February 2019 (UTC)
I fear this is one of those cases where the concepts described can potentially have slightly different definitions between different languages and don't necessarily always match 100%. Plus there might be languages where no distinction is made between the two, or languages where it gets more complicated. All of which probably got mashed together during the initial creation of Wikidata via interwiki links. Plus we don't know which language users were using when adding these items as statements to other items. With means changes to the item's statements or to the labels/definitions in major languages could result in incorrect statements in other languages. --Kam Solusar (talk)
Reminds me of creative work (Q17537576) vs work (Q386724) vs artificial object (Q16686448): work (Q386724) doesn't even have consistent descriptions in different varieties of English. Ghouston (talk) 22:00, 14 February 2019 (UTC)
I guess a telephone book would not be considered a creative work under US copyright law because it only contains facts, and has no creative input or commentary. It would would be a "work" that is just a compilation of facts, effort went into it, but not creative effort. --RAN (talk) 22:22, 14 February 2019 (UTC)
Yeah, I think that's the main distinction. But we have three items for two concepts. And one of the concepts varies depending on which country's laws you use, at which point in time, so isn't really useful for subclassing from. Ghouston (talk) 22:31, 14 February 2019 (UTC)
Overall I'd say its a mess... Back in the days when I tried to sort things out, business (Q4830453) was a commercial term corresponding to this LoC definition which more or less matches with en:Business or de:Unternehmen. enterprise (Q6881511) used to be for "big companies" (enterprise). company (Q783794) was for the abstract legal concept of an association of natural or juridic persons or forms that are neither but "close enough" (en:Company/de:Personenvereinigung), independent of the concrete legal form in a given jurisdiction. At the moment I don't have time or much incentive to clean it up again, because one would have to start at the Wikipedia articles and clean them up from layman concepts based on a solid outside reference and then, once clean definitions exist, match them up in Wikidata. --S.K. (talk) 06:56, 18 February 2019 (UTC)

Violating DRY

What's the point of this nonsense? en:Don't repeat yourself refers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:21, 15 February 2019 (UTC)

Another example: Wikidata:Property proposal/taxon author citation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 18 February 2019 (UTC)

Works in collection (P6379)

User:KrBot has been busy on my watchlist in the last few days, adding has works in the collection (P6379) statements to lots of artists.

Is this the right thing to be doing? If an artist is known for 40 different works, in 40 different museums, are we going to end up with 40 different P6379 statements?

This seems like a classic case of a one-to-many property, which normally we would try to avoid, usually by instead trying to work with an inverse property that would only have one value (or a handful of values at most) for each item. In this case that might correspond to leaving it to collection (P195) and location (P276) statements on each artwork item to carry the information, then using a query to gather up results for a per-artist report.

Pinging @Hannolans: These edits that KrBot is making, are they what you envisaged when you proposed this property? Jheald (talk) 10:57, 15 February 2019 (UTC)

I tried to stop this, but was a lone dissenter. We need more eyes on property proposals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:33, 15 February 2019 (UTC)
There is no many-to-one connection possible in wikidata, unless we import the works of those creators. This would mean importing all photographs, design, prints, posters, fashion, tableware in wikidata of all archives and museums worldwide. We are talking about huge datasets. Currently we have all paintings in wikidata, but if we want the many-to-one we need a discussion of we should import all collection items of every museum. The need for this property is clear, this is the first time you can query which archive or museum has works of an creator. Our direct use case is to bridge archives and museums to check copyright and licences for photographers. Other use cases are to query 'how many artists are male/female in museum x', which artists in this museum are local, how many artists are from foreign countries. Which local designers have also works in museums in our neighbour country. --Hannolans (talk) 13:09, 15 February 2019 (UTC)
Maybe David can tell us why he supports every proposal without any arguments. Some get appoved with his vote as only interaction. Sjoerd de Bruin (talk) 14:31, 15 February 2019 (UTC)
I support the proposals that I see it useful.We can develop a condition prevents the creation of a property when only one user supports it although the motion was put to a vote for a long time David (talk) 14:42, 15 February 2019 (UTC)
This is a many-to-many, not a one-to-many property, and it was explicitly discussed in the proposal discussion why creating all the individual work items that would allow for many-to-one relations is simply not practical. As to Andy's opposition - if people feel it's important to have "more eyes on property proposals" (this one had more comments and discussion than most - 7 different people in the edit history) it's also important for those who do participate to actually respond to those who try to engage them. Declaring "oppose" without engagement is simply not helpful. I invite anybody to read the proposal discussion and judge for themselves what happened here. ArthurPSmith (talk) 16:00, 15 February 2019 (UTC)
I put some queries on the talk page of the property. Looks like Vincent van Gogh (Q5582) is currently in the most collections for paintings. I added has works in the collection (P6379) for the collections. It's quite a lot, but doable and this is the painter with the most different collections. Others will be less. Multichill (talk) 12:22, 16 February 2019 (UTC)
190 P6379 statements for Van Gogh?? Is this really what we want to do, or useful to anybody? Jheald (talk) 12:49, 16 February 2019 (UTC)
Same as the number of sitelinks to Wikipedia. The item also has 110+ identifier statements. So about the same in the order of magnitude. Quite different than including every work on an artist.
I have a background in computer science so I don't like redundancy. But I'm pragmatic. We have a lot of redundant data to make it easier to work with our data. This property serves a purpose and doesn't break the order of magnitude. That's more important to me than the redundancy. Or do we have another argument against this property? Multichill (talk) 13:11, 16 February 2019 (UTC)
Redundancy between an identifier statement and a collection statement? That's not really the case, since a person can have an identifier at an institution even if they have no works there. E.g., if they are depicted in a work, or they donated something. Ghouston (talk) 22:03, 16 February 2019 (UTC)

Separate entities for pseudonyms, alter ego's

There's been some, well-intentioned I believe, efforts to separate musical artists from their aliases, but unfortunately this has ended up more like duplicates. Aphex Twin and Richard David James is maybe the most glaring example, but there's also Freddie Mercury alias Larry Lurex and quite a few others. Is there a clear policy on this? If separating artistic aliases from "real persons" is something that we want to avoid it would be useful to have a "rule" to point people to, if it's something that's encouraged then a standard way of doing it should maybe be established, so we don't end up with both the alias and the person having instance=human thus counting a two people. Any input appreciated! Moebeus (talk)

If it's simply a pseudonym I don't think it deserves a separate item. But if there are attached attributes - like a fake birth date and location, different nationality, family, gender, etc associated with it then a separate item makes sense to me, as it would otherwise be hard to attach the attributes to just the pseudonym. However, the pseudonymous item should be an instance of person (Q215627) not human (Q5). ArthurPSmith (talk) 17:15, 16 February 2019 (UTC)
@ArthurPSmith: person not human sounds right to me, but the English description for person (Q215627) clearly states "do not use with P31". If there's consensus on this then that should be changed accordingly? EDIT: Could alter ego perhaps work instead of person (Q215627), not having the same restrictions? Moebeus (talk) 12:09, 17 February 2019 (UTC)
Hmm, I guess they want you to be more specific. Q201662 would be fine I expect. ArthurPSmith (talk) 15:07, 18 February 2019 (UTC)

Wrong instance of Q2828703

Hi all, I created a request in Wikipedia [20] to improve my understanding of the item Q2828703 . It seems that the instance of should be changed to metalanguage (Q193983) . How bold should I be here? Thanks for the help. Best regards--Hundsrose (talk) 08:58, 16 February 2019 (UTC)

Be bold. As long as nobody complains, you can assume that your changes are okay, particularly in sparse items such as Q2828703. Otherwise you need to discuss… :-) —MisterSynergy (talk) 07:20, 18 February 2019 (UTC)
Thanks a lot, MisterSynergy! --Hundsrose (talk) 07:30, 18 February 2019 (UTC)

Talk to us about talking

 

(Some translations are available. Please forward this message to your projects, thanks!)

The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.

We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.

We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.

We are currently planning the consultation. We need your help.

  • We need volunteers to help talk to their communities or user groups. You can help by creating a discussion page and hosting a discussion. You can sign up your participant group here.
  • You can also help build the list of the many different ways people talk to each other. Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.

Soon, we will invite you to leave individual feedback about talk pages and other ways that you communicate. Then we will discuss ideas with the group.

You can read more about the overall process on mediawiki.org. If you have questions or ideas, you can leave feedback about the consultation process in the language you prefer.

Thank you! We're looking forward to talking with you. Trizek (WMF) (talk) 14:59, 18 February 2019 (UTC)

Wikidata weekly summary #352

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

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.


Is item Christian Frates (Q47691741) notable enough?

I was searching on query.wikidata.org for

  • medical condition = classic autism
  • occupation = YouTuber

and I got 1 hit:

The wikidata item was created by User:Cwf97 who at their talk page is "Christian Frates". Apparently they are related to Pete Frates with 'type of kinship' 'male first cousin'. Pete Frates is given credit for inspiring the ice bucket challenge. Maybe it's at least somewhat notable? Are family members automatically notable for being related to a famous person? I just want to find wikidata notability standards. What do you make of this? --Btqfshfst (talk) 17:28, 17 February 2019 (UTC)

The author of the IMDb bios used as references (for the cousins) is a "Christian Frates", and as actor/actress they might be good enough. OTOH, the father, mother, and author could be deleted as NN, zero references, zero uses in Wikipedias. –84.46.53.0 05:47, 19 February 2019 (UTC)

Also adding that others had the concern that the user does not reply frequently enough to messages on their talk page. Now I only waited 3 little days, but I waited until the user made more edits to see if any of those edits would address my messages on their talk page. Apparently not and here's another sign of that but on User_talk:Cwf97#Communication_is_required --Btqfshfst (talk) 17:46, 17 February 2019 (UTC)

The use of P31 on Q340003 is creating an error on Commons

The use of P31 on Buridan's ass (Q340003) is creating an error on Commons:Category:Buridan's ass. I don't know how to fix it... AnonMoos (talk) 20:01, 18 February 2019 (UTC)

@AnonMoos: I think this might have already been fixed? Otherwise, can you copy the error here please? Thanks. Mike Peel (talk) 23:08, 18 February 2019 (UTC)

can some one delete or merge this page

Index toe (Q61849577) i created it but there is already a page for it --Plabe (talk) 06:17, 24 February 2019 (UTC)

OK, merged with second toe (Q6673547). Ghouston (talk) 06:50, 24 February 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 19:14, 25 February 2019 (UTC)

Request for merge

Could someone please merge Michalis Kyritsis (Q61794561) and Michalis Kyritsis (Q12881070)? - 108.71.133.201 03:52, 25 February 2019 (UTC)

Done. Rehman 06:19, 25 February 2019 (UTC)
This section was archived on a request by: Matěj Suchánek (talk) 19:14, 25 February 2019 (UTC)

Wikidata:Notability is outdated?

Reading Wikidata:Notability I wonder how up to date is that page and how well does it reflect the current state of wikidata? Most items I've come across don't seem to satisfy the notability requirements(are they requirements or more like guidelines) described on that page. I'm aware that wikidata doesn't want to host every person's data who may want the world to know about them. Though I have seen no wikidata:self-promotion page nor any kind of wikidata:npov page so maybe we can edit data without necessarily needing a neutral point of view or maybe there's nothing against self-promotion. Also btw, I'm in need of a mentor so if you're interested please post on my talk page, I'd be happy to be tutored. Btqfshfst (talk) 12:34, 13 February 2019 (UTC)

Can you give examples of items that don't meet the notability requirements? If that's the case, we just need more people with a broom. Sjoerd de Bruin (talk) 13:02, 13 February 2019 (UTC)
  • @Btqfshfst: In general no you shouldn't create a page about yourself; self-promotion items get routinely deleted. When you look at an item and wonder why it exists, check the sitelinks (generally anything that has a Wikipedia page in any language will have a Wikidata item) and check the "What links here" link, which will tell you if it is being used by other items. Also check the external id's section - many items exist here because they have been described in some authoritative external source, which (in many cases) is sufficient to meet our notability guidelines. ArthurPSmith (talk) 15:51, 13 February 2019 (UTC)
Maybe the policy should explicitly permit items corresponding to existing redirects, that was my excuse for two record labels here. For a third record label it was an existing enwiki draft and a Wikidata ukwiki category in need of a main topic. –84.46.53.230 16:37, 13 February 2019 (UTC)
@84.46.53.230: When you say "items corresponding to existing redirects", are you talking about the case where some concept does not merit a Wikipedia article in itself, but is well-covered in a Wikipedia article about a related concept and so gets redirects to that article? Bovlb (talk) 19:21, 13 February 2019 (UTC)
Not sure where that goes, but it's about Rockwerk Records (Q60609062) for dewiki, RWG Records (Q60492205) for enwiki, and Pendu Sound Recordings (Q61523615) for a draft or for a ukwiki category Category:Pendu Sound Recordings albums (Q32464776). –84.46.53.251 12:52, 17 February 2019 (UTC)
There are 3 main criteria for Wikidata notability, and the linking to any existing article or page in another Wikimedia project is only the first one. A Wikipedia non-notable musician or company can still fulfill criterion 2: It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references. "Serious" is vague, but heck I can probably find local businesses in my own town with enough public data to warrant Wikidata inclusion (websites and business registration records are publicly available). And yes, Wikidata can link to redirected entities, the redirect must simply be broken momentarily to allow synching. This is good, as there are many joint biographies on Wikipedia and other articles that discuss two or more distinct but related entities, but have been merged for Wikipedia-specific matters of style, notability, etc. Wikidata should never dictate how articles on Wikipedia are structured, and the reverse is true. -Animalparty (talk) 23:20, 13 February 2019 (UTC)

In my opinion, yes, notability is outdated if for nothing more than it relies on other site's to tell us that something is notable. While that seems like a good thing, you have to consider their policies. What makes someone notable on site-x, that makes them notable enough for us. For example, if you look at ISNI and VIAF, they admit to wanting to expand their numbers. One of the things they are looking for is to use a musician's Youtube page to help identify them. IMO, that may be good for royalty payments and Top 40 ratings. But should we consider a musician notable because they have an ISNI if all it takes to have an ISNI is a Youtube account? Currently, ISNI and VIAF are not yet using "just the Youtube account" as identification, but they have stated that to be a goal. Lazypub (talk) 13:45, 17 February 2019 (UTC)

Redirects and labels

When a redirect exist, it does not follow that the label for the redirect is appropriate for an item. It has to be the same thing.. Typically, redirects require there own item. Thanks, GerardM (talk) 12:58, 17 February 2019 (UTC)

A good example is the redirect to Heywood Broun for the Heywood Broun Award.. There is nothing in the article on that award.. There is in Wikidata.. GerardM (talk) 13:38, 17 February 2019 (UTC)
Let's see if I grok this: en:Obsession was a redirect to en:Calvin Klein, because that page contained something about the perfume. Then it was split into a pure BLP and a company page, both not mentioning this perfume at all, keeping the redirect as is, i.e., wrong.
Therefore I found a new target, added a sentence about this perfume, wikilinked Calvin Klein + company (IIRC this was already the case), and adjusted the redirect. But this still wouldn't allow me to list the redirect here in a (not existing) "Obsession (perfume)" item, the editor would tell me that the new target en:Heroin chic already exists as Heroin chic (Q389259).
And at that point I'd be lost, is the correct procedure really to disable the redirect for some minutes, add the item as site-link, note the (at this point in time) wiki page here, and re-enable the redirect? It sounds like an interesting kludge, but it also sounds like a missing feature in the editor, and presumably I didn't understand it at all.
Whatever the correct way to handle redirects is, please add a pointer in the notability policy, a {{R printworthy}} on my say so is too obscure (= attack vector for the professional spammers here.) –84.46.53.0 18:55, 19 February 2019 (UTC)

Quickest way to find an item given the value of an external identifier?

Hello, I am not too familiar with the technical side of Wikidata, so I was hoping for some assistance. I have various lists of values for the property UEFA player ID (P2276), so I was wondering what would be the quickest way of finding which item the values I have correspond to?

For example, if I have the following list of IDs: 

250002096
63706
95803
250016833

What would be the quickest way to get the corresponding items (en masse)? (In this example, it would be the following four: Robert Lewandowski (Q151269), Cristiano Ronaldo (Q11571), Lionel Messi (Q615), Harry Kane (Q969725))

Any help would be appreciated. Thanks, S.A. Julio (talk) 06:12, 19 February 2019 (UTC)

The en masse approach would be to use the Query Service like here. It does work with some thousand identifiers in one run, but not with a truly "unlimited" number of course. If you experience timeouts, you might have provided too many identifiers. For individual identifier lookup, you can also use the regular search function of the web interface, using e.g. haswbstatement:P2276=250002096. —MisterSynergy (talk) 06:20, 19 February 2019 (UTC)
Resolver only does one at a time, but it’s very fast for this sort of lookup. - PKM (talk) 07:08, 19 February 2019 (UTC)
Thanks to both of you, exactly what I was looking for! S.A. Julio (talk) 10:13, 19 February 2019 (UTC)
One can also use the search box at the top of the page, and put in a search string like eg haswbstatement:P2276=250002096
This is quite handy if one wants to edit a number of items manually: just right-click on the search result to open the item in a new tab, leaving the search tab unchanged so one can copy the new ID number into the right place in the search string when the time comes to do the next one. Jheald (talk) 19:07, 19 February 2019 (UTC)
Another possibility is to use the Wikidata Hub, e.g. as per https://tools.wmflabs.org/hub/P2276:250002096?site=wikidata. There is also a batch mode, both due to User:Maxlath. --Daniel Mietchen (talk) 01:17, 20 February 2019 (UTC)

Labels with brackets

There are so many labels with brackets, f. e. in Five Brides (Q4386089): nl = Pjat nevest (film, 2011) or ru = Пять невест (фильм, 2011). How can we transform them into valid labels, is there a workflow for that? Queryzo (talk) 23:51, 8 February 2019 (UTC)

@Queryzo: quick answer. The workflow is simple: find them and remove them. To find them, you can use any tool like the Wikidata Query Service (query of all films with a label in English ending with a bracket) or more broadly Quarry (list of all labels in English ending with a bracket). Then you can remove the brackets on this list (you can use with any tool you want; I use LibreOffice Calc, it works fine), you check the correction (in some rare case, brackets are correct, see ( ) (Q4544935) for example) and finally you import these corrected label back on Wikidata (again, with any tool you want, I use QuickStatements). Cdlt, VIGNERON (talk) 10:46, 9 February 2019 (UTC)
yes, I know these tools, but in fact this is a general problem. I thought this might be included into a bot routine or sth. Queryzo (talk) 12:59, 9 February 2019 (UTC)
Just a point about these: brackets should not be removed from labels of category items. Thank you very much, --Epìdosis 13:07, 9 February 2019 (UTC)
I usually recommend removing it AND adding a description. Because presence of such a label means there's a need to disambiguate. Matěj Suchánek (talk) 19:34, 9 February 2019 (UTC)
The problem is that not all the brackets must be deleted, ex. (Pronounced 'Lĕh-'nérd 'Skin-'nérd) (Q276827) or Snow (Hey Oh) (Q2068337). On it.wiki we have a template used to mark pages that need brackets: what's link --ValterVB (talk) 08:43, 10 February 2019 (UTC)
Indeed, but we have Module:WLink (Q19363224) and function getArticleBase() retrieving generic page title, with no fragment nor brackets. Adapted to the given wikilink it could be compared with the current label set. This would be great within a bot routine. Queryzo (talk) 10:19, 15 February 2019 (UTC)
There are also category labels like Substantiv (Deutsch) or Substantiv (Englisch) from de.wikt, which renamed causes many problems without exact description. JAn Dudík (talk) 09:48, 20 February 2019 (UTC)

How to handle cultural heritage monument in Germany (Q11691318) like An der Läuterau 23 (Q18643398) if there is only the Streetname (no real name) to identify the object? I added the village of the Street, because there can be many different items with same streetname. Would it be better like An der Läuterau 39 (Q18644966)? Regards, Conny (talk) 14:21, 20 February 2019 (UTC).

fictional human vs fictionalized human

fictional human (Q15632617) and historical character (Q3375731) seem very similar to me, surely the latter could just be represented by instances of the former with a property such as fictional or mythical analog of (P1074) or inspired by (P941) to link to the real human (Q5)?

In any case, is there an obvious way to solve the distinct values constraint on the fictional analogue property for these two items? --SilentSpike (talk) 19:27, 19 February 2019 (UTC)

  Notified participants of WikiProject Fictional universes

The sitelinks on historical character (Q3375731) would need to be checked: from the titles they look more specific than "fictional human". historical character (Q3375731) isn't currently used in Wikidata statements, but could be made a subclass of fictional human (Q15632617). Ghouston (talk) 19:56, 19 February 2019 (UTC)
@Ghouston: yes, but the other way around (the links where here before), I left a message to find a better label in English on Talk:Q3375731. That said, it doesn't change the core of the problem pointed by SilentSpike. On that, I'm not sure but I guess not using this value in instance of (P31) would be way better. Cdlt, VIGNERON (talk) 20:18, 19 February 2019 (UTC)
There is also human whose existence is disputed (Q21070568).
I think it's difficult to pin down a fictional "version" of a real human (that is, a fictional character based on a real human). Abraham Lincoln Vampire Hunter is obviously one, but what about the Charlemagne of the medieval romances? Perhaps we could eliminate this altogether by using "fictional human" <based on> "real human"? I don't know the best answer. but it's currently very fuzzy.
See Urien Rheged (Q1263208) and Uriens (Q43401974). - PKM (talk) 21:23, 19 February 2019 (UTC)
There is the possibility of using inspired by (P941), as done at Antonie Buddenbrook (Q42324811) and there is fictional or mythical analog of (P1074), as used at Christopher Robin (Q1190911). based on (P144) does not seem appropriate to me as, according to the property proposal and its English description, it should be used to indicate the works used as a basis for another work (especially for derivative works and adaptations) and humans are not works, characters inspired by them or meant to represent them not really adaptations of them. If a fictional character should be based on a particular biography (Q36279) of a human one could use based on (P144) to indicate this work as source of the character. - Valentina.Anitnelav (talk) 22:10, 19 February 2019 (UTC)
To solve the distinct values contraint issue one could add them as exceptions to the constraint (what I did). The better solution would be to add of (P642) as a qualifier and restrict this statement to a certain area (e.g. myth (Q1213296) vs. fiction (Q8253) (see fictional horse (Q2962925)/mythological horse (Q24296329)) or the work in which a character appears as a fictional analogon of a human). But I could not think of a good value to use in this case. - Valentina.Anitnelav (talk) 09:03, 20 February 2019 (UTC)

ready steady girls stopped by spam filter

I wonder if readysteadygirls.eu - a pretty good blog on European female 1960s pop singers imo - is stopped by the spam filter for actual abuse, or if it's caught by some "suspected porn" heuristic based on the domain name? Not a huge deal, but personally/anecdotally I've found this to be a well-kept and information dense website dedicated to female musicians. Moebeus (talk) 18:25, 18 February 2019 (UTC)

The global spam filters are on Meta. One of these spam filters not allowing me to link the official MediaWikiWiki custom search engine on my Commons talk page was the reason to kill all my talk and user pages on c: d: de: en: m: mw: within ten minutes three years ago.
Apart from admin abuse (real or imagined) the spam and edit filters are presumably among the top five reasons to leave anything WikiMedia for good and ever. I'm actually surprised that WikiMedia still exists. –84.46.53.0 06:04, 19 February 2019 (UTC)
I can see you pay no attention to it at all. - Jmabel (talk) 06:36, 19 February 2019 (UTC)
I don't see what your it is, but if you are talking about fixing global abuse filters this can take hours, you have to find them in the edit history to figure out why they were added in the first place, this requires bisection (was it 2011..2019 or 2002..2010 etc.), and an argument why an unclear decision over a decade ago (or whatever, newer additions have better reasons) might be not more state of the art in 2019. –84.46.53.0 18:27, 19 February 2019 (UTC)
According to WikiBlame, it was added to the blacklist in this change in 2008 by A. B. (talk • contribs • logs). It looks like that editor is no longer an administrator on that project. You may want to raise your question on meta:Talk:Spam_blacklist . Bovlb (talk) 21:26, 19 February 2019 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Let me clarify for the irony-impaired. 84.46.53.0 remarked to the effect that there were all sorts of reasons to leave Wikimedia, and expressed surprise that it still exists… and is apparently closely following this discussion and participating in it. That is what I was remarking. - Jmabel (talk) 22:24, 19 February 2019 (UTC)

For clarity, my response was intended to be helpful to @Moebeus:. I was ignoring both 84.46.53.0 and Jmabel. Bovlb (talk) 00:10, 20 February 2019 (UTC)
@Bovlb: Very useful, thanks! I posted a question on there, I'll see if it goes anywhere. btw there was a line saying #temp in the diff you linked to, after 11 years on the blacklist I take it that doesn't mean the ban was supposed to be temporary? Moebeus (talk) 00:12, 20 February 2019 (UTC)
@Moebeus: Looks like it might well have been meant to be temporary - it was blacklisted because someone was apparently spamming it on enwiki and dewiki. I guess it was never taken off again after the problem went away. Andrew Gray (talk) 23:23, 20 February 2019 (UTC)
m:Talk:Spam_blacklist#readysteadygirls.eu. –84.46.52.182 14:17, 21 February 2019 (UTC)

Talk to us about talking

 

The Wikimedia Foundation is planning a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.

We want all contributors to be able to talk to each other on the wikis, whatever their experience, their skills or their devices.

We are looking for input from as many different parts of the Wikimedia community as possible. It will come from multiple projects, in multiple languages, and with multiple perspectives.

We are currently planning the consultation. We need your help.

We need volunteers to help talk to their communities or user groups.

You can help by hosting a discussion at your wiki. Here's what to do:

  1. First, sign up your group here.
  2. Next, create a page (or a section on a Village pump, or an e-mail thread – whatever is natural for your group) to collect information from other people in your group. This is not a vote or decision-making discussion: we are just collecting feedback.
  3. Then ask people what they think about communication processes. We want to hear stories and other information about how people communicate with each other on and off wiki. Please consider asking these five questions:
    1. When you want to discuss a topic with your community, what tools work for you, and what problems block you?
    2. What about talk pages works for newcomers, and what blocks them?
    3. What do others struggle with in your community about talk pages?
    4. What do you wish you could do on talk pages, but can't due to the technical limitations?
    5. What are the important aspects of a "wiki discussion"?
  4. Finally, please go to Talk pages consultation 2019 on Mediawiki.org and report what you learned from your group. Please include links if the discussion is available to the public.

You can also help build the list of the many different ways people talk to each other.

Not all groups active on wikis or around wikis use the same way to discuss things: it can happen on wiki, on social networks, through external tools... Tell us how your group communicates.

You can read more about the overall process on mediawiki.org. If you have questions or ideas, you can leave feedback about the consultation process in the language you prefer.

Thank you! We're looking forward to talking with you.

Trizek (WMF) 15:01, 21 February 2019 (UTC)

Link to OSM in Tools section of an item page

On the left of the item page, in the "Tools" section, one could introduce a "This item in OpenStreetMap" link. This link could e.g. point to https://overpass-turbo.eu?Q=nwr[wikidata=Q1556]. What is the best way to implement such an idea? --Saerdnaer (talk) 22:26, 22 February 2019 (UTC)

Hi @Saerdnaer: this idea already exists : User:Abbe98/osm.js (just add it to your common.js, like on my User:VIGNERON/common.js). Cdlt, VIGNERON (talk) 23:10, 22 February 2019 (UTC)
How to make this a default add-on? --Saerdnaer (talk) 11:16, 23 February 2019 (UTC)

실내 경기장 = indoor arena = multi-purpose hall?

Could someone who knows Korean have a look at Q27951514 (multi-purpose hall/indoor arena) and Q1763828 (indoor arena / 실내 경기장) to see if they're maybe the same and should be merged? Moebeus (talk) 00:01, 23 February 2019 (UTC)

Talk pages consultation 2019

The Wikimedia Foundation has invited the various Wikimedia communities, including Wikidata, to participate in a consultation on improving communication methods within the Wikimedia projects. As such, a request for comment has been created at Wikidata:Requests for comment/Talk pages consultation 2019. All users are invited to express their views and to add new topics for discussion. (To keep discussion in one place, please don't reply to this comment.) Jc86035 (talk) 15:42, 23 February 2019 (UTC)

Migration and settlement?

Is there a way to add someone's migration to and settlement in a particular place? thanks again MassiveEartha (talk) 20:09, 23 February 2019 (UTC)

residence (P551) with start and end qualifiers. Ghouston (talk) 22:28, 23 February 2019 (UTC)

Q5453356

How is this a film?--115.27.198.88 01:35, 24 February 2019 (UTC)

Fixed. Thanks for bringing it up. Rehman 02:40, 24 February 2019 (UTC)
The mix-up might be explained by this line from en:Wiki "First Motion Picture Unit is also the eponymous title of a 1943 self-produced documentary about the unit narrated by radio and television announcer Ken Carpenter" Moebeus (talk) 02:55, 24 February 2019 (UTC)

The curious an entangled case of Stanisław Krzyżanowski (Q9342386)

It seems that the item of Stanisław Krzyżanowski (Q9342386) is comprised of two completely different persons.

I suppose the solution would be to create a new item for the former and remove false info from the latter, fixing interwiki links in the process. Is it OK ? 09:45, 23 February 2019 (UTC)  – The preceding unsigned comment was added by Kpjas (talk • contribs).

Yes, create a new item if you can't find one already existing. Ghouston (talk) 22:31, 23 February 2019 (UTC)
@Kpjas:, in this case, as is not unusual, there were originally two items but User:DavidMar86hdf merged them on 2015-12-25. Originally, Q9342386 corresponded to pl:Stanisław Krzyżanowski (1865-1917), and Q16059330 corresponded to en:Stanisław Krzyżanowski. Instead of creating a new item, Q16059330 can be reverted to the point before it was merged. Ghouston (talk) 23:26, 23 February 2019 (UTC)
@Ghouston: thanks for the detective work :-) Kpjas (talk) 08:06, 24 February 2019 (UTC)

Specific power station related properties

Hi. Anyone have any clue as to how to add data for specific types of power stations? For example, how to add the below information in geothermal power station items:

  1. Power plant minimum geothermal temperature requirement
  2. Number of geothermal wells
  3. Maximum depth of geothermal wells
  4. Geothermal hot water production

I've been trying to figure this out for many months without luck. Hence any help is very much appreciated :) Rehman 14:31, 23 February 2019 (UTC)

@Rehman: First could be operating temperature (P5066) with qualifiers (if it's the same as the minimum operational temperature); second could be has part(s) (P527) with quantity (P1114) qualifier. I don't know about the other two. I've never edited these items before so you should probably wait for a third opinion. Jc86035 (talk) 15:46, 23 February 2019 (UTC)
Thanks Jc86035. I went ahead and added the first two at Nesjavellir Power Station (Q693330), but the first generates an error. Will wait for more opinions on 3 and 4. Cheers, Rehman 02:34, 24 February 2019 (UTC)

I have moved this discussion to Wikidata_talk:WikiProject_Energy#Discussions:_Geothermal_power_stations. Please join the discussion if you are familiar with property usages. Any and all help is welcomed! Rehman 13:07, 24 February 2019 (UTC)

Indigenous place names

Is there a convention on how to add an the indigneous name of the place if it's in a language not supported by Wikimedia? Thanks! MassiveEartha (talk) 20:07, 23 February 2019 (UTC)

@MassiveEartha: If you're referring to using non-supported languages for properties such as name in native language (P1559), and if the indigenous language has an ISO 639-3 code, then you can request that it be added to Wikidata on Phabricator by creating a task for it. Here's an example of such a task. Mahir256 (talk) 06:59, 24 February 2019 (UTC)

Wikidata, Txikipedia and Vikidia

Hello! This was discussed in 2016, but there have been some changes since then. In Basque Wikipedia we have developed Txikipedia, the Encyclopedia version for 8-12 years old. Currently we have more than 1.400 articles but this can't be linked in a logical way to Wikidata. They describe exactly the same thing as the Wikipedia item, but we can't get directly the data from Wikidata, as the item's Q is not the same. Also, there are some external websites with the same goal: Vikidia, Klexikon, Wikikids... linking all this information could be a great way to make our projects more interesting for different ages. There are some other languages that have contacted us in the euwiki to analyze how Txikipedia was built, and this issue could afect more languages in the future. I don't have a solution, but I would be interesting in having some comments about how to link this items. Thanks. -Theklan (talk) 15:43, 10 February 2019 (UTC)

It sounds similar to simple Wikipedia that has it's own namespace. I think the way to go would be to write an RfC on WikiMedia that strips langcom from being able to withhold namespaces from projects like this. ChristianKl ❪✉❫ 18:08, 10 February 2019 (UTC)
Would a property for "topic in children's online encyclopedia" be appropriate? That way, any url (regardless of if it's a namespace of an established Wikipedia edition (as is the case for Txikipedia([21]), or a separate wiki (as is the case with Vikidia([22]), or potentially a non-wiki website, could all be added as different statements to the same property to the relevant item. With a qualifier for language. Wittylama (talk) 18:25, 10 February 2019 (UTC)
@Wittylama: Interesting idea... that would give the possibility to add automatically something like the interwiki links with the language code in it. I don't think it would be possible to add to the proper interwiki page, isn't it? -Theklan (talk) 18:54, 10 February 2019 (UTC)
@ChristianKl: the language committee does not involve itself in namespaces like this. It is not its remit. What is its remit is the creation of new projects, the use of standards to identify language content. Content in the same language is the same language. When a new project is suggested for the same language, the requirements are in localisation of the software and continued activity in the specific area. The last time this was considered was for Hindi Wikisource. Thanks, ~~
You can create a separate item and link it from there. The separate item can be linked to the main item with the "permanent duplicate" property. --- Jura 19:23, 10 February 2019 (UTC)
@Jura1: But that solution wouldn't create a Txikipedia item with links to Vikidia, isn't it? -Theklan (talk) 19:49, 10 February 2019 (UTC)
Indirectly, it would. --- Jura 19:50, 10 February 2019 (UTC)
@Jura1: Want to learn more about this solution. -Theklan (talk) 20:09, 10 February 2019 (UTC)

I have been thinking on the proposed solutions and noted that none of them would give access to the information stored in Wikidata. -Theklan (talk) 13:22, 11 February 2019 (UTC)

@Theklan: Why wouldn't a namespace that works analogous to :simple: provide access to information stored in Wikidata? ChristianKl ❪✉❫ 16:01, 12 February 2019 (UTC)
@ChristianK1: Because a namespace inside Wikipedia is not technically the same as :simple:. Simple has interwikis in the left, but Txikipedia doesn't. -Theklan (talk) 08:07, 13 February 2019 (UTC)
I use the term namespace to refer to what :simple: is. :simple: is technically a namespace. If Txikipedia would get a namespace in the same form as :simple: that would allow it to be easily integrated with Wikidata. ChristianKl ❪✉❫ 09:57, 15 February 2019 (UTC)
@Jura1: No, look at the interwikis it has now. They are not links to children Encyclopedias. Is not a duplicated item, is an item in another format. -Theklan (talk) 08:07, 13 February 2019 (UTC)
@Jura1: I would like to have interwikis to other projects (Vikidia, Klexikon, Wikimini, Wikikids...) and also benefit of Wikidata items information. So if I add an article about, let's say, London, I can get the population and coordinates directly from Wikidata. They are two different problems, but we can give a global solution to both. -Theklan (talk) 09:44, 21 February 2019 (UTC)

Hello, as the Klexikon was mentioned, I have a different problem. I am not interested in interwiki links - children usually do not look something up in other languages. But I would like to see infoboxes filled with Wikidata content in our articles... how would we do that? Ziko (talk) 20:01, 20 February 2019 (UTC)

@Ziko: I think that the best solution could be having something like the sister-projects section to fill. We have a section called "Other sites" where normally appears Commons and Meta. We could add there Txikipedia, Klexikon, Vikidia and other children encyclopedias as long as they share some common aspects with our projects: they are free and anyone can edit. -Theklan (talk) 09:43, 21 February 2019 (UTC)
@Jura1: I don't understand how a Txikipedia item could have an interwiki to Vikidia with this system. -Theklan (talk) 10:10, 25 February 2019 (UTC)

Arab League members

Today Arab League (Q7172) was in the news, a league of nations. I wonder why only the currencies of member states are listed, not the members themselves.

  1. Is it correct to add member states with "has part"?
  2. How would suspended members Syria and Libya be tagged?
  3. Would founding state Transjordan be added as a member with both start and end time and successor state Jordan as a current member only with a start time?
  4. Can states with observer state be added as "part of" with qualifier "subject has role" "observer status"?
  5. Would the rank of Transjordan and observer states be lowered to easily get a list of "real" current members?
  6. Property "part of" "Jewish refugee from Arab and Muslim countries" confuses me. Does anyone understand this?

--37.201.30.22 19:28, 24 February 2019 (UTC)

(Partial answer.)
  1. No. The member states should be added using member of (P463) on their respective items.
  2. Using qualifiers on the member of (P463) statements.
--Yair rand (talk) 20:08, 24 February 2019 (UTC)

Actual number V display

I am looking at P3087 fiscal/tax revenue. As money, it has eg 9 or more digits, plus 2 pence. But I just want it as millions. So for instance, amount is 181,608,793.67 but what I want is '181.6 millions', i.e. four significant digits, including one decimal place. Would that be a qualifier? That would be a divider plus text?

I would want eg (round down (value / 1000000) 1 decimal) Talk about confusing (talk) 04:18, 25 February 2019 (UTC)

Where do you want it as millions? Matěj Suchánek (talk) 13:06, 25 February 2019 (UTC)

Wikidata weekly summary #353

 
Here's your quick overview of what has been happening around Wikidata over the last week.
  • Development
    • Updated some icons with the new WikimediaUI icon set (phab:T209259)
    • Fixed an issue that was causing occasional failures when creating new Items (phab:T194299)
    • Investigated Wikidata Tours not loading correctly (phab:T215919)
    • Adjusted spacing between Sense ID, bar and Gloss (phab:T215502)
    • Fixing a long time issue with introducing new data types in production (phab:T216728)
    • Fixing docs for backup of wikibase container images (phab:T214941)
    • Making undo, rollback and restore work on schema content pages (phab:T214399)
    • Improving edit summaries for schema content pages (phab:T213724)
    • Tightening up the process for editing "identifying information" for Schemas (phab:T214466)

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.

Duplicate entry and wrong Wikipedia link

I would've done it myself but I am unsure on how to approach this. The item Kota Bharu (Q49278627) is for Kota Bharu (the capital of Kelantan) which is a duplicate of Kota Bharu (Q651131). But item Kota Bharu (Q49278627) already has a Cebuano Wikipedia entry while the Cebuano entry in Kota Bharu (Q651131) refers to the district in which the capital is situated. The district itself already has an entry at Kota Bharu District (Q12688353). — Jeluang Terluang (talk) 10:47, 25 February 2019 (UTC)

Done. Is this what you wanted? Rehman 10:53, 25 February 2019 (UTC)
Cebu imported geonames strike again and again! --RAN (talk) 01:44, 26 February 2019 (UTC)

Can we Please introduce nl-BE for Belgian Dutch?

There's really having differents between Belgian and Netherlands Dutches, so we the Belgian really wanna See nl-BE instead of only nl. --117.14.250.93 01:20, 26 February 2019 (UTC)

I suppose "nl" should be interpreted as Standard Dutch (Q36423). There are a whole range of dialects, apart from Flemish (Q34147) there's Zeelandic (Q237409), West Flemish (Q100103), Hollandic (Q512444) etc., although I'm not clear how much these would be reflected in Wikidata labels, or how enthusiastically they'd be used. Ghouston (talk) 20:00, 26 February 2019 (UTC)
There seems to be some enthusiasm, since some have their own Wikipedias: Zeelandic (Q237409) is at [23] (zea), West Flemish (Q100103) is at [24] (vis), Limburgish (Q102172) is at [25] (li), there are probably others. But if there are four main dialects of Dutch in Belgium, including vis and li, what does nl-BE mean? Ghouston (talk) 01:22, 27 February 2019 (UTC)
  Support There seems to be indeed having differents even between nl-BE and vls, zea... But I will file a request on Phabricator if and only if, you, 117.14.250.93, continue providing linguistic materials to verify these differents. --Liuxinyu970226 (talk) 03:58, 27 February 2019 (UTC)

Properties about cencus

Hello. I was trying to change en:Template:Infobox census (in greek) to fetch data from wikidata. Ok, I know that sometimes there is not a property for each paremeter or a way to get the data for each paramenter. But, I will ask here. Maybe someone knows more thatn me. I used us example 2010 United States Census (Q523716).

I wasn't able to find others properties. Please tell me if those I have found are correct and if we have properties for the others parameter or a way to have that data in wikidata. Xaris333 (talk) 18:24, 24 February 2019 (UTC)

media legend (P2096) could go away later, cf. Properties for deletion. –84.46.52.11 23:54, 27 February 2019 (UTC)

WDQS has fallen behind today?!

If you go to the query service right now you will see the icon in the lower right glowing red, showing the data is out of date. When I've checked it in the last few hours it has varied anywhere from 3 to 6 hours behind. @Lea Lacroix (WMDE): do you know anything about this? ArthurPSmith (talk) 19:20, 26 February 2019 (UTC)

@Smalyshev (WMF): Do you know what's the matter? Mbch331 (talk) 21:21, 26 February 2019 (UTC)
Yes, it's lagged, probably due to spike in query load. Smalyshev (WMF) (talk) 21:53, 26 February 2019 (UTC)
I wonder what caused the spike? It seems to be better today - 6 to 10 minutes delay showing right now. ArthurPSmith (talk) 21:03, 27 February 2019 (UTC)

How much hair-splitting is too much? (individual figure in publication?)

Q32348400 apparently refers to a single figure, 1 of 2 in this a scientific paper (ResearchGate). The only item linking to it is the publication itself. Do we need to keep this and items like it, or should it be merged, or deleted? Animalparty (talk) 05:59, 27 February 2019 (UTC)

I think it must be a mistake, maybe because the figures were placed after the references in the paper and one has been interpreted as a reference. Ghouston (talk) 06:59, 27 February 2019 (UTC)

Names in non-Roman script with romanized equivalent

How does one deal with names (I'm specifically thinking of birth names, but it could be otherwise) where the name is in non-Roman characters, but has a recognized Romanized rendition?

To put some meat on it, I'm looking at Q4389613. The singer Fayray's birthname is, in Kanji, 大橋 美奈子; but that's romanized as Ōhashi Minako. How should that be addressed?

I've put it in as two instances of birth name, but that raises a warning "This property is generally expected to contain only a single value"; so I suspect that's the wrong approach. What is the correct one? TJRC (talk) 18:14, 27 February 2019 (UTC)

Maybe you can put the romanized text as qualifier Revised Hepburn romanization (P2125), and add qualifier name in kana (P1814) as well. Paweł Ziemian (talk) 19:08, 27 February 2019 (UTC)
Thank you! It took me a while to understand, but the example at Q431443 made it click for me. I've revised the Q4389613 item referred to above: [26]. TJRC (talk) 00:17, 28 February 2019 (UTC)

Two items merged but still with different items

(Q2837027) and (Q60819209) are for the same person, and seem to link to the same articles in English and French, should they still have two different Wikidata id numbers? I would prefer to have them shown only under (Q60819209), which is the person's full name. Oaktree b (talk) 02:28, 28 February 2019 (UTC)

Oaktree b: Duplicated items should be merged. I merged Aline Duval (Q60819209) into Aline Duval (Q2837027) because it was created after the other one. It may have had her full name, but she's better known simply as "Aline Duval". You can learn about merging on Help:Merge. Esteban16 (talk) 02:42, 28 February 2019 (UTC)

standards for indicating uncertainties in dates

Tracked in Phabricator
Task T207705

What is the best way to record undetermined birth/death dates where all we know is a bookend year, e.g. people who are only known to have died after 1930? See for instance Fred W. Wright (Q61714940) and George Frederick Keller (Q50809195). Should we use an integer followed by earliest date (P1319) or sourcing circumstances (P1480), or is there a way to more directly indicate that the integer entered may not be anywhere close to true date? -Animalparty (talk) 18:41, 18 February 2019 (UTC)

I would follow your source, using a combination of the values available for sourcing circumstances (P1480) and refine date (P4241), possibly adding object named as (P1932) to qualify the statement or object stated in reference as (P5997) to qualify the reference. - PKM (talk) 02:46, 19 February 2019 (UTC)
See the Phabricator ticket, linked above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:57, 20 February 2019 (UTC)
refine date (P4241) is good for things like "second half of the century", but for a known "had died before 1930", I'd recommend latest date (P1326) as a qualifier alongside sourcing circumstances (P1480) . Andrew Gray (talk) 22:11, 20 February 2019 (UTC)
A part-way approach that might be interesting could be a WDQS SERVICE that could interpret our present system of values and qualifiers on a date-property, and translate it into an ISO 8601 EDTF value; plus a module for the WDQS UI that could take an ISO 8601 EDTF value and display it appropriately. This could give a way to work round {{phab:T159160}} ("Take account of date precision when displaying dates in WDQS GUI"). @Lucas Werkmeister (WMDE): In some ways this second step would be quite similar to what you did in 2017 to get the WDQS GUI to appropriately display geo:wktLiteral objects, even though the Wikidata RDF doesn't natively have any values that are geo:wktLiteral objects. Making this a type that Blazegraph understands, and that strings can be promoted into using SDRT(), turns out to be quite useful, enabling queries like tinyurl.com/y482fmsz. Would there be any chance of doing something quite similar for ISO 8601 EDTF type values? Jheald (talk) 23:12, 20 February 2019 (UTC)
@Animalparty: It's not that complicated as it might seem from comments above, current system isn't perfect, but it can well express what you want. They way you've modeled it is more or less fine, I've only adjusted the precision to make the mainsnak also valid by itself. This is documented at Help:Dates#Inexact dates. The minimum (Q21067468) on George Frederick Keller (Q50809195) was redundant (together with earliest date (P1319)) in my eyes and I've removed it. Cheers, --Marsupium (talk) 12:05, 28 February 2019 (UTC)

I need help on how to link a police operation to a larget event, and how to link those condemned in that police operation

Hi!

I'm starting to structure some of the information about Operation Lava Jato (Q18479704). Operation Lava Jato is the biggest political scandal in Brazil, and the investigations led to imprisonment, inquiries, and judicial trials of important figures in Brazil. I believe that providing structured data about this operation is a good way to visually assess the impact it had on our country. That said, I already had some troubles with Wikidata since I'm not an expert in it.

1. Operation "Juízo Final" (Q25420335) is one of the many investigations done by the Brazilian federal police. How can I properly link it to Operation Lava Jato (Q18479704)? Should I use "part of" or "subclass of"?

2. Nestor Cerveró (Q18278628) is a person that was charged of corruption and money laundering. I already provided data and reference about it. How do I link it to Operation "Juízo Final" (Q25420335)?

3. What property should I use for someone charged of a crime, but not found guilty of? I'm not sure if I'm being clear, but if someone is taken by the police it doesn't mean that they have done the crime they were charged of. They still have to go under trial under a judge to be properly convicted of (P1399). Am I correct? I just want to be sure!

Thanks! Tetizeraz (talk) 15:34, 22 February 2019 (UTC)

On 1., definitely do not use "subclass of" for anything like this. That relation should be reserved for things which are actual "classes", groups of entities (their instances). "part of" seems fine here. Not sure on any of your other questions. ArthurPSmith (talk) 16:35, 22 February 2019 (UTC)
Ad #1: related property (P1659) is rather lame, but might be exactly what you want. –84.46.53.3 22:40, 23 February 2019 (UTC)
@Tetizeraz: 2. I'd use significant event (P793)
3. I found charge (P1595). Infovarius (talk) 12:29, 28 February 2019 (UTC)

Use of coordinate location (P625)

Hi,

Since this property is highly used, I want to point out that I started a discussion Property talk:P625#Perimeter of this property to find out if this property should be restricted to the Earth only or if we can keep using it on other celestial bodies (as allowed by the "coordinate" datatype).

Cheers, VIGNERON (talk) 14:24, 28 February 2019 (UTC)

The discussion pointed to by VIGNERON is wider in scope than indicated. VIGNERON not only suggested using the property to designate a location of a celestial body with a coordinate system centered at the center of the celestial body and fixed to the body, such as a Mars-centered coordinate system to locate Olympus Mons (Q520), but also to use a system centered on a point in space, such as the center of the Sun, to locate an object many light years away from the center of the coordinate system, such as Andromeda (Q2469). Jc3s5h (talk) 16:14, 28 February 2019 (UTC)
Yes indeed, the question I ask could be rephrased as such: what value in the paramater globe are acceptable for P625. Cdlt, VIGNERON (talk) 17:17, 28 February 2019 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2019/02&oldid=1102553375"