Wikidata:Property proposal/is solution to

solution toEdit

Originally proposed at Wikidata:Property proposal/Natural science

   Done: solution to (P9030) (Talk and documentation)
Descriptiona mathematical object that satisfies the creteria for a mathematical problem
Data typeItem
Domainmathematical problem (Q1166625)
Allowed valuesmathematical object (Q246672)
Example 1Chebyshev polynomials (Q619511) "solution to" Chebyshev equation (Q3890369)
Example 2eigenvalue (Q21406831) "solution to" characteristic equation (Q33104580)
Example 3cylindrical harmonics (Q5199282) "solution to" Laplace's equation (Q339444) / with respect to cylindrical coordinate system (Q211851)
Example 4Legendre polynomials (Q215405) "solution to" Legendre's differential equation (Q98553711)
See also

Motivation: Why it is importantEdit

Many mathematical problems have solutions that are, themselves, well-known items classified in Wikidata. Therefore, it would be useful to create a pair of properties to model the relationship between a problem and its solution(s). I propose we name the property for problems as "has solution" with the inverse property for solutions as either "is a solution to" or merely "solution to."

Why the current models are inadequateEdit

It might be thought that this property is already modeled by the computes solution to (P2159) and solved by (P1136) property, but, while there is a semantic simularity, the meaning of those properties is distinct from what we plan to model with the proposed property. The computes solution to (P2159) property indicates a method that can be used to find a solution to a particular problem---not what the actual value of the solution is. Additionally, the solved by (P1136) property is used to state who found a solution, not what the solution is. In both cases, using the existing properties to state a solution to a problem results in a constraint violation, i.e. "solution" computes solution to (P2159) "problem" results in a constraint violation.

It's worth noting that one way that the "is a solution to" relationship has been modeled is by using eigenvalue (Q21406831) instance of (P31) solution (Q1879813) / of (P642) characteristic equation (Q33104580), but this is pretty clunky, hides an important relationship in a qualifier, and doesn't allow for cases when qualifiers are necessary, such as in Example 3, above.

The-erinaceous-one (talk) 08:30, 22 August 2020 (UTC)


  •   Comment maybe @TomT0m: who proposed computes solution to (P2159) wants to comment. If both are created, I think the description of P2159 needs to make the difference much more explicit. --- Jura 08:45, 22 August 2020 (UTC)
  •   Comment This may be useful - however, I would strongly recommend only having one property, not two; there's no need for an inverse as there are easy methods within Wikidata to generate computed inverses. ArthurPSmith (talk) 17:42, 24 August 2020 (UTC)
The-erinaceous-one (talk) 21:12, 24 August 2020 (UTC)
  •   Comment Any thoughts on whether the property name "is solution to" or merely "solution to" is preferable? The-erinaceous-one (talk) 21:14, 24 August 2020 (UTC)
  •   Support We need more properties describing mathematical objects, but   Oppose the creation of the "has solution" inverse property. --Haansn08 (talk) 05:14, 25 August 2020 (UTC)
  •   Support I've marked the proposal as ready, because there seems to be no more discussion. We've come to a consensus to create a property "is solution to" but not an inverse property. The-erinaceous-one (talk) 09:36, 4 September 2020 (UTC)

@Jura1: Would you be able create this property? — The Erinaceous One 🦔 09:06, 22 September 2020 (UTC)

  • I don't see that there's a consenus about whether "is solution to" or "solution to" is a better way to model the relationship. I haven't even seen arguments for preferring either. ChristianKl❫ 13:59, 22 September 2020 (UTC)
  • ChristianKl, the choice between "is solution to" and "solution to" is purely semantic and doesn't reflect an actual difference in modeling. To answer my question above, I think we should use "solution to" in order to be consistent with the labeling of most Wikidata properties (we say "instance of" not "is instance of", etc.) — The Erinaceous One 🦔 20:05, 22 September 2020 (UTC)
  • Finding the best semantics in English is part of the property proposal process. This allow then to have translations into other languages based on the chosen English one. When we find out that we want to rename a property it's otherwise often complicated because there's no automatic tickling down into other languages. That means it's worth to spend the effort to get the name right before creating the property. ChristianKl❫ 17:27, 24 September 2020 (UTC)
  • Fair enough. We're also discussing the label in the next thread, so let's just work it out there. — The Erinaceous One 🦔 05:16, 25 September 2020 (UTC)
  • I think "solves" (existing property) and "is solution to" (this proposal) should have labels that more clearly differentiate the two properties. --- Jura 14:45, 22 September 2020 (UTC)
  • Jura1, I agree. "solves" is ambiguous because we say both "solution x solves problem z" and "method y solves problem z." I've been trying to think of what to change it to, though. What do you think about "computes solution to"? — The Erinaceous One 🦔 20:05, 22 September 2020 (UTC)
    • I think both labels need to be updated: "to solve" and "be solution to" can easily end up being translated identically. If a short label can't be found, it can easily be an (almost) complete sentence for each (this is different to items where Help:Label applies). --- Jura 08:07, 24 September 2020 (UTC)
      • @Jura1: Do you have a proposed change to "is solution to"? As it is, it already forms a complete sentence when you add in the subject and object. The ambiguity can be removed by changing "solves" to "computes solution to" because "is" and "computes" are not likely to be confused, even in translations. We'll also have constraints that enforce the proper usage. — The Erinaceous One 🦔 12:00, 24 September 2020 (UTC)
  • Are we at Wikidata the first to model this relationship in structured data or are there other projects beside us that model this in structured data? Does WolframAlpha have something similar? ChristianKl❫ 17:27, 24 September 2020 (UTC)

@ChristianKl, Jura1: Looking at all the other properties on the Mathematics Project, none of them include "is" at the beginning of the label. And, since nobody has else has advocated for the proposed property to break that convention we should make the label simply, "solution to." Since this was the only thing blocking the proposed property from being created, I've changed the proposal to "ready" again. I've also put a comment on the P2159's talk page to proposing a change to P2159's label. — The Erinaceous One 🦔 10:23, 30 December 2020 (UTC)

  •   Comment I don't mind having both properties, but I think it would be useful if one could determine the scope and difference between the two properties from their labels and this without a degree in Mathematics. Contrary to item labels, property labels are meant to be unique. --- Jura 11:01, 30 December 2020 (UTC)
    • @Jura1: The scope and differences are well defined. P2159 is used on a method or algorithm that calculates a solution to a problem whereas the proposed property will be used on a mathematical object that is the solution. Just to clarify, here is a table:
Caption text
Property Proposed Label Example statement
computes solution to (P2159) computes solution to Broyden–Fletcher–Goldfarb–Shanno algorithm (Q2877013) "computes solution to" optimization problem (Q984063)
proposed property solution to Chebyshev polynomials (Q619511) "solution to" Chebyshev equation (Q3890369)
The Erinaceous One 🦔 09:37, 31 December 2020 (UTC)