Re: RDFS compatibility information in OWL-DL documents

On Apr 18, 2007, at 9:06 PM, Xiaoshu Wang wrote:
[snip]

> I think RDF has a different "import/include" model than the OWL has  
> in mind.  I guess RDF people thought of a "follow your nose" kind  
> of model.  In other words, if a URI is mentioned in an RDF  
> document, all RDF triples resided in the mentioned URI should be  
> included in the RDF model.

This is not, in any way, part of RDF. Some toolkits, pre RDF Core and  
OWL did this as a matter of course, and there are some toolkits, now,  
which do that optionally, and there are, of course, spiders, but  
spiders make use of various sorts of vocabulary in an application  
dependent manner (see foaf and seeAlso).

These behaviors are *un*standardized and, thus, not part of standard  
RDF. There is also no widespread agreement *other than* that, aside  
from owl:imports, that graph merging/spidering is application  
dependent behavior with a bias toward keeping things separate.

> If you cannot find a triple to mention the URIs you would liked to  
> "import/include", then you use rdfs:isDefinedBy.  This is what I  
> guessed, because there is no official documentation about it.

Without official documentation, there is no standardized behavior.  
There is application dependent and, in my experience, not  
particularly common.

> On the other hand, OWL does not take the "follow your nose" model.   
> Hence, it then created a tag of owl:imports.  This seems creating a  
> confusion, at least to me.  First, what if a URI is mentioned but  
> its ontology is not imported?

The meaning of a term with respect to an owl document is given by the  
axioms in the imports closure of that document and nothing else  
(except for certain terms which have fixed or application dependent  
meaning; e.g., see user defined datatypes). Thus, a URI in one  
document can be the name of a satisfiable class in one owl documetn  
and an unsatisfiable class in another. A URI can name an  
unsatisfiable class in the union of two owl documents but not in  
either alone.

>   Second, the domain of owl:imports is constrained to be  
> owl:Ontology only.  Since OWL is considered a vocabulary extension  
> of RDF, and if we take the "follow your nose" approach and accept  
> the "rdfs:isDefinedBy", I am not sure if the owl:imports is any  
> useful.

Most ontology engineers that I know do not want to take a follow your  
nose approach. I certainly don't. We had quite the dust up about it a  
few years back. Try searching for "strong ontological closure", or see:
	<http://www.cs.bell-labs.com/cm/cs/who/pfps/publications/meaning- 
long.ps>

However, an unspecified idiosyncratic property of RDF most certainly  
does not trump a reasonably specified, compatibly implemented feature  
like owl:imports. You may *prefer*, and reasonably so, your model,  
but I think from the perspective of current *standards* you are  
incorrect and current *practice*, in the minority (for some value of  
minority :))

As an analogy, consider the difference between how a web browser  
treats hrefed uris and how a web spider does. Compare with how uris  
in <img src= works. Compare with uris in namespaces in XHTML documents.

> The problem, I think, is to have a clearly defined processing  
> specification about  the treatment of URI is an RDF model. If you  
> need "to/or not to follow the nose" and when.  Without such a  
> clarification, adding new term will only create more confusion.

I think the case for well specified, controlled combination of  
documents is pretty darn strong. Indeed, I'd prefer to include *in  
the language* fairly conservative mechanisms. For me, this means  
avoiding random or excessive inclusion.

As for Alan's proposal for conditional inclusion, it seems quite  
reasonable to me at first blush. One might go for a more generalized  
mechanism, or just reuse owl:imports with some discipline about  
generating the appropriate conditional documents. The latter is most  
compatible with extant tools. However, it's not unreasonable to want  
to explore more convenient mechanisms for future standardization.

Cheers,
Bijan.

Received on Wednesday, 18 April 2007 20:38:19 UTC