Improvements to Create Class dialog and API

[csnyulas]

Based on feedback from users (incl. @cannn and Carine) the Create Class dialog needs some improvement:

• It is confusing that the classes with similar names, shown in the search results, are selectable
• If there is already a class with the exact same name as what the user wished to create, the existing class will become a child of the selected entity. This happens silently without the user's awareness, or explicit notification, which might cause confusion and undesired outcomes
• The behavior described in the previous point is a problem for the API as well. The API should not add new parents when a class creation is requested. Instead, when an API call is requesting the creation of class with the name, that is already used in an existing class, the call should fail a "Bad Request" response
• Creation of classes with the same name is not possible, which is a feature rather than a bug, as class labels are used for indexing and searching and retrieval. However classes with identical labels already exists, coming from different classifications (e.g. "Walking and moving" appears both in ICF and in ICHI). This should be fixed, to avoid problems downstream! @cannn and @csnyulas to check.

Another necessary improvements was already reported separately in issue #295.

Added after subsequent testing

• Create button should be disabled if there is no class name specified (or if it contains only whitespace characters)

[alexsilaghi]

fixed in protegeproject/webprotege-gwt-ui#232 ,who-icatx/icatx-api-gateway#64 and protegeproject/webprotege-backend-service#149

[csnyulas]

I tested the solution and it does check for duplicates and does not allow the creation of classes with the same name (at least in the UI, where I tried), but there is a slight problem that can occur due to case sensitivity.

We said we would allow creation of classes with the same name but different in upper/lower case spelling. Since the Lucene index search is case insensitive, the first match is not always guaranteed to be the exact match (sometimes it could be the second or third one). So, it is not enough to check for equality on the first match (which we assumed is always the best one).

For example in the following situation I can still create a new (superclass for the) "test" class.

There are two approaches to really fix the (remaining) problem:

• Check for duplicates in a case insensitive manner (i.e. do not allow two classes that have the same title, but differ only in use of upper/lower case characters). Overall, a better solution, but should we check with @cannn if this use case works for WHO.
• Check for equivalence on more than just the first match, e.g. for up to 5 matches or the first page of matches (although it is unlikely that we would have more than 3 classes that have the same title spelled differently, which would point to a much bigger problem anyway).

CC: @alexsilaghi

[csnyulas]

I added one more point to be checked (related to empty class names) to the list in the issue description.

[alexsilaghi]

fixed the selection of entities , fixed searching the entire result rather than the first entry for duplicates, disable button on empty string. This is the merge request : protegeproject/webprotege-gwt-ui#233

[csnyulas]

I am closing this ticket as all these issues have been fixed. I discovered some other (less critical problems), for which I created a follow-up issue: #315