MTG Engine — case study
Knowledge graph engine para análise de decks de Magic: The Gathering Commander
Projeto pessoal que serve como exemplo prático conectando vários tópicos do KB: RDF, SHACL, SPARQL, dotNetRDF, Outbox, Polyglot persistence, EKS e mais.
Problema
Existem dois sinais separados para avaliar cards/decks de Magic: The Gathering Commander:
- EDHREC mede popularidade — quantos decks usam um card
- EDHTop16 mede performance competitiva — quantos cards aparecem em torneios e em quais posições
Um sinal não implica o outro. Cards muito populares podem ser ruins competitivamente; cards de nicho podem dominar tournaments. Cruzar os dois revela:
- Cards overhyped (popularidade alta, performance baixa)
- Cards underrated (performance alta, popularidade baixa)
- Synergy packages (cards que aparecem juntos em decks vencedores)
- Recomendações por budget (best dollar-per-power)
Stack
| Camada | Tecnologia |
|---|---|
| Runtime | .NET 8 / ASP.NET Core |
| RDF library | dotNetRDF |
| Triplestore (dev) | Apache Jena Fuseki |
| Triplestore (prod) | Amazon Neptune (RDF mode) |
| ETL / ingestors | BackgroundService + HttpClient |
| Validação | SHACL via dotNetRDF |
| Eventos | Outbox → Kafka (futuro Debezium) |
| Observability | OpenTelemetry → CloudWatch (em prod) |
| Deploy | EKS com IRSA |
Por que RDF?
- Integração de fontes heterogêneas — Scryfall, EDHREC, EDHTop16, Spicerack têm shapes diferentes; RDF unifica via vocabulário comum
- Relações são first-class — "card X aparece em deck Y comandado por Z em torneio W" é uma rede de triplas natural
- Inferência — derivar fatos (legalidade por formato, color identity, synergy) via OWL ou regras SPARQL
- Validação semântica — SHACL garante "deck Commander tem 100 cards e 1 commander" na ingestão
- Queries declarativas — SPARQL responde "recomendar top 10 cards azuis < $5 que aparecem em > 5% dos top 16" sem joins manuais