Shortcut: WD:DEV
Wikidata:Contact the development team
Contact the development team 
Contact the development team
Wikidata development is ongoing. You can leave notes for the development team here, on #wikidata ^{connect} and on the mailing list or report bugs on Phabricator. (See the list of open bugs on Phabricator.) Regarding the accounts of the Wikidata development team, we have decided on the following rules:

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/01. 
Contents
dewiki versus de[edit]
While adding another language version I get offered to choose from "de" and "dewiki". If I choosed "de" I get an error message. Thats obviously a bug in the software one way or another. Eingangskontrolle (talk) 18:13, 7 January 2017 (UTC)
 Hello @Eingangskontrolle:, thanks for reporting this problem. Can you give me some details about "While adding another language version"? Is this in the general Wikidata interface? Is this when editing a statement? I can't find where you encounter this problem. Thanks, Lea Lacroix (WMDE) (talk) 14:21, 9 January 2017 (UTC)
As usual, there are so many options inside the system thats hard to predict what other will see in the same situation. I encounter two different layouts when adding aother language version.
Sometimes its the long version, where I see all existing versions. I scroll down to the bottom, add "en", "es" or "de" and the lemma.
Sometimes i get the short version. It looks much like https://www.wikidata.org/wiki/Special:NewItem?site=dewiki&page=Hermann%20Stamm&label=Hermann%20Stamm&lang=de Of course when I come from a Wikidata page the system does not know which laguage I want to add. So I write "de" and get the options "de" and "dewiki"  "de" is despite the offer not available and causes the error message. Eingangskontrolle (talk) 15:13, 9 January 2017 (UTC)
 I can currently not reproduce this. @Eingangskontrolle: Are you doing these edits on a Wikipedia page (in the "in other languages" sidebar on the left) or on an item page here in wikidata.org? I tried both, and in both cases I can type (for example) "en", and get a single suggestion for "enwiki", but never two. Thiemo Mättig (WMDE) 17:18, 12 January 2017 (UTC)
 What does the error message say?  Nikki (talk) 17:35, 12 January 2017 (UTC)
Technical question[edit]
I can't understand why the query
select ?item {
?item a wikibase:Item .
} limit 10
does not return any result. Does anyone know ? author TomT0m / talk page 12:31, 8 January 2017 (UTC)
 @TomT0m: These triples are currently omitted, see also number 2 on mw:Wikibase/Indexing/RDF Dump Format#WDQS data differences. Cheers, Hoo man (talk) 22:37, 9 January 2017 (UTC)
Alternative to the Celestial coordinate datatype[edit]
Since according to this the celestial coordinate datatype is not in the development plan, would it be possible to have a lightweight alternative? For instance creating a property "celestial coordinate" with datatype string and formatting it to link to Wikisky as it can be seen on w:Sirius. If is it feasible, which format should the string have?Micru (talk) 14:53, 9 January 2017 (UTC)
 Why not use the Coordinates datatype and add a feature that modifies how the data is displayed and added in the GUI?  Innocent bystander (talk) 16:46, 9 January 2017 (UTC
 The GUI is not the only way to add or consume data to or from Wikidata. So a GUIonly solution is not suitable. Jc3s5h (talk) 17:01, 9 January 2017 (UTC)
 Yes, that is true. But the Coordinate datatype provide us with a 2 axiscoordinatesystem. To me, that looks like all we need. The rest is basic linear algebra, something that converts from one coordinate system to another. Already today, everything is stored in decimal format, but what I see in the GUI is a dmsformat. That already looks like some GUImagic to me!  Innocent bystander (talk) 12:42, 10 January 2017 (UTC)
 The GUI is not the only way to add or consume data to or from Wikidata. So a GUIonly solution is not suitable. Jc3s5h (talk) 17:01, 9 January 2017 (UTC)



 coordinate location (P625) gives a direction in a three axis space (x, y, and z), but the distance from the origin to the point of interest (in the case of coordinate location (P625), altitude) is depricated. If one adds a coordinate location (P625) property to a celestial object and uses the default globe (Earth), and wishes to transform that to celestial coordinates (perhaps ICRF) the first step is to decide what the geographical coordinate even means. Suppose you interpret it to mean that a line from the center of the Earth to the celestial object passes through the crust of the Earth at the designated location. To perform the transformation, you will have to know when the statement was true. The precision of the time must be commensurate with the directional accuracy desired. But presently, Wikidata datetime datatype can't record times to a precision of better than 1 day, which is completely useless, because the point where the line to the object goes through the crust will describe a circle (technically, a parallel of latitude) all the way around the Earth during 1 day. Jc3s5h (talk) 17:44, 10 January 2017 (UTC)
 P625 gives us two axis. In P625 we have a third parameter "globe=Earth" that defines the coordinatesystem. A point in London (Greenwich) defines one axis and the Equator defines the other. So "Q2" in the globe parameter defines a coordinatesystem. There are other coordinatesystems, but this is the most globally used. We could theoretically allow new values in this globeparameter that defines exactly what you want, including the point in time with the precision you need. If it cannot be expressed by our time datatype today, it could be described by a label, or with a Julian Day Number, with the precision down to several decimals.  Innocent bystander (talk) 09:15, 11 January 2017 (UTC)
 I wouldn't write it the way Innocent bystander wrote it, but the globe field of coordinate location (P625) (which currently can only be entered with the API, not with the user interface) does indeed imply or specify a coordinate system. If we specified International Celestial Reference Frame (Q3153243) for the globe field, we would be close to what we need. The declination value in ICRF would correspond to terrestrial latitude, and can be expressed in the same way, degrees north (positive) or south (negative) of the equator. But the ICRF value that corresponds to longitude is called right ascension, and it is normally expressed differently than longitude; longitude is expressed as an angle east of Greenwich, either in the range 0° to 359.999...° or using negative values to express west longitude, in the range −179.999...° to 179.999...°. Right ascension is the angle along the celestial equator from (approximately) the vernal equinox eastward to the great circle that passes through the object. It is usually expressed in hours, minutes, and seconds (with decimal places for the seconds if necessary). The range is from 0 h to 3 h 59 m 59.999... s.
 P625 gives us two axis. In P625 we have a third parameter "globe=Earth" that defines the coordinatesystem. A point in London (Greenwich) defines one axis and the Equator defines the other. So "Q2" in the globe parameter defines a coordinatesystem. There are other coordinatesystems, but this is the most globally used. We could theoretically allow new values in this globeparameter that defines exactly what you want, including the point in time with the precision you need. If it cannot be expressed by our time datatype today, it could be described by a label, or with a Julian Day Number, with the precision down to several decimals.  Innocent bystander (talk) 09:15, 11 January 2017 (UTC)
 coordinate location (P625) gives a direction in a three axis space (x, y, and z), but the distance from the origin to the point of interest (in the case of coordinate location (P625), altitude) is depricated. If one adds a coordinate location (P625) property to a celestial object and uses the default globe (Earth), and wishes to transform that to celestial coordinates (perhaps ICRF) the first step is to decide what the geographical coordinate even means. Suppose you interpret it to mean that a line from the center of the Earth to the celestial object passes through the crust of the Earth at the designated location. To perform the transformation, you will have to know when the statement was true. The precision of the time must be commensurate with the directional accuracy desired. But presently, Wikidata datetime datatype can't record times to a precision of better than 1 day, which is completely useless, because the point where the line to the object goes through the crust will describe a circle (technically, a parallel of latitude) all the way around the Earth during 1 day. Jc3s5h (talk) 17:44, 10 January 2017 (UTC)







 It would be very confusing to label the celestial coordinates with latitude and longitude, because there is a type of celestial coordinates, called ecliptic coordinates, which use latitude and longitude. However, ecliptic coordinates are seldom used to publish the coordinates of celestial objects; I believe they are mainly used today in intermediate calculations. Jc3s5h (talk) 12:38, 11 January 2017 (UTC)
 The name of the axis could potentially be a problem, yes, but only if we allow it to be. The coordinate system I now work with from Statistics Sweden have X and Y instead of lat and long as axis. Converting these coordinates to a "normal" lat/long system is doable, but it is not a linear relation between them. How is it with the Moon and other nonEarthglobes? Does it always use a 180  +180 degree range? I have not worked with them very much, but if I remember correctly, they are sometimes in the range 0360? Unfortunately, the system built here, is more adapted to GeoHack@Wmflabs and Wikipedia, than how it looks IRL. That is maybe well described below.  Innocent bystander (talk) 18:11, 11 January 2017 (UTC)
 It would be very confusing to label the celestial coordinates with latitude and longitude, because there is a type of celestial coordinates, called ecliptic coordinates, which use latitude and longitude. However, ecliptic coordinates are seldom used to publish the coordinates of celestial objects; I believe they are mainly used today in intermediate calculations. Jc3s5h (talk) 12:38, 11 January 2017 (UTC)




To begin with, three dimensional objects or spaces require three axes, x, y, and z. An equivalent way to express the position of a point is two angles (declination and right ascension or latitude and longitude) and one distance (normally, the distance from the origin, where x, y, and z are zero). These are equivalent ways of representing the position of a point in space, and methods to transform between them are widely available in standard textbooks. The problem in astronomy is that the direction can normally be measured with great precision, but the distance is often poorly known. In both astronomy and geography, the distance from the origin is often not as important as the declination and right ascension (or latitude and longitude). For example, if I wanted to use my handheld GPS to walk to the spot in the woods where I put up my hunting blind, and the area wasn't mountainous, I wouldn't care all that much about the altitude.
The specification in Wikidata for the latitude and longitude can be found at mediawikiwiki:Wikibase/DataModel#Geographic_locations:
 a latitude (decimal, no default, 9 digits after the dot and two before, signed)
 a longitude (decimal, no default, 9 digits after the dot and three before, signed)
So, that isn't too specific. In theory, I could say the longitude of New York City is about 646° (one complete circle around the equator plus 286° more). But it is conventional to use the ranges I described before. I checked https://tools.wmflabs.org/geohack/ and found I could use either 74° or 286° as a longitude for New York City. Jc3s5h (talk) 20:58, 11 January 2017 (UTC)
I see I missed a question:
The coordinate system I now work with from Statistics Sweden have X and Y instead of lat and long as axis. Converting these coordinates to a "normal" lat/long system is doable, but it is not a linear relation between them. How is it with the Moon and other nonEarthglobes? Does it always use a 180  +180 degree range?
Dealing with latitude and longitude is more cumbersome than dealing with X and Y. National agencies that deal with mapping an surveying such as the w:National Geodedic Survey, often set up x, y coordinate systems over limited areas, where neglecting the curvature of the Earth won't cause any serious errors. In the US, these are called state plane survey zones; there is one zone for a small state; larger states like Texas are divided into several zones. I don't think we'll see zones like this set up on other planets until we start building highways and buildings on those planets. Until then, we'll be mostly interested in large areas of the planets, and latitude and longitude are more suitable when you're discussing large areas of a globe. Jc3s5h (talk) 21:13, 11 January 2017 (UTC)
Coordinates on celestial bodies[edit]
 On a related note, I thought we had a property 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 "reference frame") 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. For the Moon, we usually use Selenographic coordinates (Q570069). The importance of specifying the reference system can be seen from [1], 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.". The GeoURI scheme incudes a parameter for the CRS, see en:Geo URI scheme#Coordinate reference systems. I have posted a property proposal at Wikidata:Property proposal/Coordinate reference system. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:39, 9 January 2017 (UTC)
Enforce community curated constraints at client side[edit]
I was able to add an invalid value while Constraint:Single value was present at the talk page.
I prefer warnings about incorrect values interactively. d1g (talk) 11:54, 14 January 2017 (UTC)
Follow suggested types during Autocomplete[edit]
I was able to fill Earth (Q2) in handedness (P552). d1g (talk) 11:58, 14 January 2017 (UTC)