Shortcut: WD:PP/SPACE

Wikidata:Property proposal/Space

From Wikidata
Jump to: navigation, search


Property proposal: Generic Authority control Person Organization
Event Creative work Term Space
Place Sports Sister projects
Economics Transportation Natural science Property metadata

See also[edit]


This page is for the proposal of new properties.

Before proposing a property
  1. Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See steps when creating properties.


On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2017/09.

Space[edit]

coordinate reference system[edit]

   Under discussion
Description coordinate (or spatial) reference system used to determine the coordinates of a location on Earth (default: WGS84) or some other globe
Represents spatial reference system (Q161779)
Data type Item
Domain coordinates on earth or any planet or natural satellite
Allowed values instances of spatial reference system (Q161779)
Example
Motivation

I thought we had a property for this for use a qualifier with coordinate location (P625), but it seems that we do not. Strictly speaking, coordinates - even on Earth - are meaningless without knowing the coordinates referencing system (CRS, also known as "spatial reference system" or "reference frame", see also geodetic reference system (Q1502887)) used - the usual one for coordinates on Earth is World Geodetic System 1984 (Q11902211) but one or more versions of each of International Terrestrial Reference System (Q74561), North American Datum (Q993433) and European Terrestrial Reference System 1989 (Q1378197) also exist, for example. The importance of specifying the reference system can be seen from [2], which gives several coordinates on the moon, and says "Differing results come from different models with different solutions. Currently, the lunar geoid is being redefined with Clementine data, so the location (latitude, longitude, and elevation) of everything will change again very soon. In short, we know where each of the [Lunar Modules] is located is relation to local landmarks; but assignment of latitude and longitudes to those locations is an evolving process.". Geo URI (Q5533943), for example, incudes a parameter for the CRS, see en:Geo URI scheme#Coordinate reference systems.

It may be assumed that, where not stated, the CRS for coordinates on Earth is WGS84, as that is used by most online mapping systems, GPS devices, and by the various WMF projects' mapping services. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:37, 9 January 2017 (UTC)

Discussion
  • Symbol oppose vote.svg Oppose redundant to existing qualifier for other property and unstructured when used in conjunction with P625.
    --- Jura 08:38, 10 January 2017 (UTC)
  • Pictogram voting comment.svg Comment This is a similar problem like with elevation above sea level (P2044) which is basically also meaningless without knowing the reference point. There it was decided to use determination method (P459) which seems to work quite well. --Pasleim (talk) 10:17, 10 January 2017 (UTC)
    • If we start adding values in P625 for places on Earth that are not using the default this just gets messy. I'm not sure why Pigs changed their mind on this. The earlier suggestion to use separate properties seems much more sensible.
      --- Jura 10:36, 10 January 2017 (UTC)

Happy to agree to this proposal. I understand that this will provide a link to an existing standard. Well done. Thanks, GerardM (talk) 14:22, 10 January 2017 (UTC)

I support the proposal and offer Washington Monument (Q178114) as an example. The most accurate value may not be stated in WGS84. The most desirable outcome would be to transform the coordinates into WGS84, or the nearly identical ITRF. The available qualifiers to specify that this was done, and how it was done, are sparse. The determination method property could be used to specify that a transformation was performed, and the proposed property could be used to state what coordinate system the value was transformed into. The untransformed value, of course, would be found in the referenced source. (An editor who won't be bothered referencing the source has no business transforming coordinates.) Jc3s5h (talk) 18:10, 10 January 2017 (UTC)

On further reflection, I think the user interface should be corrected to permit entry of the globe, and display whatever globe was chosen. Ideally editors would transform the value as necessary to ITRF or WGS84 and specify one of those as the globe, but if the editor didn't now how, they could specify whatever globe was used and leave it for a subsequent editor to do the transformation. It could also allow the entry of coordinates for features on other planets to be made through the user interface. Jc3s5h (talk) 18:29, 10 January 2017 (UTC)

Is there a Phabricator ticket for this proposed change to the interface? And an ETA for delivery? How does the later compare to the potential for having the proposed proerty in place in seven days or so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:48, 10 January 2017 (UTC)
If the property is approved, what would your plan be to undo all the non-Earth globe fields that already exist, and remove globe from the data model (which, in the case of JSON, itself requires a Phabricator ticket)? Jc3s5h (talk) 22:09, 10 January 2017 (UTC)
I would do neither. For several globes, as well as Earth (e.g. Moon, Mars) there is more than one CRS. For each, we can assume or declare a default, but this proposal allows the specification of another. This proposal is not mutually exclusive with yours, and yours is not a reason not to do this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:14, 10 January 2017 (UTC)
I have created a Phabricator ticket in line with my response above, but it turns out there was already a Phabricator on the issue. Jc3s5h (talk) 22:30, 10 January 2017 (UTC) updated 11:48 11 January 2017 (UTC)
  • Pictogram voting comment.svg Comment, not sure if it should be a property or not… Embedding the coordinate system in the coordinnates, like it's done for the globe, would probably be better but as the globe is still not implemented in the interface right now (and it's causing several problems, like people adding earthly coordinate outside of Earth), I'm reluctant and hesitant. Cdlt, VIGNERON (talk) 10:58, 11 January 2017 (UTC)
  • Pictogram voting comment.svg Comment The more I think about it, the less happy I am with this proposal. For much of the 20th century, latitudes and longitudes in the UK were stated with reference to OSGB36 -- typically this gives a point on the ground about 100 to 150 metres away from where WGS84 would indicate. I am not at all happy with the thought of OSGB36 coordinates being used with P625, even when marked with a qualifier. I think we should maintain an insistence that all terrestial coordinates are converted to WGS84, so that this is the only scheme for terrestial coordinates that is acceptable as an argument for P625. Otherwise we are demanding that any use of P625 data must check the qualifiers and must be prepared to do coordinate conversions. As well as being a complete millstone, it's simply not realistic to expect this of data users. Most SPARQL searches don't even check qualifiers at all.
Instead I could see value in a qualifying the data with a qualifier "originally stated as" + a qualifier "original coordinate system", if we want to record how the data may have been originally presented in a given source. Jheald (talk) 21:56, 22 January 2017 (UTC)
  • Symbol support vote.svg Support This would help phab:T162331 a lot too. --Liuxinyu970226 (talk) 14:49, 11 May 2017 (UTC)
    • I object to taking such devices for map censorship (GCJ02 (Q29043602), BD09 (Q29043632)) seriously and making them acceptable for P625. These things are designed out of bad faith (creating drifts) and not numbered by ESGI; GCJ-02 in particular has the laughable error of using SK-42 ellipsoid for drifting WGS-84 input. They should be shot – rectified, I mean – on sight (um, input?). It's terrible to think about complicating queries for just these two bad things. --Artoria2e5 (talk) 18:08, 25 August 2017 (UTC)
  • Symbol oppose vote.svg Oppose Better to fix the bug Liuxinyu brought up on our end than to force others who use Wikidata to account for differing Earth geo-coordinates on their end. Mahir256 (talk) 20:49, 25 August 2017 (UTC)
    • Given that the proposal includes examples of lunar and Martian coordinates, your comment, and its basis in "differing Earth geo-coordinates", gives me concern that you may not have read it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:36, 26 August 2017 (UTC)
      • @Mahir256: This proposal per se is about easily inputting some older geodata not yet transformed to WGS84, not the terrible screw-ups Liu brought up. On another thought though, if this property is made to "rectify to WGS84 immediately by a patrolling bot", it may ease the workload on human users. Just don't keep data marked with it for long-term use… --Artoria2e5 (talk) 15:02, 26 August 2017 (UTC)
        • Good luck having a bot rectify lunar or Martian coordinates to WGS84. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:22, 26 August 2017 (UTC)
          • Apologies for misreading. Was looking at the OSGB36 comment. --Artoria2e5 (talk) 15:35, 26 August 2017 (UTC)
      • @Pigsonthewing: The general concern in the comment that I had was one of lack of standardization. You can replace Earth in that comment with any other celestial body; we should be assuming a standard coordinate system for each celestial body just as we do with WGS84 for Earth on Wikidata. (In fact, I'm sure the appropriate coordinate system can be readily assumed depending on the item in question.) There is no benefit to having multiple versions of the same coordinates for the Moon, or Mars, or any other such body (except in the random case where a location can't be expressed in one system but can in another), just as we don't need WGS84, GCJ-02, and BD-09 coordinates for locations on Earth in the same item. Instead there should be conversion tools for these as discussed (for Earth) in the ticket Liuxinyu linked to. Mahir256 (talk) 20:56, 26 August 2017 (UTC)
        • Who said anything about "multiple versions of the same coordinates"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:19, 26 August 2017 (UTC)
          • @Pigsonthewing: If this is intended for use [as] a qualifier with coordinate location (P625), it becomes conceivable for this property to become a separator (P4155) for coordinate location (P625)'s single value constraint (Q19474404). If you are not intending to modify that constraint to accommodate this property, then there should be some bot for converting non-standard coordinates (identified with this property as a qualifier) to standard ones—for non-Earth celestial bodies, such standards could be discussed separately—made ready before the property is established. (Perhaps I am way too fixated on Liuxinyu's rationale for supporting and Artoria's response to it.) Mahir256 (talk) 23:04, 26 August 2017 (UTC)

stellar rotational velocity[edit]

   Under discussion
Data type Number (not available yet)
Template parameter
Domain star (Q523)
Allowed units kilometer per second (Q4220561)
Example Pollux (Q13028) → 2.8 km/s
Planned use Import from Wikipedia to Wikidata.
Motivation

(Add your motivation for this property here.) Mikey641 (talk) 21:57, 1 April 2017 (UTC)


Discussion

Paperoastro Sarilho1 YsogoCekli829 Manlleus Meodudlye, with only limited amount of time to spend in the foreseable future. Romaine - like adding observatory codes + mapping usage (like the *observatory codes) mikeu Jc3s5h VIGNERON Harlock81 Ptolusque Pictogram voting comment.svg Notified participants of WikiProject Astronomy--Mikey641 (talk) 21:59, 1 April 2017 (UTC)

Pictogram voting comment.svg Comment Hmm, this is computable from rotation period (P2147) and radius (P2120) so do we really need a separate property for this? It may be more directly measured I suppose (and the radius for example might not be known). Also I note the proposed name has been shortened to "rotational velocity" leaving out "stellar" so it could be applied to non-stars; however the value would depend on where on the surface of the object you are measuring - the rotational velocity of an asteroid, say, is not a well-defined quantity because different parts of the surface are at different distances from the axis of rotation and so move at different speeds. So not sure about this at the moment. ArthurPSmith (talk) 13:36, 3 April 2017 (UTC)
If it should be created at all, it shouldn't be called "rotational velocity" because that is too much like angular velocity (Q161635). No reliable source has been presented showing that the term "rotational velocity" is used by the scientific community, or if so, it means what this proposal says it means. Jc3s5h (talk) 15:15, 4 April 2017 (UTC)
@Jc3s5h: Changed it to Stellar Rotational Velocity--Mikey641 (talk) 17:36, 2 May 2017 (UTC)
@Mikey641: Is there a reason it is capitalized, as far as I can find, it should not be. Josh Baumgartner (talk) 21:17, 3 May 2017 (UTC)
fixed - no we don't capitalize generic properties ArthurPSmith (talk) 20:31, 4 May 2017 (UTC)
What's the prior art with naming this relationship in astronomy? ChristianKl (talk) 10:58, 22 May 2017 (UTC)

DAMIT ID[edit]

   Under discussion
Description Identifier for Database of Asteroid Models from Inversion Techniques
Data type External identifier
Example 2 Pallas (Q3002)101
Formatter URL http://astro.troja.mff.cuni.cz/projects/asteroids3D/web.php?page=db_asteroid_detail&asteroid_id=„$1
Motivation

On site is useful information and external links Walter Klosse (talk) 16:19, 14 June 2017 (UTC)

Discussion
Pictogram voting comment.svg Comment @Walter Klosse: this looks interesting. However to be clear what is being identified here is the "asteroid id" - there is also a "model id" on the site which is something different (although model 101 happens to also be a model for Pallas, along with model 102). The label on the property should probably be clearer - 'DAMIT astroid id" perhaps? ArthurPSmith (talk) 16:52, 15 June 2017 (UTC)

synodic period[edit]

   Under discussion
Description Translated definition from the Wikipedia in French: "The synodic period of a planet is the time taken by this planet to return to the same Earth-planet-Sun configuration."
Represents no label (Q3411977)
Data type Point in time
Template parameter « période synodique » within fr:Modèle:Infobox Planète
Domain celestial bodies orbiting about a bigger one (usually stars)
Allowed values numbers
Allowed units hours, days, years
Example Saturn (Q193) → 378.0944 days
Format and edit filter validation "month" and "century" can't be used
Planned use This property is going to be used inside fr:Modèle:Infobox Astre ("astre" means "celestial body" in French", the planned replacement for fr:Modèle:Infobox Planète, fr:Modèle:Infobox Exoplanète, and other infobox models related to celestial bodies. The creation of this new infobox is coordinated on the local Astronomy wikiproject.
Motivation

We're creating for fr:Projet:Astronomy a replacement in Lua for the bunch of infoboxes that already existed on the Wikipedia in French about celestial bodies and that are hard to maintain and not linked to Wikidata. We already successfully created last year a replacement for our former planetary geography infobox like this, but the Wikidata properties were already available back then. J. N. Squire (talk) 11:45, 5 September 2017 (UTC)

Discussion
Symbol support vote.svg Support you should maybe add orbital period (P2146) as a "see also" (related but different). Also I believe the domain should only include planets (and smaller bodies) within our solar system - the definition makes no sense for extra-solar planets. ArthurPSmith (talk) 19:22, 5 September 2017 (UTC)

sidereal period[edit]

   Under discussion
Description Translated definition from the Wikipedia in French: "Time that elapses between two passes of the object in front of a distant star. It is the "absolute" period in the Newtonian sense of the term."
Represents sidereal period (Q12874157)
Data type Point in time
Template parameter « période de révolution » within fr:Modèle:Infobox Planète (sidereal period is the most often used type of period of revolution, which is a blanket term for a lot of different period types)
Domain celestial objects orbiting about another one (usually a star, a planet or a moon)
Allowed values numbers
Allowed units hours, days, years
Example Saturn (Q193) → 10757.7365 days
Format and edit filter validation "month" and "century" can't be used
Planned use This property is going to be used inside fr:Modèle:Infobox Astre ("astre" means "celestial body" in French", the planned replacement for fr:Modèle:Infobox Planète, fr:Modèle:Infobox Exoplanète, and other infobox models related to celestial bodies. The creation of this new infobox is coordinated on the local Astronomy wikiproject.
Motivation

We're creating for fr:Projet:Astronomy a replacement in Lua for the bunch of infoboxes that already existed on the Wikipedia in French about celestial bodies and that are hard to maintain and not linked to Wikidata. We already successfully created last year a replacement for our former planetary geography infobox like this, but the Wikidata properties were already available back then. J. N. Squire (talk) 11:45, 5 September 2017 (UTC)

Discussion

Pictogram voting comment.svg Comment isn't this just a special case of orbital period (P2146)? If it's not the standard definition for orbital period it could be identified with a qualifier, for example determination method (P459) sidereal period (Q12874157). ArthurPSmith (talk) 19:28, 5 September 2017 (UTC)

@J. N. Squire: can you respond? Is this really distinct from orbital period (P2146)? ArthurPSmith (talk) 17:52, 12 September 2017 (UTC)
@ArthurPSmith: Sorry, I missed that update. ^^; As for your question, yes, it's one type of orbital period (P2146). Same thing with Wikidata:Property proposal/période synodique, actually. Does it mean a new property isn't needed for this? Because it means I could improve the infobox Lua module immediately then, which would be a good thing. ^^ J. N. Squire (talk) 20:12, 12 September 2017 (UTC)
why don't you try making it work with the existing property and then see if something new is really needed? I think at least this one is really exactly the same as the default meaning of orbital period (P2146) so I'm pretty sure this one isn't needed. Don't know about synodic period. ArthurPSmith (talk) 19:24, 13 September 2017 (UTC)