Open main menu

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.

Contents

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 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)
  • It seems reasonable to add this. However, I couldn't quite figure out how many items for people were missing it. --- Jura 14:12, 3 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 Alexander (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, Alexander (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 Alexander (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: Ytterlännäs music director (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)
  • Actually, the property shouldn't be used if there is P6 or P35 with the same data. --- Jura 13:38, 3 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 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)

  • Actually, my guess is that someone who has modeled historical buildings/complexes here on Wikidata may be able to do much better than I on Saint Francis Xavier Mission (Q61238391), please feel very free to have at it. - Jmabel (talk) 00:40, 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 software 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 Snapcraft (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

Species items

Some edits by Vanessalozano (talkcontribslogs) 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)
  • Is country of origin (P495) appropriate on taxa? No.
  • Is instance of (P31)invasive species (Q183368) appropriate on taxa? No A taxon by itself cannot have the inherent property of invasive: it is a context-dependent (as well as somewhat subjective) trait held at best by certain members of the taxon (i.e. populations). An invasive species in North America might not be invasive in Africa, and vice versa. It should be removed with prejudice. Animalparty (talk) 05:09, 3 February 2019 (UTC)
    • The answer is in the name surely? Invasive species it is referring to the property of a species (taxon), not a population. Species are still invasive, even if they don't occur in your country. Vanessalozano (talk) 14:25, 4 February 2019 (UTC)
      • Actually, no. It is invasive only where it is not native. It's sort of the flip side of the old joke, "I can't be a foreigner, I'm British!" - Jmabel (talk) 16:24, 4 February 2019 (UTC)
  • Is instance of (P31)plant (Q756) appropriate on taxa? Probably not (but I'm not a Wikidatatician, or whatever you guys call yourselves), taxa should be instance of taxon (Q16521), and perhaps subclass of (P279)plant (Q756). Similar to tiger (Q19939) for animals. (Parenthetically, I note animal (Q729) and plant (Q756) are the same type of entity (a taxonomic Kingdom), but worded differently: the former is worded as the taxonomic rank, the latter as any member of the taxonomic rank. Fix it, nerds). Animalparty (talk) 05:09, 3 February 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 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 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) Nomen ad hoc

  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 TGN ID (P1667), AAT ID (P1014), ULAN ID (P245), CONA 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 of (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 Boobpedia article (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 ID (P5246), RedTube ID (P5540), YouPorn 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 glamour 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 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 Data Base (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?

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

Robert Craig Wallace (Q21545049) was well defined while Q61483178 and 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 Communist Party of China (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 don't have anything authoritative, but I would think parent/subsidiary is the correct relationship. - Jmabel (talk) 23:08, 10 February 2019 (UTC)
  • Instances of library branch (Q11396180) are varied: I noticed "operator", "parent organization" and "part of". Parent/subsidiary seems to require that the subsidiary be an organization itself. Ghouston (talk) 05:44, 11 February 2019 (UTC)
  • library branch (Q11396180) are currently considered organizations thanks to being subclasses of library system (Q28324850), but it doesn't seem right since a library branch isn't a library system. It's also an organization via library (Q7075) which refers to libraries which are organizations, also questionable. Ghouston (talk) 05:48, 11 February 2019 (UTC)
  • You probably shouldn't look at Wikidata subclass relationships too carefully: it will make your head hurt. Anything that's an instance of library (Q7075) needs to be all of a) a collection of books (where a collection is a group of physical objects) b) a GLAM, whatever that means c) a facility, meaning a kind of geographical object, d) a storage, which is a set, i.e., a mathematical object, and e) a cultural institution, which is a type of organization. Ghouston (talk) 05:55, 11 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)