Wikidata:Property proposal/proper motion components

proper motion components

declination component of proper motion

Originally proposed at Wikidata:Property proposal/Natural science

   Done: declination component of proper motion (P10751) (Talk and documentation)

Description	the value $\mu _{\delta }$, as a component of proper motion
Represents	proper motion (Q193223) (declination (Q76287))
Data type	Quantity
Domain	astronomical object (Q6999)
Example 1	Deneb (Q12179) → 1.85±0.27 milliarcsecond per year
Example 2	Antares (Q12166) → -23.3±0.76 milliarcsecond per year
Example 3	Canopus (Q12189) → 23.24±0.69 milliarcsecond per year
Planned use	migrate existing values for P2215 (P2215) with qualifier of (P642) declination (Q76287) to use this property
See also	P2215 (P2215)

right ascension component of proper motion

Originally proposed at Wikidata:Property proposal/Natural science

   Done: right ascension component of proper motion (P10752) (Talk and documentation)

Description	the value $\mu _{\alpha }$, as a component of proper motion
Represents	proper motion (Q193223) (right ascension (Q13442))
Data type	Quantity
Domain	astronomical object (Q6999)
Example 1	Deneb (Q12179) → 2.01±0.34 milliarcsecond per year
Example 2	Antares (Q12166) → -12.11±1.22 milliarcsecond per year
Example 3	Canopus (Q12189) → 19.93±0.52 milliarcsecond per year
Planned use	migrate existing values for P2215 (P2215) with qualifier of (P642) right ascension (Q13442) to use this property
See also	P2215 (P2215)

Motivation

The majority of of (P642) uses currently involve qualifying P2215 (P2215) with either declination (Q76287) or right ascension (Q13442). Migrating all of them to use one of the above two properties would eliminate the 10+ million triples taken up by the P642 qualifiers. @Ghuron: Mahir256 (talk) 19:06, 4 May 2022 (UTC)

Discussion

•  Strong support Lectrician1 (talk) 19:29, 4 May 2022 (UTC)

@Swpb, Jura1, Vojtěch Dostál, SM5POR: you should all be interested in this! Lectrician1 (talk) 19:46, 4 May 2022 (UTC)

• That would certainly simplify using proper motion data in infoboxes. 10M edits is not that much Ghuron (talk) 07:14, 5 May 2022 (UTC)
•  Support!!! Swpb (talk) 14:09, 5 May 2022 (UTC)
•  Support Good idea. ArthurPSmith (talk) 15:43, 9 May 2022 (UTC)
•  Support makes sense and it would makes things a lot easier. Romuald 2 (talk) 16:32, 10 May 2022 (UTC)
• @Ghuron, Mahir256, Lectrician1, Swpb, ArthurPSmith, Romuald 2:  Done --Tinker Bell ★ ♥ 01:21, 13 May 2022 (UTC)

Too bad I was busy with other stuff this past week... I appreciate this issue being attended to, but I see a problem with pairing two properties to represent what is essentially one data point: How do you deal with items having multiple data points, such as observations from different surveys, at different times, by different observers, using different techniques, or being assigned different ranks at Wikidata for any of a number of reasons? See Barnard's Star (Q14268) for what I would consider the canonical model item for a star with proper motion; it has no less than nine data points, one of which is preferred and therefore unique, but you need to look at the references to see which ones go together (and two sources happen to give the same -720 milliarcseconds per year R.A. value, wherefore they have been collapsed into a single statement with two references). It's doable if done right, of course, but hardly convenient or intuitive. However, creating a new arc vector datatype combining those scalars into one statement may take a long time, and the of (P642) issue may be more urgent. Should I bring this issue up elsewhere, do you think, now that the properties are already created? --SM5POR (talk) 16:15, 13 May 2022 (UTC)

@SM5POR I would make individual items for individual observations and propose a "proper motion of" property:

observationproper motion ofastronomical object

Then we can use the new properties on those items and also easily document the other details about observations you noted without requiring qualifiers to be copied between the two separate values on an astronomical object. Lectrician1 (talk) 19:43, 13 May 2022 (UTC)

That would seem to introduce another level of abstraction in Wikidata, as you would no longer assert measured data directly as properties of the astronomical objects themselves, but only of observations of said objects. Replacing 10 million+ qualified statements about stars with 10 million+ statements about observations associated with those stars doesn't seem that much of an improvement to me, even if we get rid of the of (P642) qualifier in the process. Do I understand you correctly here? Note that the concept of multiple values for the same property isn't limited to the proper motion of stars, or even to the field of astronomy as a whole; it's pervasive in the entire scientific realm (and probably outside it as well). Neither is this apparent ambiguity limited to observations with varying degree of accuracy and reliability that can be dealt with using preferred or deprecated rank, but they may relate to multiple reliable observations as the actual physical value changes with time. I'm not aware of any observations of proper motion in particular to have increased or decreased as the star's distance and direction relative to the Solar System changes, but it's theoretically possible as the precision of our measurements increase, and it's certainly a fact with other properties such as luminosity, which may vary considerably over time (just watch out for Betelgeuse (Q12124) going nova any millennium now). Then we have changes in human population, ice sheet coverage, climate etc. All this variability is nicely dealt with using different qualifiers. However, each qualifier can only handle a single statement, not a pair or other group of interrelated statements, such as the X and Y scalars of a two-dimensional vector. Combining those scalars into one data type, like latitude and longitude, would resolve that, I think. --SM5POR (talk) 05:21, 14 May 2022 (UTC)

Also note that we don't want to handle certain properties as special cases in generic software to access Wikidata (obtaining the proper motion of a distant star would require an algorithm different from the one used for 10,000+ other properties of objects in general). Applying different inheritance paths to different properties in the class tree is tricky enough, and even that hasn't been generally implemented yet. --SM5POR (talk) 05:56, 14 May 2022 (UTC)

@SM5POR Yeah, I mean I totally agree we need a double-value data type, I just proposed this as a temporary workaround. There is already a task for adding celestial coordinate data type as you described but it hasn't been worked on for 6 years and I don't think it will any time soon... Lectrician1 (talk) 13:45, 14 May 2022 (UTC)

@Mahir256: Will you be running a job to convert all of the current values at some point or should someone else? Lectrician1 (talk) 12:37, 13 May 2022 (UTC)

@Lectrician1: Once the templates on other wikis which use 'proper motion' are adjusted to read from these new properties, I can start a migration then. (It will be a lot of edits, no matter what Ghuron thinks of the number.) Mahir256 (talk) 15:25, 13 May 2022 (UTC)