So I have this simple use-case: I'd like to use a taxonomy to support faceted search/filtering in the UI. One could select a concept in the taxonomy and then enter a search string which is then searched in the classes that are covered by that concept. This is very similar to what many shopping web-sites do.
My current idea is to introduce a new property along the lines of
Is there any reason you cannot simply declare Server/PC/etc to be a subclass of Computer and then query for instances of Computer which will naturally include instances of subclasses?
I think you could use punning. You’d avoid adding the additional term and be able to use SKOS directly. If you were to add a new term it would not be a good idea to add it to a namespace that you don’t control like skos:covers.
We could attempt to create the class hierarchy and turn it into a taxonomy. That has been variously discussed in a number of articles, including here: Using OWL and SKOS
However, we want to keep the two hierarchies separate and independent intentionally. There may be situations where the class hierarchy is different from the taxonomy. Let me expand on the example just slightly: In an inventory application, I would like to cover load-balancers or firewalls. Some view them as computers some view them as network devices. Thus they would have to be in two branches of the taxonomy.
And, thanks to punning in OWL 2 this works just fine. Classes are still classes but, for the purpose of concept association, they are treated as individuals.
I don't think you need the property that points to the concept as punning handles this for you. With punning you can just treat your class as an individual and make it a skos:Concept
I suppose using this approach works and leaves only a somewhat philosophical question: making a class also a concept explicitly or using skos:exactMatch and thus making it a concept implicitly says: This class is-a concept. I am not sure if I understand the (possibly unintended) consequences of making such a statement.