Glrx

Atomic weight

FYI: the atomic weight (aka standard atomic weight) is defined & published by IUPAC (CIAAW commission), ans is quantity A_r (relative). So it has no unit. As the source says. -DePiep (talk) 22:13, 3 August 2017 (UTC)

mass (P2067) is a mass; it is not a relative mass. Most unit systems (including SI) have a dimension of mass. The wikidata field is mass. Look at the ref you cited; the masses are relative to u. The table columns are "atomic mass/u" (which is a relative number -- relative to u). The columns are not "atomic mass".

Look at this query

SELECT ?item ?itemLabel ?atomnumber ?val ?unit ?unitLabel
{ 
  ?item wdt:P31 wd:Q11344 ;
        wdt:P1086 ?atomnumber ;
        p:P2067 ?stmt .
  ?stmt psv:P2067 ?val .
  ?val wikibase:quantityUnit ?unit .
  
  SERVICE wikibase:label {
     bd:serviceParam wikibase:language "en" .}
} ORDER BY ?atomnumber

try it

All the units column are dalton (Q483261) except for your revert at silver (Q1090).

No doubt there are other masses that cite to IUPAC.

If you want, you can argue that AMU is not "u", but then we need an IUPAC version of dalton (Q483261).

Glrx (talk) 22:49, 3 August 2017 (UTC)

No. The source you want me to read (did you yourself?) never ever has a unit for A_r values. Of course not! (hint: the subscript r actually is there to say: "relative", in this case: divided by the unit mass, i.e. no unmit = no dimension). Unless you point to the contrary in that source (btw, a more recent source is CIAAW 2013 -published 2016-, but alas. Same fact).

I'm not interested in Wikidata dancing around the mass property definition: been there, got send away, people keep telling nonsense like you do. enwiki is better. (Actually, I recently created & improved en:Standard atomic weight. Worth reading!).

The fact that the Wikidata mass property is not relative, is a WD error or limit or whatever. It is not an atomic weight fact. Keep happily adding a unit to the standard atomic weight of silver, but you're still wrong each and every time.

Correct is: A_{r, standard}(Ag) = 107.8682(2). As enwiki writes. -DePiep (talk) 00:03, 4 August 2017 (UTC)

Notes: I've run the query you provided. So you say: because WD adds that unit for all, it must be OK? That's reversed order, we should follow the source, not redefine it. The standard atomic weight (A_r) is defined to be dimensionless (no unit, or unit=1) in the one and only defining source. That WD cannot handle that, does not allow WD to change the definition. My proposal Wikidata:Property proposal/standard atomic weight was turned down, for reason that is should be entered in mass (P2067) somehow (which cannot be done for being dimensionless; could be a recently added limitation by adding the dimension requirement).

BTW, the PubChem data in element's mass (P2067) is wrong. For silver (Q1090), 106.905 u is an isotopic mass or so. So should not be in that item suggesting a standard atomic weight. Could be that the query you provided shows even worse errors (only a wrong PubChem value, not a s.a.w.-related value as at least silver has).

"other masses that cite to IUPAC" - the s.a.w. is defined by IUPAC (both its definition and the element values), not just cited from. Who is WD to change their definition? Just a question: which "other mass" is or could be tied to an element (is not an isotope)?

The property we want to enter is standard atomic weight (Q28912964). Refacturing the value is making WD pushing wrong data into the world (who reads or does or understands: "to get the correct s.a.w. for this element, multiply this mass value by u^-1"). -DePiep (talk) 12:12, 4 August 2017 (UTC)

Followup: three property proposals were declined:

• Wikidata:Property proposal/standard atomic weight
• Wikidata:Property proposal/conventional atomic weight
• Wikidata:Property proposal/relative atomic mass

Glrx (talk) 19:31, 25 November 2017 (UTC)

Typeface

I see you have changed the class structure of the typefaces. After a second thought I am not really sure about the best ontology around typefaces. Have you discussed the issue with others? — Finn Årup Nielsen (fnielsen) (talk) 10:50, 2 November 2018 (UTC)

@Salgo60, Grendelkhan, Spinster: I see that you have edited the ontology around typefaces. Do you have any opinion? — Finn Årup Nielsen (fnielsen) (talk) 10:55, 2 November 2018 (UTC)

Sorry not skilled in this area put together something a year ago to be shown in Histropedia tweet - Salgo60 (talk) 10:58, 2 November 2018 (UTC)

The ontology had inconsistent types. There were many items (e.g., Adobe Jenson (Q865653)) that claimed instance of (P31) typeface (Q17451) but also claimed subclass of (P279) of Serif (Q243449). However Serif (Q243449) is subclass of (P279) typeface (Q17451). Which is it? Is the item a instance of a typeface or is it a subclass of typeface?

All I did was change P279 of the subclass to P31 of the subclass and remove P31 of the class. I kept the ontology.

To put it another way, if someone asks for all subclasses of typeface, should individual typefaces such as Adobe Jenson (Q865653) show up?

• ?subc wdt:P279* wd:Q17451 .

If you want a list of typeface instances, then this works

• ?typeface WDT:P31/WDT:P279* WD:Q17451

I did some other changes. Liberation fonts (Q245722) described itself as a set of four typefaces, but then it claimed instance of (P31) typeface (Q17451). Is it an instance of a typeface or a set of typefaces? Especially when Liberation Sans, Liberation Sans Narrow, Liberation Serif, and Liberation Mono are all P31 typeface. Is an instance of a typeface also a set of typefaces?

There's still a mess I did not touch. Tahoma (Q910757) and humanist font (Q2512884).

Maybe the typefaces should have qualifiers rather than subclasses, but the subclasses were there already.

Glrx (talk) 17:07, 2 November 2018 (UTC)

What precisely is a "typeface"? I am no expert. I note that there is something called Garamond. But then you have ITC Garamond and Adobe Garamond which seems to be typefaces. If we take a car model as Toyota Corolla (Q243543) then it is a instance of (P31) of automobile model (Q3231690) while a subclass of compact car (Q946808). If we translate that to typefaces then it seems that the ontology for Adobe Jenson (Q865653) should be the original. — Finn Årup Nielsen (fnielsen) (talk) 15:20, 4 November 2018 (UTC)

Deleting vs Deprecation

Hi. I noticed you have been deleting referenced statements, which you should never do here at Wikidata. For example, in this edit. You should either retain the statement (if it was at any time correct) or mark it as deprecated (if it was never correct). In this example, Sidney Smith commanded several large scale land operations, so military commander would be a reasonable description of one of his occupations. From Hill To Shore (talk) 07:13, 30 April 2024 (UTC)

I also see that you have been deleting deprecated statements, such as in this edit. Deprecated statements should be retained, see Help:Deprecation. From Hill To Shore (talk) 07:21, 30 April 2024 (UTC)

Thanks for note.

Military commander is a generic term; naval officer is more specific. The reference was retained, but the claim was tightened. The reference describes him as an admiral (a naval rank). Although he commanded some land forces, his military branch was Royal Navy.

I see many occupation claims as type errors. The occupation is a naval officer. The officer may hold a position such a particular command. Similarly, an officer may hold different ranks, but admiral is a rank rather than an occupation. The translated Czech source says his profession was an admiral. That's a poor translation or an imprecise statement.

Deprecated states

Statements in Wikidata should be ranked as deprecated (and not removed) if they are:

superseded (as opposed to "outdated"; see note on 'end date', below)

now known to be wrong, but were once thought correct

That does not fit with your summary of deprecate an item if it was "never correct".

The deleted dates for Painter were low precision and did not cite any sources. The retained date was a sourced claimed. Why keep an unsourced claim.

I have no problem leaving sourced conflicting dates.

Glrx (talk) 08:32, 30 April 2024 (UTC)