This is really a nit pick, but I thought I should at least mention it.
When modelling OWL (or any other Description Logics-based ontology
language) I usually try to follow a little known convention that is
enforced in older Description Logic systems (such as CLASSIC). I try
not to directly subclass redundatly if the it can be implied by a
class constructor.
For instance, consider Version, Feed, and Entry as they are now:
:Version a owl:Class;
rdfs:subClassOf [
a owl:Restriction;
owl:cardinality 1;
owl:onProperty :id ],
[
a owl:Restriction;
owl:cardinality 1;
owl:onProperty :updated ] .
:Entry a owl:Class;
rdfs:subClassOf :Version .
:Feed a owl:Class;
rdfs:subClassOf :Version .
I consider it a better (and more expressive) DL convention to express
the class hierarchy this way:
:Entry a owl:Class
:Feed a owl:Class
:Version a owl:Class;
rdfs:subClassOf
[
a owl:Restriction;
owl:cardinality 1;
owl:onProperty :id ],
[
a owl:Restriction;
owl:cardinality 1;
owl:onProperty :updated ],
[ a owl:Class; owl:unionOf (:Entry :Feed) ]
Which expresses the same thing but more consisely and it's less work
for a reasoner which can infer *both* subclass (subsumption)
relationships at once. As it turns out (and I wasn't aware of this
before), older DL languages do not "allow one to simply state that one
concpet, or category, is a subset of another. This is a deliberate
policy: subsumption between categories must be derivable from some
aspects of the descriptions of the categories. If not, then something
is missing from the descriptions."
Ofcourse this policy is hard to enforce when the subclass relationship
is between classes in seperate vocabularies, such as:
:Person a owl:Class;
rdfs:subClassOf foaf:Agent, [
a owl:Restriction;
owl:cardinality 1;
owl:onProperty :email ] .
I thought you might be interested since the ontology is written with
reasoning in mind (the embedded N3 implication for instance).
