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.