Wikidata:Property proposal/quantity symbol

quantity symbol (LaTeX)

Originally proposed at Wikidata:Property proposal/Natural science

   Done: quantity symbol (LaTeX) (P7973) (Talk and documentation)

Description	symbol for a mathematical or physical quantity
Represents	quantity symbol (Q1401551)
Data type	Mathematical expression
Domain	individual quantity (Q71550118)
Example 1	electric charge (Q1111) → Q
Example 2	group velocity (Q217361) → c_g
Example 3	mass fraction of water (Q76379025) → w_{H_2O}
Example 4	surface density (Q1907514) → \rho_A
Source	ISO/IEC 80000 (Q568496)
Planned use	replace quantity symbol (string) (P416)
Number of IDs in source	hundreds
Expected completeness	always incomplete (Q21873886)
See also	unit symbol (P5061): abbreviation of a unit for each language; if not provided, then it should default to English quantity symbol (string) (P416): symbol for a mathematical or physical quantity title in LaTeX (P6835): (qualifier) for title property (P1476), to write title in LaTeX/math notation, if the string can't render it normally. Enclose normal text with "\text{" and "}"

Motivation

The existing quantity symbol (string) (P416) has datatype string, which is not sufficient to represent all the notation used for quantity symbols. While there are some The Unicode® Standard (Q8819) sub- and superscripts, they are often not appropriate for use in quantity symbols (usually, special Unicode symbols are tied to a particular use); not all letters are available and nesting of subscripts is not supported (see example 3 above) Toni 001 (talk) 21:50, 26 November 2019 (UTC)

Discussion

•  Support David (talk) 05:34, 27 November 2019 (UTC)
•  Support Swpb (talk) 14:20, 27 November 2019 (UTC)

•  Comment @Toni 001: Your proposal also uses datatype string. Did you mean to have type "mathematical expression"? Are you proposing to remove all uses of quantity symbol (string) (P416) and replace it with the new property? If not we need a distinctive label for this property... ArthurPSmith (talk) 19:18, 27 November 2019 (UTC)
  • @ArthurPSmith: Thanks for the hint. Yes, it should be "math"; fixed now. (I remember entering math while working on this proposal and I even checked that the link works; not sure what happened.) Yes, this should completely replace P416 - there won't be any use (that I could think of) for the other property. I've been wondering how we deal with the property name in the transition period (as there are less than 300 values I expect only a few days - I volunteer to move them manually and check and improve them in the process). Maybe the new property could temporarily have some parenthesis like "(replacement for P416)" in either the label or description. Toni 001 (talk) 12:21, 28 November 2019 (UTC)
  • Ah, the datatype was changed in this edit. Toni 001 (talk) 12:23, 28 November 2019 (UTC)
•  Comment this will not be created until we agree on a new label: two properties cannot have the same label in the same language. − Pintoch (talk) 15:50, 4 December 2019 (UTC)
  • Anyone have a problem with labeling this "quantity symbol (mathematical expression)" and changing the old one to "quantity symbol (DEPRECATED)"? This is just until the uses are migrated, after all. Swpb (talk) 17:33, 4 December 2019 (UTC)
    • @Swpb: Yes, that sounds good to me. @Jura1: I noticed you already added (Tex), thanks. I updated it to (mathematical expression) as it is called like this in the documentation. Toni 001 (talk) 13:19, 5 December 2019 (UTC)
      • Maybe we could use "LaTeX" as at title in LaTeX (P6835). With "(mathematical expression)" it can be misunderstood as not meaning the datatype. --- Jura 13:46, 6 December 2019 (UTC)
        • If this is only temporary then I don't mind a lot. But note the documentation: math (Mathematical expression). Likely a lot of though went into writing this documentation and deciding against mentioning (La)TeX in this paragraph. Toni 001 (talk) 00:43, 7 December 2019 (UTC)
          • oh .. as I wrote some of it .. probably not. --- Jura 12:52, 20 January 2020 (UTC)
    • Hi @Pintoch: (pinging you as potential property creator) We now have a name (proposed by Jura1) that has not been opposed for some time, which seemed like the only technical reason to hold off the creation. (Jura1 prefers to keep the existing property because the new one is not query-able, but I think that need not hold off the creation of this new property, because a potential deletion request [if/when someone brings it forward] will have its separate discussion anyway.) Thanks. Toni 001 (talk) 12:06, 4 February 2020 (UTC)

• • I think it could actually be helpful to have both. math datatype is still incompletely supported and it's not clear if that ever will change. Many basic things can still not be done. --- Jura 04:48, 5 December 2019 (UTC)
    • @Jura1: With "incomplete support" are you suggesting that there are things that can be entered as string but not as math? From my limited experience I would guess that the new property can do more than the old one - in particular, all the values I've seen for the old property can definitely be expressed with the new one. Toni 001 (talk) 13:22, 5 December 2019 (UTC)
      • Not quite, anything can be entered in either, it's just that the math version can't be queried reliably on Query Server.--- Jura 18:49, 5 December 2019 (UTC)
        • Good point about querying. But see for instance this query about ISO/IEC 80000 quantities: The quantitySymbols column now shows various (composite) symbols that look bad or even wrong. On the other hand, the symbolInFormula column looks very nice, thanks to the math type of that property. So, that's the whole point of this proposal: Some things can't be entered as string. If I had to choose between queryability and being able to enter values correctly, then I'll clearly choose the latter. Toni 001 (talk) 00:51, 7 December 2019 (UTC)
          • You see how it looks, but you can't really query what was actually entered. --- Jura 10:33, 20 January 2020 (UTC)
            • I updated the proposal accordingly. Are the supporters ok with? Maybe this could be a qualifier for P416? --- Jura 12:52, 20 January 2020 (UTC)
              • Thanks, looks good to me. (I still think that the existing property should eventually be deprecated but I see no reason why we should hold up this new property for such a discussion - fine with me if we want to maintain both for now.) Toni 001 (talk) 19:00, 20 January 2020 (UTC)
•  Support. Wikisaurus (talk) 20:33, 5 December 2019 (UTC)
• By the way, how one should label language? For example, median lethal dose (Q711849) is called "LD50" in most languages, but "DL50" in French (also "ЛД50" in Russian and Ukrainian, but they probably use international "LD50" quite often, so "LD50" is ok for them). Is it normal what is done on p:P2240#P416? (I know it should not be on the property). Wikisaurus (talk) 13:40, 6 December 2019 (UTC)
  • @Wikisaurus: A similar question has been raised before for unit symbol. So in the long term, we might potentially want a hybrid datatype that is both "mathematical expression" and "monolingual text". Or we could try to model this with qualifiers as intended in the example you gave. Toni 001 (talk) 14:04, 6 December 2019 (UTC)
•  Comment revisiting this, wouldn't we want to create one with monolingual string datatype (to match the unit property) and merely use the qualifier TeX string (P1993) on its values? --- Jura 12:18, 4 February 2020 (UTC)
  • @Jura1: This would suffer from exactly the same issue as the existing property: Many symbols can't be entered (correctly). That's how I chose the examples: 3 out of 4 can only be entered if the datatype is mathematical expression, thereby demonstrating the need for this new property. Toni 001 (talk) 14:41, 4 February 2020 (UTC)
    • Sorry, somehow I missed that TeX string (P1993) has string datatype. Should have double checked that. Let's move ahead with this. --- Jura 05:37, 6 February 2020 (UTC)
• @Toni 001, ديفيد عادل وهبة خليل 2, Swpb, ArthurPSmith, Pintoch, Jura1:  Done --Tinker Bell ★ ♥ 04:14, 17 March 2020 (UTC)