Feature synopsis: form comments

Dear all,

	Frank asked me to give feedback about the Feature synopsis, 
this is what I do now. I separate form (syntactic) comment from 
content (semantic) comments about the language itself. My comments 
are mainly syntactic in fact.
	There will also be a message about another miscelaneous issue.

General comments:

0) terminology: the headers "language synopsis" and "language 
description" are not correct since no language is described (and this 
is what is said in the text). I would use a term like "primitive" 
"constructor" "notion" or "concept" (the document might also been 
describing an "infoset" but since I still do not get what this is, I 
am not sure).

1) the document hesitate between a reference card "language synopsis" 
and a primer "language description". I would say that:
- the first part is not detailled enough for a reference card (I 
would add primitive signature: Class x Relation);
- more important, the second part is not detailled enough to be a 
primer: it requires a lot of knowledge about classes, etc.

My suggestion here would be to organise the document around the 
second part with headers for each primitives that can be easily 
extracted for making a reference card (but a reference card is more 
about a language than primitives). This would  lead to an easier to 
maintain document as well as easier to search.

2) conventions: In some places it seems to use the convention that 
classes are Capitalized, properties are notCapitalized. This is not 
consistent throughout the document so I give below the list of places 
not respecting this rule:
- 3.1, subClassOf: person, mammal
- 3.1, individual: person
- 3.3, inverseOf: P1, P2
- 3.3, transitiveProperty: P
- 4, oneOf: DaysOfTheWeek
- 4, hasValue: DutchCitizens
- 4, disjointWith: Man, Woman
- 4, unionOf: to revise completely: Dutch citizens, senior citizens...

3) signatures:
a) It is not stated very clearly at the begining that we have 
classes, properties and individuals (three sorts of things). These 
are abstract things.
b) The primitives apply to certain of these abstract things. It would 
be good to say it because it is easy to try to apply a cardinality to 
a class for instance...

4) individuals: using "individual" to refer to the value of a 
datatype (3.1) does not suits me. These stuffs have very different 
properties and I think that they should not be mixed.
For instance, does all "3.1, individual" applies to datatype values? 
Can I write: (sameIndividualAs 1 2) ? (hasValue 1 successor 2)?

Local comments:

Abstract, par1: "a additional vocabulary" --> "an additional"
	Note that this expression sounds like "yet another...", I 
think that another phrasing like "by extending..." should be more 
appropriate.

3.1, 1st par: "Thus the term Class is more precisely stated as 
owl:Class" NO! "owl" is not a namespace name (which must be a URI). 
It can be redefined by the user to be any URI. I would suppress this 
sentence or add: when "owl" is declared to denote the OWL namewpace 
URI.

3.1, 1st par: the term individual --> the term "individual"

3.1, range: "also... as is..." (I do not know if the english is OK)

3.2: differentIndividualFrom: it is a bit problematic to refer to the 
undefined notion of "contradiction" here. I tried to find another 
example, but did not found one and I suspect that there are not such 
an example due to the restriction of the language (I have a nice one 
with cardinality 2...).

3.3, TransitiveProperty: atmost1 and exactly1 should be replaced by cardinality

3.3, FunctionalProperty: This is has --> This has

3.3, FunctionalProperty: hasFather or hasBirthFather could be another 
example in the line of what was there before (but not totaly 
satisfying).

3.3, someValuesFrom, last sentence: "can not deduce", I would mention 
"from this information alone" (e.g., if it is functionnal...).

3.4, minCardinality: that that --> that

3.6, imports: "a URI specifying from where the ontology is to be 
imported from", I would suppress the last from.

3.6, versionInfo: add a mention that this is the version of the 
ontology not of the language in which it is written (usually provided 
in XML).

4, oneOf: suppress "set of"

4, unionOf,...: IntersectionOf --> intersectionOf, UnionOf --> unionOf

4, complex classes: add that "Nothing is thus the subclass of any 
other class and particularly to the intersectionOf any couple of 
classes". This is an important consequence that will often be 
overlooked.

5: provided --> provide?

	Please if you want to yell at me, leave me in copy since I am 
not recipicent of this mailing list.


-- 
  Jérôme Euzenat                  __
                                  /      /\
  INRIA Rhône-Alpes,            _/  _   _   _ _    _
                               /_) | ` / ) | \ \  /_)
  655, avenue de l'Europe,    (___/___(_/_/  / /_(_________________
  Montbonnot St Martin,       /        http://www.inrialpes.fr/exmo
  38334 Saint-Ismier cedex,  /          Jerome.Euzenat@inrialpes.fr
  France____________________/                Jerome.Euzenat@free.fr

Received on Wednesday, 4 September 2002 04:52:12 UTC