Use the `liquipedia` player property and the Liquipedia API to generate unique identifiers for players<->teams

[simonsan]

Ideally we use the liquipedia player property and the Liquipedia API to write a script that automatically generates this file.

Originally posted by @happyleavesaoc in #33 (comment)

Regarding: a small script that enumerates the players in the players.yaml and put in a unique ID in teams.json for referencing players

[happyleavesaoc]

I made some progress on this. I have a script that uses the Liquipedia API to get associated Teams for all players in the data. It also grabs some other metadata (twitch, etc) that can be used to enrich our data.

[happyleavesaoc]

Now the problem is synchronization. I wonder if github actions can be configured to do that for us ("serverless")

[simonsan]

Now the problem is synchronization. I wonder if github actions can be configured to do that for us ("serverless")

I'm quite comfortable with creating actions, but I would need to understand how you would think of it. Do you want to use that script within a cronjob in a gh-action that pulls in data e.g. hourly and updates the player profiles and teams?

Would the script be sufficient to also check PRs against these information?

[happyleavesaoc]

Yes, I think something like that would work. If I craft the script to take the players and teams yaml as input, and write changes to those same files, that should leave the checkout in a state ready for commit. Does that align with the github actions workflow?

[simonsan]

Yes, I think something like that would work. If I craft the script to take the players and teams yaml as input, and write changes to those same files, that should leave the checkout in a state ready for commit. Does that align with the github actions workflow?

Yes I think so, I would probably not push these changes directly to master though from within the action, but to another branch and creating and automatic Pull Request for reviewing and merging. So that it's only half-automatic somehow, in case something breaks.

[happyleavesaoc]

Agree.

What do you think about adding a team property to players.yaml and removing teams.json?

1. Eliminates need for lookup
2. Eliminates need to update two files if a player name changes
3. Eliminates need to read two files
4. Loss of team abbreviation (mitigate by maintaining team metadata only in teams.json?)
5. Player scan required to get team composition (vs opposite right now)

[simonsan]

Agree.

What do you think about adding a team property to players.yaml and removing teams.json?

1. Eliminates need for lookup

2. Eliminates need to update two files if a player name changes

3. Eliminates need to read two files

4. Loss of team abbreviation (mitigate by maintaining team metadata only in `teams.json`?)

5. Player scan required to get team composition (vs opposite right now)

I assume you mean to add a team property to each of those players, right?

Hmm, I'm not sure if I'm a big fan of it, honestly. I like this kind of normalisation between players and teams although it's a bit annoying to handle a kinda database in yaml-style.

I initially thought about adding unique IDs to teams.json and adding a field to the corresponding player in players.yaml or the other way around, to add a unique ID to each player and replace the player names in teams.json with it. For sure with the disadvantage of needing to process both.

Hmm, I'm quite unsure about this. Could you shortly give a code example in yaml how you would imagine it, to understand it better and the impact it would have.

I do see the point that it's quite annoying to have to files for a really small number of teams though.

[happyleavesaoc]

- name: TheViper
  team: GamerLegion
- name: DauT
  team: GamerLegion
- name: Vivi
  team: White Wolf Palace

team would only be updated via Liquipedia, which enforces uniqueness. It's effectively a key for our purposes and therefore not strictly denormalization.

[simonsan]

Hmm, I mean teams.json is also missing a link to a team page or something like this. So I'm not sure if it's better to break it down now in just a single string. Or to really make the one time effort and enhance teams.json with as much information as possible (e.g. URL to team pages, achievements, team icons or links to them etc.).

But true, with Liquipedia in place it's possible to also query that information from there, I'm not sure if they updated to the media wiki already which has a better and easier to use API. This SMW (Semantic Media Wiki) thingy was relatively annoying to use for small tasks. So also from this standpoint it might be still good to save some data easily parseble in this repository.

[happyleavesaoc]

Done