Re: Description Logics Knowledge Base

On Jun 22, 2007, at 4:31 PM, Chuming Chen wrote:

>
> Dear List,
>
> I understand the traditional Description Logics Knowledge Base  
> consists of a TBox </wiki/TBox> (terminological box) and an ABox </ 
> wiki/ABox> (assertional box).

Eh. I wouldn't get *too* hung up in that distinction. It's not like  
there's a *structure*, the TBox, which is syntactically enforced. The  
TBox consists of formulae of a certain form (i.e., universally  
quantified conditionals with one free variable "on top"). The "RBox"  
"exists" in any DL with property axioms, e.g., subPropertyOf, or  
transitive.

> With the development of SHOIQ and SROIQ, the role or property is  
> standing out and we now have a RBox.

Again, this is just some terminology. Don't get hung up in it. (It  
also is "there" in much weaker dls)

> Some papers I am reading only consider TBox and RBox as the DL  
> knowledge base and exclude ABox.

With nominals (O) you can encode all ABox axioms (i.e., axioms of the  
sort, a rdf:type B, and s p o) as TBox axioms (e.g., using hasValue).

It often simplifies proofs to work with a reduce set of forms. For  
example, in several recent papers, you'll see people only having  
cases for universal quantification, min cardinality, and disjunction,  
since existential, max, and conjunction are definable from the former  
(with negation).

> Can anybody shed some light on this? Would it be better if we call  
> DL knowledge base the triple of TBox, RBox and ABox?

It's better not to get hung up on the terminology. Or rather, if you  
got confused by that shift in papers, the terminology is likely  
getting in your way rather than helping you.

In many DLs (without nominals) there is the striking feature that  
TBox entailments are (largely) isolated from ABox statements This is  
a good thing. With nominals, this isolation is lost, so while some  
things are simpler (when proving things you can restrict your  
attention to the TBox) other things are more complex (the analogy  
between TBox and Schema and ABox and data is weakened...consider data  
complexity).

There are good human factors reasons not to write all your abox  
statements as TBox statements, even when you can, and perhaps good  
implementational reasons too (sometimes, eliminating constructs can  
improve reasoner performance by presenting more uniform input; other  
times, there are useful clues in the more constructor heavy for or  
the normalization process can introduce difficulty).

Cheers,
Bijan.

Received on Saturday, 23 June 2007 09:13:13 UTC