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: Wed, 05 Jan 2005 07:47:44 -0500 (EST)
Message-Id: <20050105.074744.131187857.pfps@research.bell-labs.com>
To: jeen@aduna.biz
Cc: jos.deroo@agfa.com, www-rdf-logic@w3.org

From: Jeen Broekstra <jeen@aduna.biz>
Subject: Re: RDF as a syntax for OWL (was Re: same-syntax extensions to RDF)
Date: Wed, 05 Jan 2005 10:21:36 +0100

> Peter F. Patel-Schneider wrote:
> 
> > I am trying to determine just what is being demonstrated here.
> > 
> > Are you saying that you find it easy to build a complete parser
> > (i.e., translator) for OWL in RDF/XML?  Are you saying that you
> > find it easy to build an incomplete parser for OWL in RDF/XML?  Are
> > you saying that you find it easy to build a species validator for
> > OWL in RDF/XML?
> 
> I am somewhat hesitant to enter into this debate as I personally have
> not as much experience with handling OWL data as you and Bijan 
> probably have, but the one thing that haunts me in this is that you 
> both seem to insist on *parsing* OWL in RDF/XML. And I can't help but 
> wonder if abandoning this approach for validation in favor of 
> *querying* (or using rules, for all I care) for 'well-formedness' 
> would make everything a bit easier.

Well, strangely enough, this is just about exactly what my owl.ml code
does.  Other parts of the code transform RDF/XML into an internal RDF graph
structure - owl.ml, in essence, "queries" this RDF graph.  However, there
are lots and lots of "queries" that have to be performed and combined in a
particular fashion, resulting in quite complex code.

> Perhaps I don't understand the parameters of the task at hand too
> well, but I also have the feeling that perhaps you are not applying
> the right tools to the job. Your quoted figures for an OWL parser from 
> RDF/XML seem to assume a DOM structure but no RDF toolkit, i.e. you 
> are directly trying to construct OWL from the XML syntax (you mention 
> a 'nice internal data structure' but a graph data structure is not the 
> same as an RDF toolkit).

Well, of course, if there was a toolkit that transformed RDF/XML into an
RDF graph, that would remove the need for rdfxml.ml, which does precisely
this.  However, beyond this particular task, I do no believe that an RDF
toolkit would help much, if at all.  Almost all of the owl.ml code is
concerned with actual recognition of OWL syntax.  For example, the code to
search for particular triples is

	let find2 s p g = 
	  Graph.filter (function(Triple(ts,tp,tb))-> s=ts && (NUriref p)=tp) g
	let find2r o p g = 
	  Graph.filter (function(Triple(ts,tp,tb))-> o=tb && (NUriref p)=tp) g
	let find3 s p o g = Graph.mem (Triple(s,(NUriref p),o)) g

What more could an RDF toolkit do for this task?

> My hunch is that actually _using_ the triples through an RDF API/query 
> language instead of trying to bypass it will make life easier (and no, 
> I'm not claiming that it is trivial or very easy, I merely have the 
> impression that it is not as fiendishly difficult as you make it out 
> to be).

Yes, sure, it would eliminate the need for rdfxml.ml.  However, as
indicated above, I doubt that it would help beyond that.


> To take Bijan's example of checking that a class expression such as:
> 
>      <owl:Restriction>
>          <owl:onProperty rdf:resource="P"/>
>          <owl:someValuesFrom rdf:resource="C"/>
>      </owl:restriction>
> 
> is 'well-formed', i.e. is exactly formulated as such and has no extra
> or missing triples, is simply a matter of doing some queries.
> 
> construct distinct *
> from {R} rdf:type {owl:Restriction};
>           owl:onProperty {Prop};
>           owl:someValuesFrom {Val}
> 
> retrieves a subgraph that you can check (using any RDF toolkit's
> utility methods) quite easily for the existence/omission of triples.

Umm, I don't believe that this would provide any benefit at all.  First,
this would not retrieve any OWL DL-illegal triples, and thus would not be
useful for species validation.  Second, you are still left with a graph
that would have to be processed in exactly the same way as the entire RDF
graph would have to be.  For example, how would this make checking for
missing bits any easier to program?  (Yes, because the graph might be
significantly smaller it might be faster to check, but I don't think that
it would be any easier to check.)

> Granted, many query languages in the current set of RDF tools perhaps
> still miss the expressiveness to make this as painless as it might be 
> (I'm thinking of explicit support for containers and collections, 
> here, which many tools still miss, and aggregation functions such as 
> count(), min(), etc.), but I still have the feeling this would be a 
> good approach.

> If you have experience to the contrary, it would be interesting to 
> learn at what point you found the RDF toolkit/API/query language that 
> you worked with lacking.

Well, given that there are, to my knowledge, no RDF toolkits/APIs/query
languages for any variety of ML, I have not used them.  

> Jeen
> -- 
> Jeen Broekstra          Aduna BV
> Knowledge Engineer      Julianaplein 14b, 3817 CS Amersfoort
> http://aduna.biz        The Netherlands
> tel. +31(0)33 46599877  fax. +31(0)33 46599877


Peter F. Patel-Schneider
Bell Labs Research
Received on Wednesday, 5 January 2005 12:48:00 UTC

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