pbprdf

I'm seeing several people asking what RDF is useful for. If you're curious, I use it for basketball analytics: https://github.com/andrewstellman/pbprdf Here's an article about my system, pbprdf: https://www.zdnet.com/article/nba-analytics-and-rdf-graphs-g... And an example of its use: https://gist.github.com/andrewstellman/4872dbb9dc7593e56abdd... Here's an example of what the RDF files generated by pbprdf look like: Here's the ontology, which defines the vocabulary it uses: https://github.com/andrewstellman/pbprdf/blob/master/generat... And this is what the data looks like: <pbprdf/games/2017-11-29_Warriors_at_Lakers/230> pbprdf:shotPoints "3"^^xsd:int ; pbprdf:shotAssistedBy <pbprdf/players/Klay_Thompson> ; pbprdf:shotType "26-foot three point jumper" ; pbprdf:shotMade "true"^^xsd:boolean ; a pbprdf:Sho

This article talks about my open source RDF basketball analytics project: https://github.com/andrewstellman/pbprdf The author links to the Hacker News thread where he learned about it: https://news.ycombinator.com/item?id=16542183 Happy to answer questions.

This is interesting, I always wanted to find a good use case for RDF but in the end RDBMS worked out fine. Sports events seem a good example. What made it easier for you in your example of basketball play-by-plays with RDF? Taking the first example https://github.com/andrewstellman/pbprdf#example-analyze-a-s... and translating it into an RDBMS approach seems rather straight forward: GameEvent (PersonA, EventType, PersonB, Game, Time) Roster (Person, Game, Team) To get the fouls drawn you then take SELECT Team, COUNT(Team) FROM GameEvent JOIN Roster ON GameEvent.Game = Roster.Game AND GameEvent.PersonB = Roster.Person WHERE GameEvent.EventType = "foul" GROUP BY Roster.Team Is it because of easier schema changes later on like introducing "secondsLeftInPeriod"? I suppose in a normalized relational scenario that could be somet

I've been using RDF and triplestores / RDF databases for the last half-decade, developing both front-end and back-end systems, and training many developers to work in RDF. If you're used to either relational databases or object-oriented design, it's a really different way of thinking about data. Just like OOP is really good for certain kinds of problems and models, and RDBMS is good for other kinds of problems and models, RDF is great for specific kinds of problems. For example, if you need to combine several data from several somewhat incongruent sources into a single coherent database (e.g. dozens of data feeds that are almost the same, but you need to preserve the differences while combining the parts that are the same), you might end up with headaches trying to come up with a good RDBMS design; RDF is really well-suited for that kind