Wikidata:Project chat: Difference between revisions

Content deleted Content added

Inline

Revision as of 22:10, 6 February 2019

Wikidata project chat

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

Start a new discussion

Edit

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 2025/04.

Hippolyte Peragallo (Q21390773) and Hippolyte Peragallo (Q21522800)

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

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).[reply]

Who unsigned here?! --Liuxinyu970226 (talk) 11:29, 31 January 2019 (UTC)[reply]

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)[reply]

Suitability of property "Boobpedia article"

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

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

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

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)[reply]

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)[reply]

+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)[reply]

+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)[reply]

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)[reply]

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)[reply]

Absolutely. Boobpedia's notability standards are (ahem) solely based on bust size. Th. Hon. 15:27, 2 February 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

This is not about censorship or sexuality. This is about respect for the women whose data we collect and the women editors (few as they are) who contribute here. A site that treats women's body parts as objects to be collected should not be available as a named link. Given the wide-ranging nature of that site (any woman in public view who is ample enough), having such an ID is far too open to abuse, even if efforts are made to limit it to professionals.

As far as sexuality is concerned Wikidata already provides links to the major professionally managed sites covering pornography and erotic models: Adult Film Database actor ID (P3351), IAFD female performer ID (P3869), Pornhub star ID (P5246), RedTube ID (P5540), YouPorn performer ID (archived) (P5267). Their coverage is far more explicit than Boobpedia's and provides plenty of flesh in still pictures and in action. They may also provide height, weight, and measurements. What they do not provide is information about their subjects as people. Boobpedia, on the other hand, is not a pornography site in the same way. It is lovingly devoted to ample women with articles as well as images. Some of the material is from Wikipedia (acknowledged in large print at the bottom) and other material is editor provided. @Robin van der Vliet: proposed the ID in good faith because the site provides so much information. As far as I can tell Boobpedia is the only such site that cares enough about its subjects as people to do so. I suggest that the ID be converted to a reference URL (P854) for the occupations erotic photography model (Q3286043) and pornographic actor (Q488111).

Wikidata is a major database, not a hobby site, and we need to mindful of the dignity of both our subjects and the women editors we are trying to attract. An ID link to a site labeled "Boobpedia" has no place here. StarryGrandma (talk) 16:51, 31 January 2019 (UTC)[reply]

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)[reply]

IIRC Pornhub + RedTube + YouPorn belong to one network of related sites, and Pornhub star ID (P5246) should be good enough for methis zoo. After checking Boobpedia for a few other celebs:

At the moment this site appears to be strict about their topic, no slim models (ignoring red links), and up to date with references for what they cover, better than what I'd expect from, say, RedTube or YouPorn. And if they cover any kind of current or former celebrity, then limiting their efforts to "erotic" here is suspicious, cf. NOTCENSORED already mentioned above. OTOH, what does WikiData offer for male celebs, sport / wrestler / actor / model / whatever? Nothing would be also suspicious, or rather, unfair. –84.46.53.94 12:00, 1 February 2019 (UTC)[reply]

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. and 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)[reply]

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)[reply]

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)[reply]
- 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)[reply]
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)[reply]
- 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)[reply]

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)[reply]

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 cluster 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)[reply]

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)[reply]

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)[reply]

The design decision happened in 2013 by Doco. ChristianKl ❪✉❫ 20:09, 30 January 2019 (UTC)[reply]

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)[reply]

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)[reply]

Visualising gene structure 'is part of' relationships as diagram

Hello all,

I'm trying to encode the relationships and references in the two diagrams in w:Gene_structure within Wikidata. I've a few questions:

Am I using the mostly using Property:P361, Property:P31, and Property:P279. Do those seem reasonable?
what're the best ways to visualise the hierarchy (maybe as a tree diagram)?
Is there a good way to indicate which properties only apply to eukaryotes or prokaryotes? (example using 'of' qualifier)

Evolution and evolvability (talk) 10:31, 29 January 2019 (UTC)[reply]

Can you be more specific about where you want to use the diagram to give a better understanding of the needs for it? ChristianKl ❪✉❫ 18:17, 29 January 2019 (UTC)[reply]

@ChristianKl: I'm hoping to show how the key relationships within the diagram can be made machine readable via Wikidata. Something where I could draw a network showing the elements as vertices with properties as edges of different colours, constrained into a directional hierarchy, with vertices coloured based on their Property:P31? E.g. core promoter is part of a promoter, which is a type of regulatory element and part of a gene. Evolution and evolvability (talk) 04:34, 30 January 2019 (UTC)[reply]

@Evolution and evolvability: I’m currently trying some experiments on visualizing taxonomic ranks datas on Wikidata, for example this diagram is an idea of what I’d like to achieve (on principle, not real datas) and some page in which I try to go towards this User:TomT0m/TestRanks on this test page (using a Sparql query to extract the datas. As the discussion on project taxonomy on implementing the model I’d like on ranks data to reach my goal is currently stuck, I’d be happy to reorient my goals to collaborate with you. :) author TomT0m / talk page 08:56, 30 January 2019 (UTC)[reply]

@TomT0m: Very nice! I've had a bit of a play around to come up with that and a couple of other google search suggestions:

GraphvizOnline. How adaptable to you think it might end up being?
Wikidata-graph-builder simple to use, but not quite versatile enough
Wikidata Query Service butchered from something else that Fnielsen wrote because I cant work out the syntax! The depths are wrong though so it doesn't quite work, but I get the impression that it should be possible to do the colour encoding etc.

So none are quite successful, but seem to be getting closer! Evolution and evolvability (talk) 11:14, 30 January 2019 (UTC)[reply]

I've also added a not over at Request_a_query no that I've discovered that page, since it seems a sensible location. Evolution and evolvability (talk) 03:53, 31 January 2019 (UTC)[reply]

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

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

@Howard61313 : Generally speaking, I have to say I think it's good practise to split them up and using "said to be the same as" to interlink where appropriate - same as we do for given names and family names. The reason being there are other items, like (titles of) books, films, band names, night clubs, fashion brands, etc. that might need to be "different from" one language disambiguation page but not the others. Moebeus (talk) 15:57, 29 January 2019 (UTC)[reply]

@Moebeus: These are not the most appropriate examples here, "national police" is not like the name of works or people, but government agencies shared by several countries instead. The example of Q20901295 (Ministry of Foreign Affairs) would be better, which doesn't need to be "different from" other pages although they have different ways to be referred to in different languages, for example, "Außenministerium" (roughly "Ministry of the Exterior" in German) and "Ministério das Relações Exteriores" (roughly "Ministry for Foreign Relations" in Portuguese) are called differently in their respective languages, but they're still the same thing as "Ministry of Foreign Affairs". Instead of "said to be the same as", they're "already the same as".--Howard61313 (talk) 04:02, 30 January 2019 (UTC)[reply]

They are all different items: the french page is a list, all the other page are disambiguation, but all these disambiguation have different spelling so they are different disambiguation that we must keep separated. If next time you ping me I can answer more quickly --ValterVB (talk) 18:17, 29 January 2019 (UTC)[reply]

@ValterVB: They are all the same items, for Christ's sake. The French page is a "page d’homonymie " (disambiguation page) instead of a list, didn't you read it on the top of the page? And different spelling in different languages doesn't make things different. For example, Police nationale (France) on fr.wikipedia is exactly the same as National Police (France) on en.wikipedia and Policía Nacional (Francia) on es.wikipedia, which are all referring to the national police force of France. By the way, your reason doesn't justify your act to split 国家警察 on ja.wikipedia and 國家警察 on zh.wikipedia into different items, which are both disambiguation pages about national police, even written in almost the same way with Han characters ("Hànzì" in Chinese/"Kanji" in Japanese. By the way, this is another good case showing that different spelling makes the same topic, which are not separated. Another good example can be seen above, concerning "Ministry of Foreign Affairs" in different languages. The difference between the spelling of "Außenministerium" and "Ministério das Relações Exteriores" is even larger than the difference between "National police", "Nationalpolizei", "Police nationale" and "Policia Nacional"!) And this act doesn't justify your edition to remove labels in other languages as well (for example, "Polis Kebangsaan" in Malay, "Cảnh sát Quốc gia" in Vietnamese and "국가경찰" in Korean, which are all corresponding translations for "national police". There's no point to remove them).--Howard61313 (talk) 03:44, 30 January 2019 (UTC)[reply]

See Wikidata:WikiProject Disambiguation pages/guidelines, and discussions on its Talk page. Ghouston (talk) 05:06, 30 January 2019 (UTC)[reply]

Disambiguation pages aren't about a topic but about multiple separate topics that have the same name. As a result, we merge Disambiguation pages when they have the same name and not by topic (by definition each Disambiguation page is about more then one topic). You could create a redirect ":en:Nationalpolizei" that points to ":en:National police" and link that ":en:Nationalpolizei" item from the same item as ":de:Nationalpolizei". This redirect creation at the moment isn't as comfortable as possible but it gives you interwiki-links if your intention is to have interwiki-links on the corresponding Wikipedia pages. ChristianKl ❪✉❫ 11:00, 30 January 2019 (UTC)[reply]

Thank you for correcting my words. Compare to "same topic", now I think that "same name" is more appropriate for the case of "national police" (which are disambiguation pages for police forces in several countries that can be translated as "national police" from their respective languages).--Howard61313 (talk) 04:22, 31 January 2019 (UTC)[reply]

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

Species items

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

Is country of origin (P495) appropriate on taxa?
Is instance of (P31) → invasive species (Q183368) appropriate on taxa? (I would think it isn't without at least two qualifiers to indicate time and place, since whether a species is considered invasive is heavily context-dependent.)
Is instance of (P31) → plant (Q756) appropriate on taxa?

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

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)[reply]

@User:Vanessalozano: Mind to comment? --Succu (talk) 22:35, 30 January 2019 (UTC)[reply]

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)[reply]
- 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)[reply]
  - 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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Daty Wikidata Editor alpha release

Hi everyone,

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

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

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

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

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

Download

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

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

Note for GNU/Linux users

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

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

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

Note for Ubuntu users

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

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

Note for Mac users

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

Thanks

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

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

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

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)[reply]

@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)[reply]

Does it support lexemes? KaMan (talk) 15:17, 30 January 2019 (UTC)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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 magazine cover (Q44532723) doesn't have the correct subclass.) Jc86035 (talk) 10:48, 3 February 2019 (UTC)[reply]

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)[reply]

Please merge article with translated

Salzderhelden saltworks (Q60790654) is a translated or english version of the german version: Saline Salzderhelden (Q2214431) . Please merge or make otherwise visible the corresponding language version in both wikipedias. --Rosegluy (talk) 19:56, 30 January 2019 (UTC)[reply]

Done--Ymblanter (talk) 20:19, 30 January 2019 (UTC)[reply]

Anastasiya Knyazeva

I have noticed that Anastasiya Knyazeva was deleted. Why? :-) --151.49.74.230 22:47, 30 January 2019 (UTC)[reply]

Without you giving the item ID it's hard to give you an answer. Likely, the item didn't fit our notability policy. ChristianKl ❪✉❫ 10:10, 31 January 2019 (UTC)[reply]

Did you mean this - Anastasiya Pavlovna Knyazeva (Q55104095)? --Ksc~ruwiki (talk) 18:49, 31 January 2019 (UTC)[reply]

Or perhaps Anastasiya Pavlovna Knyazeva (Q44979759), deleted 2019-01-20T14:54:35 by @MisterSynergy: (Does not meet the notability policy: content was: "Anastasiya Knyazeva", and the only contributor was "151.49.119.153"). Bovlb (talk) 19:59, 31 January 2019 (UTC)[reply]

I have undeleted and merged. Bovlb (talk) 20:08, 31 January 2019 (UTC)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

Thanks, I'll try that. - Jmabel (talk) 01:20, 4 February 2019 (UTC)[reply]

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)[reply]

Soviet Sports Title

We have Master of Sport of the USSR (Q1803234), Master of Sport of USSR in Chess (Q16674680), Master of Sport of USSR in Chess Composition (Q4284316) and maybe others. How should those be used? If the latter two are separate titles, I think they should be used as individual statements with award received (P166), but if they are only thematic divisions of only one title, I think that only the first item thould be used. But I don't know much about those soviet titles, and therefore I am hesitating to add anything. Steak (talk) 08:55, 31 January 2019 (UTC)[reply]

They are three different titles. -- VlSergey ^(трёп) 09:09, 31 January 2019 (UTC)[reply]

Ok, thanks. Steak (talk) 13:37, 31 January 2019 (UTC)[reply]

Facto Post Issue 20, licensing data

The latest issue is at w:User:Charles Matthews/Facto Post/Issue 20 – 31 January 2019. The editorial mentions the version problem with much Creative Commons licensing in major repositories, but without giving details.

This business came up in the ScienceSource planning to scale up the focus list described at WD:SSFL. Licences without version number, so more precisely subclasses of licenses, are commonly used in sites such as unpaywall. They are present in the open access collection of PubMed Central, and presumably unpaywall gets them from there. PubMed Central pages on papers very often link to the actual Creative Commons license page; but not always. As far as we can tell, the best source to use is the OpenXML on Europe PMC. Charles Matthews (talk) 12:01, 31 January 2019 (UTC)[reply]

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)[reply]

done. --Pasleim (talk) 09:48, 1 February 2019 (UTC)[reply]

Thank you very much. --Ksc~ruwiki (talk) 19:59, 1 February 2019 (UTC)[reply]

Alexander and Александр

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

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)[reply]

Alexander (Q923) is in latin script, Aleksandr (Q17501806) in cyrilic, so definitely different entities and nothing to merge. But I am not sure if it is wise to fill latin transliteration as Aleksandr (Q17501806) label, as it is causing a bit mess.--Jklamo (talk) 23:22, 1 February 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

It didn’t work because you are not logged in. – Máté (talk) 11:20, 1 February 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Russian help?

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

I've seen other cases like that. Delete the ruwiki sitelink and merge them! ArthurPSmith (talk) 16:04, 1 February 2019 (UTC)[reply]

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)[reply]

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)[reply]

Yes, it was just redirect. --Ksc~ruwiki (talk) 20:06, 1 February 2019 (UTC)[reply]

officeholder (P1308)

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

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)[reply]

Excellent, thanks! Preferred rank a great way to designate the incumbent. --RAN (talk) 23:20, 1 February 2019 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 position holder (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)[reply]

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)[reply]

Actually, the property shouldn't be used if there is P6 or P35 with the same data. --- Jura 13:38, 3 February 2019 (UTC)[reply]
- @Jura1: Where is that documented? --Oravrattas (talk) 16:48, 3 February 2019 (UTC)[reply]

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: season (Q27020041) or similar? Or should P3450 be deleted? Matěj Suchánek (talk) 10:32, 2 February 2019 (UTC)[reply]

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): 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)[reply]

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)[reply]

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: 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)[reply]

⟨ 2018–19 Ligue 1 (Q51546683)  

 ⟩ organizer (P664) ⟨ French Football Federation (Q244750)  

 ⟩

, and not

⟨ 2018–19 Ligue 1 (Q51546683)  

 ⟩ organizer (P664) ⟨ Ligue 1 (Q13394)  

 ⟩

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I have filed a bug report with Github. Bovlb (talk) 21:55, 2 February 2019 (UTC)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

"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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Wikidata weekly summary #350

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

Events
- Next Wikidata workshop/meetup in Paris: February 15th
- Next Wikidata meetup in Berlin: March 12th
- The conference grant proposal for WikidataCon was submitted and could use endorsements.

Press, articles, blog posts
- „Eisberg voraus!“ – Sächsische Landeskunde mit SXRM, Wikisource und Wikidata by Jens Bemme (in German)
- Linking the OLAC Video Game Vocabulary with Wikidata by Tracy Hoffmann and Peter Chan
- Adam blogged about how to update an existing Wikibase docker instance

Other Noteworthy Stuff
- Got some time? SpeedPatrolling, a tool to simplify patrolling of recent changes on Wikidata (documentation), has been announced and you can use it to help fight vandalism.
- Got some time? Match some streets and the humans they are named after.
- Got some time? Help link OpenStreetMap and Wikidata Items with the new OSM <-> Wikidata matcher.
- Wikidata Query Service now has over 7 billion triples.

Did you know?

Development
- Making progress towards first showable version of basic Shape Expression support
- Layout polishing for the mobile termbox (the box that shows labels, desctiptions and aliases) and continuing work on the "in more languages" and "all entered languages" sections in it
- Added tracking for the number of Senses and Forms to our graph for tracking the number of Items, Properties and Lexemes
- Worked more on making it easier to set up Quickstatements in other Wikibase instances
- Preventing an entity to redirect to itself (phabricator:T214919)
- Working on making Federation (reusing Wikidata's Items and Properties to make statements) work for Wikimedia Commons to get the rollout of the next stage (support for depicts statements) unstuck
- Fixed an issue with adding sitelinks from Commons (phabricator:T213975)
- Fixing Cognate support for yue Wiktionary (phabricator:T214400)

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

Read the full report · Unsubscribe · Lydia Pintscher (WMDE) 21:33, 4 February 2019 (UTC)[reply]

Triplication?

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

Robert Craig Wallace (Q21545049) was well defined while Robert Craig Wallace (Q61483178) and Robert Craig Wallace (Q21545053) were based on RKD record with minimal info. They all had in common that it was british painter and etcher with unusual name painting marine themes and landscapes in the same time period. I merged them. --Jarekt (talk) 14:15, 5 February 2019 (UTC)[reply]

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)[reply]

Excellent! --RAN (talk) 16:41, 5 February 2019 (UTC)[reply]

That is very good. --Jarekt (talk) 16:58, 5 February 2019 (UTC)[reply]

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)[reply]

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: [1], [2], [3] -- Vlsergey (talk) 08:23, 6 February 2019 (UTC)[reply]

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)[reply]

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

Great. I'll probably use it on Commons for tombstones. Eg. c:Category:Grave of Lafargue (Père-Lachaise, division 76)

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): [4] thx Queryzo (talk) 19:54, 5 February 2019 (UTC)[reply]

@Queryzo: Done in An deiner Seite (Q50824526), but in futute you can do it yourself by clicking on "Edit" and "remove". Bovlb (talk) 21:37, 5 February 2019 (UTC)[reply]

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)[reply]

@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)[reply]

@Queryzo: Done. Bovlb (talk) 17:44, 6 February 2019 (UTC)[reply]

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)[reply]

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)[reply]

As a way to harmonize, what about populating "manner of death" with death at sea (Q46998267) or at sea (Q55438959) in addition to accident?

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)[reply]

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)[reply]

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)[reply]

Considering still Florence, the Uffizi Gallery is the building, but the Uffizi institution runs also Palazzo Pitti and the Boboli Gardens. In Genoa, Italy I can suggest museum of the world cultures (Q3868144) which is housed in Albertis Castle (Q3662403) --Sabas88 (talk) 10:24, 6 February 2019 (UTC)[reply]

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)[reply]

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)[reply]

Expanding what a property can be used on?

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

Thanks, Nicereddy (talk)

For a change like this the general procedure is to write a comment on the talk page of the property, ping the people who participated in the discussion for creating the property and link from here to that discussion. ChristianKl ❪✉❫ 15:14, 6 February 2019 (UTC)[reply]

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)[reply]

@Levana Taylor: The best discussion about this previously is probably the one at Wikidata_talk:WikiProject_Books/2018#Pseudonyms, though I'm not sure there's a direct answer to your question there. If you definitely need a separate item for the pseudonym, then said to be the same as (P460) might be a way to link them if that's not certain, but you might be better asking at WikiProject Books, as they have quite a well-defined model already and a large community of people involved with resolving issues like this. --Oravrattas (talk) 08:26, 6 February 2019 (UTC)[reply]

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)[reply]

What's also annoying - why is it limited to CC? A lot of official German map data is licensed by "Datenlizenz Deutschland Namensnennung" [5], which de fakto is the same as cc-by, but not legally. Ahoerstemeier (talk) 11:24, 6 February 2019 (UTC)[reply]

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)[reply]

"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)[reply]

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)[reply]

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

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

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

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

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

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

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

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

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

There is no credible secondary source for these IDs.

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

Special:CentralAuth/MisterSynergy: 21:53, 1 December 2012 - 1,737,460 - interface-admin, sysop, translationadmin
Special:CentralAuth/Jura1: 19:17, 2 May 2014 - 10,352,209 - propertycreator, rollbacker, translationadmin
Special:CentralAuth/Succu: 14:29, 4 February 2013 - 2,643,769 - (-)
Special:CentralAuth/Mahir256: 16:22, 28 April 2013 - 1,524,420 - interface-admin, sysop

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

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

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

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

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

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

I guess blocking this IP would be a good start.--Ymblanter (talk) 21:49, 6 February 2019 (UTC)[reply]

For the people new here, let me introduce the user known as Tobias Conradi here also known as Tamawashi. His modus operandi: Contribute from an Telefónica Deutschland (Q2401561) ipaddress. Usually quite constructive for a while and at some point the user derails completely and starts attacking people. We seem to be at this point now. Looks like it's time for some blocks. Multichill (talk) 21:59, 6 February 2019 (UTC)[reply]

Content at de:Baltisches Biographisches Lexikon Digital is not trustable. --Succu (talk)

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)[reply]

@@ Line 659: / Line 659: @@
 : I guess blocking this IP would be a good start.--[[User:Ymblanter|Ymblanter]] ([[User talk:Ymblanter|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 21:49, 6 February 2019 (UTC)
 ::For the people new here, let me introduce the user known as [[:meta:Requests for comment/Global ban for Tobias Conradi|Tobias Conradi]] here also known as [[user:Tamawashi|Tamawashi]]. His modus operandi: Contribute from an {{Q|Q2401561}} ipaddress. Usually quite constructive for a while and at some point the user derails completely and starts attacking people. We seem to be at this point now. Looks like it's time for some blocks. [[User:Multichill|Multichill]] ([[User talk:Multichill|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 21:59, 6 February 2019 (UTC)
+::: Content at [[:de:Baltisches Biographisches Lexikon Digital]] is not trustable. --[[User:Succu|Succu]] ([[User talk:Succu|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]])
 == Relationship between Wikidata, VIAF, Getty (ULAN, CONA, etc) ==