- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Wed, 3 Oct 2007 15:35:10 +0100
- To: ewallace@cme.nist.gov
- Cc: public-owl-dev@w3.org
On 3 Oct 2007, at 14:40, ewallace@cme.nist.gov wrote: > Back to the using keys with OWL discussion: Thanks! > Bijan, > > I infer from what you wrote and a quick look at the > poster that you have concluded that keys as integrity > constraints with OWL are problematic. More precisely, we can't express that as a straightforward combination of OWL and DL-Safe rules, or restrictions there of. So we are postponing that bit. We can handle having max 1 explicit key easily enough. > Can you elaborate > on this in a fashion that a non-logician might understand? The simplest explanation is that integrity constraints involve a non first order feature (i.e., axioms as "checks" rather than inference generating things). Proper integrity constraints entail *contradictions* if you violate them. We probably can do something close (he says, riskily)... So, consider: bob hasID 5. mary: some.hasID. So bob has an id which is 5, mary has an id but we don't know it. If we had dl safe rules with safety constraints on datatype atoms, then we could have something like: hasID(?X, ?V) -> Good(?X). We could maybe negate it for bad ~hasId(?X, ?V) -> Bad(?X). Thus far, bob would get into Good and mary would...I think...get into bad. You could then make Bad unsatisfiable....Hrm. I'm feeling a bit dim right now. That negation worries me a tad, but perhaps pointlessly. Oh, duh, Mary wouldn't get into Bad. Because there is no corresponding negated triple with explicit values in it. In other words, consider: bob hasID 5. mary: some.hasID. mary ~hasId 6. This is still consistent, and would get mary into bad. but then so would: bob hasID 5. mary hasID 7. mary ~hasID 6. Which isn't what we want! (sorry about the brain fart above). So, basically, our inclination is to punt a bit on the integrity constraint semantics for the first round and hope to incorporate it in a more general solution. Or, if that doesn't seem feasible after a while, we can try to add the semantics to our extended syntax directly. The point of this first proposal is to get the simplest and straighforwardest highly useful bit to production quality as soon as possible. Cheers, Bijan.
Received on Wednesday, 3 October 2007 14:33:57 UTC