Basically I am with Sabine and support the idea.
Yet I want to warn against doing it now and doing it quickly so as
to avoid certain pitfalls.
I suggest, rather to develop & train bots, data, and algorithms
with the test wikipedia only, for the time being, where spefic
situations can easily be (re)created without risk of havoc.
What follows are details and reasons, you can safely stop reading
here if not interested.
I've been mass inserting data in the ripuarian test wikipedia at
a semi autmated level, which I created from several small database
like collections, such as:
- names, and ISO codes of languages having Wikipedias,
- dates and mottos of carnival parades in the city of cologne of
the last 185 years.
- redirects for dialectal, and spelling variants
- etc.
So I've (limited) experience.
Pitfalls to be avoided.
----------------------
If we have inserted data in a WP already, and later a refined
version of that data becomes available, we want to pass that
to the WP. This becomes complicated when an article already
exists for a record. Thus we may strategically choose to export
data as late as possible, at an as complete state as possible,
when general additions and amendments have become unlikely, and
the data structure is stable.
We can safely replace articles, when we can determine that they
have been unaltered since our own last update - i.e. we need to be
able to look at the version history for those cases.
When an article has been conventionally updated by an editor, that
may mean, he altered data, which we originally supplied, and that
we have to update our source before we may re-exort data to
WPs again. It is possible, that an update made in one WP shall
influence others as well, though this is not neccessarily so.
When we say, we supply only some specific data to an article, e.g.
an infobox, then we can reread the infobox, and if it has not
been altered, we can rewrite it for an update.
We can also use such infoboxes to import new data from WPs, when
they have been altered, e.g. someone died. We should have, however,
some protection agains collecting errors, garbage, and vandal drivel.
Both such uses should imho be documented by comments in the
wikicode of the articles in question. Editors must know of the
implications of their edits.
Summarizing all this, I'd suggest to carefulls plan, and test
drive, all aplications having the least chance to be more than
sheer article-creation-and-the-leave-it-alone-forever projects.
Language.
--------
Another field needing attention is language.
A pretty huge number of names (of persons, places, langages, etc.)
are identical between languages, or are transliterated somehow, or
undergo systematic transformations (e.g. of the kind that Estonian
versions of male names have 'as' appended to them, afaik) etc.
The rule of thumb is that for lesser-known distant things (places,
languages, persons, etc.) the existance of special or irregular
translations is very unlikely.
That may mean, we can compile a set of transformation rules, and
an exception lookup mechanism (e.g. in WiktionaryZ) and pretty
well assume, when exceptions are not found, that we can use the
rules.
Naturally, when this assumption fails, we need to have a feedback
path from the respective language community, that allows us to
"repair" errors. Since in most Wikipedias there are editors
reviewing all, or most, new articles, we can assume feedback to be
rather quick and reliable.
Finding the right, grammar, wording etc. for automatically
generated non-tabular content is quite an interesting task which
I'll not address here any further ;-)
Community aspects.
-----------------
Wikies not having alert proofreaders should imho not be filled
with much automated content, since this might be a remarkable
hindrance for community buildup.
The amount of newly inserted automated data should be determinable
by wiki admins, and generally it might be wise to make it somehow
related to the number of edits of any given time period, so as not
to overload the community.
How wiki admins find the right figures should imho be left to
them, valid suggestion might be by public voting, or taken from
experience of how thoroughly data can be verified.
Alo, keeping data up to date needs imho to be negotiated with the
communities. I bet, we'll receive several interesting ideas of how
this could be accomplished without interfering with potential
human editors too much.
Greetings to all
Purodha
-- e-mail: <wikidata-l.mail.wikimedia.org(a)publi.purodha.net>