Nested SKOS Concept Schemes?

Question

I'm trying to make a knowledge graph of sorts with some of my company's data. I'm primarily using SKOS as the ontology for describing things, but I'm running into a quandry about the usage of ConceptSchemes.

Basically I want to create a concept scheme for navigating various concept schemes. Although SKOS asserts Concepts and Schemes to be disjoint, it also explicitly says skos:inScheme has no domain. This leads me to think I can get away with having a ConceptScheme where most/all of its concepts are actually ConceptSchemes.

This making Schemes navigable seems like it has to be a common enough problem, but I haven't been able to find much on the subject. Is this "Schemes of Schemes" an advisable approach? Or if not, is there a better way to link disparate concept schemes so that they get the navigability that such a solution would offer?

p.s. I tagged this with 'dcat' as well since I plan to build a DCAT data catalog (potentially a catalog of catalogs) in a similar way. However I think a clear answer to the main question should clear up the DCAT side of things too.

Answer 1

Well, the specification is clear, Concept and ConceptScheme are disjoint. The domain of inScheme is irrelevant to this. “I know my actions are breaking rule A, but they are not breaking rule B, therefore it is okay to break rule A.” It doesn’t work that way.

So, what are the consequences of breaking the rule?

• Data validators that know the SKOS rules would likely complain
• Tools for editing or displaying SKOS will likely get confused and might not work
• People familiar with SKOS will give you dirty looks when you describe your modelling

If you are okay with that (and you might well be) then go ahead.

Answer 2

There is no need to violate the disjointness of concepts and concepts schemes. If you use inScheme to create a scheme of schemes, or even a scheme M that is a mixed collection of schemes and concepts, you have not assigned two types to anything. Your scheme's members simply have different types. I agree with your interpretation that the lack of a domain for inScheme is intended to make this kind of thing possible.

To put it differently: There is a difference between assigning types Concept and Concept Scheme to the same resource (not allowed), and creating a collection that contains distinct members of both of these types.

PS. Whether this modelling approach is the best way to solve your problem, well, that's a different question from the one you asked here.