LC3 Responses/DB6

To: daniel@fgm.com
CC: public-owl-comments@w3.org
Subject: [LC response] To Daniel Barclay

Dear Daniel,

Thank you for your comment
     <http://lists.w3.org/Archives/Public/public-owl-comments/2009Sep/0025.html>
on the OWL 2 Web Ontology Language last call drafts.

We agree that any ambiguity that may exist between UML and Functional Syntax is not problematical as they are in such close correspondence -- in fact the Functional Syntax can be thought of as a linear form of the UML.

Regarding possible ambiguity between the ontology-statement level and the level of the classes, individuals, etc., our experience suggests that the improved readability justifies any slight loss of precision. However, we will continue to look for ways to improve the editorial quality of the text, and in doing so we will certainly take your comment into consideration.

Please acknowledge receipt of this email to <mailto:public-owl-comments@w3.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

Regards,
Ian Horrocks
on behalf of the W3C OWL Working Group

CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.

PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL

> The structure of OWL ontologies is defined using UML. In the text, 
> Functional Syntax is used to refer to the UML structures. 

Where is the correspondence between the Functional Syntax and
the UML structures specified?

 > The purpose of
> the narrative explanations and examples is to provide informal and 
> intuitive explanations. 

If the correspondence between the Functional Syntax and the UML
structures is not defined elsewhere, then those "narrative"
explanations need to be normative definitions, don't they?
(Something does.)


(Actually, see the "** Ah--maybe that points out the problem ..." part
below.)


> This may sometimes involve relatively informal 
> use of the Functional Syntax, but we feel that this informality is 
> justified in making the document more approachable. 

It might seem more approachable at first glance, but the multiple
approximations in the wording actually make it much _harder_ to
follow--the reader has to disambiguate many terms even in a single
sentence.

If the text were a little more wordy but more accurate (e.g.,
"the class denoted by the class expression 'xxx( yy )' contains
individuals" rather than "the class expression 'xxx( yy )' contains
individuals"), then if one didn't understand a sentence the first
time, one could simply re-read it and pay attention to every wording
step along the way.

However, the way things are now, when you try to re-read things
_more_ carefully to tease out the intended meaning, you see more and
more  ambiguity, and can be _less_ and less sure about what each word
means and can be _less_ and less sure about what the specification
really meant to specify.



 > Those needing formal
> definitions can and should refer to the UML and to the "Complete 
> Grammar" Appendix [1].

But the Complete Grammar appendix specifies only the _syntax_ of the
Functional Syntax, and not its semantics--the correspondence to the
objects specified in UML.  If that appendix is the _only_ normative
definition of the Functional Syntax, then obviously something is
missing in the specification.



> We were aware of the possible confusion between UML classes/instances 
> and ontology classes/instances and were careful to ensure that we 
> explicitly say "UML Class" or "instance of UML Class" whenever we are 
> referring to the former. 

Doesn't your next paragraph (below) contradict that?  (You say (below)
that "class expression" in the quote from the spec refers to instances
of the UML class, but the quote from the spec shows that it does not
in fact explicitly say "UML Class" or "instance of UML Class.")


 > We now explicitly mention this, as well as
> clarifying some other issues related to the use of UML, in Section 2.1 
> [2]. To review these changes please refer to the relevant diff [3].
> 
> For example, when we say "An intersection class expression 
> ObjectIntersectionOf( CE(1) ... CE(n) ) contains all individuals that 
> are instances of all class expressions CE(i) for 1 ≤ i ≤ n", we are 
> referring to ontology class expressions (that is, instances of the UML 
> class ClassExpression), ...

That ("we are referring to ... instances of the UML class
ClassExpression") doesn't seem to be correct.  Consider the first
occurrence of "class expression" there--in what way can a class
expression contain individuals?

If that first "class expression" really does refer to an instance
of the (UML-specified) ClassExpression class, specifically, the
ObjectIntersectionOf class instance class specified by that quoted
syntax "ObjectIntersectionOf( CE(1) ... CE(n) )" then:

Such instances do _not_ contain individuals:

- The (UML-specified) ObjectIntersection class has no aggegration or
   composition relationship, or even any associations with, the
   (UML-specified) Individual class, so the (UML-level)
   ObjectIntersection class does not in any sense "contain" any
   UML-level individuals.

- Clearly, that _UML_-level class instance does not contain a
   _syntax_-level string or an _ontology_-level individual (an
   individual contained in the class described by the class
   expression).

Isn't it really the (ontology-level? logic-level?) _class_
represented by _class_expression_ (the (UML-level) ClassExpression
instance and/or the (syntax-level) ClassExpression non-terminal
instance) that _contains_ individuals?



** Ah--maybe that points out the problem more clearly:

It's _not_ the ambiguity between the level of the UML and the level
of the syntax (which closely follows the UML) that is the main
problem (and possibly that ambiguity isn't a problem, since the
syntax and the UML correspond closely).

The main problem is the ambiguity between the ontology-statement
level (i.e., the syntax, the UML classes, and the represented
axioms/etc.) and the level of the classes, individuals, etc.,
described by the ontology-statement level.

That's why "class expression ... contains individuals" doesn't
make sense:  A class expression describes/denotes/etc. a class, and
a class can contain individuals, but the class expression doesn't
contain any individuals.  Writing that one does causes confusion.





> [3] 
> http://www.w3.org/2007/OWL/wiki/index.php?title=Syntax&diff=25572&oldid=25485 
> 
> 
> Please acknowledge receipt of this email to 
> <mailto:public-owl-comments@w3.org> (replying to this email should 
> suffice). In your acknowledgment please let us know whether or not you 
> are satisfied with the working group's response to your comment.

I think* I agree with the changes reflect in the differences shown at
http://www.w3.org/2007/OWL/wiki/index.php?title=Syntax&diff=25572&oldid=25485

.
(* allowing for having misread the wording since I'm looking at it
with the HTML tags visible)

I think I'm (at least partially) satisfied regarding the ambiguity
between the syntax and UML levels.

I'm not yet satisfied regarding the ambiguity between the
UML level (syntax/UML/constructs) and the logic level (classes,
individuals, etc.).

To: daniel@fgm.com
CC: public-owl-comments@w3.org
Subject: [LC response] To Daniel Barclay

Dear Daniel,

Thank you for your comment
     <http://lists.w3.org/Archives/Public/public-owl-comments/2009Sep/0010.html>
on the OWL 2 Web Ontology Language last call drafts.

The structure of OWL ontologies is defined using UML. In the text, Functional Syntax is used to refer to the UML structures. The purpose of the narrative explanations and examples is to provide informal and intuitive explanations. This may sometimes involve relatively informal use of the Functional Syntax, but we feel that this informality is justified in making the document more approachable. Those needing formal definitions can and should refer to the UML and to the "Complete Grammar" Appendix [1].

We were aware of the possible confusion between UML classes/instances and ontology classes/instances and were careful to ensure that we explicitly say "UML Class" or "instance of UML Class" whenever we are referring to the former. We now explicitly mention this, as well as clarifying some other issues related to the use of UML, in Section 2.1 [2]. To review these changes please refer to the relevant diff [3].

For example, when we say "An intersection class expression ObjectIntersectionOf( CE(1) ... CE(n) ) contains all individuals that are instances of all class expressions CE(i) for 1 ≤ i ≤ n", we are referring to ontology class expressions (that is, instances of the UML class ClassExpression), and we are simply providing an informal explanation of the semantics of the intersection class expression.

[1] http://www.w3.org/2007/OWL/wiki/Syntax#Appendix:_Complete_Grammar_.28Normative.29

[2] http://www.w3.org/2007/OWL/wiki/Syntax#Structural_Specification

[3] http://www.w3.org/2007/OWL/wiki/index.php?title=Syntax&diff=25572&oldid=25485

Please acknowledge receipt of this email to <mailto:public-owl-comments@w3.org> (replying to this email should suffice). In your acknowledgment please let us know whether or not you are satisfied with the working group's response to your comment.

Regards,
Ian Horrocks
on behalf of the W3C OWL Working Group

CUT AND PASTE THE BODY OF THE MESSAGE (I.E. FROM "Dear" TO "Group") INTO THE BODY OF AN EMAIL MESSAGE. SET THE To:, CC:, AND Subject: LINES ACCORDINGLY.

PLEASE TRY TO REPLY IN A WAY THAT WILL ALLOW THREADING TO WORK APPROPRIATELY, I.E., SO THAT YOUR REPLY CONTINUES THE THREAD STARTED BY THE ORIGINAL COMMENT EMAIL

Summary:
1) The descriptions mapping syntactic elements to structural objects
    are ambiguous, using the same term to refer to different things.
    They should be more precise.
2) Some of that ambiguity is caused by the poor names of some
    non-terminals.  Those non-terminals should be renamed.


Section 8.1.1 says (with subscripts transcribed using parentheses):

   An intersection class expression ObjectIntersectionOf( CE(1)
   ... CE(n) ) contains all individuals that are instances of
   all class expressions CE(i) for 1 ≤ i ≤ n.

That wording conflates the syntactic elements and the objects that
those syntactic elements denote in multiple ways:

- In the first part of the sentence, CE(i) refers to class
   expressions strings matching the ClassExpression production), but
   after "instances of," CE(i) instead refers to the classes
   described or denoted by those class expressions.

- Similarly, in the very first part of the sentence, "class
   expression" refers to class expressions, but after "instance of,"
   it refers to classes.

- Even more confusingly, the first occurrence of "class expression"
   is used in _both_ ways:  As the subject of the sentence it refers
   to a class expression (the intersection class expression), but
   the verb ("contains") treats it as instead referring to the class
   described by the class expression.  (A class contains
   individuals; a class expression (a string) only contains other
   syntactic objects (e.g., the nested class expressions CE(i)).)

The specification should be considerably more precise than that.


Shouldn't section 8.1.1 say something like this (added words
highlighted)?:

   An intersection class expression ObjectIntersectionOf( CE(1)
   ... CE(n) ) _specifies_the_class_that contains all
   individuals that are instances of all _classes_specified_by_the_
   class expressions CE(i) for 1 ≤ i ≤ n.

Yes, that might sound a little wordy, but the additional--and more
_precise_--words make it much easier to understand what is being
specified.


Note that some other cases are even less clear.

Consider section 8.1.4., which says (again, transcribed using
parentheses):

   An enumeration of individuals ObjectOneOf( a(1) ... a(n) )
   contains exactly the individuals a(i) with 1 ≤ i ≤ n.

Notice how, to get the intended meaning, the reader has to
interpret the first occurrence of the word "individuals" as
referring to the strings matching the Individual production, but
then interpret the second occurrence as referring to the
individuals identified by those strings.

Otherwise, one can easily read that as saying, tautologically,
that an enumeration containing individuals a(1) ... a(n) contains
the individuals a(1) ... a(n).


The specification should not re-use terminology ambiguously like
that.   It should use different phrases to refer to the syntactic
elements vs. to the things denoted by the syntactic elements.
This is especially true because one of main things this OWL
specification is trying to specify is the mapping between the
syntax and its meaning (at the structural level).


This problem exists partly because some of the productions
(non-terminals) have names that don't really reflect what they
are.

For reference, the non-terminal name "ClassExpression" seems to be
a good name:
- An expression is a syntactic construct.  A string matching the
   non-terminal ClassExpression is indeed an expression.
- Using the words in the non-terminal names as a phrase in English
   ("class expression") naturally refers to strings matching that
   ClassExpression production.
- The phrase "class expression," as used to refer to a string
   matching the ClassExpression non-terminal), is clearly different
   from the phrase "class," as used to refer to the thing (the class)
   denoted or described by a class expression.

However, the non-terminal names "Class" and "Individual" are poor
names--they easily lead to confusion.

Consider "Class":
- A class is not a syntactic construct.  A string matching the
   non-terminal Class is _not_ a class; it is an identifier (a form
   of IRI) that _denotes_ a class.
- Using the word in the non-terminal name as a phrase in English
   ("class") does _not_ naturally refer (only) to _strings_ matching
   that Class production--it also refers the _classes_denoted_by_
   those strings.
- The phrase "class," as used to refer to a string matching the
   Class non-terminal, is _not_ clearly distinguished from the
   phrase "class" as used to refer to the thing (the class) denoted
   by a ... um ... "class" in the non-terminal sense.

Something like "ClassIRI" or "ClassIdentifier" would be a much
better name for the non-terminal currently named "Class."

Recall the Class production:

   Class := IRI

and consider it renamed to ClassIRI or ClassIdentifier.

In particular, note how it makes a lot more sense to say:

    A class IRI is an IRI that denotes a class.

or:

    A class identifier is an IRI that denotes a class.

rather than the nonsensical:

    A class is an IRI that denotes a class.


(Careful readers might note that those example statements expose
the fact that the non-terminal name "IRI" has a similar problem:

An IRI is a string and therefore can be a piece of syntax, so
having a non-terminal named "IRI" isn't necessarily a problem.

However, strings matching the OWL non-terminal "IRI" are _not_
IRIs!  (They are angle-bracket-bracketed IRIs or abbreviations
that specify IRIs.)  Stop the madness!)

The name "Individual" is mostly parallel to "Class," except that
it does not include only IRIs (so "IndividualIRI" is not a
candidate new name).


So ...

1.  The wording specifying the meaning of the syntax (the
     correspondence between the syntactic elements and the objects
     represented by them) should be made more precise, perhaps
     using the pattern shown above.

2.  The names of non-terminals should be reviewed and those
     that lead to the ambiguity described above should be renamed
     appropriately.

     (An alternative _might_ be to just reword the textual
     references to the non-terminals to remove the ambiguity, but
     that would likely make things excessively verbose (e.g., "string
     matching the non-terminal X").)