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(a)gmail.com
Date: Fri, 5 Apr 2013 22:22:06 +0200
To: wikidata-l(a)lists.wikimedia.org
Subject: Re: [Wikidata-l] Page history and properties
On 5 April 2013 21:41, Michael Hale <hale.michael.jr(a)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
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l