Review of the BOT spec

Here is a detailed review of the document at 
https://w3c-lbd-cg.github.io/bot/, as of 2019-01-29T15:05:42+01:00 .


Sec.1:
  - "This section is non-normative" -> this suggests that some sections 
are normative. CG reports cannot be normative in any way. I think it is 
sufficient to have a warning in the "Status of This Document" saying 
that this is not going to be a recommendation, rather than repeating in 
every section that it's not normative.
  - "during it's full life cycle" -> its
  - "Several industries ... main industry" -> this sentence is hard to 
parse. Consider rephrasing.
  - this section uses "extendable ontology" and "extensible baseline" -> 
is there a subtle difference between "extendable" and "extensible" that 
applies there, or are those terms interchangeable?

Sec.2:
  - "This section lists the set of competency questions" -> this section 
does not have *any* question. Moreover, it is not "the set" but "a set". 
For any non trivial ontology, the set of possible competency questions 
is virtually infinite.
  - The items in this list are essentially descriptions of the terms of 
the ontology, nothing more.
  - I don't think this section is useful if there is another document in 
preparation addressing the UCs and requirements. A reference to this 
other document in the introduction would be sufficient, IMHO.

Sec.3:
  - I think this section should have more examples, suggesting modelling 
tips for typical edge cases, or suggest alternatives when no single 
model can be presented as the best practice
  - can a zone be mobile? e.g., can a train be a zone?
  - bot:Zone and bot:Element may not be disjoint (see my other email)
  - bot:Space and bot:Storey or bot:Building may not be disjoint. 
Couldn't a storey be a space itself? If not, why not? How is a single 
room storey distinct from the storey itself? If such disjointness is 
kept in BOT, then there must clarifications on what bot:Space precisely 
means, and what distinguishes it from storeys and buildings (and maybe 
sites).
  - "Domain Includes" and "Range Includes" are more cosmetic than 
functionally useful
  - "bot:interfaceOf MIN 1" -> it would be better to use 
owl:someValuesFrom, because it is much better supported by reasoners 
that implement a fragment of OWL (yet it is equivalent in meaning).
  - there are multiple ReSpec warnings in Sec.3.6
  - "If the data format is textual, then the lexical form of the 3D 
Model literal SHOULD be encoded as a Unicode [UNICODE] string, which 
SHOULD be in Normal Form C" -> this is useless. All literals are, by 
definition, given in UNICODE, and should, by W3C recommendation, be in 
Normal Form C. Please refer to 
https://www.w3.org/TR/rdf11-concepts/#dfn-literal

Sec.4:
  - In my opinion, alignments should be kept separated from the main 
specification. More alignment modules could appear in the future, some 
alignment modules may become obsolete, etc. The rest of the spec is 
totally self contained and persistent, irrespective of the evolution of 
other competing/complementary models.

Sec.5:
  - this section could be extended or reinjected as examples for each 
class specification


Best,
-- 
Antoine Zimmermann
Institut Henri Fayol
École des Mines de Saint-Étienne
158 cours Fauriel
CS 62362
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://www.emse.fr/~zimmermann/
Member of team Connected Intelligence, Laboratoire Hubert Curien

Received on Wednesday, 30 January 2019 15:01:47 UTC