Thursday, April 07, 2005

Q & A on Cardinality
I'm not blogging as much these days, which is annoying me. Instead, I'm working longer hours, particularly in the evenings when I normally write the blog. I'm pretty happy about the amount of work I'm getting done, but it would be nice to be keeping track of it better.

Over the last 3 days I've spent some significant time working over some problems to do with cardinality. Anyone watching the RDF Logic mailing list will have seen me working through some of these issues. I'll confess that it's a little embarrassing having the world watch me blunder along as I learn something, but at least I'm coming to a better understanding. Thanks go to Bijan Parsia for this.

So what is the deal with owl:minCardinality? Well there seem to be two broad cases to consider.

The first is that owl:minCardinality can conflict with another restriction on the domain of a predicate. For instance, there may be an owl:maxCardinality restriction which is for a lower number than the owl:minCardinality restriction. Or perhaps the range of the restricted predicate is a limited set of instances (from a owl:oneOf definition on the class of the range), and the size of the set of the range is less than the minimum cardinality. In cases like this, the class is unsatisfiable. That means that while the class can exist without conflict, any instances of the class will cause a conflict.

I had earlier thought that it would be illegal to have an unsatisfiable class, but this is not the case. The classic case of this is the owl:Nothing class. Allowing these classes does change things a bit.

So owl:minCardinality can be used to define (and detect violations of) unsatisfiable classes.

The second case is where owl:minCardinality is used to define a satisfiable class. In this case, it tells you that a predicate is in use, but it can't say anything else. If the knowledge base includes some usages of that predicate, then fine. If the knowledge base does not include the usage of that predicate, then you still know that the predicate is being used... but you can't know how it's being used.

From the perspective of supporting OWL minimum cardinality in a database (like Kowari), this means that the database can't do anything for you (except detect the use of an unsatisfiable class). It can't entail any new statements, nor can it detect an inconsistency that must be corrected.

For people who were hoping to use owl:minCardinality to restrict their models in some way, this will come as a disappointment.

I'm still thinking that it may be useful for some people if I allow for a "temporary" closed world check. That way, if they want to use minimum cardinality to check that a predicate is used at least that many times, then they can. This is an incorrect usage of OWL, but one that I think some people expect to have.

I'll work on the correct implementation first, and then I'll look at installing a switch that will allow of this incorrect (though potentially useful) behaviour. At that point I'll have to decide if I want to assume unique names or not. Yuck. :-)

2 comments:

Anonymous said...

On the "temporary closed world" bit: This is exactly what we recognized when playing with modeling and OWL. Our current thinking is that there must be a subset of OWL that we can pick from and assume certain, *validation* rules. Then we can run things through that before they reach the graph.

Andrew said...

I don't know if you read:
http://www.deri.at/teaching/seminars/internal/slides/OWL_DLvsFlight.pdf

Or here:
http://semantic.nodix.net/

A concrete example seemed to get me to a happier place more quickly.

I'm thinking that closing the world can be a pragmatic thing to do. But either way you still need to be able to count in an open or closed world no matter what - just what you can do with it is less.

If you do close the world and create semantics to represent closed world, unique named cardinality restrictions say you're doing OWL Flight or Paul DL or something not OWL DL.