W3C home > Mailing lists > Public > public-owl-comments@w3.org > February 2009

Please define import closure of an ontology *document*

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 24 Feb 2009 08:42:12 -0500
Message-Id: <33D99B64-B41F-4D16-B444-252D91D2B172@creativecommons.org>
To: public-owl-comments@w3.org
Re: http://www.w3.org/TR/2008/WD-owl2-syntax-20081202/

I would like to suggest that sections 3.4 and 3.6 would be simplified
if you defined the notion of the import closure of an ontology
*document* instead of, or in addition to, the import closure of an

The problem you're faced with is that in order to know which ontology
(in the structural specification sense) you're talking about, you need
to know the types of all IRIs occurring in its ontology document,
which in general will require knowing the ontology's import closure.
This is circular, since import closure is defined on the structural
specification, so the closure that you seek in order to specify the
ontology is a function of the ontology that you wish to specify.  In
practice this isn't a problem since the closure computation uses only
a "part" of the ontology that doesn't depend on the closure, but
editorially and formally this is rather messy.

You have tried to finesse this through the operational notion of
"canonical parsing" which specifies an incremental procedure for
processing ontology documents and "constructing" ontologies, resulting
in what looks like a complicated fixed-point computation.  Operational
accounts are harder to understand and prove things about that
declarative ones, so I think it's worth some effort to look for a
declarative account.

Canonical parsing amounts to the following:

   directImports(OD) = ontology documents directly imported by OD
   importClosure(OD) = ontology documents directly or indirectly  
imported by OD
     (transitive closure of directImports)
   decls(OD) = declarations provided by OD (table 9)
   allDecls(importClosure(OD)) = union of decls(OD2)
      for OD2 in importClosure(OD)
   structuralSpec(OD, allDecls(importClosure(OD)))
     = ontology resulting from parsing OD  (if well-formed)

Once you know the ontology, its direct imports may be read off
directly, and its import closure (ontologies, not ontology documents
come from the direct imports relation by transitive closure.  Of
course you have little need to know the import closure of an ontology
because by definition of 'ontology', the ontology already knows how  
all its IRIs
are declared.  The only thing the import closure is good for now is to
determine which ontologies to combine in order to build a theory to be
modeled in one of the model theories.

I think I am only suggesting an editorial change to canonical parsing
3.6 and imports 3.4.  Instead of the algorithm-like description of
canonical parsing, there would be a few definitions similar to the
above.  Instead of talking about "steps" and "creating an Ontology"
(which to me makes no sense since I understand Ontology as a
mathematical abstraction, not a data structure in a computer), one
simply says that the directImports (directlyImportsDocument) relation
on ontology documents is determined "using the rules of the relevant
syntax" (quoting 3.6), and that decls(OD) is "the set of all
declarations listed in Table 9" (presumably also determined by knowing
the relevant syntax).  The rest is specified by building the process
using composition as above and transitive closure.

The paragraph "From a physical point of view" in 3.4, which right now
is almost impenetrable, can be made much more lucid if it is able to
make reference to the import closure of the document.  "directly
imported ontologies" makes no sense if you don't know which ontology
(SS), but is perfectly fine if replaced by "directly imported ontology

Besides cleaning up the presentation, this rework would, I believe,
clarify the relations between the various surface syntaxes and the
structural specification, and make the data dependencies of OWL
processes more explicit, which in turn would smooth the way to the
creation of novel implementation methods and surface syntaxes.

I would be happy to work with you on the prose if you agree that this
might lead to an improvement (as I do).

Received on Tuesday, 24 February 2009 13:42:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:01:29 UTC