We discuss ALCK, a nonmontonic logic that augments ALC with the epistemic operator K, and argue that a similar extension to OWL would be desirable. We show, however, that at its current state the OWL syntax is too inflexible to capture even this syntactically simpleminded extension. Finally, we introduce our implementation of ALCK as an extension to the tableau-based OWL-DL reasoner Pellet.
the question of whether bob is actually a manager or a programmer. An integrity constraint in this case will check that every employee is known to be one or the other.
Integrity constraints are common in database and frame systems, where the CWA is usually made. Without completely abandoning OWL’s open world, it would be useful to capture such constraints. The epistemic formulation of such integrity constraints−i.e. asking the database only for known facts−was noted by Reiter. These constraints, phrased epistemically, can be captured in ALCK. 2
ALCK
In [
We focus on the use of K in queries and assume that queries are posed to an ALC knowledge base Σ. Intuitively, the query ha : KCi (resp. haKRbi for a role) is read as “Is the individual a known to be C?” More formally, we let I be the usual interpretation, and W a set of interpretations that satisfy C. We say Σ |= ha : KCi if and only if for every interpretation I ∈ W, a ∈ CI. The set W must be maximal, which means that in our case it is simply the set of all first-order models of C. Returning to our motivational example, the closed-world query desired can be phrased as: Σ |= hbob : KM anager t KP rogrammeri. 3
The K operator is quite simple from a syntactic standpoint: it can be applied to classes and properties. We outline several failed approaches to encoding K into the RDF/XML syntax of OWL. It is clear that the operator cannot be encoded as a class, for the simple reason that it applies to other classes and properties. This left us with two options: 1. As a property? We could coin a new reserved OWL object property, owl:K.
To represent ha : KCi, we must make an anonymous class related via owl:K to C. Suppose that we want to encode hbob : M anager u ¬KHackeri: <rdf:Description rdf:about="#bob"> <rdf:type> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Manager"/> <owl:Class> <owl:complementOf>
<owl:Class> 1 Named after Kripke originally <owl:K>
<owl:Class rdf:about="#Hacker"/>
</owl:K>
</owl:Class>
</owl:complementOf>
</owl:Class>
</owl:intersectionOf>
</owl:Class>
</rdf:type>
</rdf:Description>
There are two immediate problems with this: (1) we are forced to generate
superfluous anonymous classes to maintain the “striped” structure of the
syntax (see [
<owl:modality>K</owl:modality> </owl:Class> <owl:Class rdf:about="#Person">
<owl:modality>K</owl:modality> </owl:Class> </owl:intersectionOf> </owl:Class> </rdf:type> </rdf:Description> The problem here is that we could easily reserialize this description such that the syntax becomes ambiguous. For example, it is perfectly correct to pull the following out of the conjunction: <owl:Class rdf:about="#Manager">
<owl:modality>K</owl:modality> </owl:Class>
And place it in the top-level. In its place in the conjunction, we can substitute <owl:Class rdf:about="#Manager">. While this is a valid serialization, our assertion now lost its proper structure. With this change, our assertion simply becomes hbob : M anager u KP ersoni. This is not the behavior we wanted; we only meant to apply K to the class M anager in the first conjunction, and not in general.
With all these complications, remember that we haven’t mentioned more sophisticated use of K. We have not considered the use of the operator in existential and universal role restrictions, such as ∃KR.C or ∀R.KC, for example. Even if we adopt the first approach and ignore its severe drawbacks, it is clear that such a syntax is not going to be human-readable. 4
We have implemented the ALCK language as an extension to the tableau-based
OWL-DL reasoner Pellet. In addition to the K queries outlined above, we also
admit a restricted use of K in the terminology, in the form of an epistemic rule.
An epistemic rule is of the form of KC v D where C and D are ALC concepts.
Frustrated with the failure to come up with an OWL syntax extension, we have
extended the KRSS format to allow for K and epistemic rules. The extension is
trivial and is described in [
Our examples focused on the use of K in queries posed to a first-order (ALC)
knowledge base. Extending more expressive description logics with this
functionality (including epistemic rules) is easy. Other useful features of nonmonotonic
logics, like default rules, can be formalized by admitting K freely in the
terminology, and by adding another epistemic operator, A, to the language (see [