Wikidata:Requests for comment/Derived properties
| An editor has requested the community to provide input on "Derived properties" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- stale --Pasleim (talk) 08:50, 20 August 2016 (UTC)
Properties that can be derived/calculated from other properties are often opposed in the Property proposal process, and are therefor not so often created. I am starting to feel like that is a bad idea. A calculated value does not always have the same precision as one that can be found in a source and we do not always know what value is the derived value and which is the measured fact.
One example: The source Småorter 1990 (Q20087097) tells me that Korsbacken (Q2791237) in 1990 had a population of 68 in an area of 5 hectare (Q35852) and a population-density of 1,278 km-2. A calculation would give 1360 km-2, but that is not what the source tells us. The difference here probably comes from the fact that the area is closer to 5.3 ha than 5.0 ha.
Second example: When there is a large demonstration (Q175331), we are often told the number of participants by the police. That number is normally not based on a head count. It is based on estimates of the density of the crowd multiplied with the area covered. Here the "population" is a derived number, while the "density" is a basic fact.
I can give you a number of properties in astronomy that also can be derived, but I prefer to not calculate them, since I think we loose information from the source when we do that. The minor planet Sedna have never been observed near its Apoapsis. That number is therefor based on calculations. That can be seen in the sources, since that number has a very poor precision. If we do not allow us to add such properties into our items, I think we loose information.
Discussions
[edit]I am not saying that we have to add a property about population density and other derived properties to every item we have. I rather say that should have the option to do that when we feel that information can be lost. -- Innocent bystander (talk) 07:15, 22 October 2015 (UTC)
- I'd say It's a question for WikiProject Reasoning when it will be up. I'd also say there is no special problem if it's clearly stated that it's a computation and the method is stated. The key issue would be how to model the sources of the raw datas in the statement, as there may be several sources in Wikidata with different numbers, hypothetically, and it may be ambiguous for a computation if we don't know which one to use. An alternative would be to just leave it unsourced. But as the dev team noticed in a thread on the subject, we can't anyway count on any kind of inferences done directly in Wikibase anytime soon, so any kind of inference or computation for other statement would actually be done by bot creating a statement, or in infoboxes or clients ... Anyway Markus will probably be happy if you add that kind of usecase for analysis on the Reasoning project :) author TomT0m / talk page 09:21, 22 October 2015 (UTC)
- I would add my
Weak support to having derived properties. In physics we have both half-life (P2114) and mean lifetime (P2645) which are related by a simple scale factor (ln(2)). However one is traditionally used for one type of system (nuclides) and the other used for others (elementary particles), so having both is helpful to enter exactly what source materials use and to provide what people are accustomed to. However, it seems to me it would be helpful to have some way to query/obtain one property value from the other if it has not been stated explicitly. Maybe that has to be done by external tools rather than anything internal to wikidata; I certainly don't see an obvious mechanism for this within wikidata's structure at the moment. ArthurPSmith (talk) 16:08, 18 April 2016 (UTC)