Ontology design patterns for annotation: The ORG ontology localization use case

Tracking #: 696-1906

Guadalupe Aguado
Olga Ximena Giraldo
Asunción Gómez-Pérez
Elena Montiel-Ponsoda
Maria Poveda

Responsible editor: 
Krzysztof Janowicz

Submission type: 
Although ontologies were originally conceived as abstract knowledge representations understandable by computers, there is an ever increasing need of providing this knowledge to the user in a more friendly way. One method to facilitate this process is ontology localization, which has acquired great importance in research, in that it tries to present the ontology information in the user's language. However, localizing ontologies is not a trivial task. In this paper we propose some ontology design patterns that can guide users in the process of assigning labels or identifiers to ontology entities. Based on our experience on localizing ontologies, we have developed some good practices as patterns following the Ontology Design Patterns initiative.
Full PDF Version: 

Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 26/Aug/2014
Review Comment:

The paper presents annotation ontology design patterns to capture desirable consistent naming conventions and descriptions in the context of ontology development. Overall, the paper is well-written. However, there are two shortcomings: (i) Some of the ideas in the paper are too straightforward to warrant a research publication. For example, consider Sections 5.1 and 5.2 which describe relevant issues that are obvious. (ii) There are grammatical stipulations about naming convention that are not easy to use consciously unless it comes naturally to a user. For example, one will use 'is located at' in the label because that is natural and not because it is in 'part particle + preposition' form.

I am unable to assess the ontology localization examples involving Spanish fragments.

Review #2
By Tim Clark submitted on 21/Sep/2014
Minor Revision
Review Comment:

Very useful work which should be published here, with the following minor revisions:

section 2 - motivation - seems a little repetitive - could it be rolled up into section 1, Introduction?

section 3 - page 2 “We extend this meaning to de-
note the way an ontological concept adopts when ex-
pressed in natural language by using different morpho-
syntactic structures available in all natural languages.”

do you mean “adapts”? this is not clear as written.

page 2 - “In this particular case, as the addressed problem
does not involve neither the structure of ontology elements nor modeling elements we do not…”

“neither” —> “either”
insert comma after “elements”

page 4 - “In this use case we show how a class definition should have been created according to the presented pattern, it could also be applied to improve the current definition.”

“pattern, it could” —> “pattern. It could”

“The translators should have the adequate training and needed expertise in intercultural communication so as…target language complying…”
“The translators should have adequate training, and the sufficient expertise in intercultural communication, so as……target language, complying…”

“So, a background on” —> “So, a background in”

“Before presenting the final product, the translated ontology should be revised by an editor and/or an ontology engineer.”

Please indicate specifically what an editor might do vs. an ontology engineer. The “and/or” construction here implies equivalency, but this does not seem likely.

page 5 - “Moreover, it should be advisable to…” —>
“Moreover, it would be advisable to…” OR “Moreover, it is advisable to…”

page 6 - “For the case of the property http://www.w3.org/ns/org#member from the ORG ontology is is neither clear nor intuitive the directionality of the property just from the label attached to it…” —>
“For the case of the property http://www.w3.org/ns/org#member from the ORG ontology, the directionality of the property is neither clear nor intuitive, just from the label attached to it…”

page 7 - “could have been provided…” —> “should have been provided…”

“could have been named…” —> “should have been named…”

page 8 - “straight forward” —> “straightforward”

“multi-word terms as for the case of the class…that is named as follows…” —>
“multi-word terms. This the case for the class…,which is named as follows…”

page 9 (Table 16 & Table 17) —> “in order to clarifying the directionality and meaning of the property…” —> “in order to clarify the directionality and meaning of the property…”

page 11 - “In this regard, Ishida 10)” —> “In this regard, Ishida 10”

“Best Practices for Publishing Linked Data” working group 11 in URIs for Linked Data,…” —>
“Best Practices for Publishing Linked Data” Working Group 11 on URIs for Linked Data,…”

“In this respect, we find some valuable guidelines presented at Common HTTP Implementation problems,…” —>
“In this respect, we find some valuable guidelines presented in Common HTTP Implementation Problems,…”

“which aims at deepening on the annotation issue…” —>
“which aims at deepening discussion of the annotation issue…” OR
“which aims at deepening understanding of the annotation issue…”

page 11-12
“the latter may also require to rely on…that allow to account for…”
“the latter may also require reliance on…that can account for…”

page 12
“We found that most ontologies analyzed do not use
meaningful labels for named entities.”

which ones were those you analyzed? this seems very cursory indeed

“that cover all different cases it could appear…” —>
“that cover the multiplicity of different cases which could appear…”

“alphabets that do not have distinction…” —>
:alphabets that do not distinguish…”

Review #3
By Mark Gahegan submitted on 07/Oct/2014
Major Revision
Review Comment:

The aim of this paper is to propose design patterns that can be used to annotate an ontology: that is, create meaningful labels and descriptions for ontological terms. There is a specific focus on localization, and particularly the challenges faced by translating ontologies into different languages.

I very much like the focus of this paper. The problem outlined is now commonplace, and whereas we have some simple, established guidelines and conventions for naming ontological terms, these guidelines do not always produce readable results and they are usually host-language-specific. Recognizing these problems, the authors here have taken a more careful, deliberate view of the issues, and provide some simple design patterns for choosing appropriate names/labels.

I enjoyed reading the paper, it is easy to follow (and I don’t find the tables too distracting, in fact I would rather they were described more in the text. It was a nice change to see this less technical issue addressed, I think it is overdue for more careful consideration. All tables and figures seem appropriate to me.

Apologies to the authors for taking so long to get this review completed.

Some issues that I think should be addressed in your revisions

The authors make claims about the study of ontologies they have conducted, in the introduction, in section 5 and in the conclusions (e.g. “we found that most ontologies analyzed…”). I’d like to read more about the actual investigations carried out, the ontologies explored, and the kinds of naming confusions most often encountered, as well as any more qualitative feedback from ontology users. If indeed a study has been conducted, then its results would support the aims pursued here, and I suggest including at least a summary of your findings in this paper.

Section 2 is very short, I suggest you merge this into section 1. I did not follow the first sentence in this section. Also, the last paragraph in section 2 should be merged with the last paragraph in section 1 (it largely repeats).

Just how practical is it to expect to gather together the team of experts described to document and localize an ontology? Has it ever happened? Are you imagining that this should happen in order to translate between every language and community? Is this practical? Can you say more about you findings in the conclusions that “ most ontologies analyzed do not use meaningful labels…” What are the common mislabeling mistakes? Which ontologies did you analyzed? How did you analyze them? Could this be automated? If so, how?

Related to the last point, I think you could do more to suggest which patterns to apply. For example, tables 8 and 9 show two possible patterns for naming properties. Whereas I think these are valid, and helpful, the difficulty is in choosing which pattern to apply in a given situation. What are the rules / guidelines that suggest which patterns apply for a given property? I’d like to see some further work in this paper to address the problem of deciding which patterns to apply. Having choices is good, but if the wrong choice is used, then it will do no good. How do we know which pattern is the most appropriate? (You claim this purpose in the conclusions.)

Table 13 might be enhanced by providing a pattern for capitalizing in German too, where all nouns are capitalized?

The examples from tables 11-16 require the reader to understand some Spanish in order to grasp the subtleties of the patterns. I think you need to provide a better description of exactly how these examples address the subtleties of English to Spanish language translation. (I have a Spanish-speaking friend who I asked for help here.) In examples 15-17, the translation to Spanish seems to give a clearer description that would also be equally valid in the original English! Would you agree?

Some minor points

Localization also produces challenges when moving from one community of practice to another. Are you aware of any examples of situations where one community uses different words to describe the same concept as another, even within the English-speaking world?

Page 2>. I’d tighten the definition of a linguistic realization patter to:
A linguistic realization pattern is a structure or guide to maintain coherence in expressing linguistically labels, properties and definitions, and to help users in naming the different elements of an ontology, both in the creation and the localization process.
Figure 1 the topmost label should be Otology design patterns (ODP)

Page 5, last sentence. Do you mean glossaries?

Page 10. The concise form of “the wall of the eosophagus” is in fact “eosophagus wall”

Page 12. I don’t think that a good drafting document will ever avoid all ambiguity problems, but it will certainly reduce them.