Modeling vs Encoding for the Semantic Web
Review 1 by Thomas Lukasiewicz:
Contents: The paper argues that the Semantic Web community should adopt a more modest engineering view of semantics. It suggests that OWL is a powerful encoding language, but too weak as a modeling language. The paper then proposes to develop separate modeling languages to complement such encoding languages.
Evaluation: I like quite much the ideas of the paper, in particular the one observing that there are some problems with current markup in the Semantic Web, which may be resolved by introducing separate modeling languages; I also like the idea suggesting that ontologies actually constrain the domain.
I have some doubts, though, that modeling languages will completely solve the current problems. Actually, I recently see the problems more and more being solved by machine learning techniques for (often fully) automatic annotation and/or extraction from Web content. How does this observation match (or interplay with) the modeling initiative described in the paper? Could you discuss/comment?
Minor comments: The paper is not always easy to read; would it be possible to increase its readability, maybe by more examples?
The paper should also be formated in the style of the SWJ journal. In particular, the text body should be written using only one font size (currently, some parts are written in significantly smaller fonts). Furthermore, the layout should be improved: explicit enumeration should be used whenever necessary, and the rest of the text should then be written in a continuous way.
Review 2 by Giancarlo Guizzardi:
This paper discusses a very important point and calls attention to an aspect of ontology engineering which has been for far too long neglected in the Semantic Web literature. Actually, the point in question is very similar to the point I make in "Theoretical Foundations and Engineering Tools for Building Ontologies as Reference Conceptual Models" which has been accepted in this very same inaugural issue of the journal. As consequence, I believe this journal issue will benefit from having these two papers complementing each other and reinforcing each other"s main argument.
In the sequel, I include some comments that I believe can help to improve the clarification of the paper in some specific points.
Abstract: "Web research should produce languages for both" -> More generally, I would put that ontology research should produce languages for both.
In the same paragraph, "Ontology modeling languages should support ontological distinctions and translation into any encoding language (RDF, OWL of some flavor, or something else)." -> I would put it in different phrasing, as one can wrongly interpret the sentence as stating "ontology modeling languages should guarantee translatability to any enconding language". Since the latter idea has been suggested in the past (and since I don"t believe that is what you mean), I think it would be interesting to make your point more explicit here.
Page 2: "At those times, both fields used a single paradigm for encoding and modeling: relational algebra for databases and logical devices for user interfaces." -> In the field of databases, in the 80's there was already an understanding (at least in the research environment) of the need of separating the conceptual, logic and physical design. Conceptual-level modeling languages termed Semantic Data Modeling languages (e.g., Chen's ER diagrams, Abrial's Semanatic). I take the opportunity here to cite a fragment of the aforementioned paper submitted to this same inaugural issue: "At this point, I would like to echo the historical report of Janis Bubenko regarding an analogous discussion taking place in the conceptual modeling community in the 70"s between supporters of Conceptual Data Models (e.g. ER diagrams) and those of the Relational Data Model . As summarized by Bubenko,"[t]oday the battle is settled: conceptual data models are generally used as high-level problem oriented descriptions. Relational models are seen as implementation oriented descriptions"™".
Page 3: "As the saying "words don"t mean, people do" expresses, it is people who mean something when they use a term." -> The clarity of this point should be improved. With this phrasing, one can take the interpretation of functionalist view on semantics (as opposed to a referentialist one) and I don't think that is what you intended.
Page 4: "While it is possible to "ontoclean" diagrammatic modeling languages like UML , formal reasoning support requires different kinds of languages." -> Since the references are not numbered, I am assuming here that reference  is to (Guizzardi, 2005). If so, I truly appreciate the reference to this work, but I would put it in a different way. The proposal in  is much broader in scope than an "OntoClean" UML profile. If only because the former deals only with taxonomic relationships, whilst the latter address a much larger superset of ontological concepts including, for instance, part-whole relations, different sorts of dependence, moments, formal and material relations, quality dimensions and domains, etc. The important point nonetheless that should be highlighted is that both proposals are concerned with truly "ontological level" distinctions, not merely with logical and epistemological ones.
Another point that needs clarification is whether what you mean by "formal reasoning" is "automated reasoning". If so, I don't think an ontology modeling language MUST support automated reasoning, since that is only one of the possible applications of ontologies. In contrast, what they MUST support is human problem-solving and, when convenient, they could be (possible partially) mapped to (possibly multiple different) encoding languages that support automated reasoning. It seems to me (judging from the remainder of the text) that you agree with these points.
Page 5: ""¦but functional languages offer functions to model perdurants (and qualities)."-> Notice that in the usual interpretation, qualities are endurants. If functions are the representation of perdurants then I assume you mean function in the programming sense (akin to an OO method). A function in this sense models a specification of a behavior. So, it is unclear here if you really mean a "behavior modeling a quality", or simply what is named an "attribute function" or a "mapping" that maps an endurant to a certain quale (only implicitly associated with a quality).