-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02.01.2013 14:24, Daniel Kinzler wrote:
> 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.
No it's not that horrible, but simply could become unmaintainable.
Take e.g. list like [1] or [2] wich are
1. very long 1000+ entries
2. multidimensional, in fact matrix instead of list meaning it has 1+
values per entry
My problems (better the bot's problems) are:
1. it would be too slow to be able to update the data daily as done now
2. the configuration scales with the number of entries which is simply
unmaintainable
I setup the bot now to use (cheap hack) "aliases" in order to link to
other items, like e.g. single players from a season list. But as
mentioned... it is slow as hell...
> 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.
Could you give me more info about how qualifies will work? Is there any
docu available?
> 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.
That sounds good. Would it also be possible to use e.g. player ids or
else (whatever given by the source)?
> 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.
As mentioned I treid something like this with aliases already. However
there HAS TO BE an api interface that is able to modify all those
properties (in this case from a lot of items) at once - else this will
not be performant!! Is some api like this up to come?
> 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.
I think it will take A LOT LONGER - but you are completly right is has
also some advantages but IF AND ONLY IF there will be a permformant api.
So I need help (!) here...
> 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.
That would be very nice... indeed!! :)
Thanks and greetings
DrTrigon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlDomwwACgkQAXWvBxzBrDDdKACgppK3WQNWSzCixYwCF1rANaN+
pwMAoN4D1102ixDI6PnUMDf3ppjcvWKe
=WwKq
-----END PGP SIGNATURE-----
_______________________________________________
Wikidata-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
