The version management described in "5.1 Representation" and "5.2 Versioning – managing information over time" for classifications is not the one I see implemented for other usage of SKOS like thesaurus (Eurovoc). Typically, for thesauri :
The ConceptScheme and Concept URI remain stable over time in each version; the Concept URIs should not changed, otherwise content indexation would be broken;
The versioning information (date of publication, version, number, etc.) is captured in an instance of Dataset that is included in the file (as a header).
While I understand that the management and publication of classifications can be handled differently than thesauri, I think the differences in the 2 approaches should be stated clearly. The risk is that people with a thesaurus versioning problematic applies the classification approach that does not fit their situation. It should be stated clearly why XKOS considers that each version is a new ConceptScheme, and it should be stated clearly that this is only one possible solution to the question of the versioning of ConceptSchemes.
The versioning management described in 5.1 says that the URI of the ConceptScheme changes with each version. What about the Concepts URIs ? the section says nothing about concepts.
The fact that the classification "in general" is a skos:Concept sounds odd. I suggest that XKOS leaves open the range of that property to allow different modeling; in particular why would it be wrong to consider the classification "in general" as a ConceptScheme rather than a Concept ?
And "belongsTo" sounds odd too considering this is a temporal notion. Why not relying on PROV-O to describes this, and use a prov:specializationOf instead of xkos:belongsTo ? (prov:specializationOf : "An entity that is a specialization of another shares all aspects of the latter, and additionally presents more specific aspects of the same thing as the latter. In particular, the lifetime of the entity being specialized contains that of any specialization. Examples of aspects include a time period, an abstraction, and a context associated with the entity."). At least an equivalentProperty statement can be made to PROV-O;
Additionnaly, if a new ConceptScheme is created for each new version, XKOS should also provide the algorithm to translate classification information on version N to version N+1. If not, a clear statement should be made that such a translation algorithm is out of scope and should be implemented on a case by case basis;
The version management described in "5.1 Representation" and "5.2 Versioning – managing information over time" for classifications is not the one I see implemented for other usage of SKOS like thesaurus (Eurovoc). Typically, for thesauri :
While I understand that the management and publication of classifications can be handled differently than thesauri, I think the differences in the 2 approaches should be stated clearly. The risk is that people with a thesaurus versioning problematic applies the classification approach that does not fit their situation. It should be stated clearly why XKOS considers that each version is a new ConceptScheme, and it should be stated clearly that this is only one possible solution to the question of the versioning of ConceptSchemes.