I guess number of instances works in more cases, for example the number of iphone ever built could work ... actually if I look at the ''Population'' article in frwiki, I get "Une *population* est un ensemble d'individus ou d'éléments partageant une ou plusieurs caractéristiques qui servent à les regrouper." (a population is a set of individuals or elements sharing one or several characters that allows to regroup them", this seems another word for "class" :) So I guess it's just a matter of vocabulary.
I guess the population of earth is the number of instances of the "human on earth" class :) On the other hand, human population is kind of a natural property for a country, its number of wolfes for example may not be worth having a property. Having an item "French Wolf" with a property "number of instances" is way more convenient and generic, and could avoid the burden of having to create (potentially a big number of) properties for each kind of animals we might want to store population in some places. 2015-04-29 21:19 GMT+02:00 Markus Krötzsch <mar...@semantic-mediawiki.org>: > Ok, sounds reasonable. > > In all of these cases I do wonder though why we need to store the number > at all. We can just count the instances, can we not? Queries allow for this > (and will be an official feature in due course). > > And in cases where not all instances are supposed to be on Wikidata, there > are usually better ways to store the number, e.g., "population of Earth" is > better than "number of instances of living person" (besides the fact that > we don't have "living person"). > > Regards, > > Markus > > On 29.04.2015 20:29, Thomas Douillard wrote: > >> Actually, like it is, there is no /number of planets/ property, there is >> a class of planet (solar system planet) together with a /number of >> instances/ property. This might save us : we can have two item : >> * solar system planet (old style definition) and >> * solar system planet (new style definition) >> This might just put the problem in another place though :) although >> this might not change the correctness of statements like /<solar >> system/> <has part> </solar system planet/ (old style)> :) >> >> >> Pluto can still be an old style definition planet, and maybe <solar >> system planet> >> is a subclass of </solar system planet/ (old style)> >> >> Thinking about it, classes are naturally a good way to deal with >> definitions. >> >> 2015-04-29 19:35 GMT+02:00 Markus Krötzsch >> <mar...@semantic-mediawiki.org <mailto:mar...@semantic-mediawiki.org>>: >> >> >> Hi, >> >> General case first: Many statements depend on time and have an end >> date (e.g., population numbers). The general approach there is to >> (1) have a qualifier that clarifies the restricted temporal validity >> and (2) make the current statement "preferred". So your idea with >> the ranks was a good starting point, but it should be "normal" and >> "preferred" instead of "deprecated" and "normal". And infovarius was >> also right in this sense to use a temporal quantifier. Note that >> more than one statement can be preferred if more than one is current >> (this could be relevant, e.g., for the classes that Pluto is/was an >> instance of). >> >> >> However, this answer is only about the general pattern of dealing >> with things that changed over time, and the intended use of ranks in >> this case. Things might be different here. It's a special case in >> that it was not so much the world that changed but the definition, >> so the real question is what our property "number of planets" really >> means: >> >> (1) "Number of planets at a given time (given as a qualifier), based >> on the definition of planet adopted at this time" >> (2) "Number of planets according to the definition that was used >> when the property was introduced" >> (3) "Number of planets according to the definition that is current >> right now" >> >> (3) is problematic since it means that the meaning of the property >> would change over time, and statements that were true will become >> false. I would strongly discourage this. But both (1) and (2) are >> possible. If one wants to use (1) then *every* statement with this >> property must have some time qualifier -- otherwise it will not make >> any sense since one would not know which definition is meant. >> >> In case (2), the number of planets of our solar system is 8, and >> nothing else. It has never been 9 *according to the definition of >> planet used by this property*. So if this interpretation is adopted, >> then the statement with value 9 should really at best be there in a >> deprecated form, not in a temporal form. It could make sense to keep >> a deprecated form to warn other users that this should not be >> reintroduced. >> >> One could also add more options, e.g., one could have a qualifier >> that specifies the definition of planet that is used. This would be >> a bit like (1) but instead of time one would now always need to >> specify a definition, and the statements would not be temporal at >> all (the number would always remain 9 according to the old >> definition). One could still use "preferred" to mark the statement >> that is based on the most common definition. >> >> The world is beautifully complicated, isn't it? I'll leave it to you >> experts to discuss what makes sense here here :-) >> >> Best regards, >> >> Markus >> >> >> On 29.04.2015 18:05, Thomas Douillard wrote: >> >> Hi, a small question about qualifiers and ranks. >> >> It is well known that the number of planets changed in 2006. Or >> did it ? >> Of course, Pluto is still here, it's just its status that >> changed. The >> definition of planets changed in 2006. >> >> This imply that (imho), the statement "the number of planets in >> the >> solar system in 9" should be deprecated. But infovarius did not >> agree >> with me and changed the rank of the claim back to normal and put >> an end >> date. I still think it should be deprecated, but it raise me a >> question: >> How are we supposed (if we are) to express an information about a >> deprecation ? Should we include something about the deprecation >> in the >> sources ? Should we have a qualifier ''deprecation date'' ? >> >> https://www.wikidata.org/wiki/Q17362350 >> >> >> _______________________________________________ >> Wikidata-l mailing list >> Wikidata-l@lists.wikimedia.org >> <mailto:Wikidata-l@lists.wikimedia.org> >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l >> >> >> >> _______________________________________________ >> Wikidata-l mailing list >> Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org >> > >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l >> >> >> >> >> _______________________________________________ >> Wikidata-l mailing list >> Wikidata-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikidata-l >> >> > > _______________________________________________ > Wikidata-l mailing list > Wikidata-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata-l >
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
