On Wed, Apr 3, 2013 at 11:27 PM, Sven <svenmanguard(a)gmail.com> wrote: They're already on the test system and should go live with the next deployment. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Community Communications for Wikidata Wikimedia Deutschland e.V. Obentrautstr. 72 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

I think we did discuss a simple, working solution: Saving the value together with the Wikipedia page. The major argument against that was: it is a waste of storage to create a new Wikipedia page (perhaps daily) when property values included in a page are changed in Wikidata. I personally value trust and documentation of change much higher than disk storage, but even then, there are ways to balance this. So perhaps a modified proposal that matches the current development stage: If an editor saves a page with {{#property:population}} the parser looks up the current value and changes this to: {{#property:population|current value=2348732}} and stores this wikitext version in the Wikipedia. The same would apply to updating, saving {{#property:population|current value=2348732}} may result in {{#property:population|current value=2348700}} being saved. This would mean no additional "waste" of storage for articles that are regularly changed. For those that are not, one could imagine a bot-based monthly update check to make past knowledge transparent. I realize that this would require a pattern, where the Wikidata-derived values would remain editable on the topic/article pages, i.e. the property function would have to be inserted in the template call, rather than in the template definition. Those wikidata properties automatically called inside templates with a dynamic item decided by the current template call would not be preserved. However, both editing patterns would be available and it would be up to the community of each Wikipedia to choose the preferred one. (As I said previously: although similar to the issue of commons images and templates, the issue at stake for Wikidata is different. Because of the problems in preserving a transparent editing history, updates to commons images are generally restricted to truly minor improvements (contrast, cropping, better resolution, etc.). I am not aware of cases, where commons images regularly are replaced with updated content that is different in substance and thus automatically changes all Wikipedia pages, representing different knowledge. I don't want to exclude this, but even for changing company logos the usual solution is to create a new name, preserving the old logo. Similarly, templates may fail to work in old versions (big problem!), but I am not aware that a template would render out-of-time information when viewing a past revision. Thus, the problem of Wikidata with respect to endangering the trust basis of Wikipedia, the version system, is related, but different). Gregor

This is in my opinion an upstream issue for MediaWiki proper. I do not think that templates and images from Commons are that different. Take this image for example: < https://en.wikipedia.org/wiki/File:Treaty_of_Accession_2011_Ratification_Ma… It always reflects the current state of ratification. Take the templates that display the conservation status of species in Wikipedia. It encodes a whole lot of knowledge about different preservation status systems, and if they change, this is also not preserved anywhere in the history. <https://en.wikipedia.org/wiki/Wikipedia:Conservation_status I agree that this is an issue. But our solution is consistent with the way it is done in other parts of Wikipedia, and a solution should not be partially addressing Wikidata but Wikipedia as a whole. One way would be to great HTML dumps of Wikipedia at regular intervals, as, e.g., the Internet Archive does it. A much more thorough discussion of this issue can be found here in a RENDER deliverable I was co-authoring in 2010: <http://render-project.eu/wp-content/uploads/2010/05/D1.1.2.pdf Cheers, Denny 2013/4/4 Gregor Hagedorn &lt;g.m.hagedorn(a)gmail.com > > when templates (or, in the case of wikidata, properties) get deleted or > renamed. > > Nobody has come up with a good solution yet. > I think we did discuss a simple, working solution: Saving the value > together with the Wikipedia page. > The major argument against that was: it is a waste of storage to > create a new Wikipedia page (perhaps daily) when property values > included in a page are changed in Wikidata. I personally value trust > and documentation of change much higher than disk storage, but even > then, there are ways to balance this. So perhaps a modified proposal > that matches the current development stage: > If an editor saves a page with {{#property:population}} the parser > looks up the current value and changes this to: > {{#property:population|current value=2348732}} > and stores this wikitext version in the Wikipedia. The same would > apply to updating, saving {{#property:population|current > value=2348732}} may result in {{#property:population|current > value=2348700}} being saved. > This would mean no additional "waste" of storage for articles that are > regularly changed. For those that are not, one could imagine a > bot-based monthly update check to make past knowledge transparent. > I realize that this would require a pattern, where the > Wikidata-derived values would remain editable on the topic/article > pages, i.e. the property function would have to be inserted in the > template call, rather than in the template definition. Those wikidata > properties automatically called inside templates with a dynamic item > decided by the current template call would not be preserved. However, > both editing patterns would be available and it would be up to the > community of each Wikipedia to choose the preferred one. > (As I said previously: although similar to the issue of commons images > and templates, the issue at stake for Wikidata is different. Because > of the problems in preserving a transparent editing history, updates > to commons images are generally restricted to truly minor improvements > (contrast, cropping, better resolution, etc.). I am not aware of > cases, where commons images regularly are replaced with updated > content that is different in substance and thus automatically changes > all Wikipedia pages, representing different knowledge. I don't want to > exclude this, but even for changing company logos the usual solution > is to create a new name, preserving the old logo. Similarly, templates > may fail to work in old versions (big problem!), but I am not aware > that a template would render out-of-time information when viewing a > past revision. Thus, the problem of Wikidata with respect to > endangering the trust basis of Wikipedia, the version system, is > related, but different). > Gregor > _______________________________________________ > Wikidata-l mailing list > Wikidata-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

There was a discussion about this months ago and I think that the conclusion was every property should have a valid_from and a valid_to field [default = end of the universe]. So you can get snapshots for past versions without any magic. An example for a hypothetic cashflow-database (dates are YYMMDD ) might be: select * from cf where origin = "wmde" and v2 = 999999 and payment_date from wmde select * from cf where origin = "wmde" and v2 = 121231 and payment_date end of year 2012 I don't know if something like this would be easy to add to your existing database scheme. Lukas Am Do 04.04.2013 09:47, schrieb Daniel Kinzler:

If that is so simple, can the {{#property:xxx}} call in a wikipedia simply resolve to the revision that was valid at the point in time equivalent to a given revision? It seem like you say you already have the code to do that when creating the wikidata item description. I disgree that this is an issue for mediawiki core, since it is a question of how the Wikidata-specific property function works. Gregor PS: I admit that Denny has found an example to where an image seems to be changing in content on commons, but I still believe this is a rare case. Any wiki-statistician that can supply exact number for these cases?

And what are you doing when you want the knowledge of the world from 5 years ago? Isn't this a valid need? To compare what have changed for example in the measurement of ocean depth? These snapshots could be a low hanging fruit with valid_from and valid_to and it is saving disk space compared to storing complete dumps every day. Instead of having a "List of Presidents of the US" or looking up every person for a property "President of the USA" you could get this List from the property "President" from the Item "USA" together with valid_from and valid_to. Lukas Am Do 04.04.2013 22:23, schrieb Michael Hale:

I don't think, that the most claims are immutable. Am Fr 05.04.2013 00:30, schrieb Michael Hale:

Good Point! The first things I thougt about were populations and other country, region or city oriented data. But would two fields that can be set to NULL as default - valid_from -> the beginning of the time, valid_to -> the end of the universe - hurt anyone? Am Fr 05.04.2013 00:37, schrieb Michael Hale:

On 4 April 2013 22:23, Michael Hale &lt;hale.michael.jr(a)live.com&gt; wrote: You are correct, the "current version" would have to be an exception, and display under the current time rules just as in the implementation. My proposal only makes sense when versions from the history are being displayed. Gregor

Le 2013-04-05 09:32, Gregor Hagedorn a écrit : Do you also plane to add a "source" relation? I mean, a statement is necessarily stated somewhere before it comes into the db. Some statement could have an empty field for this relation, but it should be a "need fix" state. I don't believe in "timeless universal statement". Sure there are statements that everybody would agree. But this mean we should have no difficulty to find some references where you can find this statement claimed. Also we should keep in mind that what we can sincerely perceive as universal truth, may well be a cognitive/cultural bias. To resume, Wikidata should not be a statements database, but a statements on statements database. That is, "we claim that this paper/person/source claims that" and not "we claim that". As said, we don't have to make it a necessary requirement and an entry without such a source may be taken as "someone (see history) reported there's a used statement which claims 'blablabla', but we have no source to support this statement". It's even more important with historical statements. Past history is not something which can't be falsifyed: it's something that some groups may even actively want to distort. In France for example it's illegal to claim revisionism statements, that is to claim that there was no Holocaust during World War II, because there are groups that actively defend such a these. But you can't rely on such a legal mean to prevent governemental history distortions, and it prevent people to train their critical mind. So to my mind it's better to be able to know who claim what, so anyone can judge by itself if some conflict of interest are involved or not.

The thing to remember is that the history of a page is the history of the wiki markup for the page, not the history of the rendered HTML. It would be misleading if edits were shown in the markup history for an article each time a template or Wikidata item changed because reverting the markup to that version wouldn't actually revert the change. I think what curators with specific specialties want is the ability to automatically expand their watchlist to include all templates and data items that could affect their watched pages. Then a way to view the merged watchlists from multiple projects would be helpful. There is room for improvement in global account integration. For example, I just noticed that I need to set my timezone on Wikipedia and Wikidata independently.

Oh, nice.

Well, I could make a view that shows the diff of a Wikipedia article stacked on top of the diff for the corresponding Wikidata item on my computer in a few minutes. But diffs can be very long sometimes, so there would be a lot of discussion about whether that view is more appropriate than just making it easier to find the link to the Wikidata item on the diff and edit pages for articles that include Wikidata properties. But the work-around you suggest is not a work-around. If the U.S. article currently says: "The population of the U.S. is 309,000,000 people." And I change it to say "The population of the U.S. is {{#property:population|current-value=309000000}} people." Which scenarios does that improve?

So you agree that it is more important to reduce clutter than to add functionality that very few people use? They used to save backups of the HTML versions of pages, but they stopped 5 years ago because it's not worth the extra overhead for something so few people use. http://dumps.wikimedia.org/other/static_html_dumps/ I do think the integration of Wikipedia and Wikidata will be improved, but importing data, importing references, and switching the templates over are higher priorities. I'm not saying it is easy to use #property to refer to a particular article revision. I'm saying it is impossible and should stay that way. To enable the scenario you describe with wiki markup syntax would require something like {{#property:population|values_revisions=300000000,1739242,280000000,1344282}}, which would just get worse the older an article gets and defeats the whole purpose of having Wikidata in the first place. Now, the MediaWiki API does let you invoke the renderer. http://www.mediawiki.org/wiki/API:Parse We could expand the functionality of the oldid parameter to know to use a past version of Wikidata items when doing renders of old revisions, but the impression I get is that not enough people are asking for that feature to warrant giving it a high priority.

But you do agree that it is easier to curate articles by updating one value in a database than updating the value separately everywhere it appears?

2013/4/6 Gregor Hagedorn &lt;g.m.hagedorn(a)gmail.com&gt;om>: [...] [...] This is great, but the solution I saw (i.e. {{#property:population|current-value=309000000}}) makes the whole Wikidata absolutely useless. The changes in wikidata items are already visible in users' watchlist, and if I'm not mistaken even in recent changes. I'm sorry, but I do agree with Michael: we need to focus primarily on importing data and their references and then adapting the templates. This is the reason why Wikidata has been put up: to make data storage, editing, and even creating new articles easier. Plus, just a note about seeing an item as of 2011. If I try to see what an article looked at that time and if a template in the meantime has been substituted and deleted, I'd see only a red mark stating "Template:Whatever" instead of that template. In 12 years, nobody complained about that... :) -- Luca "Sannita" Martinelli http://it.wikipedia.org/wiki/Utente:Sannita

No, it is not an example of a solution. If you wrote a property inclusion like that, and then someone changed the value on Wikidata, and then someone made an arbitrary edit somewhere else in the article, then when they save the page again the parameter that you have provided makes no sense. We don't store information about the history of an article in the article itself. The correct solution would be to change the behavior of the renderer to look for old versions of templates and data items, but Wikidata wouldn't be pressured to do this until Wikipedia changed the way it renders templates. To pressure Wikipedia into changing the way it renders templates you will need more people that want think this feature is important. The only time I ever look at old versions of articles is when I'm looking at a change from my watchlist or looking for the most recent change that wasn't vandalized if I randomly come across vandalism.

I understand what you were asking for now, but the only situations I'm aware of where the wiki markup is automatically changed before saving is for ~~~~, which is only supposed to be used on talk pages. Enabling a template inclusion to be automatically rewritten during a save has no precedent, so it would require a lot of community support to push the feature through. I think we are all trying to think of the best ways to integrate the workflow of Wikidata and Wikipedia, but Wikidata isn't mature enough yet to know exactly what problems we will run into. I think articles will be updated more frequently than items for the foreseeable future. I think the primary concern is that people will be drawn to do more vandalism on Wikidata because then their changes are visible in more places. That is why Wikidata changes for your watched articles already show up in your watchlist.

Le 2013-04-05 23:19, Michael Hale a écrit : As far I understand, I totaly disagree. We have to provide a way to obtain the page as it was when a user made a commited it. Otherwise you will provide false attribution statements. Argumentum ad populum is not an acceptalbe here. Well, that should obviously be an automaticaly generated things. Knowing the date of a particular wikipedia revision page, you will also be able to compute which wikidata revision the proprety call should return. -- Association Culture-Libre http://www.culture-libre.org/

Le 2013-04-06 20:31, Luca Martinelli a écrit : I wasn't aware of such an issue. But here the issue is less important, as template generaly are used for shaping the article, relevant data being passed as argument. I can't afford the time to read all of [1], but did you make an extensive research before "nobody complained"? Now there's also the assumption that the impact level would be the same as with template deletion, which as far as I know require a community decision. Anyone can modify wikidata anytime, so my guess is that won't have the same impact. By the way I do use page history links. For example when citing a particual assumption/sentance you found in a wikipedia article, one may want to give an accurate revision, because – you know – new revisions may change! So in order to make relevant references, you have to cite accurate revision, and not the main URL that may evolve to something completely different from what you wanted your reader to be pointed to. [1] https://bugzilla.wikimedia.org/buglist.cgi?title=Special%3ASearch&quick… -- Association Culture-Libre http://www.culture-libre.org/

Le 2013-04-08 15:02, Luca Martinelli a écrit : When I look in the history, I want to see the data which where used then : there are the correct data of this history context. The "current" page may be automaticaly edited to match the current wikidata entries it refers to, but this changes should appears in the history, just like it's done with bots. So, no, I don't care that the last revision of an article uses the "correct data", because "correct data" is an ambiguous term. What I hope to see, is that the last revision article uses the last revision of the wikidata entries it needs; or at least the value it had the last time that a commit was made to update this value. And when I look in the history, I want to see the value that the article used to use then. Otherwise it would be history counterfeiting. -- Association Culture-Libre http://www.culture-libre.org/

Le 2013-04-08 15:54, Luca Martinelli a écrit : Sorry, I didn't want to upset anyone. Ok, do you mean making a bug report on https://bugzilla.wikimedia.org/ ? If so I would welcome any advise to make a bug report as relevant as possible. To my mind it would be realy like put the cart before the horse if we began to feed articles with wikidata before we have a proper history management. I understand the willing to be able to use this bright new tool. I **do** share your exitement here. But if you take a step backward, there's no urge to go into a situation possibly harmful for the credibility of our "will to be reliable through transparency". So, before I make a bug report, can anyone confirm me that as it is today, wikidata invokation in previous revision of a page will fail to provide the relevant data, that is, the data which was returned at the time the revision was in use. More generaly, could developers/admins confirm me that data update would not appear in the article history. Because it seems to me that I saw such entries with the interlang migration, so until now I supposed that any change in wikidata would rise a new revision with a commit message in each article using this data. Kind regards, mathieu

Le 2013-04-09 20:44, Michael Hale a écrit : Could you please provide the relevant URL? thank you :) -- Association Culture-Libre http://www.culture-libre.org/

I saw the election here: http://en.wikipedia.org/wiki/National_electoral_calendar_2013The Italian Wikipedia was the first in the list of those that already support phase 2 Wikidata functionality, so I changed the Italian article about Venezuela: http://it.wikipedia.org/wiki/Venezuela"Presidentedente: Nicolas Maduro" is now being pulled from Wikidata.