General Thoughts
Taxonomies can be flat or hierarchical. It is natural for educational taxonomies to contain several levels of hierarchy even when they are represented as flat lists in, say, a CSV file.
For example, the Lightcast skills taxonomy is three leveled consisting of a category → sub-category → skill.
I believe we should maintain the hierarchical semantics in our data model even if it makes sense to flatten levels for convenience for specific use cases, say full text search.
This would allow us to easily, say, gather all taxon in a specific parent category, say, algebra. A different approach would be to use string matching in queries, but that is an unnecessary compromise.
Lightcast OpenSkills
The Lightcast Taxonomy is a three level hierarchical taxonomy made up of categories, sub-categories and skills. Skill nodes are rooted to persistent, but priority, URLs.
...
Each node is also associated with a number of other types of meta-data including keywords, and associations with occupations, O*Net Job Codes, other standards, etc. This data is denormalized and stored as a list in a single field of semi-colon separated values.
The content of the the skill taxonomy can be reviewed here.
- Should we support relations between nodes in different taxonomies? For example, WGU includes a Lightcast URL for the aligned skill in that taxonomy.
- Should the data model include a notion of modifiers or specifiers to relate arbitrary values to a node? This could be useful for association O*Net coded for example, could also be useful in the case of common core where grades are associated with a node, but aren’t really part of the hierarchy.
...