parts per thousand
I've been wondering about the difference, too. So far I have not found a source which explains well the difference. I have the feeling that they, while having the same numeric value, are used under the name "per mille" or "parts per thousand" depending one the discipline. The former has symbol ‰, while the latter uses ‰ or is spelled out, but some disciplines do use "ppt" despite its ambiguity (thousand vs. trillion).
It's not uncommon for units to appear under different "names". For instance, coulomb and ampere second are both units of electric charge with a conversion factor of 1. They are equal but not the same. In Wikidata we have been preserving such "duplicates" which I think is good.
I'd say that they could also have a said to be the same as (P460) statement.
Good afternoon! Thanks a lot for your Coherent SI units. I will start to contribute to norwegian nynorsk (nn) and norwegian bokmål (nb). Related to this I do have a question about decimals after comma. Have any idea how to adjust decimals after comma in such a way that it can be with two decimas only. Example https://no.wikipedia.org/wiki/Avondale_(Arizona) have a localy statement in the land area in the infobox. In norwgian wikipedia the infobox picks up the land area from WD and displays it as 117,380821 https://no.wikipedia.org/wiki/Avondale_(Arizona). Breg
Hello @Pmt. Thanks for your contributions; I just saw some of your additions on my watchlist.
About your question: Rounding to a lower precision does make sense. I don't have experience with how those infoboxes work. Probably the author of the infobox would be able to help.
Toni: It's the same as :en:Template:Wikidata (:no:Mal:Wikidata). The template now get the long decimals, wich is kinda too much for a small article. I dont know if that helps. But thanks anyway.
Deutscher Eintrag für Circumference
Hi Toni 001, ich verstehe nicht ganz genau, was hier passiert ist: einige löschen, die anderen ändern. Aber letztendlich fehlt ein deutscher Eintrag für den Begriff "Circumference". Ich hatte "Kreisrand" vorgeschlagen, weil es so angenommen wird aber ich denke, du hast es gelöscht. Falls es der Name dir nicht gefällt, kannst du auch Kreislinie oder ähnliches nutzen aber bitte lass dort einen deutschen Eintrag bei "Circumference", ich sehe es als notwendig. Danke.
Hi Yeshua Saves. Wie es aussieht, wurde der Artikel zu "Kreisrand" im Deutschen Wikipedia gelöscht. Aber dennoch, die Bedeutung eines Wikidata Elements sollte so präzise und eindeutig wie möglich sein. In der Einleitung des Englischen Artikels ist von einer Länge die Rede. Diese Bedeutung würde mit "Kreisumfang" ins Deutsche übersetzt. Da "Kreisumfang" und "Kreisrand" verschiedene Dinge bezeichnen, sollten diese nicht dem gleichen Wikidata Element zugeordnet werden.
Alles klar, dann bitte mach einen Link zu der deutschen Begriff, weil es fehlt noch. Siehe meine Diskussion auf der Seite von Circumference. Alles Beste.
Die Deutsche Wikipedia scheint keinen Artikel zu "Kreisumfang" zu haben, nur eine Weiterleitung zu https://de.wikipedia.org/wiki/Kreis#Umfang. Man kann von Wikidata aus keinen Link zu einer Weiterleitung setzen.
Schade. Das habe ich bemerkt, als ich versuchte "Circumference" mit "Kreis#Kreisflächen" zu linken. Ich finde noch unbefriedigend, dass es keinen deutschen Link bei "Circumference" ist: ich bitte um Lösung. Vielleicht sollte man "Kreisumfang" zu einem eigenständigen Artikel machen. Sei gesegnet.
We sent you an e-mail
Really sorry for the inconvenience. This is a gentle note to request that you check your email. We sent you a message titled "The Community Insights survey is coming!". If you have questions, email firstname.lastname@example.org.
You can see my explanation here.
kilometre v. kilometer
you replaced a recent edit I made, changing the en: version of kilometre (Q828224) back to kilometre. It seems that the british spelling is kilometre, am I wrong?
Hello. Yes, "kilometre" is British English and "kilometer" is American English. Before your edits, "kilometer" was already an alias and after your change, only the American English version remained as both label and alias.
@Trilotat: I just noticed that you changed the label of (kilo)metre to American English. What's the reason for this?
Isn't it acceptable for kilometer to be the English label if kilometre is the alias (and the reverse in British English)?
Maybe I'm on a slippery slope since there is theatre and so many other words with such ending. Ugh..
Correct. But why swap the two? So far most units containing metre/meter use BE as label. I think that using consistently either the one or the other as label is good.
I'm reverting my changes. Thanks for the engagement.
You changed spellings in labels from British to American because you're in love with Donald Trump. You might deny this, but no one will believe your denial.
Jc3s5h, that's absolutely not appropriate or relevant. I appreciate your reverts of my changes. but let's keep the discussion apolitical.
I will admit that I approached this from an American-centred perspective. I acknowledge that's a flawed perspective in this situation and have learnt from my error. See... I'm trying.
Fyzikalna casť chyba...:? Tab E
Vznik (zapalenie slnka)?:)moj nazir s vysvetlenim z fyzikalneho hladiska co zatial neni teoria predpokladu v osnovach
Otvor tab E farebna zloska
Unfortunately I don't understand your language or the machine translation of the question.
In a few more days I'll have finished a script I'm working on to cross-check all units entities for consistency, and fill in certain missing information (for example, measured physical quantity (P111).) So if you don't mind waiting, you can save yourself some work. (Or, if you want to make sure that your new entries are as complete as you can make them from the get-go, carry on. :-) )
Thanks for your effort. Having independent contributors cross-check and extend the data either manually or with the help of a program is invaluable for the quality and completeness. I'm looking forward to see your contributions.
About P111: Verifying the consistency is pretty straight-forward when both the quantity and the unit item have sufficient "machine readable" data like unit conversion, dimension, links to other quantity and unit ontologies and so on. But judging the correctness is harder, because those involve conventions, like newton-metre measuring torque, but not energy, even though from the dimensions that would be OK. Another tricky case: Gray measures absorbed dose and kerma. Rad also measures absorbed does, but I haven't yet found a reference to it being used to measure kerma.
I just came across another tricky case: I had never realized it, but luminance (Q355386) and illuminance (Q194411) are two different, albeit dimensionally equivalent, quantities. I'm still checking, but I think our units for these are not quite all perfectly tagged and may need some cleanup.
I think this sort of case is even harder to think about because it's not always consistent whether there are different units for different quantities or not. You mentioned torque and energy, which have different units. Impulse (Q837940) and momentum (Q41273) basically have different units. And yet electrical resistance (Q25358), impedance (Q179043), and electric reactance (Q193972) are all unapologetically measured in ohms (Q47083). (There's also voltage (Q25428) and potential difference (Q3707379) both measured in volts (Q25358), altohough I'm starting to think Q3707379 may be a mistake.)
Hi Toni 001,
I noticed your message on Wikidata project chat page, which led me to look up your profile. Thank you for all the work!
I’m reaching out to you because I’m working on a research project about understanding what motivates editors like you to contribute to Wikidata. We’re also interested in learning about how you feel your contributions are being used outside of Wikimedia community. Since you are such an active community member, I thought you might also be interested in helping to build the broader community’s knowledge about Wikidata, and why it matters.
If you’re interested, let’s schedule a time to talk over Zoom, or whichever platform you prefer. You could reply here or fill in a questionnaire, whatever works for you. The conversation should take about 30 min.
Hope you have a great day,
Your research poses interesting questions and I think that the result will be valuable for the Wiki projects.
I've been with Wikidata since the beginning and started contributing actively about one year ago.
I accept your invitation. I'm flexible with the interview times, preferably daytime in Europe.
Thank you for accepting the invitation! I have sent you an email with several time slots for you to pick.
modeling compound units
I expect I'll ask this question in a broader forum soon, but I thought I'd ask you first: have you thought about the problem of explicitly expressing units like volt ampere (Q550341), cubic metre per second (Q794261), and joule per square metre (Q80374519) in terms of their constituent base units? Obviously conversion to SI unit (P2370) doesn't work for this, and what's needed is basically some kind of expression syntax. (There are defining formula (P2534) and unit symbol (P5061), of course, but those are both presentation forms, not really machine-readable expressions.)
What you are asking for effectively amounts to expanding, in an given unit, all the named unit combinations (for instance, joule to m^2 kg / s^2) and simplifying fractions. The resulting expression corresponds to the dimension (P4020) for the quantity which is measured using that unit. So, if you want to figure out that volt ampere and Watt are basically the same (ignoring conventional restrictions), you can compare the dimensions of the corresponding quantities and the conversion to coherent SI unit (P2370, see also my proposal there to include the adjective "coherent" somewhere in the label or description).
I acknowledge that strictly speaking, P4020 is not machine readable, because it is entered (by users) in LaTeX, which is a presentation syntax.
Temperatures are a different topic: Conversions require a factor and an offset, while P2370 only stores a factor.
Thanks for your thoughts.
You're right, ISQ dimension (P4020) is the closest thing we've got to what I was asking about. For several applications it's quite sufficient. In the best of all possible worlds I do wish there were a good way to list an explicit derivation explicitly for each Q47574 (e.g., metre per second (Q182429) = Q11573 ÷ Q11574), but choosing (or more likely inventing) just the right datatype to support using expressions as wikidata values is a formidable problem, so I think I won't hold my breath.
The data encapsulated in P4020 is constrained enough that I do consider it machine-readable. I've only found one case so far that my straightforward little parser can't parse.
Another problem I'm not racing to solve right now -- it can certainly wait -- is the "affine" transformations one needs for temperatures. I can imagine doing it using arbitrary expressions, and I can also imagine doing it in a more constrained and special-cased way involving at most a single 'offset' value.
As a fan of units I imagine you're well familiar with the GNU Units (Q3093305) program. I've been amazed to discover recently some of the boundaries it has broken as compared to the traditional Unix implementation (not just affine transforms, but arbitrary fuctions, and even table interpolation...).
Also as a fan of units I hope you read xkcd last week!
The unit symbol of millibar is mbar. It's a pity xkcd got that wrong. But funny anyway, thanks for sharing. I'm not familiar yet with GNU Units. So far I've been using mostly the WL for checking the consistency of the Wikidata units and quantities.
I love units too, but is petaradian (Q94414053) really a useful unit?
Hello @Scs. This particular unit does not seem useful (to me, and as it seems neither to you).
I created it in a systematic effort to cover extensively certain unit combinations. Last year I added all combinations of SI base units (of which there are seven) with all possible prefixes (of which there are 20).
Recently I continued to add combinations of SI units with special name (of which there are 22) with prefixes.
I acknowledge that a certain faction of those combinations in not (ever) used in practice. However, I repeatedly stumbled over certain units that were not yet in Wikidata. Having to add a unit whenever the need comes up is more cumbersome and error prone than doing a well-thought-through batch (due to the human mind forgetting certain details as times passes).
Fair enough. Thanks for the reply. (And I won't say anything about petasteradians... :-) )
Nice to see various users being interested in units, too.
@Scs: Your comment kept me thinking. Since you mentioned it, I've been adding (from the batch explained above) only units that I can find mentioned anywhere on the internet (some frequent results include Wiktionary). This might leave 50ish not-so-notable units from the batch of 440. I'm going back and forth about whether to add them or not. Let me know if you have any strong arguments or opinion. Currently I tend to think that we should just add all of them: Even if, say, gigaradian is not useful on its own, it might appear as part of some angular velocity unit. Apart from that, having this batch complete will facilitate certain consistency check queries.
Thanks for asking. Here's my opinion. (But it's only that, an opinion.)
Since units are productive, we can never list all of them, and I don't believe we should try. Anyone who is doing any serious work in metrology should be (I'd really go farther and say must be) using a program like units(1), not a static database of units. So I don't believe there's a reason for us to have explicit entries for units that can be trivially, unambiguously, and mechanically derived via prefix+base unit combinations. I don't believe there's a use case for why a user would be looking up a "useless" unit in Wikidata in the first place.
So yes, I believe in explicitly listing only the "useful" units, not every possible combination.
But: Those words "useful" and "useless" are of course just about purely subjective, so I'm not going to complain (beyond questions like the one that started this thread) if someone enters some units that I don't find useful. They don't cost me much, and they don't cost Wikidata much, either.
With regard to consistency checks: I'm not sure what you have in mind, but I certainly wouldn't add extra units just for that reason. I myself am working on a reasonably comprehensive set of scripts to cross-check Wikidata's units against units(1) and other databases, and since units(1) is of course a program that's more than a static database, I trust it to play a part in double-checking Wikidata's units entries whether Wikidata's units entries are "complete" or not.
(Actually, I guess I can imagine what you have in mind: since it's so hard to define "useful", and if you do want to have explicit entries for, at least, all the prefix+SI base unit combinations, it's much easier to make sure we have all of them if the working definition of "all of them" is the full MxN set.)
With all of that said, where explicit entries can be useful is when the "trivial, mechanical" derivations are not so unambiguous, after all. In my own work, I've decided it's okay to use mechanical productions for fully-spelled-out prefixes like kilo, milli, and mega, but not k, m, and M. The abbreviated prefixes just have way too many possibilities for ambiguity. So my own units database (the one I'm building to help me cross-correlate Wikidata, units(1), and others) has explicit entries for km, mm, cm, etc., even though my programs have no problem parsing (just as units(1) does) forms like "kilometer", "millimeter", and "centimeter". So to the (admittedly rather narrow) extent that Q94414053 ties together the parseable string "petaradian" and the potentially more ambiguous string "Prad", I can agree that it has some scrap of utility, after all.
(You're probably familiar with UCUM. I've been intrigued by its explicit use of a "metric" flag, to reduce ambiguity by limiting the unit names to which metric prefixes are allowed to be applied)
For the well-defined subset of 440 SI units formed by combining any prefix with any of the 22 SI units with special name, by simply adding all of them, we can avoid the question about notability that would otherwise have to be asked for each of them. I'm not planning to add all units, of which of course there are infinitely many.
One point I haven't made explicit yet: My motivation is not primarily to store the conversion factors. Those are - as you mention - trivial. The more important aspect that I'm after is having a stable identifier for each unit that could possibly be used anywhere. That starts with Wikidata itself, which requires a unit-item to exist before a quantity-valued statement can be made using that unit. When we add statements from a reference then we should be as faithful as possible, which includes using the unit used in the source, with the understanding that a user of that data can express the same value in any other unit they like (given the appropriate tool or SPARQL query).
In the long term I foresee Wikidata unit-items being used in other contexts: For instance in Wikibase installations inheriting Wikidata (unit and other) items. But more generally, any RDF dataset could use Wikidata unit-items (QUDT is another example of an RDF unit ontology with a similar goal). To facilitate such use Wikidata should be as "complete" as possible in terms of unit coverage, and here "complete" could be defined as "any unit mentioned anywhere" (potentially excluding articles created for the sole purpose of mentioning weird units by someone reading this comment).