Wikidata:Project chat

From Wikidata
(Redirected from Wikidata:Project Chat)
Jump to: navigation, search
Shortcut: WD:PC
Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Requests for deletions and mergers can be made here.

IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at September.

A filter for badge removes[edit]

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: [1] [2] ? --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: [3] [4] [5]. --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"[6]. --Stryn (talk) 18:37, 13 September 2014 (UTC)

Proposal: enable FlaggedRevs on wikidata[edit]

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)

Symbol oppose vote.svg 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: [7], [8], [9], [10], [11], [12]. --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)
Symbol oppose vote.svg 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)
Symbol support vote.svg 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)
Symbol support vote.svg 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)
Symbol support vote.svg 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)
Symbol support vote.svg 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)
  • Pictogram voting comment.svg 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)
  • Pictogram voting comment.svg 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)
Symbol oppose vote.svg 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)
Symbol support vote.svg 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)
  • Symbol neutral vote.svg 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)
  • Symbol oppose vote.svg 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)
  • Pictogram voting comment.svg 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)
  • Symbol oppose vote.svg 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 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)
  • Symbol oppose vote.svg 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)
  • Pictogram voting comment.svg 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)
  • Symbol oppose vote.svg Oppose to check every IP edition in Wikidata. It's not viable / Symbol support vote.svg 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[edit]

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)

  • Pictogram voting comment.svg 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[edit]

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)
    • @Vlsergey: I subscribe Jheald's words. The way I see this working is:
  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)

Adding automatically links to items[edit]

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 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 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 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)

Songs or singles[edit]

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 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 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 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

Viswaprabha (talk)
Maximilianklein (talk)
Jane023 (talk) 08:21, 30 May 2013 (UTC)
Alexander Doria (talk)
Ruud 23:15, 24 June 2013 (UTC)
Filceolaire (talk)
Jayanta Nath
Yann (talk)
John Vandenberg (talk) 09:14, 30 November 2013 (UTC)
Danmichaelo (talk) 19:30, 16 February 2014 (UTC)
Ravi (talk)
Vlsergey (talk)
Mvolz (talk) 08:21, 20 July 2014 (UTC)
Hsarrazin (talk) 07:56, 9 August 2014 (UTC)
Pictogram voting comment.svg Notified participants to Wikiproject Books @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 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 creator of an event, a competition...[edit]


I saw that we had the properties founder (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, formation location (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 founder (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[edit]

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. 16:12, 15 September 2014 (UTC)
You can use at least this dataset. We will have at least one reference with a time value. 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)

President of Bolivia[edit]

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 Q13403037 (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: Q13403037 (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)

Cleaning Wikidata Sandbox (Q4115189)[edit]

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[edit]

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 ( 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[edit]

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[edit]

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[edit]

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Фотиева_схизма 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)

  • @Neolexx: did you try mw.wikibase.getEntityObject().id ? -- Vlsergey (talk) 13:47, 16 September 2014 (UTC)
    • Perfect, thank you! If there is something as simple to query Wikidata API then I'll be totally happy. --NeoLexx (talk) 13:59, 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Фотиева_схизма
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[edit]

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) miga 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)
Symbol support vote.svg 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)

What should we do with wrong data from Wikipedia ?[edit]

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 is 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 (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)

Special:SetSiteLink cancel button suggestion[edit]

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)

Label lister not working[edit]

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)

Property values full list[edit]

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[edit]

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: target of a interwiki-link:

--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. 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. 21:48, 19 September 2014 (UTC)

Wikidata for GLAMs Workshop: November 14, Amsterdam[edit]

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)

Vital Article badge?[edit]

Should we have Vital Article as a badge? There's currently Top-importance articles (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)

Rendering of Module pages ?[edit]

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)