Wikidata:Property proposal/relative atomic mass

relative atomic mass edit

Originally proposed at Wikidata:Property proposal/Natural science

   Not done
DescriptionThe average mass of single element atoms in a given sample or source. Made relative (dimensionless) by division by carbon-12 mass. Is not: atomic mass (not unit Da or u).
Representsrelative atomic mass (Q41377)
Data typeNumber (not available yet)
Domainchemical element (Q11344), when standard atomic weight is not applicable
Allowed valuesnumber
Allowed unitsnone (dimensionless value)
Example
  • Ar(B) = 10.8185(±1.5)
(My rough reading from CIAAW (2106), fig 3: boron-bearing materials, Evaporated sea water. DePiep)
SourceCIAAW (2106): before going into their limiting requirements, this Report describes the general way of determining the value.
Planned useCan be added to 34 elements (118 − 84 elements that do not have a standard atomic weight assigned). Also for items that are a sample (moon rocks?). Can be used in periodic table overviews, could use an annotation.
See also
Motivation

The relative atomic mass is the general physical quantity (symbol Ar) for element's mass. Its value is dimensionless. It is written Ar(E) for element E, e.g. Ar(Tc) = 98. An uncertainty range might be added, written like "98(3)" or otherwise.

The quantity is best known in a more specified, qualified form: the standard atomic weight for elements (say Ar, standard). That specification is maintained by CIAAW (an IUPAC commission), and limits the samples to being: terrestial, natural, stable, well-handled, well-researched. Now the task is to explain: if the value is not a CIAAW authorised standard value, don't use the word 'standard' or 'CIAAW'. The separate property 'standard atomic weight' (proposed) allows for keeping these two apart.

For all situations that are not within the scope of the CIAAW standard, the general Ar should be used. For example, for the relative atomic mass of an element in -

Moon rocks (not terrestial)
Elements with instable isotopes only like polonium (not stable)
Single source research contributing to the CIAAW calculations (by itself not representative for the whole Earth)
Enriched uranium (not natural).

DePiep (talk) 16:35, 9 March 2017 (UTC)[reply]

Discussion
Then defer and wait or work to get clarification, I'd say. How is your understanding the lawmaking rule? -DePiep (talk) 06:34, 14 March 2017 (UTC)[reply]
  •   Oppose Oh I think this is clear enough, but it is not needed, if I understand the issue. First of all, to address the "moon rock" concern, simply attach a qualifier to the value indicating the origin of the mass evaluation (as well as a reference). The same can be done for specific terrestrial sources that differ from the usually asserted average. Secondly for short-lived radioactive elements, there IS no reasonable way to define a standard mass, as whatever isotopic collection we have is purely artificial and could be anything. For specific isotopes we already have mass (P2067) and the basic "A" integer value can be obtained as the sum of atomic number (P1086) and neutron number (P1148). I think the problem here is DePiep is under the impression that the "standard weight" property needs to be purely the value provided by CIAAW - yes we do something like that with our external identifier properties, but for quantitative values properties need to be generic: any authority that asserts a "standard average weight" should be allowed to provide that value for the property, with a reference (and possibly a qualifier) asserting the source or type. Properties for physical quantities should never be limited to a single source. ArthurPSmith (talk) 17:26, 13 March 2017 (UTC)[reply]
Ouch, had to correct subject item into relative atomic mass (Q41377). Will reply to ArthurPSmith here later. -DePiep (talk) 18:32, 13 March 2017 (UTC)[reply]
re ArthurPSmith. Several issues.
1. This proposal, relative atomic mass relative atomic mass (Q41377) is a true physical quantity, symbol Ar (or r.a.m. here). Do not confuse this with standard atomic weight.
2. DePiep is under the impression that the "standard weight" property needs to be purely the value provided by CIAAW. Yes I am. And so is the IUPAC community (the CIAAW parent organisation). CIAAW/IUPAC is the one and only authority to publish standard atomic weight (Q28912964) (s.a.w. here, or Ar, standard as I can write it). Note: keyword is "standard", which is used only in this meaning & context, in this environment. Of course, when the s.a.w. itself is the topic of discussion, this limit is relaxed. More background: en:Standard atomic weight (I started recently).
3. The proposal/quest is to add s.a.w., r.a.m. or both as a property. Now, and only now, Wikidata comes in play. I want to learn why this would not be a good addition, but so far I don;t understand the reasons for rejection.
4. IIReadC, ArthurPSmith proposes to use mass (P2067) to store a mass with an element (as is done with the mass number for an specific isotope). Now P2067 is a mass. Suppose a value+source is entered correctly, how can the reader (aka infobox, or external data consumer), how can that consumer be sure to have the right mass? Must is do an interpretation of the source? How to ask for a certain mass value (while there may be an other one, or more).
Example in case: helium (Q560), today. Has "4.003±0 atomic mass unit", and "mass=4.002602±0.000002 atomic mass unit". (at the moment, I can not read the reference); (note that "standard atomic weight" value is *not* in there). So: How do I get out the value I want to know? Somehow I must be able to differentiate between available masses. -DePiep (talk) 17:56, 29 March 2017 (UTC)[reply]
For some reason I could not remove (edit) that unit "atomic mass unit", and not add Qualifier="standard atomic weight", because ... that qualifier must be a property. Circular now. -DePiep (talk) 18:17, 29 March 2017 (UTC)[reply]
Done, crudely. PubChem is not an OK source. -DePiep (talk) 18:44, 29 March 2017 (UTC)[reply]
perhaps using the source/reference relationship is not the right way to go; however, there are a huge number of properties where we do exactly this sort of thing using qualifiers, so that there are several claims for the same property with different values. For example population data is given with a "point in time" qualifier, and many geographical locations in wikidata have multiple population claims depending on the year - see for example the population section of California. Given that this and your other proposed "standard mass" properties would only apply to a very small number of items (at most the 118 elements) I really don't see a need for more than (at most) one new property, with appropriate qualifiers describing the determination method (P459). ArthurPSmith (talk) 18:07, 30 March 2017 (UTC)[reply]
  •   Oppose. The trio of proposals is confused and duplicative of mass (P2067). The proposals want the quantity to be a pure ratio (i.e., number), but that ratio is just the [atomic mass]/[some standard atomic mass unit]. In other words, the unit of measurement for atomic mass is [some standard atomic mass unit]. mass (P2067) can use dalton (Q483261) (u or Dalton). The topic is about a physical quantity, so having units attached to the value is a plus; a normalized value query (psn:) should work. We don't want one dimensionless property for temperature ratio to one °R and another for temperature ratio to one Kelvin. Another fracture line of the proposals is tying the properties to how the numbers are specified. The "standard atomic weight" proposal is supposed to be an interval, the "conventional atomic weight" proposal is supposed to be a single number derived from "standard atomic weight", and "relative atomic mass" is the "standard atomic weight" for nonstandard situations. Quantities already do that. For the first case, one can query P2067 for wikibase:quantityLowerBound and wikibase:quantityUpperBound to get an interval. For the second case, use wikibase:quantityAmount to get a single value. For the third case, there is no requirement that P2067 must be restricted to a particular source's definition. Yes, there is confusion about what upper and lower bounds may mean (what confidence level), but that problem exists throughout the project. And yes, there is a distinction between an average atomic mass of a sample and the mass of actual atoms. These proposals don't address that population issue. Glrx (talk) 20:13, 5 August 2017 (UTC)[reply]
How to save & retrieve a physical quantity
  • This is core physical quantity stuff.

So I have this real-life quantity (from scientific sources), and I think Wikidata (WD) should be able to receive & present that (store it, and let info-consumers read it). If I understand ArthurPSmith well, it cannot be stored as I'd expect (not some 1:1 copy), but we should store it as a mass (P2067).

I will not go into "how to save that numeric value in a property" here (see nearby).
As ArthurPSmith described, the WD-property mass with datatype Quantity can store a mass somehow. However,
A. It does not allow for the quantity name/symbol/identifier/QID. It only has "number unit" input option. One can not specify: this value is the "mass at takeoff" or mass "Ar". AFAIK, with a certain mass value (property) I can enter the source but I can not enter the appropriate quantifier:Qxxx.
B. How can an info-consumer (a wiki infobox or an external site reading & using this WD property), how can it ask specifically for item's "mass at takeoff" or item's "Ar" mass (existing, entered)? As I read ArthurPSmith here, that infobox must make an interpretation of the masses available in the item.
C. While being a "mass", it does not require the dimension of mass (e.g., also allowed is: x kg/mol). This is where the Property "mass" loses being "the physical quantity mass". Could be fine, but this shifts a bit of WD data philosophy off to the true 'mass'-reading infoboxes (...is how I feel it ;-) ).
Z So far, I get the impression that main physical quantity notation in WD (think BIPM and SI-brochure) is lacking. I'd expect that when I add a quantity value (number×unit), at least I can (should) specify its quantity definition/name/symbol/QID.

@ArthurPSmith, Pigsonthewing: -DePiep (talk) 21:55, 16 March 2017 (UTC) — -DePiep (talk) 23:22, 16 March 2017 (UTC)[reply]

Physical quantities primer edit

  1. quantity = value
    value = number × unit (unit has the dimension, number is a number)
  2. quantity name = number × unit name
  3. quantity symbol = number × unit symbol
  4. quantity symbolspecified = number × unit symbol
Examples:
Speed: v = 10 km/h
A more specific quantity: specify the quantity (not the unit km/hmax)
Max speed: vmax = 10 km/h

Notes:

Habit: quantity symbol is in italics: v. One rarely sees this symbol (outside tables and graphics). In written language, the name is used: "The speed is ...".
"dimension" is a product of seven independent dimensions (time, distance, ...). As in: dimension of speed = distance/time.
Note that the dimensions are not predicting a certain unit. Both mile and km are OK for a "distance" dimension.
The "×" operator symbol is usually omitted. Still: a product it is.
The formula is algebraic, on purpose. A great feature! For example, we can 'cross out' sames above and below the deviding slash (as with all math: must be done correctly...):
7 h × 10 km/h = 70 h×km/h = 70 km
Special case: dimensionless. Then the unit = 1 (not: absent; not: 0). The value is, still algebraic: number × 1
-DePiep (talk) 21:55, 16 March 2017 (UTC) — -DePiep (talk) 23:22, 16 March 2017 (UTC)[reply]
@DePiep: Now you've lost me. Have you read WD:Q? If something can't be handled using appropriate qualifiers then sure we can define new properties to handle it - and I think at least one standard atomic mass property of this sort would be helpful. As to data entry - if you define something as a string datatype you can put whatever you like into it, but that greatly limits reusability and also user expectations (that quantitative values should involve a number, not a string). Wikidata numbers are arbitrary precision, so that shouldn't be an issue. ArthurPSmith (talk) 23:39, 16 March 2017 (UTC)[reply]
re 1: No I had not read or seen WP:Q ever. That is because I am struggling for months to find plain equivalents WD pages for my familiar enwiki pages like the village pumps and documentation. Months? A year. No-where-ever did I came across a useful link, (enwiki does not have a relevant WikiProject --unless 2015 is ok-- and WD is four years old now? Compare Lua introduction), never got a useful link until some WD smarty comes along and links it, always while blaming me for not knowing it. That is WD for me. I did my very best to write this contribution, and maybe you might consider digesting it. I claim that this post about SI and physical quality deserves a better reading (see Z). You actually did not reply my core points, you just wrote a 'how to use a WD-property'.
re 2: I did not mention it in my replies, because it is a non-issue here. In this proposal any "standard atomic weight" is not relevant and it is too confusing. Ar, the quantity "relative atomic mass", is the topic. (that 'standard atomic weight' is the most well-known specific form of it, Ar, standard, but the topic is: quantity-in-WD). Please do not use 'standard atomic weight' again in this discussion this way.
re 3: You are talking 'string' datatytpe. I said: that is not the issue.
re 4: shortest: adding a mass property value to hydrogen, I could not add quantifier for that mass (value): "relative atomic mass (Q41377)"  – The preceding unsigned comment was added by DePiep (talk • contribs) at 00:39, 17 March 2017‎ (UTC).[reply]
@DePiep: when I said "you've lost me" I meant I no longer understand what you are trying to do here. I have read what you wrote, I do not follow the logic or see a clear action needed or proposal here. Given that you have been using Wikidata for longer than I have (I started in fall 2015, you apparently in fall 2013) I am also confused at your unfamiliarity with basics. "Project Chat" is the "village pump" here and you have posted there several times over the years. wikidata is not enwiki, but we do have "Help" pages of various sorts, listed on Help:Contents (which is linked via "Help" in the navigation bar on every page here). If you find them inadequate you are free to improve them or ask for help in so doing, there is also an RFC process. I find the watchlist functionality very useful. Not sure what else I can advise or help with here. ArthurPSmith (talk) 20:44, 20 March 2017 (UTC)[reply]
Sorry, that was my frustration taking over for me not getting all this. You deserve a better reply. Later on. -DePiep (talk) 11:18, 21 March 2017 (UTC)[reply]

@DePiep, ArthurPSmith, Gstupp, Benjaminabel:@Pigsonthewing, Glrx, Gstupp, Willighagen, Walkerma: Not done, given that this proposal has gotten stale. If you are still interested in a property for this purose feel free to create a new property proposal. ChristianKl (talk) 18:40, 1 November 2017 (UTC)[reply]