Re: [Wikidata] Controversy around Wikimania talks

[Yaroslav M. Blanter]

Andy Mabbett писал 2016-08-04 22:45:

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

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.


There is no community action to overrule. The deletion was done by
single, involved admin, with no discussion, and without any backing in
policy.


Really? And we, the admin cabal, just massively disregard policies?

May be you should learn to listen at some point. You have been provided 
with all necessary explanations, multiple times. You may agree or 
disagree, but repeatedly stating there were no explanations is 
IDONOTHEARIT.


Stop it.

Cheers
Yaroslav

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

Re: [Wikidata] Hello Wikidata!

[michaelmontague44]

Dear Glorian,I need my October 1971 psychological evaluation from the AFEES 
Center in Milwaukee un- edited and non- redacted. 


Powered by Cricket Wireless
 Original message From: Gerard Meijssen 
 Date: 8/5/16  1:12 PM  (GMT-06:00) To: "Discussion 
list for the Wikidata project."  Subject: Re: 
[Wikidata] Hello Wikidata! 
Hoi,
Are there any specific tasks for you? What is it we can bother you with?

PS Welcome :)
Thanks,
  GerardM

On 5 August 2016 at 15:20, Glorian Yapinus  wrote:
Hi folks!

My name is Glorian Yapinus, but you can simply call me Glorian ;) . For the 
next 6 months, I will assist Lydia in supporting you all.

Regarding to my educational background, I hold a bachelor's degree in 
Information Technology and currently, I am working on my Master's in Software 
Engineering and Management.

I am a warm and nice person. So, please do not hesitate to reach out to me for 
any queries :-)

Last but not least, I am looking forward to working with you.

Cheers,

Glorian

-- Glorian YapinusProduct Management Intern for Wikidata
Imagine a world, in which every single human being can freely share in the sum 
of all knowledge. That‘s our commitment.
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. 
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der 
Nummer 23855 B. 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

Re: [Wikidata] Authority control help

[Brill Lyle]

Here's drafts of a color deck (for projection) and a grayscale deck (for
printing)

https://upload.wikimedia.org/wikipedia/commons/f/ff/2016-08-05-AuthorityControl.pdf

https://upload.wikimedia.org/wikipedia/commons/c/cc/2016-08-05-AuthorityControl-Grayscale.pdf

Suggestions welcome!

- Erika


*Erika Herzog*
Wikipedia *User:BrillLyle *

On Fri, Aug 5, 2016 at 3:45 PM, Brill Lyle  wrote:

> Andy and others --
>
> Would it be helpful if I did a slide deck that has this as a printable /
> projectable document? I could generate that if it might be useful.
>
> - Erika
>
>
> *Erika Herzog*
> Wikipedia *User:BrillLyle *
>
> On Fri, Aug 5, 2016 at 2:29 PM, Andy Mabbett 
> wrote:
>
>> On 5 August 2016 at 18:50, Brill Lyle  wrote:
>> > I created a pretty rough, but hopefully still usable, help page for
>> manually
>> > inputting and moving Authority control metadata from Wikipedia to
>> Wikidata
>> > for new pages that have no associated Wikidata item.
>> >
>> > https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control
>>
>> Looks good! I will certainly make use of this in my training sessions..
>>
>> I would move your step 7 above the current step 5.
>>
>> I would also add a note that other statements should be added, not
>> least P31 ("instance of") => Q5 ("human").
>>
>> It's good practise to check for duplicates before creating an item,
>> but I think it's safe to omit that step, in a case like this, in a
>> simple guide for Wikidata newbies.
>>
>> Thanks for putting in the effort.
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> 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] Authority control help

[Brill Lyle]

Andy and others --

Would it be helpful if I did a slide deck that has this as a printable /
projectable document? I could generate that if it might be useful.

- Erika


*Erika Herzog*
Wikipedia *User:BrillLyle *

On Fri, Aug 5, 2016 at 2:29 PM, Andy Mabbett 
wrote:

> On 5 August 2016 at 18:50, Brill Lyle  wrote:
> > I created a pretty rough, but hopefully still usable, help page for
> manually
> > inputting and moving Authority control metadata from Wikipedia to
> Wikidata
> > for new pages that have no associated Wikidata item.
> >
> > https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control
>
> Looks good! I will certainly make use of this in my training sessions..
>
> I would move your step 7 above the current step 5.
>
> I would also add a note that other statements should be added, not
> least P31 ("instance of") => Q5 ("human").
>
> It's good practise to check for duplicates before creating an item,
> but I think it's safe to omit that step, in a case like this, in a
> simple guide for Wikidata newbies.
>
> Thanks for putting in the effort.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] Authority control help

[Brill Lyle]

Wanted to also add that I understand:

There are bots that
- Harvest new articles
- Add items for new articles
- Harvest authority control data

This is for casual Wikipedians -- especially librarians who like Authority
control and are creating stubs at editathons -- to start to learn how to
create a linked entry and edit Authority control on Wikidata. Something
quick and sequential so they might get an overview and translation of the
cross-walk between Wikipedia and Wikidata.

Gerard M. and I had an off list conversation about this and he thinks it is
not a valuable effort (see bots above). So that's why I wanted to mention
this usage.

Also when I want to have the new Wikipedia stub have the Authority control,
I can never use the steps. I am old and tired and need everything written
down. :-)

- Erika



*Erika Herzog*
Wikipedia *User:BrillLyle *

On Fri, Aug 5, 2016 at 1:50 PM, Brill Lyle  wrote:

> I created a pretty rough, but hopefully still usable, help page for
> manually inputting and moving Authority control metadata from Wikipedia to
> Wikidata for new pages that have no associated Wikidata item.
>
> https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control
>
> Wasn't sure if it is okay to create a page on Wikidata, but I followed the
> Be Bold! mantra and just went for it.
>
> And again this is not the most elegant solution, but I wanted there to be
> some sort of graphic documentation on how to update Authority Control.
>
> Best,
>
> - Erika
>
> *Erika Herzog*
> Wikipedia *User:BrillLyle *
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Authority control help

[Brill Lyle]

I forgot about the duplicate issue. I think the assumption here is a new
Wikipedia page -- which is what we encounter at many of the editathons here
in NYC -- and how to get Authority control in as a new Wikidata item, but I
think I will footnote this

Thanks!

- Erika


*Erika Herzog*
Wikipedia *User:BrillLyle *

On Fri, Aug 5, 2016 at 3:09 PM, Andrew Gray 
wrote:

> On 5 August 2016 at 19:28, john cummings  wrote:
> > Hey Erika
> >
> > One suggestion, add a step before creating a new item on Wikidata of
> > searching for an existing item, it may be an item exists but isn't
> linked to
> > Wikipedia.
>
> With authority control, that may be a self-repairing a problem - if
> you add an identifier that already exists on another item, it'll be
> automatically logged and flagged on the constraints report. These get
> pruned every now and again, so the duplicate record will get fixed in
> time. See, for example, a few examples (which are probably my fault!)
> at https://www.wikidata.org/wiki/Wikidata:Database_reports/
> Constraint_violations/P1614#.22Unique_value.22_violations
>
> Andrew.
>
> - Andrew Gray
>   andrew.g...@dunelm.org.uk
>
> ___
> 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] Authority control help

[Brill Lyle]

Very smart. Done.

I didn't want to get into adding statements and other elements to Wikidata
as it somewhat outside the scope of the Authority control thing, but Maybe
I should link to the Tours. I founds those helpful.

Thank you!


*Erika Herzog*
Wikipedia *User:BrillLyle *

On Fri, Aug 5, 2016 at 2:29 PM, Andy Mabbett 
wrote:

> On 5 August 2016 at 18:50, Brill Lyle  wrote:
> > I created a pretty rough, but hopefully still usable, help page for
> manually
> > inputting and moving Authority control metadata from Wikipedia to
> Wikidata
> > for new pages that have no associated Wikidata item.
> >
> > https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control
>
> Looks good! I will certainly make use of this in my training sessions..
>
> I would move your step 7 above the current step 5.
>
> I would also add a note that other statements should be added, not
> least P31 ("instance of") => Q5 ("human").
>
> It's good practise to check for duplicates before creating an item,
> but I think it's safe to omit that step, in a case like this, in a
> simple guide for Wikidata newbies.
>
> Thanks for putting in the effort.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] Authority control help

[Brill Lyle]

Good suggestion. Done.


*Erika Herzog*
Wikipedia *User:BrillLyle *

On Fri, Aug 5, 2016 at 2:28 PM, john cummings 
wrote:

> Hey Erika
>
> One suggestion, add a step before creating a new item on Wikidata of
> searching for an existing item, it may be an item exists but isn't linked
> to Wikipedia.
>
> Thanks
>
> John
>
> On 5 August 2016 at 19:50, Brill Lyle  wrote:
>
>> I created a pretty rough, but hopefully still usable, help page for
>> manually inputting and moving Authority control metadata from Wikipedia to
>> Wikidata for new pages that have no associated Wikidata item.
>>
>> https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control
>>
>> Wasn't sure if it is okay to create a page on Wikidata, but I followed
>> the Be Bold! mantra and just went for it.
>>
>> And again this is not the most elegant solution, but I wanted there to be
>> some sort of graphic documentation on how to update Authority Control.
>>
>> Best,
>>
>> - Erika
>>
>> *Erika Herzog*
>> Wikipedia *User:BrillLyle *
>>
>> ___
>> 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
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Authority control help

[Andrew Gray]

On 5 August 2016 at 19:28, john cummings  wrote:
> Hey Erika
>
> One suggestion, add a step before creating a new item on Wikidata of
> searching for an existing item, it may be an item exists but isn't linked to
> Wikipedia.

With authority control, that may be a self-repairing a problem - if
you add an identifier that already exists on another item, it'll be
automatically logged and flagged on the constraints report. These get
pruned every now and again, so the duplicate record will get fixed in
time. See, for example, a few examples (which are probably my fault!)
at 
https://www.wikidata.org/wiki/Wikidata:Database_reports/Constraint_violations/P1614#.22Unique_value.22_violations

Andrew.

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

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

Re: [Wikidata] Breaking change in JSON serialization?

[Stas Malyshev]

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.

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

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

Re: [Wikidata] Hello Wikidata!

[Scott MacLeod]

Hi Glorian, Lydia and Markus,

Very nice to meet you and welcome to Wikidata, Glorian.

Per this communication with Lydia from around July 10th -
http://scott-macleod.blogspot.com/2016/07/dusky-grouse-in-
what-ways-could-we-get.html - where she asked us if World University and
School had a candidate to develop WUaS in Wikidata ... I'd be very
interested in talking with you please about developing the (donated to
Wikidata) CC World University and School in CC Wikidata anticipating
student applicants beginning this September (as if applying to MIT or
Stanford, for example, and first in English, but anticipating all ~204
countries' main languages for online university degrees, including
especially planning-to-accredit online CC Indonesia World University -
http://worlduniversity.wikia.com/wiki/Indonesia - planned in Indonesian).
This would also include beginning to develop CC MIT OCW already in 7
languages and CC Yale OYC in Wikidata as courses for credit at WUaS, and as
a kind of course catalog, both of which WUaS has begun.

Glorian, could we possibly please get this course catalog and student
application process up and running in Wikidata by September 1for potential
student applicants (again as if applying to MIT or Stanford), to
matriculate in autumn 2017 for free CC BS/BA degrees?

The WUaS project is partly about creating online CC wiki Harvards of the
Internet in every countries' main language, accrediting on CC MIT OCW and
CC Yale OYC.

Thank you.

Best regards,
Scott

P.S.
Here's a WUaS video from 2013, with a WUaS Board member from Indonesia,
Tito Dimas, partly about CC permission from CC MIT OpenCourseWare to
translate their courses into Indonesian per communication with Yvonne Ng at
MIT (under the CC license) -https://www.youtube.com/watch?v=WdipRA8u4kw -
where WUaS wasn't able to gather the resources at the time to do this
translation, however.

Per your LinkedIn profile, Glorian - https://www.linkedin.com/in/
glorian-yapinus-ab4a3b6b - do you think it might be possible to collaborate
with the Swiss German University you went to in Indonesia - for translation
of MIT OCW into Indonesian, for example?

Thank you.



On Fri, Aug 5, 2016 at 11:12 AM, Gerard Meijssen 
wrote:

> Hoi,
> Are there any specific tasks for you? What is it we can bother you with?
>
> PS Welcome :)
> Thanks,
>   GerardM
>
> On 5 August 2016 at 15:20, Glorian Yapinus 
> wrote:
>
>> Hi folks!
>>
>> My name is Glorian Yapinus, but you can simply call me Glorian ;) . For
>> the next 6 months, I will assist Lydia in supporting you all.
>>
>> Regarding to my educational background, I hold a bachelor's degree in
>> Information Technology and currently, I am working on my Master's in
>> Software Engineering and Management.
>>
>> I am a warm and nice person. So, please do not hesitate to reach out to
>> me for any queries :-)
>>
>> Last but not least, I am looking forward to working with you.
>>
>> Cheers,
>>
>> Glorian
>>
>> --
>> Glorian Yapinus
>> Product Management Intern for Wikidata
>>
>> Imagine a world, in which every single human being can freely share in
>> the sum of all knowledge. That‘s our commitment.
>>
>> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
>> der Nummer 23855 B. 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
- Please donate to tax-exempt 501 (c) (3)
- World University and School
- via PayPal, or credit card, here -
- http://worlduniversityandschool.org
- or send checks to
- 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] Authority control help

[Andy Mabbett]

On 5 August 2016 at 18:50, Brill Lyle  wrote:
> I created a pretty rough, but hopefully still usable, help page for manually
> inputting and moving Authority control metadata from Wikipedia to Wikidata
> for new pages that have no associated Wikidata item.
>
> https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control

Looks good! I will certainly make use of this in my training sessions..

I would move your step 7 above the current step 5.

I would also add a note that other statements should be added, not
least P31 ("instance of") => Q5 ("human").

It's good practise to check for duplicates before creating an item,
but I think it's safe to omit that step, in a case like this, in a
simple guide for Wikidata newbies.

Thanks for putting in the effort.

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

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

Re: [Wikidata] Authority control help

[john cummings]

Hey Erika

One suggestion, add a step before creating a new item on Wikidata of
searching for an existing item, it may be an item exists but isn't linked
to Wikipedia.

Thanks

John

On 5 August 2016 at 19:50, Brill Lyle  wrote:

> I created a pretty rough, but hopefully still usable, help page for
> manually inputting and moving Authority control metadata from Wikipedia to
> Wikidata for new pages that have no associated Wikidata item.
>
> https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control
>
> Wasn't sure if it is okay to create a page on Wikidata, but I followed the
> Be Bold! mantra and just went for it.
>
> And again this is not the most elegant solution, but I wanted there to be
> some sort of graphic documentation on how to update Authority Control.
>
> Best,
>
> - Erika
>
> *Erika Herzog*
> Wikipedia *User:BrillLyle *
>
> ___
> 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] Hello Wikidata!

[Gerard Meijssen]

Hoi,
Are there any specific tasks for you? What is it we can bother you with?

PS Welcome :)
Thanks,
  GerardM

On 5 August 2016 at 15:20, Glorian Yapinus 
wrote:

> Hi folks!
>
> My name is Glorian Yapinus, but you can simply call me Glorian ;) . For
> the next 6 months, I will assist Lydia in supporting you all.
>
> Regarding to my educational background, I hold a bachelor's degree in
> Information Technology and currently, I am working on my Master's in
> Software Engineering and Management.
>
> I am a warm and nice person. So, please do not hesitate to reach out to me
> for any queries :-)
>
> Last but not least, I am looking forward to working with you.
>
> Cheers,
>
> Glorian
>
> --
> Glorian Yapinus
> Product Management Intern for Wikidata
>
> Imagine a world, in which every single human being can freely share in the
> sum of all knowledge. That‘s our commitment.
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. 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

[Wikidata] Authority control help

[Brill Lyle]

I created a pretty rough, but hopefully still usable, help page for
manually inputting and moving Authority control metadata from Wikipedia to
Wikidata for new pages that have no associated Wikidata item.

https://www.wikidata.org/wiki/Wikidata:Tours/Authority_control

Wasn't sure if it is okay to create a page on Wikidata, but I followed the
Be Bold! mantra and just went for it.

And again this is not the most elegant solution, but I wanted there to be
some sort of graphic documentation on how to update Authority Control.

Best,

- Erika

*Erika Herzog*
Wikipedia *User:BrillLyle *
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Hello Wikidata!

[Info WorldUniversity]

Welcome, Glorian! :)

Friendly regards,
Scott

CC http://worlduniversityandschool.org/
CC https://twitter.com/WorldUnivAndSch


On Fri, Aug 5, 2016 at 6:39 AM, Enock Seth Nyamador 
wrote:

> Welcome Glorian.
>
> Best,
>
> - Enock
>
> On Fri, Aug 5, 2016 at 1:29 PM, Biyanto Rebin <
> biyanto.re...@wikimedia.or.id> wrote:
>
>> Your name is so Indonesian. Nice to know you.
>>
>> Regards from Indonesia :)
>>
>> 2016-08-05 20:20 GMT+07:00 Glorian Yapinus 
>> :
>>
>>> Hi folks!
>>>
>>> My name is Glorian Yapinus, but you can simply call me Glorian ;) . For
>>> the next 6 months, I will assist Lydia in supporting you all.
>>>
>>> Regarding to my educational background, I hold a bachelor's degree in
>>> Information Technology and currently, I am working on my Master's in
>>> Software Engineering and Management.
>>>
>>> I am a warm and nice person. So, please do not hesitate to reach out to
>>> me for any queries :-)
>>>
>>> Last but not least, I am looking forward to working with you.
>>>
>>> Cheers,
>>>
>>> Glorian
>>>
>>> --
>>> Glorian Yapinus
>>> Product Management Intern for Wikidata
>>>
>>> Imagine a world, in which every single human being can freely share in
>>> the sum of all knowledge. That‘s our commitment.
>>>
>>> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>>> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
>>> der Nummer 23855 B. 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
>>>
>>>
>>
>>
>> --
>>
>> Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018
>> Wikimedia Indonesia
>> Nomor Ponsel: +62 8989 037379
>> Surel: biyanto.re...@wikimedia.or.id
>> 
>>
>> Dukung upaya kami membebaskan pengetahuan: http://wikimedia.
>> or.id/wiki/Wikimedia_Indonesia:Donasi
>>
>> ___
>> 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] Breaking change in JSON serialization?

[Daniel Kinzler]

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?


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

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


-- 
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] Breaking change in JSON serialization?

[Peter F. Patel-Schneider]

On 08/05/2016 06:46 AM, Daniel Kinzler wrote:
> Am 05.08.2016 um 15:02 schrieb Peter F. Patel-Schneider:
>> I side firmly with Markus here.
>>
>> Consumers of data generally cannot tell whether the addition of a new field 
>> to
>> a data encoding is a breaking change or not.
> 
> Without additional information, they cannot know, though for "mix and match"
> formats like JSON and XML, it's common practice to assume that ignoring
> additions is harmless.

The assumption that ignoring additions is harmless is a very dangerous
practice, even if it is common.

> In any case, we had communicated before that we do not consider the addition 
> of
> a field a breaking change. It only becomes a breaking change when it impacts 
> the
> interpretation of other fields. In which case we would announce it well in 
> advance.

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.

>> 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. 
> 
> Depends on the circumstances. For a web browser for example, this would be 
> very
> annoying behavior. Nearly all websites would be unusable. Similarly, most 
> email
> would become unreadable if mail clients would be that strict.

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.  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.  When such contracts are
in place systems can indeed expect to see additional fields, and are permitted
to ignore these extra fields.


>> 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 disagree on "any". For example, do you want announcements about changes to 
> the
> order of attributes in XML tags? 

No.

> Why? 

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.

> In case someone uses a regex to process
> the XML? Should you not be able to rely on your clients conforming the to XML
> spec, which says that the order of attributes is undefined?

Yes indeed.  And there would be no problem in changing the order of entities
in the JSON dump as this order is deemed to be insignificant in well-behaved
JSON texts.

> In the case at hand (adding a field), it would have been good to communicate 
> it
> in advance. But since it wasn't tagged as "breaking", it slipped through. We 
> are
> sorry for that. Clients should still not choke on an addition like this.

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.

>> 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.
> 
> Is this just for Wikidata, or does that extend to other kinds of data too? 
> Why,
> or why not?

I say this for any data, except where there is a contract that such additional
fields are not meaning-changing.

> By definition, any extensible format or protocol (HTTP, SMTP, HTML, XML, XMPP,
> IRC, etc) can contain parts (headers, elements, attributes) that the client 
> does
> not know about, and should ignore. Of course, the spec will tell clients where
> to expect and allow extra bits. 

Yes, these standards have explicit wording that there are certain places where
additional bits are allowed, and that these additional bits can be safely
ignored.  Consumers of data in these standards can verify that the data has
not been corrupted and then safely ignore extra bits in certain places,
because they have a contract that the encoding of the data that they care
about is not affected by these extra bits.  However, I don't see this contract
with respect to the Wikidata JSON encoding.

> That's why I'm planning to put up a document
> saying clearly what kinds of changes clients should be prepared to see in
> Wikidata output:
> 
> 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 

[Wikidata] Wikidata Toolkit 0.7.0 released

[Markus Kroetzsch]

Dear all,

I hereby announce the release of Wikidata Toolkit 0.7.0 [1], the Java 
library for programming with Wikidata and Wikibase.


This is a maintenance release that implements several fixes to ensure 
that WDTK can be used with recent Wikidata API outputs and future 
Wikidata JSON dumps.


The new version also ships the code used to generate the basic 
statistics used in the back of the SQID Wikidata Browser [2].


Maven users can get the library directly from Maven Central (see [1]); 
this is the preferred method of installation. There is also an 
all-in-one JAR at github [3] and of course the sources [4] and updated 
JavaDocs [5].


As usual, feedback is welcome. Developers are also invited to contribute 
via github.


Cheers,

Markus

[1] https://www.mediawiki.org/wiki/Wikidata_Toolkit
[2] https://tools.wmflabs.org/sqid/
[3] https://github.com/Wikidata/Wikidata-Toolkit/releases
[4] https://github.com/Wikidata/Wikidata-Toolkit/
[5] http://wikidata.github.io/Wikidata-Toolkit/


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

[Daniel Kinzler]

Am 05.08.2016 um 15:02 schrieb Peter F. Patel-Schneider:
> I side firmly with Markus here.
> 
> Consumers of data generally cannot tell whether the addition of a new field to
> a data encoding is a breaking change or not.

Without additional information, they cannot know, though for "mix and match"
formats like JSON and XML, it's common practice to assume that ignoring
additions is harmless.

In any case, we had communicated before that we do not consider the addition of
a field a breaking change. It only becomes a breaking change when it impacts the
interpretation of other fields. In which case we would announce it well in 
advance.

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

Depends on the circumstances. For a web browser for example, this would be very
annoying behavior. Nearly all websites would be unusable. Similarly, most email
would become unreadable if mail clients would be that strict.

> 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 disagree on "any". For example, do you want announcements about changes to the
order of attributes in XML tags? Why? In case someone uses a regex to process
the XML? Should you not be able to rely on your clients conforming the to XML
spec, which says that the order of attributes is undefined?

In the case at hand (adding a field), it would have been good to communicate it
in advance. But since it wasn't tagged as "breaking", it slipped through. We are
sorry for that. Clients should still not choke on an addition like this.

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

Is this just for Wikidata, or does that extend to other kinds of data too? Why,
or why not?

By definition, any extensible format or protocol (HTTP, SMTP, HTML, XML, XMPP,
IRC, etc) can contain parts (headers, elements, attributes) that the client does
not know about, and should ignore. Of course, the spec will tell clients where
to expect and allow extra bits. That's why I'm planning to put up a document
saying clearly what kinds of changes clients should be prepared to see in
Wikidata output:

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.

-- 
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] Hello Wikidata!

[Enock Seth Nyamador]

Welcome Glorian.

Best,

- Enock

On Fri, Aug 5, 2016 at 1:29 PM, Biyanto Rebin  wrote:

> Your name is so Indonesian. Nice to know you.
>
> Regards from Indonesia :)
>
> 2016-08-05 20:20 GMT+07:00 Glorian Yapinus :
>
>> Hi folks!
>>
>> My name is Glorian Yapinus, but you can simply call me Glorian ;) . For
>> the next 6 months, I will assist Lydia in supporting you all.
>>
>> Regarding to my educational background, I hold a bachelor's degree in
>> Information Technology and currently, I am working on my Master's in
>> Software Engineering and Management.
>>
>> I am a warm and nice person. So, please do not hesitate to reach out to
>> me for any queries :-)
>>
>> Last but not least, I am looking forward to working with you.
>>
>> Cheers,
>>
>> Glorian
>>
>> --
>> Glorian Yapinus
>> Product Management Intern for Wikidata
>>
>> Imagine a world, in which every single human being can freely share in
>> the sum of all knowledge. That‘s our commitment.
>>
>> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
>> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
>> der Nummer 23855 B. 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
>>
>>
>
>
> --
>
> Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018
> Wikimedia Indonesia
> Nomor Ponsel: +62 8989 037379
> Surel: biyanto.re...@wikimedia.or.id
> 
>
> Dukung upaya kami membebaskan pengetahuan: http://wikimedia.
> or.id/wiki/Wikimedia_Indonesia:Donasi
>
> ___
> 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] Hello Wikidata!

[Biyanto Rebin]

Your name is so Indonesian. Nice to know you.

Regards from Indonesia :)

2016-08-05 20:20 GMT+07:00 Glorian Yapinus :

> Hi folks!
>
> My name is Glorian Yapinus, but you can simply call me Glorian ;) . For
> the next 6 months, I will assist Lydia in supporting you all.
>
> Regarding to my educational background, I hold a bachelor's degree in
> Information Technology and currently, I am working on my Master's in
> Software Engineering and Management.
>
> I am a warm and nice person. So, please do not hesitate to reach out to me
> for any queries :-)
>
> Last but not least, I am looking forward to working with you.
>
> Cheers,
>
> Glorian
>
> --
> Glorian Yapinus
> Product Management Intern for Wikidata
>
> Imagine a world, in which every single human being can freely share in the
> sum of all knowledge. That‘s our commitment.
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. 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
>
>


-- 

Biyanto Rebin | Ketua Umum (*Chair*) 2016-2018
Wikimedia Indonesia
Nomor Ponsel: +62 8989 037379
Surel: biyanto.re...@wikimedia.or.id


Dukung upaya kami membebaskan pengetahuan:
http://wikimedia.or.id/wiki/Wikimedia_Indonesia:Donasi
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Hello Wikidata!

[Luca Martinelli]

Welcome on board. :)

L.

Il 05 ago 2016 15:20, "Glorian Yapinus"  ha
scritto:

> Hi folks!
>
> My name is Glorian Yapinus, but you can simply call me Glorian ;) . For
> the next 6 months, I will assist Lydia in supporting you all.
>
> Regarding to my educational background, I hold a bachelor's degree in
> Information Technology and currently, I am working on my Master's in
> Software Engineering and Management.
>
> I am a warm and nice person. So, please do not hesitate to reach out to me
> for any queries :-)
>
> Last but not least, I am looking forward to working with you.
>
> Cheers,
>
> Glorian
>
> --
> Glorian Yapinus
> Product Management Intern for Wikidata
>
> Imagine a world, in which every single human being can freely share in the
> sum of all knowledge. That‘s our commitment.
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. 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

[Wikidata] Hello Wikidata!

[Glorian Yapinus]

Hi folks!

My name is Glorian Yapinus, but you can simply call me Glorian ;) . For the
next 6 months, I will assist Lydia in supporting you all.

Regarding to my educational background, I hold a bachelor's degree in
Information Technology and currently, I am working on my Master's in
Software Engineering and Management.

I am a warm and nice person. So, please do not hesitate to reach out to me
for any queries :-)

Last but not least, I am looking forward to working with you.

Cheers,

Glorian

-- 
Glorian Yapinus
Product Management Intern for Wikidata

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. 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] Breaking change in JSON serialization?

[Peter F. Patel-Schneider]

I side firmly with Markus here.

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

Peter F. Patel-Schneider
Nuance Communications

PS:  JSON is a particularly problematic encoding for data because many aspects
of the data that a particular JSON text is meant to encode are left
unspecified by the JSON standards.

On 08/05/2016 05:04 AM, Daniel Kinzler wrote:
> Hi Markus!
> 
> You are asking use to better communicate changes to our serialization, even if
> it's not a breaking change according to the spec. I agree we should do that. 
> We
> are trying to improve our processes to achieve this.
> 
> Can we ask you in return to try to make your software more robust, by not 
> making
> unwarranted assumptions about the serialization format?
> 
> 
> With regards to communicating more - it's very hard to tell which changes 
> might
> break something for someone. For instance, some software might rely on the 
> order
> of fields in a JSON object, even though JSON says this is unspecified, just 
> like
> you rely on no fields being added, even though there is no guarantee about 
> this.
> Similarly, some software might rely on non-ascii characters being represented 
> as
> unicode escape sequences, and will break if we use the more compact utf-8. Or
> they may break on changes whitespace. Who knows. We can not possibly know what
> kind of change will break some 3rd party software.
> 
> I don't think announcing any and all changes is feasible. So I think an 
> official
> policy about what we announce can be useful. Something like "This is what we
> consider a breaking change, and we will definitely announce it. And these are
> some kinds of changes we will also communicate ahead of time. And these are 
> some
> things that can happen unannounced."
> 
> You are right that policies don't change the behavior of software. But perhaps
> they can change the behavior of programmers, by telling them what they can 
> (and
> can't) safely rely on.
> 
> 
> It boils down to this: we can try to be more verbose, but if you make
> assumptions beyond the spec, things will break sooner or later. Writing robust
> software requires more time and thought initially, but it saves a lot of
> headaches later.
> 
> -- daniel
> 
> Am 04.08.2016 um 21:49 schrieb Markus Kroetzsch:
>> Daniel,
>>
>> You present arguments on issues that I would never even bring up. I think we
>> fully agree on many things here. Main points of misunderstanding:
>>
>> * I was not talking about the WMDE definition of "breaking change". I just 
>> meant
>> "a change that breaks things". You can define this term for yourself as you 
>> like
>> and I won't argue with this.
>>
>> * I would never say that it is "right" that things break in this case. It's
>> annoying. However, it is the standard behaviour of widely used JSON parsing
>> libraries. We won't discuss it away.
>>
>> * I am not arguing that the change as such is bad. I just need to know about 
>> it
>> to fix things before they break.
>>
>> * I am fully aware of many places where my software should be improved, but I
>> cannot fix all of them just to be prepared if a change should eventually 
>> happen
>> (if it ever happens). I need to know about the next thing that breaks so I 
>> can
>> prioritize this.
>>
>> * The best way to fix this problem is to annotate all Jackson classes with 
>> the
>> respective switch individually. The global approach you linked to requires 
>> that
>> all users of the classes implement the fix, which is not working in a 
>> library.
>>
>> * When I asked for announcements, I did not mean an information of the type 
>> "we
>> plan to add more optional bits soonish". This ancient wiki page of yours that
>> mentions that some kind of change should happen at some point is even more
>> vague. It is more helpful to learn about changes when you know how they will
>> look and when they will happen. My assumption is that this is a "low cost"
>> improvement that is not too much to ask for.
>>
>> * I did not follow what you want to make an "official policy" for. Software
>> won't behave any differently just because there is a policy saying that it 
>> should.
>>
>> Markus
>>
>>
>> On 04.08.2016 16:48, Daniel Kinzler wrote:
>>> Hi Markus!
>>>
>>> I would like to elaborate a little on what Lydia said.
>>>
>>> Am 04.08.2016 um 09:27 schrieb Markus Kroetzsch:
 It seems that some changes have been made to the JSON serial

Re: [Wikidata] Breaking change in JSON serialization?

[Daniel Kinzler]

Hi Markus!

You are asking use to better communicate changes to our serialization, even if
it's not a breaking change according to the spec. I agree we should do that. We
are trying to improve our processes to achieve this.

Can we ask you in return to try to make your software more robust, by not making
unwarranted assumptions about the serialization format?


With regards to communicating more - it's very hard to tell which changes might
break something for someone. For instance, some software might rely on the order
of fields in a JSON object, even though JSON says this is unspecified, just like
you rely on no fields being added, even though there is no guarantee about this.
Similarly, some software might rely on non-ascii characters being represented as
unicode escape sequences, and will break if we use the more compact utf-8. Or
they may break on changes whitespace. Who knows. We can not possibly know what
kind of change will break some 3rd party software.

I don't think announcing any and all changes is feasible. So I think an official
policy about what we announce can be useful. Something like "This is what we
consider a breaking change, and we will definitely announce it. And these are
some kinds of changes we will also communicate ahead of time. And these are some
things that can happen unannounced."

You are right that policies don't change the behavior of software. But perhaps
they can change the behavior of programmers, by telling them what they can (and
can't) safely rely on.


It boils down to this: we can try to be more verbose, but if you make
assumptions beyond the spec, things will break sooner or later. Writing robust
software requires more time and thought initially, but it saves a lot of
headaches later.

-- daniel

Am 04.08.2016 um 21:49 schrieb Markus Kroetzsch:
> Daniel,
> 
> You present arguments on issues that I would never even bring up. I think we
> fully agree on many things here. Main points of misunderstanding:
> 
> * I was not talking about the WMDE definition of "breaking change". I just 
> meant
> "a change that breaks things". You can define this term for yourself as you 
> like
> and I won't argue with this.
> 
> * I would never say that it is "right" that things break in this case. It's
> annoying. However, it is the standard behaviour of widely used JSON parsing
> libraries. We won't discuss it away.
> 
> * I am not arguing that the change as such is bad. I just need to know about 
> it
> to fix things before they break.
> 
> * I am fully aware of many places where my software should be improved, but I
> cannot fix all of them just to be prepared if a change should eventually 
> happen
> (if it ever happens). I need to know about the next thing that breaks so I can
> prioritize this.
> 
> * The best way to fix this problem is to annotate all Jackson classes with the
> respective switch individually. The global approach you linked to requires 
> that
> all users of the classes implement the fix, which is not working in a library.
> 
> * When I asked for announcements, I did not mean an information of the type 
> "we
> plan to add more optional bits soonish". This ancient wiki page of yours that
> mentions that some kind of change should happen at some point is even more
> vague. It is more helpful to learn about changes when you know how they will
> look and when they will happen. My assumption is that this is a "low cost"
> improvement that is not too much to ask for.
> 
> * I did not follow what you want to make an "official policy" for. Software
> won't behave any differently just because there is a policy saying that it 
> should.
> 
> Markus
> 
> 
> On 04.08.2016 16:48, Daniel Kinzler wrote:
>> Hi Markus!
>>
>> I would like to elaborate a little on what Lydia said.
>>
>> Am 04.08.2016 um 09:27 schrieb Markus Kroetzsch:
>>> It seems that some changes have been made to the JSON serialization 
>>> recently:
>>>
>>> https://github.com/Wikidata/Wikidata-Toolkit/issues/237
>>
>> This specific change has been announced in our JSON spec for as long as the
>> document exists.
>>  
>> sais:
>>
>>> WARNING: wikibase-entityid may in the future change to be represented as a
>>> single string literal, or may even be dropped in favor of using the string
>>> value type to reference entities.
>>>
>>> NOTE: There is currently no reliable mechanism for clients to generate a
>>> prefixed ID or a URL from the information in the data value.
>>
>> That was the problem: With the current format, all clients needed a hard 
>> coded
>> mapping of entity types to prefixes, in order to construct ID strings from 
>> the
>> JSON serialization of ID values. That means no entity types can be added 
>> without
>> breaking clients. This has now been fixed.
>>
>>
>> Of course, it would have been good to announce this in advance. However, it 
>> is
>> not a breaking change, and we do not plan to treat additions as breaking 
>> c