W3C home > Mailing lists > Public > www-webont-wg@w3.org > May 2003

Proposed response regarding imports issue

From: Jeff Heflin <heflin@cse.lehigh.edu>
Date: Wed, 28 May 2003 09:48:16 -0400
Message-ID: <3ED4BE20.FD6957A2@cse.lehigh.edu>
To: WebOnt <www-webont-wg@w3.org>

The following is a proposed response to Dave Becket regarding the issue
with imports raised in:

http://lists.w3.org/Archives/Public/public-webont-comments/2003May/0056.html

Note, this includes proposed text for S&AS, as discussed earlier on the
mailing list.

Dear Dave,

Thank you for you comment. As the original issue owner for imports, I
have been asked to respond on this issue to you.

You say:

> Firstly it seems that owl:imports potentially will import the entire
> semantic web of OWL Ontologies.  Have you considered the security and
> denial-of-service implications of this mechanism?

It may be true that the imports closure of some documents will be very
large. However, it should be smaller than the set of documents found by
following all the URIs in each document, and certainly smaller than the
entire Web itself. Still the result may be so large that applications
may have to give up after a certain point and like search engines which
don't truly cover the whole Web, admit that they only provide partial
results. In my message to Jennifer Golbeck, I proposed adding the
following text to Reference to make it clear that not every OWL tool
needed to load every ontology:

"Note that whether or not an OWL tool must load an imported ontology
depends on the purpose of the tool. If the tool is a complete reasoner
(including complete consistency checkers) then it must load all of the
imported ontologies. Other tools, such as simple editors and incomplete
reasoners, may choose to load only some or even none of the imported
ontologies."

I assume by denial-of-service implications you are imagining a scenario
where someone creates an ontology or set of ontologies that imports a
target some large number of times, causing any application that loads
the ontology to "attack" the target. Note that an application gains no
benefit from reloading an ontology, so it is expected that efficient
applications will cache their ontologies and only load the target a
single time, severely hampering any attempt at denial-of-service via the
imports mechanism.

You also comment:

> Secondly, is not clear at what stage that this (Imports Closure
> http://www.w3.org/TR/2003/WD-owl-semantics-20030331/rdfs.html#5.3 )
> should be done.  In an example where you have some RDF/XML that will
> map to RDF triples describing an OWL ontology, what are the steps
> that you expect to happen?

There was a minor ommision in 5.3 that explains how imports relates to
entailment. The last definition should say that K and Q are
imports-closed. I propose to change it to:

"Definitions: Let K and Q be imports-closed collections of RDF graphs.
Then K OWL Full entails Q whenever every OWL Full interpretation (of any
vocabulary V that includes the RDF and RDFS vocabularies and the OWL
vocabulary that satisfies all the RDF graphs in K also satisfies all the
RDF graphs in Q. K is OWL Full consistent if there is some OWL Full
interpretation that satisfies all the RDF graphs in K."

There would also be a similar change in section 5.4 for OWL DL.

Note that these changes mean that in order to compute entailment, you
must first compute the import closure (as defined earlier in Section
5.3). As I
mentioned before not every tool needs to process imports. For those
that do, a straight-forward approach is to recursively load the
documents imported by each document you load and then execute any
reasoning. However, it is not the purpose of the Semantics
document to mandate a particular processing strategy.

As for your process point: The formal objection of Jim Hendler is given
in:

http://lists.w3.org/Archives/Public/www-webont-wg/2003Mar/0281.html

I do not believe Dan Connolly has written a formal objection.

Thank you again for you comment. Please let me know if I have adequately
addressed your concerns.

Jeff
Received on Wednesday, 28 May 2003 12:42:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:00 GMT