We thank the reviewers for their excellent comments and suggestions for improvements to the paper. We revised the paper to address each of the suggestions. Below we describe the changes we made that were requested by the reviewers as well as answers to the questions of the reviewers. ---------------------------------------------------------------------- Reviewer #1: ---------------------------------------------------------------------- 1). "Not mentioned is the list of OWL features not supported." We added a sentence to the implementation section clarifying this, and also a brief description of what is not supported to the introduction (along with some motivation for why we consider only a subset of constructs). ---------------------------------------------------------------------- 2). "Overriding the OWL open world assumption should be fine, so long as that assumption is made clear to the users in the documentation." We primarily provide a different approach (e.g., than Protege) for specifying disjoint classes, as opposed to a general override of the OWA. However, we agree that describing this feature will be particularly important to users of owlifier that are familiar with OWL-DL. We also describe this in Section 3.1. ---------------------------------------------------------------------- 3). "There is no mention of the competing CMAP-COE tool that makes it easy to create ontologies visually, with help from drop-down lists. It would be helpful to include a line that compares your approach to CMAP (which also supports only a subset of OWL)." We added additional text in the introduction that further describes our motivation for the spreadsheet-based approach and some of its advantages for ecologists/scientists over CMAP-COE. This is also now briefly mentioned in the conclusion (which lists additional related work). ---------------------------------------------------------------------- 4). "Something that might be pointed out - the tool could be used to help enforce some community standards (e.g., a common use of a "part-of" relation)." We added two sentences to the conclusion that highlights this feature of owlifier. ---------------------------------------------------------------------- 5). "In the references: Usually, the word "pages" is abbreviated to pp. Ref 18: should be to a journal article, not a web site - perhaps Raskin and Pan (2005) in Computers & Geosciences. Ref 19: to EKAW? What is that? Compare Refs 4 and 7 - different wordings are used to describe the same conference." We fixed each of these. ---------------------------------------------------------------------- Reviewer #2: ---------------------------------------------------------------------- 6). "In the early stages of the paper there are some assertions without reference about what is and is not difficult. See p.2 end of 2nd, 3rd and 4th paragraphs. Can a little more detail be added to support the statements? If not, then noting that these are suppositions would be useful for the reader." To address this issue we added additional text in the introduction on why there is a need for new tools familiar to ecological scientists for ontology development, comparing our approach to CMAP-COE and Protege as well as efforts such as OBO. Also, much of the motivation for the work is based on our work with ecologists and information managers, which we refer to in the paper (in the implementation section). ---------------------------------------------------------------------- 7). "Was there any quantifiable basis for choosing the predicates? In particular, the statement" "While not as expressive as OWL-DL, our approach can produce ontology structures that are essential for improved data discovery and integration [14]." indicates some level of decision in the reduced description but without any details, especially in terms for DL-expressivity, it is SHIQ, SHOIN, or what?" As far as we are aware, the arrangement of DL constructs used in owlifier does not directly map to any previously named DL sublanguage, however, it does provide only OWL-DL based constructs, and thus can be considered best as a sublanguage of SHOIN(D). Note that although many of the OWL-DL constructs can be used, they can only be used in certain contexts. Also, some of the more foundational constructs of DLs are not considered, e.g., value restrictions and concept disjunction. While additional blocks can easily be added to owlifier spreadsheet conventions, the proposed set of blocks were chosen to provide a simplified syntax (for a novice DL user) while leading to a "natural" or "intuitive" semantics of blocks for these users. ---------------------------------------------------------------------- 8). "There are no mention of instances, that I could find, at all of instances? Are these part of the use case or not? If not, this really needs to be stated. An ontology without instances has limited application." Our main goal is to provide a mechanism for describing ecological concepts, and then to allow additional tools to use these concepts for annotating scientific data (which represents the instances/values). We briefly mention this now in the introduction, and also elaborate on the scope of owlifier later in the paper. Also see our response to (14) below. ---------------------------------------------------------------------- 9). "Fig.1 suggests a round-trip approach to knowledge engineering, but in fact it is not. How does the present formulation represent to scientist what gets dropped in the back conversion from OWL to the spreadsheet format?" We reworded the implementation section to make it clearer that the conversion is not information preserving. In general, the owlifier tool will only notify the user of this situation, but at this time no additional support is provided. We also tried to better clarify and describe the extensions to owlifier needed to better support the round trip conversion in the conclusion (as part of our future work). ---------------------------------------------------------------------- 10). "Most of all, there is almost no (or none at all) description of the implementation or any evaluation, i.e. the how, why, etc. What has this application been applied to?" The areas the owlifier application has been applied to is described in the implementation section, as well as in the introduction (briefly). In particular, we are applying owlifier to the Traitnet project (ecologists studying/using biological trait data) and to an LTER project that is attempting to impose structure over a large list of keywords extracted from existing metadata documents. We have not performed a formal evaluation of the owlifier application, which we state in the paper as future work, however, we have received positive (informal) feedback on the tool and we briefly describe this at the end of the implementation section. ---------------------------------------------------------------------- 11). "It seems that it would be easy to generate complex blocks. How are moderate size ontologies developed?" Our use of owlifier has included both small and moderate sized ontologies. Ecologists often create spreadsheets with large amounts of data, and similarly owlifier can be used in this way. In addition, sparse blocks significantly simplify the size of large hierarchies, since not all information needs to be repeated per row. In the LTER project mentioned above, there are thousands of terms (organized into a flat list) that are easily imported into Excel, and then using the Excel editing features, have been fairly easily organized into hiearchies (i.e., entity blocks and property blocks). In general, using a combination of tools (e.g., that could show a portion of the spreadsheet visually) would also probably be extremely useful, however, we have not developed this type of technology for owlifier. ---------------------------------------------------------------------- 12). "What is the rationale for the proposed extensions later in the paper, i.e. what are the use cases or evaluation-driven itersations?" The point of these extensions are primarily for round-trip support of owlifier to OWL-DL and back. We added and revised the last paragraph to better articulate the goals and motivation of this work. ---------------------------------------------------------------------- Reviewer #3: ---------------------------------------------------------------------- ---------------------------------------------------------------------- 13). "Possibly the authors could signal at the end of section 1 something like "Readers unfamiliar with logic notation may safely ignore the small amount they may encounter in what follows."" We added a sentence stating this. ---------------------------------------------------------------------- 14). "Although not enough to recommend required additions, I am left a little puzzled as to why the authors seem to be silent on two issues: OWL data type properties and owlifier instance entities. Both of these would seem easy to represent in their owlifier syntax. I would also imagine that both could arise in representing and reasoning about both dataset metadata and record-level metadata on biodiversity databases. So I am left wondering whether I am wrong about the ease of representing them in spreadsheets and attaching DL axioms, or whether instead, the authors believe that these two OWL constructs are better treated in as data for reasoners or elsewhere." Our use cases are largely driven by separating the specification of conceptual information (i.e., t-box assertions) from instance-level information. In particular, in our applications instance level information is provided through "semantic annotations" that map data sets to ontology instances. In this way, too, multiple data sets can be mapped to the same ontologies. Our decision also is inspired in part by the work of Rector et al. that state in the OWL Pizza's paper: "this paper only concerns issues in defining OWL classes, since this is the strength of OWL-DL, and most existing classifiers deal with individuals completely or not at all." However, we may extend owlifier in the future to include datatype properties, which would be a natural and simple extension. ---------------------------------------------------------------------- 15). "On page 4 (Subsection "Overlap blocks", the second sentence has a small English ambiguity: "[...]a given set of classes may have overlapping instances." could reasonably be understood to mean that some instances overlap one another, whereas I believe the clause means "several classes may have common instances." [Grammatically, the overlapping instances do not belong to the collective "set of classes" but rather to each of the members of that collective]" We fixed this, which now reads: "Overlap blocks explicitly relax this assumption by stating that a given set of classes may share common instances." ---------------------------------------------------------------------- 16). "Reference 22 is missing 'c' in the article title. "logi" should be "logic"." We fixed this.