Wikidata:Project chat/Archive/2014/09

From Wikidata
Jump to navigation Jump to search

breaking changes for gadgets

Hey folks,

We are working on re-vamping a lot of the underlying code for the user interface at the moment. These changes are the first major steps for the new user interface. They are necessary to allow editing all sitelinks or label/description/alsiases at once for example. Unfortunately some gadgets will need to be adapted to these changes. Specifically it is the introduction of sitelinkview and aliasview.

We are aware of the following gadgets that will need to be adapted but those might not be all:

  • MediaWiki:Gadget-DraggableSitelinks.js
  • MediaWiki:Gadget-KeyShortcuts.js
  • MediaWiki:Gadget-MainLangFirst.js
  • MediaWiki:Gadget-Move.js
  • MediaWiki:Gadget-Preview.js
  • MediaWiki:Gadget-SimpleTransliterate.js

The new code is live on test.wikidata.org for you to test your gadgets against. The changes will go live on wikidata.org on Tuesday. Sorry for the breaking change. I hope the new UI will be worth it for you though :)

Cheers --Lydia Pintscher (WMDE) (talk) 12:30, 31 August 2014 (UTC)

Lydia Pintscher (WMDE), does test.*.org exist for other sister projects? Test.wikidata.org isn't linked in the list of sister projects at the top of the recent changes list, to my knowledge... --Gryllida 03:31, 1 September 2014 (UTC)
I don't know if another sister project has a test system like this besides Wikipedia. I'm not sure which list you mean. Can you link? --Lydia Pintscher (WMDE) (talk) 06:29, 1 September 2014 (UTC)

Reading a diff about dates

I'm having trouble reading this diff where a birth date in the Julian calendar was added. The information seems contradictory to me.

The first line in the diff says "+00000001635-04-25T00:00:00Z (Gregorian)". Then it says "ISO timestamp +00000001635-04-25T00:00:00Z" and ISO 8601 always uses Gregorian dates. But later in the diff, it says "property / date of birth: 25 April 1635 Julian / rank. And in the page itself it says "25 April 1635 Julian".

Another confusing factor is that if I click "edit" next to the date of birth, I am only given an opportunity to edit the date, not change the calendar. So can someone explain why the same date, April 25, 1635, is being described as both Julian and Gregorian? Jc3s5h (talk) 16:15, 25 August 2014 (UTC)

The first one you are seeing is what is stored internally. That is always gregorian iirc. We need to improve the diff view there. Do you or someone else have suggestions for how? The other data can't be edited yet in the user interface but will probably in the future. --Lydia Pintscher (WMDE) (talk) 09:57, 29 August 2014 (UTC)
It seems to me that while it would be nice to improve the diff, it is more urgent to fix the display in the page. If the internal representation is "+00000001635-04-25T00:00:00Z (Gregorian)" and it is Gregorian (I think your right about that) then it is a falsehood for the page to state "25 April 1635 Julian".
If the diff is to be improved, perhaps it should be explained with a more complete phrase, such as "Prior to edit display preference was Gregorian calendar, after edit display preference is Julian calendar. Jc3s5h (talk) 16:04, 1 September 2014 (UTC)

WDQ -- how to get text of commonslink ?

Quick question (I hope), perhaps @Magnus Manske: re WDQ:

What do I need to put in, to get it to give me the text of the Commons sitelinks for items returned ?

For example, I can send 

  http://wdq.wmflabs.org/api?q=LINK[commonswiki]%20AND%20CLAIM[31:4167836]&props=373

to get the value of Commons category (P373) for every category that has a sitelink to Commons (caution: returns 251,000 hits).

But how do I specify that I would like it to give me the actual Sitelink text ? Jheald (talk) 18:11, 29 August 2014 (UTC)

The sitelinks are not stored in WDQ, only the fact that one exists for an item. I'm keeping all information in RAM, so space is precious. The main purpose of WDQ is to give you items that match a query. You'll have to go to Wikidata proper (API or Labs DB) to get the sitelinks. Same for labels, aliases, descriptions, qualifiers, sources, etc. --Magnus Manske (talk) 22:17, 29 August 2014 (UTC)
Thanks. @Multichill: Is that what you do for your User:Multichill/Cross namespace page? Jheald (talk) 22:41, 29 August 2014 (UTC)
That's just a quick and dirty database query to get items that link to different namespaces in Wikipedia. Multichill (talk) 20:41, 30 August 2014 (UTC)
@Multichill: Thanks very much for this. I'm travelling for the next couple of days, but then I think with luck it ought to be possible to adapt it to do exactly what I want -- without having to hit Wikidata individually for 250,000 separate queries! Thanks, Jheald (talk) 09:07, 1 September 2014 (UTC)

Please, add the badge for quality articles

Tracked in Bugzilla
Bug 70268

Those badges referes to «Quality Articles» project on ruwiki and several other projects. Color of the badge can be green or white (not silver). -- Vlsergey (talk) 00:39, 24 August 2014 (UTC)

@Vlsergey, Lydia Pintscher (WMDE): recommended article (Q17559452)--GZWDer (talk) 07:56, 24 August 2014 (UTC)
Thanks a lot, this may actually solve the Wikivoyage problem of three badges.--Ymblanter (talk) 08:49, 24 August 2014 (UTC)
If there is rough consensus on this here by Wednesday I will add it. --Lydia Pintscher (WMDE) (talk) 12:25, 24 August 2014 (UTC)
Support of course :) --Stryn (talk) 18:59, 24 August 2014 (UTC)
Support! --putnik 17:51, 27 August 2014 (UTC)

Hey :) I just wanted to file the bug to get quality article added. Is this the same as recommended article? We have quite some items in Category:Badge items now. Can someone get some overview of this and see what should be merged? --Lydia Pintscher (WMDE) (talk) 09:52, 29 August 2014 (UTC)

Yep, it's the same thing, though I don't know what's the "official English name" of this. You can rename it to "Quality article" if you think it means the same. Swedish name "rekommenderade artikeln" is roughly translated as "recommended article", that's why it was named for such. For the category question, I think there's nothing needed to merge. --Stryn (talk) 19:05, 30 August 2014 (UTC)
Now we got the Wikivoyage consensus: meta:Wikivoyage/Lounge#Badges. In Wikivoyage, we have three grades of distinguished articles, which are star, guide, and usable articles. At this point, we can use FA badge for star, GA for guide, and we need to activate quality/recommended article for usable. @Lydia Pintscher:: what needs to be doe for that? To file a bug to activate the quality article badge, and another one to show the badges in Wikivoyage? Or otherwise we can show the badges using the mediawiki extension, but the third nadge needs to be activated anyhow.--Ymblanter (talk) 13:36, 1 September 2014 (UTC)
If you could file a but that'd be awesome. One is enough. Thanks! :) --Lydia Pintscher (WMDE) (talk) 16:14, 1 September 2014 (UTC)
Filed the bug.--Ymblanter (talk) 20:02, 1 September 2014 (UTC)

Deletion vs redirect

This issue has been already discussed at several places but we did not come to any reasonable conclusions. Now, we have an option of redirecting item, and the RfD interface has been updated, so that one can choose both options of speedy deletion and speedy redirect. But we still lack the policy of what should/could be redirected. Possible answers would be:

  1. We do not need any policy; leave it to the discretion of the administrator;
  2. Delete everything;
  3. Redirect everything if there is an obvious target (for example, a merge leftover);
  4. Go to RfC and create some intermediate policy (example: redirect only items which correspond to the main name space of the projects, ad only if they are at least one week old; else delete).

Before rushing to RfC, I think it would be a good idea to see what are the community views. Note that we are NOT talking about including redirects to the item (storing Wikipedia redirects on Wikidata), this is an entirely different issue.--Ymblanter (talk) 18:57, 26 August 2014 (UTC)

Delete if is a recently created item (24-48 hours) redirect for other cases. --ValterVB (talk) 19:54, 26 August 2014 (UTC)
Agree with ValterVB. It is important that we have stable Qrefs and redirects are the way to do it. Filceolaire (talk) 00:00, 27 August 2014 (UTC)
Empty bot created items should allways beeing deleted. They gain no knowledge. --Succu (talk) 21:09, 28 August 2014 (UTC)
@Succu:. Redirects shouuld only exist when the two items were about exactly the same thing. This is not about knowledge gain. The only purpose of redirects is that if an external users uses Wikidata ids, and two items are merged, we do not break his things. This may be useful regardless of who created the item in the first place, and I would say, even if it is a few hours ago. --Zolo (talk) 10:20, 29 August 2014 (UTC)
I'm personally not willing to make use of the redirect feature unless it is implemented to the UI properly and the i18n is sufficiently completed. This is something we as end-users can really expect … Vogone (talk) 21:30, 28 August 2014 (UTC)
I agree with Vogone. The feature is still under development and contains bugs. We should wait some time until it is ready for mass use. SPQRobin (talk) 21:49, 28 August 2014 (UTC)
@Vogone:. Redirect work for the end user in the sense that if the item is a redirect, we go directly to the page to which it redirects. And it is really not more difficult to make a merge than to request a deletion. And a deletion requestion is as easy to fullfill as a merge request, so I do not quite see what you mean. --Zolo (talk) 10:20, 29 August 2014 (UTC)
What part of my statement is unclear to you? There is no UI support available for an unknown reason and as you can see in the auto summaries developers didn't seem to care about proper MediaWiki messages at all. This means the feature is broken resp. not ready and I won't use it. Imagine they broke the ability to edit items through the UI. Would you also use the same argument and say it isn't harder to edit as there are gadgets/scripts to do so? Vogone (talk) 10:48, 29 August 2014 (UTC)
Furthermore redirecting is sometimes troublesome, because the item that is supposed to become a redirect has to be completely empty, while the merge API not always completely empties the item. Merge.js treats it well, but the redirect options at WD:RFD (gadget for admins) and widar/the game do often fail to create the redirect. In those cases the game does mention this to the user, but the WD:RFD gadget does not. Apart from that, I am willing to create the redirects. This is however - as in most cases - not flawless, while use by everyone is expected. Lymantria (talk) 11:00, 29 August 2014 (UTC)
Vogone, we had the choice of deploying it in the current state without a special page to create redirects or not. Given that admins being overworked because of all the deletion requests I opted for deploying it without the special page. It works perfectly fine for an initial useful version. As for the issue with the edit summary: this has nothing to do with not caring. It's an oversight that will be fixed with the next deployment. --Lydia Pintscher (WMDE) (talk) 11:35, 29 August 2014 (UTC)
@Lydia Pintscher (WMDE): While I do understand the choice you made, as an admin who has carried out quite a couple of deletions I am worried about wrong merges. Up to a couple of days ago, most of these merges would result in a deletion request, that should be checked by an admin before to be carried out or reverted. But now we simply solve the admin workload by not monitoring the merges anymore? There have been wrong merges more than once, in particular by new users or overenthusiastic "gamers". There is no place where redirect-creatings are gathered. Moreover, having a list with item couples that shouldn't be merged is not useful anymore, as redirects do not turn red. I think that may turn into a major quality issue. Lymantria (talk) 13:10, 29 August 2014 (UTC)
http://quarry.wmflabs.org/query/389 will give you a sense of what and how many redirects are created. whym (talk) 14:08, 29 August 2014 (UTC)
I think we all agree that redirects are needed and useful. The issue you bring up however is valid of course. Do you have suggestions for how to improve that? --Lydia Pintscher (WMDE) (talk) 09:04, 30 August 2014 (UTC)
@Lydia Pintscher (WMDE): The least would be that redirects are easily identifiable. For instance by there appearance as a link (green, like in categories in wikipedia?). Recently created redirects should be visable somewhere. It seems that edits are not caught by the editfilter (See Filter 50...) - but perhaps automatic labelling is possible like it is with widar. That might make it more easy to do some managing if necessary. Lymantria (talk) 14:25, 2 September 2014 (UTC)
@Lydia Pintscher (WMDE): Sorry for the probably too harsh part about not caring. I just notice more and more broken or missing MediaWiki messages on Wikibase, while other areas/extensions don't experience this problem as much as Wikidata, as the reviewers there seem to look at i18n more accurately. Thanks for deploying this feature at such a early stage though, the intention is clearly good and of course some testing in production always helps! Though, I believe, to come to Ymblanter's initial question, that we should not yet make redirects the "default", and first wait until everything in this regard is fully ready and functioning. Anyway, is a new special page really needed? I would have thought a simple checkbox at Special:MergeItems would do it as well. Regards, Vogone (talk) 17:12, 29 August 2014 (UTC)
Yeah a checkbox in Special:MergeItems could be better. What do others think? WRT translations being broken: Are there specific patters? If we're doing one thing wrong again and again then that's something I just need to know and bring up in the team. --Lydia Pintscher (WMDE) (talk) 09:01, 30 August 2014 (UTC)
I think we should be more consistent in whether we are going to delete or redirect the duplicated item because from RFD archives, I see some admins deleting and some admins redirecting. Jianhui67 talk★contribs 13:26, 30 August 2014 (UTC)

Redirects at target

Sorry to ask what may be a FAQ — Portals are semi-deprecated on en.wn, and I think some other Wikinewses, but perhaps not on all of them. If at some point in the future, many, or even all, of these portals are made redirects to the corresponding categories, what happens to the Wikidata-generated sister links to those portals? Especially considering that the corresponding category probably (by the time this is done) already has a set of sister links provided from Wikidata? --Pi zero (talk) 21:40, 30 August 2014 (UTC)

This is not theoretical, I see. en.wn portal Portal:Russia interwikis to ru.wn Портал:Россия, which is a redirect to Категория:Россия. When the portal was switched over to wikidata, Russian Wikinews was deprived of its proper interwiki. I corrected this error on en.wn, by restoring the locally specified interwiki, but presumably Russian Wikinews is still being unfairly cut out of interwikis from other portals on the list. This seems like a conceptual problem: Wikidata is building an ontology, but the purpose of interwiki links is not ontological, as such. --Pi zero (talk) 00:35, 31 August 2014 (UTC)
@Pi zero: Portals must be linked with portals (where exist). Now Russian Wikinews reduce the number of portals (gradually redirects to similar categories). Therefore wrong linking must be corrected - only remove interwiki links to redirects from portals to categories in Wikidata. Now everything looks correct: Portal:Russia (Q8252645). --sasha (krassotkin) 06:18, 1 September 2014 (UTC)
@krassotkin: I don't understand what you mean. The situation may be correct for Wikidata, but it is wrong for the other sisters that are now being induced to provide inferior service to their readers in order to draw their interwikis from an ontology for which interwikis are apparently not the primary design concern.
  • The purpose of an interwiki, I maintain, is to help the reader by providing a convenient link to analogous pages in other languages. Therefore, for purposes of interwikis, there should be an interwiki from en.wn page Portal:Russia to ru.wn page Портал:Россия, and it would be counterproductive to omit this interwiki link. If you follow that link, it redirects to another page on ru.wn (Категория:Россия), but the correct thing to do is still to provide an interwiki to Портал:Россия.
  • The purpose of Wikidata, as best I can figure it, is to construct an ontology. The ontology seems to be philosophically motivated. When deciding what pages are and are not to be included in Wikidata item Q8252645, one therefore considers only what is appropriate for the ontology, not what is appropriate for interwiki linking of pages. And, in fact, it appears that the decision made on this point is one that may be appropriate for the ontology, but is wrong for purposes of interwiki linking of pages, and is (in its small way) damaging to ru.wn because it allows Wikidata ontological concerns to determine interwiki links.
--Pi zero (talk) 14:16, 1 September 2014 (UTC)
I'll amplify this point. If ru.wn had chosen to provide no page Портал:Россия, then it would be correct to provide no interwiki to ru.wn from en.wn Portal:Russia. However, ru.wn has chosen to provide a redirect at that page, which is to say, ru.wn has decided that if someone is looking for Портал:Россия they should be sent to Категория:Россия. Therefore, if one respects the right of ru.wn to make this decision, interwikis to Портал:Россия should be provided. --Pi zero (talk) 14:22, 1 September 2014 (UTC)
No, at the notability policy (sub 1 first bullet) it is stated clearly that a sitelink should not point to a redirect. Lymantria (talk) 15:40, 1 September 2014 (UTC)
Lymantria, you seem to be missing the point. That's a Wikidata policy, which presumably has been chosen for purposes of Wikidata's ontology. And that's fine, as long as Wikidata's ontology is only used as a local structure. However, the decision of whether to provide an interwiki absolute should not be based on what rules Wikidata chooses to use for its ontology. In this case, Wikidata's internal decision to exclude rediects is causing real harm to other projects by lowering the quality of their product. I see nothing wrong with Wikidata deciding its own internal policies; the problem here is that Wikidata is not simply deciding its own internal policies, it's damaging other projects by imposing its ontologically motivated policies on the properly non-ontological interwiki practices of other projects. I'm not sure how else to put this; it is inappropriate for decisions about interwikis on other sisters to be forced on them by unrelated philosophical concerns on Wikidata. --Pi zero (talk) 16:22, 1 September 2014 (UTC)
Wikidata does not force other projects to refrain from local interwikilinks. Lymantria (talk) 16:28, 1 September 2014 (UTC)
That's an obvious technical truth. It's not a particularly practical truth, though. It's a bit like saying ordinary taxpayers are offered various advantages by a tax system that only a tax lawyer could figure out. How are these other projects to avail themselves of this supposed flexibility? Obviously, they'd do it using the organizational infrastructure that's inevitably going to be dismantled since Wikidata is supposedly now taking over its function. The difference between that previous infrastructure and Wikidata is that the purpose of the previous infrastructure was to provide helpful interwikis, whereas Wikidata apparently has some other purpose of its own. --Pi zero (talk) 17:39, 1 September 2014 (UTC)
@Pi zero: I understand your logic, but it's not completely accurate. Linking of portals (enwn) and categories (ruwn) is a kind of cheating readers. Because it's not the same in the general case. ru.wn saved redirect for referential integrity only (see at least the internal - Special:WhatLinksHere). --sasha (krassotkin) 19:33, 1 September 2014 (UTC)
There is a bugzilla bug to allow links to redirects and I believe the development team plan to fix this in the next month. In view of that I believe it is time to start a Wikidata:Requests for comment to propose the wikidata policy is changed so that sitelinks to redirects are allowed and to define the circumstances under which we should do this. Filceolaire (talk) 21:58, 1 September 2014 (UTC)
It would be cheating readers to not help them find the Russian analog to the page they're looking at. And we're not talking about linking portals and categories. The situation is technically symmetric and effectively asymmetric, but neither of those involves listing a category in Wikidata item Q8252645. If you're looking at en.wn Portal:Russia, its Russian interwiki directs you to, technically, ru.wn Portal:Russia; and effectively, rn.wn Category:Russia. However, if you're looking at ru.wn Portal:Russia, you don't (ordinarily) see it but instead you end up seeing ru.wn Category:Russia to which you were redirected. And when you're looking at ru.wn Category:Russia, its English interwiki directs you to en.wn Category:Russia (not to en.wn Portal:Russia). If you start at en.wn Portal:Russia, follow its Russian interwiki, and then from the page you end up at, follow its English interwiki, you end up at en.wn Category:Russia. I maintain there is nothing wrong with that; it's the behavior most useful for the reader, it's the behavior most beneficial to both projects, and Wikidata, in order to support it, would not have to corrupt Q8252645 by listing a category page. I'm entirely willing to concede that Wikidata might have a good reason, for its own objectives (which are unclear to me), to not be willing to list a redirect there; I simply maintain that while possibly right for the purpose of Wikidata, it is wrong for the purpose of interwikis, and the negative consequences of this mismatch, while they do not directly harm Wikidata, do harm the sister projects that use Wikidata for interwikis. I also don't claim to know all the answers about how to solve the problem; but I maintain that it is a problem.
As for the point about referential integrity, preserving interwikis is a case of referential integrity. If you're looking for ru.wn Portal:Russia, you should be led to their Category:Russia. If you're looking at en.wn Portal:Russia, and you look for a Russian interwiki, you are looking for ru.wn Portal:Russia, and as just stated, you should be led to their Category:Russia. En.wn may eventually choose to redirect its portals to categories (once we've upgraded the categories a bit more), and if we do that, the most appropriate thing for another project to do with its interwiki that used to link to our Portal:Russia will be to continue to link it to our Portal:Russia. To do otherwise would be penalize us, and penalize the reader, for our decision that the best way for us to improve our project is to redirect the portal to the category. --Pi zero (talk) 21:56, 1 September 2014 (UTC)
@Pi zero: I agree with you in the next. Wikidata should provide technical possibility to individual projects and their community to build own structures and links there. After reaching a consensus in a local community, we should raise the question and expect to solve it from Wikidata. It is the task of developers and community Wikidata think of how. Wikidata should solve problems, but not create new ones. We created our projects for many years. But now cometh the people who did not make any changes there and don't listen to our arguments. In particular I am extremely disappointed with the discussion above: #Wikinews linking. I'm not ready to discuss other issues until there is no summed result. I'm sorry. --sasha (krassotkin) 08:32, 2 September 2014 (UTC)
Indeed, one of the biggest problems we've had over the years at en.wn is people from en.wp coming over, not knowing anything about news and not bothering to learn, presumably on the assumption that since their project is bigger than ours they are qualified to tell us how to run our wiki. I did foresee that Wikidata would become another vector for those who don't know about news, and don't care to learn, to disrupt how news projects are run. Yet, here we are. --Pi zero (talk) 12:33, 2 September 2014 (UTC)
Lymantria, the the notability policy doesn't state that sitelinks SHOULD NOT point to a redirect. It states that sitelinks at present CANNOT point to a redirect. And it has note saying that links to redirect are allowed (see this RFC), but we are waiting for the technical implementation - which I personally hope comes soon. Regards, Dipsacus fullonum (talk)

Grants to improve your project

Apologies for English. Please help translate this message.

Greetings! The Individual Engagement Grants program is accepting proposals for funding new experiments from September 1st to 30th. Your idea could improve Wikimedia projects with a new tool or gadget, a better process to support community-building on your wiki, research on an important issue, or something else we haven't thought of yet. Whether you need $200 or $30,000 USD, Individual Engagement Grants can cover your own project development time in addition to hiring others to help you.

Removing badge

How can I remove the badge? For example in Wikidata Sandbox Q4115189 I added two badges, then only one, then the other one, but I can not remove it! --FRacco (talk) 19:11, 26 August 2014 (UTC)

Edit -> click the badge > hold Ctrl and click the badge which is selected, and after this it's unselected. Then save your changes. --Stryn (talk) 19:28, 26 August 2014 (UTC)
Thanks! --FRacco (talk) 20:29, 26 August 2014 (UTC)
Wouldn't it be better to have checkboxes for adding/removing badges? --Glaisher (talk) 16:22, 1 September 2014 (UTC)
Indeed it would... I saw a week-two-ago when Bene* and Lydia(?) talked about this, and they had a some reason why not... --Stryn (talk) 16:23, 1 September 2014 (UTC)
I think we'll switch to checkboxes after all. It does seem to be the better solution. --Lydia Pintscher (WMDE) (talk) 17:07, 1 September 2014 (UTC)
I've filed bugzilla:70333 now. --Lydia Pintscher (WMDE) (talk) 09:24, 3 September 2014 (UTC)

There's a featured list badge item Q17506997 which enabled as a badge I assume could replace en:Template:Link FL on quite a few wikis. Apparently some sort of community consensus is needed to enable this badge. So this here is a proposal to use a featured list badge. 88.196.241.249 17:47, 1 September 2014 (UTC)

 Support, also there's already an item for this badge: featured list badge (Q17506997). --Stryn (talk) 18:33, 1 September 2014 (UTC)
 Support Dozens of wikis still have JavaScript code in their MediaWiki namespace (e.g. en:MediaWiki:Gadget-featured-articles-links.js) just because of en:Template:Link FL. It absolutely makes sense to replace this just like featured and good articles, so that the JavaScript can be dropped everywhere. --Entlinkt (talk) 18:51, 1 September 2014 (UTC)
 Support Amir (talk) 20:11, 1 September 2014 (UTC)
 Support Why not? --Jklamo (talk) 21:35, 1 September 2014 (UTC)

Thanks folks :) I've filed bugzilla:70332. Will be done in a bit. --Lydia Pintscher (WMDE) (talk) 09:15, 3 September 2014 (UTC)

Quantities with units

Unitless quantities was introduced some time ago. Somewhere I saw "not now" for adding units. Will it remain like that for long? Lots of properties are on hold, because they require units. -- Poul G (talk) 23:11, 1 September 2014 (UTC)

The question was already asked: this is in the pipeline, but nobody is working on it and the working plan of the development team is too full to develop this feature in a near future. They are looking for somebody who can handle that.
If I am waiting on that datatype too I prefer to wait some months before adding a new datatype in order to check that everything is ok for the monolingual datatype. Snipre (talk) 14:51, 2 September 2014 (UTC)
OK, lets look again in a couple of months. By then we have been waiting for a year. Most of the time with the expectation, that it will be here in a few months time. -- Poul G (talk) 00:11, 3 September 2014 (UTC)

Classes for properties ?

Hi,

For some times, I’m wondering : shouldn’t there be classes for properties ? (maybe « class » isn’t the most appropriate world) For instance :

Is it a good idea or just a fool’s thought ?

Cdlt, VIGNERON (talk) 17:19, 2 September 2014 (UTC)

@VIGNERON: I think there have been discussions about this in the past which always had some support. I certainly think that it is a good idea, because the properties, too, should have a semantic description with properties and not just labels and descriptions. -Tobias1984 (talk) 18:53, 2 September 2014 (UTC)
Adding statements to properties is work in progress right now. We've just cleared one huge blocker for it. We should make progress in this sprint and hopefully finish it in the next sprint. --Lydia Pintscher (WMDE) (talk) 09:10, 3 September 2014 (UTC)

WP include gadget no longer working?

I've just woken up and gone to Wikidata and the gadgets seem to have changed. Yesterday, I was using a gadget that showed me a small preview of the linked English Wikipedia article—just the first paragraph or so. It seems to have disappeared overnight. It is ludicrously useful for patrolling and cleaning up issues—I'm currently going through and checking hundreds of GerardM's high-speed, semi-automated edits and the lack of this gadget has doubled the number of clicks I need to do to check most of the claims. —Tom Morris (talk) 07:03, 3 September 2014 (UTC)

MediaWiki_talk:Gadget-Preview.js#Fix_gadget_for_new_sitelink_selectors Aude (talk) 08:07, 3 September 2014 (UTC)

Fix for draggable sitelinks: MediaWiki talk:Gadget-DraggableSitelinks.js. I can't look at all gadgets now, but others that might be affected:

Aude (talk) 11:10, 3 September 2014 (UTC)

Yes, move is probably affected too – it stopped working for me yesterday. Jon Harald Søby (talk) 18:22, 3 September 2014 (UTC)

bugfixes and suggestions for qualifiers and references

Hey folks :)

Yesterday we deployed new code. This includes among other things bugfixes for:

In addition you now also get suggestions when adding a qualifier or a reference.


Cheers --Lydia Pintscher (WMDE) (talk) 15:23, 3 September 2014 (UTC)

blog post by Histropedia

Hey folks :)

The guys behind Histropedia are pretty awesome and they are making cool use of Wikidata. I asked them to write a bit about how they use Wikidata and how they think they can help Wikidata in the future. http://blog.wikimedia.de/2014/09/02/why-wikidata-is-so-important-to-histropedia/


Cheers --Lydia Pintscher (WMDE) (talk) 15:24, 3 September 2014 (UTC)

P of Q

Q12280 (bridge) as a sample. To what class P does it appertain? And how I should search by myself? Say I need to make a CLAIM[all where P-something has value Q12280] --NeoLexx (talk) 15:28, 1 September 2014 (UTC)

Classes are Qitems just like instances are Qitems.
bridge (Q12280) has statements that it is a subclass of thoroughfare (Q83620) and of architectural structure (Q811979) so those are the classes it appertains to.
Pitems are properties, not classes. Filceolaire (talk) 16:58, 1 September 2014 (UTC)
Thank you for answering, but it doesn't really answer my question. As I said, I don't care about current Wikipedia — Wikidata relations, I am specifically interested for data queries to Wikidata directly, and they are basically build as "all items were this P is set to this Q". Say if want all wiki-notable Caucasian males, then it is gender=male and ethnic_group=Caucasian where keys are P and values are Q. And then CLAIM[21:6581097] AND CLAIM[172:7129609] (P21(gender)=Q6581097(male) and P172(ethnic group)=Q7129609(Caucasian race) and then voila.
So now irrespective to what P and Q really are (or meant to be initially), if I want to have the list of all bridges of some kind, I need to start with "where Pwhat? is Q12280 (bridge) and...". So how to find it and how to find any needed P overall? That remains my question, unless of course the database structure has changed recently and drastically comparing to the dump at wmflabs. --NeoLexx (talk) 18:45, 1 September 2014 (UTC)
instance of (P31) https://wdq.wmflabs.org/wdq/ You cannot search. You have to know. --JulesWinnfield-hu (talk) 19:10, 1 September 2014 (UTC)
Great thank you! So is it correct to say that it is decided to set an "universal key" P31 (get me all instances of) for data queries? --NeoLexx (talk) 19:25, 1 September 2014 (UTC)
In general all items have P31 property. You can have a view of properties at Wikidata:List of properties. --JulesWinnfield-hu (talk) 19:44, 1 September 2014 (UTC)
Yes, I see. Wikidata:List of properties/Generic is the most helpful for the moment. As a side note I see a contradiction there between the rightful suggestion to use more specific P rather than generic P31 and at the same time no way to identify that specific P from the current Q page (unless one knew it in advance). It should be propagated throughout somehow in the way male (Q6581097) is done, maybe. For my particular trouble I now see it in an extra semantic step comparing to mass databases. So instead of straight saying "give me all bridges/cities/males/... where (filters)" one needs to start with "give me all items where that property set to bridges/cities/males/... and where (filters)". Thank you again. --NeoLexx (talk) 20:29, 1 September 2014 (UTC)
P.S. Why currently so poor outcome sometimes? All wiki-notable Caucasian males gives whole 57 persons from all wikis across... All wiki-notable African American/Negroid homosexual males just one. wmflabs uses some light database dump just for testing or Wikidata is still so far from being filled? --NeoLexx (talk) 20:43, 1 September 2014 (UTC)
Your problem may be that wikidata has have a lot of dificulty with defining "Ethnic" group. A person has to self identify and apparently only one person identifies himself as "Negroid" ethnicity. Not surprising as 'Negroid' is not an 'ethnic' group. If you are looking for 'race' then we don't have a property for that as it is a social category pretending to be a scientific category. In practice pretty much everyone in the USA (for instance) would be classified as 'mixed' race because the nearly all have ancestors from more than one of the traditional (black, white, red, yellow) races.
ethnic group (P172):African Americans (Q49085) has nearly 8 thousand examples if that is any use to you but if 'Afro American' were to be a 'subclass' of some wider ethnic group then I would argue that it is a subclass of 'American' and not a 'subclass of:African'. An 'Afro American' is a type of 'American' not a type of 'African'. Just my opinion. Filceolaire (talk) 21:48, 1 September 2014 (UTC)
I am in a great doubt that Perry Watkins identified himself as a Negroid :-) And indeed it is said there African American. If you take a look at the request, it asks for "all males and (homosexual or gay) and (African American or Negroid)". And that gives only one person from wmflabs. And "all males and (homosexual or gay) and Caucasian" gives only 3 persons. So it must be something else to investigate yet.
As a side note I do not care any particularly about homosexuality or US ethnic questions, just a few complex and not so boring queries I constructed to teach myself the proposed query syntax. At the same time I deeply hope that we are not getting at the end a "politically correct database querying mechanics". The last thing the humanity needs is a politically correct robot with nug screens "The way you have tried to connect data is not acceptable for my electronic soul. Ask for something more salutary." :-) --NeoLexx (talk) 22:01, 1 September 2014 (UTC)
We already have a 'politically correct' database if by 'politically correct' you mean 'based on reliable sources'. There is no clear unambiguous definition for 'caucasian race' or even 'race'. These terms have been used for various political purposes so they will will not be used here. If you want to propose a property to record the race of persons as registered in various registration schemes that have existed in the USA, in Nazi Germany, in Apartheid South Africa then I would support that but it would not apply to people who were not registered under those schemes and there would be no reason to link 'White', 'Aryan', and 'Blank' in the same class.
As the database is 'politically correct' so the query results will be as well, no matter what the query mechanism is.
See also the discussion about sex or gender (P21). If we are using how a person dresses, or what their given name is, to determine their sex then we have no way of knowing for sure what their gender (or even their sex) is so we have agreed to have one general, unspecific, property for both 'sex' and 'gender'. Hope this helps. Filceolaire (talk) 21:49, 3 September 2014 (UTC)
On a completely unrelated topic, wikidata cannot give a good answer to the question 'What are the largest cities by population' either because for most large cities there is no agreed definition as to where the city extends - what should be included and where it stops. We can tell you the population of each 'administrative territorial entity' however. Filceolaire (talk) 21:55, 3 September 2014 (UTC)

Blue box around references

Why is there now a blue box around references? Is it part of the new UI? — Ayack (talk) 07:41, 3 September 2014 (UTC)

It's a bug (default jquery stuff overriding wikibase styles) and not supposed to be part of the design. We are investigating this. Aude (talk) 08:08, 3 September 2014 (UTC)
Ok, thanks. — Ayack (talk) 08:10, 3 September 2014 (UTC)
Actually, I found it nice (it emphasizes property separations), so I would vote for keeping it.--Ymblanter (talk) 10:27, 3 September 2014 (UTC)
It is inconsistent with other UI elements and should be removed. --Ricordisamoa 00:14, 4 September 2014 (UTC)

Hello. I can not add new interwiki links to any item. When I hit add, it shows a blank space where it is supposed to show a frame for the link. It does not happen if I try it while logged off. This is what I get: https://i.imgur.com/lnkqR60.png

I removed my user scripts, clear the cache and cookies, but the problem still exists. Allan J. Aguilar (Ralgis) 15:55, 3 September 2014 (UTC)

You can't because you have Twinkle enabled on your global.js on Meta. It's not working with Wikidata. You can exclude it from Wikidata, see instructions at https://www.mediawiki.org/wiki/Extension_talk:GlobalCssJs#Ability_to_exclude_a_wiki.3F_47286 --Stryn (talk) 18:52, 3 September 2014 (UTC)
Oh, I see. Thank you very much, Stryn. Allan J. Aguilar (Ralgis) 20:26, 3 September 2014 (UTC)

correct application of occupation:linguist

This belongs in a tea room, but AFAIK there isn't a tea room yet.

I studied linguistics in university and learned a number of subjects that collectively make linguistics, such as syntax, phonetics and phonology, and historical linguistics. These skills are what make a linguist.

Other professionals such as translators may know lots about one or more other languages, but they don't need any of those skills, and those skills do not make someone a translator, a poet, a novelist, etc. A translator knows one or two languages deeply, but a linguist should be familiar with every major language and at a different level. A translator does not need to know what a voiced labial plosive is.

If you throw a linguist into a village in the jungle where they speak an unknown language, the linguist can write a complete grammar of that language with details about phonology and syntax. A translator, poet, or a re-animated philologist might be able to learn the language, but they could not write a scholarly description of it.

Linguistics is mutually exclusive from being a translator, poet, author, playwright, or literary critic. It is similar to philology, but not the same, and why mark someone as a linguist when we can mark them as a philologist?

Yet currently we have several thousand people marked P107:Q14467526 (occupation:linguist) who are not linguists at all. To take a random example, w:P. Y. Saeki is not a linguist, and the English article at least does not use the word "linguist" or "lingu-" anything even once.

I'm looking for some widespread agreement that people like P. Y. Saeki were not linguists, and generally that P107:Q14467526 should be used more narrowly as a scientist of language rather than just anybody who used language professionally in some capacity. --Haplology (talk) 01:45, 4 September 2014 (UTC)

Try contacting GerardM. As far as I can tell, he is responsible for most of these problems (edits from last December) and he's recently shown a bit of willingness in correcting his mistakes. Pichpich (talk) 02:34, 4 September 2014 (UTC)

upcoming features and changes

Hey folks :)

We have quite a lot of changes lined up that are going to be deployed soon. Here's an overview of what's coming up. I hope we can stick to this but if there are any unforeseen issues we might have to delay some of it.


Tuesday August 19th
  • Wikinews will be able to manage its sitelinks via Wikidata
  • Wikidata will become its own client. This means you can for example add a sitelink to Wikidata:Help to the item for all main help pages. You will also be able to make use of the data in items on other pages in Wikidata with lua. (Arbitrary access will be enabled for Wikidata for this but when data in an item changes we will not be able to purge the page using the data yet.)
  • Sitelinks for projects with just one sitelink in the group (like Commons, Wikidata and in the future Meta for example) will be grouped together in one sitelink group.
  • Badges for good and featured articles can be stored on Wikidata right next to the sitelink. In a later roll-out we will make it possible to show them on the Wikipiedias and sister projects in the sidebar too. We will start with badges for featured and good articles. More can be added on request later. Thanks to Bene* and lazowik for this feature.
  • Redirects between items will be possible. When two items are merged one of them can then be turned into a redirect. This way our identifiers can be considered much more stable by 3rd parties for example. It will also make it unnecessary to delete duplicate items. This will hopefully reduce the workload of our admins considerably. For now redirects can only be created via the API.
  • We are introducing the new datatype monolingual text. This will allow you to make statements with a string and an associated language.

Please go and test these on test.wikidata.org and let me know if there are any issues.


Tuesday August 26th
  • The entity suggester will be able to suggest properties in qualifiers and references as well.
  • BREAKING CHANGE: We'll switch the internal serialization format to be the same as the one that is returned by the API. The xml dumps will also be adjusted then. If your tool relies on either the dumps or the internal serialization of an item page then it will likely need to be adjusted. (This is one of the remaining blockers for statements on properties and further progress on Commons support.)
  • We'll deploy the "in other projects" sidebar as a beta feature to Wikipedia, Wikisource and Wikiquote. This way you will see links in the sidebar of Wikipedia for example linking to Commons, Wikivoyage, Wikisource and so on. This can be configured per-wiki. Thanks to Tpt for this feature. (Wikipedias will get this 2 days later.)
  • We will make it possible to show badges from Wikidata in the sidebar on Wikipedia and co.

Cheers --Lydia Pintscher (WMDE) (talk) 18:12, 15 August 2014 (UTC)

Thanks for this new features. I hope this will give new reasons for contributors to use WD. Just remain the quantity with unit datatype and the arbitrary access to another item to offer the full use in WP. Do you think these two features will be ready for end of the year ? Snipre (talk) 19:27, 15 August 2014 (UTC)
I'm trying to find someone to work on units. (Any takers? Contact me!) Arbitrary access we will start this year. I hope we can also get at least an initial version out this year. --Lydia Pintscher (WMDE) (talk) 19:32, 15 August 2014 (UTC)
Great update! I cannot wait to see arbitrary access and units! --Micru (talk) 09:55, 16 August 2014 (UTC)
I get “Lua error in mw.wikibase.lua at line 74: Access to arbitrary items has been disabled.” --JulesWinnfield-hu (talk) 22:11, 15 August 2014 (UTC)
Where do you get this? What exactly were you trying to do? --Lydia Pintscher (WMDE) (talk) 08:36, 16 August 2014 (UTC)
This is really exciting! @Lydia Pintscher (WMDE): for the "in other projects", is Wikivoyage getting it too? --Rschen7754 02:23, 16 August 2014 (UTC)
Wikivoyage already has its related sites thing. We'll need to figure out how to make that play together nicely. But I think in the long run we can replace that. --Lydia Pintscher (WMDE) (talk) 08:36, 16 August 2014 (UTC)
Good news! @Lydia Pintscher (WMDE):, does the change in internal serialization format affect the entity objects given to clients using mw.wikibase.getEntityObject in Lua modules? If so, you are likely to break fetching of Wikidata data in the Wikipedias. Regards, Dipsacus fullonum (talk) 05:11, 16 August 2014 (UTC)
No that should not be affected. The Lua part that will be affected is the usage on Lua here on Wikidata itself to fetch data from items in a hackish way. --Lydia Pintscher (WMDE) (talk) 08:36, 16 August 2014 (UTC)
Arbitrary access doesn't work on test2wiki https://test2.wikipedia.org. Lua doesn't work on testwikidata https://test.wikidata.org. Where can be tested these things? --JulesWinnfield-hu (talk) 09:17, 16 August 2014 (UTC)
@JulesWinnfield-hu: arbitary access has been enabled on test.wikipedia.org .--Snaevar (talk) 13:24, 16 August 2014 (UTC)
@Snaevar, Lydia Pintscher (WMDE): I get the same error “Lua error in mw.wikibase.lua at line 74: Access to arbitrary items has been disabled.” there too. Wikidata related tests are on test2wiki. Could you please enable also on test2wiki? So far works nowhere. --JulesWinnfield-hu (talk) 17:36, 16 August 2014 (UTC)
The features are not being enabled until Tuesday. John F. Lewis (talk) 17:38, 16 August 2014 (UTC)
@John F. Lewis, Lydia Pintscher (WMDE): Well, it's after Tuesday and nothing changed. --JulesWinnfield-hu (talk) 08:41, 20 August 2014 (UTC)
Have you tried to purge the page (?action=purge)? Sjoerd de Bruin (talk) 09:06, 20 August 2014 (UTC)
Finally I've seen it here on Wikidata. Thank you. --JulesWinnfield-hu (talk) 09:17, 20 August 2014 (UTC)
Does anybody know if arbitrary access has been enabled on the test version of Commons? Or would it be best for the time being to use test.wikipedia.org for templates for future use on Commons? Jheald (talk) 13:48, 16 August 2014 (UTC)
It is only enabled on test.wikidata.org - not on any other wiki yet. And it will only be enabled on wikidata.org next week. Sorry if that was unclear. So what you will be able to do is access the data of an item on another page on this wiki. You can of course use this to build some demos on test.wikidata.org. --Lydia Pintscher (WMDE) (talk) 16:40, 16 August 2014 (UTC)
Good news, even if I don't understand everything and consequences on everyday use of wd :D
as for redirections, that's a very good thing as merging of items and rfd is really getting overcrowded, even without "The Game". --Hsarrazin (talk) 13:14, 16 August 2014 (UTC)
I know I'm late but this is great! Thank you Lydia!! --AmaryllisGardener talk 00:47, 20 August 2014 (UTC)

How to use arbitrary access?

I'm a bit confused, is the inclusion syntax in meta still valid? meta:Wikidata/Notes/Inclusion_syntax. I'm trying this, but I get no output. I'm also unable to create content pages in ns0...--Micru (talk) 22:17, 16 August 2014 (UTC)

Hmmm it seems the patch for the property parser function didn't make it in :( I should have noticed this and mentioned it... Sorry. Tracking of that part is at bugzilla:68029. So for now only Lua and we'll add the property parser function with one of the next deployments. The ticket is on the board for this sprint. --Lydia Pintscher (WMDE) (talk) 10:29, 18 August 2014 (UTC)
@Micru:. In any case, it seems that the parser function would only return results in Wikidata's default language (English). Alternatively, you can use {{Data}} that is localized {{data|property=P569|item=Q76}} -> .--Zolo (talk) 10:11, 31 August 2014 (UTC)

Multilingual text datatype

Is the multilingual text datatype still on schedule, or has it been canceled? Consequently, should we wait for it or work on a solution based on monolingual text datatype? --Shlomo (talk) 22:34, 19 August 2014 (UTC)

It's still scheduled :) --Lydia Pintscher (WMDE) (talk) 06:07, 20 August 2014 (UTC)
Is number with units coming first, though? --Jakob (talk) 16:46, 20 August 2014 (UTC)
I don't know yet. I'll try to have units first though. --Lydia Pintscher (WMDE) (talk) 19:38, 21 August 2014 (UTC)

Badge colours

Wouldn't it make more sense for Good Articles to have silver badges, and Featured Articles, gold ones? It Is Me Here t / c 23:42, 19 August 2014 (UTC)

Agreed. --Jakob (talk) 00:01, 20 August 2014 (UTC)
We accidentally mixed them up in the config. Will be fixed. --Lydia Pintscher (WMDE) (talk) 06:07, 20 August 2014 (UTC)
@Lydia Pintscher (WMDE): That's fixed since, like, 11 hours or so :D Lazowik (talk) 09:59, 20 August 2014 (UTC)
@Lazowik: I can't see the fix (in Q77). --Ssola (talk) 16:20, 20 August 2014 (UTC)
@Ssola: Works for me. E.g. dewiki has good article and has silver icon. Maybe clear your browser's cache? Lazowik (talk) 23:45, 20 August 2014 (UTC)
Finally working :) --Ssola (talk) 16:36, 21 August 2014 (UTC)

Now is possible to attach 2 badges to one sitelink, see [1]. Do it have some advantage or it's only bug? --KuboF (talk) 23:57, 19 August 2014 (UTC)

That's intended yeah. In the future we will have more badges and it might make sense for a sitelink to have several of them. --Lydia Pintscher (WMDE) (talk) 06:08, 20 August 2014 (UTC)
But I suppose article should not be badged as "featured" and "good" in the same time. Maybe should exist some groups of badges, inside of which only one can be used. But, supposedly, it varies from wiki to wiki. --KuboF (talk) 15:27, 20 August 2014 (UTC)
WikiProjects on en.Wikipedia can have multiple different ratings for an article, because there are mutliple projects per article. --Izno (talk) 19:01, 24 August 2014 (UTC)

Monolingual text structure

Can somebody please help me with lua access to the monolingual text? Special:ListDatatypes suggests to use language and value; but while the datavalue.value.language works fine, datavalue.value.value doesn't. See [2], line 134.--Shlomo (talk) 11:50, 21 August 2014 (UTC)

✓ Done The access is not through value, but text. Can somebody correct it in the list? It's a "Special:" page and I don't know, how to change it.--Shlomo (talk) 13:29, 21 August 2014 (UTC)
Apparently, no one can... :( --Shlomo (talk) 13:48, 28 August 2014 (UTC)

Whyyyyy????? At labels and descriptions is (language, value), at snak value is (text, language). Why are there two implementations? Why had to be implemented for the second time? --JulesWinnfield-hu (talk) 14:03, 21 August 2014 (UTC)

Bug in the UI

Another problem with the monolingual text in the Wikidata UI: when trying to change an already existing statement, I get the field to change the text, but I can't change the language. I had to delete the statement and recreate it with the correct value.--Shlomo (talk) 19:22, 21 August 2014 (UTC)

Can you please post a link to an item where you had this problem? --Lydia Pintscher (WMDE) (talk) 19:40, 21 August 2014 (UTC)
Q13222899.--Shlomo (talk) 19:58, 21 August 2014 (UTC)
Hmmm I can: https://www.wikidata.org/w/index.php?title=Q13222899&diff=152337576&oldid=152255832 Did you click in the text box? Then another one should pop up where the language is shown. --Lydia Pintscher (WMDE) (talk) 07:59, 22 August 2014 (UTC)
That's it. I didn't click the text box, since I wasn't going to change the text, only the language... With a click on the text box it works. Not very intuitive, though. A little bit like the old Snoozleberg game - try clicking everything, something should work...--Shlomo (talk) 09:03, 22 August 2014 (UTC)
Heh yeah totally. My plan was to have a separate field for the language before the actual text. However the current code makes that very hard. We'll have to do some major refactoring first. Until then this hopefully works. --Lydia Pintscher (WMDE) (talk) 10:19, 22 August 2014 (UTC)
As long as there's a project chat, where we can ask and get a quick answer, it's not so bad. And I'm aware that there are many other important tasks to do...--Shlomo (talk) 11:59, 22 August 2014 (UTC)

How to unmark badge(s) of a sitelink?

E.g. the zhwikivoyage link of Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License (Q3910767). --Liuxinyu970226 (talk) 12:43, 5 September 2014 (UTC)

Mnn I've found answers below: #Removing badge. --Liuxinyu970226 (talk) 12:52, 5 September 2014 (UTC)

Huh?

What happened to Q17831325? I created it through widar earlier today, it is linked to from nl:Ciwaringin, but... I'm totally puzzled. Lymantria (talk) 15:04, 3 September 2014 (UTC)

Looks normal to me. What specifically is wrong? --Lydia Pintscher (WMDE) (talk) 15:24, 3 September 2014 (UTC)
I get the Dutch message: "Wikimedia Foundation - Fout (Error) - Onze servers hebben op dit moment een technisch probleem (Our servers experience a technical problem at the moment)" etc. Lymantria (talk) 16:31, 3 September 2014 (UTC)
P.S. I just want to add that it is a disambiguation page. Lymantria (talk) 16:39, 3 September 2014 (UTC)
When I try to edit it with the interface, I got a 500 Internal server error. --Dereckson (talk) 16:47, 3 September 2014 (UTC)
Hmmm something is indeed broken there. I can load it but when I try to add a statement entering the property doesn't do anything. Anyone seeing issues anywhere else? Or is it just this item? --Lydia Pintscher (WMDE) (talk) 17:29, 3 September 2014 (UTC)
Same for me, an attempt to add an English title gives 500 server error.--Ymblanter (talk) 18:03, 3 September 2014 (UTC)
I can read the item now, but indeed not add a property. Lymantria (talk) 05:13, 4 September 2014 (UTC)

https://bugzilla.wikimedia.org/show_bug.cgi?id=70347 is the error (from the logs) when I try to add a label to that item. I am not quite sure why and need to investigate. Aude (talk) 19:38, 3 September 2014 (UTC)

Thanks. Lymantria (talk) 05:13, 4 September 2014 (UTC)
The item works now. Problem was it was missing in the wb_entity_per_page table in the database. I ran a script to add missing entries to the table. Aude (talk) 09:40, 4 September 2014 (UTC)
Thank you. Lymantria (talk) 18:41, 5 September 2014 (UTC)

Diff size?

Why is this diff of my edit today marked as having +8377 bytes? I have made a number of similar edits, and most of them are marked as having reasonable size (+20 or smth).--Ymblanter (talk) 16:52, 5 September 2014 (UTC)

This is because of the change in the internal serialization format (e.g. what is stored in the database) to the api format. The format is more verbose, hence the diff size, but nothing to be concerned about. Aude (talk) 17:00, 5 September 2014 (UTC)
Thanks Katie.--Ymblanter (talk) 17:03, 5 September 2014 (UTC)

People who born and died in same day

Hello, My bot made a mistake and added 16 birth dates to P570 (death date). To get that information I wrote a script and get list of people who have same birth and death date (precision 11, means just birth dates like year-month-day) surprisingly 692 items has the same issue. I fixed my bot's mistakes but others need to be checked by hand because It didn't happen automatically. the list is here. Please check and fix them. Any suggestion or comment is welcome Amir (talk) 22:35, 26 August 2014 (UTC)

Interesting. I checked one of them (Armand Schulthess (Q677828)). The birthdate is sourced as stated in (P248) Integrated Authority File (Q36578). The source indeed states the birthdate as 1972-09-29 which really is the deathdate. I wonder if many of these items have the wrong data due to error in the sources. Regards, Dipsacus fullonum (talk) 06:52, 27 August 2014 (UTC)
very interesting. Thanks, maybe some were introduced through "The Game", as it accidentally happened to me once or twice, AFAIK... and I reported on Bitbucket for a fix to prevent it.
the list should be updated by people who correct items, since almost all those I checked were already corrected. --Hsarrazin (talk) 07:12, 27 August 2014 (UTC)
I've been through many of these and most of them are from various bots, and they mostly cite en.wiki, so I assume that means that the bots got the (wrong) date from en.wiki. --Haplology (talk) 00:19, 28 August 2014 (UTC)
As noted earlier, WEF Framework seems to allow such additions. Here is a recent sample [3]. --- Jura 14:03, 30 August 2014 (UTC)
Can you explain in the report how you generated it? Then we could re-run it to get a list of outstanding items (and again in future to detect future errors by future bots). 101.115.25.85 14:25, 6 September 2014 (UTC)

Need help with Lua

Does anybody know what happens ? In Module:Artwork, line 192, when I write 

local id = j.mainsnak.datavalue.value['numeric-id']

I get an error "attempt to index field 'mainsnak' (a nil value)." (see Template:Artwork/testcases). And yet this should not be a nil value. If I replace it with 

if true then return j.mainsnak.datavalue.value['numeric-id'] end

I get the numeric ID all right.--Zolo (talk) 16:35, 5 September 2014 (UTC)

What is the item? Probably there are some no value snaks and you skip them with the return. --JulesWinnfield-hu (talk) 17:47, 5 September 2014 (UTC)

I thnk that the problem is this --ValterVB (talk) 17:49, 5 September 2014 (UTC)
@JulesWinnfield-hu. These are the depicts (P180) values of Portrait of Philip the Good, Duke of Burgundy (Q17334940). There are no special values, but you are right that the issue arises only for some statements, and that it is the reason why it does not show when using "return". So yes perhaps at internal issue. --Zolo (talk) 18:20, 5 September 2014 (UTC)

You mess up the variables. You index maindepiction inside the loop with self elements, then you use depictedpersonstring and otherdepictionsstring which have no assignment statements. --JulesWinnfield-hu (talk) 18:52, 5 September 2014 (UTC)

Ooops yes, it should have been maindepiction[i] not maindepiction[j], pretty stupid ! (the rest is because I had left things unfinished because it did not work). Thanks ! --Zolo (talk) 19:18, 5 September 2014 (UTC)
@Zolo: Why did not you use your Wikidata module to make this call ? would reduce this kind of errors, all these thing.foo.bar["wow"] are really a bad copy/paste smell, prone to error and not exactly easy to maintain. TomT0m (talk) 09:44, 6 September 2014 (UTC)
@TomT0m: I'll try but I am not sure the module can really do that at the moment. --Zolo (talk) 17:42, 6 September 2014 (UTC)

Some way to visually identify redirects?

Hi, I'm working on merging items listed in User:Byrial/countrymerge and I would really appreciate if I could use some scheme to visually recognize if the target item of a given link is a redirect, a bit like the red link (Q17105557) quickly shows that the target is a deleted page. Is there some gadget or other scheme to identify redirects without having to follow the link? LaddΩ chat ;) 14:08, 6 September 2014 (UTC)

Copy and paste .mw-redirect { color: #006633;}.mw-redirect:visited { color: #009900;}.mw-redirect:hover { color: #990000;}.mw-redirect:active { color: #990000;} in your css. All redirect will be green. --ValterVB (talk) 14:20, 6 September 2014 (UTC)
Whoooooooah! Great scheme thanks ValterVB ! :D LaddΩ chat ;) 15:14, 6 September 2014 (UTC)

List of properties by data type ?

Do we have a list of properties by data-type ?

Or (better): Is there a way to write a query to return this ?

For example: all properties which can return a Commons Media File; or all properties which must return an item.

Links to such a list or such queries would (IMO) be a useful addition to Help:Data type and WD:P. Jheald (talk) 14:50, 6 September 2014 (UTC)

Two things which are curious: It seems eg "Commons media file" can't be reliably searched for using Advanced search with the Property name space; nor does it appear to have a Q-number. Jheald (talk) 14:59, 6 September 2014 (UTC)
AFAIK Wikidata has only one data-type "string". You may request all entries with a certain property(s) filled or all entries with a certain property(s) still empty. Say to get a list of all bridges across the Danube with Commons categories do:
https://wdq.wmflabs.org/api?q=claim[31:(TREE[12280][][279])]%20AND%20claim[177:1653]%20AND%20noclaim[373:4294967295]
where noclaim for P373 (Commons category) if its property equals to Q4294967295 ('no value'). See details at https://wdq.wmflabs.org/api_documentation.html --NeoLexx (talk) 15:43, 6 September 2014 (UTC)

Try Wikidata:Database reports/Constraint violations/All properties --- Jura 15:51, 6 September 2014 (UTC)

Nice! That was exactly what I was looking for, and more. Jheald (talk) 16:02, 6 September 2014 (UTC)
@Jheald: See Wikidata:List_of_properties/all_in_one_table 178.237.94.235 19:51, 6 September 2014 (UTC)
Thanks. I did eventually find that too, but Jura's link is nicer: it has links to the properties, counts the number of occurrences, summarises all the other constraints they need, and appears to be more up to date. Given all that, perhaps the link you give should be turned into a redirect. Jheald (talk) 20:06, 6 September 2014 (UTC)

problems linking - Pyramid G1-d

Greetings, all,

I have problems linking articles en:Pyramid G1-d and fr:Pyramide G1D. Error messages are: 'An unexpected error occurred: $1.', and then 'Invalid token'.

Regards, Y-barton (talk) 16:38, 6 September 2014 (UTC)

Hi, Y-barton. Have you tried doing it on Wikidata itself? There is a bug related to this if you try to do it directly from Wikipedia, see bugzilla:70415. The bug is fixed and will be deployed on Monday, so from then on out it should work normally again. Jon Harald Søby (talk) 17:21, 6 September 2014 (UTC)
Thank you, Jon. I didn't even know that one can also do this from Wikidata. I think I'd better wait when the thing is fixed, and then do it the old way. :) Y-barton (talk) 02:49, 7 September 2014 (UTC)

stored to display time value conversion

It took me quite a time to correctly code the following algorithm in LUA. Hope, you will find it useful.

The TimeValue always stored as proleptic Gregorian calendar (Q1985727) whatever interface said. There are several problems on Wikidata and Wikipedia sides with those:

So in ruwiki there is an updated w:ru:Module:Wikidata/date that handles conversion from TimeValue to string. It works like that:

  • If calendarmodel is proleptic Gregorian calendar (Q1985727) just show the date
    • for dates before 1582-10-15 it means some bot (or user) incorrectly entered Julian date as Grigorian. No big deal for us (on Wikipedia side). Display as it is, and categorization is still correct, because for dates before 1582-10-15 it is always Julian-based
    • for dates after 1582-10-15 it means (from module point of view) that date is correctly presented as Grigorian. No conversion is required.
  • If calendarmodel is proleptic Julian calendar (Q1985786), one of three choices (made by formatAsJulian procedure)
    • for dates before 1582-10-15 it means date is correctly stored in Wikidata in proleptic Gregorian calendar (Q1985727) but need to be converted and displayed as simple proleptic Julian calendar (Q1985786) date
    • for dates between 1582-10-15 and 1918-01-26 LUA module converts stored Gregorian date to Julian and displays "mixed" date strings
    • for dates after 1918-01-26 LUA module displays error, because it is meaningless to display dates after 1918-01-26 in Julian calendar

Hope this helps you for your local wikis -- Vlsergey (talk) 04:10, 4 September 2014 (UTC)

Thank you for the clarifications. If I understand correct, an editor or bot have to manually convert a proleptic Julian calendar (Q1985786) date to a proleptic Gregorian calendar (Q1985727) date before entering it to Wikidata. I know I have failed to do so in some cases, because I thought that Wikidata would do the conversion, and others may also have failed to do the conversion themselves. So I suspect that any date in Wikidata currently marked as being proleptic Julian calendar (Q1985786) could be wrong because it was not converted by the editor before entering. That seems a mess. Regards, Dipsacus fullonum (talk) 07:34, 4 September 2014 (UTC)
The UI converts it automatically, only the bots entered wrong dates, without conversion. --JulesWinnfield-hu (talk) 08:07, 4 September 2014 (UTC)
It does not seem that the UI converts dates. I sat publication date (P577) in the sandbox item to 1 Januar 1000 (Julian) with the UI. And the API for bots report the claim as:
<property id="P577">
  <claim id="Q4115189$79e35a6a-4ca2-3b9b-cb18-acb6239645fe" type="statement" rank="normal">
    <mainsnak snaktype="value" property="P577" datatype="time">
      <datavalue type="time">
        <value time="+00000001000-01-01T00:00:00Z" timezone="0" before="0" after="0" precision="11" calendarmodel="http://www.wikidata.org/entity/Q1985786" />
      </datavalue>
    </mainsnak>
    <qualifiers />
    <qualifiers-order />
  </claim>
</property>
So, the date entered and shown in the UI seems not to be converted. Regards, Dipsacus fullonum (talk) 08:57, 4 September 2014 (UTC)
You are right. Not very long ago it worked as it should. It doesn't work now. --JulesWinnfield-hu (talk) 09:42, 4 September 2014 (UTC)
As I see "time" parameter contains Jullian date if "calendarmodel=Q1985786". It is displayed in used-friendly and bot-friendly format "+00000001541-12-07T00:00:00Z calendarmodel=Q1985786" = "December 7, 1541Julian", we need convert nothing in this case. The only place where we have error is documentation that says "time is always saved in proleptic Gregorian". We need change it to "time is saved in format specified in calendarmodel parameter". — Ivan A. Krestinin (talk) 19:43, 4 September 2014 (UTC)
@Ivan A. Krestinin: To save time in any possible caledarmodel in future (to actually save it, not just display) the core would need to understand how those calendar system works, including Japaneese calendar, Hebrew and Maya ones. Otherwise it will became just another "string" field, without any possibility for range queries. Thus I don't think it is appropriate to make Wikidata core to handle those things. It is much better to save it in single uniform format (like proleptic Gregorian) and let user interface decide how to display and interpret it. Also, it is not simple "just change documentation". There is already thousands of data moved (not copied!) to Wikidata from ruwiki, and i would be strongly oppose to such changes in existing fields -- because they will became invalid. -- Vlsergey (talk) 03:15, 5 September 2014 (UTC)
It is not very good idea use Wikidata in current situation. Different items uses different format currently. Many items contains invalid values at all die to bot`s bugs. Wikidata core does not process dates. Uniform format requires processing on core/API side. Date conversion algorithm is non-trivial. It is better do not use it on any side. — Ivan A. Krestinin (talk) 10:46, 6 September 2014 (UTC)
works for me. -- Vlsergey (talk) 11:59, 6 September 2014 (UTC)

The the term "proleptic Julian calendar" is confusing. The Julian calendar was used consistently and correctly throughout Europe and some parts of western Asia beginning March 1, AD 8. Before that leap years were not always observed every 4 years as ordered by Julius Caesar in 46 BC, and historical records do not allow reconstructing exactly how leap years were observed. So in one sense the proleptic Julian calendar consists of extending the Julian calendar backwards from March 1, AD 8, following the rules that were observed after that date.

Another complication was that the Anno Domini year numbering system was not followed in all the countries that used the Julian calendar until 1700.

A third complication is that many countries did not begin the year on January 1. The last country I know of to switch to January 1 for the beginning of the year was England, in 1752 (which is also the time they changed to the Gregorian calendar).

So the term "proleptic Julian calendar" should be better defined, and perhaps replaced with a better term. Jc3s5h (talk) 16:04, 7 September 2014 (UTC)

Latin had no letter J until after Medieval era; thus, pages claining either Latin or Greek with a J are in error

this route to gain access was taken to get WIKIDATA to correct Wikipedia's pages on Origins of alphabet letter J. – The preceding unsigned comment was added by 70.161.110.183 (talk • contribs).

(Moved from Wikidata:Requests for comment/Latin had no letter J until after Medieval era; thus, pages claining either Latin or Greek with a J are in error.--GZWDer (talk) 15:29, 6 September 2014 (UTC))

The la. code seems to encompass all latin forms, including lat-cla and lat-med. I also note there are not ISO 639-3 codes to distinguish among these forms.
So to consider it an error, you have first to define what latin is. On Wikipedia, la:Lingua_Latina#Historia gives a good overview. --Dereckson (talk) 22:38, 6 September 2014 (UTC)
Note that you can provide an alias with the alternative spelling so that searches will find the item whichever spelling is searched for. Filceolaire (talk) 01:30, 7 September 2014 (UTC)
For reference, the section below titled #Workshop: Greek and Latin in an Age of Open Data might be of interest. Waldir (talk) 17:40, 7 September 2014 (UTC)

On Italian Project chat we want add on the left column the list of Project chat like here, but Project:Village pump (Q16503) is alredy used with Wikidata:Project chat. Someone know how to solve the problem? --ValterVB (talk) 15:45, 6 September 2014 (UTC)

It's not possible. Also the same applies e.g. for the main page of Commons. If you use other than the English version of the main page (like https://commons.wikimedia.org/wiki/Etusivu), you won't see the links. --Stryn (talk) 19:50, 6 September 2014 (UTC)
I would like to move Wikidata:Project chat to Wikidata:Project chat/en and create a new "interlanguage" page Wikidata:Project chat like this:
{{#ifexist:Wikidata:Project chat/{{int:Lang}} | {{Wikidata:Project chat/{{int:Lang}}|lang={{int:lang}}}} | {{Wikidata:Project chat/en|lang=en}} }}
so all languages chat can have on the left column the list of Project chat like here. (the code is the same as the main page). --FRacco (talk) 21:48, 6 September 2014 (UTC)
Well, that would be a one solution. If it works, and doesn't cause any problems, I would support the idea. However if we click "edit" on the project chat page then, there's only the ifexist code you gave above. So how we fix that? --Stryn (talk) 08:45, 7 September 2014 (UTC)
Yes, you are right :(
"edit" and "talk page" doesn't work in that way! We did that in Italian Main Page, but usually you don't use "edit" in main page, here is different! But I think we have to solve the problem, because all commons and wikidata pages have the same problem. Probably we have to change the structure of sitelinks or remove all commons and wikidata links - because at this moment they are wrong! --FRacco (talk) 16:18, 7 September 2014 (UTC)

Q18000000

Is created by myself:)--DangSunM (talk) 00:41, 7 September 2014 (UTC)

please document it a little (add claims), so that non-corean users can understand if it's a person, a bridge, or anything else ;) --Hsarrazin (talk) 00:49, 7 September 2014 (UTC)
@분당선M: Agreed - LaddΩ chat ;) 01:04, 7 September 2014 (UTC)
The sheer size and speed of growth of Wikidata amazes me. I think that by page count, we will soon be the largest Wikimedia project. --Jakob (talk) 01:18, 7 September 2014 (UTC)

I made English label, description, and some statements, for @Hsarrazin, Laddo: :D — by Revicomplaint? at 03:51, 7 September 2014 (UTC)

Sounds like a nice subject. If I find English (or any Latin-graphics) sources I will create an English article.--Ymblanter (talk) 08:28, 7 September 2014 (UTC)
@Hym411: thanks :)--Hsarrazin (talk) 08:40, 7 September 2014 (UTC)
@Ymblanter:If you couldn't find one, tell me and I can make it with Korean sources (if allowed). @Hsarrazin: No problem :D — by Revicomplaint? at 08:46, 7 September 2014 (UTC)
It is certainly allowed, as soon as the sources are reliable. I will have a look later today.--Ymblanter (talk) 09:35, 7 September 2014 (UTC)

Sorry that I didn't add the statements. Because I curruntly having script problem so I coudn't add or editing the statement for now. Thanks for Hym411 for doing the work instead for me:)--DangSunM (talk) 10:20, 7 September 2014 (UTC)

Workshop: Greek and Latin in an Age of Open Data

This event, at the University of Leipzig in December, may be of interest: Workshop: Greek and Latin in an Age of Open Data. It would be good to have somebody there to represent and speak about Wiktionary and Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 7 September 2014 (UTC)

Broken?

I just tried and failed to link en:Maup Caransa to Q2586638; I got an error message saying "invalid token" (with the mysterious symbol $1 !) I recalled reading at en:Wikipedia:Village Pump (technical) about someone else being unable to link articles here, but they had been able to do so by directly editing the item, so I tried that, but English wasn't in the list of Wikipedias, it was only at the top, so I added it there but no apparent success (maybe there is a massive lag). Is something broken in the mysterious guts of this project with all its floaty stuff, and if so, did you all know? Yngvadottir (talk) 16:16, 7 September 2014 (UTC)

@Yngvadottir: See Wikidata:Contact_the_development_team#Une_erreur_inattendue_s.E2.80.99est_produite_:_.241_.2F_Invalid_token, it seems it would be fixed next Monday. LaddΩ chat ;) 16:26, 7 September 2014 (UTC)

Pages loading time

Germany (Q183). Loading time (no debug mode, no gadgets, Windows 7, iCore i5 / 64 Gb, Firefox stable): 40 (forty) seconds. Also Firefox asked twice if I would like to stop JQuery JS execution. I believe this is inappropriate. Well, 1Mb per page (257991 in GZip) doesn't look nice neither. -- Vlsergey (talk) 21:35, 25 August 2014 (UTC)

  • It is really amazing how poorly browsers perform with Wikidata or very long pages on Wikipedia. Just out of interest is this more a problem of Wikipedia or the browsers? I also tried opening a 10 mb Wikidata dump file recently and Gedit too has problems with that. Is that the point where one should go shopping for a server CPU with 12 cores? -Tobias1984 (talk) 12:16, 26 August 2014 (UTC)
Noted :) Germany is an extreme case of course in comparison to most of the other items we have. Nonetheless we need to improve page loading times more. And we will. We'll hopefully make significant progress on this again during the UI redesign as a lot of code is being rewritten. --Lydia Pintscher (WMDE) (talk) 06:22, 4 September 2014 (UTC)

The poor perfomance affects Wikipedia articles, which relay on the wikidata. For example the corresponding article pl:Niemcy almost always is found in the category with broken scripts due to timeout for script execution. The internal comments with Lua profile data taken from broken page is as follow: 

Lua time usage: 11.186/10.000 seconds
Lua memory usage: 19.77 MB/50 MB
Lua Profile:
   Scribunto_LuaSandboxCallback::getEntity                         8600 ms       93.9%
   Scribunto_LuaSandboxCallback::getExpandedArgument                240 ms        2.6%
   Scribunto_LuaSandboxCallback::fetchLanguageName                  120 ms        1.3%
   recursiveClone <mwInit.lua:32>                                    60 ms        0.7%
   type                                                              40 ms        0.4%
   <mw.language.lua:62>                                              20 ms        0.2%
   [others]                                                          80 ms        0.9%

I think that for extreme cases there should be provided some cache, or function getEntity should be excluded from calculating the time used for Lua scripts. Is there a corresponding case in bug tracker available? Paweł Ziemian (talk) 15:51, 7 September 2014 (UTC)

There are pages with the same problem here on Wikidata (Wikidata:List of properties/Generic) and on huwiki. --JulesWinnfield-hu (talk) 17:15, 7 September 2014 (UTC)
But in Wikipedia articles there is enabled access only to corresponding data in Wikidata. I wonder if the data are retrieved once at the first call to getEntity, or once per each #invoke of Lua module, or (the worst) per each call to getEntity. Paweł Ziemian (talk) 21:57, 7 September 2014 (UTC)
I guess it is the worst, once per each getEntity. --JulesWinnfield-hu (talk) 23:14, 7 September 2014 (UTC)
What needs to be done is to change the modules, that are used on those wikipedia pages, to use mw.wikibase.entity.create( mw.wikibase.getEntityObject() ). Doing so will reduce the time used for :getEntity. This has allready been done with Module:LoP row, which is transcluded on the Wikidata:List of properties pages. That fact also is one of the reasons why the main issue of the Wikidata:List of properties pages is overuse, not performance.--Snaevar (talk) 22:18, 7 September 2014 (UTC)
I don't think so. --JulesWinnfield-hu (talk) 23:14, 7 September 2014 (UTC)
Tracked in Bugzilla
Bug 62707

Is there a possiblity to remove (unlink) a wikipedia link? What I want to do: remove the de.wp link in Q2133472. There is only an option to add a new link or edit an existing link but no choice to remove an existing link.--Wdwd (talk) 09:41, 6 September 2014 (UTC)

Click Edit and then Remove. --ValterVB (talk) 09:52, 6 September 2014 (UTC)
Thanks. Due to some client side javascript issues (jquery bugs - stops working on this page) i come to this page when i click edit. On this page there is no "Remove". Is there any possibility to remove a link whithout using client side scripts and/or direct API calls?--Wdwd (talk) 17:35, 6 September 2014 (UTC)
@Wdwd: If you clean the field, the link should be removed. Does it work for you? There has been some issues with it before, so I'm asking. Matěj Suchánek (talk) 18:35, 6 September 2014 (UTC)
Thanks for the hint, it doesn't work. I add the german wikipedia link again. Then I try to remove the site link on this page Special:SetSiteLink/Q2133472/dewiki by removing the text "Rauschartigkeit" and click on the tab "set the site link". The site link still remain. Without any error message. When i try to enter a dummy text, e.g. a single space " ", i got the error The specified article could not be found on the corresponding site.--Wdwd (talk) 22:02, 6 September 2014 (UTC)
I removed it for you. Please use a decent JS browser, like the last version of (not too heavily modified) Firefox, IE, Chrome, Safari or Opera. Among this list, you'll probably get the best support on Firefox and Chrome. --Dereckson (talk) 22:43, 6 September 2014 (UTC)
The problem is perhaps that the javascript takes too long to load and finally dies before all widgets are initialized. This is the old loading issue. The special page issue is bugzilla:62707. -- Bene* talk 17:50, 8 September 2014 (UTC)

Article name from P

Say I got a set of bridges meeting the requested criteria. Among them Tower Bridge (Q83125). Is there currently a property P to query its English value "Tower Bridge" or its Russian value "Тауэрский мост"? --NeoLexx (talk) 16:08, 6 September 2014 (UTC)

No, and furthermore, article names could refer to:
  • the title of the wikipedia page linked to this item in the desired language
  • the item label
 
Each Wikidata item currently provides the following content:
 
The labels, descriptions and list of pages aren't properties. They have to be queried as what they are.
Please tell us what you need and where (and the tools you have at your disposal) and we'll provide you a solution or with steps to achieve a tool providing this solution. --Dereckson (talk) 22:26, 6 September 2014 (UTC)
  • @Dereckson: Hi, thank you for answering and sorry for my delay. Basically I am doing "Stage 3" in terms of Wikidata: human readable list generation. Currently I'm just checking concepts and approaches so the actual database readiness and correctness are lesser important to me.
    So using the WDQ interface I can get by a single query a list of say all bridges crossing Danube and their images (if available) and their Commons categories (if existing). For that I additionally requesting properties P18 and P373:
    https://wdq.wmflabs.org/api?q=claim[31:(TREE[12280][][279])] AND claim[177:1653]&props=18,373
    So far so good, but obviously I need names of these bridges for any human readable list. Say I need to know that Q849786 is actually called Trajan's Bridge in English or Мост Траяна in Russian. For that I see two options:
    1. The right one would be to add another property request for "English Wikipedia article name" and "English Wikidata short description". Overall any data entry is nothing but entry ID and entry properties (ID or key is a property as well of course, it is just the only non-editable one to save the database integrity). But as you explained at the current stage it is not finished yet and currently database entries contain properties, "not exactly properties" and "not at all properties" :-)
    2. In such case the other option would be to get Q list first, and then loop through all of them over https://www.wikidata.org/w/api.php for actual names. It seems hugely ineffective, especially fop large lists, but definitely doable. I just didn't find yet API action for say "send Q — get English Wikipedia article name". I would appreciate a hint.
      1. This one I found, one needs to use action=wbgetentities Continuing with Trajan's Bridge (Q849786), to get its aliases, labels and descriptions (if any) both in English and Russian one needs to query
        https://www.wikidata.org/w/api.php?format=json&action=wbgetentities&props=aliases|labels|descriptions&languages=en|ru&ids=Q849786
        So the 2nd way of actions is understood. But at the real deployment of "Stage 3" it is necessary IMHO to set standard numerical properties for everything so single queries would be possible. --217.66.157.110 17:16, 8 September 2014 (UTC)
        Silly me: ids suggest that queries can go in chunks. Indeed "maximum number of values 50 (500 for bots)", so in 2-5 chunks the majority of lists can be obtained. Still even 2 > 1 :-) plus requesting data from two different sites in two different formats which is not really convenient. Si I would still suggest to fix the issue with numeric P for these properties even before the actual "Stage 3" deployment. --217.66.157.110 17:27, 8 September 2014 (UTC)
    3. Obviously if there is already a more effective way, especially in a single database query then it would be great.
--NeoLexx (talk) 14:15, 8 September 2014 (UTC)
/w/api.php?action=wbgetentities&format=json&ids=Q849786%7CQ83125&props=sitelinks&sitefilter=enwiki or you can request feature for WDQ. --JulesWinnfield-hu (talk) 17:21, 8 September 2014 (UTC)
Wow... We submitted at once. Too late :-) but thank you for helping! --217.66.157.110 17:30, 8 September 2014 (UTC)
Concerning feature request for WDQ: it is of course an option, Magnus Manske seems pretty active. But I would suggest to fix the database by uniforming its structure so it could be just &props=X,Y,Z By adjusting external services instead of it, we are creating unnecessary dependence of users on those particular services. --NeoLexx (talk) 17:43, 8 September 2014 (UTC)
Three last messages here is also me, all suddenly my session got expired. --NeoLexx (talk) 17:43, 8 September 2014 (UTC)

mwLua and JSON

Sorry if asking something obvious, but is JSON format fully compatible with mwLua? So say simply save JSON data as new Module for mw.loadData --NeoLexx (talk) 14:34, 8 September 2014 (UTC) Actually just realized that it's off-topic for this forum, I was just thinking in the context of Wikidata. Sorry. --NeoLexx (talk) 14:37, 8 September 2014 (UTC)

Notability again

Hi community, I usually check tagged edits every week but I didn't do it for one month. Today I opened adding invalid links... As you can see there is too much to do now (ie. delete, explain...). Maybe we should set AbuseFilters to disable? Since those edits come from both newbies and confirmed users I think the notability policy is not as highlighted as it's needed. Matěj Suchánek (talk) 16:49, 8 September 2014 (UTC)

I think it is better to start with warn? But I agree, adding those pages doesn't make sense. Lymantria (talk) 17:39, 8 September 2014 (UTC)
Yes, warning might be a good idea. -- Bene* talk 17:42, 8 September 2014 (UTC)

Can't switch between julian and gregorian date

If it's just me, can somebody correct the date of birth (P569) for Sholem Aleichem (Q238090), please? (The julian date is set as gregorian and the gregorian as julian...). If it's not just me, can somebody fix the bug?--Shlomo (talk) 08:12, 5 September 2014 (UTC)

  • @Shlomo: the date "2 march" is correct date (it is stored and displayed in Gregorian, as explained in topic above), and marker "Julian" is correct as well, because the person was born on territory where Julian calendar was used. The displayed date, as you can see in ru-wiki is "18 февраля (2 марта) 1859", so everything is already correct here. -- Vlsergey (talk) 14:34, 5 September 2014 (UTC)
    Everything is not correct. The "18 February" date is definitely wrong, because this is the Julian date of Sholom Aleichem's birth and is marked as "Gregorian". The idea that a statement saying "2 march Julian" actually means "2 march Gregorian, but should be presented in Julian system as another date which we won't show you" is confusing and crazy. I'm pretty sure no user or editor of wikidata would think this way and if this is what the developers intended, I'd strongly recommend to stop using the "Julian date" (maybe better description of the date as a Julian one) at all and enter (and mark) all dates clearly as Gregorian.--Shlomo (talk) 15:51, 5 September 2014 (UTC)
    @Shlomo: 1. "18 February" was imported from GND, so yes, there is a error. But it is marked as "deprecated", so this value shall not be used or displayed to client. 2. "is confusing and crazy" -- i totally agree that current system of marking dates with "Julian" mark is not the best. But if you consider Wikidata as storage, not as frontend, it is not a big deal. Dates can be displayed correctly in infoboxes, and that's the main point. -- Vlsergey (talk) 16:28, 5 September 2014 (UTC)
    The modules on wikipedias (etc.) surely can handle it, if their authors will know that no matter what the item states about calendar system, the value is always Gregorian. What I'm worried about are the editors (and bot-ditors) of Wikidata, who will enter a Julian date or even "correct" the Gregorian to Julian assuming that "2 March Julian" means 2nd March according to Julian calendar. I didn't make a research, but I'm pretty sure that a lot of dates already saved and marked as Julian are Julian dates, not Gregorian dates that should be recalculated and displayed as Julian. If this is true, we have much bigger problem than I was afraid of in the beginning - a problem with the reliability of the data.--Shlomo (talk) 21:59, 6 September 2014 (UTC)
    well, bot shall handle such information as any other -- make a "discrepancies report", present it to user and give him ideas where to dig. I do know about such mistakes made by some bot owner and reported them to him. Sadly, he refused to correct them by himself. So i just added additional lines to my bot to automatically fix those mistakes when moving data from ruwiki to wikidata. Regarding LUA, that exactly the reason why i described to process of handling calendarmodel couples topics above. -- Vlsergey (talk) 00:37, 7 September 2014 (UTC)
There is a bug (https://bugzilla.wikimedia.org/show_bug.cgi?id=65847) regarding switching calendars which we just fixed but not deployed yet. I am not sure about conversion between calendars in the UI. Aude (talk) 17:05, 5 September 2014 (UTC)
  • If it displays "2 March 1859 (Julian)" then that should mean 2 March according to the Julian calendar. I would consider a behaviour different than that (especially, "2 March according to the Gregorian calendar, but display it as Julian") as incorrect. The DB underneath should save it in Gregorian (or rather, ISO), but it should also on Wikidata be displayed in Julian. --Denny (talk) 15:20, 9 September 2014 (UTC)
Other related bugs: https://bugzilla.wikimedia.org/show_bug.cgi?id=70398 https://bugzilla.wikimedia.org/show_bug.cgi?id=70395 . So it is currently a bug and will hopefully be fixed soon. --Denny (talk) 15:25, 9 September 2014 (UTC)

Links to Commons - state of play

I finally found out how to do the queries I wanted to do (which, it turned out, could mostly be achieved using Autolist and grep, as originally suggested to me by User:Micru ).

Therefore, please find for your interest:

The most obvious headline is that there are 179,084 non category-like items on Wikidata with sitelinks to Commons; but Commons in total only has 112,000 galleries.

Category / non-Category namespace clashes

Drilling a bit further, of those 179,084 non category-like items, 84,167 in fact link to non-categories on Commons, while 94,899 link to categories. (Figures don't quite add up because the latter two were based on a slightly earlier read from the database, which I haven't been bothered to update).

Of the links with namespace clashes, only about 1100 have topic's main category (P910) set, to give an obvious alternative item to link from instead; while only 204 have Commons gallery (P935) set, to give an obvious alternative target.

In fact, fewer than 8200 items in total have Commons gallery (P935) set at all; compared to 84,167 items which have links to Commons non-categories, 9,182 of which also have topic's main category (P910) set.

Category-like items

On the category side, items marked as categories do accurately link to Commons categories. But there are 11,651 which have Commons links but no Commons category (P373); and 11,238 which have Commons category (P373) but no link to Commons -- perhaps because the Commons category is instead being claimed by an article item.

Other namespaces

Turning to the Wikidata:WikiProject Structured Data for Commons/Phase 1 progress/Links pages, there are about 150 Commons File pages, plus a handful of Creator and Institution templates, that are being linked to Wikidata items -- probably none of them should be. There are also a handful of Templates being linked to non-Template items; and a few Commons pages (though the latter are harder to spot, because the labels of items that are instances of Wikimedia project page (Q14204246) can sometimes be very inconsistent -- would it perhaps be an idea to standardise all of these to start "Project:" ?) Not all items that do seem correctly links appear to be marked as instances of Wikimedia project page (Q14204246), but probably should be.

As for modules: I wasn't sure if they are supposed to be instances of Wikimedia module (Q15184295) or Scribunto module (Q11382506) -- the choice appears to vary from module to module.

Finally, it's perhaps worth noting that for all of these more exotic namespaces the number of corresponding items on Wikidata appears to be rather few; at least compared to the numbers at c:Commons:Database reports/Page count by namespace. So it may be worth hunting out Commons non-main and non-category pages to add to items. Jheald (talk) 23:16, 5 September 2014 (UTC)

Addition: This discussion now also noted at Commons Village Pump -- Jheald (talk) 10:00, 6 September 2014 (UTC)

Big props to User:EugeneZelenko, who's cleaned out all of the stray sitelinks to the Commons:Institution namespace, and all but four of those to the Commons:Creator namespace. Quite a lot of stray File: sitelinks remaining, however. Jheald (talk) 17:04, 9 September 2014 (UTC)

Error rates

It would be nice to have some facts about error rates in Wikidata. Is there anyone that has come up with some hard facts? It seems like some users have their own idea about how much errors there are in Wikidata, and some even have an idea that there should be zero errors. It will probably be a small and finite numbers of errors and it will be very difficult to significantly decrease this. In Wikidata there is an additional problem of fewer eyes on the data compared to Wikipedia, so as long as the data isn't reused in Wikipedia (only a minor number of properties are) the errors will not be weed out. So does anyone have some hard fact on how much errors there are in Wikidata right now and what the half time of errors are? The last should probably be measured in page views.

I could add that I would like more use of references, and perhaps better references. A reference saying that some value comes from English Wikipedia is virtually useless, but a reference saying that a value comes from a specific page on English Wikipedia could be help full. A reference to an external page would be help full, as you then would shorten the path to the source data. It would also be really useful to have a system that tried to invalidate the data, and if successful would mark the data as invalid unless there was a reference in place. (An inverse factoid finding system, if the given fact can't be found the claim is marked as invalid.) Jeblad (talk) 12:47, 7 September 2014 (UTC)

Error rates
How do we define a "data error"? Wikidata:Database_reports/Constraint_violations/All_properties provides some kind of error counts. LaddΩ chat ;) 16:03, 7 September 2014 (UTC)
Better references
I believe some people work on developing improved tools for more easily defining references (or better importing them from WP). In parallel, we could identify on which properties we absolutely require references; possibly another constraint type? Could be done with the upcoming statements on properties. LaddΩ chat ;) 16:03, 7 September 2014 (UTC)
Marking invalid data
Visually marking invalid data, indeed! Ideally, we'd need to trigger a validation/consistency check upon changes to properties, but until this is possible we could simply visually mark basic constraint violations beside individual erroneous property values. This would at least let the user know that something is wrong with his/her edit - big improvement on the current scheme. LaddΩ chat ;) 16:03, 7 September 2014 (UTC)
Hard data will not be easy to come by, but the amount of errors will be considerable. Just think of Lsjbot adding all those pages based on the worst database he could find. And there is no shortage of Wikipedia-users who are doing even worse. I don't know about the theory that the amount of errors increases as there are more page views; this will be true enough for some kinds of topics, but I doubt it will apply generally. - Brya (talk) 17:27, 8 September 2014 (UTC)
Can you explain "I don't know about the theory that the amount of errors increases as there are more page views; this will be true enough for some kinds of topics, but I doubt it will apply generally." As far as I know the errors decrease with page views as users will remove errors they spot with some (small but significant) probability. In some cases erroneous common knowledge can interfere with the process, but I'm not sure how often that happen. Jeblad (talk) 09:14, 9 September 2014 (UTC)
It seems hard to imagine any general way to check error rates, but we now have quite a lot of "authority control" databases that should make crosschecking with other databases possible. We should possibly try to get a standard procedure like a big table for every property showing which values have been checked and match Wikidata, which do not etc. Not absolute error rates, but potentially points of comparisons.
For many topics, I think importing data directly from authoritative databases, rather than through a Wikipedia/DBPedia intermediary could help a lot in raising quality standards. This is what user:BotMultichill has done for artworks (from Europeana), or user:ValterVBot for population statistics (from national census data). One major blocker is the CC0 license though. -Zolo (talk) 10:32, 9 September 2014 (UTC)

A better way to model causation

Wikidata currently has one very narrow property to model causation. A broader and more robust approach would help build interesting applications. Please see Property_talk:P828#A_better_way_to_model_causation and give your feedback! Thanks, Emw (talk) 03:02, 9 September 2014 (UTC)

Change in renaming process

Single-user login (SUL) finalisation's goal is so that every Wikimedia editor has a single, recognized global account with one username across all projects. As you may know, after a long delay, it's now underway as an effort between bureaucrats, stewards, and Wikimedia Foundation engineers. This will also allow for development of cross-wiki tools like global notifications and watchlists. There is no set date for the completion of single-user login finalization at this time.

The process involves changing all rename processes into one global renaming process. The ability for local bureaucrats to rename users on this wiki will be turned off on Monday, 15 September 2014, as one of the first steps. Global renamers are in the process of being created to make sure projects and languages are represented by the time this occurs. I sent a note to every bureaucrat about this process three weeks ago with an invitation to participate and many have begun requesting to be a part of the group. Together with the stewards, the global renamers will be empowered to help editors work through the often difficult process of getting a global name.

In parting, visit Special:MergeAccount to unify your account if you have never done so. If your local pages about renaming still need to be updated, please do so and consider pointing people to m:SRUC for future rename requests, especially if this project does not have bureaucrats that hold global renamer permissions. If you have any questions, you can read more on the help page on Meta. You can also follow the technical progress on mediawiki.org. Contact me on Meta any time with questions as well. Thank you for your time.

-- User:Keegan (WMF) (talk) 16:23, 9 September 2014 (UTC)

Acceptable values for P793 - significant event

GerardM is willing to note an imprisonment at the Auschwitz concentration camp as significant event for the different inmates.

To do so, he offers the following claim: significant event (P793) -> [an item "Auschwitz concentration camp inmate"].

For me, this is a constraint violation: a class of humans isn't an acceptable value for an event property. I so offer the following claim: significant event (P793) -> [an item "imprisonment at Auschwitz concentration camp"].

GerardM denies this as the optimal solution: for him, “it is against the way we do things at Wikidata” and, as he recycled a liste of inmates into an inmate item, “In the past it was decided that we do not create new items for the singular of what is a "list" in a Wikipedia when there are no singular articles. It was preferred to rename it and use it for whatever the singular item is. There are tons of items that are in such a way.”.

And so instead to have 3 concepts, imprisonment (to use as event property's value), list of prisoners (for the de. Wikimedia-liste item), prisoner (to describe the content of such list), he would have one item, a jack of all trade, which is human and event and liste.

For me, and with the experience of having seen all the discussions, thoughts and results to carefuly organize the Firefly/Serenityverse items to comprehensively describe each concept by Ash Crow and Harmonia Amanda (and more generaly their good work on fictional universe), I'm in favour to create similar items but with different semantic goals as frequently as needed to help organize knowledge. And I also think this solution is compliant with the goal stated in WD:N “It fulfills some structural need, for example: it is needed to make statements made in other items more useful.”.

When I compare these two approches, I wonder if I'm not thinking to maximize the potential of comprehension and datamining by software and program, where GerardM would prefer to organize knowledge with as few entries as possible, but requiring human processing. I don't like his approach: facts are less valuable if there could be of different nature and lack of precision when used in an automated way. We have seen a lot of false positive in GerardM own automated edits. I'm not inclined to create traps leading to such false positive to people reusing Wikidata.

What's the preferred solution for you? --Dereckson (talk) 21:06, 6 September 2014 (UTC)

I was told not to use a list with instance of (P31) and then better create aother wikidata item, e.g. list of islands of Japan (Q1125331), island of Japan (Q17308006)--Oursana (talk) 21:56, 6 September 2014 (UTC)
I've also found a pertinent discussion on this issue: Disambiguation pages and other lists of links in the Wikidata:Requests for comment/Inclusion of non-article pages's talk page. The conclusion is similar to what you were told to. --Dereckson (talk) 22:01, 6 September 2014 (UTC)
Oursana I would say to use list articles with instance of (P31). You should, however, first rename the item from 'list of foos' to 'foo' with 'list of foos' as an alias. The justification for this is that a 'list of foos' article is an article about the class of foos and as such is an obvious target for instance of (P31). Add a 'subclass of' statement to the 'foo' article. This applies to nearly all the 'list of' articles and to some of the 'disambiguation' articles - e.g. those dealing with given names and surnames.
Note that you should also use position held (P39) with 'list of' articles - in the this case 'lists of mayors of bar' and 'list of kings of foo' and similar lists. Just rename the items to 'mayor of bar' and 'king of foo'. Creating a separate item is not needed unless there are actual wikipedias separate articles. Filceolaire (talk) 01:26, 7 September 2014 (UTC)
Indeed, the use of Position held could be interesting.
About the subclass of (P279) use, I see the documentation is to express the relation “all of these items are instances of those items”, so this is used for two lists when one is a subset of another? e.g. list of castles in Klow (the capital of Syldavia) would be a subclass of list of castles in Syldavia? --Dereckson (talk) 02:10, 7 September 2014 (UTC)
@ Filceolaire, I do not agree with you, I propose two different items to prevent a mass: foo, and list of foo, see also User talk:Pasleim# Hokkaidō (Q35581)--Oursana (talk) 02:25, 7 September 2014 (UTC)
I think that havinh two items will create a mess.
  • Sitelinks which should link together will be arbitrarily split between different items.
  • We will have a bunch of 'list of' items which describe wikipedia artifacts rather the wikidata concepts.
Dereckson, part of (P361) would better describe the relation between "list of castles in capital of Foo" and "list of castles in Foo". Cheers, Emw (talk) 11:48, 7 September 2014 (UTC)
Back to the target of significant event (P793): mixing concepts is a very bad long-term solution; events and persons are different concepts, thus require different items. imprisonment at Auschwitz concentration camp (Q17986818), subclass of occurrence (Q1190554), is the right target for significant event (P793). LaddΩ chat ;) 02:19, 7 September 2014 (UTC)
This is an old discussion. In the past we decided that we would not have items for the lists if there are no items for the singular. From a Wikidata point of view this is not problematic. At the time this was a compromise, it was what the community wanted. Now it seems we are moving the other way. English Wikipedia has renamed many articles into "list of" because such a large part of that article is a list. Wikidata is typically better at producing lists than a Wikipedia is.
When we decide to reverse our course on having both lists and nolists articles, we have a serious problem because they have been mixed from the days before Wikidata. There is no way to get this right without much involvement of many people who know their language. Thanks GerardM (talk) 12:26, 7 September 2014 (UTC)
About the linguistic care.
Yes, you're right, to organize human knowledge in such a way it's useful to query data and get coherent information, to help future natural language processing software and maybe IA to use Wikidata as a source to identify and link concepts, we have a need to be very careful how we define concepts and avoid to mix an human and an event for example.
If you're more in a mood to use Wikidata as a mere repository to fill infoboxes, I understand this is not important for you, but if you want to make Wikidata more useful for humanity, don't think only about Wikipedia, think about how to carefully and precisely define relations between items.
This is not a new decision and a reverse of course of action.
It has been decided more than one year ago if we can trust WD:N, Wikidata:Requests for comment/Inclusion of non-article pages and that discussion.
By the way, what you did appeared in Wikidata:Database reports/Constraint violations/P793. So the people preparing this report seems to consider your solution weren't acceptable BEFORE this discussion.
What destiny for lists?
It has been suggested lists could in the future be replaced by Wikidata queries on Wikipedia. And so the list items using this techniques wouldn't be articles and then would disappear of Wikidata. I don't know if this is a sound prophecy, but it gives another argument to avoid to confuse a list with an item.
There would, I believe, still be articles, it's just that the article would be a table with the values for 'name', 'start date', 'end date' etc. for each mayor with all these values imported from Wikidata and available for the other 280 language wikipedias to use with a simple template. Filceolaire (talk) 18:19, 10 September 2014 (UTC)
In conclusion.
We are here to do things properly and better organize the knowledge with claims and relations, taking the need to describe Wikipedia articles in consideration, including the strange ones mixing several concepts, but not to build upon Wikipedia mix of concept errors/choices/compromises.
--Dereckson (talk) 12:59, 7 September 2014 (UTC)

I was wonder about this also in combination with Q1756454 Jane023 (talk) 13:36, 7 September 2014 (UTC)

Why aren't we tracking "Subcategory of" ?

Why is it that we're not tracking "subcategory of" as a property ?

Autolist finds:

But for all the rest there is nothing.

My reason for asking is that I've been wondering whether I can use Commons category (P373) to identify probable matches between category-like items and article-like items, to identify new category's main topic (P301) / topic's main category (P910) pairs.

Along the way, I would like to deal with about 15,000 category-like items for which the value of P373 is non unique. Quite often, this reflects a clear sub-cat/super-cat pair, eg

I would like to determine which of the two is the super-category.

But that doesn't seem to be something that we're tracking. Is there any reason why not ? Jheald (talk) 23:32, 6 September 2014 (UTC)

Don't forget category combines topics (P971). Multichill (talk) 09:07, 7 September 2014 (UTC)
Category trees may be quite different between WP-projects. Lymantria (talk) 10:57, 7 September 2014 (UTC)
@Lymantria: That might suggest that (some of) our Category-like items are actually pulling together non-equivalent concepts.
But one could simply give a union of all of the items that a cat-item is a sub-cat of, compiled across all languages.
Do you have any sense of the numbers here? Can we quantifiably say that this is a widespread problem; or is it more a case of a few high-profile known cases?
Also, has anyone written an essay or put up a page, pulling together what we know about the issue? Jheald (talk) 12:11, 7 September 2014 (UTC)
Well, it is quite natural that category trees in large wikipedias will be more fine, having more subcategories, than small ones. The same is true for wikipedias tending to have many categories per page (e.g. enwiki) having more subcategories than ones where overcategorization is disliked (e.g. nlwiki). For instance, categories concerning countries may be grouped: - by continent, - by smaller region within continent (e.g. Caribbean), - by biogeographical region, - not at all, etc. I personally think that trying to catch all these groupings just makes things messy. Lymantria (talk) 06:54, 8 September 2014 (UTC)
Because 'Categories' are wikipedia artefacts and are not real world concepts which need a wikidata item. We have the items so categories can have sitelinks but we don't bother much with them apart from linking them to the corresponding item, if it exists. Filceolaire (talk) 18:31, 10 September 2014 (UTC)

Merge and buy of companies ?

I have a problem to describe a company which merged which another company to form a new one and the resulting company was finally bought some years after by a new one. Are there specific properties or can I use significant event property for that ? Example: Blackwell Science and Blackwell Publishers merged in 2001 into Blackwell Publishing. The latter is then bought by Wiley (Q1479654) to form Wiley-Blackwell (Q767319).

Description of companies events

How can we describe these events in terms of items creation and properties ?

Event Company A Company B Company C
Merge: 2 companies A and B become one with a new name C significant event (P793):union (Q17853087)
qualifiers: date, ?		 significant event (P793):union (Q17853087)
qualifiers: date, ?		 New item ?
Acquisition: one company buy another one but keep it as a "filiale" with a new name or its previous name Example Example Example
Acquisition-consolidation: one company buy another one and integrate the new one in its structure Example Example Example
Spin-off: a company A is divided into two parts and one part take a new name B significant event (P793):corporate spin-off (Q15865002)
qualifiers: date		 significant event (P793):corporate spin-off (Q15865002)
qualifiers: date		 -
Rename: A company A changes its name to company B without any change in its structure significant event (P793):name change (Q14904150)
qualifiers: date, ?		 Do we create a new item? -
Example Example Example Example

Snipre (talk) 12:20, 10 September 2014 (UTC)

--189.173.99.20 10:12, 23 September 2014 (UTC)=== Discussion ===

Similar approach to describe these events should also apply with municipalities (merging with or without name change, etc). Michiel1972 (talk) 13:24, 10 September 2014 (UTC)

I think you'd soon hit problems, because we over-simplify. What we often think of a company is often many different oganisations. Take an example like IBM or Microsoft, and look at their entry on Open Corporates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:21, 10 September 2014 (UTC)

We don't need to start with all details but definitively we need to create a data structure for company events because this will be a problem if different structures are used in parallel. As mentioned by Michiel1972 we have a similar problem for administrative levels and countries. We need a general structure for merging items and dividing items with their relative connections to be able to store the information at the right place. Snipre (talk) 14:39, 10 September 2014 (UTC)

Please modify or copy the above table to propose your ideas and if there is an interest, I will move the paragraph in a RfC. Snipre (talk) 14:39, 10 September 2014 (UTC)

The critical question is can you describe the entity in one item. When one company takes over another then you need a separate item for the company that was taken over, with an end date. In theory the company that did the taking over can be considered the same item it was before and statements on that item describe its change of name, headquarters etc.
For a merger (or a split) the merged entity can be considered to be a new item with a start date.
How do you decide which applies in each case? Just think if you can describe the entity in statements about one item. If you can't then you need to split into two items.
OK? Filceolaire (talk) 18:01, 10 September 2014 (UTC)

Allpages Bug?

Why do Special:AllPages/Q18011759 show Lakka (Q1801176)? --Diwas (talk) 13:58, 10 September 2014 (UTC)

In multiple places, the items are sorted alphabetically by QID, and Q1801176xxx comes after Q1801175yyy alphabetically, no matter what xxx and yyy are. This sure is not very intuitive, but I guess it's not to be considered a bug. --YMS (talk) 15:52, 10 September 2014 (UTC)
Yes of course, sorry. I had seen the alphabetical order like in Special:AllPages/Q18 but anything stops me to realize that it is (nearly) equal to Special:AllPages/Q1799999999999999999999. Thanks --Diwas (talk) 16:58, 10 September 2014 (UTC)

Wikinews linking

First part

Today Wikidata launched Wikinews sitelinking and some bots are doing it wrong. See the original proposal: "Wikinews categories correspond to Wikipedia articles and to similar items in other wikiprojects", and discussion. Wikinews category ("news by theme") should be linked to the basic item (for example, with Wikipedia article). --sasha (krassotkin) 11:47, 20 August 2014 (UTC)

I never did get any response to my query as to why the proposal asserts that something must be done. Nor does it appear Brian McNeil's query does not appear to have received any reply either. I don't recall ever getting any response at Wikidata when I've invited discussion of why involvement with Wikidata would be a net advantage to Wikinews rather than a detriment. --Pi zero (talk) 12:02, 20 August 2014 (UTC)
I can't find any reason behind this linking, I think n:en:Category:Greece should be linked to Category:Greece (Q4367791) not Greece (Q41) no matter what is inside of the categories. Redirects shouldn't be linked at all. Amir (talk) 12:36, 20 August 2014 (UTC)
Oh... you think, but I work with it for several years. OK. In Wikipedia - article by topic, in Wikivoyage - guide by topic, on Commons - gallery by topic, ...etc..., in Wikinews - news by topic. The only difference, that topic in Wikinews technically organized as a category (or as a portal for similar topics, but that's another story). --sasha (krassotkin) 12:53, 20 August 2014 (UTC)
We traditionally associate articles of Wikipedia with categories of Wikinews. See "sister projects" in w:Barack Obama#External links for example. --sasha (krassotkin) 13:03, 20 August 2014 (UTC)
I agree with sasha, Wikinews categories correspond to Wikipedia articles, on french wikinews we try for several months to name the Wikinews category with the name of the Wikipedia article. Wikinews categories have to be linked with Wikipedia articles and similar items. On french Wikipedia, the link between the article and the Wikinews category is already in place, example--Mattho69 (talk) 13:11, 20 August 2014 (UTC)
I'm sensing a logical disconnect here (parties talking past each other). En.wn categories (those that have been updated to it) use a master template, {{Topic cat}}, that provides, amongst other things, prominent sister links to other (so far, English-language) projects. These are constructed by hand, and the mappings sometimes require deep thought. Often the Wikipedia link is to an article, but occasionally it'll be to a portal or some other space — I think we've got at least one that links into project space. Matches aren't always one-to-one; indeed, I've been wondering for some time whether we ought to have a way to provide multiple links to the same sister. (I consider hands-on work with our category hierarchy a crucial part of gaining understanding of it and perhaps how to improve it.)
I've observed that ontologies used by different Wikinewses may differ a great deal from each other (in abstracts; geocats tend to be mostly the same, though there may be nuances such as whether or not Croatia is a subcat of Ukraine). And I've observed that ontologies for en.wn are often quite different from those for en.wp; it concerns me that imposition of Enclyclopedic ontology on a news project could damage the news mindset. A strong incentive to make Wikinews categories correspond to Wikipedia articles might ultimately be a bad thing.
This is not really relevant in Wikidata as subcategory is a poor relationship beetween item. In Wikidata we link items with a lot of properties way more precisely defined. An event can be a part of a story instead of a member of the category. We use classes to sort item using instance of (P31) to say for example that a specific war battle is a member of the set of all war battle. If we want to be more specific we can create the class of all battles on the current Ukrainian War. This is what we do here, there is few overlap with a news site, except we can help and give datas to build a chronology of recent or less recint events if needed in a news. If an event has a Wikinews article about it, then it will have an item and Wikinewsists will ae able to store informations about that event, the sequince of events that lead to this one, the previous election on the same office, the winner … TomT0m (talk) 17:17, 20 August 2014 (UTC)
@Pi zero:
I agree Wikidata doesn't relate to deciding whether, say, Croatia should be a subcat of Ukraine. However, the choice of what is and is not an entity — which does not come up too much in geography — is an ontological issue that does matter. For example, I remember poking around other Wikinewses with an eye toward our category Freedom of speech, only to discover that just about every Wikinews I looked at handled it differently. It's been a while, but as I recall several of them had (for example) a category Censorship instead of Freedom of Speech. These are clearly not the same thing; yet, for project purposes it makes sense to cross-link them. On the surface this would appear to me a decision properly left in local hands, not something to farm out to Wikidata. --Pi zero (talk) 18:19, 20 August 2014 (UTC)
Wikidata is sensitive, it requires a 1 topic/1 item mapping, so for edge cases it could need a minimum of manual work. The original plan of the devteam was to use old style interwikis in those cases. No real problem for you then (it is not excluded more advanced solutions will emerge, it coould be possible to infer relevant interwikis by exploring the items an item is linked to for example). The ultimate decision remains in the hand of local communities. TomT0m (talk)
There's also the major wiki tradition (so I perceive) of lovingly hand-crafted material. I remember a Wikipedia article I worked on that required a customized infobox because it had unique properties unlikely to make sense for any infobox for a class of articles; and I wonder if that work will ultimately be crushed under the Wikidata juggernaut. In the case of Wikinews, there's a famous/infamous case where Serbian Wikinews boosted their output with a bot to import and publish material from public domain outlets, such as Voice of America. The theory as I understand it was that these articles would "seed" the wiki, drawing in people who would become contributors. What actually happened was that the Serbian Wikinews contributor base, which had been on the rise, dropped. The number of articles published went up and up, but the resulting news archive doesn't attract readers (perhaps because there's no reason to read stuff that's available somewhere else anyway), whereas in contrast en.wn's archive is a major attraction. There seems to me to be a take-away lesson here that the wrong sort of automation can reduce contributor influx rather than increase it (I imagine the difference between tools that increase and decrease participation has to do with the user being in control). So it seems to me one ought to be skeptically cautious about claims of contributor increase from automation. --Pi zero (talk) 13:45, 20 August 2014 (UTC)
Wikidata is a tool, it's up to community to decide whether or not to use it. But it's not magical and won't write article by itself. One can even think that people who loves to gather datas and build Wikitable by hand, and stops when someone made their work easier lost their time before and maybe are not fit to write news articles (if you ask a real journalist if he enjoys purely techical tasks he might curse  :) ) On the other hand the time not spent to build the table is won to gather better datas and write better texts. Maybe if people do not do that it is that they … can't ? Your question has no easy answer. My feeling is that for a journalist Open Data is an opportunity for fact checking and advanced data analysis. TomT0m (talk) 17:17, 20 August 2014 (UTC)
The example infobox I mention was a case of customization not because somebody "liked" to do stuff by hand, but because what the article called for could not be done well without customization. That is, the table produced was a better product than generic techniques could produce. It seems a bit naive to dismiss such things with "it's up to community to decide whether or not to use it"; such things have momentum (hence the juggernaut allusion), and my concern is that the momentum would preclude customization in those cases that call for it, thereby preventing users from improving an article when they want to. Which discourages participation.
I don't see how Wikidata makes his work any harder. It will still be possible to build a custom infobox, as painfully as before :) TomT0m (talk)
Your suggestion for possible use of Wikidata for news... I can think of difficulties, of course, but I'm particularly struck that it sounds like a very sophisticated use of Wikidata. Tbh, the only uses of Wikidata I've been seeing discussed concretely have been simplistic ones that I'm concerned would do damage by precluding various kinds of improvements. --Pi zero (talk) 18:19, 20 August 2014 (UTC)
See what it is possible to generate automatically and dinamically from Wikidata datas : with Reasonator. This is just the beginning. Note the chronology of its life with dated events in the bottom. @Pi zero:
Annyway, we will always need people to feed the database with datas, press agencies don't write Wikidatas statements using the API. Or write articles (although natural language generation (Q1513879)  View with Reasonator View with SQID is actually used in some fields of journalism, to generate news about sport matches from the minutes for example). TomT0m (talk) 20:16, 20 August 2014 (UTC)
Sorry, too long text for quick undretanding. But it does not make sense, that some Wikinews categories are linked with categories and some with articles. There is category's main topic (P301) and topic's main category (P910) for makinq relations between article and category namespace. The same was result of RFC for Commons linking. JAn Dudík (talk) 12:37, 22 August 2014 (UTC)
  • That this specificity of Wikinews. There exactly categories are "main topics" - "newspapers" by topics. And there's nothing than news in the mainspace or another item except categories for linking with articles of Wikipedia (or other projects). --sasha (krassotkin) 13:50, 22 August 2014 (UTC)

See example Quotes about Russia (ru) - News about Russia (ru). But there it is category in Wikinews. --sasha (krassotkin) 13:57, 22 August 2014 (UTC)

Specificity ow Wikinews? Yes, Wikiquote are almost similar to Wikipedia. But in Wikisource, there are authors and categories. For Wikibooks there are main categories too. Wikiversity - categories. And Wikisourse is linked category to category. Why is problem linking category to category, if this is only on external site and in wikinews article will be all interlanglinks to main namespace in other languages? JAn Dudík (talk) 18:23, 22 August 2014 (UTC)

Explanation

TL;DR: Some projects restrict use of mainspace for things such as news headlines, book titles, etc. They use categories to detail a topic (such as Biology). Some use both (i.e. Commons). It is necessary to link primary means (that be a category, an article, or both) of talking about topic properly, so that readers receive most relevant content when they use interproject links. --02:58, 22 August 2014 (UTC)

TL;DR: At Wikinews, As topics are not main content (Biology is not a news headline), interesting content on a topic is stored in a category. If you'd like interproject links to work by providing interesting, entertaining read on the article subject from the various Wikimedia projects, then n:category:biology needs to show up at w:biology. No end users read w:category:biology. --00:50, 22 August 2014 (UTC)

That's a lot of discussion above, but I think it diverged from the original query. The original query was "let's link n:Category:Biology with w:Biology, not w:Category:Biology". The response was that Wikidata tries to capture data and this might be in clash with this request. I would like to clarify why Wikinews uses categories and does not use mainspace articles the way majority of other Wikimedia projects do.

  • (edit conflict)Biology is not a news headline, even though it is a good article name at other Wikimedia projects. At Wikinews, it does not belong to mainspace.
  • There is no direct match between a Wikinews article and a Wikipedia article (unless the event meets notability guidelines) or a Wikibooks article (unless someone accidentally happens to write a wikibook about it) or a file (unless there is only one picture in the world about an event), although there may be a link to a Commons category. Trying to match interproject links to Wikinews's mainspace is almostmeaningless — they only overlap where a sister project talks about news (which is quite done a lot, but is rare compared to the amount of non-news content they have).
  • For news on a topic, Wikinews uses categories. An extension is used to put a list of fresh ones.
  • Interproject links serve the purpose of giving a user media on a given subject. This means encyclopedic article, books, quotes, pictures, and news. News on a given subject. This means a few. A category is best suited for this purpose.
  • Mainspace pages exist as redirects to categories. We don't need to use them. They only exist for local links to work, which is ugly and is a side-effect. (I hope to think about smarter wikilinking at some point.)
  • Is there more categories than such local redirects? (I'm sure it's not the other way round; I'll post here when I have numbers).
  • Some language editions of Wikinews don't take proper care to maintain such mainspace articles. They don't always exist, and don't always forward to correct place (such as to a Portal: instead of Category:; the former ones are a remnant of Wikipedia way of thinking or an experiment in some historical past).
  • Is it technically possible to attach Wikidata to a page which is a redirect?
Yes, but not deployed yet as of 2013.

Therefore I can only conclude that

  1. We could face the same issue with Commons. The only reason they don't put all stuff into categories is that they have content interesting to readers, different from what browsing a category can give.
  2. Wikiquote could face this problem, were they to dedicate a separate article for each quote (this would make it possible to browse translations of proverbs, for instance). Only a category would bring these together reasonably well. --00:19, 22 August 2014 (UTC)
  3. Wiktionary could face this problem, were they to dedicate a separate article (or Wikidata item) for each word meaning. --00:19, 22 August 2014 (UTC)
  4. At Wikinews, for a given subject, there's nothing else of interest other than browsing fresh members of a category. It's the closest match to a corresponding article subject on another wiki. (Exceptions exist where another project talks about a big event, i.e. 09/11 maybe, and Wikinews does not have a category on it.)
  5. We appear to need to link stuff to categories (Wikipedia's Biology, Category:Biology would all go to Wikinews's Category:Biology.)

--Gryllida 15:12, 21 August 2014 (UTC)

It doesn't. Wikidata would have three items for that - America, North America, and South America. If the individual Wikipedias would want to link to anything else then the exact match, they can still do so locally. --Denny (talk) 16:54, 24 August 2014 (UTC)
Maybe can we just create a property (Wikinews category) like Property:P373 to add Wikinews categories to Wikipedias articles ? Or maybe some script can link automatically the Wikipedia article to the Wikinews category using Property:P910 ? --Mattho69 (talk) 14:57, 21 August 2014 (UTC)
The first thought doesn't sound. The second thought sounds if this actually shows up at Wikipedia, Commons, etc articles properly — where can I find examples of property:p910? (I don't expect a script need for that. Hm. That'd be surprising, as I thought that people tell what links where, and it starts working server-side.) --Gryllida 15:17, 21 August 2014 (UTC)
For example Euromaidan (Q15224558)  View with Reasonator View with SQID uses topic's main category (P910) to be linked with Category:Euromaidan (Q15262078)  View with Reasonator View with SQID . So maybe when someone wants to link Wikipedia and Wikinews on this topic the link can be made automatically between the Wikipedia article and the Wikinews category. --Mattho69 (talk) 16:07, 21 August 2014 (UTC)
Mattho69I don't know all this Wikidata stuff. Could you please link this specific article the way you described and show me what edits you did (and I will look what it says in sidebar too)? --Gryllida 23:19, 21 August 2014 (UTC)
For now it only possible to link the Wikidata item with the Wikidata category item, like this. But what I suggest is that this link can be used to link directly the Wikipedia article to the Wikinews category, but I don't know how. --Mattho69 (talk) 00:14, 22 August 2014 (UTC)
It would be nice to figure out. --Gryllida 00:43, 22 August 2014 (UTC)
@krassotkin I know that (I'm synop on fr.wn) but people are linking Wikinews categories to Wikipedia categories and I try to find a solution for everyone. --Mattho69 (talk) 20:36, 21 August 2014 (UTC)
@Mattho69 I know. I write not only for you;-) Wikidata is logical project. We don't have to come up how to bypass logic. Let's go to link:-) --sasha (krassotkin) 06:42, 22 August 2014 (UTC)

Preliminary conclusion

Dear Wikidata residents and those of you who are adding Wikinews things to Wikidata,

I am a Wikinews contributor (English and Russian) and I know the project structure. I analysed the discussion above and a discussion with sasha (krassotkin) at Russian Wikinews (n:ru:Викиновости:Форум/Общий). From these discussions, to me it looks like

  1. For some language editions of Wikinews, The task here is to link WP's Biology to WN's Category:Biology. This is what end users should end up visiting in the interproject links in sidebar, as it provides relevant content. All 3 participating people (me, sasha, and Mattho69 (french WN sysop) agree on this. (For some Wikinews, a main namespace article exists and is not a redirect. Regardless of how this problem is solved, they will work the "normal" way of linking.)
  2. At Wikidata, from what I could see, such task may be accomplished by
    1. linking to redirect (ugly, and also not implemented/supported at Wikidata atm);
    2. linking 'wp:biology' to 'wn:cat:biology' despite it being different namespace (which is fine with me and sasha; it provides relevant content), or
    3. using the 'topic's main category' object mentioned by Mattho69 earlier. doesn't appear to be implemented either.

Therefore we can only proceed by #2 at the moment, and may look into other options later if the software supports them sufficiently well. --Gryllida 13:54, 22 August 2014 (UTC)

kowikinews does not have redirect to category on ns 0 (main namespace), so kowikinews is okay with any resolution (note: kowikinews is really small wiki with less than 5 regular contributor.) — by Revicomplaint? at 14:19, 22 August 2014 (UTC)
Added to the above. (A wiki being small doesn't mean that things should be done wrongly, and I understand that in this instance there is absolutely no effect of this problem solution on this wiki.) --Gryllida 14:28, 22 August 2014 (UTC)
A second discussion is now also open on this page, but it is about interlanguage links (which are a separate topic from this). --Gryllida 14:32, 22 August 2014 (UTC)
Related discussion: i think, the best way to link Wikidata and Wikinews is through the Category item from Mikani. --Gryllida 08:49, 23 August 2014 (UTC)
This is an old discussion. I talked to Base after that. If he wants to join the current discussion better if we previously discuss it in Ukrainian or Russian (it's easier for me). --sasha (krassotkin) 09:49, 23 August 2014 (UTC)
I might notice that the phrasing here is ambiguous. What is a "category item"? Wikinews does gather topics in categories. Base, please share your thoughts on the above. --Gryllida 03:29, 1 September 2014 (UTC)

Items with issues

On labs I made a list of items that have cross namespace issues. The Wikinews sitelinks on these items should be moved to the corresponding category item. Multichill (talk) 19:03, 27 August 2014 (UTC)

Of course not. It contradicts everything that is written above:
  • We need to link the relevant entity. But topics on Wikinews located in the space of categories. Historically.
  • There's nothing in the main space that could be linked with articles of Wikipedia on Wikinews (for example, as galleries on Commons).
  • Wikinews categories aren't the same that categories in other projects. This is such "tag cloud" or "news by topic".
  • Wikinews many years linked their categories with articles in Wikipedia through {{Sister project links}}.
  • And in this lies was our proposal to Wikidata: Wikidata:Wikinews/Development#Interproject links.
But, the opposite side has no arguments except "I don't like how it looks". --sasha (krassotkin) 20:34, 27 August 2014 (UTC)
Some arguments against
I am afraid that this discussion is messed and spread on various pages - what about starting regullar RfC?
JAn Dudík (talk) 05:30, 28 August 2014 (UTC)
These are not arguments but simple questions and erroneous statements. They are caused by lack of knowledge of the specifics of Wikinews. All active editors of Wikinews know the answers. You had to ask before start of your bot. Also it is better to ask questions one by one. However,
  • Categories months, days, and so on Wikinews should be linked with the relevant articles of Wikipedia. See: w:August 2014. Now, not all editions of Wikipedia have an article/(list in main space) about day. But as far as I know, this is planned by some users in the future. If such object is not in Wikidata, it should be created.
  • There are no concepts "category's main topic" and "topic's main category" in Wikinews. Wikinews category is precisely topic now.
There are articles for every day in some projeyct which are Main topic of same-named Wikinews categorz. --90.182.83.10 14:55, 28 August 2014 (UTC)
Can you give me an example? --sasha (krassotkin) 15:52, 28 August 2014 (UTC)
  • I am unaware of experienced editors Wikinews who fundamentally disagree with that. We can discuss and argue about the details, but not on principles.
  • About ontology. Now, category of Wikinews is the same "category of being" that Wikipedia article or topic in the main space in any other project. On the other hand, Category Wikinews, it's not the same "category of being" that category in other projects. This is what I wrote above. We must link equivalent entity. Therefore, your arbitrary linking incorrectly.
  • Linking news with article is absolutely wrong (from example RusAir Flight 9605 (Q1762806)). These are completely different entities. In this case, news reports about only one or a few related events, but the article talks about its historical development. Some Wikinews editions have categories called "Topics of ". See for example n:ru:Сюжеты 2014 года (Topics of 2014) and as part of its n:ru:MH17 (Malaysia Airlines Flight 17). The last category is the equivalent of the relevant article, but every single news from this category is not.
I agree to move this discussion on a separate page but not now. We must summarize and act in concert. --sasha (krassotkin) 08:21, 28 August 2014 (UTC)

And what about this alternate solution:

  • Categories on Wikinews will have separate items
  • These items will be tagged as P31=Wikinews category
  • Connection between these items and other categories and articles will be wia special properties "Wikinews category Theme" and "Related Wikipedia category"

? --90.182.83.10 14:55, 28 August 2014 (UTC)

krassotkin You're moving categories from category items to non category items. That's not how it's done here. Please cease doing that. You first need to get consensus, not move stuff to force it. We already had a pretty long discussion about this when Commons so I don't think that will make it. Multichill (talk) 21:50, 1 September 2014 (UTC)

  • I do it because topics in Wikinews located in the space of categories now. There was a very different situation on Commons and Wikinews. I know about the discussion and wrote above what is the difference. Moreover, I knew about it before made my offer to Wikidata (read it please). Anyway it's not good to make categorical statements, but arguments are welcome. --sasha (krassotkin) 06:23, 2 September 2014 (UTC)
  • @Multichill: Wikinews is a project who wants to use Wikidata. Wikidata does not have rights to define how Wikinews shall link their pages to Wikidata ontology. If some Wikinews project would like to link their categories pages to Wikidata non-category items -- it their right. The decision shall be made in own project community, not by Wikidata community. Wikidata community can advise to link categories to categories. Wikidata community can present instruments to use category-to-category links in the most efficient way. But Wikidata community can not prescribe how other projects must link their pages. Wikidata is building it's own ontology -- okay, go on with it. Build it, improve it, link it with other projects. But other projects are not building ontology, neither prevents you from doing that -- they are just using interwikis to create interwiki and interprojects links. -- Vlsergey (talk) 13:19, 2 September 2014 (UTC)
Multichill: In Commons, main namespace pages have meaningful content related to a subject (see eg c:Australia), while at Wikinews main namespace articles — if they even exist — are only redirects. There is no technical means to sanely link a redirect as an interproject link. There is no philosophical or practical sense in forcing Wikinews to duplicate its category contents in mainspace, either — "Australia" is not a news headline. Unfortunately I can see how these differences from Commons create a different situation here. --Gryllida 02:53, 9 September 2014 (UTC)
@krassotkin:, @Vlsergey:, @Gryllida:: guys, guys, please. Before moving links from one point to another, please discuss it first. We all want to find a solution to integrate both our projects. We are in no hurry, let's just discuss first and then we'll sort out the best options. Ok? Sannita - not just another it.wiki sysop 12:56, 9 September 2014 (UTC)
@Sannita: i'm not in wikinews project and has nothing to do with it, so don't ask me :-) Anyway, i don't see what shall be discussed here. krassotkin explains situation very well, i made a point that each project has it own right do integrate in way they would like to. And i didn't see any valid contra-arguments. So no reason to delay, from my point of view. Vlsergey (talk) 13:06, 9 September 2014 (UTC)
Someone mentioned that consensus exists. I strongly disagree.
We as a community define the ontology of this project. Other projects, like Wikipedia, Commons or Wikinews can decide how to use that information and how to use that to make other links.
You can use the links in Wikidata or override it with some local template. It's still a bit inflexible until bugzilla:47930 is fixed, but that's a matter of time. We have items for topics and we have items for categories. We have category's main topic (P301) and topic's main category (P910) (and category combines topics (P971)) to connect these. Wikinews uses categories to group related articles together, just like Commons does that for files and Wikipedia for articles. The difference is that these articles can't easily be linked to subjects in other projects.
Don't remove your local links yet, don't mess up our ontology and once bugzilla:47930 is fixed, update your local code to have stuff link to whatever you want. Multichill (talk) 19:50, 9 September 2014 (UTC)
@Multichill: it has nothing to do with Wikidata own ontology. Wikidata is free to define it's own ontology. Wikinews is free to define it's own ontology (used on Wikinews only) and is free to connect it's own ontology to Wikidata ontology. Linking Wikinews categories to Wikidata non-category-entities does not change Wikidata ontology neither any other project one. Because of this every project is free to define it's way to connect to Wikidata ontology. Don't interfere with other project policies. Community of Wikidata has no rights to do such things. More over, doing such things as preventing other project to use Wikidata in the way they want to makes the whole project idea very dictatorial and unhealthy. We provide instrument to create interwikis -- projects are free to use it as they would like too. Dixi. -- Vlsergey (talk) 21:21, 9 September 2014 (UTC)
I don't agree, and I don't like the way you are discussing. In wikidata we provide more than interwiki links and the interwiki links are sorted by namespace. That has nothing to do with dictatorship or health and mind me, putting that in a discussion is a huge fallacy. Lymantria (talk) 05:26, 10 September 2014 (UTC)
@Lymantria: do you have arguments except "i don't agree"? I do understand that a lot of people from Wikidata community don't agree that they don't have right to interfere other projects, but that usually the only way projects would like to use wikidata. The fallacy is the discussion here from the beggining, let me make it short and easier to understand:
WD: — hey, wikinews, we provide you a way to link your pages to other projects
WN: — cool, we are going to use it right away
WD: — stop here, stupid people, don't mess up with our ontology!
WN: — but... but... but we didn't added claims neither changed you properties... we just wanted to link pages like you tell us we can
WD: — you have no rights to tell us how to link your pages to other projects. We do know better how to link them, do as we said
WN: — but... but... but we have community consensus that we need to link like ...
WD: — we don't care about your community consensus, because we have people who don't like how you made up your own ontology
WN: — (shrugs) hmm... hmm... Okay, then how we link our pages with wiki pages according to our local community decision — as we did for several years in row?
WD: — you can't because you need to wait for fixing bug № bla-bla-bla and bug № bla-bla-bla
WN: — (very possible variant) (just goes away and tell other projects not to use Wikidate because it useless and local community don't care about other projects structure except Wikipedia and Commons)
That's exactly what I call dictatorial and unhealthy. Other projects can have different namespace structure, much different from Wikipedia and Commons structure. They can and they do have structure where main space IS categories. Again, it has nothing to do with Wikidata "ontology". "interwiki links are sorted by namespace" was never an argument before -- we have a lot of Wikisource projects where "Author" namespace exists and still we allow to link this "Author" namespace with main namespace. So this it was not a limitation before. It just some people don't like the idea to link categories to item, because they think they can do better. But projects like wikinews do not need better. They have good variant, they have local community support, they just need for some people to not to stand in the way. Let the projects do mistakes, they are not not gong to ruin wikidata project. (much better not-happend-variant of discussion)
WD: — hey, wikinews, we provide you a way to link your pages to other projects
WN: — cool, we are going to use it right away
WD: — you know, we don't usually link categories to main space. With projects like Commons we do the following (explanation with slides and pictures)
WN: — this variant is interesting, but it's too complicated for us. We don't have galleries, so we okay with simple one-to-one category-to-entity links
WD: — okay, do it like this if it's your decision, but remember you can always count on us to help you move to recommended structure if some day you would like too
WN: — great, thank you, we are going to use your project and tell everyone how great you are
-- Vlsergey (talk) 07:00, 10 September 2014 (UTC)
Unfortunatelly, there was problem with communication before launching phase 1. Yes, it was written on WD:Wikinews that you want to link categories with articles, but maybe nobody read it or understand something else, so Wikidata community was surprised, when you started it.
But, Wikinews lived without data from Wikidata years ago, so you must now (as is only phase 1 live) use old system, and when phase 2 coome, use for interproject linking topic's main category (P910) (maybe with ifexists:label_for_it).
Comparison with wikisource is little bit different: wikisource Author namespace have none equivalent on another project, so It can be easily connected with main namespace articles. But Wikinews categories have equivalents: other project categories. And as I wrote above, there are both categories like Category:Japan (Q1411284) which you wants to connect with articles and categories like Category:Candidates for speedy deletion (Q5964), which can be only connected with another categories. If ALL wikinews category can be connected with other articles, situation would be easier.
BTW, there is also Anexo namespace on es.wikipedia or Dílo: namespace in czech Wikiquote - and thet are all connectable with wikipedia articles.
Wikisource is still using old-style linking for main namespace, because there are some more problems with editions and instances. I thing, Wikinews have the same possibility. JAn Dudík (talk) 11:06, 10 September 2014 (UTC)
@JAn Dudík: It always good to read discussion carefully. For example, you used "you want to ", "you must now ", but i'm not a part of Wikinews community. From technical point of view phase 2 has nothing to do with linking between projects -- you can't obtain label in different project basing on Q-id, so no LUA code could currently help display link from Wikinews category to Wikipedia article and vice-versa (unless it's the same entity, as Wikinews planned to do). And, in the end, there are still no arguments why categories must be linked only to categories. There is no technical limitations, no rules, neither any good reason to enforce that. It's not a problem to connect things like Japan (Q17) to Wikinews category and threat things like Category:Candidates for speedy deletion (Q5964) as usual categories. I don't see any problem here. And also I don't see any reason for you to use the word "must", may be it's just mistranslation. -- Vlsergey (talk) 11:22, 10 September 2014 (UTC)
@Vlsergey: 1) How can I know if you are part of wikinews community, when you have blank userpage? ;-) 2) when you split wikinews categories, some to categories, some to articles, there will be very difficult to make many automatical processes unless you correctly mark ALL of them if they are "articles" or "categories". BTW If I understand this dicussion correctly, there are only people from ru.wikinews who want it. and what about people from other 30 wikinews languages? JAn Dudík (talk) 12:25, 10 September 2014 (UTC)
1) i said it page ago. 2) Did you just said "better to create problems to people than to bots?" :-) Bots are bots, software engineers will handle their problems. 3) Only one big Wikipedia project already actually integrates their infoboxes with Wikidata (guess which one), so it's no surprise only single wikinews project is active in discussion here. And even if it's only single project... why not to listen it? -- Vlsergey (talk) 13:41, 10 September 2014 (UTC)
Vlsergey's depiction of dialogs between Wikidata and Wikinews sounds reasonably plausible to me — speaking as an en.wn insider. With the small qualification that, after many years of en.wn being harassed by a small-but-vocal group of Wikinews-haters from Wikipedia, and being dissed by Commons (who ignore fundamental differences in the way we handle images from the way Wikipedia handles images), some of us at en.wn had a sinking feeling, despite hopes to the contrary, that Wikidata would turn out to be just one more way to push a Wikipedian mindset on us.
Come to think of it, the wikimedian sisterhood is a fairly dysfunctional family, roughly split into two factions. The oldest, and largest, sister (Wikipedia) is self-absorbed and often bullying, though also vaguely friendly to her younger siblings in a distracted sort of way. It doesn't help with her frequent arrogance that mom really does like her best. A couple of the other sisters (Commons and Wikidata) tend to side with her, though each of them has some of the same problems with self-absorption. Most of the rest of the siblings are a lot more considerate of others, and often get annoyed with the eldest and her little clique, though they're all fond of her in a frustrated sort of way. Of course, people do tend to be nicer to others when they're at the bottom of the pecking order, so you can't really be sure that the other sisters wouldn't be just as bad if they were more important. --Pi zero (talk) 13:17, 11 September 2014 (UTC)

in other projects sidebar

There we already included the block "in other projects sidebar" in Russian Wikinews (see "В других проектах" in left sidebar n:ru:Владимир Путин for example). And now anyone can understand why it's done - we link topics with topics. There's nothing for what Wikidata needed at this stage. And it's the only one way we will be able to query the properties from Wikidata to categories-topics in Wikinews in the future.

We must continue to develop. So we need these interproject links. If we will solve these problems with another way in the future, we can move all of the links with bots.

I propose to summarize the discussion. --sasha (krassotkin) 06:23, 2 September 2014 (UTC)

I interpreted it as "in Wikinews, categories are user-facing means to show a topic — they're not purely administrative — so let's link them with objects of equivalent role at other projects (even if they're in a different namespace)". This is consistent with discussion above. At the administrator board on this wiki, I've suggested that a local sysop closes this discussion. --Gryllida 02:48, 9 September 2014 (UTC)

Gadget to create local copy of Wikidata (to disable Wikidata update)

Sometimes (see topic above) local wikipedia would like to protect the page. Any sysop could do that, except he could not prevent the Wikidata changes to be pushed into protected page. Sometimes additional checks are required (for example for living people pages, semi-protected pages, etc). There is a simple gadget that can create copy of current Wikidata and save it as LUA module.

Prerequirements:

  • make sure that all your Wikibase-related LUA code is migrated from getEntity() to getEntityObject()
  • make sure that all calls to Wikidata code is goes though single LUA function and modify it like the following:
function loadCacheSafe( entityId )
	local status, result = pcall( function() return mw.loadData( 'Module:WikidataCache/' .. entityId ) end );
	if ( status == true ) then
		return result;
	end
	return nil;
end

function getEntityFromId( )
	local entity = mw.wikibase.getEntityObject();
	if ( entity ) then
		local cached = loadCacheSafe( entity.id );
		if ( cached ) then
			return cached;
		end
	end
	return mw.wikibase.getEntity()
end
wef-weffreeze[ResourceLoader|rights=editprotected,delete|dependencies=jquery.ui.dialog,mediawiki.api.edit]||weffreeze.js|weffreeze.css
Module:WikidataCache\/.* <noedit> # local Wikidata cache is protected

As a result any page could be in three states:

  • By default page has no cached Wikidata information, gadget toolbar link is default blue. Sysop could create local Wikidata cache, thus disabling automatic Wikidata update for current page.
  • If cache is created then any page view gadget checks if Wikidata is changed (only if gadget is used)
    • If Wikidata page is still the same (the one used to create cached copy), gadget toolbar link is green
    • If Wikidata page is updated, gadget toolbar link is red. One can check the difference in Wikidata (using gadget) and approve them (update local cache) or ignore them (do nothing)
    • Anyway, one can remove cache (using gadget as well), thus removing Wiidata protection and allowing direct updates from Wikidata to local pages.

Hope this will help to protect your wiki from Wikidata vandalism in protected, semi-protected pages and articles about living people. --- Vlsergey (talk) 10:49, 10 September 2014 (UTC)

I think this is the wrong way of doing things. We rather need more people patrolling Wikidata recent changes by a better watchlist integration and more anti-vandalism tools. Just ignoring changes on Wikidata won't work because then the basic idea that the data stays up-to date automatically is thrown away. I see that local Wikipedias want to prevent their data being vandalized but in my opinion we have to face the problem on Wikidata, not Wikipedia. -- Bene* talk 19:07, 10 September 2014 (UTC)
@Bene*: since our community is disagree to enable FlaggedRevs patrolling, thus preventing client even in far distance future from using stabilized data for living person articles and does not provide feature to stop using updated data even for protecting pages, it's the only way i can agree to use Wikidata in client Wikipedia. Nothing personal, just rules, common for all Wikipedias. Sometimes changes must be reviewed before going public. Sometimes changes must be discussed before incorporated into result page. And discussed on local wiki, not on some non-local-language site, with non-shared watchlist. -- Vlsergey (talk) 01:47, 11 September 2014 (UTC)

On Stack Overflow, most popular tags have a wiki page that describe the concept the tag is about. Since I couldn't find one, I've extracted and reviewed a list of a few thousand Stack Overflow tags and corresponding Wikipedia articles, which should map easily to Wikidata entities. This currently lives in a Google spreadsheet, and it is a less than ideal way to share this information. Is this mapping this the type of information that would be appropriate to store in Wikidata itself, as a new property? What about links to other Stack Exchange network sites? I didn't want to propose a property without getting an understanding of what is in scope and out of scope for Wikidata. Bskaggs (talk) 16:52, 10 September 2014 (UTC)

Bskaggs, I'd say so. Great idea. Something like a 'Stack Exchange tag' property with datatype URL might work well. If you want to get such a property created, the next step I suggest is proposing it at Wikidata:Property_proposal/Authority_control. Please ping WikiProject Informatics and me there via {{Ping project|Informatics}} and {{Ping|Emw}} (or just [[User:Emw|Emw]]) so this can be acted on quickly. Emw (talk) 12:37, 11 September 2014 (UTC)

Badge names

Would it be possible to rename WD badges from "Φ article" to "Φ content"? E.g. list of The Simpsons video games (Q2458013) is a featured list, not a featured article, on en:. It Is Me Here t / c 17:40, 10 September 2014 (UTC)

Featured lists will get own badge, see featured list badge (Q17506997) for the item, and Bugzilla:70332. --Stryn (talk) 18:04, 10 September 2014 (UTC)
What about more obscure ones? E.g. en:Portal:Featured portals, en:Portal:Featured sounds, en:Wikipedia:Good topics? It Is Me Here t / c 11:18, 11 September 2014 (UTC)
... it takes some time but will be possible in the future. Hopefully there will be a checkbox to choose all kinds of badges available in the specific project.--Giftzwerg 88 (talk) 15:48, 11 September 2014 (UTC)
First you have to propose them here, and if there's enough supporters then it's possible to create those after a bugzilla request. You can see our current badges at Category:Badge items. --Stryn (talk) 16:13, 11 September 2014 (UTC)

Extended watchlist support... wasn't so hard

RuWiki Gadget WEF WatchList Example

There is a new gadget in ruwiki that can be used to display wikidata changes in extended watchlist. Could be enabled in settings. Works as follows:

  1. user upload local watchlist to wikidata as page in user namespace (using button "sync" in tools menu)
  2. each visit to local watchlist RecentChangesLinked is obtained in ATOM format and integrated into local watchlist

Currently only for ruwiki, but if you interested, you can help me to translate. -- Vlsergey (talk) 09:10, 11 September 2014 (UTC)

I can't edit anything

Hi,

I don't know if this is a bug so I prefer ask here before making a new bug request.

I can't edit anything with my account. For example, if I go to Q18000000 and I click on any "edit" link, nothing happens. If I write in a field, for example, adding a Spanish description. "Save" link never gets enabled. I've made a screenshoot with an example:

http://postimg.org/image/el1gzxwmh/

But if I logout from my account, everything works fine, and I can edit again:

http://postimg.org/image/6s9fltwe7/

As you can see, I'm not blocked from this wiki https://www.wikidata.org/w/index.php?title=Special:Log/block&page=User%3AJorgechp This happens to me with any browser I try (Firefox, Chromium and Opera).

--Jorgechp (talk) 09:13, 10 September 2014 (UTC)

With me everything works fine except the "Search" field which does not accept any input. - Brya (talk) 11:20, 10 September 2014 (UTC)
I can edit now. It seems to be a problem with Twinkle and Wikidata. --Jorgechp (talk) 13:13, 10 September 2014 (UTC)
Search field is still strange: I have to type a search term below the supposed field location.... Lymantria (talk) 07:39, 12 September 2014 (UTC)

How to model dates without known precision?

Some articles and sources have information like "born around 1709", how to model those values in Wikidata? -- Vlsergey (talk) 04:04, 11 September 2014 (UTC)

See for some of the discussions I am aware of e. g. Wikidata:Project chat/Archive/2014/08#How to store dates as given in a source ? and Help:Modeling/general/time. --HHill (talk) 10:59, 11 September 2014 (UTC)
@HHill: i read the following links and found no clues. Does it mean we have no support for such dates? Shall we introduce some qualifier like "value type" with possible values "exact", "somewhere about"? -- Vlsergey (talk) 04:01, 12 September 2014 (UTC)
@Vlsergey: As far as I understand your question, those discussions I linked to treat precisely the same problem. And yes, afaik we currently have no adequate solution for it (at least for doing it manually). As for the example you give, you might want to model the date „born around 1709“ as something like born between 1699 and 1719. How to do stuff like this technically I don't know, but at least some others have put some thinking into it, and it appears not to be an easy problem. --HHill (talk) 09:07, 12 September 2014 (UTC)
@HHill: «…to model the date „born around 1709“ as something like born between 1699 and 1719…» I don't want to model "around" like this for sure, because it not like in source. There is nothing like "10/20 years precision" in source. My proposal is to add new qualifier called "value type" with possible values like "probable value", "somewhere about value" (or may be even "miscalculated value" or "misspelled value" for obvious mistakes in sources). -- Vlsergey (talk) 09:19, 12 September 2014 (UTC)
And how will machines read/treat this, e.g. in a search or a sortable list? --HHill (talk) 09:26, 12 September 2014 (UTC)
@HHill: well, how machine will threat values like "unknown, but not before 1710" ? The answer is the same -- as you wish. It may throw the item away, put it into the beginning of the list, assume some precision, play some mp3 with Frank Sinatra. But the software engineer shall take such things into account of course. -- Vlsergey (talk) 09:43, 12 September 2014 (UTC)
See same discussion at Wikidata:Contact the development team#Wikidata broken by design?. --JulesWinnfield-hu (talk) 09:55, 12 September 2014 (UTC)
@HHill, JulesWinnfield-hu: proposed new qualifier at Wikidata:Property proposal/Generic to model such values and other sourcing circumstances -- Vlsergey (talk) 13:00, 12 September 2014 (UTC)

A filter for badge removes

Hi, I think it would be useful to have an abuse filter to show a list of deleted badges on Wikidata. I found this delete only because it was on my Watchlist. Then we could check the related wiki, does the badge require deleting or not. I don't know how to do it, but if someone knows... --Stryn (talk) 06:48, 6 September 2014 (UTC)

@Stryn: Special:AbuseFilter/51. This is the first version which is only based on that diff. There might also exist other ways how a badge can be removed. Matěj Suchánek (talk) 07:30, 6 September 2014 (UTC)
Thank you. --Stryn (talk) 19:47, 6 September 2014 (UTC)
@Matěj Suchánek: Why it didn't catch these: [4] [5] ? --Stryn (talk) 15:04, 13 September 2014 (UTC)
Maybe it would be nice to have a filter also for items with added badges, since there were some wrongly added badges: [6] [7] [8]. --Stryn (talk) 15:04, 13 September 2014 (UTC)
@Stryn: New version of the filter based on the two diffs. About the added badges: which cases? E.g. bots excluded? Matěj Suchánek (talk) 16:00, 13 September 2014 (UTC)
Bot-excluded would be fine for now. --Stryn (talk) 16:02, 13 September 2014 (UTC)
Done. Matěj Suchánek (talk) 16:36, 13 September 2014 (UTC)
Now if we add badges they also are marked as "badge deleted"[9]. --Stryn (talk) 18:37, 13 September 2014 (UTC)

Hi there, I'd like to know if there is a tool that could add automatically sitelinks to items. I have a list of items which I already know that have missing sitelinks, and at the moment I have to search for everyone, and then add manually the sitelink to each item. Is there the possibility to make this in a faster way? --Sannita - not just another it.wiki sysop 13:48, 12 September 2014 (UTC)

Creator Copy and paste you list under "Wikipedia pages (one per row)", add your wiki in text box "on site" and click on "Do it!" --ValterVB (talk) 13:57, 12 September 2014 (UTC)
@ValterVB: No, I don't need to create items, I need to add sitelinks that I know that are missing to existing items. --Sannita - not just another it.wiki sysop 14:07, 12 September 2014 (UTC)
The option "Do not create item if label/alias exists" can be useful? If the name of the page exist in label/alias on other item, Creator don't create item but show those items. --ValterVB (talk) 14:16, 12 September 2014 (UTC)
@ValterVB: Yes, but I always have to open manually the item, and insert manually the sitelink. I would like to do this two operations automatically. --Sannita - not just another it.wiki sysop 15:02, 12 September 2014 (UTC)
I also want it. Currently I must use Special:ApiSandbox to do that. Probably @Magnus Manske: to allow adding sitelinks using QuickStatements.--GZWDer (talk) 08:59, 13 September 2014 (UTC)
There is a way to get around it: first create items and then merge using QuickStatements. Lymantria (talk) 08:12, 28 September 2014 (UTC)

Proposal: enable FlaggedRevs on wikidata

Actually, i don't understand why is it not enabled yet. So far we can enable it to track vandalism and care about export options later. -- Vlsergey (talk) 11:21, 9 September 2014 (UTC)

 Oppose I don't think FlaggedRevs is needed on Wikidata.... tracking vandalism is done by patrolling already. — by Revicomplaint? at 11:38, 9 September 2014 (UTC)
This doesn't work out well really. Just going back 24 hours in the recent changes at any given time easily brings up loads of undetected vandalism. This is only sad as long as Wikidata is more or less just a project on its own, but once a change in Wikidata will possibly reflect on hundreds of Wikimedia projects and possibly in many thousands of articles (and an unknown amount of third-party sites) it will become totally unacceptable. --YMS (talk) 11:46, 9 September 2014 (UTC) PS: To check my statement, I quickly checked the unpatrolled edits being 24 to 26 hours old (older wasn't possible, as the Recent Changes page timed out if I raised the limit). I did not actually find vandalism there, but several unproductive edits nonetheless: [10], [11], [12], [13], [14], [15]. --YMS (talk) 12:17, 9 September 2014 (UTC)
flagged revision is the patrolling with ability to patrol the bunch of revision by single click and simple ui to compare patrolled and non-patrolled versions, integration with watchlist and special pages to track outdated patrolled page and non-patrolled. The functionality of 'current system is not enough, from my point of view. For example, it marks revision as checked even if it is created by trusted user, even if it based on non-checked revision by some vandal, and workflow to check, say, 100 revisions when part of them are not correct, is not simple. -- Vlsergey (talk) 11:53, 9 September 2014 (UTC)
 Oppose, first we also need to know if it works with Wikibase. Sjoerd de Bruin (talk) 11:43, 9 September 2014 (UTC)
i don't thick there shall be any problems (wikidata is the same revision-based system so far), but of course it should be checked on testwiki first. -- Vlsergey (talk) 11:55, 9 September 2014 (UTC)
 Support Patrolling is not enough when we compare the number of items and the number of contributors. And this can be a good argument in favor of data use by Wikipedia: there are a lot of opposition to use Wikidata because few wikipedians follow the items modifications on wikidata. And finally this can be a good way to ensure a larger use of a common data structure (an occasional contributor isn't aware of all possibilities to store data. The question is to know if we want to implement FlaggedRevs now or when we reach a more stable state with wikidata development. Snipre (talk) 12:00, 9 September 2014 (UTC)
we can introduce "not vandalism" level right now and wait for "has good structure" level until we have good development. Actually, we can also introduce "checked with sources" level now as well. It would be a big "pro" to use it on external projects. -- Vlsergey (talk) 12:10, 9 September 2014 (UTC)
 Support I used to do patrolling, and usually was quite alone in doing so. Some others do, but you'll find undetected vandalism (and many, many unpatrolled edits in the first place) even for non-current edits all the time (see my comment on Hym411's vote above). We obviously do not have enough manpower to rely on the "somebody probably will see it" type of vandalism fighting. --YMS (talk) 12:17, 9 September 2014 (UTC)
 Support Unfortunately vandalism is already present on wikidata and with higher WD usage on wikis it will be rising. I am afraid that at the moment big part of "non-english detectable vandalism" is undetected. --Jklamo (talk) 12:25, 9 September 2014 (UTC)
 Support I like FlaggedRevs pretty much and enabling it here too would help other FlaggedRevs wikis to feel more comfortable using Wikidata, as new users' edits would also require a second pair of eyes here before they go "live". Anyway, we must definitely ensure the FlaggedRevs extension works smoothly together with Wikibase first before disabling patrol. Vogone (talk) 12:27, 9 September 2014 (UTC)
  •  Comment There are many thousands or tens of thousands of IP edits per day. How will we check them all and mark them as reviewed?  – The preceding unsigned comment was added by Jakec (talk • contribs).
Are there? Recent changes list currently shows me quite exactly 1500 IP edits in the last 24 hours. That's some, but I wouldn't call it "many thousands or tens of thousands".
And if there are: We basically have two options (simplified world model following): Don't check them and hope that nobody ever really vandalizes Wikidata, or have a system for how to check them and how to see what has been check and hasn't yet. --YMS (talk) 14:14, 9 September 2014 (UTC)
  •  Comment: After reading mw:Help:Extension:FlaggedRevs I see that this can be configured in many different ways, so it may be better to have a more precise proposal to discuss. Now users who comes from wikis using flaggedRevs in different ways, may have different conceptions of how flaggedRevs can or should work in Wikidata. And users who do not come from wikis using flaggedRevs, do not know what this is about at all. Regards, Dipsacus fullonum (talk) 13:56, 9 September 2014 (UTC)
 Oppose FlaggedRevs as-is would mesh very poorly with Wikidata's interface and database software. If this ever will happen, it will have to use a completely new extension. If vandalism is the problem, then we need to use normal semi-protection and patrolling more often.--Jasper Deng (talk) 14:03, 9 September 2014 (UTC)
Semi-protection is no option if we have millions of items and thousands of properties and sadly don't know in advance which of them is going to be vandalized today. --YMS (talk) 14:19, 9 September 2014 (UTC)
 Support Not today but I think we will need it very soon; however, it will be big change which will also cause some other things to change/improve (e.g. Widar edits not allowed with no confirmed status etc.). Matěj Suchánek (talk) 14:23, 9 September 2014 (UTC)
  •  Neutral (almost oppose), it depends of which settings we want. If we should check all edits made by anonymous users and newbies, I say no thanks. I don't have any idea how would it even work with Wikibase. Also seems like the developers are not very willing to enable the flagged revisions as seen here. --Stryn (talk) 15:24, 9 September 2014 (UTC)
  •  Oppose, we do not have enough manpower to monitor our 18M items.--Ymblanter (talk) 15:25, 9 September 2014 (UTC)
    Though pending changes for selected items could help.--Ymblanter (talk) 15:26, 9 September 2014 (UTC)
    Manpower is not an issue here. Nobody forces people to do anything here. I would like to use this on pages in my watchlist and help other people with the same pages. It's okay if this system is used only at 10% of pages than nowhere at all. And still, we need manpower to fight vandalism. It will be much easier to fight catch vandalism with FlggedRevs. If we don't have power even for this then this project is useless. -- Vlsergey (talk) 17:16, 9 September 2014 (UTC)
  •  Comment. In a wider context, it would be nice if Wikibase could be able to represent multiple branches of its data, tracked at a very granular item/property level as to where different branches differed from a consensus 'trunk' version, without duplicating agreements. Tracking a Stable/Unstable version pair would be one example of this, with a trunk and one branch. A private 'Office' branch, containing some suppressed information, would be another.
A larger-scale use-case (Proposal at meta / Wikidata archived chat) could be common Wikibase back-end shared by a number of different genealogical organisations each running their own genealogical wikis, where each separate wiki (or even each separate user) for their own view would be able to over-ride the central trunk to present their own personal assessment (eg which John Smith out of a number of possibilities should be considered the probable father of John Smith II). -- Jheald (talk) 16:04, 9 September 2014 (UTC)
  •  Oppose beyond any oppose I've done ever. I'm doing this for two reasons. 1. Last time I checked, Wikibase does not work with FlaggedRevs as a matter of fact - when I tested it - Wikibase broke upon the enabling of it. As far as I know, no patch has been made or a real test to fix this so this is purely based on my own testing. 2. This defeats the purpose of Wikidata. The idea is every change is available to be used everywhere by everyone the second it is made. Adding in a few day or perhaps a week delay because 'someone didn't click accept' is stupid. We get vandalism, yeah sure. Everything gets vandalism. We need to prevent vandalism in ways which don't block our data or contrast the overall objective of a project. John F. Lewis (talk) 16:26, 9 September 2014 (UTC)
    • 1. Non working because of bugs is not a good reason for complete decline. If we agree to enable it, then we can next try to find resources to fix this extension and/or wikibase. 2. The main idea of Wikidata is to provide _reliable_ source of data. If community would decline to enable this feature on Wikidata in near future then, at least in Russian Wikipedia, we will need to disable using wikidata completely on stabilized pages and living person pages, or provide some intermediate cache with manual update from Wikidata. Still this kind of workaround will be much better than situation when some vandal changing date of birth or adding date of death to page that is stabilized and shown on ru.wiki front page. 3. Also, it seems you have very serious misunderstanding how Flagged Revision extension works. It does not prohibit data to be used. It allows to mark revisions as checked or unchecked. That's all. To use or not to use checked revision is solely client decision. So far, of course, all Wikibase client will use current revision (because Wikibase Client does not support checked flags), but, in future, it would be appropriate for some Wikipedias to use checked revisions only. Not everyone wants system like "one click and 1k changes". -- Vlsergey (talk) 17:14, 9 September 2014 (UTC)
  •  Oppose. If our level of patrolling isn't enough without flaggrevs, it won't be enough with it either. If there's X amount of changes that we simply can't patrol to let through, better to let them all pass through unchecked than not pass through at all. Anyway, this proposal isn't technically feasible, as the extension wasn't built for this, and it would probably be extremely difficult to modify it to allow this. --Yair rand (talk) 17:31, 9 September 2014 (UTC)
    My thoughts exactly. --Waldir (talk) 18:59, 10 September 2014 (UTC)
  •  Comment If I remember correctly when arbitrary access will be fixed, update of Wipedia will not be immediately, but postponed just to decrease the problem of vandalism. --ValterVB (talk) 18:22, 9 September 2014 (UTC)
  •  Oppose to check every IP edition in Wikidata. It's not viable /  Support to protect (somehow) well-sourced statements, letting IP's modify other statements without sources or add alternative values to the existent statements. It's needed a lot of time and resources to source correctly an item, we cannot let an IP simply delete it. A database needs stability.—Totemkin (talk) 01:29, 10 September 2014 (UTC)
  • I suppose it's a matter of growing. Initially, we don't need patrolling and fancy that undetected (or slowly detected) vandalism isn't going to do much harm. Eventually, as this wikibase instance itself grows, it's easy to break things, and some things may have to be protected from trouble in some way. And I don't want them to protected up to a certain user rights level, — sysop only or autoconfirmed only, as this prevents IP contributors from editing — so I'd like to support flaggedrevs here, as soon as it's technically possible.
Of course, if we have to ask such question, maybe we need more helpers (patrollers, sysops). This is a relatively common problem at many remotely big sister projects. Why not stick a "Want to help out with maintaining this wiki? Get involved!" in site notice to attract people interested in helping with the project? --Gryllida 04:45, 15 September 2014 (UTC)

instead on summary

It is very sad to me, but there won't be consensus for using this extension on Wikidata. Because of that i begin to develop additional scripts to disable direct usage of Wikidata on ruwiki to prevent vandalism from Wikidata to be immediately delivered to protected and semiprotected ruwiki pages. -- Vlsergey (talk) 17:50, 9 September 2014 (UTC)

  •  Comment It's interesting. There's also quite a lot of fear amongst the vandal-fighters on Commons about the potential implications of turning on Stage 2, never mind Stage 3 and Commons' own CommonsData wikibase, unless much better integration can be achieved with the existing vandal-fighting tools and workflow. En-wiki as well has (if I remember correctly) been very cautious about green-lighting Phase 2 for infoboxes -- IIRC, there is an approval process for templates that use Stage 2, and so far only a couple of templates using it. There is a clear problem here that needs thinking about, or there is going to be continued resistance from the wikis.
The issue is that changes made on Wikidata don't produce changed wikitext on the wikis, which is what the anti-vandalism tools (and flagged revision systems) work on. I don't know what could be done about this; but I wonder if there could be a MediaWiki API option to show changes on Wikidata as changed article wikitext; and to trap any attempts to change back that 'virtual' wikitext and transmit the deltas as edits to Wikidata. That might make it possible to detect and fix vandalism on Wikidata through more-or-less the current tools running on the client wikis. Jheald (talk) 19:34, 9 September 2014 (UTC)
  • I imagine things will get better as the tech improves. We still don't have a way to get Wikidata changes to show up in watchlists for those who use Enhanced Changes, which many people do. We don't have a way of adding RelatedChanges lists to watchlists, or even limiting RelatedChanges to transcluded templates and Wikidata items. There's still no live feed of changes on anything. There's no Wikidata log showing when sitelinks get changed. --Yair rand (talk) 21:49, 9 September 2014 (UTC)
Even if you optimize the track of modifications some contributors don't want to see their watching list doubling by integrating their current Wikipedia articles with the corresponding wikidata items. They work in a specific wiki and they don't want to see their "workload" increasing by using wikidata: wikidata should reduce some work not doing the inverse. If you try to say to that people that they have to follow a new bunch of modifications they will say they don't need wikidata: they were able to work without it until now so why changing for a system which is not more secured and increases their time to fight vandalism ? Wikipedian contributors of big wikipedias are not interested by wikidata: their have their own rules and they are working to improve a already good data structure in Wikipedia articles. They are creating lists and categories so wikidata doesn't offer new possibilities for them. So if they can point a single disadvantage they will refuse to enter into matter about wikidata. The only way to enlarge the use of wikidata is to consider it like a service and services has to match customer desires. Without that wikidata won't find a large set of applications in WP. Snipre (talk) 11:17, 10 September 2014 (UTC)
+1. -- Vlsergey (talk) 11:47, 10 September 2014 (UTC)
+2. -- Vogone (talk) 12:30, 10 September 2014 (UTC)
That tends not to be how people look at Commons. Why would Wikidata be different? --Yair rand (talk) 20:37, 10 September 2014 (UTC)
@Yair rand: What kind of vandalism in Commons can have an influence on WP ? Only one: to replace the picture by another one. You can modify all the text, the license, the author name, this doesn't affect the use of the picture on WP. And to erase a picture by a new one you have to follow one process with several steps. This is sufficent to discourage the vandals which are in favour of 2 clicks actions. So WP people aren't aware of most of vandalism in Commons. Snipre (talk) 21:23, 10 September 2014 (UTC)

FlaggedRevs on wikipedias

Why not to do it the other way around? Wikipedias can activate FlaggedRevs and they can patrol the incoming changes from Wikidata if they wish. Although it would be interesting to share which statements have been patrolled to increase quality.--Micru (talk) 01:00, 11 September 2014 (UTC)

  • @Micru: activating FlaggedRevs does not help to track changes in data from Wikidata, it is just "another Lua generated output" from FlaggedRevs point of view. you can see it by example on German or Russian wikipedias. Just doesn't work this way. Also, why to fight vandalism in multiple places instead than on source? -- Vlsergey (talk) 01:37, 11 September 2014 (UTC)
    • @Vlsergey: The reason to fight vandalism in more than one place is that then you get more eyes on the problem.
Other reasons are that people on the wiki get to see the effect of the edit in context, which may make it much more obvious. Also they are likely to speak the language of that wiki, whereas general patrollers on Wikidata may not. Also, we may not have many patrollers on Wikidata. Also patrollers on wiki may be more motivated, as they are the ones whose content is actually facing end-users; and it is their 'most valued' article which is being defaced.
So (IMO) there are a lot of reasons why it would be very nice to involve patrollers on the end-wiki. And, certainly from Commons, there are patrollers who would like to be able to see all changes to their pages.
But it's a question of tools, and hooks for tools.
It seems to me there are two key issues:
  • (1) How to allow vandal-fighting tools on wiki to be able to see relevant changes on Wikidata (if they want to).
As you say, at the moment, all the tools on wiki see at the moment is 'just "another Lua generated output"'. Could there be an API switch on MediaWiki that, when selected, adds a commented list of all the properties of the Wikidata item with their values, for any Lua call that pulls data from Wikidata, or incorporates another Lua call with such a list? (Might be good for debugging too). If changes in that annotated wikitext could be tracked, then it might be possible to use exising tools to identify bad changes with minimal modifications. The software is already able to flag wiki pages as changed, if the Wikidata item has changed. This would be an extension to be able to show what that change was, nearly in context.
  • (2) How to allow vandal-fighting tools on wiki to reverse relevant changes on Wikidata (if they need to).
This also needs some thinking about, because at the moment the hooks aren't there to let relevant changes (which may be larger than just one language) be reversed, all from the same tool that's patrolling changes on wiki, rather than from Wikidata.
However, if the MW software is being extended to present the patrolling tool with a 'virtual change' when the WD is adjusted, presumably it could also be extended to trap a 'virtual revert', identify it as such, and propagate it to Wikidata as a revert.
Yes, it would take a certain amount of plumbing. But I think we should look on this as an existential issue for Wikidata. It really is that important (IMO).
If wikis are scared of using data from Wikidata, because they can't trust its integrity against vandalism, Wikidata will be decimated in the momentum it otherwise could have had. As every experience from 10 years of wiki tells us, data that is used is more likely to become data that is right. Data that is used is more likely to involve people to add more data. Data that is used puts the project on the map.
At the moment there is fear of using Wikidata -- fear on en-wiki, fear on Commons, fear even on ru-wiki for high-value articles. This has to be recognised as a high-stakes issue, that needs to be seen for a priority, with a route-plan for how to address it. Jheald (talk) 07:35, 11 September 2014 (UTC)
@Jheald: I don't know if you already spoke with the people who don't want to use WD in its current development but they are not interested to follow the WD items: they just want to track changes of the data which are used in their WP articles. I don't know if this represents the major part of the wikipedians who are currently against the use of WD, but this is a part of them. Your description can be simplified like that: use of WD = same problems of WP with a higher complexity in detection and correction. Saying that we have to create the soft to have more people following WD items is not understanding the problem: some wikipedians don't want to learn the WD system and do that job because they are already doing it in a very simple way on their WP. Even if you create the soft as you describe, this just means more work for them for data they already have most of the time (we are speaking about large WPs). What is the advantages for these wikipedians of using WD ? What you propose is just doubling the number of diff in their watchlist and working in different systems (WP and WD). For them WD is an option, and as they can choose to use it or not, they want to have more benefit than what they have now. WD doesn't provide any insurance about data quality and about data preservation, nothing more than what WP is providing. So what are the benefits of using WD ? More data ? Most of the current data are extracted of the WPs so few chances for large WPs to improve their articles. Snipre (talk) 12:19, 11 September 2014 (UTC)
Hi @Snipre:. Thanks for the comment.
I think there are two differences between what I've suggested, and what you say:
  • (1) It wouldn't be doubling their watchlists, because (if we got the API option right) they would only see any changes that were being presented in their WP articles. So if somebody changes a Hungarian label, that wouldn't ping a watchlist on en-wiki.
  • (2) Again, if we got the software right, they wouldn't have to learn WD, just revert with Huggle on their own WP the way they do at the moment, and have the MediaWiki software pick up that that revert is actually a revert to be propagated to WD, rather than made on WP. In this way, the difference for the vandal fighter's experience would be minimal: the aim is to make it that they should still be able to do it in a very simple way on their WP.
So I hope the suggestion actually already answers your two key objections.
As to whether people object to WD because they don't see any gain from it: (1) smaller wikis have a huge amount to gain from WD, and still need to fight vandals; (2) Commons has a lot to gain from WD - eg automated multi-lingual linkbacks form Commonscats to corresponding wiki articles in each language, which will no longer be done through sitelinks; (3) Even en-wiki has a lot to gain from the possibility of systematic quality control of data, which WD may be able to offer; plus from automated template population for new articles.
So I think the resistance really can be lessened, if we can find a way for existing vandal-fighting tools to be adapted to just work 'automagically', with minimal change to vandal-fighter experience. Jheald (talk) 13:10, 11 September 2014 (UTC)
To make even more concrete what I have in mind, suppose in a wiki page you have wikitext including a template
{{info drawn from Wikidata}}
what I'm suggesting is an API option that would add the property values pulled by using that template. So with the option on, the wikitext would appear to say
{{info drawn from Wikidata}}<!-- WD_EXTRACT -->label = Mona Lisa| P170:painter = Q762:Leonardo da Vinci| P571:date of foundation or creation = 1503<!-- /WD_EXTRACT -->
For a change to the wikidata, with the option on one would also be able to see a corresponding virtual diff in the above (calculated on request on the fly). Alternatively, if one was viewing without the option there would be no change, no diff, and of course no change in the actual article wikitext.
Finally if one reverted the virtual diff, that revert would be sent as a revert message to revert the edit on WD.
I'm not saying it would need no work. (It's a whole new mode for viewing wikipages, with wikitext + some template expansion, that I'm asking for, after all). But I don't think it would necessarily be a huge amount of work, and I think the advantages would be worth it. Jheald (talk) 13:45, 11 September 2014 (UTC)
Ok, it seems good against the opposition to use WD. But before starting to develop any code, better start to take the temperature among the wikipedians: developing a tool to use WD should be done to match most expectations/to reduce most critics. And as all projects this should be compared to the adaptation of the FlaggedRevs to WD: the FlaggedRevs in WD is perhaps not the optimal solution but perhaps the easiest to implement in a short time. If we have to wait one year to develop a new system we will continue to loose interest of people. This was IMO the main reason of the few numbers of wikidatians: too much expectations at the beginning when a lot of limitations were present and now very few of active contributors even if we eliminate some constraints. Snipre (talk) 14:16, 11 September 2014 (UTC)
I don't think it would take a year, if the will was there. The code already has to keep track of which wiki pages reference an item, to mark them dirty if the item changes. The biggest change needed for this proposal would be to create a new per-wikipage extended diffs table, that recorded each time the page was marked dirty due to a change at wikidata, with a link to the identity of the diff in the wikidata diffs table.
After that, producing a mechanism to display such diffs, and trapping any reverts, should be a couple of reasonably quick hacks.
It's worth noting that applying FlaggedRevs to WD would also be a major undertaking. The big question is: what criteria do you use to mark an edited item page as 'okay'. Suppose an item gets multiple edits in multiple languages. Does a Russian editor have to confirm every edit in Dutch before the page is marked good for ru-wiki? Or if a Russian editor confirms the latest Russian edit is okay, does that re-set the flags for every other language as well? I think, for each item, you would really need a separate 'flagged/unflagged' status for each attached wiki. @Micru: has given some thoughts below, but I think they don't actually go far enough to do the job. Jheald (talk) 14:41, 11 September 2014 (UTC)
  1. A change is made on Wikidata directly or through another wiki. The statement is marked as "non-flagged" on Wikidata (value not editable here)
  2. The value is propagated to the Wikipedias. If they are using flaggedRevs, then they might have configured if they trust flaggedRevs from other wikis or not
  3. If they trust other wikis then as soon as some wiki approves a value, the statement is marked as "flagged" on Wikidata and the value is updated for all wikis. If one wiki does not trust the others, then the change is marked as "not patrolled" for their wiki.
I think for this to work value usage tracking would be necessary. I agree this would improve trust significantly since it would give pedias control over the data with the option to benefit from the reviews from others. @Lydia Pintscher (WMDE):.--Micru (talk) 11:55, 11 September 2014 (UTC)
  • Generally I support giving sister projects control over patrolling Wikidata items that affect them. But this shouldn't be the only means to patrol things. This wikibase instance should still remain capable of detecting and handling unambiguous vandalism on its own site. --Gryllida 04:51, 15 September 2014 (UTC)

The creator of an event, a competition...

hello,

I saw that we had the properties founded by (P112) (Domaine : Organization, place) and creator (P170) (Domaine : painting, sculpture, other works of art), but do we have a property to indicate the creator of events, like international observance, for exemple. World Vegan Day (Q152977) was created by a woman, World Water Day (Q183740) by an intergovernmental organisation... In continuation, location of formation (P740) seems to refer to a group (company/organization/band...), but in the case of a competition, like Wiki Loves Monuments (Q1353202), how can we say that it was originally organized in the Netherlands? I don't see anything that seems to fit in Wikidata:List of properties/Events.

I also want to mention another concern on international observance. Sometimes they do not take place on a specific day, such as International Beer Day (Q240661), which takes place on the first Friday of every August. In this case, how to set it? Some religious holidays, such as Easter (Q21196), seems to have the same concern. Okki (talk) 20:14, 14 September 2014 (UTC)

I think the scope of founded by (P112) should be broadened to include events. After all, an event can have a founder as well. (And I instantly thought of P112 when I saw the section header) --Jakob (talk) 21:34, 14 September 2014 (UTC)

Countries population

I noticed that all or most (I did not check all) countries do not have their current population on Wikidata. Is there anything preventing adding the population (say by parsing the English Wikipedia)? Can it be done by bot?--Ymblanter (talk) 14:49, 15 September 2014 (UTC)

There's many (Special:WhatLinksHere/Property:P1082) countries where is already their population. I think it's ok to import them from enwiki, if there's a source for populations. --Stryn (talk) 14:59, 15 September 2014 (UTC)
Please use another method than just parsing WP:en. Primo because of the problem of the source secundo because I don't understand why WP:en is more reliable than WP:de for example. 141.6.11.18 16:12, 15 September 2014 (UTC)
You can use at least this dataset. We will have at least one reference with a time value. 141.6.11.18 16:17, 15 September 2014 (UTC)
This is perfectly fine with me, though I would rather have it made by bot that do it myself.--Ymblanter (talk) 16:21, 15 September 2014 (UTC)
Nobody said that enwiki is more reliable than other Wikipedia. It was just an example. The CIA link you gave looks good. So if it can be used as a source it would be great. --Stryn (talk) 16:23, 15 September 2014 (UTC)
Eventually it can be improved with the results of censi etc, but I think as an initial point it is perfect.--Ymblanter (talk) 16:37, 15 September 2014 (UTC)
@Ymblanter: For USA I have already prepared the BOT: see at Bot request. --ValterVB (talk) 18:59, 15 September 2014 (UTC)
I have seen it, thanks.--Ymblanter (talk) 19:39, 15 September 2014 (UTC)

Cleaning Wikidata Sandbox (Q4115189)

Please add a JS tool or bot for cleaning or drain claims of Wikidata Sandbox (Q4115189). Some times the page has many claims and it will slow for loading also reading the item's entities is difficult - Yamaha5 (talk) 21:20, 15 September 2014 (UTC)

calling all German and Italian speakers

I've been making lists of items where the item's description or label has zero (0) words in common with the article of the Wikipedia in that language, or in other words two lists, one where Description ∩ Article = Ø and the other where Label ∩ Article = Ø. This method is good at finding unhelpful edits in English so I tried it for German and Italian, and unfortunately it is very inaccurate but a speaker of that language can scan the list and quickly find vandalism or other junk. --Haplology (talk) 01:47, 16 September 2014 (UTC)

Thanks for these lists. I have started to work on the German one. But there might be some false positives, e.g. Isaac Habrecht (Q1673486). Its German description "Uhrmacher" is found twice in the German article. --Pasleim (talk) 19:23, 16 September 2014 (UTC)
Thanks for the feedback. I think the problem with Isaak's article was that the extractor (WikiExtractor.py) was confused by the * mark. The script throws away lists and maybe it thought that the text following * was a list item. The other instance of "Uhrmacher" was inside a template, and the script throws out templates too. Maybe later I'll scan the XML dumps directly, but it seems hard... --Haplology (talk) 00:41, 17 September 2014 (UTC)
Thank you for the Italian list. I have started to work on it. --FRacco (talk) 01:22, 17 September 2014 (UTC)
Thanks, noted. --Haplology (talk) 10:55, 17 September 2014 (UTC)

@Haplology: Can you make this list for other languages too? e.g. czech (cs) one? JAn Dudík (talk) 05:23, 17 September 2014 (UTC)

I'd be glad to. I make them one by one and and it takes a little time but I'll put it up at User:Haplology/cs when it's done. --Haplology (talk) 05:28, 17 September 2014 (UTC)
@JAn Dudík: It's up. It might be only 10% accurate but I hope it helps.
I posted this at Wikidata:Café, but in case any interested Spanish speakers are reading this, you might want to look at es. --Haplology (talk) 10:55, 17 September 2014 (UTC)

@Haplology:, can we try Russian too? But list for descriptions can be very bad because of declensions... --Infovarius (talk) 09:08, 18 September 2014 (UTC)

Please merge two items

For categories: Q9605295 and Q8768211 . Thanks, --Piotrus (talk) 07:15, 16 September 2014 (UTC)

Done by GZWDer. --Dereckson (talk) 11:05, 16 September 2014 (UTC)

request to get items without labels in language XX

I'd like to get all items with only russian label - or other language - without label in FR language... is it possible ?

Special:EntitiesWithoutLabel/fr gives ALL items without FR label, in antechronological order, which is not what I'm looking for. Is there an autolist request that would do it ?

Even better would be to get all instance of (P31)human (Q5) without FR label :) - or any statement/any language combination, of course ;)

That would be very useful :) --Hsarrazin (talk) 12:29, 16 September 2014 (UTC)

Tools can offer you results for queries you can execute in 0-20 seconds.
When a 4-10 minutes time is required, this is not convenient for web interfaces. You have to ask what you want previously, so we can prepare a periodic job to run a query and format the result (or request a Wikimedia Tool Labs access if you wish to dive into SQL and do yourself such queries).
I'm preparing the instance of (P31)human (Q5) to see if it's a good strategy to automate that. --Dereckson (talk) 12:06, 17 September 2014 (UTC)
sorry :( - I thought it was possible with Autolist but I just could not get the syntax ok... I did not want to make you build a tool :) --Hsarrazin (talk) 12:27, 18 September 2014 (UTC)

Get Q for the current Wikipedia page

I really stock with it. Say I am on w:ru:Фотиева схизма and I need to know that it is Q3813712 at Wikidata. The engine itself perfectly knows it as the link to Wikidata is already at the page side menu. Yet I failed to find any obvious way to obtain this data either by "magic words" or by mw:Extension:Wikibase Client/Lua. So far I am using quick'n'durty way over API and Javascript: first quering https://www.wikidata.org/w/api.php?action=wbgetentities&sites=ruwiki&format=json&props=info&titles=Фотиева_схизма and second (as Q property in the returned object is actually what we need to find) a lesser trivial for-in loop: 

function onSuccess() {
  var data = JSON.parse(xhr.responseText);
  var q = '';
  for (q in data.entities) {break;}
  return q;
}

I agree that it looks just as it is: a rather sick pervertion — but I really couldn't find yet something normal. --NeoLexx (talk) 13:18, 16 September 2014 (UTC)

There is also mw.config.get('wgWikibaseItemId') Javascript. --JulesWinnfield-hu (talk) 14:16, 16 September 2014 (UTC)

After a throughout reading I also found a way over API of the corresponding Wikipedia via mobileview query. For the same example from ruWiki it is possible
https://ru.wikipedia.org/w/api.php?format=json&action=mobileview&prop=pageprops&pageprops=wikibase_item&page=Фотиева_схизма
and then
Q = jsonObject.mobileview.pageprops.wikibase_item for Wikidata API compliant form or
Q = jsonObject.mobileview.pageprops.wikibase_item.substring(1).parseInt(10) for WDQ API compliant form.
Still it most definitely needs to be a feature of action=wbgetentities of Wikidata API itself, not some side use of mobileview from local wikis. And WD/WDQ format choice in the query itself would be also helpful. --NeoLexx (talk) 11:29, 18 September 2014 (UTC)

"Instance of" for periodic events

Between Frankfurt Book Fair (Q57293) and 2010 Frankfurt Book Fair, which one is an instance of trade fair (Q57305) ? (I would say the 2010 edition). And any idea for the P31 of the other ? --Zolo (talk) 07:28, 17 September 2014 (UTC)

I would say that the 2010 Frankfurt Book Fair is an instance of Frankfurt Book Fair (Q57293) which is a subclass of trade fair (Q57305), thus implying that the 2010 Frankfurt Book Fair is an instance of trade fair (Q57305) without having to add an extra statement. --Yair rand (talk) 08:32, 17 September 2014 (UTC)
That seems reasonable, but what I do not like is that it does not make any distinction between say "Frankfurt Book Fair" and "Book fair". There should be something telling that Frankfurt Book Fair feels like an individual event, while Book fair does not. Maybe we could need an item Frankfurt Book Fair and Detroit Motor Show, but not to "Book fair" or "auto show". But I know neither how it should be labelled nor how it should be structured. If the new item is used as a P31 for Frankfurt Book Fair, it should probably not be a subclass of trade fair, else both Frankfurt Book Fair and 2010 Frankfurt Book Fair would end up being instances of trade fair. --Zolo (talk) 08:54, 17 September 2014 (UTC)
This imo is related to the metaclass notion : if Book fair is a class of periodical events, then "Frankfurt Book Fair" is an instance of it. To be consistent, we could create two items Book fair for the class of sigular event, and Periodical Book Fair for the class of events. Then we coud have :
TomT0m (talk) 11:47, 17 September 2014 (UTC)
To draw a more complete picture : imagine we associate properties to instances of a class. The periodical events class is then convenient, it would have a potential periodicity or day in year property associated. The Event class would have the point in time (P585) View with SQID property associated, on the contrary. This picture is consistent with the scheme I proposed, the <Frankfurt Book Fair> has a periodicity, and the <2010 Frankfurt Book Fair> has a date.
I'm with Yair rand on this: 2010 Frankfurt Book Fair is an instance of Frankfurt Book Fair (Q57293) which is a subclass of trade fair (Q57305), or book fair, or periodical book fair. Emw (talk) 00:37, 18 September 2014 (UTC)
 Support LaddΩ chat ;) 01:55, 18 September 2014 (UTC)
It seems that we all agree that the 2010 Frankfurt Book Fair should be an instance of Frankfurt Book Fair, and the Frankfurt Book Fair an instance of Book Fair. But I think like TomT0m that we should have a P31 (or, perhaps, a p279) in Frankfurt Book Fair so that we distinguish items about a identifiable fair like Frankfurt Book Fair from more generic subclasses of book fair like children's book fair. "Periodical Book Fair" might not be the clearest label though, because it feels like it is a subclass of Book Fair while the two classes are really disjoint). --Zolo (talk) 07:54, 18 September 2014 (UTC)
Yes, not only they are really disjoint, but if we associate a level in the individual (0)/class (1)/metaclass or class of classes (2) model I proposed, one is on the (1) level (the Frankfurt BookFair class) and the other on the (2) level (the <Periodical Bookfair> metaclass). Conceptually it is important not to mix levels if we want to keep things well founded : an item in the level (1) can only be a subclass of other items in the level (1), and an instance of items in the level (2), an item in the (0) level can only be an instance of an item in the (1) level, and absolutely not an instance of items in the level (2) as this would mix class and metaclass instances, ...
This works pretty well in our case here : a specific edition of Frankfurt Bookcase is an instance of Bookcase, Frankfurt Bookcase (as a class of event) is an instance of <periodical events> (and periodical events instances are classes of concrete events themselves), and this is also consistent with the class/properties of their instances classical scheme we also find in Object Oriented programming languages, or in OWL in a more powerful way.
But you are right, maybe another label to <Periodical Bookfair> would help, or at least an explicit description like Bookfair events classes in a common place and date in year. TomT0m (talk) 09:49, 18 September 2014 (UTC)

President of Bolivia

This item is a mix of lists and singular. I am quite happy to use it in the singular but I am not well able to distinguish between them in all the possible languages. Truthfully, I only need the singular and I cannot be bothered splitting them properly.

What I can do is create a split and chuck out all the obvious list items. This does create a mess. However, this is a side effect of the "decision" to split. My question therefore is "what to do". As it is I just assume that this instance is singular and I add all presidents of Bolivia to it. Thanks, GerardM (talk) 16:39, 15 September 2014 (UTC)

GerardM You know my opinion. All these pages, whether they are called 'list of' or not, relate to the class of people who have held the office of President of Bolivia. As such it should be the target of 'office held' statements about these people and should be renamed to reflect this. Filceolaire (talk) 20:23, 15 September 2014 (UTC)
In Russian this item it linked to list. And list is not a valid option for "office held". It shall be split in two items ("President of Bolivia" and "List of presidents of Bolivia") and used as value of "office held" only after that. Well, you will brake interwiki by doing that, so take care. -- Vlsergey (talk) 06:16, 16 September 2014 (UTC)
Hoi, I love opinions. I do not know Russian and most other languages. I can break things up, I cannot put them back together again. A list is not a building and an institution like you see often in a college. It makes sense to break these up. Not so much in lists and items. They are a WMF construct anyway. Thanks, GerardM (talk) 06:26, 16 September 2014 (UTC)
@GerardM: another option is not to care about interwiki, create new element "President of Bolivia", NOT move interwiki to it and use it as qualifier both to list and as "office help" value. -- Vlsergey (talk) 06:31, 16 September 2014 (UTC)
From a data management point of view this is a hopeless proposal. It is much better to have two items, one for list and one for singular and isolate the links waiting for someone to fix things. What would we do with all the existing statements for instance... The new item would be the singular anyway. Thanks, GerardM (talk) 06:49, 16 September 2014 (UTC)
@GerardM: From a data modelling point of view 'lists' don't exist. They are a strange wikipedia concept we have to include because they have pages. Classes however have a meaning and fit right in on wikidata.
having two items and splitting the sitelinks between them makes interlanguage links between them makes wikipedia worse too. Splitting has no advantages
Vlsergey The Russian article may be called a 'list' but it is still about a class of people and should be linked to the item about that class of people even if that item is called 'President of Bolivia". Change the russian label for the wikidata item to 'President of Bolivia' (with 'list of ...' as an alias) and it is a valid option for 'office held'. Generating the list automatically should also be much easier when the item links directly to the target of these statements. Filceolaire (talk) 17:43, 16 September 2014 (UTC)
@Filceolaire: The president of Bolivia (Q373548) is a mix, primary goal of such mix -- to create interwiki links between de-facto different items -- ones are lists (not only Russian one), others are about position. Before using such items as property value we need a common policy. I can't agree to policy "let's count list as class" because it is not correct and will create problems. It's already a problem with Period of appanages (Q13403037) and list of early East Slavic states (Q393871). Policy "let split them apart" would be much better, but requires additional software support to show links from linked items on interwiki panel. -- Vlsergey (talk) 02:01, 17 September 2014 (UTC)
Vlsergey You say you "can't agree to policy "let's count list as class" because it is not correct and will create problems". I say it is correct and will not create problems and I have presented arguments. Can we agree that until the additional software is available we should count lists as classes and see if any problems arise.
Note that the wikipedias don't think links between these are inappropriate - they want sitelinks between these. Can't we just agree that an article which just has a list or which just discusses are both incomplete and each needs the missing bit.
Remember that this policy applies not just to Presidents. It also applies to mayors in every little hamlet around the world. Creating two items for each of these would fill wikidata with unneeded cruft. Filceolaire (talk) 20:34, 18 September 2014 (UTC)
@Filceolaire: i did provide very good argument against such policy just above: Period of appanages (Q13403037) and list of early East Slavic states (Q393871). Do you want another example? I do have: President of Russia (Q218295) and list of presidents of Russia (Q6861127). It is not correct to count list or objects as class -- just because we already have different Wikipedia items about those. -- Vlsergey (talk) 07:34, 19 September 2014 (UTC)

Usually, when you click an "edit" link somewhere on WD, there's also a "cancel" link in edit mode. But there is no Cancel button when assigning badges; you can only use the browser's Back button or whatever. So, could Special:SetSiteLink/Q123456 (i.e. could the screen when assigning badges) have a Cancel button too, please? It Is Me Here t / c 13:48, 17 September 2014 (UTC)

I cannot imagine what is the specific purpose of button "cancel". Can you tell? --Infovarius (talk) 09:22, 18 September 2014 (UTC)
In case you press the wrong thing, and don't want to screw the page up. It Is Me Here t / c 00:48, 19 September 2014 (UTC)

Wikidata for GLAMs Workshop: November 14, Amsterdam

Wikimedia Nederland is organising a Wikidata for GLAMs workshop on the 14th of November 2014 in Amsterdam. The invitations have just been send out. I might need some help with writing tutorials, small assignments, etc. It would also be nice to know if anyone is available for assistance through IRC in case we need more thinking power or get stuck with anything. If anyone is interested in helping with this or would like to receive a message where to find the content, please contact me. Ter-burg (talk) 13:35, 19 September 2014 (UTC)

Property values full list

Hello. Is there any possibility to get a full list of possible values for some property? Thank you very much in advance, (IKhitron (talk) 10:56, 18 September 2014 (UTC))

@IKhitron: The set of all possible values for a property is listed in the field "allowed values", on the "talk page" of each property, like Property talk:P190 or Property talk:P17.
However if you rather want to get the list of all values that are actually being used (as of now), I don't know. A bot or a WD query, possibly. LaddΩ chat ;) 01:50, 19 September 2014 (UTC)
Thank you very much. It did not help in this specific case because I can see there "Any item that represents a class; any item that is not an instance", but at least I know the direction to search. (IKhitron (talk) 12:57, 19 September 2014 (UTC))
@IKhitron: : Any item that represents a class : this is any instance of class, if our tree is somewhat complete (not yet probably), so it's a pretty big number of item. One query that might be an approximation is any item that has a subclass of items with a subclass of claim. Which property are you talking of, instance of (P31). ? TomT0m (talk) 15:14, 19 September 2014 (UTC)
Thank you for your answer. Indeed, this is the one. (IKhitron (talk) 19:36, 19 September 2014 (UTC))

Big articles in English wikipedia and linking to subheaders

Sometimes English wikipedia does not have a corresponding article, and then I would like to interwiki-link to section of an article. This was possible in pre-Wikidata era.

This is not possible anymore? Also an interwiki-link to a section of article disables linking to a (whole) article, because target article can't be referenced multiple times from source wiki.

So (English) wikipedia articles should not be created as one huge article, but as a modular article with sub-articles.

Here is the case that I tried: source of a interwiki-link: https://fi.wikipedia.org/wiki/Ristikulma target of a interwiki-link: https://en.wikipedia.org/wiki/Angle#Intersecting_angle_pairs

--Pasixxxx (talk) 10:06, 19 September 2014 (UTC)

It has to be done the "old fashioned" way by adding the link to the bottom of the page. Unfortunately it's only one way "fi -> en". I've added the link to the bottom of the Finnish page. 130.88.141.34 12:12, 19 September 2014 (UTC)
Many long Wikipedia articles were not created large to begin with, but grew organically to their current size. It would probably be good for readability to split these to match up with other languages, but using Wikidata as a reason is not a good idea. Jane023 (talk) 17:35, 19 September 2014 (UTC)
Temporarily remove the redirect from the WP page, link the page to Wikidata, then put back the redirect again. This has been a long-lasting discussion. 132.208.169.223 21:48, 19 September 2014 (UTC)

Vital Article badge?

Should we have Vital Article as a badge? There's currently top-importance article (Q17580682) at Category:Badge items, but I'm not sure that's the same thing. It Is Me Here t / c 15:52, 19 September 2014 (UTC)

We should have badges for all quality/importance rankings. And maybe vital articles as well. --Jakob (talk) 01:49, 20 September 2014 (UTC)

Songs or singles

en.Wikipedia has an ongoing problem with the conflation, or confusion, of songs and singles. This is exemplified by the interchangeable use of its Infobox song and Infobox single. I am now seeing this affecting Wikidata; for example, One of These Days (Q957641) is tagged as an instance of single (Q134556), whereas the linked en.Wikipedia article, en:One of These Days (instrumental), is about the composition in all it forms, including live performances and as an album tack.

Furthermore, singles (at least from the pre-digital-download era) usually comprise at least two recordings, an "A" and "B" side; and the latter may vary by territory or release format.

How granular do we want to be? Can we learn anything from sites like MusicBrainz? Is there a task force looking at this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:32, 13 September 2014 (UTC)

There are some advantages to use two items, to respect some relation constraints, I give here some example:
  • A discography is a list of discs (singles, EPs, albums), not of songs.
  • A song could be on a single, but also later on an album.
  • A song could get an award, or reused in a movie. The movie reuses the song, not the single disc.
  • The single could get a sales award, it's the disc, not the song which is sold.
  • Pigsonthewing has already noted the B-side issue for maxi single.
So I'd routinely create two items.
Link the en. article to the relevant item according the infobox or introduction of the article, it's mainly their problem, if they speak about two notions in one article.
In the worst case, if an en. article offers a comprehensive content of both, create a third item Wikimedia list / instance of : Wikimedia list / list of : <single>, <song> to link the en. interwiki to. --Dereckson (talk) 13:46, 13 September 2014 (UTC)
Using distinct items is not a good idea because (at least on en.wiki) the vast majority of these articles are about both the song and the single. Since you can't have two Wikidata items with the same en.wiki link, separating the two items will create a lot of confusion. I prefer having a single item with both statements P31:song and P31:single. Pichpich (talk) 19:48, 13 September 2014 (UTC)
Wikidata is the opportunity to fix the technical debt of bad organizations and structure on Wikipedia articles.
Your preference goes against the current trend of Wikidata. For example, it would be against what we're doing on written creative works where we distinguish franchise, fictional universe, books, movies.
The goal of Wikidata is to organize human knowledge, and you can't organize knowledge if one item is about two notions.
If an article are about both, create an item Wikimedia list / list of <the single>, <the song> for this item, because from a data overview, a fruit isn't a tree, a song is not a single. --Dereckson (talk) 20:41, 13 September 2014 (UTC)
By the way, this remembers me (and on IRC someone arrives separately to the same conclusion) the Wikimedia Commons first years, where people considered the project as a mere annex of Wikipédia. Wikimedia Commons is a project per se, to host informative and educative free media. Similarly, Wikidata is a projet per se, to host facts and organize human knowledge, not only an interwiki repository, with nice properties to fill infoboxes. --Dereckson (talk) 20:46, 13 September 2014 (UTC)
But what are you proposing? If you want to go back to en.wiki and convince editors there to split the tens of thousands articles that are about both the song and the single, I'd be stunned if you get any support. So how do you plan to share the site link on two items? Pichpich (talk) 20:53, 13 September 2014 (UTC)
Okki offers a good analogy: if we have an article about an album, this article could contains several paragraphs, one per song, but still be an article about the album.
So an article about a single could also speak about the song on the single.
For him, in such case, the link is to put on the single item ; and when an article is clearly about a song, the link is to put on the song item. --Dereckson (talk) 21:16, 13 September 2014 (UTC)

Each song and each single needs its own item. But we need a way to model, that: ItemsongA_version1 and ItemsongB are treated in en:articlesingleA and ItemsongA_version2 ist treated in en:articleartistA, but ItemsongA_version1 is treated in de:articlealbumX and ItemsongB is treated in de:articlesongB, while ItemsongA_version2 and ItemsongB is treated in fr:articlesingleA. Moreover from every of the articles must be a short and easy way for readers of Wikipedia to find all of these items and articles per one or two clicks. --Diwas (talk) 23:29, 13 September 2014 (UTC)

That would be perfect but as far as I understand this is not currently possible and there's no real plan to make it possible in the future. Can anyone confirm this? Pichpich (talk) 03:27, 14 September 2014 (UTC)
@Pichpich, Dereckson, Pigsonthewing:[ Hi, this seems very similar to the work/edition problem discussed by the Book project. To be consistent, maybe a Work item and two editions items (if needed) could do the trick. Maybe the most important item is the work item, who is declined. A reuse or make the scope broader of the properties used by the project for edition items. This could be use to build Wikidata queries queries in templates WikiProject Books has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. @Micru: you could be interested
TomT0m (talk) 09:24, 15 September 2014 (UTC)
Quick answer: You definitely don't need to worry about Wikipedias and what they do. Just concentrate on Wikidata: For each single that has no Wikipedia article for either of its songs, make one Wikidata item with a label such as "More famous song, flip side: second song". In the case one or the other song is already in some Wikipedia and there is a song item, then make one Wikidata item with a label such as "Existing song, flip side: other song". Whenever the songs are added, edit their items to include "part of" linking to the single item. The single item needs a "depicts"-like property for the individual songs, don't know offhand what that is. Jane023 (talk) 10:26, 15 September 2014 (UTC)
"You definitely don't need to worry about Wikipedias and what they do." Yes, we do. We don't need to slavishly follow it, but people are clearly making links based on what's on Wikipedia, and using Wikipedia categories to auto-populate Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:25, 15 September 2014 (UTC)
Actually I think that is what is preventing more people from participating in Wikidata: a mistaken idea that multiple concepts bundled into one article must somehow be linked in their entirety on Wikidata. If Wikidata untangles these concepts and splits them out, that is a good thing. It is then up to the Wikipedias to keep the concepts bundled or split them out. Presumeably at some point infoboxes will be far enough along that they can bundle the Wikidata items back up for the "concept bundlers", but personally, I am in favor of splitting everything up to the atomic level. Jane023 (talk) 12:03, 15 September 2014 (UTC)
@Dereckson, Pichpich: As TomT0m says this is exactly the same case as with bibliographic information. There is a work, a version of a work (releases), manifestations of a particular version (recordings), and exemplars (one CD, one file, etc). It would be nice if you could start the Wikiproject Music so users know about this structure. In most cases it is enough to have one item to represent it all, but in some other cases you might want to create all of them.--Micru (talk) 16:36, 15 September 2014 (UTC)

I concur with the Jane023's untangle and atomic-level describe rationale. --Dereckson (talk) 18:21, 15 September 2014 (UTC)

It is perhaps easier to decide how to proceed if we look at a specific example: Make You Feel My Love (Q1886329). It's a song written by Bob Dylan but first recorded and released as singles by Billy Joel and Garth Brooks (under a slightly different title). More recently Adele released it as a single. Countless other artists have recorded it. Do we really want one article for the song, four articles on the singles, four articles about these versions of the song and another few dozen for the somewhat lesser known recordings? And which of these items gets the en.wiki link? Pichpich (talk) 18:39, 15 September 2014 (UTC)

That's easy - make Wikidata items for all the ones you want, and don't update Wikipedia at all. I would it would be great to have Wikidata items for all of these that link back to the original song item. Leave the Wikipedia link as is, as that is the most generic choice (the original song on Wikidata should be the linking pin item in a web of recording items linking back to that item). Jane023 (talk) 08:28, 16 September 2014 (UTC)
The Source MetaData WikiProject does not exist. Please correct the name. Just chiming in to say that we created Wikidata:WikiProject_Source_MetaData for discussions like these! Also pointing to this discussion of a "manifestation of" property from User:Micru, Wikidata:Property_proposal/Creative_work#manifestation_of- I actually brought up there the issue with songs there in particular, i.e. Silent Night which has a large number of "performers" listed. I agree with Jane023 that where combining the works seems confusing to you, the best practice would be to make separate wikidata items. But it would be nice to have a property so we can link them together. Mvolz (talk) 14:29, 20 September 2014 (UTC)

Rendering of Module pages ?

Why is it that some module pages get rendered nicely, eg Module:Wikidata link, but some don't, eg Module:Infobox ?

Is there any reason for this? (Does it sometimes get better by itself ?) There doesn't seem to be anything obvious in the wikitext of the page to explain it. Jheald (talk) 21:04, 19 September 2014 (UTC)

There is an reason for this, yes and no it does not get better automatically. In order to understand the cause of the issue you need to know that Module:Wikidata link was created on wikidata while Module:Infobox was imported from the french wikipedia. Importing of modules is very broken and the root cause of that is mentioned in bugzilla:45750. Basically imports of modules tend to either fail compleatly, give broken display of the code like with Module:Infobox or somewhere in between the two.--Snaevar (talk) 13:31, 20 September 2014 (UTC)

Rafael Nadal (Q10132)

I tried to add the ATP-Doublesranking, but when I typed in his doubles ranking, "±1" is added to my entry. Can someone help me??? --Korrektor123 (talk) 16:58, 20 September 2014 (UTC)

It comes automatically, you have to make an another edit and change "±1" to "±0" so it goes off. --Stryn (talk) 17:25, 20 September 2014 (UTC)

Why? Modeling causes on Wikidata

Talk about causes is ubiquitous in everyday life and many other domains of knowledge. Until recently, we've had a few properties to make statements about cause in certain narrow areas, but lacked a way to structure data about causes across a broad range of subjects. For example, you might want to know:

Wikidata now has some new properties that provide structure for basic answers to such questions.

This approach to modeling causation attempts to balance expressiveness with simplicity. It borrows from the idea of causation as a "chain of events", which also has background conditions or events that set the stage for some outcome. These properties are not perfect, but they do allow us to capture much richness in how various sources talk about causes -- and to do so in a way that humans can easily understand.

Help:Modeling causes explains these properties, their background, examples, things to avoid, issues and context. Please comment on the 'Help:Modeling causes' talk page, or here, with any feedback. Note that a simultaneous thread exists on the wikidata-l mailing list at https://lists.wikimedia.org/pipermail/wikidata-l/2014-September/004631.html.

Hopefully we'll be able to build some cool stuff with this. Cheers, Emw (talk) 00:11, 20 September 2014 (UTC)

Don't forget cause of destruction (P770) /ℇsquilo 12:41, 20 September 2014 (UTC)
Indeed, and cause of death (P509), which motivated this broader approach to modeling causes. See Help:Modeling_causes#Related_properties. Emw (talk) 13:10, 21 September 2014 (UTC)

How can I change an article (or page) to a featured article and vice versa? --Joe Watzmo (talk) 07:28, 21 September 2014 (UTC)

de:Wikipedia:Wikidata#Exzellente und lesenswerte Artikel (Sorry only in German language)
Wikidata:Project chat/Archive/2014/09#Removing badge --Diwas (talk) 09:55, 21 September 2014 (UTC)
helped, many thanks --Joe Watzmo (talk) 10:59, 21 September 2014 (UTC)

RfC on deletion vs redirect

FYI, I started a RfC on the issue of deletion vs redirect here. Lymantria (talk) 12:26, 21 September 2014 (UTC)

o que significar isso pode me imformar

Quero imformação sobre a wikidata 177.206.184.254 03:24, 22 September 2014 (UTC)

While linking languages together : An error occurred while saving. Your changes could not be completed.

I tried to link these two pages but neither wants to let me link to the other language page. There is obviously some conflict hiding in the works but I cannot figure out where to look.

The pages are equivalent.

The Finnish (Suomi) language ATS page directly translates to the English ALC page with the odd L.. at the end which correctly redirects to the English AGC page.

.

Idyllic press (talk) 20:34, 22 September 2014 (UTC)

I'm not sure what was the problem, but I've now merged Q782524 and Q11853587. Best regards, --Stryn (talk) 20:43, 22 September 2014 (UTC)
Stryn I think I may have figured it out. These were unique wikidata entries for two language versions so they were not able to add items from one linked list to the other linked list. I fixed another similar just now by deleting the lone entry and then it allowed me to add it to the longer list of linked languages. Thanks for the prompt service. What do I do in future if there are two groups of language links with many in each group, do I have the ability to do the merge that you performed?
Idyllic press (talk) 20:52, 22 September 2014 (UTC)
On Wikidata one item can have only one sitelink from a certain project. In Finnish: Heh, huomasin juuri että taidat osata myös suomea :) Yksi kohde (item) voi sisältää vain yhden sivustolinkin tietystä projektista. Eli fi-wiki-linkki samaan artikkeliin ei voi olla kahdessa kohteessa samaan aikaan. Voit yhdistää kohteita, kun otat käyttöön asetuksistasi pienoisohjelman "merge". --Stryn (talk) 21:02, 22 September 2014 (UTC)

Open Government WikiHack

Hello everyone,

Wikimedia DC is organizing the Open Government WikiHack from September 27–28 at the National Archives in Washington, DC. The Open Government WikiHack is a one-of-a-kind hackathon. Wikimedia DC and the National Archives are teaming up to come up with solutions that help integrate government data into Wikimedia projects, especially Wikidata. If you are in the area and you would like to get involved, you can sign up for free. Please let me know if you have any questions. Harej (talk) 21:37, 22 September 2014 (UTC)

Is it possible to link e.g. [16] to Category:Akkadian literature (Q8229677)? It Is Me Here t / c 12:46, 23 September 2014 (UTC)

I noticed that some items related to Wikisource works contains links to both work and it translation. I think will be good idea to detect such items as candidates for splitting. Labels of such items may need cleaning too (since it may be translated in different ways).

We also need to have showcase items for works with translations (for example, Shakespeare, Byron, Conan Doyle), so user with Wikisource background could learn from them.

EugeneZelenko (talk) 13:57, 23 September 2014 (UTC)

Accepted qualifiers

I just realized that the suggestions for properties that are shown when you try to add a qualifier are not all accepted.

E.g. when you add a qualifier to date of birth (P569), place of birth (P19) is listed in the dropdown. However, Property talk:P569 lists only four possible qualifiers, none of which are in the dropdown. Wouldn't it make sense to populate the dropdown with only the accepted qualifiers? I assume that all other properties are available as qualifiers to allow new uses to emerge organically, which can be codified later? But currently the qualifiers we want/accept are effectively hidden to the editor. --Azertus (talk) 14:39, 23 September 2014 (UTC)

"accepted qualifiers" constrain shall be considered as an experimental, not as mandatory. At least at current time. But i think it is useful. In fact, i don't understand why p19 appears as possible qualifier for p569 since it's only a couple of items with this property used p19 as qualifier for p569. -- Vlsergey (talk) 17:42, 23 September 2014 (UTC)

year school was built??

what year was the new Hudson middle school built in Hudson north Carolina 28638??

This is Wikidata's project chat. A question like this should be posted at the Wikipedia reference desk. :) Regards, --AmaryllisGardener talk 23:03, 23 September 2014 (UTC)

Wikidata training, London Saturday 11th October

Wikimedia UK is hosting a Wikidate training session in London on Saturday 11th October. For more information and registration, please click here. Fabian Tompsett (WMUK) (talk) 11:19, 24 September 2014 (UTC)

What should we do with wrong data from Wikipedia ?

I have been trying to fix some coordinates using fr:Catégorie:Page avec coordonnées différentes sur Wikidata (currently triggered when wikipedia coordinates are more than 10 kms away from Wikidata's). When the issue comes from fr.wikipedia's coordinates, that is pretty simple: I just delete local frwiki data and the template calls Wikidata instead. But when the issue comes from Wikidata's coordinates, that is more complex. I can fix Wikidata's coordinates. But they have usually been copied from local Wikipedia's values that should be fixed too. I can fix them in the language indicated by the "imported from", but that takes more time. And as errors have often been copied across projects, that does not entirely solve the issue. I can also mark the erroneous data as "deprecated" and let bot see about fixing Wikipedia, but I am not sure this is the most efficient solution. Any other idea ? --Zolo (talk) 13:27, 17 September 2014 (UTC)

The deprecation solution seems not so bad : it leaves a trace that the value was checked by someone. TomT0m (talk) 14:37, 17 September 2014 (UTC)
Marking wrong coors as deprecated does not make a sense for me. In situations like that i simply delete wrond coors from WD (and hoping that some bot will not import wrong coors from another wiki), hoping that most of the wikis will call coors from WD soon. --Jklamo (talk) 10:10, 18 September 2014 (UTC)
+1. Deprecated should be used only with a value having a reference. If you have another value with a reference, the imported value from WP correct or not has to be deleted. Snipre (talk) 10:17, 18 September 2014 (UTC)
Just deleting incorrect (or inappropriate) coordinates are not enough. They are soon imported again. I have started to set "no value" in those cases instead. When it comes to imported data, French Wikipedia is the most frequent source of incorrect coordinate location (P625) and incorrect located in the administrative territorial entity (P131) when it comes to items with coordinates within Swedish territory. /ℇsquilo 12:06, 18 September 2014 (UTC)
@Jklamo: that seems to place a bit too much faith on hope ;). But anyway even if Wikidata want to switch to an all-Wikidata based system, this does not appear like a good solution. If we just delete wrong data in Wikidata without deleting we will have different data in Wikipedia and in Wikidata. If Wikipedia's data are different from Wikidata's, we should not remove them from Wikipedia until we have checked that Wikidata's are either the same or more accurate. If the bad data have been removed from Wikidata, there is no way to do it automatically, so we have to do that by hand all over again. That is one big time waste. If we keep the wrong data in Wikidata, but mark them as deprecated, we know that these are wrong data, and a bot can remove them from Wikipedia. There may be better solutions (that is why I was asking), but unless we have made sure wrong data have been removed from all Wikipedias, depcrecating is certainly better than just removing bad data in Wikidata.
@Snipre: if we have a value with an external reference but that is clearly wrong, it does not seem very reasonable to delete data imported from Wikipedia that appear to be right just because of that (not mentionning that most coordinates data will possibly never have a proper reference, and may not need one).
@Esquilo: Sorry but I do not understand how things would work with "no value", could you give an example ? --Zolo (talk) 12:19, 18 September 2014 (UTC)Zolo (talk) 10:32, 19 September 2014 (UTC)
The core of problem here is the way how data is transferred from Wikipedia to Wikidata. There always should be someone who is responsible for data. If all data is just copied from Wikipedia, noone is responsible -- because Wikipedia authors do not care about data on Wikidata. The only way to make the data actual and remove errors is to remove data from Wikipedia as soon as data is transferred to Wikidata. That's exactly as done in Russian wikipedia: all data from a number of infoboxes is moved from Wikipedia to Wikidata. Along with it we have a number of reports about differences -- and as soon as they resolved, data would be moved to Wikidata completely. Because of that Russian Wikipedia will look after those data (birthdays, deathdays, birth place, death place, nationality, gender, official website) because it is the data actually shown in infoboxes. If it's okay to repeat myself, as I already said on Wikimania-2014 meeting, there should not be any second data copy from Wikipedia to Wikidata. As soon as data is copied from some Wikipedia to Wikidata it shall be prohibited to copy them second time (the same data), i.e. Wikidata should me master copy of data, not any Wikipedia. Not even German. -- Vlsergey (talk) 07:31, 19 September 2014 (UTC)
You demonstrated the consequences of your way: Gadget to create local copy of Wikidata (to disable Wikidata update). Nobody at dewiki is willing to use unreferenced data. So the main question is: how do we improve referencing to relaiable sources. --Succu (talk) 09:09, 19 September 2014 (UTC)
@Succu: 1. It is very obvious consequence and i do not see anything wrong with it until we have sufficient technical support to do the same at MediaWiki level. We need to use common data and at the same time we need control over how it's embedded in protected and semi-protected wikipedia pages. 2. dewiki problem is more "deeper" -- they just don't want to. Doesn't matter if data would be referenced or not. It is just outside of dewiki, so dewiki will not use it. They want to have control over their data and references has nothing to do with it. 3. Original question was not how to handle unreferenced data, but how to remove errors from data. In wikipedia 99.99% of information has no references. Obviously Wikidata would have 90% at min unreferenced but sensitive data. Question should be not how to change it (it's impossible) but how to live with it. 4. The main idea of my answer was "data won't be good until someone would start to use them". Even with restrictions and limitations. -- Vlsergey (talk) 09:40, 19 September 2014 (UTC)
Vlsergey, I think I know a little bit more about the concerns of dewiki (2), but your statement proved them all: Yeah they have data (4), lets use us these unreliable (=unsourced) data (3), because they are data. If we don't like them, let's make us a local copy of wikidata, after we dropped our precious data into wikidata (1). Do you really think this bot-way leads to a better acceptability of wikidata? As you know dropping several database ids from ruwiki into wikidata causes a lot of work, fixing false data. --Succu (talk) 19:59, 19 September 2014 (UTC) BTW: Even coordinates could be sourced: Q4518823 (see de:Liste der Galapagosinseln#Literatur, my only contribution to dewiki using coordinates).
re Vlsergey. I agree, but it cannot be done for all languages at the same time. Wikpedias often copy each other (especially for basic, language-independent things like coordinates). It means that if data were imported from xwiki to Wikidata, and removed from xwiki, and if someone finds that the data are wrong and corrects Wikidata, it may still be useful to keep them with rank "deprecated" in case other Wikis have the same wrong data.--Zolo (talk) 10:32, 19 September 2014 (UTC)
@Zolo: i don't think it is a good way. Let's consider an example:
  1. bot checks article in xxwiki and finds that birthday field is 1 April 1234 year;
  2. bot checks Wikidata and found there are two values: one is "1 April 1234" and marked as deprecated, second is "2 May 2345" and marked as normal
  3. bot does not edit xxwiki article (not removing "1 April 1234") neither edit Wikidata (add "1 April 1234" to values list), but adds the article to local "discrepansies" xxwiki report, because if he touch anything he would change article content (and by default he must not)
another variant:
  1. bot checks article in xxwiki and finds that birthday field is 1 april 1234 year;
  2. bot checks Wikidata and found there are single value: "2 May 2345" and marked as normal
  3. bot does not edit xxwiki article (not removing "1 April 1234") neither edit Wikidata (add "1 April 1234" to values list), but adds the article to local "discrepansies" xxwiki report, because if he touch anything he would change article content (and by default he must not)
since there is no difference, i don't see the reason to keep incorrect data in Wikidata unless some source (real source, not Wikipedia) displays them. -- Vlsergey (talk) 10:51, 19 September 2014 (UTC)
@Vlsergey:. I was assuming that if local data are equal to those marked as deprecated in Wikidata it was ok to automatically replace them with those marked as normal. Maybe Wikipedias will not be willing to do that, but still I think it would be a sensible way to go, especially for data like coordinates or birth dates, that should usually have just one value. If someone marks a birth date as deprecated and keeps the other one as normal, it is hopefully because the latter is more correct. It may happen that someone or a bot will add a wrong birth date after that. But that should not happen too often because we do not encourage bot to import birth dates from Wikipedia to Wikidata when there is already one. And if it does, we would end up with two birth dates, with at least one without "real" references, and that would be a suspicious case that needs to be checked. In a worst case scenario, the local wrong value will be replaced with an even wronger Wikidata value. But that will most likely be a small minority of cases, so that this way of doing things would still be reasonable. --Zolo (talk) 12:23, 19 September 2014 (UTC)
@Zolo: Wikipedias will never agree to replace their values with Wikidata ones -- not until we prove that Wikidata is more correct than Wikipedia (in 10-15 years, i believe). Because of that so far I don't see how having such values would help. If there is a error in bot code, bot can do anything, including deleting all the claims. Bot shall be fixed. If there is no error, it doesn't matter if we have deprecated value (alongside with correct one) or not. For existing Wikidata values xxwiki [bot] should check their data and not add their value to Wikidata, unless they provide sources and change the ranks accordingly. "If someone marks a birth date as deprecated and keeps the other one as normal, it is hopefully because the latter is more correct" -- the same here: "If someone removes a birth date and replace it with the other one, it is hopefully because the latter is more correct" -- Vlsergey (talk) 12:45, 19 September 2014 (UTC)
@Vlsergey:. It surely depends on the sort of data, but take coordinates that are rather non controversial. Errors usually have pretty trivial reasons like messing up with the decimal conversion. Once they are noticed they are pretty obvious. If someone has marked a value as deprecated there is not much doubt that the value is indeed wrong. The few coordinates that I marked as deprecated were mostly from Dutch and Russian Wikipedias, but it may be that 10 other Wikipedias have the same. If they see that their data matches a deprecated Wikidata value, can they automatically delete them and use the normal or preferred Wikidata values instead ? I think they can. --Zolo (talk) 15:21, 19 September 2014 (UTC)
@Zolo: "can they automatically delete them" -- let's start from other point. Do you already have some Wikipedia in mind that will do that? Does it have timeplan and bot flag/task request discussion? Because i just don't believe that any Wikipedia would do it. And if noone will -- such data is not required. In case someone would -- I would like to have some kind of "delete after" timestamp to cleanup those incorrect data. -- Vlsergey (talk) 17:21, 19 September 2014 (UTC)*
@Vlsergey: I would be willing to ask at fr.wikipedia, but the way I did it means that I did not detected bad values that were imported from fr.wikipedia. Yes, a "delete after" solution would be nice, but that may not be very easy to implement. At worst we can delete all those deprecated values imported from Wikipedia if, after some time, nobody appears to make any use of them. --Zolo (talk) 20:04, 24 September 2014 (UTC)
Many properties has {{Constraint:Single value}}. Bots must not add more than one value per item for these properties. And bots must not replace existing property values because bot can not decide that data is correct in general case. So it is enough to fix invalid data in Wikidata. And we need fix or block bots who are trying to add more than one value or replace existing. Saving a number of values with deprecated rank is very unpleasant way. Collecting errors — is not Wikidata goal. — Ivan A. Krestinin (talk) 07:29, 21 September 2014 (UTC)
@Ivan A. Krestinin:. Sorry, but that does not make much sense. The point of this thread is precisely that it is not always "enough to fix the invalid data in Wikidata". Bots can know that deprecated-rank data are incorrect. Actually, independently from this particular poin, it would seem to make a lot of sense that {{Constraint:Single value}} only take into account data with the bast rank, just like the Wikimedia inclusion syntax does by default. --Zolo (talk) 20:04, 24 September 2014 (UTC)

For manual checking of Wikidata, it may be useful to have the best available source associated with the normal value, and a different source associated with the depricated value that explains why the depricated value is wrong. The source associated with the depricated value might be good, but not as good as the source verifying the normal value. Jc3s5h (talk) 15:34, 25 September 2014 (UTC)

Label lister not working

The new (BETA) version of the labellister doesn't seem to work. Is it just me? --- Jura 14:08, 17 September 2014 (UTC)

Same for me, will not let me save my changes after Preview; had to switch back to released version. It somehow got broken in the last few days. Author is @Jitrixis: - LaddΩ chat ;) 02:03, 18 September 2014 (UTC)
I miss it already. --- Jura 22:58, 18 September 2014 (UTC)
@Jura1: Fixed. Sjoerd de Bruin (talk) 18:49, 25 September 2014 (UTC)

Good article label not automatically added to an article

Hello,

Recently, WikiData manages the "good article" labels by automatically put the image by the language links.

However, in this article, the portuguese "good article" label doesn't seem to be recognized. In the English version of the article, it is added manually ({{Link GA|pt}}), as it was in other languages. In the French version, I quit them (for wp:es and wp:pt), and only the Spanish one remains.

If you have a look on the WikiData page, you can see that there is indeed a label for the Spanish version, but none for the Portuguese one : is there any reason for that?

Thank you and best regards, --Daehan (talk) 08:48, 25 September 2014 (UTC)

PS: and sorry if I'm not clear: I don't use to work a lot on WikiData.

There's Portuguese label at Q1779837. Do you mean why the English article told "this is a good article in this language" when you put your mouse on the pt-wíki link? It was because there was still {{Link GA|pt}} in article text. I've now removed it from text and added the badge on Wikidata. Regards, --Stryn (talk) 16:06, 25 September 2014 (UTC)

Label vandalism in a mainstream item

See Special:Diff/157874111/158717184 : 4 days of IP vandalism on the item on Mathematics. This seems pretty bad to me because it's not a burried item on an unknown topic ... Maybe a little tweaking of the vandalism filter would help a little though :) TomT0m (talk) 10:38, 20 September 2014 (UTC)

@TomT0m: These are things FlaggedRevs could help us with... :-)
What exactly is "a mainstream item"? How does AF recognize such an item?
By the way, the vandalized stuff was a description, not a label. Matěj Suchánek (talk) 17:10, 20 September 2014 (UTC)
I meant an item about a very important subject ( I guess the articles about maths are very consulted on Wikipedia, everybody child in school learns some maths ... compared to, let's say the mayor of a small town of a small country's item, I would think vandalism is caught fast ... This may be a bad sign for overall vandalism rate in Wikidata, hence for the quality of our datas (although less visible items are less exposed) (and it is not that much used yet. It could b a lot more I guess, alyhough a bit too general). TomT0m (talk) 18:19, 20 September 2014 (UTC)
It could be caught fast… if the wikipedia pages used the wikidata item, for label or description... but I don't think it's the case, for now ;) --Hsarrazin (talk) 19:10, 25 September 2014 (UTC)

Wikidata Game Slow

The game is slow for me as I can it won't load in Chrome. I tried it yesterday and I couldn't login to it. Magnus anything? Eurodyne (talk | contribs) 21:58, 20 September 2014 (UTC)

Just restarted. Again. Currently on vacation, reduced connectivity. --Magnus Manske (talk) 20:03, 21 September 2014 (UTC)
Thanks a bunch! Eurodyne (talk | contribs) 20:07, 21 September 2014 (UTC)
Magnus Manske Is it down again? Eurodyne (talk | contribs) 02:01, 23 September 2014 (UTC)
Yes, it's been down for a few days now.... and so is Catscan - I think I saw Magnus is on vacation… which he much deserves… so, we'll try to be patient :D --Hsarrazin (talk) 19:15, 25 September 2014 (UTC)

Wikidata Auto Editors

Other than the Wikidata game which is currently down, what are some other auto edit tools I could use? Eurodyne (talk) 01:59, 25 September 2014 (UTC)

@Eurodyne: I know these three which also use WiDaR: Quick statements, AutoList (project page), AutoList2 (for the last two, study WDQ first). Matěj Suchánek (talk) 14:01, 25 September 2014 (UTC)
Thanks! The game is up and running again but I may use these in the future. Eurodyne (talk) 22:23, 25 September 2014 (UTC)

Settlement's Claims

For:

1-en:Iran
2-en:Yazd Province
3-en:Ardakan County
4-en:Central District (Ardakan County)
5-en:Mohammadiyeh Rural District

Should I add all of these 5 level subdivisions to located in the administrative territorial entity (P131) or part of (P361)? and does it need to have separated property for each one? like country (P17), province ,....Yamaha5 (talk) 21:14, 25 September 2014 (UTC)

@Yamaha5: only add en:Mohammadiyeh Rural District. See Property talk:P131.--GZWDer (talk) 04:53, 26 September 2014 (UTC)

Fresh category members tool idea

Hi. I'd like to (and I'm almost in the process on) write a tool which would show latest category members -- with subcats, recursively -- for new page patrol purposes. It would be a web app where you type a wiki name and category name and get a list of category members sorted by time. Later on I'd have to implement pages (if there's too many) or limit the time frame. Is this worth doing given that categories would move to Wikidata soon? If so, how soon? Thoughts? (P.S. Please distribute to sister projects village pumps). Gryllida 07:32, 21 September 2014 (UTC)

Could you develop the idea?
Maybe you could join a wireframe showing the UI? --Dereckson (talk) 13:21, 21 September 2014 (UTC)
What is a "wirefeame"? Yes, I can try to develop it. You might know how work with databases performance is pretty hard, but I hope to try to complete. Gryllida 01:08, 22 September 2014 (UTC)
A rough graphic representation of the user interface. Not the design, just the areas and elements to print (widgets).
We have some samples on Wikimedia Commons : commons:Category:Website wireframes. --Dereckson (talk) 16:58, 26 September 2014 (UTC)
  • I like the idea. I am even thinking about more advanced gadget - "Category history", which should show also deleted members. But obviously it is quite hard query by now. As for future of categories - their elimination is a question of quite long time (I'd say - years). --Infovarius (talk) 19:38, 21 September 2014 (UTC)
Eliminate categories? This sounds like a good recipe to wipe out all sisters that don't happen to have Wikipedia-like category hierarchies. Wikivoyage would probably be unaffected. Wikinews does things differently, and would be deprived of control of that part of its own infrastructure. Wikibooks uses categories in a very different way, using both manually arranged structures and lots of stuff automatically generated based on the arrangement of pages in five (or it is six) different namespaces. --Pi zero (talk) 21:49, 21 September 2014 (UTC)
At the Commons village pump I was told that Wikibase/Wikidata wouldn't replace categories but would complement them. (And even if replace, I think Wikibase/Wikidata would be capable of implementing all the pretty things that are done at various projects by hand.) I'm still querying for documentation (was expecting the folks here to enlighten me with the details, too). Gryllida 01:08, 22 September 2014 (UTC)
I'm not planning to make it a gadget, because JavaScript doesn't have a means of querying the DB directly. I already know - I already tried - that API is slow and it is inappropriate for this tool, were it to go recursively (and I currently think it needs to do that). Thought I'd try to have it be a tool on WM Labs (as they have a near-live replica of the wikimedia projects database there). Gryllida 01:08, 22 September 2014 (UTC)

Request and proposal

German Dormitorium is here: Q1245527 and about the sleeping hall for monks.

I made at the engl. page Dormitory a notice where the Dormitorium comes from and a redirect from Dormitorium to Dormitory. And at the German version, that in English it has become a "Studentenwohnheim".

Studentenwohnheim ist hier: Q15635165

An error occurs: The link enwiki:Dormitory is already used by item Q847950. You may remove it from Q847950 if it does not belong there or merge the items if they are about the exact same topic.

Maybe somebody is smarter than me to merge them? Thanks and greeting --Palitzsch250 (talk) 14:18, 26 September 2014 (UTC)

You describe several notions, so merge isn't a solution. On Wikidata, a notion = an item.
We could do that in 4 items:
--Dereckson (talk) 14:49, 26 September 2014 (UTC)
There's also sleeping dormitory (Q3037266), large room with beds, only for sleeping, linked to fr:Dortoir. LaddΩ chat ;) 01:34, 27 September 2014 (UTC)

Royal Society of Chemistry - Wikimedian in Residence

Hi folks,

I've just started work as w:Wikimedian in Residence at the w:Royal Society of Chemistry. Over the coming year, I'll be working with RSC staff and members, to help them to improve the coverage of chemistry-related topics in Wikipedia and sister projects.

You can keep track of progress at en:Wikipedia:GLAM/Royal Society of Chemistry, or use my talk page here if you have any questions or suggestions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 25 September 2014 (UTC)

Congratulations Andy, that's great news! Emw (talk) 12:54, 27 September 2014 (UTC)

Wikidata proprietary number format

Discussed with parser ideas at ru-wiki Неизвестный тип снэка. If I understand properly Wikidata for some reason decided to not use numbers but its own proprietary string format:

  • Main value in the US notation with comma-separated groups like 1,500,000
  • Zero or more space(s)
  • ±
  • Zero or more spaces
  • precision part expressed either as a number or as a nn% percent value

First queston is — what in the name hey of it is that and who's that groundbreaker-genius?
The second question: is the new format described properly or are some more caveats missing?
As the change rendered a number of Wikipedia articles to the FOOBAR state with "unknown-snak-type" an extra parser is needed (or cancel using Wikidata whatsoever until some stabilization stage). Then are there some obligations at WD to keep this at least as it is right now? So it will not become say +/- instead of ± overnight. Some explanations would be highly appreciated. --NeoLexx (talk) 10:45, 27 September 2014 (UTC)
P.S. Needless to say that WDQ's QUANTITY filter is effectively killed as well by this "innovation", but OK for now, let's solve the basic functionaly issues first and ASAP. --NeoLexx (talk) 10:50, 27 September 2014 (UTC)

@Neolexx: Could some of your concerns answered in Wikidata:Development plan and Wikidata:Requests for comment/Dimensions and units for the quantity datatype. Tobias1984 (talk) 12:14, 27 September 2014 (UTC)
Hardly, as nowhere I see discussed numbers expressed in the US pretty-printing with commas (1,500 for one thousand five hundreds and so). Neither numbers expressed in the US pretty-printing with commas followed by ± sign followed by delta. At my best knowledge such number formats never existed at all in the programming since Mr. Turing time and until September of 2014 A.D. I am ready to stay corrected on that otherwise would anyone here (where invented) please tell me a sub to get numbers from WD rather than snaks errors? Whatever happens at WD is a private WD business, but foobared Wikipedia pages is a global project issue. I never did anything with mwLua (Javascript is just fine) yet I wrote a temporary parser-fixer. As an emergency help could anyone mwLua-savvy check it for functionality? --NeoLexx (talk) 12:57, 27 September 2014 (UTC)

Wikibase stores numbers. Works fine on frwiki: [17]. I think there’s an error on ruwiki. You don’t have to parse strings with Lua. --JulesWinnfield-hu (talk) 13:52, 27 September 2014 (UTC)

You don’t have to parse strings with Lua. See frwiki for example. Also works on huwiki. You do something wrong. --JulesWinnfield-hu (talk) 14:34, 27 September 2014 (UTC)
This was the problem: [18]. --JulesWinnfield-hu (talk) 14:41, 27 September 2014 (UTC)

Sortkey

Do we have a property for "Sortkey" ? (ie the string that ought to be used for sorting an item in a particular language). I can't seem to find it.

I see that we do have family name (P734) and given name (P735), but that is not helpful for an item like eg Sting (Q483203).

Sortkey is useful for eg: sorting WDQ results in order. It is also needed by some templates for ordering the categorisation of the page they are applied to.

Many many individuals on en-wiki have a Sortkey defined in their PERSONDATA. On Commons, it is also a standard part of the Creator template.

Did I miss it? Is it here all the time? Or is this a property that ought to be created? Jheald (talk) 18:32, 20 September 2014 (UTC)

I don't think you missed it. It actually seems a little weird in the Wikidata paradigm : sorting is something the user of the data might want to do but is not really a property of the datas themselves. It is moreother language (or worse) dependant. If you watch closely to family name (P734) and given name (P735), you will notice that their datatype is not string, which complicate further. Correct me if I'm wrong, but sortkey in your mouth means when we have to sort person by alphabeletical order of their name, we sort them by "sortkey" if available otherwise by family name then by proper name ? TomT0m (talk) 19:28, 20 September 2014 (UTC)
Well unless it is in the database, it is otherwise not possible to search by it. The <Family Name>, <Given Name> <Middle Names>, <title> format is pretty standard for many applications -- en:Wikipedia:Persondata notes that it is used both by the Library of Congress in the U.S. and by Deutsche NationalBibliothek -- so it is something that, if possible, we should aim to hold and be able to make available to those that want it. Another key example where this property is needed is to be able to properly format (or re-format) citations per certain style guides.
This is information that is not necessarily easy to extract from names. Of course, one can often make a good first guess; but it really needs the data to be stored to identify that it should be "Beethoven, Ludwig van" but "Van Zandt, Townes".
So, questions, before submitting a property proposal
  • Should this be a string or multilingual text ?
    Do different langages differ much, eg LoC <-> DNB ? Or are there clear language preferences ? If the latter, would language fallbacks work sanely ? Or, are there appropriate qualifiers that could be used to do the job.
In Irish names are sorted by the surname but without the Ó or Mac prefix. 86.6.111.107 02:27, 22 September 2014 (UTC)
  • Should diacritics be included ?
  • Should this apply only to personal names, or should eg Book-titles also have their standardised searchable forms recorded ?
  • Is there a better name for the property ?
... more ? Jheald (talk) 22:28, 20 September 2014 (UTC)
This seems to be a language characteristic or maybe a flag to be included in a query rather than a characteristic of the concept/item so I would be opposed to trying to describe this in the statements about the item. 86.6.111.107 02:27, 22 September 2014 (UTC)
And how do you propose to query it, if it's not in the database? Jheald (talk) 16:16, 23 September 2014 (UTC)
You pick a query and specify which associated property statements should be downloaded (into a table) and then specify which value (column) should be used as the sort key.
This won't help if you want to sort as "Beethoven, Ludwig van" but "Van Zandt, Townes" but the only reason you would want to do that would be if 'Van Zant' is considered one surname and 'van Beethoven' is considered a prefix and a surname in which case specify 'surname:Van Zant' and 'surname:Beethoven' and use 'surname' as the sortkey.. Filceolaire (talk) 18:43, 23 September 2014 (UTC)
@Filceolaire: Some reasons to prefer creating an item 'Sortkey':
  1. It accomodates names like Sting (Q483203), which is neither a surname nor a forename, and other such unusual cases.
  2. family name (P734) is a controlled vocabulary property -- it can only be used if an item exists for the surname. On the other hand, Sortkey as a string or multilingual text property can be universal
  3. The data to populate the property is readily available from en.wiki, de.wiki, LoC and DNB
  4. The property is required as part of Wikidata-ization of the Commons {{Creator}} template, which it would be good to ultimately be able to retire. Jheald (talk) 07:07, 25 September 2014 (UTC)
I can see this working as a multilingual text datatype so you can specify a different sortkey for each language (e.g. for Irish as the comment above) and every sortkey has a language (or languages) associated with it. Filceolaire (talk) 22:14, 27 September 2014 (UTC)

Crowdfunding information

Crowdfunding is an interesting 2010s fact. A lot of project use Internet crowdfunding platforms to get an initial capital and promote the product.

Do you think this is a pertinent fact to document on Wikidata? How to best express it?

Ash Crow suggests to use the significant event (P793). What are the best qualifiers?

I made three samples so we have a base for discussion:

Thank you to Okki for Star Citizen and Veronica Mars suggestion.

--Dereckson (talk) 14:43, 26 September 2014 (UTC)

User:ValterVB, how do you set numbers ± 0? --Dereckson (talk) 18:02, 27 September 2014 (UTC)
@Dereckson: Simply I have changed from "± 1" to "± 0". For a new number you must write "10 ± 0" --ValterVB (talk) 18:45, 27 September 2014 (UTC)
Thanks. --Dereckson (talk) 20:50, 27 September 2014 (UTC)

Wikidata IEG proposal: Tools for using wikidata items as citations

Hi all,

I've started this IEG draft on meta for a wikidata related IEG: Tools for using wikidata items as citations

I'm still looking for collaborators and it would be awesome if someone wanted to join up in a developer or community organiser role. Also, if you have a few minutes to read, comment, criticize, etc. that would be awesome! Mvolz (talk) 19:18, 26 September 2014 (UTC)

  • @Mvolz: just for your information w:ru:Module:Sources already can pull information from Wikidata and display it as citation. It is used to display citations for claims from Wikidata in infoboxes. The biggest issue is bugzilla:67538 -- you won't be able to display "deattached" descriptions (i.e. descriptions from separate entities_ unless you have "cached copy" of your entity (as LUA module for example). Another issue is social: "This hack could unify the citation structure" is more "contra" than "pro" according to some community members. -- Vlsergey (talk) 05:15, 27 September 2014 (UTC)
    • @Vlsergey: Thank you, I didn't know about that module! That's awesome! And also thank you for the bug link, I'd heard there were some difficulties with the current api but wasn't sure what they were exactly. Re: social, I am confused? Are you saying that some community members have seen that support comment and view it as a negative? If so they should comment! :). Mvolz (talk) 13:45, 27 September 2014 (UTC)
      • @Mvolz: no, community members didn't see this proposal/comment yet. But it is well known that some active community members are strictly oppose unification of articles, adding infoboxes, unification of sources and other "not-related-to-content-creation" business. Other active members would like to see their unique source descriptions (sometimes even with images, see Template:Ruheroes (Q12269760) for example), so they would be against unification as well. I'm not apologist of such points of view, but you shall be careful. -- Vlsergey (talk) 11:59, 28 September 2014 (UTC)

Can I get a list of entities with a specific property using just one call to /w/api.php?

I'm trying to find all the pages with a specific property and the property value for each entity. The best way I can figure out how to do this with the API is to use "/w/api.php?action=query&bltitle=Property:PPROPERTY&list=backlinks&blnamespace=0". I then either take batches of the resulting pages and running "/w/api.php?action=wbgetentities&ids=QENTITY|QENTITY|..&props=claims" or "/w/api.php?action=wbgetclaims&entity=QENTITY&property=PPROPERTY" one at a time.

Is there any way to get all the entities with a specific property and the property values in a single call (or multiple calls of the same type based on a query limit)? --Bskaggs (talk) 20:41, 26 September 2014 (UTC)

@Bskaggs: Use WDQ (API documentation), if you wish through the front-end Autolist or Autolist 2.
With WDQ it is easy to filter by a specified property (which may or may not be required to have a specified value, as you wish), and then to output the values of a given list of properties for that hit-set.
It should be just what you need. Jheald (talk) 22:14, 26 September 2014 (UTC)
@Jheald: Thanks for the pointers! The WDQ page mentions the data can be a few hours old; do you happen to know how much the lag is normally? --Bskaggs (talk) 17:59, 28 September 2014 (UTC)
@Bskaggs: Sorry, I don't know. The things I've used it for haven't been very time-critical. @Magnus Manske: would be the one who could say. Jheald (talk) 18:31, 28 September 2014 (UTC)

Wiki Loves Monuments 2014 list items and merging

Whilst using the interactive map for Wiki Loves Monuments UK I noticed that the Wikidata item for Hampton Court Palace generated from English Heritage's list (Q17528007) could do with merging into the older Q205666, which I did. What I didn't realise was that another item from that list, "Walls And Railings To Hampton Court Palace", had already been merged into that item. This seems like a mistake; "Hampton Court Palace" would be a better fit for that item. My question is, should "Walls and Railings" be de-merged, or is it acceptable for both the Palace and its walls to have to have the same Wikidata item? Artifex (talk) 07:17, 28 September 2014 (UTC)

We have somelike discussion in Wikidata talk:WikiProject Cultural heritage The best would be to de-merge the "Walls and Railings" item and link it as as part of the Palace, or even beter, as a part of the estate (since [19] seem to be the estate entry). --Fralambert (talk) 12:12, 28 September 2014 (UTC)

is there a list of good wikidata items?

Are there pages that I can use as "role models"? items of all types that are more or less good examples of full usage of properties, qualifiers, references etc.? Thanks, DGtal (talk) 08:53, 28 September 2014 (UTC)

Have a look at Wikidata:Showcase items --Pasleim (talk) 09:02, 28 September 2014 (UTC)
Showcase answer! DGtal (talk) 09:43, 28 September 2014 (UTC)

Julian and Gregorian calendar UI - revisited

Revisiting the old chat threads like Calendar model: only display attribute or storage model?, stored to display time value conversion and Can't switch between julian and gregorian date.

The UI for dates is completely broken, even not counting that automatic calendar conversion is not working. There is no way to deduce that "Julian" and "Gregorian" attributes are related to display attributes - the natural assumption by any user is that you change the storage model of the attribute, ie. you either enter a Julian date or Gregorian date, or maybe both Julian date and Gregorian date. Nowhere it is hinted that the underlying storage model always assumes Proleptic Gregorian. The underlying storage model and the programming model seem to be badly documented too, as bot programmers have to seek forum advice to gain the understanding of dates and calendars.

This is further mitigated by the fact that the Russian Wikipedia initiated a massive WikiData upload of birth/death dates and the removal of said dates from the infoboxe templates, which now take WikiData dates into account when no explicit dates are provided to the template. The resulting error rate is close to 30-50% if you consider all Tsarist Russia articles.

Yesterday I had to correct at least dozen Russian Empire-related wikidata entries added by both bots and humans, and of course the two most common errors resulting from the unintuitive UI and badly written documentation are:

  1. Specifying Julian calendar dates instead of Gregorian dates, since the editors naturally think "Julian" means the storage model, not the display mode. So they think they enter a Julian date, when in fact they have entered a Gregorian date. This results in all dates being shifted 13-14 days forward in the infoboxes comparing to the text of the article.
  2. Providing two dates for the same attribute, as editors deduce they need to enter both "old style" and "new style", and again confuse "Julian" and "Gregorian" as storage attributes, not display attributes. This results in both dates being displayed in the infobox, as if the date is ambiguous - for example "Born: xx XXX[1] or yy YYY[2] 18nn"

Example edits by a confused user: [20] [21] This was the entry for Mikhail Lermontov, and the edit resulted in incorrect infobox dates being displayed for almost a month. I can only imagine the situation with other not-so famous entries which lack enough editor attention. It probably has become a complete mess that will have to be cleaned manually. --95.26.10.205 19:57, 28 September 2014 (UTC)

Support for mul language code

Tracked in Bugzilla
Bug 71406

See here This is relevant for (e.g.) Q16503#sitelinks-wikisource. —Justin (koavf)❤T☮C☺M☯ 08:20, 29 September 2014 (UTC)

Properties to supply on-the-fly requests

Question for Lydia Pintscher or others better aware of upcoming development: how far are we from a capability to provide properties whose values would be obtained via on-the-fly requests to WD itself? Is it in the plans at all? I'm seeking something similar to arbitrary access, but that would be made available as normal properties on items, replacing or supplementing existing properties. LaddΩ chat ;) 02:39, 30 September 2014 (UTC)

I don't understand what it is you want exactly, sorry. Can you give an example please? --Lydia Pintscher (WMDE) (talk) 06:56, 30 September 2014 (UTC)
It start from a question I asked. Right now, a lot of informations are duplicated like the symetric properties : father/mother/son/daughter/brother/sister. So, would it be possible to ask to show on the son item the inverse property already indicated in the father item ? Cdlt, VIGNERON (talk) 07:33, 30 September 2014 (UTC)
I will have a team of students working on improving constraint violation reports starting in 2 weeks. Inverse properties is something they will be looking at. One thing I do know is that these properties will not be added automatically by the software. But we will have to make it easier. If you have ideas that you want me and the students to take into account please let me know. Once they started I plan to have a more formal page for idea collection. --Lydia Pintscher (WMDE) (talk) 09:04, 30 September 2014 (UTC)
@Lydia Pintscher (WMDE): Just a question: Will this feature be related to statements on properties? Matěj Suchánek (talk) 16:12, 30 September 2014 (UTC)
Yes it'll be build on top of it. Statements on properties are being worked on this sprint. We probably need another sprint or two to get it finished. --Lydia Pintscher (WMDE) (talk) 18:20, 30 September 2014 (UTC)

Wikidata for citations

I hope nobody has posted this yet, but there is still a lack in response to the proposal to use Wikidata items to store the citations for Wikipedia:

https://meta.wikimedia.org/wiki/Grants:IdeaLab/Tools_for_using_wikidata_items_as_citations#Endorsements

-Tobias1984 (talk) 07:11, 30 September 2014 (UTC)

#Wikidata IEG proposal: Tools for using wikidata items as citations. ;) --Succu (talk) 08:17, 30 September 2014 (UTC)

How to list new company ?

Many of the people thinks wiki and google r reliable source of legal informations

Sorry, but Wikidata is not an advertizing space. --Jakob (talk) 22:40, 30 September 2014 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2014/09&oldid=2113155723"