Wikidata:Property proposal/Alexander–Briggs notation

Alexander–Briggs notation

Originally proposed at Wikidata:Property proposal/Natural science

   Done: Alexander–Briggs notation (P6432) (Talk and documentation)

Description	common notation of abstract knots
Represents	Alexander-Briggs notation (Q55960283)
Data type	Mathematical expression
Domain	knot (Q1188853)
Allowed values	/[0-9]+_{?[0-9]+}?/
Example 1	unknot (Q1188344) → $0_{1}$
Example 2	trefoil knot (Q168620) → $3_{1}$
Example 3	three-twist knot (Q7797291) → $5_{2}$
Source	en:List of prime knots or http://katlas.math.toronto.edu/wiki/The_Rolfsen_Knot_Table

Opensofias
Tobias1984
Arthur Rubin
Cuvwb
TomT0m
Physikerwelt
Lymantria
Bigbossfarin
Infovarius
Helder
PhilMINT
Malore
Lore.mazza51
Wikisaurus
The Anome
The-erinaceous-one
Daniel Mietchen
Haansn08
Xenmorpha
John Samuel
Jeremy Dover
Toni 001
Bocardodarapti
Duckmather
HTinC23
fgnievinski
Paul-Olivier Dehaye
uni
Dexxor
慈居

Notified participants of WikiProject Mathematics

Motivation

It is a standard notation of abstract knots, see enwiki. It consists of a number and a subscript: maybe, there is a better way to fill it than with _subscript? Wikisaurus (talk) 14:35, 4 August 2018 (UTC)

Discussion

•  Oppose It's not currently possible to store super/subscript markup in values. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:45, 4 August 2018 (UTC)
  • User:Pigsonthewing, as I understand, you oppose using <sub>-tag, not storing subscripts altogether. Is there a standard Wikidata way to store subscripts? If not, we can use underscore, like 5_1 instead of 5₁, as it is sometimes used in Alexander-Briggs notation. I would like to ask you to be more communitative and not just vote oppose without giving exact explanation, as it makes atmosphere on this site worse. Wikisaurus (talk) 10:38, 5 August 2018 (UTC)
    • No, I do not "oppose using <sub>-tag"; I oppose this proposal because it is not possible to do so. That is why I wrote "It's not currently possible to store super/subscript markup in values", which is both "communitative" and an "exact explanation". Personally, I find that a false accusation "makes atmosphere on this site worse". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:49, 5 August 2018 (UTC)
      • I think there is a miscommunication here. One question (a) is if it's currently possible to store subscripts in wikidata, the other question is (b) if the suggested property is significant. I think one could and should discuss these questions separately. --Physikerwelt (talk) 09:08, 6 August 2018 (UTC)
        • Thank you for sharing your opinion. The former is not a "question", since we already know that it is not possible to store subscripts in Wikidata. Given that, it is perfectly reasonable to oppose a proposal which explicitly requires us to do so, without initiating a "separate discussion". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:04, 6 August 2018 (UTC)
          • Dear @Pigsonthewing:, could you kindly explain me, what your mean by not possible. Technically - well, you can store sub-tag, you can use space or underscore as separator, you can use mathematical format. Semantically - well, in most cases formatted data is not stored semantically, just satisfying some regexp. By the rules - link, please. Accenting language error in the comments of other people not only is rude, but probably violates en:WP:CIV or how is it called here on Wikidata. Wikisaurus (talk) 11:09, 8 August 2018 (UTC)
            • If you think I'm in breach of "rules", please raise a complaint on Wikidata:Administrators' noticeboard. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:10, 8 August 2018 (UTC)
              • What use for? And @Pigsonthewing:, you have not answered my question on what you mean by not possible. Wikisaurus (talk) 15:53, 12 August 2018 (UTC)
•  Comment @Wikisaurus: You could just use characters from Superscripts and Subscripts (Q3513021) for the subscript values. Mahir256 (talk) 21:57, 4 August 2018 (UTC)
  • User:Mahir256, I rather dislike these special characters, this UNICODE mechanism should be deprecated. For example, they exist only for numbers, not for letters. Moreover, they are indistinguishable from usual numbers on some devices, which makes 11₁ and 1₁₁ look the same. Wikisaurus (talk) 10:38, 5 August 2018 (UTC)
• If you switched the datatype to mathematical expression one could write (\d+)_((\d)|\{\d+\}) which would be rendered as $10_{3}$ unfortunately mw:Extension:Math does not support knot rendering as on http://newweb.cecm.sfu.ca/cgi-bin/KnotPlot/KnotServer/kserver?ncomp=1&ncross=10&id=3 yet..--Physikerwelt (talk) 08:53, 6 August 2018 (UTC)
• @Wikisaurus: Yes, as Physikerwelt points out, we have a variant of the string datatype that DOES support TeX notation - see for example defining formula (P2534). ArthurPSmith (talk) 17:47, 6 August 2018 (UTC)
• If we store the values, I would want to store them in unicode and leave out any tags. 5₂ works better than 5₂. I  Support the property with unicode and  Oppose it otherwise. ChristianKl ❪✉❫ 11:25, 25 August 2018 (UTC)
•  Oppose as string,  Support as "mathematical expression" datatype. Lymantria (talk) 18:22, 8 January 2019 (UTC)
• Also  Support as "mathematical expression". @ChristianKl: Can you explain your position above? $5_{2}$ and 5₂ both display better than 5₂ at least for me (the subscript 2 is tiny in my browser). Other than display, both using '_' and using '<sub>' are surely easier to enter on a keyboard. And @Pigsonthewing: - do you object to using the mathematical expression datatype here, and if so can you also explain why? ArthurPSmith (talk) 18:54, 9 January 2019 (UTC)

  Any system that supports unicode can automatically display the unicode value without doing any parsing. Any app that interacts with Wikidata should be able to treat strings as being formatted in the way they should be displayed without the necessity of parsing the strings and increasing the complexity. I see unicode's job as stored the semantic meaning of a string and see only a need for a further script language when it comes to styling of text for being displayed in a certain way.

To the extend that unicode gets rendered in a way that's looks less aesthetic then other formatting that's a problem of the formatting engine and not one of the format. If unicode gets more widely used, there an incentive to get it to be rendered more aesthetically as well. On the same token, actual using unicode symbols outside of ASCII also encourages development of easier ways to input them. ChristianKl ❪✉❫ 08:27, 10 January 2019 (UTC)

Any system that supports unicode can automatically display the unicode value - that's really not true: a glyph for the unicode character needs to be in the font used, and if it's not the system falls back on some sort of default glyph that may not look good at all. Since we're talking about subscripts, what does en:Superscripts and Subscripts look like to you? The 2095-209C characters all show as strange boxes on 3 browsers I tried. Yes, unicode is nice for many uses, but it's actually probably not the best way to handle subscripting or other special notations of this sort. ArthurPSmith (talk) 16:43, 10 January 2019 (UTC)

Apart from that, the mathematical community is totally familiar with TEX-like typing of formulas and for instance typing formulas in MS-Word works that way. So for mathematical properties, the mathematical expression datatype is a very convenient choice. Lymantria (talk) 09:25, 11 January 2019 (UTC)

It seems that the MacOs doesn't support the 2095-209C characters but those are distinct from the subscripts for numbers and mathematical signs.

While I still prefer unicode strings, I think it's okay to use Mathematical expression and by default expect from every data-user to treat data from Mathematical expression to be treated as MathMl formatted. ChristianKl ❪✉❫ 10:09, 31 January 2019 (UTC)

•  Comment I've updated the proposal to show how mathematical expression would work here. ArthurPSmith (talk) 17:53, 11 January 2019 (UTC)

@Wikisaurus: Just checking - are you ok with this proposal using "mathematical expression" datatype as above? ArthurPSmith (talk) 17:55, 11 January 2019 (UTC)

• Well, it is better, then nothing, although there is very bad support of math datatype in Wikipedias and no real need for it in this case. Wikisaurus (talk) 21:35, 11 January 2019 (UTC)

• @Wikisaurus: Actually there is a need in this case because strings displayed in Wikidata (including labels and descriptions) do not support wikitext, so "<sub>" would just display straight as that string here, it would not show as a subscript. Only the mathematical expression datatype can handle any mathematical notation correctly within wikidata. You can try the string format at Wikidata Sandbox (Q4115189) for yourself. Unicode as Christian suggests would also work. I'm not sure how either would work when pulled into other wikipedias though. ArthurPSmith (talk) 17:50, 12 January 2019 (UTC)

• What I meant by overkill is the plain text like "2_3", not "2₃" (this format is really used sometimes). But I agree that in the long-term math format is better. Unfortunately, now there is no way to use it at least in Russian Wikipedia and Wikipedias using its module Wikidata. Wikisaurus (talk) 19:02, 12 January 2019 (UTC)

• @Physikerwelt: you commented earlier, what do you think of this version of the proposal? Are you aware of the issue with Russian wikipedia (or others)? ArthurPSmith (talk) 14:46, 14 January 2019 (UTC)
  • @ArthurPSmith: I am very aware of the rendering problems. There are browser vendors that do not support the MathML part of the HTML5 spec. As a workaround all (even simple) Math expressions are delivered using SVG by default. I think neither MathML <msub><mn>2</mn><mn>3</mn></msub> nor (ab)using legacy HTML 2₃ for text is something that people entering this problem should worry about. However, I do not understand what can not be used in rusian Wikipedia. I have done an exeriment: This template uses formuale from Wikidata in Wikipedia https://en.wikipedia.org/wiki/Module:ShowMath/doc. Physikerwelt (talk) 15:41, 15 January 2019 (UTC)
    • So do you support this proposal as a mathematical expression (as currently described)? ArthurPSmith (talk) 16:33, 15 January 2019 (UTC)
•  Comment I think the name of this property should be "crossing number (Q2548661)", and that the subscript value can be stored using series ordinal (P1545). --Okkn (talk) 07:09, 17 January 2019 (UTC)

@Okkn, ArthurPSmith, Physikerwelt, Wikisaurus, Pigsonthewing:  Done: Alexander–Briggs notation (P6432) − Pintoch (talk) 08:30, 2 February 2019 (UTC)