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. Change status=ready on template to attract the attention of a property creator.
  2. Creation can be done after 1 week 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/04.


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)

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)

  • 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)

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.

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


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 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)