W3C home > Mailing lists > Public > www-rdf-logic@w3.org > January 2005

Re: RDF as a syntax for OWL

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Thu, 06 Jan 2005 07:34:17 -0500 (EST)
Message-Id: <20050106.073417.91774838.pfps@research.bell-labs.com>
To: geoff@sover.net
Cc: bparsia@isr.umd.edu, www-rdf-logic@w3.org


From: "Geoff Chappell" <geoff@sover.net>
Subject: RE: RDF as a syntax for OWL (was Re: same-syntax extensions to RDF)
Date: Wed, 5 Jan 2005 22:07:52 -0500

> > -----Original Message-----
> > From: www-rdf-logic-request@w3.org [mailto:www-rdf-logic-request@w3.org]
> > On Behalf Of Bijan Parsia
> > Sent: Wednesday, January 05, 2005 10:28 AM
> > To: www-rdf-logic@w3.org
> > Subject: Re: RDF as a syntax for OWL (was Re: same-syntax extensions to
> > RDF)
> > 
> [...]
> > 
> > Jos, I have a way way easier challenge: do the negation normal form
> > transformation
> > 
> > Specification: Given an input graph, produce an output graph such that
> > all negations appear only on class names in a class expression.
> > 
> > Actually, let's make it even easier! Only for ALC
> > 
> > I'll even give the rules:
> > 	I'll use ~ for not (complementOf)
> > 		& for conjunction (intersectionOf)
> > 		v for disjunction (unionOf)
> > 		some for existential quantification (someValuesFrom)
> > 		all for universal quantification (allValuesFrom)
> > 	I'll use fairly normal infixy syntax. I'll happily convert to
> > something else.
> > 
> > 	For (compound) class expressions C and D
> > 		nnf(~~C)) => nnf(C)
> > 		nnf(~(C & D)) => nnf(~C) v nnf(~D)
> > 		nnf(~(C v D)) => nnf(~C) & nnf(~D)
> > 		nnf(~some(P, C)) => all(P, nnf(C))
> > 		nnf(~all(P, C)) => some(P, nnf(C))
> > 
> > 	Base case: for atomic class name C
> > 		nnf(C) => C
> > 		nnf(~C) => ~C
> > 
> > That's almost the prolog program :)

Almost, but not nearly.  The above is a specification of the
transformations that need be done to transform to NNF.  It doesn't (except
for the base case) give the identity transforms.

> > I'll accept the binary restriction on & and v.
> > 
> > To make it easier, I'll allow for the class expressions to be isolated
> > (i.e., not part of an axiom), if that helps.
> > 
> > I believe this exercise will be illuminating to anyone who tries it.
> 
> Given the challenge, I had to give it a try in RDF Gateway's rule language
> ;-) The results don't really rebut the ugliness claim, but do demonstrate
> that it's doable in at least one of the available frameworks. BTW, I'm not
> denying this was a bit of a pain, nor in any way trying to be an advocate
> for the forcing of fol into rdf syntax.
> 
> I ended up with rulebase below. With it I could convert a graph to nnf form
> with a few lines - e.g:
> 
>   var ds = new datasource("inet?parsetype=auto&url=c:/kill/nnftest.rdf");
> 
>   select ?p ?s ?o using #ds rulebase nnf where {[rdf:type] ?c [owl:Class]}
> and nnf(?c ?p ?s ?o);
> 
> The rules may not be 100% though I tested them with a decent number of cases
> (but no pathological ones). 

[Much of the rulebase has been removed.]

> rulebase nnf
> {
> 	infer nnf(?cin, ?p, ?s, ?o) from nnf_pos(?cin, ?cout, ?p, ?s, ?o);
> 
> 	infer nnf_pos(?cin, ?cout, ?p, ?s, ?o) from isAnon(?cin)
> 		and {[owl:complementOf] ?cin ?x}
> 		and nnf_neg(?x, ?cout, ?p, ?s, ?o);
> 
> 	//	nnf(~~C)) => nnf(C)
> 	infer nnf_neg(?cin, ?cout, ?p, ?s, ?o) from isAnon(?cin)
> 		and {[owl:complementOf] ?cin ?x}
> 		and nnf_pos(?y, ?cout, ?p, ?s, ?o);
			    ^^ Typo?  

> 	//	nnf(C) => C
> 	infer nnf_pos(?cin, ?cout, ?p, ?s, ?o) from instr(?cin, 'guid') <> 0
> 			and
> 		?cout=?cin and ?s=?cin and {?p ?s ?o};

[I've left in the nnf_pos stuff.]

> Rgds,
> 
> Geoff Chappell

Questions:

1/ With the typo, it appears that your code done't work right for double
   negation.  Is this correct?

2/ Without the identify transforms, it appears that your code won't work
   for C & D.  Is this correct?

3/ How will your code handle

	_:x rdf:type owl:Restriction .
	ex:p1 rdf:type owl:ObjectProperty .
	ex:c1 rdf:type owl:Class .
	_:x owl:onProperty ex:p1 .
	-:x owl:someValuesFrom ex:c1 .
	_:x owl:allValuesFrom ex:c1 .
	

4/ How will your code handle

	_:x rdf:type owl:Restriction .
	_:z rdf:type owl:Restriction .
	_:y rdf:type owl:Class .
	owl:intersectionOf _:x _:li .
	_:li rdf:type rdf:List .
	_:li rdf:first _:y .
	_:li rdf:rest _:li2 .
	_:li rdf:type rdf:List .
	_:li2 rdf:first _:z .
	_:li2 rdf:rest rdf:nil .
	_:y owl:complementOf _:z .
	_:z owl:onProperty ex:p1 .
	_:z owl:someValuesFrom ex:c1 .

5/ How will your code handle

	_:x rdf:type owl:Class .
	owl:complementOf _:x _:x .

6/ How will your code handle

	_:x rdf:type owl:Class .
	ex:p1 rdf:type owl:Restriction .
	ex:r1 rdf:type owl:Restriction .
	_:x owl:onProperty ex:p1 .
	-:x owl:someValuesFrom ex:r1 .
	ex:r1 owl:onProperty ex:p1 .
	ex:r1 owl:someValuesFrom ex:c1 .

Yes, I may have made the challenge harder than Bijan may have meant it, but
these are the sorts of things that you do run into when you use an
unconstrained graph formalism for your syntax.


Peter F. Patel-Schneider
Received on Thursday, 6 January 2005 12:34:47 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:43 UTC