Could be -- I'm chewing on this. One thing that's becoming clear is that I care more about the hierarchy as an *output* representation than as I do as a *data* representation. So it's possible that the schema should be loosely-structured, but the data itself should follow conventions that are "mostly hierarchical".
I don't think it's precisely a "taxonomic lens" -- I do think there's a lot of really obvious and broadly-agreed taxonomy in the data itself. The problem is simply that it's a slightly messy taxonomy, so I probably need to leave the schema itself loose enough to cope with that.
And yes, you may well be more or less correct about the tag thing, although tags/links per se aren't really the distinction -- regardless of whether it's strict or loose, we're going to be holding it together with tags/links. That's how Querki thinks: tags/links are essentially the equivalent of foreign keys in a conventional DB, and you use them all the time. The question is mainly whether any of those pointers are single-valued, or whether they are all necessarily sets of pointers. (Equivalent to the conventional-DB question of whether to have direct links between objects or a join table: in Querki, the distinction is whether the Property is "Exactly One" or "Set".)
Indeed, I'm pondering whether to decouple the schema from the taxonomy entirely, with just a single node type for all levels that means "a game or collection of games", and have the taxonomy entirely implicit in the data itself. We'll see -- something of that sort may yet turn out to be correct.
(And I'll be mildly amused if I do wind up there, since it's almost exactly how the Poker Space wound up working. We may be evolving a best practice here...)
no subject
I don't think it's precisely a "taxonomic lens" -- I do think there's a lot of really obvious and broadly-agreed taxonomy in the data itself. The problem is simply that it's a slightly messy taxonomy, so I probably need to leave the schema itself loose enough to cope with that.
And yes, you may well be more or less correct about the tag thing, although tags/links per se aren't really the distinction -- regardless of whether it's strict or loose, we're going to be holding it together with tags/links. That's how Querki thinks: tags/links are essentially the equivalent of foreign keys in a conventional DB, and you use them all the time. The question is mainly whether any of those pointers are single-valued, or whether they are all necessarily sets of pointers. (Equivalent to the conventional-DB question of whether to have direct links between objects or a join table: in Querki, the distinction is whether the Property is "Exactly One" or "Set".)
Indeed, I'm pondering whether to decouple the schema from the taxonomy entirely, with just a single node type for all levels that means "a game or collection of games", and have the taxonomy entirely implicit in the data itself. We'll see -- something of that sort may yet turn out to be correct.
(And I'll be mildly amused if I do wind up there, since it's almost exactly how the Poker Space wound up working. We may be evolving a best practice here...)