The accepted answer to this question provides a good explanation of the semantic difference between rdfs:subClassOf and owl:equivalentClass.
In the example provided by the OP, the class :Teenager is declared to be a subclass of a data property restriction on the :hasAge property with a value in the range [12:19]. The answer states that the rdfs:subClassOf assertion
means that any instance of Teenager in the OWL ontology must necessarily also have the property hasAge with a value in the range [12:19].
Although this statement may capture the semantics of subclass restrictions in OWL, what is the ultimate value of using them? It seems that not much can be inferred, programmatically, from a subclass restriction. So, is its main utility to document semantic modeling intent? When defining restrictions, why would an ontologist prefer rdfs:subClassOf over owl:equivalentClass?
For example, I encoded the following ontology (in Protégé 5.6.1), based on the OP's example:
@prefix : <urn:test/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@base <urn:test/> .
[ rdf:type owl:Ontology
] .
#################################################################
# Data properties
#################################################################
### urn:test/hasAge
:hasAge rdf:type owl:DatatypeProperty ;
rdfs:label "has age" .
#################################################################
# Classes
#################################################################
### urn:test/Person
:Person rdf:type owl:Class ;
rdfs:label "Person" .
### urn:test/Teenager
:Teenager rdf:type owl:Class ;
rdfs:subClassOf [ owl:intersectionOf ( :Person
[ rdf:type owl:Restriction ;
owl:onProperty :hasAge ;
owl:someValuesFrom [ rdf:type rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions ( [ xsd:minInclusive 12
]
[ xsd:maxInclusive 19
]
)
]
]
) ;
rdf:type owl:Class
] ;
rdfs:label "Teenager" .
#################################################################
# Individuals
#################################################################
### urn:test/_car
:_car rdf:type owl:NamedIndividual ;
:hasAge 13 .
### urn:test/_chris
:_chris rdf:type owl:NamedIndividual ,
:Teenager ;
:hasAge 20 ;
rdfs:label "Chris" .
When I run a reasoner (e.g., HermiT), the individual :_chris is still inferred to be a member of the :Teenager class, as asserted, even though the value of :hasAge is outside the defined range--and the ontology is not inferred to be inconsistent (I assume this is due to the Open World Assumption). :_chris is also inferred to be a member of the :Person class--and that's it.
If I run a DL Query in Protégé with the expression 'has age' some xsd:integer[>= 12 , <= 19], it does return :Teenager as a subclass and :_chris and :_car as instances.
Changing the DL query to 'has age' some xsd:integer[>= 12 , <= 42] returns the same results, whereas changing it to 'has age' some xsd:integer[>= 13 , <= 42] removes :Teenager as a subclass. So, that's interesting. Beyond DL queries, are there other standard ways (with current tooling) to leverage a restriction defined with rdfs:subClassOf in OWL?
Ultimately, if my main interest is in deriving new statements based on inferencing and OWL axioms, does a subclass restriction really give me anything of value?
Although this statement may capture the semantics of subclass restrictions in OWL, what is the ultimate value of using them? It seems that not much can be inferred, programmatically, from a subclass restriction.
What can be inferred is precisely what the subclass states. If you have this definition:
:Teenager a owl:Class ;
rdfs:subClassOf [ owl:intersectionOf ( :Person
[ a owl:Restriction ;
owl:onProperty :hasAge ;
owl:someValuesFrom [ a rdfs:Datatype ;
owl:onDatatype xsd:integer ;
owl:withRestrictions (
[ xsd:minInclusive 12 ]
[ xsd:maxInclusive 19 ]
)
]
]
) ; a owl:Class ] .
Then a statement :_chris a :Teenager implies both :_chris a :Person and
:_chris :hasAge [ a [ a rdfs:Datatype ; # a bit incorrect since literal is treated as an object here
owl:onDatatype xsd:integer ;
owl:withRestrictions (
[ xsd:minInclusive 12 ]
[ xsd:maxInclusive 19 ]
)
] ] .
Now you are correct that this does not give you any new interesting triples (since there are 8 concrete alternatives), but it could warn you against inconsistencies. The reason it does not in this case is because a person can have multiple ages, or at least you don't impose anything stricter in your ontology. Your ontology states that only some (hence owl:someValuesFrom) ages of a person have to be between 12 and 19 for a teenager, but not all of them! Once you add :_chris :hasAge 20, there is no inconsistency in that, since it is still possible Chris may have another age that is within the boundaries (indeed he can have all 8 ages) ‒ this is the open-world assumption.
Now I believe the issue here is the pattern of your restriction. This kind of pattern would be more suited for something like nationality:
:British a owl:Class ;
rdfs:subClassOf [ owl:intersectionOf ( :Person
[ a owl:Restriction ;
owl:onProperty :hasCitizenship ;
owl:someValuesFrom :BritishCitizenship
]
) ; a owl:Class ] .
Though perhaps imprecise in meaning, it would be reasonable to follow this pattern for this kind of class, more than for the age group.
There are two ways to "fix" the ontology in order to be able to detect the inconsistency:
Declare :hasAge a owl:FunctionalProperty. A functional property has exactly one value, and so having multiple ages is an inconsistency. This makes sense to use in this situation.
Use owl:allValuesFrom instead of owl:someValuesFrom. This is not as restrictive as the first option, but it still prevents you from stating conflicting facts about the age group of a person.
I would use both solutions, since they both state the intent of the ontology closer to the domain logic.
Now for the titular question, this is actually unrelated to the issue in your ontology, and simply depends on how accurate you want your ontology to be in relation to the business objects. The two questions to ask here are:
I think that, for this case, if one is true, the other should be true as well, in which case owl:equivalentClass would be a better choice for the class relation, and for any other definition like this one. All in all, you shouldn't necessarily prefer either of rdfs:subClassOf or owl:equivalentClass for its own sake, instead you should pick the one that is closer to the real-world relations of the objects you try to describe, within the limits of how strict you want your ontology to be.