Review comments about OWL feature synopsis document

Below you find review comments about the OWL feature synopsis document at
http://www-db.bell-labs.com/user/pfps/owl/owl.html
(version 23 May 2002).


In my view, the compact overview provided in this document gives a very 
useful 
perspective on the full language.


--Section 1
The sentence "These problems have delayed ..." does not really seem to 
belong
to this document.

The 4th paragraph, motivating the document, could be strengthened.
An overview of the language that abstracts from concrete syntax 
facilitates access to, evaluation of, and development of any concrete 
syntax 
for the language.


--Section 2
I think that the term "individual property" will lead to confusion.
Many people will read "individual property IDs" as "individual 
property-IDs",
whereas "individual-property IDs" is meant. Another name is desirable! 
The insertion of a hyphen, as above, would not be satisfactory.
The text says: "Individuals correspond to RDF resources."
I suggest to replace the name individual throughout by resource.
I strongly believe that the threshold between the language and prospective
users becomes lower by omitting each unnecessary term.


I think that the explanations (of the axioms) given later in the document 
can also become 
readable as an informal overview of the semantics and entailments of the 
language.
For this purpose, I suggest to extend the last two paragraphs of Section 
2, (which are now
extremely brief, and leave important things implicit) slightly:

I suggest to add to the next-to-last paragraph something like the next 
sentence:
There is a universe of discourse, a set whose elements are called 
resources
and data values. Classes denote subsets of the set of all resources.

I suggest to add to the last paragraph something like the next sentence:
Properties denote sets of pairs of elements of the universe of discourse.


--Section 3
Two remarks about the frame idiom.
Because the language is meant for the Web, it is of interest, also on the 
abstract level,
to be able to distribute axioms for a class or property into different 
parts.
I suggest to add this explicitly.
For subclass axioms, meaning is given by intersecting the parts.
For property axioms, this is slightly more subtle.

Second remark: The term frame can be omitted, or only used in historical 
remarks.
The text says that this idiom is widely understood. This is true in the AI 
community.
The text could speak about "each class axiom" instead of "each frame-like 
class axiom" etc.
Compare my remark above about terminology in relation to threshold.


--Section 3.1
The global structure of the productions can be simplified by omitting
the supers and the restrictions from the EquivalentClass axioms and the
SubClass axioms. Semantically, the possibility to do supers and 
restrictions comes back 
under <description>.
The <description> part is simple enough to do this.
It would then be natural to switch the positions of Sections 3.3 and 3.4.
This would simplify the presentation, make it less redundant, and more
transparent.

As to the explanation to EnumeratedClass axioms:
I suggest to make the explanation more precise by saying:
"It is also possible to define a class as exactly consisting of a certain 
set
of individuals, .."
(At least, I assume this is what is meant.)


--Section 3.2
vice versa instead of view versa

In the IndividualProperty axiom the appearance of <PropertyId> with a 
capital
is not consistent with the usage in the other axioms.

Slightly before the last axioms, the quotes around "axioms" should be 
omitted.


--Section 3.3
The notion of restriction was considered difficult in DAML+OIL.
I suggest to replace the first, brief, explanatory sentence by the more 
explicit sentence:
"Restrictions enable the definition of classes in terms of constraints on
properties."

It was suggested to replace 'range' by 'allValuesFrom' and 
'required' by 'someValuesFrom'. I think these suggestions are improvements
However, in 'someValuesFrom' the plural is not what is really meant.
I prefer the replacement of 'required' by 'someValueFrom', as one value is 
enough.
It would then be more symmetric to say 'eachValueFrom' instead of 
'allValuesFrom'.

Therefore, I prefer the replacement of 'range' by 'eachValueFrom'
and the replacement of 'required' by 'someValueFrom'.


--Section 4
In my view, the first line of the <propertyValue> production,
introducing a recursive appearance of <fact>, is confusing.
This line implies that a <fact> always stands for an individual.
But the production for <fact> says that a <fact> stands for one or more
assertions about an individual.
What is meant here? Is a fact implicitly also an individual (reification),
or does the fact need to be projected to the individual about which it is
an assertion?
In the latter case, the first line of the <propertyValue> production 
should
in my view be omitted, and replaced by the addition of such a projection 
function.

It is desirable to add explanation about how facts about anonymous 
individuals work.


Herman ter Horst