Guide Comments: Suggested response w/ question

Proposed response to Karl Dubost

NOTE:  There is a conflict between what I say in the Guide about 
<owl:Ontology rdf:about=""> and what the SAS says.

Guide:

 Where the value of the attribute is "", the standard case, 
 the name of the ontology is the base URI of the owl:Ontology 
 element.

SAS:

 The name of an ontology is thus the URI where it would be found.

The SAS is simpler.  If we use the Guide terminology, the "base URI"
can be modified by the presence of xml:base.  Which is correct?
Nowhere do we require that xml:base be tied to the document URI,
though this is the intent.  We suggest it.

- Mike

--------------------------------------------------------------------

Karl,

Thanks for your comments. In this message I have tried
to either answer your questions or propose an editorial change 
that I think addresses them.

> * In the guide document on OWL, you have written :
> 
> >     The rdf:about attribute provides a name or reference for the
> >ontology. Where the value of the attribute is "", the standard case, 
> >the name of the ontology is the base URI of the owl:Ontology 
> >element. Typically, this is the URI of the document containing the 
> >ontology. An exception to this is a context that makes use of 
> >xml:base which may set the base URI for an element to something 
> >other than the URI of the current document.
> 
> What's happening in case of conflicts between xml:base and rdf:about?

Getting all of the mirrors aligned with entities, namespaces, xml:base
and references has been tricky.  But in this case there is no
conflict.  If rdf:about is explicitly given a value, that is what it
is.  If the attribute value is "", then it is interpreted to be the
base URI of the owl:Ontology element.  Which can be set by xml:base.

> * You said
> 
> >	Tools will respond to this situation in an implementation
> >defined manner.
> 
> Free to implementations is dangerous and leads to lack of 
> interoperability. You should define what the implementation should do 
> in this case. Return of a code, etc.

Agreed that this is undesirable.  That said, there are reasons we
left this unspecified.

The formal syntax and semantics describe what well formed OWL
documents look like and how they are interpreted.  It is much harder
to specify what happens operationaly if there is a failure of the
supporting infrastructure.  Our general view was that there should at
a minimum be some way to detect failures, but we did not see clearly
how to add such a mechanism to OWL.

Consider cases of extensive, distributed ontologies, where the
inability to import a few ancillary facts would ideally not bring all
reasoning to a halt.  Additionally, one of the target consumers of OWL
ontologies are autonomous processes.  How they proceed in the face of
failure to download an ontology component is an open topic.


Please reply to the mailing list as to whether the above changes 
adequately address your comments.


- Mike

Michael K. Smith, Ph.D., P.E.
EDS - Austin Innovation Centre
98 San Jacinto, #500
Austin, TX  78701

phone: +01-512-404-6683
email: michael.smith@eds.com

Received on Thursday, 1 May 2003 11:17:32 UTC