subject:"\[Wikidata\-l\] Page history and properties"


Le 2013-04-08 15:54, Luca Martinelli a écrit :

2013/4/8 Mathieu Stumpf :

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

Re: [Wikidata-l] Page history and properties

2013-04-08 Thread Luca Martinelli

2013/4/8 Mathieu Stumpf :
> 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.

-- 
Luca "Sannita" Martinelli
http://it.wikipedia.org/wiki/Utente:Sannita

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties


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.


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

Re: [Wikidata-l] Page history and properties

2013-04-08 Thread Luca Martinelli

2013/4/8 Mathieu Stumpf :
> 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.

-- 
Luca "Sannita" Martinelli
http://it.wikipedia.org/wiki/Utente:Sannita

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

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&quicksearch=template+deleted&button=

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

Re: [Wikidata-l] Page history and properties

2013-04-08 Thread Michael Hale

"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: psychosl...@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=3,1739242,28000,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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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=3,1739242,28000,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

Re: [Wikidata-l] Page history and properties


Le 2013-04-05 22:22, Gregor Hagedorn a écrit :

On 5 April 2013 21:41, Michael Hale  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=30900}}

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



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


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

Re: [Wikidata-l] Page history and properties

2013-04-06 Thread Michael Hale

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.haged...@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  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=30900}}
> 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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

2013-04-06 Thread Gregor Hagedorn

On 6 April 2013 23:05, Michael Hale  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=30900}}
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

Re: [Wikidata-l] Page history and properties

2013-04-06 Thread Michael Hale

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.haged...@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=30900}}) 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=30900}}
> 
> 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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

2013-04-06 Thread Gregor Hagedorn

> This is great, but the solution I saw (i.e.
> {{#property:population|current-value=30900}}) 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=30900}}

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

Re: [Wikidata-l] Page history and properties

2013-04-06 Thread Luca Martinelli

2013/4/6 Gregor Hagedorn :
[...]
> 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=30900}}) makes the whole
Wikidata absolutely useless. The changes in wikidata items are already
visible in users' watchlist, and if I'm not mistaken even in recent
changes.

I'm sorry, but I do agree with Michael: we need to focus primarily on
importing data and their references and then adapting the templates.
This is the reason why Wikidata has been put up: to make data storage,
editing, and even creating new articles easier.

Plus, just a note about seeing an item as of 2011. If I try to see
what an article looked at that time and if a template in the meantime
has been substituted and deleted, I'd see only a red mark stating
"Template:Whatever" instead of that template. In 12 years, nobody
complained about that... :)

-- 
Luca "Sannita" Martinelli
http://it.wikipedia.org/wiki/Utente:Sannita

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

On 5 April 2013 23:53, Michael Hale  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

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

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.haged...@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  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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

On 5 April 2013 23:19, Michael Hale  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

Re: [Wikidata-l] Page history and properties

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=3,1739242,28000,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.haged...@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  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=30900}}
> > 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 attent

Re: [Wikidata-l] Page history and properties

On 5 April 2013 21:41, Michael Hale  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=30900}}
> 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

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

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=30900}} people." Which scenarios 
does that improve?

> From: g.m.haged...@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  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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

On 5 April 2013 20:05, Michael Hale  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

Re: [Wikidata-l] Page history and properties

Oh, nice.

> From: lydia.pintsc...@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  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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Lydia Pintscher

On Fri, Apr 5, 2013 at 8:05 PM, Michael Hale  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

Re: [Wikidata-l] Page history and properties

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.haged...@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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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

Re: [Wikidata-l] Page history and properties

2013-04-05 Thread Mathieu Stumpf


Le 2013-04-05 09:32, Gregor Hagedorn a écrit :

On 4 April 2013 22:23, Michael Hale  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.


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

[Wikidata-l] Page history and properties

2013-04-05 Thread Andrew Gray

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
>

-- 
- Andrew Gray
  andrew.g...@dunelm.org.uk

Re: [Wikidata-l] Page history and properties

On 4 April 2013 22:23, Michael Hale  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

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

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: bene...@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: bene...@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: bene...@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 articl

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: bene...@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: bene...@zedat.fu-berlin.de <mailto:bene...@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


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

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: bene...@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: bene...@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

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: bene...@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

Re: [Wikidata-l] Page history and properties

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: bene...@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

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

Re: [Wikidata-l] Page history and properties

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.haged...@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
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Page history and properties

2013-04-04 Thread Gregor Hagedorn

> 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

Re: [Wikidata-l] Page history and properties

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: bene...@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 = 99 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.
> >
> >

Re: [Wikidata-l] Page history and properties