Property talk:P4934

Documentation

• Start a query
• Current uses
• Statistics by class
• List of values
• List of qualifiers
• Count

calculated from
value of the subject item cannot be measured directly or can be calculated from the following measurands or attributes

Represents	calculation (Q622821)
Data type	Item
Domain	biomedical measurand type (Q42014143), medical attribute (Q44476427), measure (Q192276), network address (Q4418000), parameter (Q1413083), mathematical object (Q246672), individual quantity (Q71550118) or physical constant (Q173227)
Example	body mass index (Q131191) → human body weight (Q620876) human height (Q476112) mean corpuscular volume (Q1358504) → hematocrit (Q111146) red blood cell count (Q48632255) FEV1/FVC ratio (Q1988796) → forced expiratory volume in 1 second (Q1309034) forced vital capacity (Q50300573) age at death (Q50379085) → date of birth (Q2389905) date of death (Q18748141) f-number (Q862169) → focal length (Q193540) diameter of the entrance pupil (Q63572027)
Tracking: usage	Category:Pages using Wikidata property P4934 (Q106836005)
Lists	Items with the most statements of this property Count of items by number of statements (chart) Items with the most statements Items with the fewest statements Count of items by number of sitelinks (chart) Items with the most sitelinks Items with the most sitelinks, but no link to one Wikipedia (sample: Welsh Wikipedia, cywiki) Items with the fewest sitelinks Most linked wikis Items with the most identifier properties By value of property Most statements Fewest statements Most sitelinks Most linked wikis Total of sitelinks on items Most identifiers Fewest identifiers Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Chart by item creation date Database reports/Constraint violations/P4934 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 6,961 Main statement 569 8.2% of uses Qualifier 6,373 91.6% of uses Reference 19 0.3% of uses
Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Type “biomedical measurand type (Q42014143), medical attribute (Q44476427), measure (Q192276), network address (Q4418000), parameter (Q1413083), mathematical object (Q246672), individual quantity (Q71550118), physical constant (Q173227)”: item must contain property “instance of (P31), subclass of (P279)” with classes “biomedical measurand type (Q42014143), medical attribute (Q44476427), measure (Q192276), network address (Q4418000), parameter (Q1413083), mathematical object (Q246672), individual quantity (Q71550118), physical constant (Q173227)” or their subclasses (defined using subclass of (P279)). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P4934#Type Q42014143, Q44476427, Q192276, Q4418000, Q1413083, Q246672, Q71550118, Q173227, SPARQL

Value type “biomedical measurand type (Q42014143), medical attribute (Q44476427), measure (Q192276), network address (Q4418000), parameter (Q1413083), mathematical object (Q246672), measurand (Q1924249), individual quantity (Q71550118), address space (Q367204), quantity (Q309314), calendar date (Q205892)”: This property should use items as value that contain property “instance of (P31), subclass of (P279)”. On these, the value for instance of (P31), subclass of (P279) should be an item that uses subclass of (P279) with value biomedical measurand type (Q42014143), medical attribute (Q44476427), measure (Q192276), network address (Q4418000), parameter (Q1413083), mathematical object (Q246672), measurand (Q1924249), individual quantity (Q71550118), address space (Q367204), quantity (Q309314), calendar date (Q205892) (or a subclass thereof). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: subnetwork (Q11414)
List of violations of this constraint: Database reports/Constraint violations/P4934#Value type Q42014143, Q44476427, Q192276, Q4418000, Q1413083, Q246672, Q1924249, Q71550118, Q367204, Q309314, Q205892, SPARQL

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P4934#Entity types

Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P4934#Scope, SPARQL

Qualifiers “in defining formula (P7235), object has role (P3831)”: this property should be used only with the listed qualifiers. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P4934#allowed qualifiers, SPARQL

This property is being used by: sv:Mall:Faktamall enhet eu:Txantiloi:Unitate infotaula Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Reason for "as main value" scope constraint?

I can't find a discussion of the constraint here or in the proposal. Why is it needed? What is wrong with, e.g., this use? Swpb (talk) 15:51, 14 December 2018 (UTC)

Waited two weeks for an answer; boldly removed constraint pending one. Swpb (talk) 16:14, 28 December 2018 (UTC)

use with formulas?

f-number (Q862169) has a defining formula at Q862169#P2534.

To indicate what it is being used in that formula, this property seems useful: Q862169#P4934. I think it would be worth to update the description slightly to match that. Also, a qualifier to show which variable of the formula it refers to. In this version, I used a sandbox qualifier for that. Maybe we should create one. --- Jura 09:58, 8 May 2019 (UTC)

Add mathematical object (Q246672) to constraints

When I added the following statement, characteristic polynomial (Q849705)calculated from (P4934)square matrix (Q2739329), I got a constraint violation because matrices are not listed in the type constraints for calculated from (P4934). I would expect, however, that just about any subclass or instance of mathematical object (Q246672) could appear as a subject for calculated from (P4934). Are there any objections to adding mathematical object (Q246672) to the constraints? The-erinaceous-one (talk) 08:56, 14 August 2020 (UTC)

• There seems to be no objections, so I made the change. The-erinaceous-one (talk) 04:40, 31 August 2020 (UTC)

Widening the scope of this property

There is a proposal being discussed here to widen the scope of "calculated from" to "other items in defining formula". This would cover its current use, plus cases where the symbol of the item being defined does not simply appear on the left-hand-side of the defining formula. Toni 001 (talk) 09:12, 4 September 2020 (UTC)

As a first step, I've added a calculated from (P4934)property constraint (P2302)item-requires-statement constraint (Q21503247)property (P2306)defining formula (P2534). There are around 50 constraint violations [1]. The-erinaceous-one (talk) 22:21, 4 September 2020 (UTC)

I changed the label and description. Additionally, to resolve constraint violations that appeared when I added calculated from (P4934)property constraint (P2302)item-requires-statement constraint (Q21503247)property (P2306)defining formula (P2534), I also added property scope constraint (Q53869507), allowed-entity-types constraint (Q52004125), and required qualifier constraint (Q21510856) constraints. Please take look at them to see if you have any objections. The-erinaceous-one (talk) 23:37, 4 September 2020 (UTC)

Can you change the label to something that doesn't require people to add a defining formula? --- Jura 02:49, 5 September 2020 (UTC)

@Jura1: I thought there was a consensus in the other discussion to use "other items in defining formula." What would you suggest as an alternative? We could use "other items used to define or calculate" but that is cumbersome. Are there use cases where the defining formula doesn't make sense? A defining forumla statement is only missing on 53/1050 items that use P4934 (and it looks like defining formula would fit on many of those). The-erinaceous-one (talk) 04:20, 5 September 2020 (UTC)

Adding a requirement for a defining formula isn't widening its scope.

Maybe "calculated from/defined in terms of". --- Jura 04:23, 5 September 2020 (UTC)

@Jura1: In the other discussion, variants of the new name, "other items in defining formula," were stated several times, but we can continue discussing it here. Are there specific cases use cases for P4934 where the defining formula does not work that you are concerned about? Looking through the constraint violations, mentioned above, most the items I looked at have a clear defining formulas that could be added and simply haven't been. The only exceptions are the IP address items, where I just don't know enough about the subject to know if the "calculated from" values can be put into an defining equation. @Toni 001, Okkn: you might also want to weigh in on this discussion. The-erinaceous-one (talk) 06:40, 5 September 2020 (UTC)

By adding defining formalea where applicable and omitting duplicates, we find that the number of constraint violations is down to 13 out of 499 items that have P4934 statements [2]. Of the remaining constraint violations, there is one, ground track (Q218124), that would be difficult to add a defining formula, one that should probably be merged exposure time (Q815600), and the rest I am not qualified to evaluate but presumably they have some formula. Overall, we see that P4934 is used as "other items in defining formula" rather than (the slightly more broad) "Calulated from/defined by." In other words, changing the label to "other items in defining formula" might be somewhat different than the original intent of P4934, but it more accurately reflects how the property is used in practice. The-erinaceous-one (talk) 08:33, 5 September 2020 (UTC)

Maybe we can still come up with a better label.

Personally, I think we should avoid "other" and "item" in labels.

To note whether or not it's included in the defining formula, there is already in defining formula (P7235).--- Jura 09:24, 5 September 2020 (UTC)

@Jura1: I think you misunderstand in defining formula (P7235): It indicates the symbol which represents an item in the formula: Either as main value, linking the main item to the symbol, or as qualifier, linking the corresponding P4934-value to the symbol. See for instance magnetic flux density (Q30204). Toni 001 (talk) 09:54, 5 September 2020 (UTC)

I'm the one who first proposed it? --- Jura 07:48, 9 September 2020 (UTC)

@Jura1: I agree with you that the label "other items in defining formula" is not as aestetically pleasing as "calculated from," and it's a bit weird to have "other items" in the label, but it is (1) clear what it means, (2) clear how to use it, and (3) clearly shows that P4934 is related to the defining formula. With the current label, then P4934 shouldn't be used for items that are not calculated from the others. Additionally, with "calculated from/defined by," it is clearly a mashup of two distinct concepts and doesn't quite cover all cases. For example, we might have Pythagorean theorem"P4934"$a^{2}+b^{2}=c^{2}$. The Pythagorean theorem, itself, is not "calculated from" from the sides of the triangle, nor is it "defined by" their lengths, instead it gives a relation between them. Then we would need to use the label "calculated from/defined by/gives relation on." Perhaps we could use the label "has mathematically related values," but that is clunky and will definitely be abused as people use it as "see also." The-erinaceous-one (talk) 20:49, 5 September 2020 (UTC)

I think we should still try to come up with a label that actually widens the scope. --- Jura 07:48, 9 September 2020 (UTC)

@Jura1: Can you justify your objections to connecting this property to the defining formula? It's already used that way in practice. The-erinaceous-one (talk) 21:11, 9 September 2020 (UTC)

@Jura1: Please respond to the discussion. We had three editors who agreed with the proposed change and I would like to move it along. The-erinaceous-one (talk) 07:26, 16 September 2020 (UTC)

I don't think we have any other properties with "other" in the label, even items shouldn't be using that (unless it's part of a title). I don't recall three contributors suggesting we should start with that.

If we require a defining formula, the use on Q453582#P4934 seems suboptimal if not ill understood.

Personally, I think it could be sufficient to add "defined in terms of" as an alias.

Maybe we could compromise by changing "from" to "with". --- Jura 12:23, 19 September 2020 (UTC)

Jura1, replacing "with" with "from" is a little better, but I don't think "calculated with" is sufficient for a lot of uses in mathematics because there are particular objects that will never--and can never--be calculated. I like Toni 001's suggestion below.

Q453582 is a poor example of how P4934 is or should be used, even under the current modeling. It has multiple constraint violations that need to be addressed, and the meaning of its "calculated from" statements are unclear. — The Erinaceous One 🦔 07:26, 21 September 2020 (UTC)

@The-erinaceous-one: We could revive your original property proposal, potentially under the name "other items in defining formula" (though, I do like the original name, too). Then we would have this well-defined set of three properties, "defining formula", "other items in defining formula" and "in defining formula". We could move all statements which fit exactly and leave "calculated from" for those few remaining cases which don't fit. Toni 001 (talk) 12:14, 19 September 2020 (UTC)

@Toni 001: I agree with your proposal in theory, but I'm a concerned about the logisitics. Is there a easy way to change the properties on hundreds of items without doing it manually? Are the places where P4934 is used that would need to be updated? It would be easier to change P4934 to "other items in defining formula" and make a new property for the handful of items that don't have a defining formula (Jura1, I would like to hear your thoughts on this too).

— The Erinaceous One 🦔 07:26, 21 September 2020 (UTC)

As general principle, we don't want to re-purpose IDs. From the property proposal it is not clear whether "calculated from" is supposed to mean "having a defining formula". Given current use, we could make the definition more precise and strict in that sense and eliminate the very few exceptions to that stricter definition. However, if there is opposition, we are only left with proposing a new, well-defined property. While moving about 1000 statements might seem daunting, I think that, in the long run, it is better to have well-defined/scoped properties over broad, catch-all ones. (If we agree to create a new property, I'll volunteer to move physical quantity related definitions - about half of all current uses). Toni 001 (talk) 06:19, 29 September 2020 (UTC)

Has part (P527)

Has part (P527) needs to be used in order for Wikipedia special formula page to work, See for example: https://en.wikipedia.org/w/index.php?title=Special:MathWikibase&qid=Q2945123  – The preceding unsigned comment was added by ? (talk • contribs).

No. Special:MathWikibase should be fixed instead. We discussed this the other day.
Please learn to use ~~~~ to sign your comments on this wiki --- Jura 11:23, 2 December 2020 (UTC)

@jura1: Could you please point me to that discussion? As far as I know, there is no problem with using P527 in Special:MathWikibase. Andreg-p (talk) 11:47, 2 December 2020 (UTC)

It was on project chat.

Wikidata has problems with math datatype (used in the formula displayed there). We still can't access its data on query server and fixing it keeps getting delayed. Possibly due to disclosed (or undisclosed) security risks associated with it, when it's not entirely blocked from use. The result is that eventually we will have to come up with an alternative solution for the formula itself. --- Jura 11:58, 2 December 2020 (UTC)

@jura1:: Neither @Andreg-p: as the developer of the nor me as the maintainer of mw:Extension Math are aware of any issues. Can you please provide links to support your claims? Thank you Physikerwelt (talk) 12:17, 2 December 2020 (UTC)

It's possible that you aren't involved in fixing them. Léa announced the security risks on the weekly mailing lists some time ago and announced a full disclosure for later. I don't recall that happening though. I trust you are aware that it was impossible to add statements some time ago and that we can't retrieve the the entered string from Query Server? --- Jura 12:21, 2 December 2020 (UTC)

@Andreg-p: I feel that "has part" is not the best way to model quantities (or other objects) appearing in a formula: Is length or time really a "part of" acceleration? I rather see it as some left-over from the early days when no better model was available. The "better" model now is used for instance here: see how in defining formula (P7235) is used both as main value and as qualifier on calculated from (P4934) statements. But see also the discussion above how "calculated from" is not ideal. Toni 001 (talk) 12:22, 2 December 2020 (UTC)

@Toni 001: to me it sounds that "has part" is pretty mature and viewing the discussion above "calculated from" does not seem to be a property that is mature enough to be used on production wikis. Thus I would advise not to change the source code of the extension. Moreover, I think for application developers that do not focus on mathematics alone is easier to use. For instance, the first relation described in the examples (body mass index (Q131191) → human body weight (Q620876), human height (Q476112)) is only accessible to programmers who are aware that calculated from is a special case of has-part.

Template:Ping:Jura1 I honestly don't know what you are referring to? phab:T195765? phab:T266496?

Overall: Last year, we have established a new model for the future of the Math support in Wikimedia project. meta:Wikimedia_Community_User_Group_Math decides on the future of the implementation and the Wikimedia Foundation provides free code-review for the community contributed patches. Currently, there is only one patch ready to review https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/638094. That being said. If you intend to change something in the software, you

1. First need to find consensus within the community group
2. Implement the change in the software as a proposal
3. Improve the proposal until all concerns w.r.t, stability, performance, and security are satisfied
4. wait for the next deployment

This sounds more complicated than it actually is. --Physikerwelt (talk) 14:14, 2 December 2020 (UTC)

Hello @Physikerwelt: Let me add one more data point to the discussion: Of the items which have a formula, about 560 use calculated from (P4934) and about 150 use has part(s) (P527). Toni 001 (talk) 10:10, 3 December 2020 (UTC)

I think the Math community group is free to do what they want on the Meta project. Wikibase can be used independently of Wikidata.

Wikidata community just curates one such installation on this wiki. --- Jura 10:14, 3 December 2020 (UTC)

@Toni 001:thank you for this enlightening list. I manually looked at the first 200 entries, and just one did not make sense to me https://www.wikidata.org/wiki/Q1195250 the rest was quite reasonable. On the other hand, there are has part concepts that could also be transformed to calculated from such as https://www.wikidata.org/wiki/Q2111. While from an implementation point of view, it is not different if we use "has part" or "calculated from", we need to agree on one or ask @Andreg-p: if he can extend the software to accept a list of properties rather than just one property. However, as a developer, I can not really see the point of having more properties that do the same thing.

@Jura1: The important thing, is that Wikidata is the instance that is used by many people and machines, and mistakes in the data model make the use of that data more feasible. For example, the current implementation of the popup/special page was more difficult than it has to be. It uses three properties. To me, the use of P416 seems unnecessary as one could always use P2534 to model the identifier currently often modeled as P7973.--Physikerwelt (talk) 18:11, 3 December 2020 (UTC)

You are free to make whatever use you want of Wikidata. It's its main purpose. Some users found it easier with their own Wikibase installation. I can understand that you may want to use P527 there. Just regretable that you made all this development without any participation from the Wikidata community. The math datatype is really a burden for Wikidata, as the Wikibase development team doesn't support it and it still has the same issue preventing efficient use people noticed years ago. --- Jura 16:53, 6 December 2020 (UTC)

We can not change the past phab:T67397 but the future. You are invited to join the math community on Wikidata or meta or share your thoguts with us in the future. --Physikerwelt (talk) 09:37, 7 December 2020 (UTC)

Hello @Physikerwelt: I assumes you meant "mistakes in the data model make its use less feasible", right? Could you please clarify your sentence after that one? Which property is unnecessary? I only see that quantity symbol (string) (P416) can be eliminated in favor of quantity symbol (LaTeX) (P7973), which I have already proposed when the latter one was created. Toni 001 (talk) 11:28, 8 December 2020 (UTC)

@Toni 001: Thank you. You are right I mean less feasible". I would have proposed to replace quantity symbol (string) (P416) with defining formula (P2534). That way only two properties would be needed to develop applications. Reducing the number of properties is especially desirable, for federated queries as the field mapping becomes less tedious. I have to admit that the current English label for quantity symbol (LaTeX) (P7973) is in many cases more appealing than the label for defining formula (P2534). However the symbol might also be a more complex expression that would require additional meta-characters. For example, the signal $f(x)$ in the FT ${\textstyle {\hat {f}}(\omega )={\frac {1}{\sqrt {2\pi }}}\int \limits _{-\infty }^{+\infty }f(x)e^{-ix\omega }\,dx}$ is not an atomic symbol, but rather a function where $x$ is somehow more a meta character than $f$. For software running in production on Wikipedia, every change is a huge effort, as it has to go through code review. Thus implementing logic that either uses one or the other property depending on the data available, seems hardly possible. Therefore I would advocate reducing the number of properties used to the smallest possible number. Maybe widening the scope of defining formula (P2534) is an option. In addition meta-information on the semantics can be added via other properties. For example, the fact that entropy (Q45003) is a scalar quantity might be used for the interpretation as opposed to the fact that mass–energy equivalence (Q35875) is a physical law. I think Fibonacci sequence (Q23835349) uses this kind of generic interpretation and differentiation between definitions of different types. --Physikerwelt (talk) 10:14, 9 December 2020 (UTC)

@Physikerwelt: I don't see how quantity symbol (be it quantity symbol (string) (P416) or quantity symbol (LaTeX) (P7973)) could be replaced by defining formula (P2534). Those are different concepts:

• For instance, there are three symbols which are typically used to refer to the quantity Young's modulus (Q2091584) in formulas.
• Then there is a formula which defines this quantity; one needs to state which symbol is used in the formula for the main item; and finally one lists other items used in the formula.

In summary: one needs 1 property to list all possible symbols used for a quantity and three properties for the formula and its "explanation". Toni 001 (talk) 13:56, 9 December 2020 (UTC)

@Toni 001: You focus on the special case where the definiendum in defining formula (P7235) is a substring of the definition defining formula (P2534). This is one particular subclass, but it does not cover for example mathematical theorems and relations. See https://wikidata.beta.wmflabs.org/wiki/Q574284 for an example how YM can be done without extra properties. --Physikerwelt (talk) 16:21, 9 January 2021 (UTC)

Hello @Physikerwelt: There are indeed two cases, which might not be clear from the current English label of P2534 ("defining formula"). The German label "Formel" simply means formula, not implying that the item on which the formula appear is being defined. However, this aspect seems irrelevant: Per item, there is one formula, and that formula contains symbols. Why do you think it would be good to use the same property for both formula and for symbol? Hypothetically, if we used a single property for both, what would be a label and a description which makes its intended use clear? Toni 001 (talk) 10:46, 11 January 2021 (UTC)

Here is a proposal for a property to unify the way formula variables are described: https://www.wikidata.org/wiki/Wikidata:Property_proposal/symbol_represents Toni 001 (talk) 07:44, 19 April 2021 (UTC)