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).
>
> 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.
Nit Picks are great. It is really difficult to pick one's own ;-)
I'll work your suggestions into your ontology in the next few days...
Henry
I did what you suggested for :Text constructs, having a :TextContent
class be the union of :PlainText, :HTML and :XHTML.
But then I reverted back to what we have currently.
I'll keep your point in mind though. It may help us make a decision
at a later time. Ie. I'd need some further reasons to feel like the
change was worth making now.
Henry
On 22 Jul 2006, at 16:04, Chimezie Ogbuji wrote:
You're right. You can only take the convention into account if the
class description is 'complete', otherwise.you'd have to be explicit
about the subclasses.