Hey folks :)
I just sat down with Katie to plan the next important feature deployments that are coming up this month. Here is the plan: * new datatype for mathematical expressions: We'll get it live on test.wikidata.org tomorrow and then bring it to wikidata.org on the 9th * Article Placeholder: We'll get it to test.wikipedia.org on the 9th * new datatype for identifiers: we'll bring it to wikidata.org on the 16th. We'll convert existing properties according to the list on https://www.wikidata.org/wiki/User:Addshore/Identifiers in two rounds on 17th and 18th. * In Other Projects Sidebar: We'll enable it by default on 16th for all projects that do not opt-out on https://phabricator.wikimedia.org/T103102. * interwiki links via Wikidata for Wikiversity: We'll enable phase 1 on Wikiversity on the 23rd.
Cheers Lydia
On 01.02.2016 17:14, Lydia Pintscher wrote:
Hey folks :)
I just sat down with Katie to plan the next important feature deployments that are coming up this month. Here is the plan:
- new datatype for mathematical expressions: We'll get it live on
test.wikidata.org http://test.wikidata.org tomorrow and then bring it to wikidata.org http://wikidata.org on the 9th
Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF?
Markus
- Article Placeholder: We'll get it to test.wikipedia.org
http://test.wikipedia.org on the 9th
- new datatype for identifiers: we'll bring it to wikidata.org
http://wikidata.org on the 16th. We'll convert existing properties according to the list on https://www.wikidata.org/wiki/User:Addshore/Identifiers in two rounds on 17th and 18th.
- In Other Projects Sidebar: We'll enable it by default on 16th for all
projects that do not opt-out on https://phabricator.wikimedia.org/T103102.
- interwiki links via Wikidata for Wikiversity: We'll enable phase 1 on
Wikiversity on the 23rd.
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 http://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
On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch < markus@semantic-mediawiki.org> wrote:
On 01.02.2016 17:14, Lydia Pintscher wrote:
Hey folks :)
I just sat down with Katie to plan the next important feature deployments that are coming up this month. Here is the plan:
- new datatype for mathematical expressions: We'll get it live on
test.wikidata.org http://test.wikidata.org tomorrow and then bring it to wikidata.org http://wikidata.org on the 9th
Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF?
It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype.
Cheers Lydia
The string is interpreted by the math extension in the same way as the Math extension interprets the text between the <math /> tags. There is an API to extract identifiers and the packages required to render the input with regular latex from here: http://api.formulasearchengine.com/v1/?doc or also https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check_type (The wikipedia endpoint has been opened to the public just moments ago) In the future, we are planning to provide additional semantics from there. If you have additional questions, please contact me directly, since I'm not a member on the list. Moritz
On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher <Lydia.Pintscher@wikimedia. de> wrote:
On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch < markus@semantic-mediawiki.org> wrote:
On 01.02.2016 17:14, Lydia Pintscher wrote:
Hey folks :)
I just sat down with Katie to plan the next important feature deployments that are coming up this month. Here is the plan:
- new datatype for mathematical expressions: We'll get it live on
test.wikidata.org http://test.wikidata.org tomorrow and then bring it to wikidata.org http://wikidata.org on the 9th
Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF?
It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype.
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.
For a consumer, the main practical questions would be:
(1) What subset of LaTeX exactly do you need to support to display the math expressions in Wikidata? (2) As a follow up: does MathJAX work to display this? If not, what does?
Cheers,
Markus
On 02.02.2016 10:01, Moritz Schubotz wrote:
The string is interpreted by the math extension in the same way as the Math extension interprets the text between the <math /> tags. There is an API to extract identifiers and the packages required to render the input with regular latex from here: http://api.formulasearchengine.com/v1/?doc or also https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check_type (The wikipedia endpoint has been opened to the public just moments ago) In the future, we are planning to provide additional semantics from there. If you have additional questions, please contact me directly, since I'm not a member on the list. Moritz
On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher <Lydia.Pintscher@wikimedia.de mailto:Lydia.Pintscher@wikimedia.de> wrote:
On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch <markus@semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>> wrote: On 01.02.2016 17:14, Lydia Pintscher wrote: > Hey folks :) > > I just sat down with Katie to plan the next important feature > deployments that are coming up this month. Here is the plan: > * new datatype for mathematical expressions: We'll get it live on > test.wikidata.org <http://test.wikidata.org> <http://test.wikidata.org> tomorrow and then bring it > to wikidata.org <http://wikidata.org> <http://wikidata.org> on the 9th Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF? It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype. 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 <http://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.-- Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum EN742 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil.: +49 1578 047 1397 Fax: +49 30 314 21601 E-Mail: schubotz@tu-berlin.de mailto:schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
It is a bit strange to defines a data type in terms of a library of functions in another language. Or is just me that thinks this is a bit odd?
What about MathML?
On Wed, Feb 3, 2016 at 12:06 PM, Markus Krötzsch < markus@semantic-mediawiki.org> wrote:
For a consumer, the main practical questions would be:
(1) What subset of LaTeX exactly do you need to support to display the math expressions in Wikidata? (2) As a follow up: does MathJAX work to display this? If not, what does?
Cheers,
Markus
On 02.02.2016 10:01, Moritz Schubotz wrote:
The string is interpreted by the math extension in the same way as the Math extension interprets the text between the <math /> tags. There is an API to extract identifiers and the packages required to render the input with regular latex from here: http://api.formulasearchengine.com/v1/?doc or also
https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check_type (The wikipedia endpoint has been opened to the public just moments ago) In the future, we are planning to provide additional semantics from there. If you have additional questions, please contact me directly, since I'm not a member on the list. Moritz
On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher <Lydia.Pintscher@wikimedia.de mailto:Lydia.Pintscher@wikimedia.de> wrote:
On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch <markus@semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>> wrote: On 01.02.2016 17:14, Lydia Pintscher wrote: > Hey folks :) > > I just sat down with Katie to plan the next important feature > deployments that are coming up this month. Here is the plan: > * new datatype for mathematical expressions: We'll get it liveon > test.wikidata.org http://test.wikidata.org http://test.wikidata.org tomorrow and then bring it > to wikidata.org http://wikidata.org http://wikidata.org on the 9th
Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF? It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype. 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 <http://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.-- Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum EN742 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil.: +49 1578 047 1397 Fax: +49 30 314 21601 E-Mail: schubotz@tu-berlin.de mailto:schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
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
On 03.02.2016 12:44, John Erling Blad wrote:
It is a bit strange to defines a data type in terms of a library of functions in another language. Or is just me that thinks this is a bit odd?
What about MathML?
The arxiv report that Moritz posted (after you had already asked your question) says that he has improved the tooling to translate into MathML, so this is in the picture to some extent. I would not consider it as a workable input format (try writing in MathML! ;-). On the other hand, there is AsciiMathML, but I don't know how useful that is (and people know LaTeX much better). One could consider having MathML as the internal format, and AsciiMathML and LaTeX as input options for writing it, but this seems like a big project to get to work. I guess we can exclude the option of using a visual input interface for math (Microsoft tried that in Word once, they have a lot of developers, and yet ...).
Markus
On Wed, Feb 3, 2016 at 12:06 PM, Markus Krötzsch <markus@semantic-mediawiki.org mailto:markus@semantic-mediawiki.org> wrote:
For a consumer, the main practical questions would be: (1) What subset of LaTeX exactly do you need to support to display the math expressions in Wikidata? (2) As a follow up: does MathJAX work to display this? If not, what does? Cheers, Markus On 02.02.2016 10:01, Moritz Schubotz wrote: The string is interpreted by the math extension in the same way as the Math extension interprets the text between the <math /> tags. There is an API to extract identifiers and the packages required to render the input with regular latex from here: http://api.formulasearchengine.com/v1/?doc or also https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check_type (The wikipedia endpoint has been opened to the public just moments ago) In the future, we are planning to provide additional semantics from there. If you have additional questions, please contact me directly, since I'm not a member on the list. Moritz On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher <Lydia.Pintscher@wikimedia.de <mailto:Lydia.Pintscher@wikimedia.de> <mailto:Lydia.Pintscher@wikimedia.de <mailto:Lydia.Pintscher@wikimedia.de>>> wrote: On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch <markus@semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org> <mailto:markus@semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>>> wrote: On 01.02.2016 17:14, Lydia Pintscher wrote: > Hey folks :) > > I just sat down with Katie to plan the next important feature > deployments that are coming up this month. Here is the plan: > * new datatype for mathematical expressions: We'll get it live on > test.wikidata.org <http://test.wikidata.org> <http://test.wikidata.org> <http://test.wikidata.org> tomorrow and then bring it > to wikidata.org <http://wikidata.org> <http://wikidata.org> <http://wikidata.org> on the 9th Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF? It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype. 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 <http://www.wikimedia.de> <http://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 <tel:27%2F029%2F42207>. -- Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum EN742 Einsteinufer 17 D-10587 Berlin Germany Tel.: +49 30 314 22784 <tel:%2B49%2030%20314%2022784> Mobil.: +49 1578 047 1397 <tel:%2B49%201578%20047%201397> Fax: +49 30 314 21601 <tel:%2B49%2030%20314%2021601> E-Mail: schubotz@tu-berlin.de <mailto:schubotz@tu-berlin.de> <mailto:schubotz@tu-berlin.de <mailto:schubotz@tu-berlin.de>> Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org <mailto: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
Hi Markus,
it's not exactly a subset of LaTeX. Some commands were added some were removed. A large portion of those parts are documented here https://en.wikipedia.org/wiki/Help:Displaying_a_formula , and a complete list is available from http://1drv.ms/1RtoZoW For LaTeX users I created a LaTeX macro package so that they can copy and paste texvc style LaTeX code to regular LaTeX documents https://www.ctan.org/pkg/texvc However, there are two issues with this package: \and and \or are not supported by my LaTeX package since redefining those commands caused internal problems. However, most of the time people use the standard LaTeX command \lor and \land anyhow. Altogether, enwiki contains 969 \lor and 1581 \land. Statistics on the usage frequencies are available from https://gitlab.tubit.tu-berlin.de/data/wikiFormulae/tree/master
w.r.t 2) I have no idea how that relates to MathJax? Can you explain the background of your question?
Best Moritz
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Gesendet: Mittwoch, 3. Februar 2016 12:06 An: Discussion list for the Wikidata project.; Lydia Pintscher Cc: Schubotz, Moritz Betreff: Re: [Wikidata] upcoming deployments/features
For a consumer, the main practical questions would be:
(1) What subset of LaTeX exactly do you need to support to display the math expressions in Wikidata? (2) As a follow up: does MathJAX work to display this? If not, what does?
Cheers,
Markus
On 02.02.2016 10:01, Moritz Schubotz wrote:
The string is interpreted by the math extension in the same way as the Math extension interprets the text between the <math /> tags. There is an API to extract identifiers and the packages required to render the input with regular latex from here: http://api.formulasearchengine.com/v1/?doc or also https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check _type (The wikipedia endpoint has been opened to the public just moments ago) In the future, we are planning to provide additional semantics from there. If you have additional questions, please contact me directly, since I'm not a member on the list. Moritz
On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher <Lydia.Pintscher@wikimedia.de mailto:Lydia.Pintscher@wikimedia.de> wrote:
On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch <markus@semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>> wrote: On 01.02.2016 17:14, Lydia Pintscher wrote: > Hey folks :) > > I just sat down with Katie to plan the next important feature > deployments that are coming up this month. Here is the plan: > * new datatype for mathematical expressions: We'll get it live on > test.wikidata.org <http://test.wikidata.org> <http://test.wikidata.org> tomorrow and then bring it > to wikidata.org <http://wikidata.org> <http://wikidata.org> on the 9th Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF? It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype. 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 <http://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.-- Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum EN742 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil.: +49 1578 047 1397 Fax: +49 30 314 21601 E-Mail: schubotz@tu-berlin.de mailto:schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hoi, Do I understand that this is a special for English Wikipedia only ??
REALLY ??
Thanks, GerardM
On 3 February 2016 at 13:52, Schubotz, Moritz schubotz@tu-berlin.de wrote:
Hi Markus,
it's not exactly a subset of LaTeX. Some commands were added some were removed. A large portion of those parts are documented here https://en.wikipedia.org/wiki/Help:Displaying_a_formula , and a complete list is available from http://1drv.ms/1RtoZoW For LaTeX users I created a LaTeX macro package so that they can copy and paste texvc style LaTeX code to regular LaTeX documents https://www.ctan.org/pkg/texvc However, there are two issues with this package: \and and \or are not supported by my LaTeX package since redefining those commands caused internal problems. However, most of the time people use the standard LaTeX command \lor and \land anyhow. Altogether, enwiki contains 969 \lor and 1581 \land. Statistics on the usage frequencies are available from https://gitlab.tubit.tu-berlin.de/data/wikiFormulae/tree/master
w.r.t 2) I have no idea how that relates to MathJax? Can you explain the background of your question?
Best Moritz
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Gesendet: Mittwoch, 3. Februar 2016 12:06 An: Discussion list for the Wikidata project.; Lydia Pintscher Cc: Schubotz, Moritz Betreff: Re: [Wikidata] upcoming deployments/features
For a consumer, the main practical questions would be:
(1) What subset of LaTeX exactly do you need to support to display the math expressions in Wikidata? (2) As a follow up: does MathJAX work to display this? If not, what does?
Cheers,
Markus
On 02.02.2016 10:01, Moritz Schubotz wrote:
The string is interpreted by the math extension in the same way as the Math extension interprets the text between the <math /> tags. There is an API to extract identifiers and the packages required to render the input with regular latex from here: http://api.formulasearchengine.com/v1/?doc or also https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check _type (The wikipedia endpoint has been opened to the public just moments ago) In the future, we are planning to provide additional semantics from there. If you have additional questions, please contact me directly, since I'm not a member on the list. Moritz
On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher <Lydia.Pintscher@wikimedia.de mailto:Lydia.Pintscher@wikimedia.de>
wrote:
On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch <markus@semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>> wrote: On 01.02.2016 17:14, Lydia Pintscher wrote: > Hey folks :) > > I just sat down with Katie to plan the next important feature > deployments that are coming up this month. Here is the plan: > * new datatype for mathematical expressions: We'll get itlive on
> test.wikidata.org <http://test.wikidata.org> <http://test.wikidata.org> tomorrow and then bring it > to wikidata.org <http://wikidata.org> <http://wikidata.org> on the 9th Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF? It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype. 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 <http://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.-- Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum EN742 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil.: +49 1578 047 1397 Fax: +49 30 314 21601 E-Mail: schubotz@tu-berlin.de mailto:schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
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
Am 03.02.2016 um 13:57 schrieb Gerard Meijssen:
Hoi, Do I understand that this is a special for English Wikipedia only ??
No. It just makes the functionality of <math> availabel on wikidata.
Hoi, What does it do then? I understand that it is a dialect and the only use I understand is English WIkipedia. Thanks, GerardM
On 3 February 2016 at 13:59, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 03.02.2016 um 13:57 schrieb Gerard Meijssen:
Hoi, Do I understand that this is a special for English Wikipedia only ??
No. It just makes the functionality of <math> availabel on wikidata.
-- 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
Am 03.02.2016 um 14:01 schrieb Gerard Meijssen:
Hoi, What does it do then? I understand that it is a dialect and the only use I understand is English WIkipedia.
Perhaps reading the mails in this thread would help with understanding what this does. Especially the first one.
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Why did you not just use LaTeX? Do we really need additional commands here? Just think about the interoperability of the data you are creating. Just because some command alias is used on Wikipedia does not mean we need it -- we can simply translate it to standard LaTeX on import.
The question about MathJax I asked because consumers of the data clearly need some way to display this markup. MathJax is a widely used library that can support this. Or maybe MathJax already supports your custom extensions somehow (I am not that familiar with it)? If not, then what other ways are there of embedding your custom math markup language into my application?
Cheers,
Markus
On 03.02.2016 13:52, Schubotz, Moritz wrote:
Hi Markus,
it's not exactly a subset of LaTeX. Some commands were added some were removed. A large portion of those parts are documented here https://en.wikipedia.org/wiki/Help:Displaying_a_formula , and a complete list is available from http://1drv.ms/1RtoZoW For LaTeX users I created a LaTeX macro package so that they can copy and paste texvc style LaTeX code to regular LaTeX documents https://www.ctan.org/pkg/texvc However, there are two issues with this package: \and and \or are not supported by my LaTeX package since redefining those commands caused internal problems. However, most of the time people use the standard LaTeX command \lor and \land anyhow. Altogether, enwiki contains 969 \lor and 1581 \land. Statistics on the usage frequencies are available from https://gitlab.tubit.tu-berlin.de/data/wikiFormulae/tree/master
w.r.t 2) I have no idea how that relates to MathJax? Can you explain the background of your question?
Best Moritz
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Gesendet: Mittwoch, 3. Februar 2016 12:06 An: Discussion list for the Wikidata project.; Lydia Pintscher Cc: Schubotz, Moritz Betreff: Re: [Wikidata] upcoming deployments/features
For a consumer, the main practical questions would be:
(1) What subset of LaTeX exactly do you need to support to display the math expressions in Wikidata? (2) As a follow up: does MathJAX work to display this? If not, what does?
Cheers,
Markus
On 02.02.2016 10:01, Moritz Schubotz wrote:
The string is interpreted by the math extension in the same way as the Math extension interprets the text between the <math /> tags. There is an API to extract identifiers and the packages required to render the input with regular latex from here: http://api.formulasearchengine.com/v1/?doc or also https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check _type (The wikipedia endpoint has been opened to the public just moments ago) In the future, we are planning to provide additional semantics from there. If you have additional questions, please contact me directly, since I'm not a member on the list. Moritz
On Tue, Feb 2, 2016 at 8:53 AM, Lydia Pintscher <Lydia.Pintscher@wikimedia.de mailto:Lydia.Pintscher@wikimedia.de> wrote:
On Mon, Feb 1, 2016 at 8:44 PM Markus Krötzsch <markus@semantic-mediawiki.org <mailto:markus@semantic-mediawiki.org>> wrote: On 01.02.2016 17:14, Lydia Pintscher wrote: > Hey folks :) > > I just sat down with Katie to plan the next important feature > deployments that are coming up this month. Here is the plan: > * new datatype for mathematical expressions: We'll get it live on > test.wikidata.org <http://test.wikidata.org> <http://test.wikidata.org> tomorrow and then bring it > to wikidata.org <http://wikidata.org> <http://wikidata.org> on the 9th Documentation? What will downstream users like us need to do to support this? How is this mapped to JSON? How is this mapped to RDF? It is a string representing markup for the Math extension. You can already test it here: http://wikidata.beta.wmflabs.org/wiki/Q117940. See also https://en.wikipedia.org/wiki/Help:Displaying_a_formula. Maybe Moritz wants to say bit more as his students created the datatype. 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 <http://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.-- Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum EN742 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil.: +49 1578 047 1397 Fax: +49 30 314 21601 E-Mail: schubotz@tu-berlin.de mailto:schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 03.02.2016 um 14:31 schrieb Markus Krötzsch:
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Markus, this TeX dialoect is not a new invention by Moritz. It's what the Math extension for MediaWiki has been using for over a decade now, and it's used on hundreds of thousands of pages on Wikipedia. All that we are doing now is making this same exact syntax available for property values on wikibase, using the same exact code for rendering it.
I think having consistent handling for math formulas between wikitext and wikibase is the right thing to do. Of course it would have been nice for MediaWiki to not invent it's own TeX dialect for this, but it's 10 years to late for that complaint now.
Moritz, I seem to recall that the new Math extension uses a standalone service for rendering TeX to PNG, SVG, or MathML. Can that service easily be used outside the context of MediaWiki?
On 03.02.2016 14:38, Daniel Kinzler wrote:
Am 03.02.2016 um 14:31 schrieb Markus Krötzsch:
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Markus, this TeX dialoect is not a new invention by Moritz. It's what the Math extension for MediaWiki has been using for over a decade now, and it's used on hundreds of thousands of pages on Wikipedia. All that we are doing now is making this same exact syntax available for property values on wikibase, using the same exact code for rendering it.
I think having consistent handling for math formulas between wikitext and wikibase is the right thing to do. Of course it would have been nice for MediaWiki to not invent it's own TeX dialect for this, but it's 10 years to late for that complaint now.
I do not agree with this argument. One could use a simplified version that is compatible with Wikipedia *and* with the rest of the world. We do not have MediaWiki markup in our text data, in spite of it being widely used on Wikipedia for many years -- instead, we now introduce a subset of it (the part you could put into <math>). If we have settled for a subset, why not use one that works with more commonly used tools as well? I don't think that MediaWiki LaTeX users would find it very hard to go back to the LaTeX they use elsewhere (in their own documents, on StackExchange, etc.).
A question you should ask when making extensions to the Wikidata data model is how much it will cost your data users to keep supporting Wikidata content in full. Such little twists, for a few extra commands, are creating extra work for many people.
The initial announcement one week before roll-out in the live system is not ideal either, adding some urgency to make this even more expensive. Now, four days later, even the final JSON datatype id for this has not been communicated yet ... we have 5 days left to update our code and make new releases. Of course, this schedule would leave no time for downstream users of our tools to update to the new version.
Data model updates are costly. Don't make them on a week's notice, without prior discussion, and without having any documentation ready to give to data users. It would also be good to announce breaking technical changes more prominently on wikidata-tech as well.
It would also be nice to include some motivation in your announcement (like "we expect at least 100K items -- 0.5% of current items -- to use properties of this type"). In the case of math, I could find some infoboxes that use LaTeX, so I guess this is what you are aiming for? I am not sure how many pages use such data though (inline math is of course very frequent, but it's not something you would store on Wikidata). If everybody can see why this is really needed, it will also increase acceptance in spite of some technical quirks.
Regards,
Markus
Moritz, I seem to recall that the new Math extension uses a standalone service for rendering TeX to PNG, SVG, or MathML. Can that service easily be used outside the context of MediaWiki?
Am 04.02.2016 um 08:03 schrieb Markus Krötzsch:
Data model updates are costly. Don't make them on a week's notice, without prior discussion, and without having any documentation ready to give to data users. It would also be good to announce breaking technical changes more prominently on wikidata-tech as well.
These have been discussed for months, if not years. Especially identifiers.
I do not consider adding new data types a breaking change. Converting existing properties to a different data type is a breaking change to the data-set, not to the model or the software.
On 04.02.2016 18:59, Daniel Kinzler wrote:
Am 04.02.2016 um 08:03 schrieb Markus Krötzsch:
Data model updates are costly. Don't make them on a week's notice, without prior discussion, and without having any documentation ready to give to data users. It would also be good to announce breaking technical changes more prominently on wikidata-tech as well.
These have been discussed for months, if not years. Especially identifiers.
Citation needed ;-) Note that my emails were about math, not about the identifiers. Also, discussing about something is not enough. In the end, you need to give us the technical details so we can fix our tools. I knew that you planned to introduce identifier types, but I still don't know the RDF IRI for this new type.
I do not consider adding new data types a breaking change. Converting existing properties to a different data type is a breaking change to the data-set, not to the model or the software.
No, sorry, this is just wrong. The datatypes are part of the model, not of the data. Changing the format of JSON to include new, hitherto unknown types might break a tool (and not break others). It will depend on the function of the tool (and its implementation technique) but some will break.
For example, a tool that converts Wikidata to RDF will have a problem if it encounters something that it cannot translate. This is hard to recover from, since you cannot even declare the exported property as a property at all unless you probe your data to find hints in the form of values that use this data (I don't think any existing export tool would work like this). As a result, you fail to export a significant part of the property definitions, which makes the dumps invalid for OWL, or you have to omit big parts of the data. This is clearly breaking essential functionality.
An earlier email in this thread reported that the recent changes also break pywikibot, but maybe this was another part of the changes and the one-week time-to-update I complain about does not apply there (maybe this break was clear earlier so the team there had more time to adjust?).
You really need to give people more time to accommodate data model changes -- and you should start counting the time when you have finished and publicised the documentation of a change. I can't believe that my question on the type IDs in JSON and RDF is still unanswered. I would really like to release an update of our software and online tools next week, so it would be good to know by then. Does nobody know this yet, or do you not have enough resources to say it, or what is the problem? We are no longer in those early years where everything was new and there were no applications to break.
Markus
Am 05.02.2016 um 10:56 schrieb Markus Kroetzsch:
On 04.02.2016 18:59, Daniel Kinzler wrote:
Am 04.02.2016 um 08:03 schrieb Markus Krötzsch:
Data model updates are costly. Don't make them on a week's notice, without prior discussion, and without having any documentation ready to give to data users. It would also be good to announce breaking technical changes more prominently on wikidata-tech as well.
These have been discussed for months, if not years. Especially identifiers.
Citation needed ;-) Note that my emails were about math, not about the identifiers.
The ticket exists since May 2014 https://phabricator.wikimedia.org/T67397. I didn't follow discussions on the wiki, but it has been up on https://www.wikidata.org/wiki/Wikidata:Development_plan since August 2015.
Also, discussing about something is not enough. In the end, you need to give us the technical details so we can fix our tools. I knew that you planned to introduce identifier types, but I still don't know the RDF IRI for this new type.
I send the technical info in a separate mail. You are right that we should do that kind of thing a bit earlier.
No, sorry, this is just wrong. The datatypes are part of the model, not of the data. Changing the format of JSON to include new, hitherto unknown types might break a tool (and not break others). It will depend on the function of the tool (and its implementation technique) but some will break.
I think there is a fundamental difference in the perception of format specifications here. For software that consumes "mix and match" formats like JSON and XML, I expect them to be written in a forward compatible way: unknown things just get ignored.
I have written about this in a separate mail to wikidata-tech.
Am 04.02.2016 um 08:03 schrieb Markus Krötzsch:
I do not agree with this argument. One could use a simplified version that is compatible with Wikipedia *and* with the rest of the world. We do not have MediaWiki markup in our text data, in spite of it being widely used on Wikipedia for many years -- instead, we now introduce a subset of it (the part you could put into <math>). If we have settled for a subset, why not use one that works with more commonly used tools as well? I don't think that MediaWiki LaTeX users would find it very hard to go back to the LaTeX they use elsewhere (in their own documents, on StackExchange, etc.).
A question you should ask when making extensions to the Wikidata data model is how much it will cost your data users to keep supporting Wikidata content in full. Such little twists, for a few extra commands, are creating extra work for many people.
I agree that it would be nice to have a "strict TeX mode" for the math extension. I'm not sure whether we would enable that on wikidata. While it would make the life of consumers easier, it would make the life of people importing from wikipedia harder. But perhaps it would be worth it, especially if the use of "extra stuff" is actually rare on wikipedia.
Moritz, how hard would it be to add a "strict mode" that would disallow any non-standard syntax?
Daniel Kinzler, 04/02/2016 19:02:
I agree that it would be nice to have a "strict TeX mode" for the math extension. I'm not sure whether we would enable that on wikidata. While it would make the life of consumers easier, it would make the life of people importing from wikipedia harder. But perhaps it would be worth it, especially if the use of "extra stuff" is actually rare on wikipedia.
Moritz, how hard would it be to add a "strict mode" that would disallow any non-standard syntax?
I second the question, which I think warrants a new thread. Remember to file a task in Phabricator when the dust settles down. :)
Nemo
By definition the standard for math markup is MathML. Mathoid provides information on the required packages. However, it does not indicate if macros are used that are defined in the texvc package only. This will be fixed in T126016 I think calling texvc a de facto standard LaTeX dialect is justified given the number of users. I currently cannot see how strict (which could by the way easily confused with strict content MathML) would be more standard. Best Moritz
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Federico Leva (Nemo) [mailto:nemowiki@gmail.com] Gesendet: Freitag, 5. Februar 2016 11:09 An: Discussion list for the Wikidata project.; Daniel Kinzler; Schubotz, Moritz Cc: MediaWiki announcements and site admin list Betreff: Re: Strict mode for TeX/Math extension (was: upcoming deployments/features)
Daniel Kinzler, 04/02/2016 19:02:
I agree that it would be nice to have a "strict TeX mode" for the math extension. I'm not sure whether we would enable that on wikidata. While it would make the life of consumers easier, it would make the life of people importing from wikipedia harder. But perhaps it would be worth it, especially if the use of "extra stuff" is actually rare on wikipedia.
Moritz, how hard would it be to add a "strict mode" that would disallow any non-standard syntax?
I second the question, which I think warrants a new thread. Remember to file a task in Phabricator when the dust settles down. :)
Nemo
Hi Markus,
I think we agree on the goals cf. http://arxiv.org/abs/1404.6179 By the way the texvc dialect is now 13 years old at least. For now it's required to be 100% compatible to the texvc dialect in order to use wikidata in Mediawiki instances. However, for the future there are also plans to support more markup. But all new options are blocked by https://phabricator.wikimedia.org/T74240
Mathoid, the service that converts the texvc dialect to MathML, SVG + PNG can also be used without a MediaWiki instance. I posted links to the Restbase Web UI before.
api.formulasearchengine.com (with experimental features) de.wikipedia.org/api (stable)
Moritz
Am 03.02.2016 um 14:31 schrieb Markus Krötzsch:
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Markus, this TeX dialoect is not a new invention by Moritz. It's what the Math extension for MediaWiki has been using for over a decade now, and it's used on hundreds of thousands of pages on Wikipedia. All that we are doing now is making this same exact syntax available for property values on wikibase, using the same exact code for rendering it.
I think having consistent handling for math formulas between wikitext and wikibase is the right thing to do. Of course it would have been nice for MediaWiki to not invent it's own TeX dialect for this, but it's 10 years to late for that complaint now.
Moritz, I seem to recall that the new Math extension uses a standalone service for rendering TeX to PNG, SVG, or MathML. Can that service easily be used outside the context of MediaWiki?
Hi Moritz,
On 03.02.2016 15:25, Schubotz, Moritz wrote:
Hi Markus,
I think we agree on the goals cf. http://arxiv.org/abs/1404.6179 By the way the texvc dialect is now 13 years old at least. For now it's required to be 100% compatible to the texvc dialect in order to use wikidata in Mediawiki instances. However, for the future there are also plans to support more markup. But all new options are blocked by https://phabricator.wikimedia.org/T74240
Mathoid, the service that converts the texvc dialect to MathML, SVG + PNG can also be used without a MediaWiki instance. I posted links to the Restbase Web UI before.
api.formulasearchengine.com (with experimental features) de.wikipedia.org/api (stable)
This is the API you said "has been opened to the public just moments ago" and which describes itself as "currently in beta testing"? That seems a bit shaky to say the least. In your email, you said that this API was for extracting LaTeX package names and identifiers, not for rendering content, so I have not looked at it for this purpose. How does this compare to MathJax in terms of usage? Are the output types similar? It seems your solution adds the dependency on an external server, so this cannot be used in offline mode, I suppose? How does it support styling of content for your own application, e.g., how do you select the fonts to be used?
I think we agree that real documentation should be a bit more than an unexplained link in an email. Anyway, it is not your role to provide documentation on new Wikidata features or to make sure that stakeholders are taken along when new features are deployed, so don't worry too much about this. I am sure your students did a good job implementing this, and from there on it is really in other people's hands.
Cheers,
Markus
Am 03.02.2016 um 14:31 schrieb Markus Krötzsch:
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Markus, this TeX dialoect is not a new invention by Moritz. It's what the Math extension for MediaWiki has been using for over a decade now, and it's used on hundreds of thousands of pages on Wikipedia. All that we are doing now is making this same exact syntax available for property values on wikibase, using the same exact code for rendering it.
I think having consistent handling for math formulas between wikitext and wikibase is the right thing to do. Of course it would have been nice for MediaWiki to not invent it's own TeX dialect for this, but it's 10 years to late for that complaint now.
Moritz, I seem to recall that the new Math extension uses a standalone service for rendering TeX to PNG, SVG, or MathML. Can that service easily be used outside the context of MediaWiki?
Hi Markus,
with regard to the beta status: I think if word was open source it would be called word-beta. Mathoid can be installed locally, via npm install mathoid. If your application supports HTML5 you can just include the MathML returned by your local mathoid installation (or take the cached version from the service wmf provides for the public benefits. You could also install your own restbase instance for caching. However, this requires some technical skills. Gabriel Wicke and me are working on Docker Containers, to simplify the installation procedure. When you use MathML there are (in theory) no problems with the styling and the integration to your custom application. However, for devices that do not fully support HTML5 the fallback images are not optimal, since their shape is fixed. They look similar to the way how LaTeX would render the input and do not adjust to the layout. While LaTeX is appreciated by many scientists, web browsers are no TeX renders and display the declarative style information. Note, that this is a completely different approach from imperative TeX typesetting instructions. MathJax now tries to support imperative typesetting instructions within a declarative document. While this is a nice bridge technology, we should finally aim for full declaratively.
Putting that in a broader picture, I completely share your initial skepticism in starting with this texvc dialect. The optimal way would certainly be to support content MathML to support all the formula semantics https://www.w3.org/TR/MathML3/chapter4.html . However, while this is a nice idea I think it's not very likely at the moment that people would enter content MathML expressions. Therefore, I think it's reasonable to start with the same format that used within Wikipedia, and keep the formats in sync. For the future one could image a tex dialect that includes semantic macros that link to the semantic concepts as defined in the MathML sepc For example the following input $ Z(t) = \exp@{\iunit \vartheta(t)} \RiemannZeta@{\tfrac{1}{2}+\iunit t} $ Which would be rendered as displayed here http://drmf.wmflabs.org/wiki/Formula:DLMF:25.10:E1 The input form above was used by the editors of the DLMF http://dlmf.nist.gov/ to produce a digital version of the Handbook of Mathematical Functions with Formulas, Graphs, and Mathematical Tables, edited by Milton Abramowitz and Irene A. Stegun. While there are a lot of plans what could be done in the future like for instance - Identifier Namespaces in Mathematical Notation http://de.slideshare.net/AlexeyGrigorev/identifier-namespaces-in-mathematica...) - Wolfram Alpha integration https://www.dima.tu-berlin.de/menue/theses/open_theses/msc_integrating_compu... We still need to walk before we run. I.e. start with something simple and plan more advanced stuff for the future. The intermediate next steps are discussed here https://phabricator.wikimedia.org/T67397 If you think that there is an idea that is ready to implement please share it in the structured task tracker.
Thank you again for all your input and the interest in that project. Moritz
*Disclaimer: I'm a PhD student in the Database Systems and Information Management Group. While this message reflects my personal opinion, I might have been influenced from Database Research ideas. Moreover, I'm director of the MathML association and there committed to the association goals in enabling math rendering in all Web rendering engines http://mathml-association.org/ . In addition, I'm an offsite collaborator of the National Institute of Standards and Technology in the USA and I really appreciate standards.
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Gesendet: Donnerstag, 4. Februar 2016 08:20 An: Schubotz, Moritz; Discussion list for the Wikidata project. Betreff: Re: AW: AW: [Wikidata] upcoming deployments/features
Hi Moritz,
On 03.02.2016 15:25, Schubotz, Moritz wrote:
Hi Markus,
I think we agree on the goals cf. http://arxiv.org/abs/1404.6179 By the way the texvc dialect is now 13 years old at least. For now it's required to be 100% compatible to the texvc dialect in order to use wikidata in Mediawiki instances. However, for the future there are also plans to support more markup. But all new options are blocked by https://phabricator.wikimedia.org/T74240
Mathoid, the service that converts the texvc dialect to MathML, SVG + PNG can also be used without a MediaWiki instance. I posted links to the Restbase Web UI before.
api.formulasearchengine.com (with experimental features) de.wikipedia.org/api (stable)
This is the API you said "has been opened to the public just moments ago" and which describes itself as "currently in beta testing"? That seems a bit shaky to say the least. In your email, you said that this API was for extracting LaTeX package names and identifiers, not for rendering content, so I have not looked at it for this purpose. How does this compare to MathJax in terms of usage? Are the output types similar? It seems your solution adds the dependency on an external server, so this cannot be used in offline mode, I suppose? How does it support styling of content for your own application, e.g., how do you select the fonts to be used?
I think we agree that real documentation should be a bit more than an unexplained link in an email. Anyway, it is not your role to provide documentation on new Wikidata features or to make sure that stakeholders are taken along when new features are deployed, so don't worry too much about this. I am sure your students did a good job implementing this, and from there on it is really in other people's hands.
Cheers,
Markus
Am 03.02.2016 um 14:31 schrieb Markus Krötzsch:
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Markus, this TeX dialoect is not a new invention by Moritz. It's what the Math extension for MediaWiki has been using for over a decade now, and it's used on hundreds of thousands of pages on Wikipedia. All that we are doing now is making this same exact syntax available for property values on wikibase, using the same exact code for rendering it.
I think having consistent handling for math formulas between wikitext and wikibase is the right thing to do. Of course it would have been nice for MediaWiki to not invent it's own TeX dialect for this, but it's 10 years to late for that complaint now.
Moritz, I seem to recall that the new Math extension uses a standalone service for rendering TeX to PNG, SVG, or MathML. Can that service easily be used outside the context of MediaWiki?
Hi Moritz,
On 04.02.2016 12:08, Schubotz, Moritz wrote:
Hi Markus,
with regard to the beta status: I think if word was open source it would be called word-beta.
:-D You sound like me when I was a student. However, let's be serious: there are quality criteria in software engineering, and "open source" is just a license model and has nothing to do with these. The site you linked says "beta", but the API input underneath says "unstable", which sounds as if it might change in incompatible ways in the future. This sounds like more work for me as a user who would need to rely on this.
Mathoid can be installed locally, via npm install mathoid.
That's not what I meant. As I understand, you could have a Javascript application using MathJax that, once loaded, will be able to render all MathJax-compatile math even when you are offline, without requiring you to install anything on your machine. You could also provide these resources locally on your intranet without running a dedicated service.
Also, to be clear: for me, this is not a question of "Mathoid vs MathJax". What I was suggesting was to use a subset of LaTeX that works in both, so that implementers have a choice of what they like most. I am sure they both have their pros and cons.
If your application supports HTML5 you can just include the MathML returned by your local mathoid installation (or take the cached version from the service wmf provides for the public benefits. You could also install your own restbase instance for caching. However, this requires some technical skills. Gabriel Wicke and me are working on Docker Containers, to simplify the installation procedure. When you use MathML there are (in theory) no problems with the styling and the integration to your custom application. However, for devices that do not fully support HTML5 the fallback images are not optimal, since their shape is fixed. They look similar to the way how LaTeX would render the input and do not adjust to the layout. While LaTeX is appreciated by many scientists, web browsers are no TeX renders and display the declarative style information. Note, that this is a completely different approach from imperative TeX typesetting instructions. MathJax now tries to support imperative typesetting instructions within a declarative document. While this is a nice bridge technology, we should finally aim for full declaratively.
I could not agree more, but for this very reason it is hard to see how TeX could be a good basis for this in general. Any tool that translates from TeX to MathML must make some sense of the spacial relationship of symbols as typeset by a LaTeX program, which can only ever be an approximate, heuristic process. This is all good, but as you put it, it is necessarily bridge technology.
Putting that in a broader picture, I completely share your initial skepticism in starting with this texvc dialect. The optimal way would certainly be to support content MathML to support all the formula semantics https://www.w3.org/TR/MathML3/chapter4.html . However, while this is a nice idea I think it's not very likely at the moment that people would enter content MathML expressions.
(yes, obviously, this is not a workable surface syntax)
Therefore, I think it's reasonable to start with the same format that used within Wikipedia, and keep the formats in sync. For the future one could image a tex dialect that includes semantic macros that link to the semantic concepts as defined in the MathML sepc
You are arguing as if we could change datatypes every month or so. Wikidata is a big, slow-moving project. People rely on it. When you introduce a new type of data, you get a significant number of people started entering such data, editing it, developing own quality criteria and guidelines for it, building external applications that use special libraries, and so on. Why is it so hard to build a visual editor for Wikipedia? It's not because there is no technical route to do it, it is because we have to deal with more than a decade of history in our databases. Your arguments above are only about technology, disregarding the users (it's like saying "Let's just start with Wikitext -- we can always move to a visual editor in a few years!"). It seems that, however, the move you make now is what will hinder and slow down the transition you are hoping for.
I also have the feeling that you are not aware of the way in which Wikidata is used. Our data is not just an internal source code like the wikitext in Wikipedia might be -- it is our main content. Your mathoid display, however good it is, is just a UI. The real data is LaTeX now: you made it into the main *exchange format* for math on Wikidata.
Don't get me wrong: it might still be for the best. Maybe a real, semantic math markup is so far away that we just cannot wait for it. Just like Wikipedia would never have happened if they would have waited for visual editors to become available. On the other hand, Wikipedia is also one of the last sites on the planet that will get to use such technology. There is always a trade-off. I have been (and still am) missing a discussion of the costs and benefits of this. This whole issue is a communication problem much more than a technical problem (in particular, don't apply my critique this to your programming work).
For example the following input $ Z(t) = \exp@{\iunit \vartheta(t)} \RiemannZeta@{\tfrac{1}{2}+\iunit t} $ Which would be rendered as displayed here http://drmf.wmflabs.org/wiki/Formula:DLMF:25.10:E1 The input form above was used by the editors of the DLMF http://dlmf.nist.gov/ to produce a digital version of the Handbook of Mathematical Functions with Formulas, Graphs, and Mathematical Tables, edited by Milton Abramowitz and Irene A. Stegun. While there are a lot of plans what could be done in the future like for instance
- Identifier Namespaces in Mathematical Notation http://de.slideshare.net/AlexeyGrigorev/identifier-namespaces-in-mathematica...)
- Wolfram Alpha integration https://www.dima.tu-berlin.de/menue/theses/open_theses/msc_integrating_compu...
We still need to walk before we run. I.e. start with something simple and plan more advanced stuff for the future. The intermediate next steps are discussed here https://phabricator.wikimedia.org/T67397 If you think that there is an idea that is ready to implement please share it in the structured task tracker.
I am not sure I really got all the "intermediate next steps" from the rather long bug discussion there, but thanks for the useful pointer to where this design has come into being (I had not seen this in previous discussions). Here is what I got:
It all started with the desire to display and calculate, but the latter was given up. It seems that the option of using a smaller subset of LaTeX to improve compatibility with other tools has not been considered there. What I was also missing is some technical description of what the datatype should eventually contain (like a simple grammar that defines all strings that are permitted as input).
There are some interesting confusions about what "semantics" of an operator would even mean. For example, there is the question whether the join and meet in a Boolean algebra are the same as the conjunction and disjunction in first-order logic (clearly not, and even less so than TomTom said already: one is a "semantic" operation on Boolean algebras while the other is an operator in a term algebra used to define the *syntax* of logic, which is not a Boolean algebra at all; the corresponding semantic operations in first-order logic would be a join and a union, which would agree with meet and join on the two-element Boolean algebra if you would define your semantics bottom up as in most logic textbooks -- and, yes, you could factorise the sytnax into a Lindenbaum algebra too, which gives you yet another way to get a Boolean algebra here).
If you look at that case, you can see that the idea of a semantic markup might be hopelessly futuristic. I am ready to accept that layout is the only thing we can hope for in this domain, and that therefore LaTeX is the best choice. But then one could still use a standard format rather than one with those weird pseudo-semantic macros like \and and \or that pretend to refer to an operator when in reality they do not. It is interesting to note that LaTeX primarily uses command names that describe the shape of the glyphs and avoid any semantic connotation (\bowtie rather than \join, \wedge rather than \and, etc.). I think there is a lot of wisdom in that.
Thank you again for all your input and the interest in that project.
Thanks for communicating ;-)
Markus
P.S. You mentioned that you are not on this mailing list. You really should be, given that you are apparently the main contact person for one of the (small number of) datatypes we have in Wikidata. It is a huge responsibility.
P.P.S. I can see now in your footer that you are also involved with MathML. I find it quite ironic that I am trying to convince you that a custom LaTeX dialect is maybe not what we should have picked to exchange math on the Web. Do you realise that you could have pushed this whole thing into using MathML internally, offering LaTeX only as a surface syntax and compatibility mode for texvc? It even seems as if you have the technology ready to do this.
*Disclaimer: I'm a PhD student in the Database Systems and Information Management Group. While this message reflects my personal opinion, I might have been influenced from Database Research ideas.Moreover, I'm director of the MathML association and there committed to the association goals in enabling math rendering in all Web rendering engines http://mathml-association.org/ . In addition, I'm an offsite collaborator of the National Institute of Standards and Technology in the USA and I really appreciate standards.
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Gesendet: Donnerstag, 4. Februar 2016 08:20 An: Schubotz, Moritz; Discussion list for the Wikidata project. Betreff: Re: AW: AW: [Wikidata] upcoming deployments/features
Hi Moritz,
On 03.02.2016 15:25, Schubotz, Moritz wrote:
Hi Markus,
I think we agree on the goals cf. http://arxiv.org/abs/1404.6179 By the way the texvc dialect is now 13 years old at least. For now it's required to be 100% compatible to the texvc dialect in order to use wikidata in Mediawiki instances. However, for the future there are also plans to support more markup. But all new options are blocked by https://phabricator.wikimedia.org/T74240
Mathoid, the service that converts the texvc dialect to MathML, SVG + PNG can also be used without a MediaWiki instance. I posted links to the Restbase Web UI before.
api.formulasearchengine.com (with experimental features) de.wikipedia.org/api (stable)
This is the API you said "has been opened to the public just moments ago" and which describes itself as "currently in beta testing"? That seems a bit shaky to say the least. In your email, you said that this API was for extracting LaTeX package names and identifiers, not for rendering content, so I have not looked at it for this purpose. How does this compare to MathJax in terms of usage? Are the output types similar? It seems your solution adds the dependency on an external server, so this cannot be used in offline mode, I suppose? How does it support styling of content for your own application, e.g., how do you select the fonts to be used?
I think we agree that real documentation should be a bit more than an unexplained link in an email. Anyway, it is not your role to provide documentation on new Wikidata features or to make sure that stakeholders are taken along when new features are deployed, so don't worry too much about this. I am sure your students did a good job implementing this, and from there on it is really in other people's hands.
Cheers,
Markus
Am 03.02.2016 um 14:31 schrieb Markus Krötzsch:
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Markus, this TeX dialoect is not a new invention by Moritz. It's what the Math extension for MediaWiki has been using for over a decade now, and it's used on hundreds of thousands of pages on Wikipedia. All that we are doing now is making this same exact syntax available for property values on wikibase, using the same exact code for rendering it.
I think having consistent handling for math formulas between wikitext and wikibase is the right thing to do. Of course it would have been nice for MediaWiki to not invent it's own TeX dialect for this, but it's 10 years to late for that complaint now.
Moritz, I seem to recall that the new Math extension uses a standalone service for rendering TeX to PNG, SVG, or MathML. Can that service easily be used outside the context of MediaWiki?
Hi Markus,
regardless of the beta label of mathoid: If something is broken, report it on Phabricator and it will be fixed quite soon. Maybe it would be wise, if we released mathoid 1.0, to get rid of that label. I think semantic math is possible, but not today. I invite you to discuss the efforts in building a global digital mathematical library, but maybe this is not the best thread for that.
From my understanding we Wikidata is in phase 2 according to
https://de.wikipedia.org/wiki/Wikidata thus data from Wikipedia can be exported to wikidata and displayed on Wikipedia thereafter. What we are doing here is supporting math according to the definition of <math> tag in wikitext. Nothing more and nothing less. I'm convinced that starting with this approach is the best thing we can do. Writing a script that would convert that to MathML in the future is well studied. Going back from MathML to TeX is currently not possible, to the best of my knowledge. Best Moritz
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Gesendet: Donnerstag, 4. Februar 2016 18:47 An: Schubotz, Moritz; Discussion list for the Wikidata project. Betreff: Re: AW: AW: AW: [Wikidata] upcoming deployments/features
Hi Moritz,
On 04.02.2016 12:08, Schubotz, Moritz wrote:
Hi Markus,
with regard to the beta status: I think if word was open source it would be called word-beta.
:-D You sound like me when I was a student. However, let's be serious: there are quality criteria in software engineering, and "open source" is just a license model and has nothing to do with these. The site you linked says "beta", but the API input underneath says "unstable", which sounds as if it might change in incompatible ways in the future. This sounds like more work for me as a user who would need to rely on this.
Mathoid can be installed locally, via npm install mathoid.
That's not what I meant. As I understand, you could have a Javascript application using MathJax that, once loaded, will be able to render all MathJax-compatile math even when you are offline, without requiring you to install anything on your machine. You could also provide these resources locally on your intranet without running a dedicated service.
Also, to be clear: for me, this is not a question of "Mathoid vs MathJax". What I was suggesting was to use a subset of LaTeX that works in both, so that implementers have a choice of what they like most. I am sure they both have their pros and cons.
If your application supports HTML5 you can just include the MathML returned by your local mathoid installation (or take the cached version from the service wmf provides for the public benefits. You could also install your own restbase instance for caching. However, this requires some technical skills. Gabriel Wicke and me are working on Docker Containers, to simplify the installation procedure. When you use MathML there are (in theory) no problems with the styling and the integration to your custom application. However, for devices that do not fully support HTML5 the fallback images are not optimal, since their shape is fixed. They look similar to the way how LaTeX would render the input and do not adjust to the layout. While LaTeX is appreciated by many scientists, web browsers are no TeX renders and display the declarative style information. Note, that this is a completely different approach from imperative TeX typesetting instructions. MathJax now tries to support imperative typesetting instructions within a declarative document. While this is a nice bridge technology, we should finally aim for full declaratively.
I could not agree more, but for this very reason it is hard to see how TeX could be a good basis for this in general. Any tool that translates from TeX to MathML must make some sense of the spacial relationship of symbols as typeset by a LaTeX program, which can only ever be an approximate, heuristic process. This is all good, but as you put it, it is necessarily bridge technology.
Putting that in a broader picture, I completely share your initial skepticism in starting with this texvc dialect. The optimal way would certainly be to support content MathML to support all the formula semantics https://www.w3.org/TR/MathML3/chapter4.html . However, while this is a nice idea I think it's not very likely at the moment that people would enter content MathML expressions.
(yes, obviously, this is not a workable surface syntax)
Therefore, I think it's reasonable to start with the same format that used within Wikipedia, and keep the formats in sync. For the future one could image a tex dialect that includes semantic macros that link to the semantic concepts as defined in the MathML sepc
You are arguing as if we could change datatypes every month or so. Wikidata is a big, slow-moving project. People rely on it. When you introduce a new type of data, you get a significant number of people started entering such data, editing it, developing own quality criteria and guidelines for it, building external applications that use special libraries, and so on. Why is it so hard to build a visual editor for Wikipedia? It's not because there is no technical route to do it, it is because we have to deal with more than a decade of history in our databases. Your arguments above are only about technology, disregarding the users (it's like saying "Let's just start with Wikitext -- we can always move to a visual editor in a few years!"). It seems that, however, the move you make now is what will hinder and slow down the transition you are hoping for.
I also have the feeling that you are not aware of the way in which Wikidata is used. Our data is not just an internal source code like the wikitext in Wikipedia might be -- it is our main content. Your mathoid display, however good it is, is just a UI. The real data is LaTeX now: you made it into the main *exchange format* for math on Wikidata.
Don't get me wrong: it might still be for the best. Maybe a real, semantic math markup is so far away that we just cannot wait for it. Just like Wikipedia would never have happened if they would have waited for visual editors to become available. On the other hand, Wikipedia is also one of the last sites on the planet that will get to use such technology. There is always a trade-off. I have been (and still am) missing a discussion of the costs and benefits of this. This whole issue is a communication problem much more than a technical problem (in particular, don't apply my critique this to your programming work).
For example the following input $ Z(t) = \exp@{\iunit \vartheta(t)} \RiemannZeta@{\tfrac{1}{2}+\iunit t} $ Which would be rendered as displayed here http://drmf.wmflabs.org/wiki/Formula:DLMF:25.10:E1 The input form above was used by the editors of the DLMF http://dlmf.nist.gov/ to produce a digital version of the Handbook of Mathematical Functions with Formulas, Graphs, and Mathematical Tables, edited by Milton Abramowitz and Irene A. Stegun. While there are a lot of plans what could be done in the future like for instance
- Identifier Namespaces in Mathematical Notation
http://de.slideshare.net/AlexeyGrigorev/identifier-namespaces-in-mathe matical-notation)
- Wolfram Alpha integration
https://www.dima.tu-berlin.de/menue/theses/open_theses/msc_integrating _computer_algebra_systems_and_word_processors_formulae/ We still need to walk before we run. I.e. start with something simple and plan more advanced stuff for the future. The intermediate next steps are discussed here https://phabricator.wikimedia.org/T67397 If you think that there is an idea that is ready to implement please share it in the structured task tracker.
I am not sure I really got all the "intermediate next steps" from the rather long bug discussion there, but thanks for the useful pointer to where this design has come into being (I had not seen this in previous discussions). Here is what I got:
It all started with the desire to display and calculate, but the latter was given up. It seems that the option of using a smaller subset of LaTeX to improve compatibility with other tools has not been considered there. What I was also missing is some technical description of what the datatype should eventually contain (like a simple grammar that defines all strings that are permitted as input).
There are some interesting confusions about what "semantics" of an operator would even mean. For example, there is the question whether the join and meet in a Boolean algebra are the same as the conjunction and disjunction in first-order logic (clearly not, and even less so than TomTom said already: one is a "semantic" operation on Boolean algebras while the other is an operator in a term algebra used to define the *syntax* of logic, which is not a Boolean algebra at all; the corresponding semantic operations in first-order logic would be a join and a union, which would agree with meet and join on the two-element Boolean algebra if you would define your semantics bottom up as in most logic textbooks -- and, yes, you could factorise the sytnax into a Lindenbaum algebra too, which gives you yet another way to get a Boolean algebra here).
If you look at that case, you can see that the idea of a semantic markup might be hopelessly futuristic. I am ready to accept that layout is the only thing we can hope for in this domain, and that therefore LaTeX is the best choice. But then one could still use a standard format rather than one with those weird pseudo-semantic macros like \and and \or that pretend to refer to an operator when in reality they do not. It is interesting to note that LaTeX primarily uses command names that describe the shape of the glyphs and avoid any semantic connotation (\bowtie rather than \join, \wedge rather than \and, etc.). I think there is a lot of wisdom in that.
Thank you again for all your input and the interest in that project.
Thanks for communicating ;-)
Markus
P.S. You mentioned that you are not on this mailing list. You really should be, given that you are apparently the main contact person for one of the (small number of) datatypes we have in Wikidata. It is a huge responsibility.
P.P.S. I can see now in your footer that you are also involved with MathML. I find it quite ironic that I am trying to convince you that a custom LaTeX dialect is maybe not what we should have picked to exchange math on the Web. Do you realise that you could have pushed this whole thing into using MathML internally, offering LaTeX only as a surface syntax and compatibility mode for texvc? It even seems as if you have the technology ready to do this.
*Disclaimer: I'm a PhD student in the Database Systems and Information Management Group. While this message reflects my personal opinion, I might have been influenced from Database Research ideas.Moreover, I'm director of the MathML association and there committed to the association goals in enabling math rendering in all Web rendering engines http://mathml-association.org/ . In addition, I'm an offsite collaborator of the National Institute of Standards and Technology in the USA and I really appreciate standards.
Moritz Schubotz TU Berlin, Fakultät IV DIMA - Sekr. EN7 Raum E-N 741 Einsteinufer 17 D-10587 Berlin Germany
Tel.: +49 30 314 22784 Mobil:+49 1578 047 1397 E-Mail: schubotz@tu-berlin.de Skype: Schubi87 ICQ: 200302764 Msn: Moritz@Schubotz.de
-----Ursprüngliche Nachricht----- Von: Markus Krötzsch [mailto:markus@semantic-mediawiki.org] Gesendet: Donnerstag, 4. Februar 2016 08:20 An: Schubotz, Moritz; Discussion list for the Wikidata project. Betreff: Re: AW: AW: [Wikidata] upcoming deployments/features
Hi Moritz,
On 03.02.2016 15:25, Schubotz, Moritz wrote:
Hi Markus,
I think we agree on the goals cf. http://arxiv.org/abs/1404.6179 By the way the texvc dialect is now 13 years old at least. For now it's required to be 100% compatible to the texvc dialect in order to use wikidata in Mediawiki instances. However, for the future there are also plans to support more markup. But all new options are blocked by https://phabricator.wikimedia.org/T74240
Mathoid, the service that converts the texvc dialect to MathML, SVG + PNG can also be used without a MediaWiki instance. I posted links to the Restbase Web UI before.
api.formulasearchengine.com (with experimental features) de.wikipedia.org/api (stable)
This is the API you said "has been opened to the public just moments ago" and which describes itself as "currently in beta testing"? That seems a bit shaky to say the least. In your email, you said that this API was for extracting LaTeX package names and identifiers, not for rendering content, so I have not looked at it for this purpose. How does this compare to MathJax in terms of usage? Are the output types similar? It seems your solution adds the dependency on an external server, so this cannot be used in offline mode, I suppose? How does it support styling of content for your own application, e.g., how do you select the fonts to be used?
I think we agree that real documentation should be a bit more than an unexplained link in an email. Anyway, it is not your role to provide documentation on new Wikidata features or to make sure that stakeholders are taken along when new features are deployed, so don't worry too much about this. I am sure your students did a good job implementing this, and from there on it is really in other people's hands.
Cheers,
Markus
Am 03.02.2016 um 14:31 schrieb Markus Krötzsch:
Hi Moritz,
I must say that this is not very reassuring. So basically what we have in this datatype now is a "LaTeX-like" markup language that is only supported by one implementation that was created for MediaWiki, and partially by a LaTeX package that you created.
Markus, this TeX dialoect is not a new invention by Moritz. It's what the Math extension for MediaWiki has been using for over a decade now, and it's used on hundreds of thousands of pages on Wikipedia. All that we are doing now is making this same exact syntax available for property values on wikibase, using the same exact code for rendering it.
I think having consistent handling for math formulas between wikitext and wikibase is the right thing to do. Of course it would have been nice for MediaWiki to not invent it's own TeX dialect for this, but it's 10 years to late for that complaint now.
Moritz, I seem to recall that the new Math extension uses a standalone service for rendering TeX to PNG, SVG, or MathML. Can that service easily be used outside the context of MediaWiki?
Hi!
Exciting news!
- new datatype for identifiers: we'll bring it to wikidata.org
http://wikidata.org on the 16th. We'll convert existing properties according to the list on https://www.wikidata.org/wiki/User:Addshore/Identifiers in two rounds on 17th and 18th.
Is this type supposed to work already on test.wikidata.org? I tried a couple of properties and I always get "It is not possible to define a new value for a deleted property." when I try to add statement with this type.
BTW, I imagine bots like pywikibot will have to be updated to support new types? Or they will work as strings still?
Thanks,
On Mon, Feb 1, 2016 at 10:16 PM Stas Malyshev smalyshev@wikimedia.org wrote:
Hi!
Exciting news!
- new datatype for identifiers: we'll bring it to wikidata.org
http://wikidata.org on the 16th. We'll convert existing properties according to the list on https://www.wikidata.org/wiki/User:Addshore/Identifiers in two rounds on 17th and 18th.
Is this type supposed to work already on test.wikidata.org? I tried a couple of properties and I always get "It is not possible to define a new value for a deleted property." when I try to add statement with this type.
Can you try again please? And in an in-cognito window? I just tried it and it works for me: https://test.wikidata.org/wiki/Q649 We've had some issues with local store though.
BTW, I imagine bots like pywikibot will have to be updated to support new types? Or they will work as strings still?
The datatype changes but the value type stays string. So depending on what they use they might need to be adapted.
Cheers Lydia
Hi!
Can you try again please? And in an in-cognito window? I just tried it and it works for me: https://test.wikidata.org/wiki/Q649 We've had some issues with local store though.
Weird, does work for me incognito but not when logged in.
The datatype changes but the value type stays string. So depending on what they use they might need to be adapted.
RDF export seems to be fine, except that we need to update OWL and docs for new types, I'll check pywikibot a bit later.
On Wed, Feb 3, 2016 at 9:31 AM, Stas Malyshev smalyshev@wikimedia.org wrote:
Hi!
Can you try again please? And in an in-cognito window? I just tried it and it works for me: https://test.wikidata.org/wiki/Q649 We've had some issues with local store though.
Weird, does work for me incognito but not when logged in.
The datatype changes but the value type stays string. So depending on what they use they might need to be adapted.
RDF export seems to be fine, except that we need to update OWL and docs for new types, I'll check pywikibot a bit later.
We've already done analysis for pywikibot. It will fail badly -- the api cache needs to be manually cleaned, however there are some improvements we can make so that the transition is smooth. https://phabricator.wikimedia.org/T123882
On 02.02.2016 23:31, Stas Malyshev wrote:
Hi!
Can you try again please? And in an in-cognito window? I just tried it and it works for me: https://test.wikidata.org/wiki/Q649 We've had some issues with local store though.
Weird, does work for me incognito but not when logged in.
The datatype changes but the value type stays string. So depending on what they use they might need to be adapted.
RDF export seems to be fine, except that we need to update OWL and docs for new types,
That's an important point (which my question was aiming at): What are the datatype identifiers used in JSON for the two new types? And what will be used in RDF? Besides the information that the new types are both using string values, this is probably the first thing that consumers really need to know. Lydia, can you tell us?
Cheers,
Markus
On Wed, Feb 3, 2016 at 12:05 PM Markus Krötzsch < markus@semantic-mediawiki.org> wrote:
On 02.02.2016 23:31, Stas Malyshev wrote:
Hi!
Can you try again please? And in an in-cognito window? I just tried it and it works for me: https://test.wikidata.org/wiki/Q649 We've had some issues with local store though.
Weird, does work for me incognito but not when logged in.
The datatype changes but the value type stays string. So depending on what they use they might need to be adapted.
RDF export seems to be fine, except that we need to update OWL and docs for new types,
That's an important point (which my question was aiming at): What are the datatype identifiers used in JSON for the two new types? And what will be used in RDF? Besides the information that the new types are both using string values, this is probably the first thing that consumers really need to know. Lydia, can you tell us?
Good point. Daniel is working on it: https://phabricator.wikimedia.org/T125648 and https://phabricator.wikimedia.org/T125647
Cheers Lydia