Wikidata talk:WikiProject Physics

From Wikidata
Jump to navigation Jump to search

Multilingual discussion page

Feel free to participate in any language you want to.

Classification of isotope[edit]

I was wondering how we can link the different isotope between them. Using instance of (P31) we can create an item QXXX represent an element with X protons then for each isotope we create another item QYYY which is a instance of/subclass of the main item. QXXX has no physical reality but is the conceptual element. What do you think ? Snipre (talk) 11:44, 16 October 2013 (UTC)[reply]

Once number datatype is available we could make queries for "all items with same number of protons". I am not sure if a separate property would be needed. --Tobias1984 (talk) 12:13, 16 October 2013 (UTC)[reply]
There is no new property there. TomT0m (talk)
This is the way to go, 1H is a subclass of hydrogen as any 1h atom is an hydrogen atom, and 1H is an instance of isotope of hydrogen (Q466603). TomT0m (talk) 16:34, 16 October 2013 (UTC)[reply]
Sounds good. First we need to get all the isotopes in order and get rid of all the duplicates. --Tobias1984 (talk) 17:43, 16 October 2013 (UTC)[reply]
Ok, so with the list of current items
What kind of links can we create for them ? Snipre (talk) 19:37, 16 October 2013 (UTC)[reply]
There are more already more items for hydrogen: Wikidata:Physics_task_force/List_of_nuclides --Tobias1984 (talk) 19:49, 16 October 2013 (UTC)[reply]
@Tobias : not first, adding the statements is actually helpful in curating the datas and find duplicates ;) . TomT0m (talk) 08:50, 17 October 2013 (UTC)[reply]
Ok both :) Because Dutch Wiki has a lot of isotope-items but we have to find them in order not to create hundreds of duplicates. And adding the statements can be done in one run ;) --Tobias1984 (talk) 09:03, 17 October 2013 (UTC)[reply]

protium[edit]

Hi! should we use said to be the same as (P460) for hydrogen atom (Q6643508) and protium (Q15406064) ? Some languages as fr.Wikipedia have two articles. gangLeri לערי ריינהארט (talk) 12:07, 3 May 2014 (UTC)[reply]

@לערי_ריינהארט: I think if there are two pages then hydrogen atom refers to the properties of the chemical element with one proton and one electron, and protium refers to the properties of the nuclide with one proton. I wouldn't use said to be the same as (P460) for this relationship. Tobias1984 (talk) 15:03, 3 May 2014 (UTC)[reply]
@Tobias1984: Is there a property to "show" that there are more items describing different "views" of the same "object/subject". It could be used also for WD items starting with "outline of ..." (many exists at en.Wikipedia), some "history of", and other similar places where "main article" is used (also mainly at en.Wikipedia). Such situations could occur also at descriptions relevant to a specific culture; one may expect more articles in the corresponding language then in the 250+ other languages. לערי ריינהארט (talk) 15:26, 3 May 2014 (UTC)[reply]

@לערי ריינהארט: There is facet of (P1269)--Malore (talk) 14:22, 12 May 2018 (UTC)[reply]

Evaporiative cooling (machine and ultra-cold matter physics)[edit]

I found three wikidata entries: magnetic evaporative cooling (Q6731539), evaporative cooler (Q1896787) and Q2514471. They seems to describe either the technical devices (like air-conditioner) or the ultra-cold matter aspect (btw: both rely on the same physical principle). So three wikidata entries and two subjects. Any suggestions what to do? Merging? Merging what to what? I already moved the german articles. --Nobelium (talk) 18:26, 12 August 2014 (UTC)[reply]

@Nobelium: I think we should move this discussion to Wikidata:WikiProject Physics. You are more than welcome to join if you like to edit physic-topics. --Tobias1984 (talk) 22:34, 12 August 2014 (UTC)[reply]
@Nobelium: I would merge Q2514471 into evaporative cooler (Q1896787). --Petermahlzahn (talk) 12:09, 13 August 2014 (UTC)[reply]
I do not speak Danish nor Norwegian, so I do not know about evaporative cooler (Q1896787). If you are sure both items refer to the same subject so I will merge them quickly. Pamputt (talk) 21:09, 13 August 2014 (UTC)[reply]
Me too. But what I tried is to catch up a few buzz word. I agree to move the Norwegian (nynorsk) to evaporative cooler (Q1896787) (I'll do so in the next days). But I'm still unsure about the Danish article. There is the BEC (Bose-Einstein Condensate) mentioned which is - as far as I know - only reachable through the evaporative cooling and therefore belongs to magnetic evaporative cooling (Q6731539)? Concerning the magnetic in the description: there is a suggestion on the english article to rename the article Magnetic evaporative cooling to Evaporative cooling (atomic physics) (Talk:Magnetic_evaporative_cooling)
@Pamputt: Je lis que francais est ton langue maternelle: Am I right that Refroidissement par évaporation fits better to magnetic evaporative cooling (Q6731539)? --Nobelium (talk) 20:26, 14 August 2014 (UTC)[reply]

P1127[edit]

Hello, isospin z-component (P1127) was created recently. I am not sure to understand what this property means. Does it refer to weak isospin (Q678322)? Could you give any example how to use it? Pamputt (talk) 08:24, 24 August 2014 (UTC)[reply]

@Pamputt: It is a field used by the German-wiki infobox for particles: de:Vorlage:Infobox Teilchen. As I am not a particle physicist, I can only refer you to the English-wiki description:
"Isospin is described by two quantum numbers: I, the total isospin, and I3, an eigenvalue of the Iz projection for which flavor states are eigenstates, not an arbitrary projection as in the case of spin. In other words, each I3 state specifies certain flavor state of a multiplet."
(en:Isospin#Isospin symmetry). For a Proton the infobox says 1/2 and +1/2 for the z-component. And for a Neutron it is 1/2 and -1/2 for the z-component. Maybe @Svebert: can take a look at the property and add a better documentation. -Tobias1984 (talk) 08:42, 24 August 2014 (UTC)[reply]

Fundamental interactions[edit]

Hi, just catched a discussion which is in the topic of this project on Emw's talkage with Laddo. I suggest it continues here. It might interest Jibe-b who seems to be interested on Physics ontology (notif Tobias1984) and just arrived a few hours after the beginning of this conversation, what a coincidence !

The discussion is on fundamental force like gravity Help:Classification and took place here. I suggest we continue it here. TomT0m (talk) 10:56, 22 September 2014 (UTC)[reply]

As I mentioned on Emw's talk page, I personally prefer gravity (Q11412) instance of fundamental interaction (Q104934), but I don't have a strong opinion on this topic, as long as all fundamental interactions and the constraints are coherent. As TomT0m suggested, I fixed fundamental interaction (Q104934) that of course should have been subclass of interaction (Q52948) from the start. LaddΩ chat ;) 02:30, 23 September 2014 (UTC)[reply]
@Laddo: It's not really consistent to have fundamental interaction (Q104934) as a subclass of interaction but .
Any instance of interaction is the earth is attracted by the sun or the bond of some specific atoms in a Uranium bar in a nuclear power plant. Then gravitation's interaction are a subset of all interaction, my first example beetween the earth and the sun is in this class, the second is not.
'instance of (P31) links elements of the set of instances to the class (the set of instances) itself. subclass of (P279) links set of instances to set of instances. By saying gravitation instance of (P31) fundamental interaction and fundamental interaction subclass of interaction you would break this rule per my example : gravitation has a lot of instances, and its instances would also be instances of fundamental interaction.
It's different if fundamental interaction is not a subclass of interaction, by a class of interaction patterns, or a class of laws of physics who describe interactions. Then the fundamental interaction class would be a class of physical laws, and gravity would be an instance of it. Gravity would still be a class of interaction, and its instances would be interactions that follows the gravitation laws, but not a subclass of fundamental interaction as interactions are not physical laws. As I said in Emw's talkpage, we still can use both model with two items <fundamental interaction> for the set of concrete iterations that follows any of the fundamental interaction laws, and <fundamental interaction laws> for the class of all fundamental interaction, with
⟨ Gravity ⟩ instance of (P31) View with SQID ⟨ fundamental interaction laws/model/pattern ⟩
...
This seems justified because I can see a link beetween classes expressions in OWL language which can say stuff like woman are humans with a female sex and physical laws : gravity interaction are interaction that follows the gravity interaction laws.
The class expression is used such that all instance of the human class with a female sex property will be automatically (intance of) women. But in Wikidata, we can also talk of the laws of physics as object. And the laws in question can form a class of laws. If the law is the equivalent of a class expression, then this means we can use class expressions as instances in Wikidata, which breaks the principle type–token distinction (Q175928) but I don't think it is a problem. TomT0m (talk) 08:51, 23 September 2014 (UTC)[reply]

Launch of WikiProject Wikidata for research[edit]

Hi, this is to let you know that we've launched WikiProject Wikidata for research in order to stimulate a closer interaction between Wikidata and research, both on a technical and a community level. As a first activity, we are drafting a research proposal on the matter (cf. blog post). It would be great if you would see room for interaction! Thanks, --Daniel Mietchen (talk) 01:33, 9 December 2014 (UTC)[reply]

Units are available[edit]

From Wikidata:Project_chat#Units_are_live.21_.5Co.2F, it is now possible to create properties for quantities with units. Do you know if we have already open requests to ask the creation of some of the properties given on Wikidata:WikiProject_Physics? Pamputt (talk) 05:21, 10 September 2015 (UTC)[reply]

@Pamputt: We have a list of pending properties here that can be created without further discussion (although one has to make sure it meets the standards we have today): Wikidata:Property_proposal/Pending/2 - I will try to go through some of the properties soon. --Tobias1984 (talk) 17:30, 11 September 2015 (UTC)[reply]
@Tobias1984: I propose you to put again the pending proposals in the Natural science proposal page for several days or one week. It is good to see if some people can add some comments: after 2 years we have a better experience and even if the proposals are the results of a consensus, the definition of the use of the properties can be better defined from the begining in order to reduce bad use later. Snipre (talk) 17:46, 11 September 2015 (UTC)[reply]
@Snipre: Good idea. I will move some of the science properties back to the proposal page. But it will take some time going through that list and sorting out the mess :) --Tobias1984 (talk) 17:55, 11 September 2015 (UTC)[reply]

List of new properties[edit]

Automatic tables[edit]

Especially for smaller wikis generating automatic tables would be really helpful to provide up to date information with little maintenance work: Wikidata:WikiProject Physics/List of Elements. --Tobias1984 (talk) 17:28, 11 September 2015 (UTC)[reply]

Great idea - I tried this: Wikidata:WikiProject Physics/AutoList of Nuclides - though I seem to get Listeria "no template errors"? Also a problem with display of units for half-life. What would be really nice would be a chart of the nuclides tool, like the Periodic Table tool. ArthurPSmith (talk) 13:55, 2 October 2015 (UTC)[reply]
@ArthurPSmith: The list seems to work now. Great idea with having a nuclide chart. @Ricordisamoa: Could you help us with that? --Tobias1984 (talk) 21:12, 2 October 2015 (UTC)[reply]
@ArthurPSmith, Tobias1984: Sure! Please follow up in phab:T114547. --Ricordisamoa 00:34, 3 October 2015 (UTC)[reply]
FYI a working nuclide chart as an addendum to the periodic table tool is testable now - see https://gerrit.wikimedia.org/r/#/c/245591/ - Ricordisamoa seems reluctant to release as is since it's slow due to a data fetch that can't use the WDQ dump. But it does work, and I think is a nice demonstration of what you can do with wikidata... ArthurPSmith (talk) 19:44, 4 November 2015 (UTC)[reply]
@Tobias1984: Chart of the nuclides is up live - http://tools.wmflabs.org/ptable/nuclides - please let me know any suggestions for improvement! ArthurPSmith (talk) 14:53, 9 February 2016 (UTC)[reply]
Really nice job ArthurPSmith. If you have time to still improve what you did, here are some suggestions
  • Could you had some lines around the magic nuclei as shown here for example. It could help to visualise directly at what Z and N we are in a specific area of the chart.
  • Could you had a way to zoom into the chart. Currently it is quite difficult to click directly on the nuclei we are interested in.
  • You could add other visualisation in addition of the half-life one. For example a one following the decay modeI have not seen that it already exists, and so on. For the decay mode chart, could you modify the color of the electron cpature, it is too close to the positron emission colour.
  • Is the creation of the chart automatic or not? I mean, if I create a new item relative to a new isotope, will it appear directly on this chart?
That is all for now, and one more, thank you very much for this really nice work Pamputt (talk) 21:24, 9 February 2016 (UTC)[reply]
Yes, it is completely automatic - entirely derived from wikidata entries, with no outside assistance (other than conversion factors for the half-life time units). On positron emission vs electron capture - actually the BNL NNDC page lists almost all of those as electron capture for some reason - I've queried them about it and there is a way to figure it out from their data, but it's not in the main NuDat display. The ratio between electron capture and positron emission depends on the atomic state (electron energy levels) of the nucleus so it's not really a set quantity, but it still should be derivable under normal conditions. So that does need to be improved. But for now they probably should be considered the same thing since they're not being distinguished properly in the original data or in the wikidata entries. I'll definitely look into your other suggestions, thanks! ArthurPSmith (talk) 21:48, 9 February 2016 (UTC)[reply]
@Tobias1984, Pamputt: - new version is up at the same place: https://tools.wmflabs.org/ptable/nuclides - it now has the magic numbers shown via dashed lines (pulled from wikidata also) and is resizable. That took a bit of work - I switched from a table format to svg. But I think it works nicely... Any other suggestions? ArthurPSmith (talk) 23:42, 12 March 2016 (UTC)[reply]
@ArthurPSmith: really nice work. Still few remarks
  • why does the neutron (Q2348) does not appear in the chart whereas other isotopes of neutronium are present?
  • Here the text "126 neutrons" is cut (only "126 neutro" is displayed)
  • About the nuclide chart by decay mode, coul you precise that the decay mode is the main one? Indeed, some nuclides may decay by different kind of mode (for example electron capture and beta+ or fission and alpha decay). Usually, when a nuclide may decay by several decay mode, one uses several color in the same box. Yet, I guess, it will become unreadable if we do this. That's why the easier way is to specify that only the main decay mode is taken into account.
  • Do you think it could be possible to provide this tool in several languages? Pamputt (talk) 08:56, 13 March 2016 (UTC)[reply]
@ArthurPSmith: Looks amazing! I sent you a pull request for some layout changes that you might like. I also noticed that dragging the chart will result in a click when the pointer is above a nuclide-square. I also think multi-lingual would be cool, because that is Wikidatas great strength. I will try if I can get that to work next. --Tobias1984 (talk) 13:24, 13 March 2016 (UTC)[reply]
Pamputt - I believe neutron (Q2348) was missing because it didn't have atomic number or neutron number set. I have added those properties so it should show up now.. and yes, there it is! On the text label - it looked ok in my browser; maybe I can tweak font sizes or the svg viewbox to make that work better. I was trying to avoid doing anything special on a per-record basis at all; the magic numbers are pulled from wikidata and the labels placed automatically based on the range of neutron and proton numbers in the data, so there will probably be quirks like that inevitably from time to time - as more isotopes are added with more neutrons it may look better. Until we find more magic numbers. On the decay mode chart - I'm not sure it's actually doing the right thing right now, I need to check on that. The intention was to sort the decays by the fraction in each mode so it would be the dominant one displayed, but it's possible it's a little more random than that at the moment. It might be also a good idea to display more of the decay data right on the page through a hover action; it's all downloaded so display wouldn't add a lot more effort (just some more javascript code probably). In fact, and related to Tobias1984's layout change suggestion, the display doesn't work at all on the mobile devices I have tried - the isotope names are shown via "tooltips" which don't display on mobile touch-screens, and for some reason the clickable links through to wikidata don't work either (at least on the iPad and iPhone I tried). So there's definitely some work needed to get it functional in a mobile-friendly way. And internationalization would be great - the periodic table app is at least partly internationalized via a '?lang=...' parameter, I'm not sure why this isn't working on the nuclides side, but in principle it ought to be doable. ArthurPSmith (talk) 14:25, 14 March 2016 (UTC)[reply]
@ArthurPSmith: I posted a screenshot on Twitter: https://twitter.com/tobias47n9e/status/709008660601643008 I have to read up on some of the SVG stuff, but I think all of the current usability problems should not be too difficult to fix. --Tobias1984 (talk) 21:14, 14 March 2016 (UTC)[reply]

Fundamental constants: use "numeric value" (P1181) or specific properties?[edit]

I'd like to add the CODATA fundamental constant values to wikidata - available on the NIST website here - [1]. For some of them there's a property that seems to make sense to insert the numeric value of the constant - for example speed of light in vacuum (Q2111) has property speed (P2052). For others (for example the permittivity of free space - [2] - we don't have a 'permittivity' property that would apply right now, though maybe we should. For yet others (for example the Planck constant - [3] - I can't even think of what property you would use that would make sense in that fashion. Also, these properties aren't exactly logical applications of the property approach - it is not speed of light in vacuum (Q2111) itself that has that speed, it is massless particles. It is not the permittivity of vacuum (Q6158) that has that permittivity, it is a property of a vacuum. I'm thinking that maybe for all of these the better property to use would be numeric value (P1181) - except that seems to be restricted to quantity values without units, at least from its description ("numerical value of a number (e.g. 1) or a constant (e.g. pi)"). Any advice on what to do here? ArthurPSmith (talk) 18:01, 2 November 2015 (UTC)[reply]

@ArthurPSmith: I think numeric value (P1181) needs to be redefined to also take physical units. And the speed of light works well like this, in my opinon: massless quantum particle (Q2024141). --Tobias1984 (talk) 19:22, 2 November 2015 (UTC)[reply]
I should have read the discussion page - last month @Pasleim: asked exactly this question at the bottom. I think the other alternative has to be creating a new property - numeric value with units or something ? ArthurPSmith (talk) 19:34, 2 November 2015 (UTC)[reply]
ok - thanks for all the folks who commented, numeric value (P1181) seems to be ready to use for this now and I've applied it in a few cases already. However, I've run into another stumbling block in wikidata's handling of very small numbers, when trying to enter a value for Planck constant (Q122894). The units are joule second (Q1709783) which does exist so that's fine. But in those units the numeric value is tiny - 6.6x10^-34. Entering it in wikidata leaves a value that looks like 0.000000. Is there anything we can do about quantity display for extremely small or large values? I was contemplating creating a zeptojoule-picosecond unit (10^-33 joule-second) just for the purpose of allowing this to display reasonably. But that probably isn't a good idea. Any other suggestions? ArthurPSmith (talk) 21:34, 4 November 2015 (UTC)[reply]
Note I decided to post this as a phabricator request. Anybody interested should maybe comment there on the specifics... ArthurPSmith (talk) 22:07, 4 November 2015 (UTC)[reply]

Property for decay mode fraction?[edit]

The next thing I was looking to do was to add decay fraction (and source references) to the "decays to"/"decay mode" information for isotopes, using the information available from NuDat2 (NNDC). I think the additional qualifier to use for the fraction in each mode is proportion (P1107) - this seems to be used as a qualifier now in similar circumstances, for example the fraction of ownership of a company - see Meta Platforms (Q380) for example. Does this make sense to others here? ArthurPSmith (talk) 21:51, 9 November 2015 (UTC)[reply]

An example ? Snipre (talk) 23:06, 9 November 2015 (UTC)[reply]
For example, 84Rb decays from its ground state by electron capture (96.10%) and by beta minus decay (3.90%). Pamputt (talk) 06:44, 10 November 2015 (UTC)[reply]
A stupid question: is it possible to have 2 different decay modes for the same isotope ? In that we will have different fractions values but for different processes. Snipre (talk) 17:35, 10 November 2015 (UTC)[reply]
Yes, some isotopes may decay in two different ways. The most common case is about nuclides that may decay by electron capture and by beta plus. Nevertheless, most of the nuclides decay by a single way. So, for almost all the isotopes, it will be 100%. Pamputt (talk) 18:52, 10 November 2015 (UTC)[reply]
I suppose the proper term is branching fraction (Q370559) - but there's no corresponding property. proportion (P1107) seems to capture the meaning well enough, unless there's a strong feeling we should use the technical term here? ArthurPSmith (talk) 16:39, 10 November 2015 (UTC)[reply]
Indeed, the technical term is branching fraction (Q370559). No opposition to use the more generic term proportion (P1107).

Wikimania 2016[edit]

Only this week left for comments: Wikidata:Wikimania 2016 (Thank you for translating this message). --Tobias1984 (talk) 11:58, 25 November 2015 (UTC)[reply]

mean lifetime (Q1758559) and half-life (Q47270)[edit]

Hello, we currently have one property half-life (P2114) for half-life (Q47270). The link between mean lifetime (Q1758559) and half-life (Q47270) is a factor ln 2 so two items does not refer to the same quantity. In particle physics, mean lifetime (Q1758559) is much more used than half-life (Q47270). For now, half-life (P2114) is used for physics particle instead of « mean lifetime (Q1758559) ». For example, the value in neutron (Q2348) is wrong since the value corresponds to the mean lifetime (Q1758559) given in the latest PDG report. Thus, if one wants to use half-life (P2114), one has to multiply the value given by the PDG by ln 2. In order to avoid misunderstanding, do you think we should create a new property corresponding to mean lifetime (Q1758559) ? Pamputt (talk) 09:21, 6 March 2016 (UTC)[reply]

It is nice to not have to translate values when entering into wikidata - and to avoid confusion. On the other hand they are numerically very closely related. Would you expect both properties to be present for some entities? Would we want some kind of constraint between them? But I think it would be fine to propose this as a new property and see what others think. ArthurPSmith (talk) 16:19, 7 March 2016 (UTC)[reply]
Notified participants of WikiProject Physics Thank you for your having given your opinion. I opened a property proposal. Pamputt (talk) 17:06, 11 March 2016 (UTC)[reply]
I created now mean lifetime (P2645) --Pasleim (talk) 23:47, 23 March 2016 (UTC)[reply]

Question on isomer labels[edit]

I've been looking to add data on the nuclear isomers (eg. tantalum-180m1 (Q18882796)) in addition to the half-life and decay data we have for regular isotopes. However, I'm running into an issue with figuring out which one is which. For example for Ta-180 we have tantalum-180m1 (Q18882796) tantalum-180m2 (Q18882798) and tantalum-180m3 (Q18882799). However, NNDC only lists 2 levels in their main chart here - http://www.nndc.bnl.gov/chart/reCenter.jsp?z=73&n=107 - I think it's pretty clear that covers the regular Ta-180 and Ta-180m1. If you link through to their levels page here - http://www.nndc.bnl.gov/chart/getdataset.jsp?nucleus=180TA&unc=nds there are a huge number of different states listed, including one with energy in between the ground state and m1. So which ones do m2 and m3 belong to? en:Isotopes of tantalum lists m2, m3 and m4 as being associated with the 1452.40 keV (31.2 microsecond half-life), 3679 keV (2 microsecond) and 4171.0 (17 microsecond) states respectively, but is there any way to figure that out without going through the wikipedia tables? Moreover, are these really standard names for those isomeric states, or do they just happen to correspond to knowledge at a particular point in time, likely outdated? What's the best approach on linking these all together? ArthurPSmith (talk) 21:09, 23 March 2016 (UTC)[reply]

@ArthurPSmith: as far as I know, there is no normalisation for the name of metastable nuclide. For tantalum, I know only the 180mTa that refers to the state around 77 keV. Other denomination depends on the authors and I think they are not really stable over the time and may vary over the time. So I would recommend to follow only NNDC that normalise rather stable knowledge, at least for isomeric states. In a more general discussion, we could imagine that all nuclear data should be in Wikidata that means that all states of all nuclides should be imported here but it is a lot of work to maintain such data. Pamputt (talk) 22:14, 23 March 2016 (UTC)[reply]

Merging units with conversion factor 1[edit]

I don't think that merging poiseuille (Q751310) with Pascal seconds is a good idea. Although they might have the same mathematical value they are still different from the standpoint of Wikidata. A unit also could have statements when it was first used, or who defined it. With the merge that has become impossible. --Tobias1984 (talk) 08:09, 1 November 2016 (UTC)[reply]

@Tobias1984: Why would they be different from the stanpoint of Wikidata ? Seems just like another name for the same object. It should become apparent by the fact we can make the same statements for the two ... except for stuffs like "named after". Or do I miss something ? author  TomT0m / talk page 09:26, 1 November 2016 (UTC)[reply]
@Tobias1984, TomT0m: I agree with Tobias. Both items have to stay separate. As Tobias wrote, poiseuille (Q751310) may have different statement for inception (P571), named after (P138) et conversion to SI unit (P2370). For the later, the value should be 1 Pa.s that is the SI unit of dynamic viscosity (Q15152757). poiseuille (Q751310) is not part of the SI unit. Pamputt (talk) 09:48, 1 November 2016 (UTC)[reply]
@Pamputt: named after (P138) View with SQID is problematic in terms of concept as it refers to a denomination and not to a concept as is. It should actually be a qualifier of the label. To make this clear I sometime think we should have (and we have) "words items", but eventually the will belong to structured wiktionary ... That's why I think they should be left out of the equation or that in cases that the word has an interest to be an entity in Wikidata we should have a property "denomination of" with domain "word" and range "entity", in our case the "word" item would bear the "poiseuille" term, the "named after" and would link to the unit item who would bear the meaning. But what do you mean with different values for conversion to SI unit (P2370) View with SQID ? Different values event after doing the separation fore-mentioned ? author  TomT0m / talk page 09:59, 1 November 2016 (UTC)[reply]
@TomT0m: for conversion to SI unit (P2370) I mean that « Pa.s » is the SI unit, not poiseuille (Q751310). Thus, poiseuille (Q751310) should have statement conversion to SI unit (P2370) with the value « 1 » and unit « Pa.s » (the item to be created for the SI unit). The item « Pa.s » will not have statement conversion to SI unit (P2370) Pamputt (talk) 10:06, 1 November 2016 (UTC)[reply]
@Pamputt: This actually pleads for the two units just being linguistic aliases and not essentially different :) I made in the past to be able to make a proposal to be able to express units in terms of product / power / ... of other units : the two units would have exactly the same definition. If we suppose a merge of units and putting "poiseuille" as a french label/alias for the merged unit there is just no difference at all and everything keeps to be consistent. It's just conceptually simpler. Let's keep the denomination questions out of the meaning one, this is what Wikidata is about. Structured wikitionary on the other and is all about words and their mapping to concept, which seems to be our problem here. author  TomT0m / talk page 10:15, 1 November 2016 (UTC)[reply]
@TomT0m: what you wrote is exactly the problem. Currently Wikidata manages data as it. Poisseuille is an old unit that was used before SI units appear. Even conceptually, both items are different. It is not only a matter of naming. In conclusion, I understand your point of view and I do not share it, so I wrote everything I think and I will not continue. Pamputt (talk) 10:22, 1 November 2016 (UTC)[reply]
@Pamputt: This is asymmetric then since I don't really understand your POV :) I don't think what is conceptually different. Another argument : it seems that there is an article for the "poiseuille" in frwiki ... but there is none for P/s. So there is not event an interwiki conflict wrt. frwiki. It's just seems to be a change of name and there totally could be a "naming" section in an article about P/s (or "poiseuille" for what I care.) author  TomT0m / talk page 10:29, 1 November 2016 (UTC)[reply]
I would also say it is the same thing, just with a different name. Poisseuille is just a name for the unit that did not make it into the SI system, but the unit itself was always defined via the same base units kg, m and s. Maybe the item should be called pascal second with an alias poisseuille. The name pascal itself was only introduced in 1971, before that, the SI unit would have been called something like Ns/m^2. Similar examples are abampere (Q864818), ampere per metre (Q2844478) and daraf (Q1165639). If the units were conceptually different, it would be wrong to replace one name with the other.
Examples of units that are different would be newton metre (Q215571) and joule (Q25269), hertz (Q39369) and becquerel (Q102573). Because they are used only for certain quantities one can find a book where they are used alongside one another.--Debenben (talk) 13:41, 1 November 2016 (UTC)[reply]

@Infovarius: Since you merged them again. Would you also want to have seperate items for the SI unit N/m^2 between 1960 and 1971, the SI unit pascal that was introduced in 1971 and the non-SI unit N/m^2 also called pascal that was part of the MKS and MKSA system and in Germany became a legal unit in 1969?--Debenben (talk) 22:59, 2 November 2016 (UTC)[reply]

Hm, I don't know. I am not so deep into a history of units. I admit both solutions (>1 items with different properties, or 1 item with qualifiers) and I can't image drawbacks of both for a while. --Infovarius (talk) 14:25, 8 November 2016 (UTC)[reply]

Rethinking the way of describing units[edit]

Tobias1984
Snipre
Physikerwelt
Pamputt
Petermahlzahn
Jibe-b
Restu20
Daniel Mietchen
TomT0m
ArthurPSmith
Mu301
Sarilho1
SR5
DavRosen
Danmichaelo
Ptolusque
PhilMINT
Malore
Thibdx
Ranjithsiji
Niko.georgiev
Simon Villeneuve
Toni 001
Marc André Miron
DePiep
RShigapov
CarlFriedberg
Crocodilecoup
Mkomboti
Amorenobr (talk) 01:27, 3 August 2022 (UTC)[reply]
Valverde667 (talk) 16:07, 4 August 2022 (UTC)[reply]
fgnievinski

Notified participants of WikiProject Physics and @Infovarius:

Currently there are several competing ways of describe units, e.g. metre (Q11573)

  • Measured physical quantity can be described by
measured physical quantity (P111) length (Q36253)
instance of (P31) unit of length (Q1978718)
instance of (P31) unit of measurement (Q47574) with qualifier of (P642) length (Q36253)
  • system of quantities and units can be described by
part of (P361) International System of Units (Q12457)
instance of (P31) SI base unit (Q223662) (or for non-base-units: SI derived unit (Q208469))
  • and we have
conversion to SI unit (P2370) 1 metre without qualifier
instance of (P31) unit without standard conversion to SI (Q21684377)

There are several issues:

This gets more complicated when considering natural units. Setting c=1, meter (usually femtometre (Q208788) is used) becomes the unit for both space and time. Another popular choice would be electronvolt (Q83327) as a basic unit, which means it is also a unit for mass (Q11423) and the like. Then we have the choice of setting either h=1 or hbar=1. For a photon this means E=1/lambda or E=2pi/lambda and we have to multiply either with h*c or with h*c/2pi for conversion into SI units.
Conclusion: Technically, every measured physical quantity (P111), every conversion to SI unit (P2370) and unit without standard conversion to SI (Q21684377) depends on the system of units and quantities that the unit is used in and the conversion also depends on the quantity (in terms of SI-basis-quantities) that it is converted into and is not just a number, but can include units with dimensions.
  • Let's say we want to query all units of measurement. Here, we can include all subclasses with (wdt:P31/wdt:P279*) wd:Q47574 which is still rather easy. However actually useful queries, like all units of energy (with a certain property), become way too complex when having to consider all the different ways of how a unit of energy could be described.
  • It is not clear, how we deal with units that have different names, were redefined, where the legal status in a country, the "part of- or officially allowed to be used with SI" changed, or simply: How to distinguish two different units (e.g. poiseuille (Q751310)=pascal second (Q21016931)?).
  • We cannot state, e.g. instance of (P31) "unit of electric dotriacontapole" or "MKSQ derived unit" since we do not have such items. Describing every possible quantity we would need an infinite number of them.
  • What do with artificial combinations like "kilogram per cubic-femtometer" or "gram per cubic-parsec" which would technically be a unit of density (Q10387685).

I do not have a perfect solution to all problems, but I think we should never the less try to figure out a better way to describe units if we want to create a useful and consistent database.--Debenben (talk) 02:49, 21 November 2016 (UTC)[reply]

  • I completely agree that there is room for improvement. I think someone needs to come up with a proposal;-)--Physikerwelt (talk) 09:40, 21 November 2016 (UTC)[reply]
  • It seems you are concerned about a number of quite different problems, and there may be existing solutions that would address some of them if we applied them better. For example, for historical information (SI units have been regularly redefined and their relationships to other quantities changed slightly over the years) wikidata already has qualifiers to specify time ranges or points in time, and also values can be ranked as "preferred" or "deprecated". So I think we can address those changes over time with existing wikidata features. On the issue of "natural units", I think your point is that one unit (eg. MeV) can represent two (or perhaps more) different things - energy or mass for example, so you will have different conversion factors to SI units. But "natural units" are merely a notational convenience - MeV is really an energy unit and the actual mass unit is MeV/c^2 and has a well-defined conversion to SI. On the issue of the arbitrary combination of units to form new ones, I think this is a real problem with wikidata's data model at the moment - the closest we can do right now is the "Mathematical Expression" datatype used by defining formula (P2534) but that doesn't translate well to a SPARQL representation or calculation of unit conversions. I think this is an area that could definitely be better addressed. ArthurPSmith (talk) 14:51, 21 November 2016 (UTC)[reply]
  • Different conversions into different system of units can also be covered by qualifiers. Though there are at least 2 ways to do that: several P31="unit of some SI" with qualifier conversion to SI unit (P2370) or several conversion to SI unit (P2370) with qualifier applies to part (P518). --Infovarius (talk) 12:18, 22 November 2016 (UTC)[reply]
  • I was hoping that someone might come up with a better solution, but your answers are similar to what I was thinking of. Mainly two things:
1) Use a defining formula (P2534) property to state the definition of a unit in terms of basic units which does not need a qualifier and is always true. This would at least separate all unproblematic "conversions" that are in fact definitions from problematic conversions between units that use different basic quantities.
2) Create a property like taxon name (P225) to allow a unit to have several names with qualifiers
Example: statcoulomb (Q21131)
As mentioned by Infovarius, one could switch the arrangements of the qualifiers, for example
or
the first example seems to be most convenient for me, one could easily add measured physical quantity (P111) capacitance (Q164399) and conversion to SI unit (P2370) farad (Q131255) to centimetre (Q174728). I have not worked out a solution for the unit name being different in different writing systems, but I guess one could solve that.--Debenben (talk) 23:28, 27 November 2016 (UTC)[reply]
  • My memory of these issues with the cgs electrostatic units is very vague but it seems to me the best solution here is simply, if there are alternate "interpretations" of a given unit (with different conversion factors to SI), to provide separate items for them. Otherwise they will be essentially useless if used as units in themselves since they have an inherent ambiguity. Wikidata items should unambiguously refer to specific concepts, not combine multiple concepts into one label. In the specific case of the statcoulomb, I am not confident that the enwiki page describing it is reliable - it cites no reliable sources. From my vague recollection the issue is related to how the speed of light is divided up between the electrostatic and magnetic constants; in any case some of what's on that enwiki page doesn't make sense to me as it stands; a "flux" is generally a rate so would be in units of Amperes, not Coulombs. ArthurPSmith (talk) 18:07, 28 November 2016 (UTC)[reply]

Earlier proposal to describe product of units such as W.h (because of the proposition in term of a math formula) : Wikidata:Property_proposal/Archive/47#product_.2F_sum_.2F_power_.2F_function_application. One of the main reason this way not done - the use of "some value" as main value, a (very) minor point - has found a solution with the use of list of values as qualifiers (Q23766486)  View with Reasonator View with SQID in union of (P2737) View with SQID and disjoint union of (P2738) View with SQID. So maybe we can come to an agreement here. Summary : for current physical quantity like "m.s^-2" we could create an item and express with properties like "product of/pow", items like the one about meters and auxiliary items if needed (for example one for s^-2) that it's the product of meters and s^-2, and that s^-2 is s "power" -2 . author  TomT0m / talk page 19:42, 28 November 2016 (UTC)[reply]

Classification of matter[edit]

Hi, I have a small problem in Wikidata about classification of matter. Currently Antimatter is a subdivision of matter. Is it correct ? If yes, is there a name for the subdivision of matter which is not antimatter ? From my understanding antimatter and matter should be at the same level and we need a concept which integrates both matter and antimatter in a whole. Then what's about exotic matter ? Can we say that exotic matter is part of the subdivision of matter which is not antimatter ? Or exotic matter is at the same level as matter and antimatter and is part of a concept without name (something like the big whole) ? And I don't say anything about dark matter. So we can have 2 visions:

  • Vision 1:
    • antimatter subclass of matter
    • dark matter subclass of matter
    • exotic matter subclass of matter
    • ??? subclass of matter (everything which is not antimatter, dark matter or exotic matter, just normal matter)
  • Vision 2 (big whole to be determined):
    • matter subclass of ???
    • antimatter subclass of ???
    • dark matter subclass of ???
    • exotic matter subclass of ???

Comment ? Snipre (talk) 19:56, 16 December 2016 (UTC)[reply]

Definitely 1. There are a variety of definitions but I would argue that matter covers anything that has a nonzero rest mass. Matter cannot simply be subdivided into "antimatter" and "not antimatter" - for example mesons are a combination of a quark and an antiquark, so they are not really one or the other, though they usually do have anti-particles. Massive elementary bosons like the Higgs or Z do not have anti-particles (the W+ and W- are not generally considered antiparticles of one another, and certainly there's not one that's matter and one that's antimatter). Even hypothetical negative matter, with a negative rest mass, ought to be counted as matter in my book. If you think there should be a wikidata item for "normal matter" defined as the opposite of antimatter, there may be a case for it. But most concepts have both a "narrow" and "broad" meaning of this sort, and I don't see a strong need for a "normal matter" item. ArthurPSmith (talk) 20:30, 16 December 2016 (UTC)[reply]
@D1gggg: do you prefer second option? --Infovarius (talk) 21:47, 5 July 2017 (UTC)[reply]
Both 1 and 2 can be an option, depending on results of the research.
But I'm sceptical about P279 "subclass of" claims at such level - this would claim so many things (without exceptions according to RDF)
I.e. we should study both matter and antimatter well enough until we can say about
⟨ antimatter ⟩  Wikidata property  ⟨ matter ⟩
or
⟨ matter ⟩  Wikidata property  ⟨ antimatter ⟩
. d1g (talk) 21:58, 5 July 2017 (UTC)[reply]

Isotopes[edit]

First, I don't know what to do with isotope claims at antideuterium (Q11905736).

Second, I did many edits so that every concrete isotope is in 2 P279-links away from isotope (Q25276):

The following query uses these:

  • Properties: instance of (P31)  View with Reasonator View with SQID, subclass of (P279)  View with Reasonator View with SQID
    SELECT DISTINCT ?item ?itemLabel WHERE {
  { ?item wdt:P31/wdt:P279* wd:Q25276 } # old one with arbitrary depth, 2359; DISTINCT 2236
  UNION
  { ?item wdt:P279/wdt:P279 wd:Q25276 } # suggested structure with fixed links, 4509; DISTINCT 4507
  
  # BOTH UNION: 6868
  # BOTH UNION, DISTINCT: 4508
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

d1g (talk) 22:12, 3 July 2017 (UTC)[reply]

  • . You could also create a "isotope of antihydrogen" class and add antiproton to that also. The proton and neutron numbers are wrong - they should either not be there at all or should be -1. ArthurPSmith (talk) 22:22, 3 July 2017 (UTC)[reply]

We also have 5 items as result of following selection: 

SELECT DISTINCT ?item ?itemLabel WHERE {
  ?item (wdt:P31|wdt:P279)/wdt:P279+ wd:Q25276
  MINUS 
  { ?item wdt:P279/wdt:P279 wd:Q25276 }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

They are subclasses of neutron (Q2348), then isotope of neutronium (Q12525553) - I don't know if this is the most correct way. d1g (talk) 22:43, 3 July 2017 (UTC)[reply]

neutrons (singly and in groups) are nuclides and have the other characteristics of isotopic entities, they just have an atomic number of zero. ArthurPSmith (talk) 15:57, 4 July 2017 (UTC)[reply]
Oh, sorry, I see these are subclasses of "neutron". I think they're fine, they haven't caused trouble before, the relations seem suitable. ArthurPSmith (talk) 16:03, 4 July 2017 (UTC)[reply]
None of isotope (Q25276), nuclide (Q108149) (or even chemical element (Q11344)) lead to physical subclass
This means when we say
⟨ subject ⟩ instance of (P31) View with SQID ⟨ uranium-234 (Q26841207)  View with Reasonator View with SQID ⟩
it means only "instance of abstract class (Q5127848)" = concrete abstract class.
But
⟨ subject ⟩ instance of (P31) View with SQID ⟨ uranium-234 (Q26841207)  View with Reasonator View with SQID ⟩
is clearly the most physical-non-abstract claim: only time and space is missing (such data should be covered outside Wikidata); we should have an option to say claims about individual uranium-234 (Q26841207) d1g (talk) 21:46, 4 July 2017 (UTC)[reply]
@D1gggg: I did not get your point. Could you detail a bit more? What does
⟨ subject ⟩ instance of (P31) View with SQID ⟨ uranium-234 (Q26841207)  View with Reasonator View with SQID ⟩
mean? What kind of item can be instance of (P31) : uranium-234 (Q26841207)? Do you have any example? Pamputt (talk) 05:25, 5 July 2017 (UTC)[reply]
@Pamputt: physical "subclass of" links should lead to concrete object (Q15619176) or physical object (Q223557) (or other item) - as they do in artificial physical object (Q8205328)
But most isopotes are not artifacts (some in fact are)
I'm not that experienced in physics to decide where to place such claims. d1g (talk) 05:31, 5 July 2017 (UTC)[reply]
@Pamputt: Ok. This means it is a high level problem. And it is about semantics. From the physics oint of view uranium-234 (Q26841207) is clearly a nuclide (Q108149) (or isotope (Q25276) but nuclide (Q108149) is more generic). SO the question is just to know how to link in any way nuclide (Q108149) to concrete object (Q15619176) or physical object (Q223557) (or other item). The way it will be done does not have to influence what is done a the basic level, for example uranium-234 (Q26841207) is a nuclide (Q108149). Pamputt (talk) 05:38, 5 July 2017 (UTC)[reply]
d1g - instances of 1st-order meta-classes are themselves classes, whose instances would be physical objects. That's what meta-class means. There is no expectation for an instance of a first-order metaclass to be themselves a concrete physical thing that can be located in time and space - instances of first-order metaclasses are abstract, not concrete. Of course our current ontology for isotopes, elements, etc. is itself confusing and inconsistent. We've had discussions here and at the Chemistry wikiproject without coming to any final conclusions. However, I think we may be getting close. Your mass edits in this area have obviously not been helpful as they did not reflect any of the preceding discussion. ArthurPSmith (talk) 14:21, 5 July 2017 (UTC)[reply]
@ArthurPSmith: I don't know how exactly can affect uranium-234 (Q26841207) or instances of uranium-234 (Q26841207).
https://www.w3.org/TR/2014/REC-rdf11-mt-20140225/#rdfs-entailment
uranium-234 (Q26841207) should be an abstraction over physical instances, respectively Q24017414 should be abstraction of higher level IMO d1g (talk) 19:41, 5 July 2017 (UTC)[reply]
If I understand you, then yes, uranium-234 (Q26841207) is the class of physical instances of U-234, and what we are proposing is that (given it is already defined as such), nuclide (Q108149) is the class of such classes of particular nuclides, i.e. a first-order metaclass. I don't know where we want isotope (Q25276) to end up - possibly as a regular class of which U-234 is a subclass, or possibly as a metaclass. Your edits force isotope (Q25276) to be considered as a regular class and not a metaclass, but I'm not sure that makes sense. See this discussion in Wikiproject:Chemistry about the general issues with the chemical ontology. "Chemical Element" seems clearly like it should be a metaclass. It's not clear where "Chemical Substance" and some of the others ought to fall. I think the way I would do it is make "atom", "ion", "molecule", "nucleus", "particle" etc. the regular classes (of which particular elements, molecules, nuclides, etc. would be subclasses) and reserve the more general terms as metaclasses. Maybe I'll try to put together a specific plan for this and run it by those folks. ArthurPSmith (talk) 19:50, 5 July 2017 (UTC)[reply]
Regarding the relationship to physical object (Q223557) - I would say uranium-234 (Q26841207) is a subclass of physical object (Q223557) since its instances (individual U-234 particles) are physical things. But nuclide (Q108149) is NOT a subclass of physical object, as a first-order metaclass, because its instances would be abstract, not physical objects. ArthurPSmith (talk) 14:27, 5 July 2017 (UTC)[reply]
I also think that statements like would more safer to make. d1g (talk) 20:05, 5 July 2017 (UTC)[reply]
  • Interestingly I just ran across this (written long ago in enwiki) which clearly supports what is proposed here (though I'm not entirely clear where it leaves isotopes and elements): "Metaclasses are class of classes, such as for example the nuclide concept. In chemistry, atoms are often classified as elements and, more specifically, isotopes. The glass of water one last drank has many hydrogen atoms, each of which is an instance of hydrogen. Hydrogen itself, a class of atoms, is an instance of nuclide. Nuclide is a class of classes, hence a metaclass." ArthurPSmith (talk) 18:48, 5 July 2017 (UTC)[reply]
  • @ArthurPSmith: please pay attention that P31 statements about isotope (Q25276) or nuclide (Q108149) at uranium-234 (Q26841207) are not necessary according to rdfs5 + rdfs9
- my edit
with rdfs5:
⟨ uranium-234 (Q26841207)  View with Reasonator View with SQID ⟩ subclass of (P279) View with SQID ⟨ isotope (Q25276)  View with Reasonator View with SQID ⟩
- e1
with rdfs9:
⟨ uranium-234 (Q26841207)  View with Reasonator View with SQID ⟩ instance of (P31) View with SQID ⟨ isotope (Q25276)  View with Reasonator View with SQID ⟩
- e2
⟨ any ⟩ instance of (P31) View with SQID ⟨ uranium-234 (Q26841207)  View with Reasonator View with SQID ⟩
⟨ any ⟩ instance of (P31) View with SQID ⟨ isotope (Q25276)  View with Reasonator View with SQID ⟩
- e3 from e1 + rdfs9
hopefully I understand RDF 1.1 Semantics right here. d1g (talk) 20:31, 5 July 2017 (UTC)[reply]
Reworded e2 with e3. d1g (talk) 20:36, 5 July 2017 (UTC)[reply]
  • d1g but that entailment is NOT the concern with metaclasses. A particular U-234 nucleus is NOT an instance of a "nuclide", according to the above description as a first-order metaclass, because a "nuclide" must be an abstract object which consists of a class of physical objects, and a particular U-234 does not qualify. So your entailment argument would be wrong in that case. A particular U-234 nucleus is an instance of (P31) U-234 which is an instance of (P31) nuclide. There is no entailed relationship between the particular U-234 nucleus and the concept "nuclide" because "nuclide" is a metaclass. Suppose we take "nucleus" as the physical object class (not metaclass) here that is useful - then U-234 is a subclass of "nucleus" and "nucleus" is a subclass of "physical object" (say) and so a particular U-234 nucleus is an "instance of" U-234, so it is therefore an "instance of" "nucleus" and also an "instance of" "physical object". That entailment is fine. But entailment is a completely different issue from metaclass relationships. ArthurPSmith (talk) 21:00, 5 July 2017 (UTC)[reply]
@ArthurPSmith:

A particular U-234 nucleus is NOT an instance of a "nuclide", according to the above description as a first-order metaclass, because a "nuclide" must be an abstract object

I agree, then following P279 links should be disconnected to stop this rdfs propagation.
- my edit
⟨ isotope (Q25276)  View with Reasonator View with SQID ⟩ subclass of (P279) View with SQID ⟨ nuclide (Q108149)  View with Reasonator View with SQID ⟩
- even worse
d1g (talk) 21:11, 5 July 2017 (UTC)[reply]
d1g - yes, your edits broke this logic, now we have to decide what to do. Possibly we may want to remove
⟨ isotope (Q25276)  View with Reasonator View with SQID ⟩ subclass of (P279) View with SQID ⟨ nuclide (Q108149)  View with Reasonator View with SQID ⟩
. Or we may want to reverse your edits and restore under which this particular logic works (except there are other inconsistencies that still need to be resolved, it certainly was not fully consistent or logical before you started changing things). ArthurPSmith (talk)
@ArthurPSmith: The problem of metaclasse is it breaks the inheritance rule I was speaking in Wikidata:Project_chat#Inheritance_for_query. We have to be coherent and clear about this classification. If we agree to use metaclass, we should have a way to differentiate them from the "normal" classification. The only way to identify a metaclass now is to say that every attribute of a class defined as "instance of" can't be inherited by the instances of the class Snipre (talk) 12:05, 6 July 2017 (UTC)[reply]
@Snipre: we can identify them by asserting they are instance of second-order class (Q24017414) as has been done for chemical element (Q11344). Yes we need to be coherent and clear, and we haven't been so far. ArthurPSmith (talk) 15:31, 6 July 2017 (UTC)[reply]

Element carbon is a class not an object?[edit]

See WP Chemistry#A_specific_chemical_element_(Q11344)_is_a_class?. -DePiep (talk) 11:03, 5 December 2017 (UTC)[reply]

Update table isotopes issues[edit]

I am updating section #Infobox_Isotope. But after a minor edit, in Preview I meet: (1) table header broken, shows wikitable code (double !-marks etc), and (2) does not want to save at all. Checking "Changes", I see a newline was added after <translate> tag. I suspect translate tag issues. -DePiep (talk) 18:58, 23 December 2018 (UTC)[reply]

A possible Science/STEM User Group[edit]

There's a discussion about a possible User Group for STEM over at Meta:Talk:STEM_Wiki_User_Group. The idea would be to help coordinate, collaborate and network cross-subject, cross-wiki and cross-language to share experience and resources that may be valuable to the relevant wikiprojects. Current discussion includes preferred scope and structure. T.Shafee(evo&evo) (talk) 02:36, 26 May 2019 (UTC)[reply]

Botched description at property_talk:P1127[edit]

See en:Wikipedia_talk:WikiProject_Physics #Property:P1127 (isospin z-component). Sorry for neglecting to inform earlier. Incnis Mrsi (talk) 21:05, 10 July 2019 (UTC)[reply]

It turned out that Arbnos contributed to the confusion with [4] – edits undone. The usage indicates that the intended quantity is the isobaric spin, not the weak isospin. Incnis Mrsi (talk) 17:45, 14 July 2019 (UTC)[reply]
Incnis Mrsi, Okay, thanks.--Arbnos (talk) 18:14, 15 July 2019 (UTC)[reply]
I thought it was a translation.--Arbnos (talk) 18:47, 15 July 2019 (UTC)[reply]

Data structure and imported data from Review of Particle Physics (Q56810046)[edit]

Hi! I've reestarted recently editting on Wikidata and I've being exploring the best ways to import particle data from Review of Particle Physics (Q56810046). I need some help clarifying some of my doubts:

  1. While adding the authors to Review of Particle Physics (Q56810046) (still many to go, it would probably be worth it to design a program for it), I used affiliation string (P6424) as a qualifier to one of the authors, but that is not an allowed qualifier. Shouldn't we make it one?
  2. Citing the article: I've solely been using stated in (P248) and page(s) (P304). Do you think I should add any other property?
  3. I've created megaelectronvolt (Q72081071) as it is usually used for masses/energies of baryons, but it is not an acceptable unit for mass (P2067). Can we make is so? Discussion in Property talk:P2067#Megaelectronvolt.
  4. Inferior or superior limits in values. This problem also appeared while editing data for exoplanets. What's the best way to represent data where we only know a limiting number (e.g. electron (Q2225) mean lifetime (P2645) 6.6×1028 yr.)?
  5. Scientific notation. Is there a way to write it or do I need to write all the zeros?
  6. What's the best property to designate the symbol of particles (e.g. neutron (Q2348) can be represented by N or n0)?
  7. Can someone explain what's the data structure for particles, in particular what should we use for instance of (P31) and subclass of (P279)? For example, I was adding baryon (Q159731) to instance of (P31) in neutron (Q2348), but it turns out subclass of (P279) is better indicated for it, by comparison with electron (Q2225). Anyway, I don't understand electron (Q2225) has instance of (P31) with type of quantum particle (Q22675015) instead of elementary particle (Q43116) when the last one is more specific. On a similar note, are lepton (Q82586) not a subclass of fermion (Q44363) or should they be treated differently; why does electron (Q2225) has both in subclass of (P279)? I'm really confused what's the policy to treat this.
  8. neutron (Q2348) has electric charge (P2200) with value 0, though actual measurements can only approximate it. What qualifier should be added to the statement with value 0 to indicate it is mostly heuristic or a common approximation.
  9. Some properties that I don't think exist, but would probably be useful: Magnetic moment anomaly, charge radius, magnetic radius, magnetic polarisability and total angular momentum quantum number, J. Is it OK if I submit those for creation?

Sorry for the long list. I realise some questions might be too trivial, but I would like to see this clear up before I make any gross mistake. - Sarilho1 (talk) 09:59, 24 October 2019 (UTC)[reply]

@Sarilho1: Thanks for doing this, a worthy project! Some notes on your questions: (1) affiliation string (P6424) seems fine to me, it's a recently added property so maybe it was just forgotten. I added it to the allowed qualifiers for author (P50). (2) If there's an identifier used by the review to indicate the particle or otherwise locate the reference besides a page number we might want to add that - that might require a new property though. (3) Sure - kiloeV and gigaeV should be added too (there are already items for those). (4) Right now the only way to enter this in the Wikidata UI is as (for example) 330000...0 +- 330000...0 - which is not really very understandable I think. In principle you can enter bounds and displayed value separately, but that requires an API call, and I'm not sure how the UI would display it. (5) Sorry, the Wikidata UI doesn't do scientific notation as far as I'm aware; however there are interfaces to the API (like in python) that handle it. You can also get around this by defining units that are intrinsically large so you don't need so many zeros. (6) Add the different symbols as aliases ("also known as") values. Or did you have something else in mind here? (7) In general for abstract entities (i.e. not a specific electron - if one could even define such a thing) use subclass of (P279). However, there are some "metaclasses", usually designated by a phrase like "type of" (type of quantum particle (Q22675015) appears to be one of them) where an abstract entity really is intended to be an instance of it. But this is confusing to many people so you'll see errors of all sorts on this front. Once the metaclass/class distinction is clear I think it is obvious how to fix these, but feel free to keep asking to confirm you're doing the right thing here. (8) I think we usually use determination method (P459) as the qualifier in such cases; if you provide a reference for the statement then that also would obviously give more detail on how the value is determined. (9) Yes, go ahead and propose anything you see is missing! Do make sure to search the Wikidata property namespace first for obvious variations on the label in case some of these do already exist though. ArthurPSmith (talk) 13:20, 24 October 2019 (UTC)[reply]
@ArthurPSmith: Thank you very much for the answer. I read it earlier, but I didn't had the time to elaborate an answer (also, a thank-you to @Pamputt: for keeping an eye on the discussing and helping with some of the details). It was very helpful, but I'm still confused about in two points, in particular I didn't understood exactly the answer to point (4). Do you have maybe an example where it might be clearer to me? As for point (6), w:Template:Infobox particle has a parameter for symbol to indicate the symbols that are usually used to identify particles, so I was wondering if something along those lines was necessary. Regarding the other points, I think I have a good idea now how to do this. I will keep asking for feedback now and then, if necessary, but this was the most helpful. Thank you. - Sarilho1 (talk) 20:34, 24 October 2019 (UTC)[reply]
For the point 6, if you want to display the symbol in the infobox, then I think we need a new property. There are already several symbol properties (element symbol (P246), quantity symbol (string) (P416), unit symbol (P5061), ...) so there sould be no problem to have another symbol property for subatomic particle. For the point 4, sorry no idea. Pamputt (talk) 20:45, 24 October 2019 (UTC)[reply]
@Sarilho1: On point 4 - I was referring to the Wikidata data model for quantities, which is described here. Along with the numeric value there is an (optional) upper and lower bound. So in principle the value "less than X" can be represented with an upper-bound value of X and lower-bound value of 0. Our radioactive nuclide data has a lot of cases of this - for example for tritium (Q54389) the mass, half-life and some other properties are described with uncertainties (Y +- dy). ArthurPSmith (talk) 08:08, 25 October 2019 (UTC)[reply]
Looking at the point 4 more carrefuly. It seems that you should set the upper value (with its unit) and add the property sourcing circumstances (P1480) as qualifier with the value maximum (Q10578722) (or minimum (Q10585806)). Pamputt (talk) 08:19, 25 October 2019 (UTC)[reply]
@ArthurPSmith, Pamputt: Regarding point 5 on scientific notation, apparently Wikidata accepts it, writing, for example, 10-10 as 10e-10. I don't know if it might incur in some numerical errors while converting, though, so I think it should be checked with care after use. It shall help a bit, though. - Sarilho1 (talk) 17:25, 27 October 2019 (UTC)[reply]

Subclass defined by particle statistics (Q611755) or spin (Q133673):[edit]

Furthering the point (7) above, I have been trying to structure data in my test page. To sumarize, I'm proposing a systematic way of categorising particles as boson (Q43101) or fermion (Q44363) (only one of the subclasses particles should obey; not a replacement of the current ones). I would like some comments on the proposal, in particular, what's the best criteria to add the qualifier (the second question is still mostly doubts of mine about how the metaclasses are defined). Below, I reproduce the content of the test page:

particle (Q1621273) obeys two types of particle statistics (Q611755), Bose-Einstein statistics (Q191076) and Fermi–Dirac statistics (Q274072), based on the value of their spin (Q133673) (see spin-statistics theorem (Q523876)):

Therefore:

Legend: <.> denotes an item; ?(.) denotes a property.

Examples[edit]

Problems/Questions/Grievances[edit]

  1. What's the best criteria to define the subclass: particle statistics (Q611755) or spin (Q133673)?
  2. I've used <type of particle (Q1621273)> instead of type of quantum particle (Q22675015) because not all particles are subatomic and they can still be defined as fermion (Q44363) or boson (Q43101). Clearly type of quantum particle (Q22675015) is contained in <type of particle (Q1621273)> but this would create some major changes in the current structure of particle data. Is this new metaclass fully divisible in type of quantum particle (Q22675015) and chemical element (Q11344) as the Wikipedia page implies?

So, what do you think? - Sarilho1 (talk) 12:46, 28 October 2019 (UTC)[reply]

This all seems fine to me. I think I would use spin (Q133673) as the criterion, it seems clear that is the reason for the designation. One correction, you should probably not use isotope items this way unless it is clear they are items for the bare nucleus. For deuterium use deuteron (Q503527) for example. ArthurPSmith (talk) 14:09, 28 October 2019 (UTC)[reply]
Hmm - on your point 2 just above - "quantum" does not necessarily mean "subatomic", and the terms fermion and boson ONLY apply to things following quantum rules of indistinguishability. So "type of quantum particle" should indeed be sufficient. But I'm not quite sure where it comes into the above proposals anyway? ArthurPSmith (talk) 14:22, 28 October 2019 (UTC)[reply]
I have my default language in Portuguese and the label for Q22675015 is subatomic particle, that's why the item was iching me so much! <type of quantum particle> is indeed the best label and metaclass to use and I'm going to edit the item label right away. - Sarilho1 (talk) 14:56, 28 October 2019 (UTC)[reply]
Ah, good, thanks! ArthurPSmith (talk) 15:30, 28 October 2019 (UTC)[reply]
I probably should have thought about this sooner, but the problem with using spin (Q133673) as the criterion is that it might provide wrong results when the Spin-Statistics Theorem fails, in particular it might fail for some hypothetical 2+1 space particles or quasiparticles (like anyon (Q5528)) or unphysical particles like Faddeev–Popov ghost (Q1391812). In those cases, the criterion would have to solely be the statistics, arising from the field Lagrangians, they obey and not their spins. Of course, heuristically, the vast majority of cases can just be determined by the spin instead of the Lagrangians because the Theorem holds, so should those cases be treated as exceptions? - Sarilho1 (talk) 16:47, 28 October 2019 (UTC)[reply]
For such a case if it's not determined by the spin then you would definitely need to specify a different "criterion used"! But those would definitely be exceptions I would think. ArthurPSmith (talk) 18:58, 28 October 2019 (UTC)[reply]
Not everything having a well-defined statistics has a well-defined total angular momentum. A (neutral) 1H atom is always a boson whichever state it occupies. But even at 1s it technically splits to a j = 0 singlet and a j = 1 triplet. Incnis Mrsi (talk) 20:04, 1 November 2019 (UTC)[reply]

Half life unit[edit]

Hi, currently the unit used for isotopes half-life is annum (Q1092296)  View with Reasonator View with SQID. Problem, the normalized values for duration is not annum but Julian year (Q217208)  View with Reasonator View with SQID. Should we migrate or merge those two items ? It’s really convenient to use the normalized form in a query.

(Context, I’m writing a lua module for frwiki to generate a table of isotope, using a json file generated by a sparql query, that listeria bots puts and maintains in a wikipage. Problem, it’s convenient in the query to use the normalized values for half life … query and json listeria page — temporary result, probably broken fr:Modèle:Table_des_isotopes/Bac_à_sable. I can probably copy all this here afterwards) author  TomT0m / talk page 10:55, 25 February 2020 (UTC)[reply]

You can't merge them, they mean different things and have different sitelinks. I would suggest the best solution is to bug the people responsible for the normalization to switch to seconds. Or you can convert Julian years and annums to seconds and normalize that way. Year is too ambiguous a unit. ArthurPSmith (talk) 15:15, 25 February 2020 (UTC)[reply]
The precision for such values is huge and they are rounded, the ratio between the « annum » and is typically way bigger than the precision ratio of the values, so converting would not make much difference, the values are not precise enough. Besides, does the source of such statement does really « annum » ? It seems Julian year are pretty standards for this kind of stuff @ArthurPSmith: it seems it’s your bot that did the trick :) author  TomT0m / talk page 15:42, 25 February 2020 (UTC)[reply]
Ah, I see the issue is that the normalization doesn't handle "annum" at all. I guess I'd be ok with switching those to "Julian year", you're quite right that the difference is much less than the relative precision of these numbers at least in this case. ArthurPSmith (talk) 19:18, 25 February 2020 (UTC)[reply]
I put this on hold for the moment waiting for the answer in the contact the dev team for « annum » normalization. As it seems a unit used in chemistry/physics it would be nice to have. author  TomT0m / talk page 09:07, 26 February 2020 (UTC)[reply]

Specific impulse[edit]

Unfortunately, the term "specific impulse" has two slightly different definitions, one in terms of thrust per mass-flow, and another in terms of thrust per weight-flow, with different physical dimensionality, equivalent to velocity and time respectively. However, they are actually two different ways of measuring the same physical concept (basically "oomph per stuff"), with a scaling factor equivalent to the Earth's local gravitational acceleration. Until yesterday, there was only one entity to describe both.

While trying to assign a preferred unit to this, I've created two new entities, one for each definition, so that specific impulse (Q51504) now defines a class of physical quantity, with the two individual quantities having their own seperate entities specific impulse by weight (Q100828354) and specific impulse by mass (Q100793317). However, I can't see any clear way to refer to the individual well-defined concepts from the more general container concept.

Any suggestions would be welcome! -- The Anome (talk) 12:55, 25 October 2020 (UTC)[reply]

Thanks for creating those items. The issue you describe exists also for units of measurement where there exists one not-so-well-defined item (say, inch (Q218593)) and a couple of precisely defined items (say, inch (Q100046246), British Imperial inch (Q100063122), ...). I usually link them using different from (P1889). Toni 001 (talk) 09:15, 26 October 2020 (UTC)[reply]

Angular rates[edit]

I am not sure I see the differences and relations between a bunch of similar quantities: rotational velocity (Q25377096) (vector), angular velocity (Q161635) (vector), rotational speed (Q1256787) (scalar), angular speed (Q122208999) (?), angular frequency (Q834020). And rotational acceleration (Q122208905) vs. angular acceleration (Q186300). @Fgnievinski: how do you see it? Infovarius (talk) 20:53, 5 September 2023 (UTC)[reply]

@Infovarius: First, there's the difference between angle of rotation (normally in radians) and number of rotations (always in multiples of 1); they're off by a factor of 2π. I've linked to the articles in the English Wikipedia, where the topic is explained; I've spent several weeks sourcing it all to the ISO 80000 standards, SI Brochure, etc. Second, there are the corresponding temporal rates of change: angular rate (in rad/s) and rotational rate (in s-1 or Hz); again, "Ignoring this fact may cause an error of 2π.", as the BIPM warns (check the long quotes in en:Rotational_frequency#Notes and the animation in File:AngularFrequency.gif). Third, ordinary frequency is a generalization for cycles that are not necessarily a rotation -- the inverse duration period of any repeating phenomena. Fourth, angular speed and rotational speed are synonym with angular rate and rotational rate, respectively. Fifth, the corresponding velocities equal the product of speed and the axis of rotation, a unit vector; conversely, speed (scalar) is the norm of velocity (vector). Sixth, the two accelerations are the derivative of the corresponding velocities or, equivalently, the product of axis of rotation and second time derivatives of angle of rotation or number of rotations, respectively. It'd be easier to reason and explain if the SI had a dedicated dimension for angle, as it likely will have someday; without it, we have to pay special attention to the kind (or nature) of physical quantities. Otherwise, the myriad of uses for reciprocal seconds may be confusing. As put in the SI Brochure:

The SI unit of frequency is hertz, the SI unit of angular velocity and angular frequency is radian per second... Although it is formally correct to write all three of these units as the reciprocal second, the use of the different names emphasizes the different nature of the quantities concerned. It is especially important to carefully distinguish frequencies from angular frequencies, because by definition their numerical values differ by a factor [see ISO 80000-3 for details] of 2π. (...) Because of this, it is recommended that quantities called “frequency”, “angular frequency”, and “angular velocity” always be given explicit units of Hz or rad/s and not s−1.

The situation is only worse in the multitude of dimensionless units. Fgnievinski (talk) 08:56, 6 September 2023 (UTC)[reply]
The problem that I see is that you separate vector and scalar quantities. Is it necessary? I suppose it is artifact from English which has 2 words (speed and velocity) while most languages have one. --Infovarius (talk) 07:40, 8 September 2023 (UTC)[reply]
Which languages do you have in mind? In the Latin languages, "speed" may correspond to variations of "celerity" (es:celeridad, fr:célerité). Sometimes, though, the specific term is not always used, e.g., in French there's célérité du son but vitesse de la lumière; in that case, the vector nature may be emphasized, as in "vecteur vitesse". But the conceptual distinction, between the vector and its magnitude, is well established is standard vocabulary/terminology works:
Fgnievinski (talk) 23:26, 9 September 2023 (UTC)[reply]
Thanks for the references. 1) So indeed velocity/speed distinction is English-centric, half of languages (in IEC) even have no different terms for them. Acceleration e.g. doesn't have 2 similar quantities, because(?) it has no 2 words even in English. 2) I see in ISO only vector angular velocity, why to create separate (scalar) angular velocity item? --Infovarius (talk) 11:29, 11 September 2023 (UTC)[reply]
The distinction between the two concepts (vector and scalar) is well established in international standards, even in the SI Brochure (en/fr). When those standards are translated and adapted by national legal metrology authorities, the distinct concepts may receive longer names if a single word is unavailable in a particular language (as in "vecteur vitesse"). But the conceptual distinction is not removed. The more expressive language is not always English, e.g., the magnitude of angular velocity receives a special single-word term in French, "pulsation"; though it was adapted to English as "pulsatance" [10], that formal term didn't catch on, and "angular speed" is more commonly taught instead [11]. If you insist on saving some bytes, the scalar quantities "angular speed" and "rotational speed" could be merged, respetively, into "angular frequency" and "rotational frequency"; they're already noted as "said to be the same as". But the distinction between vector and scalar (and between angle of rotation and number of rotations) is sanctioned beyond doubt. Fgnievinski (talk) 03:12, 12 September 2023 (UTC)[reply]

How to specify the decay of a particle[edit]

I am updating the page of the Higgs boson (Q402), I am not sure the property decays to (P816) is suitable: it seems to me it has been designed for nucleai decay, but not for particle decay. The main problem is that I would like to express the final state of the decay and/or the intermediate state. Presently I read that the Higgs boson decays into W or Z boson (Q211922), electron (Q2225) and photon (Q3198). This is very naive, I would like to express decays as H->yy (two photons in the final state), H->ZZ, H->WW, H->mumu, ... There are many problems:

  • Should we count final states or intermediate states? The Higgs boson decay to ->ZZ, but then the two Z can decay in various modes, e.g. 4 electrons, 2 jets and 2 muons, ... (the list can become very large). For example the PDG list only intermediate states (bottom of https://pdglive.lbl.gov/Particle.action?node=S126&init=0). I guess this is the best way to go.
  • how to express set of items? How to express that one of the decay is ->Zy (the Higgs boson decays to one Z boson and one photon)? Of course we have Z boson (Q488719) and photon (Q3198), but how to express a set of the twos?
  • presently I see a "potential issue" since decays to (P816) require a qualifier decay mode (P817). This has a description "type of decay that a radioactive isotope undergoes (should be used as a qualifier for "decays to")", but we are not talking about isotopes here, and in fact all the instances are related to nuclear physics (three proton decay (Q21457313), alpha decay (Q179856), ...)

Wiso (talk) 09:39, 13 September 2023 (UTC)[reply]

Is model for and Modeled by[edit]

Please consider supporting Wikidata:Property_proposal/model_for. Thanks. Fgnievinski (talk) 02:57, 12 November 2023 (UTC)[reply]

Notified participants of WikiProject Physics @Fgnievinski: Proposal reopened : WD:Property proposal/model for (2) after the closing although a lot of support by the proposer.
I see that is the study of (P2578) is sometimes abused for this, see the theory of relativity (Q43514) item. author  TomT0m / talk page 16:04, 15 April 2024 (UTC)[reply]

Symmetries[edit]

A theory or equations are invariant under a group of transformations. For example special relativity (Q11455)  View with Reasonator View with SQID equations are invariant under Lorentz transformation (Q217255)  View with Reasonator View with SQID. There are many concepts associated in physics, such as Q3001822  View with Reasonator View with SQID which has an article on frwiki.

How could we model this ? This could be an interest in maths also so I'll notify project maths of this topic.

Tobias1984
Snipre
Physikerwelt
Pamputt
Petermahlzahn
Jibe-b
Restu20
Daniel Mietchen
TomT0m
ArthurPSmith
Mu301
Sarilho1
SR5
DavRosen
Danmichaelo
Ptolusque
PhilMINT
Malore
Thibdx
Ranjithsiji
Niko.georgiev
Simon Villeneuve
Toni 001
Marc André Miron
DePiep
RShigapov
CarlFriedberg
Crocodilecoup
Mkomboti
Amorenobr (talk) 01:27, 3 August 2022 (UTC)[reply]
Valverde667 (talk) 16:07, 4 August 2022 (UTC)[reply]
fgnievinski

Notified participants of WikiProject Physics

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

Notified participants of WikiProject Mathematics

author  TomT0m / talk page 13:55, 19 March 2024 (UTC)[reply]

@TomT0m: Were you aware of the relatively new property is invariant under (P12457)? I'm not sure it's being used in the way you suggest but I think it could be. ArthurPSmith (talk) 15:42, 19 March 2024 (UTC)[reply]
No I was not, interesting ! Although it seems that covariance is more general that invariance. Invariance is already useful.
I'm uncovering several intricated but unlinked items here like general covariance (Q2638561) / Q3001822 / principle of relativity (Q945995) and maybe more.
I'm not sure yet how to set all this up. author  TomT0m / talk page 16:03, 19 March 2024 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata_talk:WikiProject_Physics&oldid=2129896197"