A good question from huwiki:
When I click on an earlier version of the page in the history, will the "then-value" of the property be shown or the current value? If I read the 2013 version of [[United States of America]] in 2018, will Obama be the president?
Once we get qualifiers (and can specify time periods using them) then we will have all past values included, with qualifiers. So Obama, but also Eisenhower, Lincoln, Taft, etc.
Any word on when we get qualifiers, anyone?
On Apr 3, 2013, at 5:23 PM, Bináris wikiposta@gmail.com wrote:
A good question from huwiki:
When I click on an earlier version of the page in the history, will the "then-value" of the property be shown or the current value? If I read the 2013 version of [[United States of America]] in 2018, will Obama be the president?
-- Bináris _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Wed, Apr 3, 2013 at 11:27 PM, Sven svenmanguard@gmail.com wrote:
Any word on when we get qualifiers, anyone?
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.
On 03.04.2013 23:23, Bináris wrote:
A good question from huwiki:
When I click on an earlier version of the page in the history, will the "then-value" of the property be shown or the current value? If I read the 2013 version of [[United States of America]] in 2018, will Obama be the president?
You will see the current value, not the old one. This is the same as for templates and images. A "time warp" system that allows us to view old versions of pages exactly as they were has long been discussed, but is tricky, especially when templates (or, in the case of wikidata, properties) get deleted or renamed. Nobody has come up with a good solution yet.
The qualifiers Sven mentioned will allow us to record who was president when in Wikidata, but when including the "current president" on a Wikipiedia page, this will always be the present one, even when looking at old version of the page.
-- daniel
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
Gregor Hagedorn, 04/04/2013 11:39:
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.
A middle ground would be using the qualifiers for something like {{#property:president|as of=2013}} which would always transclude the president of /this/ mandate. However you'd still have to pass this parameter in any call for a template where the property is transcluded, while such stuff is often implicit. The problems Daniel describes are hardly resolved. (This said knowing nothing about the syntax, qualifiers etc. Sorry.)
Nemo
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_Map...
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 g.m.hagedorn@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Denny Vrandečić, 04/04/2013 12:10:
This is in my opinion an upstream issue for MediaWiki proper. I do not think that templates and images from Commons are that different [...]
...and that's already been rejected (for now): https://bugzilla.wikimedia.org/show_bug.cgi?id=34778
One way would be to great HTML dumps of Wikipedia at regular intervals, as, e.g., the Internet Archive does it.
This requires dumpHTML to work again after 5+ years. :) http://www.kiwix.org/index.php/Mediawiki_DumpHTML_extension_improvement would benefit from some help.
Nemo
Storage aside, one major problem with the save-in-the-article is that it shovels a lot of increased complexity onto the Wikipedia editors - one of the hopes for Wikidata is that we can convert the existing morass of WP template data into invoking {{infobox city}} and have population, etc, magically appear. Wikipedia articles thus become less scary, we get happier editors, everyone wins.
But having the "live" data saved into Wikipedia loses all this benefit - we have the same muddle of template data, with added semantic markup, If seeing |population=2348732 was confusing, |population={{#property:population|current value=2348732}} is the the worst of all worlds!
This is something we should probably fix within MediaWiki & Wikidata, so that it can handle things invisibly but give a meaningful response. My preference would be to build some kind of hook so that it can say "give me the version of the data in existence at timestamp X" and be given an accurate value; to have any meaningful ability to navigate old versions of WP we already need to do develop this for templates.
Nemo's suggestion for "give me the data valid at this date" and marking everything up correspondingly is interesting but I think a bit of a red herring - it will give spurious results. If we look at the old version of a Wikipedia article, we want to see *the article as it existed* then, not *the truth as it existed then*.
Imagine we had someone who was, say, married very quietly in 2013 and only publicly announced it in 2015. The information will be added to Wikidata in 2015 ("spouse: John Smith"), marked as valid from 2013 onwards. If we have a timestamp-of-data based system, looking at a 2014 page revision will not list a spouse in the infobox; if we have a data-validity based one, then the 2014 page will report "spouse: John Smith" even though Wikipedia itself didn't know that at the time.
- Andrew.
On Thursday, 4 April 2013, Gregor Hagedorn wrote:
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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
= 130404; -- would give the actual view of future cashflows coming
from wmde
select * from cf where origin = "wmde" and v2 = 121231 and payment_date
= 130404; -- would give the view of cashflows coming from wmde seen by
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:
On 03.04.2013 23:23, Bináris wrote:
A good question from huwiki:
When I click on an earlier version of the page in the history, will the "then-value" of the property be shown or the current value? If I read the 2013 version of [[United States of America]] in 2018, will Obama be the president?
You will see the current value, not the old one. This is the same as for templates and images. A "time warp" system that allows us to view old versions of pages exactly as they were has long been discussed, but is tricky, especially when templates (or, in the case of wikidata, properties) get deleted or renamed. Nobody has come up with a good solution yet.
The qualifiers Sven mentioned will allow us to record who was president when in Wikidata, but when including the "current president" on a Wikipiedia page, this will always be the present one, even when looking at old version of the page.
-- daniel
Are you saying every property should have a valid_from and valid_to date or every claim? If you want that information for queries to be able to show information about deprecated properties then I don't understand the example because both queries use the same properties. If it is for claims, then I don't see what value we'd gain from storing that extra metadata. Every scenario I can think of where you care about past states of the database is already handled by the compare selected revisions feature. For example, if I use compare selected revisions on the United States of America item I can see that on March 14th Daffy Duck was the president, and now Barack Obama is. If we decide that a new name is better for a property, then we are essentially saying that it is a better name for the property when we look at past and current values of the property. I also think that in our discussions of qualifiers for properties of datatype item we are continuing to use data that should be stored in items as examples of qualifiers. I do not expect to find information about when a president took office as a qualifier in a list of values for the heads of state property. I expect to find that information on the item for the person or on an item that contains all information about a specific presidential administration. How would we capture Grover Cleveland's terms as a qualifier? I would just expect to find a list of two dates for when he took office and two dates for when he left office on the item for Grover Cleveland. I guess we could list him twice, but then where do we put information about the vice-presidents? Do we just make an arbitrary rule that as soon as something has 3 or more qualifiers, the information should be put into separate items? I think one of the goals of Wikidata is to have each piece of information provided once, in the most appropriate place possible, otherwise maintaining consistency becomes problematic. Also, for situations where I think there is no question that a qualifier should be used, such as historic population values, have we decided how specific of a property should be used for that qualifier? If we just have a generic date property, that allows growth to happen the fastest, because there are many places that property could be used as a qualifier. I think a date associated with a population value is pretty self-explanatory, but perhaps there are situations where people will be confused as to why there is a date associated with a value. Do we just put information in the property description or create more specific properties to use as qualifiers?
Date: Thu, 4 Apr 2013 15:02:37 +0200 From: benedix@zedat.fu-berlin.de To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
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
= 130404; -- would give the actual view of future cashflows coming
from wmde
select * from cf where origin = "wmde" and v2 = 121231 and payment_date
= 130404; -- would give the view of cashflows coming from wmde seen by
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:
On 03.04.2013 23:23, Bináris wrote:
A good question from huwiki:
When I click on an earlier version of the page in the history, will the "then-value" of the property be shown or the current value? If I read the 2013 version of [[United States of America]] in 2018, will Obama be the president?
You will see the current value, not the old one. This is the same as for templates and images. A "time warp" system that allows us to view old versions of pages exactly as they were has long been discussed, but is tricky, especially when templates (or, in the case of wikidata, properties) get deleted or renamed. Nobody has come up with a good solution yet.
The qualifiers Sven mentioned will allow us to record who was president when in Wikidata, but when including the "current president" on a Wikipiedia page, this will always be the present one, even when looking at old version of the page.
-- daniel
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
don't see what value we'd gain from storing that extra metadata. Every scenario I can think of where you care about past states of the database is already handled by the compare selected revisions feature.
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?
I thought one of the main reasons we are making Wikidata is so that you can update a value there, and then everywhere it is used will be automatically updated. If we find a more precise measurement for the depth of an ocean trench, then I just want to update it on Wikidata, and then every article that references it will be updated. I don't want to have to update it on Wikidata and then go do a null edit on every article that uses that information.
From: g.m.hagedorn@gmail.com Date: Thu, 4 Apr 2013 22:13:24 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
don't see what value we'd gain from storing that extra metadata. Every scenario I can think of where you care about past states of the database is already handled by the compare selected revisions feature.
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?
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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 thought one of the main reasons we are making Wikidata is so that you can update a value there, and then everywhere it is used will be automatically updated. If we find a more precise measurement for the depth of an ocean trench, then I just want to update it on Wikidata, and then every article that references it will be updated. I don't want to have to update it on Wikidata and then go do a null edit on every article that uses that information.
We will use qualifiers to tag values with dates for which they are relevant if there isn't a better place to put the information. We commonly use the example of historic population values. MediaWiki software saves disk space by delta encoding edit histories. http://en.wikipedia.org/wiki/Delta_encoding I can probably think of at least 5 different ways we could arrange the schema of Wikidata to store information about US presidents, but I don't think using universal valid_from and valid_to values for every claim is the most efficient, natural, or flexible way to do so.
Date: Fri, 5 Apr 2013 00:08:00 +0200 From: benedix@zedat.fu-berlin.de To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
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 thought one of the main reasons we are making Wikidata is so that you can update a value there, and then everywhere it is used will be automatically updated. If we find a more precise measurement for the depth of an ocean trench, then I just want to update it on Wikidata, and then every article that references it will be updated. I don't want to have to update it on Wikidata and then go do a null edit on every article that uses that information.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
I don't think, that the most claims are immutable.
Am Fr 05.04.2013 00:30, schrieb Michael Hale:
We will use qualifiers to tag values with dates for which they are relevant if there isn't a better place to put the information. We commonly use the example of historic population values. MediaWiki software saves disk space by delta encoding edit histories. http://en.wikipedia.org/wiki/Delta_encoding
I can probably think of at least 5 different ways we could arrange the schema of Wikidata to store information about US presidents, but I don't think using universal valid_from and valid_to values for every claim is the most efficient, natural, or flexible way to do so.
Date: Fri, 5 Apr 2013 00:08:00 +0200 From: benedix@zedat.fu-berlin.de To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
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 thought one of the main reasons we are making Wikidata is so that you can update a value there, and then everywhere it is used will be automatically updated. If we find a more precise measurement for the depth of an ocean trench, then I just want to update it on Wikidata, and then every article that references it will be updated. I don't want to have to update it on Wikidata and then go do a null edit on every article that uses that information.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
I don't have any data to agree or disagree with you about that, but most of the edits I have made have been for films. Most of those claims are immutable.
Date: Fri, 5 Apr 2013 00:34:21 +0200 From: benedix@zedat.fu-berlin.de To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
I don't think, that the most claims are immutable.
Am Fr 05.04.2013 00:30, schrieb Michael Hale:
We will use qualifiers to tag values with dates for which they are relevant if there isn't a better place to put the information. We commonly use the example of historic population values. MediaWiki software saves disk space by delta encoding edit histories. http://en.wikipedia.org/wiki/Delta_encoding
I can probably think of at least 5 different ways we could arrange the schema of Wikidata to store information about US presidents, but I don't think using universal valid_from and valid_to values for every claim is the most efficient, natural, or flexible way to do so.
> Date: Fri, 5 Apr 2013 00:08:00 +0200
> From: benedix@zedat.fu-berlin.de
> To: wikidata-l@lists.wikimedia.org
> Subject: Re: [Wikidata-l] Page history and properties
>
> 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 thought one of the main reasons we are making Wikidata is so that
> > you can update a value there, and then everywhere it is used will be
> > automatically updated. If we find a more precise measurement for the
> > depth of an ocean trench, then I just want to update it on Wikidata,
> > and then every article that references it will be updated. I don't
> > want to have to update it on Wikidata and then go do a null edit on
> > every article that uses that information.
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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:
I don't have any data to agree or disagree with you about that, but most of the edits I have made have been for films. Most of those claims are immutable.
Date: Fri, 5 Apr 2013 00:34:21 +0200 From: benedix@zedat.fu-berlin.de To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
I don't think, that the most claims are immutable.
Am Fr 05.04.2013 00:30, schrieb Michael Hale:
We will use qualifiers to tag values with dates for which they are relevant if there isn't a better place to put the information. We commonly use the example of historic population values. MediaWiki software saves disk space by delta encoding edit histories. http://en.wikipedia.org/wiki/Delta_encoding I can probably think of at least 5 different ways we could arrange the schema of Wikidata to store information about US presidents, but I don't think using universal valid_from and valid_to values for every claim is the most efficient, natural, or flexible way to do so. > Date: Fri, 5 Apr 2013 00:08:00 +0200 > From: benedix@zedat.fu-berlin.de <mailto:benedix@zedat.fu-berlin.de> > To: wikidata-l@lists.wikimedia.org <mailto:wikidata-l@lists.wikimedia.org> > Subject: Re: [Wikidata-l] Page history and properties > > 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 thought one of the main reasons we are making Wikidata is so that > > you can update a value there, and then everywhere it is used will be > > automatically updated. If we find a more precise measurement for the > > depth of an ocean trench, then I just want to update it on Wikidata, > > and then every article that references it will be updated. I don't > > want to have to update it on Wikidata and then go do a null edit on > > every article that uses that information. > > > _______________________________________________ > Wikidata-l mailing list > Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> > https://lists.wikimedia.org/mailman/listinfo/wikidata-l _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Well, I don't know if they would hurt anyone, but I don't think people would go through the extra effort to set them. Here are our current properties. http://www.wikidata.org/wiki/Wikidata:List_of_properties We could categorize them according to mutability, but we'd also need to know how many times each property is used. For historic population values, qualifiers will serve the purpose you want. For presidential terms, I think we will either see "started presidency" and "ended presidency" properties that are added to items for people who have been president, or we will see "administration began" and "administration ended" properties added to items for each presidential term/administration.
Date: Fri, 5 Apr 2013 00:49:04 +0200 From: benedix@zedat.fu-berlin.de To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
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:
I don't have any data to agree or disagree with you about that, but most of the edits I have made have been for films. Most of those claims are immutable.
Date: Fri, 5 Apr 2013 00:34:21 +0200
From: benedix@zedat.fu-berlin.de
To: wikidata-l@lists.wikimedia.org
Subject: Re: [Wikidata-l] Page history and properties
I don't think, that the most claims are immutable.
Am Fr 05.04.2013 00:30, schrieb Michael Hale:
We will use qualifiers to tag values with dates for which they are relevant if there isn't a better place to put the information. We commonly use the example of historic population values. MediaWiki software saves disk space by delta encoding edit histories. http://en.wikipedia.org/wiki/Delta_encoding
I can probably think of at least 5 different ways we could arrange the schema of Wikidata to store information about US presidents, but I don't think using universal valid_from and valid_to values for every claim is the most efficient, natural, or flexible way to do so.
> Date: Fri, 5 Apr 2013 00:08:00 +0200
> From: benedix@zedat.fu-berlin.de
> To: wikidata-l@lists.wikimedia.org
> Subject: Re: [Wikidata-l] Page history and properties
>
> 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 thought one of the main reasons we are making Wikidata is so that
> > you can update a value there, and then everywhere it is used will be
> > automatically updated. If we find a more precise measurement for the
> > depth of an ocean trench, then I just want to update it on Wikidata,
> > and then every article that references it will be updated. I don't
> > want to have to update it on Wikidata and then go do a null edit on
> > every article that uses that information.
>
>
> _______________________________________________
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 4 April 2013 22:23, Michael Hale hale.michael.jr@live.com wrote:
trench, then I just want to update it on Wikidata, and then every article that references it will be updated. I don't want to have to update it on Wikidata and then go do a null edit on every article that uses that information.
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 :
On 4 April 2013 22:23, Michael Hale hale.michael.jr@live.com wrote:
trench, then I just want to update it on Wikidata, and then every article that references it will be updated. I don't want to have to update it on Wikidata and then go do a null edit on every article that uses that information.
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
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.
My concern is, that the Wikidata editors, those not with random editing behavior, but those who are curators/caretakers of specific pages, experience a disempowerment, because they loose control.
I view the decision to inform about wikidata changes only in the short-lived recentchanges, but not in the page history, as problematic. Page editors will now be informed that the page has changes, but this change is not recorded in the page history, and it cannot be seen in the version-diffs. This is breaking a lot of assumptions of trust. Wikipedia can be be collaborative because of this trust in the versioning system and because of the accessibility with reasonable, of the version-diffs (transparency).
Some editors will probably leave the Wikipedia project due to the introduction of Wikidata, no matter how much Wikidata reaches out to them. I feel that the number is much higher in the present "disempowerment" implementation, which is why I try to argue here for making content changes that come from Wikidata and affect Wikipedia pages transparent on Wikipedia, not only Wikidata.
This discussion is about proposing potential elements and ideas; there may be much better ideas. I am not convinced by the arguments against the proposed means: I fear the thinking is a programmers thinking, not a content editor thinking. Denny, I feel that your proposal that some html-version archiving somewhere, which is not integrated into the wikipedia editing workflow, does not take sufficient care of the needs of the editors, especially the need to be able to use the version comparison, not just find rendered versions somewhere in isolation.
But neither of us can see into the future. I think Wikidata is a great achievement as it is, and we all agree that it can be made better by better integration into existing Wikipedia workflows. Let us focus on the importance of this and try to find the best means that are achievable with existing resources.
Gregor
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.
From: g.m.hagedorn@gmail.com Date: Fri, 5 Apr 2013 15:53:43 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
My concern is, that the Wikidata editors, those not with random editing behavior, but those who are curators/caretakers of specific pages, experience a disempowerment, because they loose control.
I view the decision to inform about wikidata changes only in the short-lived recentchanges, but not in the page history, as problematic. Page editors will now be informed that the page has changes, but this change is not recorded in the page history, and it cannot be seen in the version-diffs. This is breaking a lot of assumptions of trust. Wikipedia can be be collaborative because of this trust in the versioning system and because of the accessibility with reasonable, of the version-diffs (transparency).
Some editors will probably leave the Wikipedia project due to the introduction of Wikidata, no matter how much Wikidata reaches out to them. I feel that the number is much higher in the present "disempowerment" implementation, which is why I try to argue here for making content changes that come from Wikidata and affect Wikipedia pages transparent on Wikipedia, not only Wikidata.
This discussion is about proposing potential elements and ideas; there may be much better ideas. I am not convinced by the arguments against the proposed means: I fear the thinking is a programmers thinking, not a content editor thinking. Denny, I feel that your proposal that some html-version archiving somewhere, which is not integrated into the wikipedia editing workflow, does not take sufficient care of the needs of the editors, especially the need to be able to use the version comparison, not just find rendered versions somewhere in isolation.
But neither of us can see into the future. I think Wikidata is a great achievement as it is, and we all agree that it can be made better by better integration into existing Wikipedia workflows. Let us focus on the importance of this and try to find the best means that are achievable with existing resources.
Gregor
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Fri, Apr 5, 2013 at 8:05 PM, Michael Hale hale.michael.jr@live.com wrote:
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.
FYI: Wikidata edits relating to a watched article should already show up in the user's Wikipedia watchlist.
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.
Oh, nice.
From: lydia.pintscher@wikimedia.de Date: Fri, 5 Apr 2013 20:07:44 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
On Fri, Apr 5, 2013 at 8:05 PM, Michael Hale hale.michael.jr@live.com wrote:
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.
FYI: Wikidata edits relating to a watched article should already show up in the user's Wikipedia watchlist.
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.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 5 April 2013 20:05, Michael Hale hale.michael.jr@live.com wrote:
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.
I partly agree, the ideal situation is that a) changes of wikidata (and perhaps templates, and perhaps images, with decreasing necessity in practice) show in the page history b) in the diff, such changes are shown separately from the changes of the wikitext itself, but with the same action. This can be achieved by showing the affected changes after a separation line below the wikitext diff.
However, since this was rejected previsously as undoable, the expansion of {{#property: to include the current value would be a work-around.
We perhaps disagree about the priorities. I believe Wikipedia editors are not primarily keen on the technical definition of the diff as the changes of the wikitext of the database. I believe they want and need transparency about when an who changed a specific topic they care about.
Gregor
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?
From: g.m.hagedorn@gmail.com Date: Fri, 5 Apr 2013 21:22:15 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
On 5 April 2013 20:05, Michael Hale hale.michael.jr@live.com wrote:
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.
I partly agree, the ideal situation is that a) changes of wikidata (and perhaps templates, and perhaps images, with decreasing necessity in practice) show in the page history b) in the diff, such changes are shown separately from the changes of the wikitext itself, but with the same action. This can be achieved by showing the affected changes after a separation line below the wikitext diff.
However, since this was rejected previsously as undoable, the expansion of {{#property: to include the current value would be a work-around.
We perhaps disagree about the priorities. I believe Wikipedia editors are not primarily keen on the technical definition of the diff as the changes of the wikitext of the database. I believe they want and need transparency about when an who changed a specific topic they care about.
Gregor
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 5 April 2013 21:41, Michael Hale hale.michael.jr@live.com wrote:
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?
It makes changes visible in the present wikitext diff and allows to render the past version easily to a correct value. It is not meant as a perfect solution to all, but as an option for an editing community to enable them to chose between keeping the information visible and traceable in the Wikidata diff. I agree about the disadvantages of "clutter", but the point is that is does allow a community to choose that they don't like clutter and don't need the history and diffs, and simple create the property functions inside the templates (with no tracking). This would indeed show the changes in the present diff and it would allow several years into the future to reasonably understand (in wikitext) and render (as html) previous states of wikipedia articles several years into the past.
However, better solutions are certainly possible. Based on what you write I can imagine an editing workflow diff similar to the stacking of diffs, but actually reduced to a link pointing to Wikidata. The features I view as important are:
1. In the history, Wikidata changes for a topic are made visiable durign the the display of Wikipedia-Wikitext changes. Ideally multiple Wikidata edits could be merged into a single line if no Wikitext changes occur in between. There could be options to hide Wikidata changes. The "how" is not so important, but I think the present watchlist implementation is insufficient, because it generates an "attention" message, but makes it hard to follow up (which usually occurs in the page history + diff).
2. In the actual diff, instead of stacking the Wikitext + Wikidata property diffs, I could imagine that a solution that at the bottom says: "Associated Wikidata properties changed in the choosen period." Where choosen period is the period chosen for the diff by the editor and where the whole is linked to a Wikidata diff. Present Wikipedia communication practice heavily relies on pointing to specific history diffs (through links), but currently Wikidata changes are completely invisible there. By automatically "linking them in" present practice could continue smoothly and non-disruptive.
3. Ideally, the Wikidata diff link should have option to hide the "Wikidata internal" properties like changes in item labels, and should show language specific changes only for a specific language, to keep the attention of content editors focussed on the relevant changes (most likely Wikidata will still show more properties than those used on the wikipedia page, but this could be acceptable).
----
The question of rendering the html for past versions is separate. You seem to say that it is already easy to write the #property: function such that it takes into account the edit timestamp of a wikipedia page version and evaluates the property as it was at that point in time (with the current version (ie. when called without a pageid) always evaluating to now(), not the last editing timestamp.
ASIDE: I don't worry too much if a property is being referenced by name or ID in a past version and has since been deleted, the resulting error message is transparent rather than misleading (which the display of "wrong" information is).
Gregor
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.
From: g.m.hagedorn@gmail.com Date: Fri, 5 Apr 2013 22:22:06 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
On 5 April 2013 21:41, Michael Hale hale.michael.jr@live.com wrote:
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?
It makes changes visible in the present wikitext diff and allows to render the past version easily to a correct value. It is not meant as a perfect solution to all, but as an option for an editing community to enable them to chose between keeping the information visible and traceable in the Wikidata diff. I agree about the disadvantages of "clutter", but the point is that is does allow a community to choose that they don't like clutter and don't need the history and diffs, and simple create the property functions inside the templates (with no tracking). This would indeed show the changes in the present diff and it would allow several years into the future to reasonably understand (in wikitext) and render (as html) previous states of wikipedia articles several years into the past.
However, better solutions are certainly possible. Based on what you write I can imagine an editing workflow diff similar to the stacking of diffs, but actually reduced to a link pointing to Wikidata. The features I view as important are:
- In the history, Wikidata changes for a topic are made visiable
durign the the display of Wikipedia-Wikitext changes. Ideally multiple Wikidata edits could be merged into a single line if no Wikitext changes occur in between. There could be options to hide Wikidata changes. The "how" is not so important, but I think the present watchlist implementation is insufficient, because it generates an "attention" message, but makes it hard to follow up (which usually occurs in the page history + diff).
- In the actual diff, instead of stacking the Wikitext + Wikidata
property diffs, I could imagine that a solution that at the bottom says: "Associated Wikidata properties changed in the choosen period." Where choosen period is the period chosen for the diff by the editor and where the whole is linked to a Wikidata diff. Present Wikipedia communication practice heavily relies on pointing to specific history diffs (through links), but currently Wikidata changes are completely invisible there. By automatically "linking them in" present practice could continue smoothly and non-disruptive.
- Ideally, the Wikidata diff link should have option to hide the
"Wikidata internal" properties like changes in item labels, and should show language specific changes only for a specific language, to keep the attention of content editors focussed on the relevant changes (most likely Wikidata will still show more properties than those used on the wikipedia page, but this could be acceptable).
The question of rendering the html for past versions is separate. You seem to say that it is already easy to write the #property: function such that it takes into account the edit timestamp of a wikipedia page version and evaluates the property as it was at that point in time (with the current version (ie. when called without a pageid) always evaluating to now(), not the last editing timestamp.
ASIDE: I don't worry too much if a property is being referenced by name or ID in a past version and has since been deleted, the resulting error message is transparent rather than misleading (which the display of "wrong" information is).
Gregor
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 5 April 2013 23:19, Michael Hale hale.michael.jr@live.com wrote:
So you agree that it is more important to reduce clutter than to add functionality that very few people use?
No, I strongly disagree with this. I think the functionality of being able to curate the page Wikipedia editors care for should have highest priority. I believe it is very important to make Wikidata palatable to the people Wikipedia depends upon. Reducing clutter is nice, but avoiding to loose transparency and trust is essential.
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?
From: g.m.hagedorn@gmail.com Date: Fri, 5 Apr 2013 23:45:10 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
On 5 April 2013 23:19, Michael Hale hale.michael.jr@live.com wrote:
So you agree that it is more important to reduce clutter than to add functionality that very few people use?
No, I strongly disagree with this. I think the functionality of being able to curate the page Wikipedia editors care for should have highest priority. I believe it is very important to make Wikidata palatable to the people Wikipedia depends upon. Reducing clutter is nice, but avoiding to loose transparency and trust is essential.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 5 April 2013 23:53, Michael Hale hale.michael.jr@live.com wrote:
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?
Absolutely.
But in my experience Wikipedia editors care about the product of a readable, intelligable, correct encyclopedic article that others enjoy to read. People that are able to care about individual properties in Wikidata are rare. Wikidata needs the coupling between Wikipedia editors and Wikidata curation. The editors should be supported, not alienated by giving them the feeling that it becomes unmanageable for them to follow the changes (because of workflow separation, because of too many insigificant changes (like label changes in any number of languages that the average editor is unable to read).
I view support of Wikipedia editor workflow, for which the implemented change notification in recentchanges/watchlist is an important first step, with support of change transparency discussed here a second step, as an important piece in the whole puzzle.
(Not as the only important thing, don't get me wrong :-) )
Gregor
2013/4/6 Gregor Hagedorn g.m.hagedorn@gmail.com: [...]
Wikidata needs the coupling between Wikipedia editors and Wikidata curation. The editors should be supported, not alienated by giving them the feeling that it becomes unmanageable for them to follow the changes (because of workflow separation, because of too many insigificant changes (like label changes in any number of languages that the average editor is unable to read).
[...]
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... :)
This is great, but the solution I saw (i.e. {{#property:population|current-value=309000000}}) makes the whole Wikidata absolutely useless.
(I asked Luca back about this, and perhaps one point is that the term "current" is too easily misunderstood. The point is not that wikidata should have such a property, but that the value at the time of saving a past version of a wikipedia page is preserved. Perhaps
{{#property:population|value-when-saving-page=309000000}}
would be less easily misunderstood. nothing in Wikidata would be made useless by this, it would work exactly like now when calling the current page, it would only work differently when calling the cite-thiy-version-of-a-page links. And it would allow a wikipedia community to structure their work such that Wikipedia editors can still curate and see changes to the values.
--------
However, as said above, this is just an example of a solution. It is safe, very small processing overhead, small storage overhead and scales well to load.
A more elegant solution would clearly be to do two things:
a) when creating a Wikipedia diff on the Wikipedia page version history, to either show directly, or link to a Wikidata property diff (reduced to the relevant parts as outlined in an earlier mail) in addition to the wikitext diff of the page.
Note that it is not necessary to merge all Wikidata versions into the Wikipedia version. When comparing two arbitraty Wikipedia page version, it is irrelvant whether 1 or multiple Wikidata changes are included, all corresponding changes should be shown on request. The only necessary item is a single Wikidata indicator (operating like a special version line) on top for cases where Wikidata properties are changed after the last Wikipedia edit.
b) expand the property function such that for all calls of specific (citable) page versions, it retrieves the property rendering at that point in time from wikidata.
Gregor
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.
From: g.m.hagedorn@gmail.com Date: Sat, 6 Apr 2013 22:49:24 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
This is great, but the solution I saw (i.e. {{#property:population|current-value=309000000}}) makes the whole Wikidata absolutely useless.
(I asked Luca back about this, and perhaps one point is that the term "current" is too easily misunderstood. The point is not that wikidata should have such a property, but that the value at the time of saving a past version of a wikipedia page is preserved. Perhaps
{{#property:population|value-when-saving-page=309000000}}
would be less easily misunderstood. nothing in Wikidata would be made useless by this, it would work exactly like now when calling the current page, it would only work differently when calling the cite-thiy-version-of-a-page links. And it would allow a wikipedia community to structure their work such that Wikipedia editors can still curate and see changes to the values.
However, as said above, this is just an example of a solution. It is safe, very small processing overhead, small storage overhead and scales well to load.
A more elegant solution would clearly be to do two things:
a) when creating a Wikipedia diff on the Wikipedia page version history, to either show directly, or link to a Wikidata property diff (reduced to the relevant parts as outlined in an earlier mail) in addition to the wikitext diff of the page.
Note that it is not necessary to merge all Wikidata versions into the Wikipedia version. When comparing two arbitraty Wikipedia page version, it is irrelvant whether 1 or multiple Wikidata changes are included, all corresponding changes should be shown on request. The only necessary item is a single Wikidata indicator (operating like a special version line) on top for cases where Wikidata properties are changed after the last Wikipedia edit.
b) expand the property function such that for all calls of specific (citable) page versions, it retrieves the property rendering at that point in time from wikidata.
Gregor
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On 6 April 2013 23:05, Michael Hale hale.michael.jr@live.com wrote:
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.
Michael, this makes no sense to me. I think your scenario makes perfect sense to everyone:
Wikipedia page V1, content written:: x {{#property:population}} Wikipedia page V1, content stored:: x {{#property:population|value-when-saving-page=309000000}} property:population on Wikidata changed to 300 Wikipedia page V2: wikitext x changed to U, property function call changes on saving to: U {{#property:population|value-when-saving-page=300}}
In both cases the value-when-saving-page is correct, transparent and makes sense.
But forget it, if no-one likes it. I am not arguing about this. I am arguing about employing Wikipedia editors for the sake of proofreading Wikidata changes, while at the same time avoid making them feel helpless and no longer in charge of "their" pages.
The correct solution would be to change the behavior of the renderer to look for old versions of templates and data items,
I agree, as I wrote this is a preferrable solution for that part of the problem.
It does not solve the diff-transparency problem, however, which I consider the more important problem.
but Wikidata wouldn't be pressured to do this until Wikipedia changed the way it renders templates.
I am not trying to pressure you or make war on you.
I prefer to believe we both are on the side of discussing how as many contributors as possible are motivated to contribute to the growing commons of Wikipedia and Wikidata, and how the quality of it can best be upheld.
Gregor
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.
From: g.m.hagedorn@gmail.com Date: Sat, 6 Apr 2013 23:21:41 +0200 To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
On 6 April 2013 23:05, Michael Hale hale.michael.jr@live.com wrote:
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.
Michael, this makes no sense to me. I think your scenario makes perfect sense to everyone:
Wikipedia page V1, content written:: x {{#property:population}} Wikipedia page V1, content stored:: x {{#property:population|value-when-saving-page=309000000}} property:population on Wikidata changed to 300 Wikipedia page V2: wikitext x changed to U, property function call changes on saving to: U {{#property:population|value-when-saving-page=300}}
In both cases the value-when-saving-page is correct, transparent and makes sense.
But forget it, if no-one likes it. I am not arguing about this. I am arguing about employing Wikipedia editors for the sake of proofreading Wikidata changes, while at the same time avoid making them feel helpless and no longer in charge of "their" pages.
The correct solution would be to change the behavior of the renderer to look for old versions of templates and data items,
I agree, as I wrote this is a preferrable solution for that part of the problem.
It does not solve the diff-transparency problem, however, which I consider the more important problem.
but Wikidata wouldn't be pressured to do this until Wikipedia changed the way it renders templates.
I am not trying to pressure you or make war on you.
I prefer to believe we both are on the side of discussing how as many contributors as possible are motivated to contribute to the growing commons of Wikipedia and Wikidata, and how the quality of it can best be upheld.
Gregor
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Le 2013-04-06 20:31, Luca Martinelli a écrit :
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... :)
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&quicks...
2013/4/8 Mathieu Stumpf psychoslave@culture-libre.org:
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"?
Well, *of course* we use to reach consensus *before* changing templates. I thought it was a given point, since we're no different from any other WP community. :)
And yes, nobody complained because discussions about changing a template are long, and thorough, and sometimes even frustrating. :) Usually, we even update data here contained while changing the templates...
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* - that we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be easier with Wikidata. I wouldn't have been its main sponsor in it.wp, if it wasn't for this.
Le 2013-04-08 15:02, Luca Martinelli a écrit :
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* - that we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be easier with Wikidata. I wouldn't have been its main sponsor in it.wp, if it wasn't for this.
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.
2013/4/8 Mathieu Stumpf psychoslave@culture-libre.org:
Le 2013-04-08 15:02, Luca Martinelli a écrit :
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* - that we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be easier with Wikidata. I wouldn't have been its main sponsor in it.wp, if it wasn't for this.
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.
Ok, I give up. Ask the devs to solve this problem, open a bug about it, whatever.
For the records I *do not* see as a problem as of now, since IMVHO we've got other priorities to deal with - first of all: filling the items with statements, and possibly completing the statements with sources, in order to make the data on Wikidata usable on Wikipedia.
Le 2013-04-08 15:54, Luca Martinelli a écrit :
2013/4/8 Mathieu Stumpf psychoslave@culture-libre.org:
Le 2013-04-08 15:02, Luca Martinelli a écrit :
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* - that we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be easier with Wikidata. I wouldn't have been its main sponsor in it.wp, if it wasn't for this.
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.
Ok, I give up. Ask the devs to solve this problem, open a bug about it, whatever.
Sorry, I didn't want to upset anyone.
For the records I *do not* see as a problem as of now, since IMVHO we've got other priorities to deal with - first of all: filling the items with statements, and possibly completing the statements with sources, in order to make the data on Wikidata usable on Wikipedia.
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
Venezuela is electing a new president in about a week. I went ahead and switched the Italian article to use the Wikidata property so we might be able to capture a good example there.
Date: Mon, 8 Apr 2013 16:24:49 +0200 From: psychoslave@culture-libre.org To: wikidata-l@lists.wikimedia.org; wikitech-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
Le 2013-04-08 15:54, Luca Martinelli a écrit :
2013/4/8 Mathieu Stumpf psychoslave@culture-libre.org:
Le 2013-04-08 15:02, Luca Martinelli a écrit :
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* - that we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be easier with Wikidata. I wouldn't have been its main sponsor in it.wp, if it wasn't for this.
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.
Ok, I give up. Ask the devs to solve this problem, open a bug about it, whatever.
Sorry, I didn't want to upset anyone.
For the records I *do not* see as a problem as of now, since IMVHO we've got other priorities to deal with - first of all: filling the items with statements, and possibly completing the statements with sources, in order to make the data on Wikidata usable on Wikipedia.
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
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Le 2013-04-09 20:44, Michael Hale a écrit :
Venezuela is electing a new president in about a week. I went ahead and switched the Italian article to use the Wikidata property so we might be able to capture a good example there.
Could you please provide the relevant URL?
thank you :)
Date: Mon, 8 Apr 2013 16:24:49 +0200 From: psychoslave@culture-libre.org To: wikidata-l@lists.wikimedia.org; wikitech-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
Le 2013-04-08 15:54, Luca Martinelli a écrit :
2013/4/8 Mathieu Stumpf psychoslave@culture-libre.org:
Le 2013-04-08 15:02, Luca Martinelli a écrit :
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* -
that
we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be
easier
with Wikidata. I wouldn't have been its main sponsor in it.wp,
if
it wasn't for this.
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.
Ok, I give up. Ask the devs to solve this problem, open a bug
about
it, whatever.
Sorry, I didn't want to upset anyone.
For the records I *do not* see as a problem as of now, since IMVHO we've got other priorities to deal with - first of all: filling
the
items with statements, and possibly completing the statements with sources, in order to make the data on Wikidata usable on
Wikipedia.
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
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
http://it.wikipedia.org/wiki/Venezuela
On Wed, Apr 10, 2013 at 8:46 AM, Mathieu Stumpf psychoslave@culture-libre.org wrote:
Le 2013-04-09 20:44, Michael Hale a écrit :
Venezuela is electing a new president in about a week. I went ahead and switched the Italian article to use the Wikidata property so we might be able to capture a good example there.
Could you please provide the relevant URL?
thank you :)
Date: Mon, 8 Apr 2013 16:24:49 +0200 From: psychoslave@culture-libre.org To: wikidata-l@lists.wikimedia.org; wikitech-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
Le 2013-04-08 15:54, Luca Martinelli a écrit :
2013/4/8 Mathieu Stumpf psychoslave@culture-libre.org:
Le 2013-04-08 15:02, Luca Martinelli a écrit :
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* - that we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be easier with Wikidata. I wouldn't have been its main sponsor in it.wp, if it wasn't for this.
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.
Ok, I give up. Ask the devs to solve this problem, open a bug about it, whatever.
Sorry, I didn't want to upset anyone.
For the records I *do not* see as a problem as of now, since IMVHO we've got other priorities to deal with - first of all: filling the items with statements, and possibly completing the statements with sources, in order to make the data on Wikidata usable on Wikipedia.
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
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Association Culture-Libre http://www.culture-libre.org/
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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%22Presidente: Nicolas Maduro" is now being pulled from Wikidata.
Date: Wed, 10 Apr 2013 08:46:41 +0200 From: psychoslave@culture-libre.org To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
Le 2013-04-09 20:44, Michael Hale a écrit :
Venezuela is electing a new president in about a week. I went ahead and switched the Italian article to use the Wikidata property so we might be able to capture a good example there.
Could you please provide the relevant URL?
thank you :)
Date: Mon, 8 Apr 2013 16:24:49 +0200 From: psychoslave@culture-libre.org To: wikidata-l@lists.wikimedia.org; wikitech-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
Le 2013-04-08 15:54, Luca Martinelli a écrit :
2013/4/8 Mathieu Stumpf psychoslave@culture-libre.org:
Le 2013-04-08 15:02, Luca Martinelli a écrit :
What I tried to say is: we don't mind if we go back in a page history and find a red link to a template, nobody cares, because we all know that a template has been deleted/substituted *for a reason* -
that
we even discussed for a VERY long time. What we DO care is that the article has *right now* the correct data - and this will be
easier
with Wikidata. I wouldn't have been its main sponsor in it.wp,
if
it wasn't for this.
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.
Ok, I give up. Ask the devs to solve this problem, open a bug
about
it, whatever.
Sorry, I didn't want to upset anyone.
For the records I *do not* see as a problem as of now, since IMVHO we've got other priorities to deal with - first of all: filling
the
items with statements, and possibly completing the statements with sources, in order to make the data on Wikidata usable on
Wikipedia.
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
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Association Culture-Libre http://www.culture-libre.org/
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
2013/4/9 Michael Hale hale.michael.jr@live.com:
Venezuela is electing a new president in about a week. I went ahead and switched the Italian article to use the Wikidata property so we might be able to capture a good example there.
+1, in this way we can discuss about actual data and move from there. Good idea. :)
Le 2013-04-05 23:19, Michael Hale a écrit :
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.
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.
To enable the scenario you describe with wiki markup syntax would require something like
{{#property:population|values_revisions=300000000,1739242,280000000,1344282}},
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.
"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." "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."
Date: Mon, 8 Apr 2013 11:07:21 +0200 From: psychoslave@culture-libre.org To: wikidata-l@lists.wikimedia.org Subject: Re: [Wikidata-l] Page history and properties
Le 2013-04-05 23:19, Michael Hale a écrit :
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.
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.
To enable the scenario you describe with wiki markup syntax would require something like
{{#property:population|values_revisions=300000000,1739242,280000000,1344282}},
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/
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Le 2013-04-05 22:22, Gregor Hagedorn a écrit :
On 5 April 2013 21:41, Michael Hale hale.michael.jr@live.com wrote:
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?
It makes changes visible in the present wikitext diff and allows to render the past version easily to a correct value. It is not meant as a perfect solution to all, but as an option for an editing community to enable them to chose between keeping the information visible and traceable in the Wikidata diff. I agree about the disadvantages of "clutter", but the point is that is does allow a community to choose that they don't like clutter and don't need the history and diffs, and simple create the property functions inside the templates (with no tracking). This would indeed show the changes in the present diff and it would allow several years into the future to reasonably understand (in wikitext) and render (as html) previous states of wikipedia articles several years into the past.
However, better solutions are certainly possible. Based on what you write I can imagine an editing workflow diff similar to the stacking of diffs, but actually reduced to a link pointing to Wikidata. The features I view as important are:
- In the history, Wikidata changes for a topic are made visiable
durign the the display of Wikipedia-Wikitext changes. Ideally multiple Wikidata edits could be merged into a single line if no Wikitext changes occur in between. There could be options to hide Wikidata changes. The "how" is not so important, but I think the present watchlist implementation is insufficient, because it generates an "attention" message, but makes it hard to follow up (which usually occurs in the page history + diff).
- In the actual diff, instead of stacking the Wikitext + Wikidata
property diffs, I could imagine that a solution that at the bottom says: "Associated Wikidata properties changed in the choosen period." Where choosen period is the period chosen for the diff by the editor and where the whole is linked to a Wikidata diff. Present Wikipedia communication practice heavily relies on pointing to specific history diffs (through links), but currently Wikidata changes are completely invisible there. By automatically "linking them in" present practice could continue smoothly and non-disruptive.
- Ideally, the Wikidata diff link should have option to hide the
"Wikidata internal" properties like changes in item labels, and should show language specific changes only for a specific language, to keep the attention of content editors focussed on the relevant changes (most likely Wikidata will still show more properties than those used on the wikipedia page, but this could be acceptable).
To be sure I undestood what you say, wouldn't it resume as a "show/hide wikidata changes" checkbox in the page history, just as it's done with bots and so on?
Ah, beware of the ---- which is broadly used as a "bellow is my signature, the text you don't care and won't read unless you really have to"
The question of rendering the html for past versions is separate. You seem to say that it is already easy to write the #property: function such that it takes into account the edit timestamp of a wikipedia page version and evaluates the property as it was at that point in time (with the current version (ie. when called without a pageid) always evaluating to now(), not the last editing timestamp.
ASIDE: I don't worry too much if a property is being referenced by name or ID in a past version and has since been deleted, the resulting error message is transparent rather than misleading (which the display of "wrong" information is).
Gregor
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l