-----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-----