W3C home > Mailing lists > Public > public-owl-dev@w3.org > October to December 2007

Re: [TF:DbE] The easiest keys there are

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 3 Oct 2007 15:35:10 +0100
Message-Id: <A22DC5B8-0E23-411F-BE56-A343DDE17BA7@cs.man.ac.uk>
Cc: public-owl-dev@w3.org
To: ewallace@cme.nist.gov

On 3 Oct 2007, at 14:40, ewallace@cme.nist.gov wrote:

> Back to the using keys with OWL discussion:


> 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  

	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  

Received on Wednesday, 3 October 2007 14:33:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:58:15 UTC