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

Re: OWL, XML-RDF and Imports

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Sun, 16 Feb 2003 09:35:45 -0500 (EST)
Message-Id: <20030216.093545.133826248.pfps@research.bell-labs.com>
To: seanb@cs.man.ac.uk
Cc: www-webont-wg@w3.org

From: Sean Bechhofer <seanb@cs.man.ac.uk>
Subject: OWL, XML-RDF and Imports
Date: Fri, 14 Feb 2003 16:58:43 +0000 (GMT Standard Time)

[...]

> So let's take a couple of little examples.
> 
> Ex 1)
> -----
> 
> Ontology A contains the triples:
> -------------------------------
> A owl:imports B
> x rdf:type owl:Thing
> p rdf:type owl:ObjectProperty
> x p y
> -------------------------------
> 
> Ontology B
> -------------------------------
> B owl:imports A
> y rdf:type owl:Thing
> p rdf:type owl:ObjectProperty
> x p y
> -------------------------------
> 
> Now in this case (according to my reading of the rules), A and B are both
> OWL-Lite ontologies as everything's nicely typed. 

This is an odd case, as A and B import each other.  This means that it is
difficult to consider them independantly.

> But when taken
> independently (ignoring the imports), they're Full. 

If you remove the imports from each of them they each are not in DL, yes.

> Referring back to my
> earlier message, this can further complicate the situation when we're
> trying to parse as we can't really parse/process the ontologies
> independently. So this isn't a complete disaster, but means that it's less
> obvious that it might be how we process these things.

I agree that circular imports patterns make life more difficult.


> Ex 2)
> -----
> 
> Similar to 1), but with the added complication that new we're spreading
> the well-formedness of a single expression through two ontologies
> 
> Ontology A
> -------------------------------
> A owl:imports B
> p rdf:type owl:ObjectProperty
> C rdf:type owl:Class
> D rdf:type owl:Class
> C rdfs:subClassOf R
> R rdf:type owl:Restriction
> R owl:onProperty p
> -------------------------------
> 
> Ontology B
> -------------------------------
> R owl:allValuesFrom D
> -------------------------------

Here there is no circular imports, so the situation is quite different.

> In this case, A (disregarding the import) has a malformed restriction, and
> is thus certainly not in Lite or DL (and may not even be in Full, but I'm
> not entirely sure about that as yet). 

A is in Full, as is B.  Full allows for all sorts of malformed junk.

> With the import, it's Lite. However,
> B is always "broken".

B is definitely not in Lite or DL, as it has malformed junk.

> So we've got a situation where a Lite ontology can import an arbitrary RDF
> document and still be in Lite.

Well, A without the imports is definitely not in Lite, and should not be.

> I'd argue that this is now getting confusing, and the above (trivial)
> examples suggest that imports as it stands isn't really sufficient for
> supporting modularisation.

I agree that this it a situation that we should not support.

The issue here, I think, is whether deficiencies in a document can be made
up by imported documents.

> For example, if I'm building an editor that wants to be able to support
> modularisation and maintain information in a sensible fashion, situations
> like 2) above are really going to confuse it. Somewhere I want to be able
> to record the fact that C is a subclass of (some p D), but where is this
> information actually held? In A? In B? If I'm ever going to have any
> chance of round tripping this stuff I'm going to have to keep a whole load
> of information hanging around. The split across the two ontologies is too
> fine-grained -- at the level of triples rather than actual conceptual
> "chunks" of the ontology. 

I agree that having triples be the indivisible parts of the syntax is a bad
thing.  I believe that my feelings about triples are well known.

> At this point, I won't hide the fact that this
> aspect is one of the things that I *do* really dislike about the use of
> RDF-XML for representing languages like OWL: the conflation of machinery
> for representing underlying syntax and the language primitives themselves,
> which then allows me to do this kind of thing. With reference to my
> earlier analogy in [2], the matchsticks are now split up into two
> different boxes and you've got to try and determine whether the
> observation deck is in Box A.



> A Proposal
> ==========
> 
> A possible solution would be to place further restrictions on the allowed
> triples in an RDF-XML representation of an OWL ontology. For example, we
> could require that all the conditions regarding the typing of URI refs and
> well-formedness are "locally enforced", i.e. all the necessary bits are
> present even when disregarding the imports statements.

I agree with this sentiment.  

> This seems to be a sensible thing to do -- If I'm going to use a
> Class|Property|Individual from some imported ontology, I should really
> know what it is before I use it, so requiring that I explicitly state that
> I know its type is no great hardship, and may then allow me to work
> independently with the modules, even when the imports are not available.
> In Ex 2, I can't really do much at all with A if B is not available (say
> I'm editing my ontologies off-line somewhere). Allowing me to effectively
> split the syntax of individual expressions across multiple locations (as
> is done in Ex 2.) seems to me to be far too lax, and I have difficulty
> seeing why one might want to allow this.

Your proposal is the very strong version of this idea.  You want to state,
essentially, that an RDF document is only in OWL DL ontology form if 
1/ its triples form the translation of a single OWL ontology that 
   a/ separates the vocabulary appropriately, 
   b/ provides a type for every individualID, and
   c/ doesn't use prohibited vocabulary
  and
2/ all imported documents are also in OWL DL ontology form,
3/ the imports closure of the document separates the vocabulary
   appropriately. 

I would support this proposal, even though it requires that each document
type all the individual names it mentions.  I would also support a version
that weakens 1c by only requiring it for the imports closure as a whole.
In fact, I would prefer an even weaker version where individualIDs need not
be typed at all.  

> My guess is that even if something along these lines is not present, tools
> will by default enforce some kind of similar conditions. Without it, it's
> near impossible to guarantee that you can work with the [documents?]
> independently (which will be, in my opinion, a requirement of tools).

I agree.

> Cheers,
> 
> 	   Sean
> 
> [1] http://www-db.research.bell-labs.com/user/pfps/owl/semantics/semantics-all.html#4.1
> [2] http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0206.html

peter
Received on Sunday, 16 February 2003 09:35:55 GMT

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