Wikidata:Contact the development team/Archive/2017/01

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Allow longer URLs

I would like to link in a refernce to the file http://ricerca.agenziaentrate.gov.it/Wrapper/entrate/mySolrUpdate.jsp?q=2E3CE96DE6DD8997&id=EB089AAE3BA0383902CB9F0F4D90DCD505B45548CF3284194AB6A38A2014F388AC48646316D9E27C04FFF42733580F42851286DBF3145C157E4C7438BD122C2E0EBC57F6388C49DB0B44FAB9D4C8D19DCF37D2E1A1A47E6E398597D655E9C7CFD77308960AB0CA17EAF613C15B4D69858BB2B73A7D4221EE7520D6FFA15B0245831BAA8B18DB20C58FAE8F95AB92B385113A2D8B47A4252AE2F0425F456CD593E22F8BE610473459E4F9A06B6D05794C81ACCF1B463C403241DBA9FA647582500477FE6223C519BF60518D8ACE6CACB67AF070970C670FC078418E3070AD245E5097D7B3A467233DC2B6CF554F1A6F1C5BA0617CBF5DE08B1544A24B77ECB5E6BA49545AE0764751. However, it doesn't allow me because it's longer than 500 characters. Could you set this limit a bit higher? --Pasleim (talk) 21:02, 26 December 2016 (UTC)

We had a discussion about it on the mailing list. That kinda got stuck then. I'll pick it back up - probably after the holidays. --Lydia Pintscher (WMDE) (talk) 13:16, 27 December 2016 (UTC)

@Lydia Pintscher (WMDE): Nudge. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:58, 4 January 2017 (UTC)

Thanks for the ping. I've created phabricator:T154660. Please have a look and add comments if you have any. --Lydia Pintscher (WMDE) (talk) 12:42, 5 January 2017 (UTC)

Datatype for linking queries?

Is there going to be a datatype for linking items with queries? It would be nice to have a property to link queries representing a given category or list. The URL datatype doesn't seem appropriate unless we use an URL-shortener like tinyurl.com as it is available on WQS and I don't know about the reliability of this external service.--Micru (talk) 15:57, 4 January 2017 (UTC)

For the particular usecase a gadget is probably better to autogenerate the list. There is already one - easyquery. Once we have query entities we will likely have a datatype to link to them however. --Lydia Pintscher (WMDE) (talk) 12:45, 5 January 2017 (UTC)

dewiki versus de

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

I can't understand why the query

select ?item {
  ?item a wikibase:Item .
} limit 10

Try it!

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

Tracked in Phabricator
Task T56097

Tracked in Phabricator
Task T127950

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 GUI-only 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 axis-coordinate-system. 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 dms-format. That already looks like some GUI-magic to me! -- Innocent bystander (talk) 12:42, 10 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 coordinate-system. A point in London (Greenwich) defines one axis and the Equator defines the other. So "Q2" in the globe parameter defines a coordinate-system. There are other coordinate-systems, but this is the most globally used. We could theoretically allow new values in this globe-parameter 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.

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 non-Earth-globes? 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 0-360? 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)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘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 non-Earth-globes? 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

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 Geo-URI 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

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

I was able to fill Earth (Q2) in handedness (P552). d1g (talk) 11:58, 14 January 2017 (UTC)

@D1gggg: (This also answers the question above) The data model used by Wikidata doesn't enforce any constraints on the data (except for the mere data type). That is per design to support all of the world's weirdnesses. There are soft constraints (constraints that are not strictly enforced on save but are rather monitored by individual users using lists of these violations) maintained by the community. We currently have (premature) support for checking these constraints in the software: Special:ConstraintReport/Q42. It is planned to build up upon that and also potentially include it into the UI more prominently. Cheers, Hoo man (talk) 09:43, 19 January 2017 (UTC)

Wiktionary / Cognate

Do you have some plan (date, how long) for Wiktionary support? It seems (in Wikidata weekly summary #244)development for phase [0] is almost finished... JAn Dudík (talk) 17:41, 23 January 2017 (UTC)

Hello,

The phase 0 (Cognate extension to improve interlinking between Wiktionaries) is ready to be deployed, and we will only need a few days to prepare the announcement in several languages. So I would say that the announcement will be next week and the deployment one week after :) Lea Lacroix (WMDE) (talk) 11:28, 26 January 2017 (UTC)

Formatter URLs that require modification of the statement string value

Is there a way to modify the string value of the statement that is used to construct the formatter URL (P1630) for a particular statement? We are adding IDs for ontologies in Open Biological and Biomedical Ontology Foundry Ontologies (Q4117183), using their CURIE, which has a colon as the separator between the namespace/prefix and the numerical code. However, the url we'd like to use (a https://en.wikipedia.org/wiki/Persistent_uniform_resource_locator) has the colon replaced by an underscore.

For example, an ID in the relations ontology looks like this: RO:0002008, but the url looks like this: http://purl.obolibrary.org/obo/RO_0002008. It is important to keep the prefix within these codes, so simply using the numerical code is not a good solution. Thanks in advance! Gstupp (talk) 21:07, 26 January 2017 (UTC)

You could ask obolibrary to institute server-side redirects. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:30, 26 January 2017 (UTC)

There is phabricator:T151329 for this. --Pasleim (talk) 21:59, 26 January 2017 (UTC)

Maybe of interest: Create guidelines for OBO maintainers who want to be included in Wikidata. --Succu (talk) 22:14, 26 January 2017 (UTC)

Sorting of statements has a hickup

There is a Gadget, helping sorting the statements in items (P31 at the top etc). I cannot find it in the list at Special:Preferences today, but I know it used to be there. The problem now is that this gadget fails when I come to an item directly from a client. It works when I reload the page or follow a link here at Wikidata, but not always otherwise. -- Innocent bystander (talk) 08:42, 30 January 2017 (UTC)

Hello, is it MediaWiki:Gadget-statementSort.js? Did you try to purge the page when it doesn't work? Lea Lacroix (WMDE) (talk) 11:00, 30 January 2017 (UTC)

@Lea Lacroix (WMDE): Yes, it works when I purge, but isn't this intended to work without a purge? -- Innocent bystander (talk) 11:58, 30 January 2017 (UTC)

The gadget was removed as obsolete by Pasleim, so now the sorting is done directly by the software, isn't it? If the item was cached before this change, purging the cache is necessary. Matěj Suchánek (talk) 13:30, 30 January 2017 (UTC)

I'm not completely sure how to shut down a gadget. Could it be that the gadget is still loaded if a user had it activated before I removed it from the list? --Pasleim (talk) 17:34, 30 January 2017 (UTC)

No, that should do. It might be, that the gadget still gets loaded from cache occasionally (although that should really only be a problem for logged out users). In rare cases it could also be that people load the gadget directly via their common.js. Cheers, Hoo man (talk) 09:22, 31 January 2017 (UTC)