W3C home > Mailing lists > Public > public-owl-dev@w3.org > July to September 2011

RE: Using cardinality restrictions

From: <Soeren.Kemmann@iese.fraunhofer.de>
Date: Wed, 13 Jul 2011 16:18:13 +0200
Message-ID: <AAEECBB86B185F468D8134DE603C20D402156AB3@hermes.iese.fhg.de>
To: <sattler@cs.man.ac.uk>
Cc: <public-owl-dev@w3.org>, <Soeren.Kemmann@iese.fraunhofer.de>


I’ve now said (as closure) that only values of class RefClass are allowed as
hasRef-successors and I’ve made RefClass an enumeration class. RefClass has
exactly the values defined as in the instance enumeration set. 


I would now assume the due to the fact that only RefClasses are allowed as
hasRef-successors and I havn’t defined an instance of the enumeration that
even in an open world the instance (with the described hasRef property)
cannot have any other (unknown) instance.

Or is this assumption wrong?

If I do not explicitly state a hasRef-successor it is not said that the
instance does not have one, correct?

Then I don’t understand how closure can help me in a situation where I want
to know whether a property has cardinality 0!


From: Uli Sattler [mailto:sattler@cs.man.ac.uk] 
Sent: Mittwoch, 13. Juli 2011 15:46
To: Kemmann, Soeren
Cc: public-owl-dev@w3.org
Subject: Re: Using cardinality restrictions



On 13 Jul 2011, at 14:28, <Soeren.Kemmann@iese.fraunhofer.de> wrote:

Hi Uli, hi @all,


Yes, that makes sense!

I was trying to build a small example analog to the famous pizza example.

The difference is that I do not want to assign instances to the partitions
and use them, but I want to just define instances and have the reasoner
interfere to which class they belong to.

I’m sorry … but I couldn’t achieve this yet. This is what I did:

My Class Hierarchy:


- RefClass

- TestValuePartition == (Part1 union Part2)

                - Part1

                - Part2

Part1 and Part 2 are marked as disjoint.

Furthermore, I defined that Part 1 has some references to RefClass (hasRef
some Class).

Now, if I create two instances with asserted type TestValuePartition, one
that has a reference to an instance of RefClass and the other having no


again, be careful, 'the other having no *known* [reference to an] instance
of RefClass.

Due to the value partition I would have expected that instance 1 is
interfered to be of Part1 


...and this works (as you say below)

and instance 2 to be of Part2, but again only Part1 works!


same as before: instance 2 may or may not have a hasRef-successor, so we
have not enough information to say whether instance 2 is an instance of
Part1 or of Part2... 

Instance 2 stays as being a TestValuePartition instance (only). For me the
Value Partition is in this case not a value partition!?

What am I missing?



I am afraid you are missing the open world assumption (and thus of possible,
but neither necessarily true, nor necessarily false facts - e.g., instance 2
is possibly an instance of Part1, possibly an instance of Part2, thus not
necessarily an instance of either)...check for 'closure axioms'! Cheers, Uli



Thanks a lot!







From: Uli Sattler [mailto:sattler@cs.man.ac.uk] 
Sent: Dienstag, 12. Juli 2011 17:35
To: Kemmann, Soeren
Cc: public-owl-dev@w3.org
Subject: Re: Using cardinality restrictions



On 12 Jul 2011, at 10:27, <Soeren.Kemmann@iese.fraunhofer.de> wrote:

Hi there,


I’m trying to model (with Protégé 3.4.6 with Pellet Reasoner … just in case
it matters) that a class A has two subclasses B and C, where B and C are

The distinction I want to make is that every instance of A is either of
subclass B or of C dependent on the cardinality of a property p.

The “test” is whether the instance has values assigned to property p ( p min
1). This kind of works … the instances are interfered to be of that type.

But the other class does not work. If tried (p max 0), (p exactly 0), (p
exactly 0 RangeClass), but nothing works.


I’m using OWL-DL and as far as I understood 0/1 cardinalities are ok for
OWL-DL, right?



Hi Soeren, 


yes, they do - I guess you have, in your ontology, something like 


B SubClassOf C   

A SubClassOf C  %% these two axioms aren't really necessary if you have the
2 below...


A EquivalentClass C and (p min 1) 

B EquivalentClass C and (p max 0) 


...and then when you have an instance of C with 


- 1 known p-successor, they are classified as being an instance of A

- no known p-successor, they are ... only classified as being an instance of
C - and you wonder why...


The reason is found in the word 'known' used above: your instance of C has
no *known* p-successor, but could have some, due to the open world


So, how to rescue this? For example, you could say explicitly how many
p-successors an individual has...in general, you need a 'closure' statement
that says that the *known* p-successors are all p-successors. 


If I remember correctly, the famous Pizza tutorial explains this in detail
(see http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/ )


Cheers, Uli

Thanks a lot!





Dipl. Inf. Soeren Kemmann
Fraunhofer IESE
Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Tel.: +49 (0) 631 / 6800 - 2218
Fax.: +49 (0) 631 / 6800 - 9 2218



Received on Wednesday, 13 July 2011 14:19:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:20 UTC