DL Modelling Nit Picks of AtomOwl Ontology

0 views
Skip to first unread message

Chimezie Ogbuji

unread,
Jul 22, 2006, 10:04:38 AM7/22/06
to atom...@googlegroups.com
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).

Henry Story

unread,
Jul 22, 2006, 1:45:29 PM7/22/06
to atom...@googlegroups.com

On 22 Jul 2006, at 16:04, Chimezie Ogbuji wrote:

>
> 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

Henry Story

unread,
Jul 24, 2006, 11:34:04 AM7/24/06
to atom...@googlegroups.com
Having a little more time to look at your proposal I am not sure I
think this is quite right. There is a difference between what is
currently in the ontology and what you have stated. The current
ontology would allow one to imagine that there are other things that
can be :Version-s, whereas you are saying that a version is exactly
the union of an :Entry and a :Feed. By the way, this is not to say
that I believe that it would not be better to have :Version be
exactly the class of all :Entries and :Feeds.

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:

Chimezie Ogbuji

unread,
Jul 24, 2006, 8:45:48 PM7/24/06
to atom...@googlegroups.com
On 7/24/06, Henry Story <henry...@bblfish.net> wrote:
>
> Having a little more time to look at your proposal I am not sure I
> think this is quite right. There is a difference between what is
> currently in the ontology and what you have stated. The current
> ontology would allow one to imagine that there are other things that
> can be :Version-s, whereas you are saying that a version is exactly
> the union of an :Entry and a :Feed. By the way, this is not to say
> that I believe that it would not be better to have :Version be
> exactly the class of all :Entries and :Feeds.

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.

Reply all
Reply to author
Forward
0 new messages