On 31.12.2012 22:19, Jeroen De Dauw wrote: > Hey, > > Now as I can see the idea would be to have an item for each player and > then a property "ranking" containing the value. But that would mean we > have to split up data given in a list and spread it over thousands of > items (update all of them) in order to use a query to re-collect them > into a list and deliver it to the infobox as before. > > In case of player rankings, this does not seem that horrible to me. Having the > info set as regular claims for regular items makes the info available for the > items themselves and allows doing any other type of query the system supports > against it, as opposed to only having the info available in the specific > aggregation you have in mind. Alternatively you could have an item for "season > foo in sport bar" where you have multiple "player baz has score bah". Not sure > how we're actually supporting the later though, but it should be possible > IIRC.
That's an instance of the standard "actor X played role Y in movie Z": "player X achieved score Y in season Y". We support this using qualifiers. If there's an item about the season and a property called "played-in-season" or something, then there would be one claim for each player for that property, and each claim would have a qualifier that contains the score. I would, however, prefer to have it the other way around: give each player a property "achieved-score" or something, and add qualifiers that specifies the season and league. The season's overview can then be created from a query. This means that each player's item would have to be updated from an external source, but I don't see how this would fundamentally harder than updating a single data item (the season) from the external source. Sure, it will take a bit longer, but it also provides more flexibility, I think. And perhaps most importantly, it allows users to see the performance of a player in one glance. If the player's scores were only encoded in the season items, it would be a bit tricky to generate a player's performance history from that, and it would require one query for each player. -- daniel -- Daniel Kinzler, Softwarearchitekt Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l