Wikidata:Property proposal/is solution to

From Wikidata
Jump to navigation Jump to search

solution to

[edit]

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 polynomial (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 tocylindrical coordinate system (Q211851)
Example 4Legendre polynomial (Q215405)"solution to"Legendre differential equation (Q98553711)
See also

Motivation: Why it is important

[edit]

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 inadequate

[edit]

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)[reply]

Discussion

[edit]
The-erinaceous-one (talk) 21:12, 24 August 2020 (UTC)[reply]

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

  • 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)[reply]
  • 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. ChristianKl17:27, 24 September 2020 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]
      • @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)[reply]

@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)[reply]

  •  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)[reply]
    • @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 polynomial (Q619511)"solution to"Chebyshev equation (Q3890369)
The Erinaceous One 🦔 09:37, 31 December 2020 (UTC)[reply]