-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all!
Sorry for my ignorance, if this is common knowledge: What about lists? I know they are not very popular (or completely unsupported) but my bot maintains several list like player rankings, currency exchange rates or similar for infoboxes, see e.g. [1]-[7]. The bot uses external sources (e.g. an URL) an retrieves data (e.g. a list of player rankings) and syncronizes/updates the data in the wiki.
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. Furthermore would it cause a huge effort setting up the configuration for the bot since we would have to connect every (of the 1000+ players) with the data from the external list needing an own bot configuration. In case somethings changes on the external site we would have to update all those configurations.
As I see an item containing a list would be possible. But at the moment every list entry or item would need a new property to be created and filled with one or more claims. While this would be technical feasible it seams strange to create thousands of properties just for one single usage in one item.
On the other hand it it would be possible to have claims/statements that contain not only a value but a key-value pair, then somthing like sketched in [8] (p32) could be easily done with a simple configuration on the according talk page.
So I hope we can find a solution here, since this would help to have the most recent data on wikidata with minimal effort.
Thanks and greetings DrTrigon
[1] http://de.wikipedia.org/wiki/Vorlage:Elo-Punkte [2] http://de.wikipedia.org/wiki/Vorlage:Wechselkursdaten/EZB [3] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenDE [4] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenAT [5] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenCH [6] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenDE/Quelle [7] http://de.wikipedia.org/wiki/Vorlage:ITTF-Weltranglistendaten (there are examples on enwiki and others too...)
[8] http://wikidata-test-repo.wikimedia.de/wiki/Q356
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The links read of course:
[1] http://de.wikipedia.org/wiki/Vorlage:Elo-Punkte [2] http://de.wikipedia.org/wiki/Vorlage:Wechselkursdaten/EZB [3] http://de.wikipedia.org/wiki/Vorlage:Infobox_Kreditinstitut/DatenDE [4] http://de.wikipedia.org/wiki/Vorlage:Infobox_Kreditinstitut/DatenAT [5] http://de.wikipedia.org/wiki/Vorlage:Infobox_Kreditinstitut/DatenCH [6] http://de.wikipedia.org/wiki/Vorlage:Infobox_Kreditinstitut/DatenDE/Quelle [7] http://de.wikipedia.org/wiki/Vorlage:ITTF-Weltranglistendaten (there are examples on enwiki and others too...)
[8] http://wikidata-test-repo.wikimedia.de/wiki/Q356
(sorry for that)
On 31.12.2012 14:51, Dr. Trigon wrote:
Hello all!
Sorry for my ignorance, if this is common knowledge: What about lists? I know they are not very popular (or completely unsupported) but my bot maintains several list like player rankings, currency exchange rates or similar for infoboxes, see e.g. [1]-[7]. The bot uses external sources (e.g. an URL) an retrieves data (e.g. a list of player rankings) and syncronizes/updates the data in the wiki.
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. Furthermore would it cause a huge effort setting up the configuration for the bot since we would have to connect every (of the 1000+ players) with the data from the external list needing an own bot configuration. In case somethings changes on the external site we would have to update all those configurations.
As I see an item containing a list would be possible. But at the moment every list entry or item would need a new property to be created and filled with one or more claims. While this would be technical feasible it seams strange to create thousands of properties just for one single usage in one item.
On the other hand it it would be possible to have claims/statements that contain not only a value but a key-value pair, then somthing like sketched in [8] (p32) could be easily done with a simple configuration on the according talk page.
So I hope we can find a solution here, since this would help to have the most recent data on wikidata with minimal effort.
Thanks and greetings DrTrigon
[1] http://de.wikipedia.org/wiki/Vorlage:Elo-Punkte [2] http://de.wikipedia.org/wiki/Vorlage:Wechselkursdaten/EZB [3] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenDE [4] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenAT [5] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenCH [6] http://de.wikipedia.org/wiki/Vorlage:Infobox Kreditinstitut/DatenDE/Quelle [7] http://de.wikipedia.org/wiki/Vorlage:ITTF-Weltranglistendaten (there are examples on enwiki and others too...)
[8] http://wikidata-test-repo.wikimedia.de/wiki/Q356
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
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.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
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
-----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