Re: disambiguation of properties: explicitly or by assumptions?

On 1 Jan 2004, at 02:20, David Martin wrote:
> A concern has come up that, with only declarations like the above, an 
> OWL reasoner can't be sure if these are all of the inputs of 
> OrderBook, or if these 2 inputs are distinct, or how many inputs 
> OrderBook has. And of course that's clearly true; the above 
> declaration is ambiguous on all of these points.
>
> It's also true that we could add in additional declarations that 
> remove the ambiguity.  For example, we could add a cardinality 
> restriction that says "OrderBook has exactly 2 Inputs", and we could 
> add a differentFrom statement that says "BookName and CreditCardInfo 
> are 2 different things".
>
> OK, some of us feel that we should add these additional declarations, 
> so as to avoid any possible confusion or malfunction in an OWL 
> reasoner that might be processing one of our knowledge bases.

I'm definitely on this side.

>  Others of us (myself included) feel that it's extremely unfortunate, 
> on practical grounds, to have to add in these "disambiguation 
> declarations".  To my mind, some of the reasons for this view are:
>
>     () For one thing, there's the issue of economy of representation: 
> the number of differentFrom statements could get to be quite large. 
> (For N inputs, (N choose 2) = (N * (N - 1)) / 2 differentFrom 
> statements are required.)
>     () While there are more economical ways of getting the same 
> disambiguation, they still tend to be cumbersome, inelegant 
> complications that obscure (from humans) what's most important about 
> the knowledgebase.
>     () No matter how you disambiguate, the presence of the 
> disambiguation declarations makes it harder and more complicated to 
> make changes to the knowledgebase.
>     () No matter how you disambiguate, these declarations also make it 
> harder and more complicated (or even impossible) to build on and 
> extend the knowledgebase in a modular fashion.

These are very reasonable objections. A simple solution, as you point 
out below, is to provide additional "front-end" assumptions that can 
simplify the management of the ontology.

> For those of us who are opposed to adding in the "disambiguation 
> declarations", it seems we could avoid doing so by stipulating a set 
> of assumptions, such as the "Unique Names Assumption" (UNA) that makes 
> them unnecessary.  Of course, the UNA by itself isn't enough.  In the 
> example above, UNA tells us there are at least 2 inputs, but it 
> doesn't tell us that's *all* there are.  Here it appears some form of 
> cardinality restriction is still needed.
>
> There appear to be 2 issues on which we need to get clear:
>
> (1) The technical question: is there some other assumption that could 
> be called upon to eliminate the need for a cardinality restriction, 
> **whose definition is clear enough and widely recognized enough to be 
> useful, or might become so** (and thus is likely to be supported by 
> reasoners)? Like perhaps some form of the closed-world assumption?  
> (We have some as-yet-inconclusive ideas about this, but I omit them 
> here in the interest of brevity.)

Various solutions to this long-standing issue in knowledge 
representation have been proposed in the past.
You could have an operator (i.e., a macro) which states that a role is 
"closed" in a particular individual context (moreover, UNA should 
hold). In your example, you could state that the role <hasInput> is 
closed for AtomicProcess with the two explicit individual fillers, and 
this would add the statements "OrderBook has exactly 2 Inputs", and 
"BookName and CreditCardInfo are 2 different things".
A simpler approach is to use directly the UNA and the OWL-Full oneOf 
construct, which enumerates the exact number of fillers of the hasInput 
role for AtomicProcess.

The above solutions work if you are talking about individuals. If you 
want to make such statement at the ontology level then you should have 
general constructs among classes.
Object-oriented formalisms and most of conceptual graphs dialects do 
have such assumption embedded: it says that in a specialisation 
hierarchy, all the subclasses of a superclass are mutually disjoint, so 
that no individual can be instance of more than one class (unless it is 
in the same specialisation path). Moreover, UNA holds.
As such, this assumption would be too strong, since it forbids any 
non-trivial intersection among classes.
In general, I'm strongly in favour -- and I always pushed to have it as 
a predefined construct in DLs and ontology languages -- to have a 
disjoint-covering (i.e., partitioning) macro (like in UML or in 
Extended-ER) in the ontology language, which translates into pairwise 
disjointness statements among the subclasses and a union covering 
statement between the subclasses and the superclass. For example, 
[male,female partition person] translates into
male \subsumedby ((\not female) \and person)
female \subsumedby person
person \subsumedby (male \or female)
Please note that nesting such constructs (i.e., partitions of 
partitions of parti...) is known to kill the current reasoners (since 
there is an exponential explosion of reasoning by case). It would be 
nice if implementors of reasoners will consider explicit optimisations 
for the partitioning construct, which I believe is crucial to build 
precise ontologies (as this example shows).

> (2) The "social" question: is it reasonable and workable for a group 
> of ontology users (users of OWL-S in this case) to stipulate that all 
> knowledge bases using a given ontology may be assumed to rely on 
> assumptions such as UNA and whatever the answer to (1) is?

I think yes.
--e.

Enrico Franconi                  - franconi@inf.unibz.it
Free University of Bozen-Bolzano - http://www.inf.unibz.it/~franconi/
Faculty of Computer Science      - Phone: (+39) 0471-315-642
I-39100 Bozen-Bolzano BZ, Italy  - Fax:   (+39) 0471-315-649

Received on Friday, 2 January 2004 12:36:53 UTC