[Wikidata] (Ab)use of "deprecated"

[Markus Kroetzsch]

Dear all,

As you may know, statements in Wikidata can be marked as "preferred" or 
"deprecated" to distinguish them from the "normal" ones.


I found that many items have perfectly valid historical statements 
marked as "deprecated". For example, our showcase item "Kleinmachnow"


https://www.wikidata.org/wiki/Q104192

has a statement "population: 20,086 (point in time: 2011)" that is 
confirmed by a reference. Nevertheless, the statement is marked as 
"deprecated". This would mean that the statement "the popluation was 
20,086 in 2011" is wrong. As far as I can tell, this is not the case.


It seems that somebody wanted to indicate that this old population is no 
longer current. This is achieved not by deprecating the old value, but 
by setting another (newer) value as "preferred".


Similar problems occur for the mayor of this town.

I hope there is no deeper confusion in the community regarding this 
intended use of "preferred" and "deprecated". Most other items are using 
it correctly, it seems. The fact that it occurs in a showcase item is 
still making me a bit concerned.


Cheers,

Markus



--
Prof. Dr. Markus Kroetzsch
Knowledge-Based Systems Group
Faculty of Computer Science
TU Dresden
+49 351 463 38486
https://iccl.inf.tu-dresden.de/web/KBS/en

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

Re: [Wikidata] Breaking change in JSON serialization?

[Markus Kroetzsch]

Dear all,

There have been some interesting discussions about breaking changes 
here, but before we continue in this direction, let me repeat that I did 
not start this thread to define what is a "breaking change" in JSON. 
There are JSON libraries that define this in a strict way (siding with 
Peter) and browsers that are more tolerant (siding with Daniel). I don't 
think we can come to definite conclusions here. Format versioning, as 
Stas suggests, can't be a bad thing.


However, all I was asking for was to get a little email when JSON is 
changed. It is not necessary to discuss if this is really necessary due 
to some higher principle. Even if my software tolerates the change, I 
should *always* know about new information being available. It is 
usually there for a purpose, so my software should do better than "not 
breaking".


Lydia has already confirmed early on that suitable notification emails 
should be sent in the future, so I don't see a need to continue this 
particular discussion. Daniel's position seemed to be a mix of "I told 
you so" and "you volunteers should write better code", which is of 
little help to me or my users. It would be good to rethink how to 
approach the community in such cases, to make sure that a coherent and 
welcoming message is sent to contributors. (On that note, all the best 
on your new job, Léa! -- communicating with this crowd can be a 
challenge at times ;-).


Markus


On 11.08.2016 22:35, Stas Malyshev wrote:

Hi!


My view is that this tool should be extremely cautious when it sees new data
structures or fields.  The tool should certainly not continue to output
facts without some indication that something is suspect, and preferably
should refuse to produce output under these circumstances.


I don't think I agree. I find tools that are too picky about details
that are not important to me hard to use, and I'd very much prefer a
tool where I am in control of which information I need and which I don't
need.


What can happen if the tool instead continues to operate without complaint
when new data structures are seen?  Consider what would happen if the tool
was written for a version of Wikidata that didn't have rank, i.e., claim
objects did not have a rank name/value pair.  If ranks were then added,
consumers of the output of the tool would have no way of distinguishing
deprecated information from other information.


Ranks are a bit unusual because ranks are not just informational change,
it's a semantic change. It introduces a concept of a statement that has
different semantics than the rest. Of course, such change needs to be
communicated - it's like I would make format change "each string
beginning with letter X needs to be read backwards" but didn't tell the
clients. Of course this is a breaking change if it changes semantics.

What I was talking are changes that don't break semantics, and majority
of additions are just that.


Of course this is an extreme case.  Most changes to the Wikidata JSON dump
format will not cause such severe problems.  However, given the current
situation with how the Wikidata JSON dump format can change, the tool cannot
determine whether any particular change will affect the meaning of what it
produces.  Under these circumstances it is dangerous for a tool that
extracts information from the Wikidata JSON dump to continue to produce
output when it sees new data structures.


The tool can not. It's not possible to write a tool that would derive
semantics just from JSON dump, or even detect semantic changes. Semantic
changes can be anywhere, it doesn't have to be additional field - it can
be in the form of changing the meaning of the field, or format, or
datatype, etc. Of course the tool can not know that - people should know
that and communicate it. Again, that's why I think we need to
distinguish changes that break semantics and changes that don't, and
make the tools robust against the latter - but not the former because
it's impossible. For dealing with the former, there is a known and
widely used solution - format versioning.


This does make consuming tools sensitive to changes to the Wikidata JSON
dump format that are "non-breaking".  To overcome this problem there should
be a way for tools to distinguish changes to the Wikidata JSON dump format
that do not change the meaning of existing constructs in the dump from those
that can.  Consuming tools can then continue to function without problems
for the former kind of change.


As I said, format versioning. Maybe even semver or some suitable
modification of it. RDF exports BTW already carry version. Maybe JSON
exports should too.




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

Re: [Wikidata] Breaking change in JSON serialization?

[Peter F. Patel-Schneider]

On 08/11/2016 01:35 PM, Stas Malyshev wrote:
> Hi!
> 
>> My view is that this tool should be extremely cautious when it sees new data
>> structures or fields.  The tool should certainly not continue to output
>> facts without some indication that something is suspect, and preferably
>> should refuse to produce output under these circumstances.
> 
> I don't think I agree. I find tools that are too picky about details
> that are not important to me hard to use, and I'd very much prefer a
> tool where I am in control of which information I need and which I don't
> need.

My point is that the tool has no way of determining what is important and what
is not important, at least under the current state of affairs with respect to
the Wikidata JSON dump.  Given this, a tool that ignores what could easily be
an important change is a dangerous tool.

>> What can happen if the tool instead continues to operate without complaint
>> when new data structures are seen?  Consider what would happen if the tool
>> was written for a version of Wikidata that didn't have rank, i.e., claim
>> objects did not have a rank name/value pair.  If ranks were then added,
>> consumers of the output of the tool would have no way of distinguishing
>> deprecated information from other information.
> 
> Ranks are a bit unusual because ranks are not just informational change,
> it's a semantic change. It introduces a concept of a statement that has
> different semantics than the rest. Of course, such change needs to be
> communicated - it's like I would make format change "each string
> beginning with letter X needs to be read backwards" but didn't tell the
> clients. Of course this is a breaking change if it changes semantics.
> 
> What I was talking are changes that don't break semantics, and majority
> of additions are just that.

Yes, the majority of changes are not of this sort, but tools currently can't
determine which changes are of this sort and which are not.

>> Of course this is an extreme case.  Most changes to the Wikidata JSON dump
>> format will not cause such severe problems.  However, given the current
>> situation with how the Wikidata JSON dump format can change, the tool cannot
>> determine whether any particular change will affect the meaning of what it
>> produces.  Under these circumstances it is dangerous for a tool that
>> extracts information from the Wikidata JSON dump to continue to produce
>> output when it sees new data structures.
> 
> The tool can not. It's not possible to write a tool that would derive
> semantics just from JSON dump, or even detect semantic changes. Semantic
> changes can be anywhere, it doesn't have to be additional field - it can
> be in the form of changing the meaning of the field, or format, or
> datatype, etc. Of course the tool can not know that - people should know
> that and communicate it. Again, that's why I think we need to
> distinguish changes that break semantics and changes that don't, and
> make the tools robust against the latter - but not the former because
> it's impossible. For dealing with the former, there is a known and
> widely used solution - format versioning.

Yes, if a suitable sort of versioning contract was implemented then things
would dramatically change.  Tools could depend on "breaking" changes always
being accompanied by a version bump and then they might be able to ignore new
fields if the version does not change.  However, this is not the current state
of affairs with the Wikidata JSON dump format.

>> This does make consuming tools sensitive to changes to the Wikidata JSON
>> dump format that are "non-breaking".  To overcome this problem there should
>> be a way for tools to distinguish changes to the Wikidata JSON dump format
>> that do not change the meaning of existing constructs in the dump from those
>> that can.  Consuming tools can then continue to function without problems
>> for the former kind of change.
> 
> As I said, format versioning. Maybe even semver or some suitable
> modification of it. RDF exports BTW already carry version. Maybe JSON
> exports should too.

Right.  I'm all for version information being added to the Wikidata JSON dump
format.  It would make the production use of these dumps much safer.

Until suitable versioning is part of the Wikidata JSON dump format and
contract, however, I don't think that consumers of the dumps should just
ignore new fields.


Peter F. Patel-Schneider
Nuance Communcations



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

Re: [Wikidata] (Ab)use of "deprecated"

[Stas Malyshev]

Hi!

> I would argue that this is better done by using qualifiers (e.g. start
> data, end data).  If a statement on the population size would be set to
> preferred, but isn't monitored for quite some time, it can be difficult
> to see if the "preferred" statement is still accurate, whereas a
> qualifier would give a better indication that that stament might need an
> update. 

Right now this bot:
https://www.wikidata.org/wiki/User:PreferentialBot
watches statements like "population" that have multiple values with
different time qualifiers but no current preference.

What it doesn't currently do is to verify that the preferred one refers
to the latest date. It probably shouldn't fix these cases (because there
may be valid cause why the latest is not the best, e.g. some population
estimates are more precise than others) but it can alert about it. This
can be added if needed.

-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikidata] Breaking change in JSON serialization?

[Stas Malyshev]

Hi!

> My view is that this tool should be extremely cautious when it sees new data
> structures or fields.  The tool should certainly not continue to output
> facts without some indication that something is suspect, and preferably
> should refuse to produce output under these circumstances.

I don't think I agree. I find tools that are too picky about details
that are not important to me hard to use, and I'd very much prefer a
tool where I am in control of which information I need and which I don't
need.

> What can happen if the tool instead continues to operate without complaint
> when new data structures are seen?  Consider what would happen if the tool
> was written for a version of Wikidata that didn't have rank, i.e., claim
> objects did not have a rank name/value pair.  If ranks were then added,
> consumers of the output of the tool would have no way of distinguishing
> deprecated information from other information.

Ranks are a bit unusual because ranks are not just informational change,
it's a semantic change. It introduces a concept of a statement that has
different semantics than the rest. Of course, such change needs to be
communicated - it's like I would make format change "each string
beginning with letter X needs to be read backwards" but didn't tell the
clients. Of course this is a breaking change if it changes semantics.

What I was talking are changes that don't break semantics, and majority
of additions are just that.

> Of course this is an extreme case.  Most changes to the Wikidata JSON dump
> format will not cause such severe problems.  However, given the current
> situation with how the Wikidata JSON dump format can change, the tool cannot
> determine whether any particular change will affect the meaning of what it
> produces.  Under these circumstances it is dangerous for a tool that
> extracts information from the Wikidata JSON dump to continue to produce
> output when it sees new data structures.

The tool can not. It's not possible to write a tool that would derive
semantics just from JSON dump, or even detect semantic changes. Semantic
changes can be anywhere, it doesn't have to be additional field - it can
be in the form of changing the meaning of the field, or format, or
datatype, etc. Of course the tool can not know that - people should know
that and communicate it. Again, that's why I think we need to
distinguish changes that break semantics and changes that don't, and
make the tools robust against the latter - but not the former because
it's impossible. For dealing with the former, there is a known and
widely used solution - format versioning.

> This does make consuming tools sensitive to changes to the Wikidata JSON
> dump format that are "non-breaking".  To overcome this problem there should
> be a way for tools to distinguish changes to the Wikidata JSON dump format
> that do not change the meaning of existing constructs in the dump from those
> that can.  Consuming tools can then continue to function without problems
> for the former kind of change.

As I said, format versioning. Maybe even semver or some suitable
modification of it. RDF exports BTW already carry version. Maybe JSON
exports should too.
-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikidata] (Ab)use of "deprecated"

[Markus Kroetzsch]

On 11.08.2016 18:45, Andra Waagmeester wrote:

On Thu, Aug 11, 2016 at 4:15 PM, Markus Kroetzsch
mailto:markus.kroetz...@tu-dresden.de>>
wrote:


has a statement "population: 20,086 (point in time: 2011)" that is
confirmed by a reference. Nevertheless, the statement is marked as
"deprecated". This would mean that the statement "the popluation was
20,086 in 2011" is wrong. As far as I can tell, this is not the case.


I wouldn't say that with a deprecated rank, that statement is "wrong". I
consider de term deprecated to indicate that a given statement is no
longer valid in the context of a given resource (reference). I agree, in
this specific case the use of the deprecated rank is wrong, since no
references are given to that specific statement.
Nevertheless, I think it is possible to have disagreeing resources on an
identical statement, where two identical statements exists, one with
rank "deprecated" and one with rank "normal". It is up to the user to
decide which source s/he trusts.


The status "deprecated" is part of the claim of the statement. The 
reference is supposed to support this claim, which in this case is also 
the claim that it is deprecated. The status is not meant to deprecate a 
reference (not saying that this is never useful, potentially, but you 
can only use it in one way, and it seems much more practical if 
deprecated statements get references that explain why they are deprecated).






It seems that somebody wanted to indicate that this old population
is no longer current. This is achieved not by deprecating the old
value, but by setting another (newer) value as "preferred".


I would argue that this is better done by using qualifiers (e.g. start
data, end data).  If a statement on the population size would be set to
preferred, but isn't monitored for quite some time, it can be difficult
to see if the "preferred" statement is still accurate, whereas a
qualifier would give a better indication that that stament might need an
update.


Sure, there should always be qualifiers as needed, and we already have 
qualifiers like start and end date in most cases. However, one should 
still set the "best" statemnt(s) to be preferred as a help for users of 
the data. When you use date in queries or in LUA, it would be very hard 
to analyse all statements' qualifiers to find out which one is currently 
the best. The "preferred" rank gives a simple shortcut there. In SPARQL, 
for example, the best ranked statements will be used in the simplified 
"direct" properties in namespace wdt: Users who want to get all the 
details can still use the qualifiers, but this leads to more complicated 
queries.


Best regards,

Markus



Cheers,

Andra



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




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

Re: [Wikidata] ArticlePlaceholder is now live on Welsh and Kannada Wikipedia

[Info WorldUniversity]

Great, Lydia, Lucie and All,

Thanks for these important ArticlePlaceholder developments. What are
further steps ahead for Content Translation in these regards? For example,
how best to chart out a possible path to an Universal Translator in
Wikipedia's 358 languages from where we are now? What's needed next after
these developments?

Thank you,
Scott



On Thu, Aug 11, 2016 at 1:13 AM, Gerard Meijssen 
wrote:

> Hoi,
> As to search, Magnus already did that over a year ago.
> Thanks,
>   GerardM
>
> On 10 August 2016 at 18:56, Lydia Pintscher 
> wrote:
>
>> Hey folks :)
>>
>> Just a quick note that we have now rolled out the ArticlePlaceholder
>> on Welsh and Kannada Wikipedia as well. Both project had requested it.
>> Here are 2 example pages:
>> * https://kn.wikipedia.org/wiki/%E0%B2%B5%E0%B2%BF%E0%B2%B6%E0
>> %B3%87%E0%B2%B7:AboutTopic/Q1459
>> * https://cy.wikipedia.org/wiki/Arbennig:AboutTopic/Q2673
>>
>> We are continuing to work on improving it based on the feedback we've
>> gotten so far from the projects that already have it. This includes
>> layout fixes, making it possible to translate an article from another
>> language using the ContentTranslation tool and getting them to show up
>> in search engine results.
>>
>>
>> Cheers
>> Lydia
>>
>> --
>> Lydia Pintscher - http://about.me/lydia.pintscher
>> Product Manager for Wikidata
>>
>> Wikimedia Deutschland e.V.
>> Tempelhofer Ufer 23-24
>> 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/029/42207.
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>


-- 

- Scott MacLeod - Founder & President

- http://worlduniversityandschool.org

- 415 480 4577

- PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516

- World University and School - like Wikipedia with best STEM-centric
OpenCourseWare - incorporated as a nonprofit university and school in
California, and is a U.S. 501 (c) (3) tax-exempt educational organization.


World University and School is sending you this because of your interest in
free, online, higher education. If you don't want to receive these, please
reply with 'unsubscribe' in the body of the email, leaving the subject line
intact. Thank you.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] (Ab)use of "deprecated"

[Andra Waagmeester]

On Thu, Aug 11, 2016 at 4:15 PM, Markus Kroetzsch <
markus.kroetz...@tu-dresden.de> wrote:

>
> has a statement "population: 20,086 (point in time: 2011)" that is
> confirmed by a reference. Nevertheless, the statement is marked as
> "deprecated". This would mean that the statement "the popluation was 20,086
> in 2011" is wrong. As far as I can tell, this is not the case.
>

I wouldn't say that with a deprecated rank, that statement is "wrong". I
consider de term deprecated to indicate that a given statement is no longer
valid in the context of a given resource (reference). I agree, in this
specific case the use of the deprecated rank is wrong, since no references
are given to that specific statement.
Nevertheless, I think it is possible to have disagreeing resources on an
identical statement, where two identical statements exists, one with rank
"deprecated" and one with rank "normal". It is up to the user to decide
which source s/he trusts.


>
> It seems that somebody wanted to indicate that this old population is no
> longer current. This is achieved not by deprecating the old value, but by
> setting another (newer) value as "preferred".
>

I would argue that this is better done by using qualifiers (e.g. start
data, end data).  If a statement on the population size would be set to
preferred, but isn't monitored for quite some time, it can be difficult to
see if the "preferred" statement is still accurate, whereas a qualifier
would give a better indication that that stament might need an update.

Cheers,

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

[Wikidata] Job Vacancy Textmining, Hannover

[christian.wartena]

Dear all,

we have a vacancy in our group  on text mining in Open Access publications.  
The results of the text mining process will be stored using Wikidata 
infrastructure. The position is for three years with a possibility of extension.

The Job is part of a new project "NOA - The replication of open access images: 
development of a method for automatic harvesting, indexing and provision of 
open access images from technical subjects using the infrastructure of 
Wikimedia Commons and Wikidata".

You will part of a dynamic international team at the Hochschule Hannover. 
Hannover is a large and central city  in Germany with a number of universities 
and research institutes. Basic knowledge of German is an advantage but not 
strictly necessary. For full details, please, refer to: 
http://www.hs-hannover.de/dezernat-i-personal-und-organisation/personalangelegenheiten/stellenausschreibungen/sonstige-stellen/index.html#c65180

Please note that applications should be send before 19th August 2016!

For any questions about the project and the job, please contact me.

I'm looking forward to all questions and applications!

Best,

Christian


Prof. Dr. Christian Wartena
Hochschule Hannover
Fakultät III - Medien, Information und Design
Abt. Information und Kommunikation
Lehrgebiet Sprach- und Wissensverarbeitung
Studiengangskoordinator Bachelor Informationsmanagement (BIM)

Expo Plaza 12
30539 Hannover
e-mail: 
christian.wart...@hs-hannover.de
Tel: +49 (0)511 9296 2594





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

Re: [Wikidata] (Ab)use of "deprecated"

[Lydia Pintscher]

On Thu, Aug 11, 2016 at 4:15 PM, Markus Kroetzsch
 wrote:
> Dear all,
>
> As you may know, statements in Wikidata can be marked as "preferred" or
> "deprecated" to distinguish them from the "normal" ones.
>
> I found that many items have perfectly valid historical statements marked as
> "deprecated". For example, our showcase item "Kleinmachnow"
>
> https://www.wikidata.org/wiki/Q104192
>
> has a statement "population: 20,086 (point in time: 2011)" that is confirmed
> by a reference. Nevertheless, the statement is marked as "deprecated". This
> would mean that the statement "the popluation was 20,086 in 2011" is wrong.
> As far as I can tell, this is not the case.
>
> It seems that somebody wanted to indicate that this old population is no
> longer current. This is achieved not by deprecating the old value, but by
> setting another (newer) value as "preferred".
>
> Similar problems occur for the mayor of this town.
>
> I hope there is no deeper confusion in the community regarding this intended
> use of "preferred" and "deprecated". Most other items are using it
> correctly, it seems. The fact that it occurs in a showcase item is still
> making me a bit concerned.

At least on this item they were set by a now inactive user. Do you
have more items to see if it is the same user there? Can someone fix
the ranks in that item please?

https://www.wikidata.org/wiki/Help:Ranking seems fine wrt deprecated
rank and I've not seen much confusion around it.


Cheers
Lydia

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata

Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
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/029/42207.

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

Re: [Wikidata] Controversy around Wikimania talks

[Andy Mabbett]

On 11 August 2016 at 12:57, David Cuenca Tudela  wrote:

>> what is the function of all the policies when they so obviously are hardly
>> worth the bits they consist of.
>
> Policies are not commands that have to be blindly obeyed. They are a general
> framework for the admins and users to approach the blurry or defined limits,
> but of course some autonomy is needed to decide in edge or uncertain cases.
> That means to take decisions that eventually will make some people (like you
> in this case) unhappy.

That is all well and good, but when an admin is challenged over an
inappropriate use of their tools, by members of the community in good
standing, and acting in good faith, and asked to reinstate
unilaterally- and speedily- deleted items and nominate them for a
deletion discussion involving the wider community, they should not
refuse to do unless there is a policy that gives support for their
actions.

In this case, there is none, and furthermore none has even been claimed.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Wikidata] Controversy around Wikimania talks

[Luca Martinelli]

I kindly ask to stop this discussion here, and to discuss the relevant
topics in the relevant places - on Wikidata, on Meta, or wherever you
feel like it, just not here.

Thank you.

L.

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

Re: [Wikidata] Controversy around Wikimania talks

[Gerard Meijssen]

Hoi,
I do not care for "policies" that are only there for some and not for
others. I do not care to be told that I am wrong because of the policy and
at the same time to notice that policies are arbitrarily enforced. This is
not one such situation. One person who has the power deleted many items and
might proves right.

This is NOT about wishing for policies. It is to indicate that as it is
policies are not for everyone. THAT is what is wrong because it removes the
legitimacy of any and all policies and it removes any reason to accept what
an administrator has to say. To make things worse arguments are not what
makes for this situation, the arguments have not been mine. It is what
other people had to say. My question I am left with is plain, why respect
administrators, why respect policies?
Thanks,
  GerardM

On 11 August 2016 at 13:57, David Cuenca Tudela  wrote:

> > what is the function of all the policies when they so obviously are
> hardly worth the bits they consist of.
>
> Policies are not commands that have to be blindly obeyed. They are a
> general framework for the admins and users to approach the blurry or
> defined limits, but of course some autonomy is needed to decide in edge or
> uncertain cases. That means to take decisions that eventually will make
> some people (like you in this case) unhappy.
>
> I generally prefer to have admins with more autonomy than with less, more
> specifically because when there are less regulations the type of people
> involved tend to create in general a more amiable climate, and I think that
> has been the case so far for Wikidata. If you are complaining about the
> health of the community, then you should be careful with the things you
> seem to wish for (regulations, processes, etc), because it can backfire and
> have the opposite effect.
>
> OTOH, if Commons is going to have its own structured database and those
> items might qualify there with less opposition, why to make such a big deal
> about it?
>
>
> Regards,
> Micru
>
>
>
> On Thu, Aug 11, 2016 at 1:05 PM, Gerard Meijssen <
> gerard.meijs...@gmail.com> wrote:
>
>> Hoi,
>> What is trivial. I find that the disappointment in what our policies
>> bring us amounts to a lot. Effectively it is only who you are that
>> determines what you get away with. The quality of arguments are easily
>> dismissed with "I have a different opinion" (that is NOT an argument.
>>
>> When you look at my credentials you will agree that I have been involved
>> heavily in our project and for all the wrong reasons I am disengaging. I
>> object to the way conflicts are handled. I object to the collective shrug
>> of not caring, not wanting to be involved of our admins. In the end it does
>> not matter.
>>
>> Wikidata is a very important project that is underserved in attention to
>> its community. It just sort of happens and the statistics are so good that
>> we do not even look at the relative health of Wikidata as a community.
>>
>> It is one thing for stewards to say what they say, it is one thing for
>> individual administrators to say what they say but when the situation goes
>> rogue, when arguments presented by others do not get the collective
>> attention of the administrative processes that are in place. When the
>> allegation that admins do as they please is just a determination it becomes
>> obvious to raise the question what is the function of all the policies when
>> they so obviously are hardly worth the bits they consist of.
>> Thanks,
>>   GerardM
>>
>> On 1 August 2016 at 02:05, Vi to  wrote:
>>
>>> [Note: I'm using the last message for a cumulative reply]
>>>
>>> Wikidata has 16k active users, 66 admins, 3 'crats, with a pretty active
>>> community. This thread has turned into a weird mix of inclusionism vs.
>>> deletionism catfight + a request to undelete some contents in a specific
>>> project + a series of off-topics. The first part might fit the scope of
>>> this list (though is *so* boring), same for the third one. Instead, the
>>> second part must be discussed on Wikidata following local policies.
>>>
>>> Finally, just to clarify: undeletions by stewards are completely out of
>>> our mission and policies (I, for one, would rather intervene to delete ^^),
>>> same for the staffers. No chances to overrule a community for such trivial
>>> reasons.
>>>
>>> Vito
>>>
>>> 2016-08-01 0:36 GMT+02:00 Info WorldUniversity <
>>> i...@worlduniversityandschool.org>:
>>>
 If, as Jimbo Wales' wrote the purpose of Wikipedia involves imagining
 "a world in which every single person on the planet is given free access to
 the sum of all human knowledge. That's what we're doing.—Jimbo Wales
 [3]
 "
 https://en.wikipedia.org/wiki/Wikipedia:Purpose ...

 and the mission of the Wikimedia Foundation includes:

 "The mission of the Wikimedia Foundation is to empower and engage
 pe

Re: [Wikidata] Breaking change in JSON serialization?

[Peter F. Patel-Schneider]

On 08/05/2016 08:57 AM, Daniel Kinzler wrote:
> Am 05.08.2016 um 17:34 schrieb Peter F. Patel-Schneider:
>> So some additions are breaking changes then.   What is a system that consumes
>> this information supposed to do?  If the system doesn't monitor announcements
>> then it has to assume that any new field can be a breaking change and thus
>> should not accept data that has any new fields.
> 
> The only way to avoid breakage is to monitor announcements. The format is not
> final, so changes can happen (not just additions, but also removals), and then
> things will break if they are unaware. We tend to be careful and conservative,
> and announce any breaking changes in advance, but do not guarantee full
> backwards compatibility forever.
> 
> The only alternative is a fully versioned interface, which we don't currently
> have for JSON, though it has been proposed, see
> .
> 
>> I assume that you are referring to the common practice of adding extra fields
>> in HTTP and email transport and header structures under the assumption that
>> these extra fields will just be passed on to downstream systems and then
>> silently ignored when content is displayed.
> 
> Indeed.
> 
>> I view these as special cases
>> where there is at least an implicit contract that no additional field will
>> change the meaning of the existing fields and data.
> 
> In the name of the Robustness Principle, I would consider this the normal 
> case,
> not the exception.
> 
>> When such contracts are
>> in place systems can indeed expect to see additional fields, and are 
>> permitted
>> to ignore these extra fields.
> 
> Does this count?
> 

This email message is not a contract about how the Wikidata JSON data format
can change.  It instead describes how consumers of that (and other) data are
supposed to act.  My view is that without guarantees of what sort of changes
will be made to the Wikidata JSON data format, these are dangerous behaviours
for its consumers.

>> Because XML specifically states that the order of attributes is not
>> significant.  Therefore changes to the order of XML attributes is not 
>> changing
>> the encoding.
> 
> That's why I'm proposing to formalize the same kind of contract for us, see
> .

This contract guarantees that new fields will not change the interpretation of
pre-existing ones, which is strong, but I don't see where it guarantees that
the meaning of entire structures will not change, which is very weak.

Consider the rank field.  This doesn't change the interpretation of existing
fields.  However, it changes how the entire claim is to be considered.

>> Here is where I disagree.  As there is no contract that new fields in the
>> Wikidata JSON dumps are not breaking, clients need to treat all new fields as
>> potentially breaking and thus should not accept data with unknown fields.
> 
> While you are correct that there is no formal contract yet, the topic had been
> explicitly discussed before, in particular with Markus.
> 
>> I say this for any data, except where there is a contract that such 
>> additional
>> fields are not meaning-changing.
> 
> Quote me on it:
> 
> For wikibase serializations, additional fields are not meaning changing. 
> Changes
> to the format or interpretation of fields will be announced as a breaking 
> change.
> 
>>> Clients need to be prepared to encounter entity types and data types they 
>>> don't
>>> know. But they should also allow additional fields in any JSON object. We
>>> guarantee that extra fields do not impact the interpretation of fields they 
>>> know
>>> about - unless we have announced and documented a breaking change.
>>
>> Is this the contract that is going to be put forward?  At some time in the 
>> not
>> too distant future I hope that my company will be using Wikidata information
>> in its products.  This contract is likely to problematic for development
>> groups, who want some notion how long they have to prepare for changes that
>> can silently break their products.
> 
> This is indeed the gist of what I want to establish as a stability policy.
> Please comment on .
> 
> I'm not sure how this could be made less problematic. Even with a fully
> versioned JSON interface, available data types etc are a matter of
> configuration. All we can do is announce such changes, and advise consumers 
> that
> they can safely ignore unknown things.
> 
> You raise a valid point about due notice. What do you think would be a good
> notice period? Two weeks? A month?

Human-only due notice can only be a part of well-behaved software ecosystem.
Software ends up being used in places separated from its initial developers,
indeed from any developer.  Requiring software to silently accept breaking
additions means that breaking additions will usually break something even with

Re: [Wikidata] Breaking change in JSON serialization?

[Peter F. Patel-Schneider]

My view is that any tool that imports external data has to be very cautious
about additions to the format of that data absent strong guarantees about
the effects of these additions.

Consider a tool that imports the Wikidata JSON dump, extracts base facts
from the dump, and outputs these facts in some other format (perhaps in RDF,
but it doesn't really matter what format).  This tool fits into the
"importing data from [an] external system using a generic exchange format".

My view is that this tool should be extremely cautious when it sees new data
structures or fields.  The tool should certainly not continue to output
facts without some indication that something is suspect, and preferably
should refuse to produce output under these circumstances.

What can happen if the tool instead continues to operate without complaint
when new data structures are seen?  Consider what would happen if the tool
was written for a version of Wikidata that didn't have rank, i.e., claim
objects did not have a rank name/value pair.  If ranks were then added,
consumers of the output of the tool would have no way of distinguishing
deprecated information from other information.

Of course this is an extreme case.  Most changes to the Wikidata JSON dump
format will not cause such severe problems.  However, given the current
situation with how the Wikidata JSON dump format can change, the tool cannot
determine whether any particular change will affect the meaning of what it
produces.  Under these circumstances it is dangerous for a tool that
extracts information from the Wikidata JSON dump to continue to produce
output when it sees new data structures.

This does make consuming tools sensitive to changes to the Wikidata JSON
dump format that are "non-breaking".  To overcome this problem there should
be a way for tools to distinguish changes to the Wikidata JSON dump format
that do not change the meaning of existing constructs in the dump from those
that can.  Consuming tools can then continue to function without problems
for the former kind of change.

Human-only signalling, e.g., an annoucement on some web page, is not
adequate because there is no guarantee that consuming tools will be changed
in response.


Peter F. Patel-Schneider
Nuance Communications

On 08/05/2016 11:56 AM, Stas Malyshev wrote:
> Hi!
> 
>> Consumers of data generally cannot tell whether the addition of a new field 
>> to
>> a data encoding is a breaking change or not.  Given this, code that consumes
>> encoded data should at least produce warnings when it encounters encodings
>> that it is not expecting and preferably should refuse to produce output in
>> such circumstances.  Producers of data thus should signal in advance any
>> changes to the encoding, even if they know that the changes can be safely 
>> ignored.
> 
> I don't think this approach is always warranted. In some cases, yes, but
> in case where you importing data from external system using a generic
> data exchange format like JSON, I don't think this is warranted. This
> will only lead to software being more brittle without any additional
> benefit to the user. Formats like JSON allow to easily accommodate
> backwards-compatible incremental change, so there's no reason not to use
> it.
> 
>> I would view software that consumes Wikidata information and silently ignores
>> fields that it is not expecting as deficient and would counsel against using
>> such software.
> 
> I think this approach is way too restrictive. Wikidata is a database
> that does not have fixed schema, and even its underlying data
> representations are not yet fixed, and probably won't be completely
> fixed for a long time. Having software break each time a field is added
> would lead to a software that breaks often and does not serve its users
> well. You need also to consider that Wikidata is a huge database with a
> very wide mission, and many users may not be interested in all the
> details of the data representation, but only in some aspects of it.
> Having the software refuse to operate on the data that is relevant to
> the user because some part that is not relevant to the user changed does
> not look like the best approach to me.
> 
> For Wikidata specifically I think better approach would be to ignore
> fields, types and other structures that are not known to the software,
> provided that ones that are known do not change their semantics with
> additions - and I understand that's the promise from Wikidata (at least
> excepting cases of specially announced BC-breaking changes). Maybe
> inform the user that some information is not understood and thus may be
> not available, but not refuse to function completely.
> 

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

Re: [Wikidata] Render sparql queries using the Histropedia timeline engine

[Markus Kroetzsch]

On 11.08.2016 13:40, Daniel Kinzler wrote:

Hi Navino!

Thank you for your awesome work!

Since this has caused some confusion again recently, I want to caution you about
a major gotcha regarding dates in RDF and JSON: they use different conventions
to represent years BCE. I just updated our JSON spec to reflect that reality,
see .

There is a lot of confusion about this issue throughout the linked data web,
since the convention changed between XSL 1.0 (which uses -0044 to represent 44
BCE, and -0001 to represent 1 BCE) and XSL 1.1 (which uses -0043 to represent 44
BCE, and + to represent 1 BCE). Our JSON uses the traditional numbering (1
BCE is -0001), while RDF uses the astronomical numbering (1 BCE is +).


Is this still true? We have discussed this at length over a year ago [1] 
and there is really not much complication or "fun" about this. It is 
actually quite simple: the whole world has agreed on using + to mean 
1 BCE in technical contexts. It's just nicer to calculate with.


In particular, the JSON export is at odds with JavaScript itself (!), 
which also treats year + as 1 BCE, or course:


http://www.ecma-international.org/ecma-262/6.0/#sec-extended-years

Besides JavaScript, the exact same convention is used by ISO 8601, XML 
Schema, RDF, SPARQL, and in other programming languages that support BCE 
dates, such as Java (see SimpleDateFormat class).


Can we file a bug against the current JSON export to have this fixed? It 
would be very good if our JSON would agree with ISO, W3C, JavaScript, 
our own RDF export, and all astronomers ;-)


This would affect users of BCE dates, such as Histropedia, so it would 
be good if any users of such dates could comment on what they prefer.


Cheers,

Markus

[1] https://phabricator.wikimedia.org/T94064


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

Re: [Wikidata] Render sparql queries using the Histropedia timeline engine

[Navino Evans]

Yay, fun indeed!
I can see all of the BCE dates are out by one on the timeline, will get
that fixed.

Thanks a lot for updating the JSON spec and filling me in on the details,
that's cleared a few things up :-)

On 11 Aug 2016 12:40, "Daniel Kinzler"  wrote:

> Hi Navino!
>
> Thank you for your awesome work!
>
> Since this has caused some confusion again recently, I want to caution you
> about
> a major gotcha regarding dates in RDF and JSON: they use different
> conventions
> to represent years BCE. I just updated our JSON spec to reflect that
> reality,
> see .
>
> There is a lot of confusion about this issue throughout the linked data
> web,
> since the convention changed between XSL 1.0 (which uses -0044 to
> represent 44
> BCE, and -0001 to represent 1 BCE) and XSL 1.1 (which uses -0043 to
> represent 44
> BCE, and + to represent 1 BCE). Our JSON uses the traditional
> numbering (1
> BCE is -0001), while RDF uses the astronomical numbering (1 BCE is +).
>
> Yay, fun.
>
> Am 10.08.2016 um 21:49 schrieb Navino Evans:
> > Hi all,
> >
> >
> >
> > At long last, we’re delighted to announce you can now render sparql
> queries
> > using the Histropedia timeline engine \o/
> >
> >
> > Histropedia WikidataQuery Viewer
> > 
>
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Controversy around Wikimania talks

[David Cuenca Tudela]

> what is the function of all the policies when they so obviously are
hardly worth the bits they consist of.

Policies are not commands that have to be blindly obeyed. They are a
general framework for the admins and users to approach the blurry or
defined limits, but of course some autonomy is needed to decide in edge or
uncertain cases. That means to take decisions that eventually will make
some people (like you in this case) unhappy.

I generally prefer to have admins with more autonomy than with less, more
specifically because when there are less regulations the type of people
involved tend to create in general a more amiable climate, and I think that
has been the case so far for Wikidata. If you are complaining about the
health of the community, then you should be careful with the things you
seem to wish for (regulations, processes, etc), because it can backfire and
have the opposite effect.

OTOH, if Commons is going to have its own structured database and those
items might qualify there with less opposition, why to make such a big deal
about it?


Regards,
Micru



On Thu, Aug 11, 2016 at 1:05 PM, Gerard Meijssen 
wrote:

> Hoi,
> What is trivial. I find that the disappointment in what our policies bring
> us amounts to a lot. Effectively it is only who you are that determines
> what you get away with. The quality of arguments are easily dismissed with
> "I have a different opinion" (that is NOT an argument.
>
> When you look at my credentials you will agree that I have been involved
> heavily in our project and for all the wrong reasons I am disengaging. I
> object to the way conflicts are handled. I object to the collective shrug
> of not caring, not wanting to be involved of our admins. In the end it does
> not matter.
>
> Wikidata is a very important project that is underserved in attention to
> its community. It just sort of happens and the statistics are so good that
> we do not even look at the relative health of Wikidata as a community.
>
> It is one thing for stewards to say what they say, it is one thing for
> individual administrators to say what they say but when the situation goes
> rogue, when arguments presented by others do not get the collective
> attention of the administrative processes that are in place. When the
> allegation that admins do as they please is just a determination it becomes
> obvious to raise the question what is the function of all the policies when
> they so obviously are hardly worth the bits they consist of.
> Thanks,
>   GerardM
>
> On 1 August 2016 at 02:05, Vi to  wrote:
>
>> [Note: I'm using the last message for a cumulative reply]
>>
>> Wikidata has 16k active users, 66 admins, 3 'crats, with a pretty active
>> community. This thread has turned into a weird mix of inclusionism vs.
>> deletionism catfight + a request to undelete some contents in a specific
>> project + a series of off-topics. The first part might fit the scope of
>> this list (though is *so* boring), same for the third one. Instead, the
>> second part must be discussed on Wikidata following local policies.
>>
>> Finally, just to clarify: undeletions by stewards are completely out of
>> our mission and policies (I, for one, would rather intervene to delete ^^),
>> same for the staffers. No chances to overrule a community for such trivial
>> reasons.
>>
>> Vito
>>
>> 2016-08-01 0:36 GMT+02:00 Info WorldUniversity <
>> i...@worlduniversityandschool.org>:
>>
>>> If, as Jimbo Wales' wrote the purpose of Wikipedia involves imagining
>>> "a world in which every single person on the planet is given free access to
>>> the sum of all human knowledge. That's what we're doing.—Jimbo Wales
>>> [3]
>>> "
>>> https://en.wikipedia.org/wiki/Wikipedia:Purpose ...
>>>
>>> and the mission of the Wikimedia Foundation includes:
>>>
>>> "The mission of the Wikimedia Foundation is to empower and engage people
>>> around the world to collect and develop educational content under a free
>>> license  or in the
>>> public domain, and to disseminate it effectively and globally.
>>>
>>> In collaboration with a network of chapters
>>> , the Foundation
>>> provides the essential infrastructure and an organizational framework for
>>> the support and development of multilingual wiki projects
>>>  and other endeavors
>>> which serve this mission. The Foundation will make and keep useful
>>> information from its projects available on the Internet free of charge
>>> , in perpetuity."
>>>
>>> https://wikimediafoundation.org/wiki/Mission_statement
>>>
>>> I'd vote as a Wikidata community member for aggregating conferences and
>>> courses in all languages with machine and wiki (human) processes. Whether
>>> this is best done in Wikidat

Re: [Wikidata] Render sparql queries using the Histropedia timeline engine

[Daniel Kinzler]

Hi Navino!

Thank you for your awesome work!

Since this has caused some confusion again recently, I want to caution you about
a major gotcha regarding dates in RDF and JSON: they use different conventions
to represent years BCE. I just updated our JSON spec to reflect that reality,
see .

There is a lot of confusion about this issue throughout the linked data web,
since the convention changed between XSL 1.0 (which uses -0044 to represent 44
BCE, and -0001 to represent 1 BCE) and XSL 1.1 (which uses -0043 to represent 44
BCE, and + to represent 1 BCE). Our JSON uses the traditional numbering (1
BCE is -0001), while RDF uses the astronomical numbering (1 BCE is +).

Yay, fun.

Am 10.08.2016 um 21:49 schrieb Navino Evans:
> Hi all,
> 
>  
> 
> At long last, we’re delighted to announce you can now render sparql queries
> using the Histropedia timeline engine \o/
> 
> 
> Histropedia WikidataQuery Viewer
> 


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikidata] Controversy around Wikimania talks

[Gerard Meijssen]

Hoi,
What is trivial. I find that the disappointment in what our policies bring
us amounts to a lot. Effectively it is only who you are that determines
what you get away with. The quality of arguments are easily dismissed with
"I have a different opinion" (that is NOT an argument.

When you look at my credentials you will agree that I have been involved
heavily in our project and for all the wrong reasons I am disengaging. I
object to the way conflicts are handled. I object to the collective shrug
of not caring, not wanting to be involved of our admins. In the end it does
not matter.

Wikidata is a very important project that is underserved in attention to
its community. It just sort of happens and the statistics are so good that
we do not even look at the relative health of Wikidata as a community.

It is one thing for stewards to say what they say, it is one thing for
individual administrators to say what they say but when the situation goes
rogue, when arguments presented by others do not get the collective
attention of the administrative processes that are in place. When the
allegation that admins do as they please is just a determination it becomes
obvious to raise the question what is the function of all the policies when
they so obviously are hardly worth the bits they consist of.
Thanks,
  GerardM

On 1 August 2016 at 02:05, Vi to  wrote:

> [Note: I'm using the last message for a cumulative reply]
>
> Wikidata has 16k active users, 66 admins, 3 'crats, with a pretty active
> community. This thread has turned into a weird mix of inclusionism vs.
> deletionism catfight + a request to undelete some contents in a specific
> project + a series of off-topics. The first part might fit the scope of
> this list (though is *so* boring), same for the third one. Instead, the
> second part must be discussed on Wikidata following local policies.
>
> Finally, just to clarify: undeletions by stewards are completely out of
> our mission and policies (I, for one, would rather intervene to delete ^^),
> same for the staffers. No chances to overrule a community for such trivial
> reasons.
>
> Vito
>
> 2016-08-01 0:36 GMT+02:00 Info WorldUniversity  worlduniversityandschool.org>:
>
>> If, as Jimbo Wales' wrote the purpose of Wikipedia involves imagining "a
>> world in which every single person on the planet is given free access to
>> the sum of all human knowledge. That's what we're doing.—Jimbo Wales
>> [3]
>> "
>> https://en.wikipedia.org/wiki/Wikipedia:Purpose ...
>>
>> and the mission of the Wikimedia Foundation includes:
>>
>> "The mission of the Wikimedia Foundation is to empower and engage people
>> around the world to collect and develop educational content under a free
>> license  or in the public
>> domain, and to disseminate it effectively and globally.
>>
>> In collaboration with a network of chapters
>> , the Foundation
>> provides the essential infrastructure and an organizational framework for
>> the support and development of multilingual wiki projects
>>  and other endeavors
>> which serve this mission. The Foundation will make and keep useful
>> information from its projects available on the Internet free of charge
>> , in perpetuity."
>>
>> https://wikimediafoundation.org/wiki/Mission_statement
>>
>> I'd vote as a Wikidata community member for aggregating conferences and
>> courses in all languages with machine and wiki (human) processes. Whether
>> this is best done in Wikidata/Wikibase, or another related platform or
>> elsewhere, may be worth exploring process-wise in a number of different
>> Wikidata forums and discussions. This also seems wise, and relatively easy
>> too I.T.-wise, given shared unfolding agreement among Wikidatans and
>> Wikipedians.
>>
>> Friendly regards, Scott
>>
>> CC https://twitter.com/WorldUnivAndSch
>>
>> On Jul 31, 2016 2:18 PM, "Gerard Meijssen" 
>> wrote:
>>
>>> Hoi,
>>> There were lists of Wikimania talks for the Wikimanias. So these items
>>> were not standing alone they were in context and THAT is what makes it
>>> attractive to have them. We do have Wikimanias as items and on there own
>>> they do not provide information. Looking at them from only WIkidata you do
>>> not get the picture. Thank  that Magnus has his fantastic
>>> tools that allow us to show the value of data.
>>> Thanks,
>>>   GerardM
>>>
>>> On 31 July 2016 at 22:47, Stas Malyshev  wrote:
>>>
 Hi!

 > Ask yourself what it is about.. It is about the Wikimania talks. What
 > was done is removing all the Wikimania talks without any discussion.

 I wonder whether Wikidata is really the best platform to host Wikimania
 talks and information about it. While I have no doubt thes

Re: [Wikidata] ArticlePlaceholder is now live on Welsh and Kannada Wikipedia

[Gerard Meijssen]

Hoi,
As to search, Magnus already did that over a year ago.
Thanks,
  GerardM

On 10 August 2016 at 18:56, Lydia Pintscher 
wrote:

> Hey folks :)
>
> Just a quick note that we have now rolled out the ArticlePlaceholder
> on Welsh and Kannada Wikipedia as well. Both project had requested it.
> Here are 2 example pages:
> * https://kn.wikipedia.org/wiki/%E0%B2%B5%E0%B2%BF%E0%B2%B6%
> E0%B3%87%E0%B2%B7:AboutTopic/Q1459
> * https://cy.wikipedia.org/wiki/Arbennig:AboutTopic/Q2673
>
> We are continuing to work on improving it based on the feedback we've
> gotten so far from the projects that already have it. This includes
> layout fixes, making it possible to translate an article from another
> language using the ContentTranslation tool and getting them to show up
> in search engine results.
>
>
> Cheers
> Lydia
>
> --
> Lydia Pintscher - http://about.me/lydia.pintscher
> Product Manager for Wikidata
>
> Wikimedia Deutschland e.V.
> Tempelhofer Ufer 23-24
> 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/029/42207.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata