RE: RDF as a syntax for OWL

> -----Original Message-----
> From: Peter F. Patel-Schneider [mailto:pfps@research.bell-labs.com]
> Sent: Thursday, January 06, 2005 7:34 AM
> To: geoff@sover.net
> Cc: bparsia@isr.umd.edu; www-rdf-logic@w3.org
> Subject: Re: RDF as a syntax for OWL
> 
> 
> 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
 [...]
> 
> [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?

Yes, it's broken as is - a little pre-posting cleanup gone awry.
 
> 2/ Without the identify transforms, it appears that your code won't work
>    for C & D.  Is this correct?

Yes. I'm missing several identity transforms as you point out. 
 
> 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 .

As is, it will convert the complement of that restriction into two new
restrictions.

I suppose the right thing to do would be to flag the restriction as
malformed? If so, I imagine rules along the lines of these could be used:

infer {[rdf:type] ?r [ex:InvalidRestiction]} from 
	{[rdf:type] ?r [owl:Restriction]} 
	and not {[owl:onProperty] ?r ?p};

infer {[rdf:type] ?r [ex:InvalidRestiction]} from 
	{[rdf:type] ?r [owl:Restriction]} 
	and {[owl:allValuesFrom] ?r ?x}
	and {[owl:someValuesFrom] ?r ?y};

etc.

Then depending upon the needs of the graph consumer, the whole graph could
be invalidated if it contains anything invalid or the particular invalid
restriction could just be ignored.

 
> 
> 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 .

It would likely do something wrong ;-)

What should it do? It seems to me it could reasonably toss it out as a
malformed restriction. I guess the difficulty is that the nnf rules must
obviously preserve meaning wrt to the system that's interpreting the result
graph... do all malformed restrictions have unambiguous meaning wrt owl
semantics? Do any?

> 5/ How will your code handle
> 
> 	_:x rdf:type owl:Class .
> 	owl:complementOf _:x _:x .

Do you mean this?

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

If so, nothing is emitted by the rules.

 
> 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 .

Is this another malformed example? If not, please highlight for me the
relevant part of this example.
 
> 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.
>

No disagreements here.

The smearing of higher-arity relations into triples is seemingly the source
of much pain when trying to use RDF as a syntax for other languages (due to
the fact that you can't really constrain the triples so that only valid and
complete instances of the relation can be represented). I'm not sure that
represents the same problem when using RDF to represent incomplete knowledge
(from one or more sources) - in fact it probably becomes a strength. 

> 
> Peter F. Patel-Schneider

Rdgs,

Geoff Chappell

Received on Thursday, 6 January 2005 16:51:02 UTC