Proposed reply to http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0029.html

I propose the following reply and changes to partly address
http://lists.w3.org/Archives/Public/public-webont-comments/2003Apr/0029.html
from Jeff Pan.  As stated in the response, final resolution awaits the
final version of RDF datatyping, which is not yet in a form that is usable
in OWL. 

peter


Again, thank you for your comments.   In this message I propose some
editorial and tyopgraphical changes that I think might help to address
some of them.  The remainder will be handled later, as indicated in the message.

> 1. Section 2
> 
> Section 2 claims that OWL uses some of the facilities of XML Schema, and some
> built-in XML Schema datatypes can be used in OWL. It is not clear, however,
> whether the derived datatypes based on the above supported XML Schema datatypes
> can be used in OWL or not. Reasons for why they can (or can't) be used in OWL are
> expected to be explained in section 2 as well.

Yes, this is not currently clear.  I propose to make the following
editorial addtion to the paragraph in Section 2 that talks about the usable
XML Schema datatypes:

	Because there is no reliable way to go from a URI reference to an
	XML Schema datatype in an XML Schema, user-defined XML Schema
	datatypes cannot be used in OWL.
 
> 2. Section 3
> 
> (1) In the definition of the formal syntax, rdf:type is treated as an annotation
> property as follows:
> 
> ER:VAP U {rdf:type} -> P(R*(R U LVT)),
> 
> while no explanation is made about why it is treated this way.

I propose to add

	(The property rdf:type is added to the annotation properties so as
	to provide a meaning for deprecation, see 
	<a href="direct.html#owl_DeprecatedClass_semantics">below</a>.)
after
	ER provides meaning for URI references that are used as
	OWL properties.
in Section 3.1.  

> (2) The description of the elements of VD is a bit confusing, along with the
> supported datatype described in section 2. Section 2 says a list of XML Schema
> datatypes can be used in OWL, ..., *and* OWL also uses rdfs:Literal and can use
> rdf:XMLLiteral. Section 3.1 says VD contains the URI references of the built-in
> OWL datatypes and rdfs:Literal. Thus it seems that rdfs:Literal and
> rdf:XMLLiteral are not built-in OWL datatypes, and rdf:XMLLiteral is not in VD
> (but can be in D of a datatype theory). Is that right?

This awaits a finalization of RDF datatyping.

> (3) In the definition of datatype theory, it is not clear that what kinds of
> datatypes can be in the set D. Does it contain only the built-in OWL datatypes,
> or also their derived datatypes? If it can only consist of built-in OWL
> datatypes, the datatype theory is quite limited and seems to me not enough in
> many cases.

I propose to clarify the situation by adding ``A datatype theory must
contain datatypes for xsd:string and xsd:integer.  It may contain datatypes
for the other built-in XML Schema datatypes that are suitable for use in
OWL.  It may also contain other datatypes, but there is no provision in the
OWL syntax for conveying what these datatypes are.'' to the definition of a
datatype theory.

Further resolution awaits a finalization of RDF datatyping.
 
> (4) In an abstract OWL interpretation, I think it might be easier to understand,
> if we present S in the following way:
> 
> S: VI -> R
> SA: VI U VC U VD U VDP U VIP U VAP U VO U {owl:DeprecatedClass,
> owl:DeprecatedProperty} -> R U LVT
> 
> so that we won't confuse ourselves S(i),the interpretation of an individual URI,
> and SA(i), some annotation of  an individual URI. Surely S can be further
> extended to plain literals and types literals. I believe separating
> interpretation and annotation is usually a good idea.

I believe that this separation would not work well.  Suppose S maps ex:a
and ex:b to the same domain element.  Then annotations on ex:a are also
annotations on ex:b.  Therefore SA would have to follow S for individual
names.  I do not propose to make any change here.
 
> (5) The expression EC(annotation(p1 o1)) seems to me a bit "annoying", partly
> because having annotation in interpretation is strange, partly because
> annotations don't seem to be natural elements of VC or VD.

I agree that it is a bit jarring to have EC defined on
annotations.  However, it makes the semantics go through much
better.   I propose to change to ``EC is extended to ... , values, and
pannotations....''  in Section 3.2 to clean up some related introductory
wording. 

> Jeff
> --
> Jeff Z. Pan  ( http://DL-Web.man.ac.uk/ )
> Computer Science Dept., The University of Manchester

Received on Monday, 14 April 2003 13:30:59 UTC