Map-On: A web-based editor for visual ontology mapping

Tracking #: 996-2207

Alvaro Sicilia
German Nemirovski
Andreas Nolle1

Responsible editor: 
Isabel Cruz

Submission type: 
Tool/System Report
This paper presents Map-On, a web-based editor for visual ontology mapping developed at the Architecture, Representation and Computation research group of the La Salle at Ramon Llull University. The Map-On editor provides a graphical environment for ontology mapping creation based on the representation of mapping using an interactive graph layout. Thus, a point-and-click interface simplifies the mapping creation process. Based on the user inputs the editor automatically generates a R2RML document, particularly produces the IRI patterns and the SQL queries. It has been used in real scenarios alleviating the effort of coding R2RML statements which is one of the main barriers for adopting R2RML in research and in the industry communities
Full PDF Version: 

Major Revision

Solicited Reviews:
Click to Expand/Collapse
Review #1
By Amruta Nanavaty submitted on 31/Mar/2015
Review Comment:

This is a paper describing Map-On, a web-based graphical environment tool for mapping a database schema to a domain ontology. It supports different kinds of users to manually establish relations between the elements of a database and domain ontology in context of an Ontology-based Data Access (OBDA) scenario. The editor, based on the user’s input, automatically generates an R2RML document, produces Internationalized Resource Identifier (IRI) patterns and SQL queries. The authors describe the architecture and how the tool works very well. The automatic generation of R2RML mappings from the user actions and the graph based visualization layout seem to be unique features of Map-On. However, please find below the major comments:

1. The title of the paper seems to be ambiguous. Ontology mapping generally refers to finding correspondences between two ontologies. Instead, in this paper, the authors propose a web-based graphical editor tool to map a database schema to domain ontology.

2. The screenshots pertaining to the interface are not clear.

3. There are spelling mistakes in Sections 4.2 and 6. For example, "overs" instead of "hovers" and "stablished" instead of "established".

4. There is an incomplete sentence “… methods for query specific concepts, roles, and attributes based on a text provided by the user.” in Section 5.

5. The authors do not mention in the paper whether the tool will report any inconsistencies that might be created while the user maps a database schema to an ontology.

6. The authors do not explain in the paper how the tool would handle mappings between a database element and a domain ontology concept involving constraints.

7. The authors do not explain the significance of adding neighboring nodes along with the mappings on the left hand side panel of the mapping space.

8. The authors demonstrate the usefulness and the feasibility of the Map-On editor in a real scenario for creating R2RML documents. They claim in the paper that the effort of creating mappings was reduced with the help of Map-On editing tool. However, there is no significant proof provided in the paper supporting their claim.

Review #2
By Daniel Faria submitted on 31/Mar/2015
Minor Revision
Review Comment:

The paper describes Map-On, a web-tool for editing and visualizing mappings between relational databases and ontologies.

Map-On appears to be a well-designed tool, with all the functionalities that are necessary to create, manage and view mappings between databases and ontologies, and a simple and straightforward GUI that enables its use by both expert and novice users.

The paper is clearly written, well-structured and well-illustrated, and does a good job of conveying the capabilities of Map-On.

However, there was one aspect where I found it lacking, which is the lack of comparison between Map-On and the related tools (Karma and ODEMapster). The paper details that Map-On opts for a graph layout rather than the tree layout used by the related tools, but does a poor job of explaining why a graph layout is preferable (although I agree that it is) and how it impacts the usefulness of the tool. Given that this appears to be the key difference between Map-On and its competitors, I think it is essential to clarify it in the manuscript. [e.g., one scenario where a graph layout is clearly better than a tree layout is for visualizing ontologies that have cases of multiple inheritance.]

I would also like a mention to be made about how the tools differ with regard to functionality - apart from the layout aspect, are there any functionalities that Map-On has and other tools don't or vice-versa?

Finally, there were a few minor errors in the manuscript (e.g., "quantity and quantity" at the end of the first paragraph of the Introduction), so a careful revision of the text is in order.

Review #3
By Valerio Santarelli submitted on 18/Apr/2015
Major Revision
Review Comment:

The authors present Map-On, a web-based graphical mapping editor for creating R2RML mappings from ontologies to SQL data bases. The tool provides a graph layout representation of the ontology, the database, and the mappings, and automatically generates R2RML mappings from the connections between ontology predicates and database tables that the user defines through a point-and-click interface.
The motivation behind this work is that in general the creation of R2RML mappings requires background knowledge of ontology engineering, formal logic, and SQL query design, and, in absence of automated tools, these mappings must be generated manually. Such manual generation is problematic for users that do not posses these skills, and is, in any case, a time-consuming and error-prone process.
The authors also present a real-world setting in which this tool has been used, and provide some details of this use case and a quantitative overview of the R2RML mappings obtained with the tool.
The tool has been made accessible through a custom guest read-only account.

I appreciate the motivation that lead to the creation of the tool, and I think Map-On can be useful in creating mappings for OBDA scenarios. Indeed, creating mappings is typically quite a taxing task, even for experts in ontology engineering, SQL, and logic, and such a tool can help avoid errors that are common when writing mappings by hand. It also manages to provide the user with a nice customizable graph representation of the database, the ontology, and the mappings between the two. Therefore, I have no doubts about the usefulness and the potential impact of the tool.

The aspects I most like about the tool is that it is easy to use (I was able to find my way around the interface even without reading any instructions), it has a nice, clean, and clear interface, it features frequent pop-ups with helpful tips, and the Help panel is very well done, it is clear and comprehensive, and guides the user through the entire process. The overall quality of the tool is in my opinion absolutely satisfactory.

However, a significant drawback of the paper is that it lacks any sort of user evaluation, which in my opinion is necessary when presenting a new tool or system. The authors claim throughout the paper that Map-On can help users of any kind (skilled and not skilled in ontology and mapping design) in easily generating R2RML mappings from an ontology to a data source. Personally, I do not doubt that the editor can be useful for this purpose, but nonetheless, this claim must be corroborated through proper user evaluation following some standard HCI setup.
The authors state that Map-On has been validated through its application in the SEMANCO project, and that the graphical representation of the mappings has supported their creation and understanding in the project. While evidence of the use of Map-On in real-life projects is certainly a plus, I do not feel that simply saying that it has been used in the project and reporting the number of mappings that have been created through the tool is sufficient evidence of its validity. Furthermore, the authors do not give any information regarding the users who actually used the tool to create the mappings.

The paper in general manages to illustrate the purpose of the tool, to provide a quite comprehensive overview of its features through several figures which depict the interface and the representation of the ontology, database, and the mappings, and it describes the architecture of the tool, with a brief description of its modules.

It also provides a sort of walk-through of the ontology mapping process with the Map-On editor, which is quite useful, even though the tool is intuitive and easy to use, at least with respect to the features available to the demo guest account. One observation I have here is that the description of the process would have benefited from referencing the specific names of the different tabs in Map-On (for example, the "Data sources" tab, or the "Ontology" tab), and to have given names to the panels in the various tabs. This would have allowed to describe the process more clearly, indicating the specific tabs or panel in which each step must be performed, and avoiding things like "clicking the checkboxes on the bottom-left side of the interface" (instead replacing it with, for example, "clicking the checkboxes in the Database panel", which is much more clear in my opinion). This would have also aided the readability of section 4.2, in which the interface of the editor is described, which I think is slightly confusing as it is.

The authors give a sufficient overview of the existing relevant tools for mapping editing. To the best of my knowledge I don't think any relevant references are missed.
Also, R2RML mappings are introduced in the preliminaries section. The description is clear, however the last two paragraphs should not be included in this section (if at all). The last paragraph has nothing to do with R2RML mappings, instead it describes some of the features of the tool, and the first paragraph (whose first sentence is meaningless in my opinion) discusses some subjective drawbacks of the R2RML standard.

In section 4.1, the authors claim that graph layout representations of ontologies represent roles as edges. This is not always true (see, for example, the Graphol language for ontologies [Console et al. 2014]).
In section 5, the authors claim that the possibility of changing the layout by dragging the graph nodes makes the visualization more clear. This should be backed up with some evidence. Obviously, avoiding edge overlapping helps in the visualization, but constantly moving around nodes that represent the predicates of the ontology and the database tables can limit the user's ability to quickly identify the nodes that represent the element he is looking for. This is a known issue with ontology visualization tools that provide a dynamic representation of the ontology.

In general, I feel that the paper is severely lacking in clarity and readability. In fact, it is written to a barely acceptable standard, with many sentences whose meaning is not at all clear, numerous typos, and in general quite poor english (some examples below).

- [pg.1] applications led to the increasing need -> applications has lead to the increasing need
- [pg.1] in terms of the ontology to transform them in terms -> in terms of the ontology and transforms them in terms
- [pg.1] high time consuming -> high time consumption
- [pg.1] supported by the best practices -> I have no idea what this means
- [pg.1] Maestro Studio -> Mastro Studio
- [pg.2] creating R2RML mappings requires of advanced skills -> creating R2RML mappings requires advanced skills
- [pg.2] close the gaps in the expertise -> overcome the lack in expertise
- [pg.2] In spite of that, the editor -> In spite of the fact that the editor
- [pg.2] However, the first choices in this concern ... -> I don't understand what the authors mean
- [pg.2] It also provides with a graphic visualization of the database schema and with the domain ontology -> It also provides a graphic visualization of the database schema and of the domain ontology
- [pg.2] A R2RML mapping -> An R2RML mapping
- [pg.3] requires of technical skills -> requires technical skills
- [pg.4] fosters productivity, as long as complex mapping tasks can be carried out with few user actions. -> What does this mean?
- [pg.5] the cursor overs -> the cursor hovers over (repeated twice)
- [pg.5] This feature works the other way around -> This feature works the other way around as well
- [pg.5] facilitates the user to define -> facilitates the user in defining
- [pg.5] serves to partitioning -> serves to partition
- [pg.5] defined as a SQL queries -> defined as SQL queries
- [pg.5] In the generation of SQL queries is taken into account the adjacent mappings -> In the generation of SQL queries the adjacent mappings are taken into account
- [pg.5] modules (Figure 4) -> module (Figure 4)
- [pg.6] The second paragraph is interrupted after "The module also implements", and seems to pick up again in the next column, after three different paragraphs
- [pg.6] compliant document -> document compliant
- [pg.6] mapping space where the mapping belongs to -> mapping space to which the mapping belongs
- [pg.7] stored in the same place, this reduces -> stored in the same place in order to reduce
- [pg.7] typing input box -> typing in the input box
- [pg.7] the user select one concept -> the user selects a concept
- [pg.7] The first sentence in paragraph 5 is not clear to me.
- [pg.7] cursor hovers the mapping -> cursor hovers over the mapping
- [pg.7] will corresponds -> will correspond
- [pg.8] The platform makes interoperable -> The platform makes the data sources and tools interoperable
- [pg.8] in context of OBDA -> in the context of OBDA
- [pg.8] The Map-On -> either just "Map-On", or "The Map-On editor"
- [pg.8] The mapping editor has four distinctive features -> it should be five features, since five are then listed
- [pg.9] weather -> whether

In light of these observations, I think that the paper can be accepted for publication, but not prior to making major revisions to address the issues stated above. In particular, I think that conducting a proper user evaluation is absolutely necessary to demonstrate the validity of the tool, and that the writing should be significantly improved in order to make the paper more readable.