Re: Cardinality in the open world

On Apr 7, 2005, at 2:27 AM, Paul Gearon wrote:

> Hi,
>
> Thanks for the comments.  I'll try to clarify, and perhaps change the 
> way I presented the question.
>
> On 06/04/2005, at 3:41 PM, Bijan Parsia wrote:
>>> I've been having some difficulty understanding the use of OWL 
>>> cardinality with the open world assumption, and I'd like some advice 
>>> please.
>>>
>>> While I know that the open world assumption means that any 
>>> unspecified statements are "unknown".
>>
>> What do you mean by "unspecified"?
>
> I'm thinking in terms of a set of RDF statements, such as those found 
> in an RDF database.  An "unspecified" statement is one that does not 
> appear in the database.

Can it be entailed by the kb?

>>>  I interpret this to mean that it is possible for any unwritten 
>>> statement
>>
>> But there are known unwritten statements. Most entailments, for 
>> example.
>
> My ultimate purpose here is to try to work out which are valid 
> entailments.  I am also trying to recognise when a set of statements 
> contains a contradiction.

Can one "contain" a contradiction by entailing one?

>>>   (If I'm wrong here, then let me know as the rest of this message 
>>> is based on this assumption).
>>
>> This doesn't seem to be the most helpful way to conceive of it. 
>> Better to think in terms of model theory (though, it's possible that 
>> your version will line up with the model theoretic one...it's just 
>> nicer to use standard terminology).
>
> Unfortunately I don't have a background in model theory.  Can you 
> suggest a primer for me?

Actually, the RDF semantics document has a pretty nice intro.

Otherwise, I'd just read some logic books.
[snip]
>>> minCardinality of 1:
>>> This describes existence.  Any statements with this predicate make 
>>> the model valid.
>>
>> Not if there were a maxCardinailty of 0.
>
> True.  However, I would distinguish that as an inconsistency in the 
> TBox data.

But it can occur where there is no tbox.

	a:minCard(1)
	a:maxCard(0)

No tbox. (The ":" means "type"). It's awkward to write this in RDF or 
RDF/XML, but so much is :)

> While these inconsistencies are important to find, I want to assume 
> that the TBox information is correct, and I am looking for 
> inconsistencies in the ABox data in relation to the TBox data.

	a:C
	a: ~C

> In a practical context, I'd like to check an ontology for 
> contradictions upon entry to the database.

Usually, this is called checking for concept unsatisfiability. However, 
there is always at least one unsatisfiable concept in an ontology, 
owl:Nothing. So unsatisfiabiltiy of a class isn't a devestating 
problem, unless you assert something as a member of it.

But look, do you you think this tbox is contradictory?

	A subClassOf min (3,P)
	B subClassOf max (2, P)

Clearly not. Yet,

	x rdf:type A.
	x rdf:type B.

is inconsistent.

>  I don't think it would make sense to check for consistency and 
> perform entailments with an inconsistent ontology.

Of course I didn't suggest that.

> I take your point though.  Please excuse my assumptions.  :-)

It's ok :) But the point is that you can accumulate statements of 
membership in a restriction in a variety of ways. These can clash.

> Re: minCardinality 1
>>>   However, if there are no statements with the predicate then the 
>>> model is still consistent, as those statements could exist.
>
> Reword this to: If there are no statement with the predicate then the 
> consistency of this is "unknown".

No. If nothing contradicts it, then it is consistent. We don't know if 
anything is a member of that class, but it is consistent of many things 
that they are a member of that class.

e.g.,
	bob: minCard(1, P)

It's consistent even if we don't know any other *facts* about bob.

If our kb enatils (or states):
	bob: maxCard(0,P)

then we're in trouble again.

It's perhaps better for you to think of consistency to be a feature of 
a *set of statements*. A set of statements is consistent if it is 
*possible* for them to all be true together. That is, there is an 
interpretation of the set such that every statement comes out true.

So, unless a statement is self-contradictory (i.e, *always false*), 
it's going to be consistent with itself. So to get inconsistency joy 
you'll have to add more statements.

> This is because the database does not contain any statements to make 
> this restriction consistent, so the existence of these statements is 
> "unknown".

Let's make the restriction a free standing expression in a typical dl. 
To do that, it has to be an abox statement (i.e., a ground formula), or 
a tbox statement (i.e., a universally quantified conditional). So 
consider

	a:minCard(1, P)

Is that consistent? Yes, for sure!!! Why? Because there's an 
interpretation underwhich it is true (i.e., it has a model).

Oh, you say, but there is a "database" statement. Well, consider the 
tbox statement:

	for all x, if A(x), then minCard(1,P)x

(ok, this is ugly, since normal first order doesn't have counting 
quantifiers. Let's see, the expansion would be something like:

	for all x, (if A(x), then some y, Pxy)

Hmm. That seems right, but I'm wee bit tired so who knows :) You get 
the idea though.

(Eek, my first one was nuts. I just reduced this to the existential. 
Higher cardinalities are more tersely expressed with counting 
quantifiers)

Is this sentence consitent? Sure it is! And we know it. Why? because 
there is an interepretation yadda yadda yadda. What's such an 
interepretation? Well, imagine a world where there is only one 
individual, mary, and she is not A.

Or, imagine a world where mary *is* A. and there another individual, 
sally. And mary P sally. Or heck, mary P mary.

Imagine another world where there's only sheeva. and sheeve is A. and 
sheeva Ps sheeva.

Imagine another world....

> Consequently, this cannot be called an error (due to inconsistency) 
> because the consistency cannot be determined.

See above. Consistent all the way, baby!

>
>>> minCardinality > 1:
>>> If there are not enough statements using the predicate, then the 
>>> model will still be consistent because those statements could exist.
>
> Reword to: If there are not enough known statements using the 
> predicate, then consistency is "unknown".

Nope.

> Therefore no error is found.
>
> Incidentally, you can probably tell from my working here, but I'm 
> making the assumption that the above statement is in relation to a 
> single subject.  All of the tests I describe here need to be performed 
> over each subject-predicate in turn.

Lost me. You seem to be dealing with class expressions, which, in a dl, 
are never free standing. either they are (mostly) ground, or parts of 
quantified conditionals. (ok, it's a leetle more complicated)

>> Not necessarily. For example, and still trivial, say you had a 
>> minCard= 4 and a maxCard = 2. Oops.
>
> Yes, though this is the TBox error I mentioned above.

You don't understand what you mean here. :)

>>> The only case where this could not be consistent would be if it is 
>>> not legal to create the required statements.  The only instance of 
>>> this that I can think of is if the range of the predicate is 
>>> restricted in some way, for instance it could be a oneOf without 
>>> enough members.
>>
>> See above.
>
> Yes, this is another TBox error.  Since I was going to pick up on this 
> one, I should have also mentioned the minCardinality > maxCardinality 
> error as well, so I see why you are pointing it out.
>
>>>   However, that case would be a fault in the ontology, not in the 
>>> data.
>>
>> I don't see what this means and the degree that I do, I don't see 
>> that it matters.
>
> There is a difference between data contradicting its ontology and the 
> ontology contradicting itself.

It's all one, man. This is just logic. There's no "data/ontology" split.

>  When the ontology contradicts itself then it is impossible to insert 
> data into a database that will work with the ontology.

Of course, I've been not using any tbox statements in my 
counterexamples.

> When an ontology is consistent, then it becomes useful, and it can be 
> used on data which is inserted into the database.  In this case "used" 
> means to check for consistency, and to perform entailments.

Really, you are confused.

> This has a practical application, as ontology data *can* be considered 
> separately inside a database (though this is not required, since OWL 
> is expressed in RDF).  Often an ontology will be written once, and 
> used many times on different sets of data.  In this case, the ontology 
> should be recognised to be inconsistent as soon as it is presented to 
> the database, rather than when it is applied to a set of data.

These are all statements. It's true that you can have two sets of 
statements that are consistent on their own, but inconsistent when 
merged. So? There's no magic there.

Set 1: a:C
Set 2: a:~C
set 1 union 2: a:C, a:~C

So?

Set 1: a:min(2,P)
Set 2: a:max(1,P)

You see where this is going.

How about

Set 1: C subclassof min(2,P). D subClassOf max(1, P)
Set 2: a:C,  a:D

Set 1 is consistent (and an "ontology"; pure tbox). Set 2 is consistent 
(pure abox; still an ontology! ;))

Set 1 union 2 is inconsistent.

[snip]

Sorry, I don't have the time/energy to go through the rest of this. Let 
me know if there's something that isn't clarified by the discussion 
thus far and I'll try to repond.

Cheers,
Bijan.

Received on Friday, 8 April 2005 01:20:15 UTC