GSOC 2017- Support Multiple Classes per Concept Project

[jtatia (Jai Tatia)]

Hi @burke I have been working on the core module for a while now trying to understand concepts, concept classes and the requirements of the project.

Through this project we are aiming to provide more flexibility by allowing concepts to be assigned to more than one class. (while providing backward compatibility)

i.e. What we had

What we want

This would require the following :-

1. modeling the core api to include multiple classes per concept. Achievable by including a new table:- concept_class_map (for mapping concept with multiple concept classes) .concept_id .concept_class_id and accordingly added suitable methods and modifying the existing one’s. Thus we are basically redesigning concepts to have one concept_class_id as primary class (for backward compatibility and for those cases where concepts have only 1 class) and mapping the other classes in a Hash table. 2)Change in the data model by including the above table. Thus we would also have to modify the DAO and HibernateDAO classes.
2. Modifying the web rest api to reflect these additions and changes so that other modules can fetch and post data. 4)Modifying the ui of concept management tools for ex. Modifying the add concept fragment to be able to add multiple classes. (I have the ui mock ups regarding the changes ready)

Questions We have concept_class_id (as primary class). So if someone voids it or deletes it, will another arbitrary concept class from the mapped data become the primary class, i.e will the primary class have any privileges or is it only for backward compatibility. When showing a searched concept do we show only the primary class or all its classes. For searching I think we can change the filter to be able to select multiple classes. (i have a mock up for it)

Thought We added Concept classes to place concepts in a higher bucket, but with this we have a 2 tier relationship. What do you think about creating a hierarchical form for better categorising. Like for example we have a concept class drug which contains all the drug information. If we are able to create a hierarchical table we will be able to further classify the concept classes.We could make it in form of a binary tree or by mapping data. This could provide for better search.

Reference:- discussion on dev list, TRUNK-4540

[burke (Burke Mamlin)]

@jtatia

We have concept_class_id (as primary class). So if someone voids it or deletes it, will another arbitrary concept class from the mapped data become the primary class, i.e will the primary class have any privileges or is it only for backward compatibility.

If you look at concept_class, you’ll see it can only be retired. While you can purge a concept class that hasn’t ever been used, once its used, you can only discourage future use by retiring it.

The use of a primary concept class is for backwards compatibility.

@jtatia

When showing a searched concept do we show only the primary class or all its classes.

Once the API supports multiple classes per concept, then any future code or opportunities to refactor existing code could remove the assumption that concepts have only one class. That would include searching & display screens. So, yes, it would be preferable to show all classes.

@jtatia

ThoughtWe added Concept classes to place concepts in a higher bucket, but with this we have a 2 tier relationship. What do you think about creating a hierarchical form for better categorising. Like for example we have a concept class drug which contains all the drug information. If we are able to create a hierarchical table we will be able to further classify the concept classes.We could make it in form of a binary tree or by mapping data. This could provide for better search.

It’s a fine thought and there are lots of efforts over the past 50 years or more on building ontologies like this (e.g., UMLS). The challenge is that life is never as clean as your diagram. Relationships between classes can be complex. While we could constrain our use case to a simple hierarchy, we would still face two big challenges in the real world: (1) admins with the time and knowledge to properly create & maintain the class hierarchy and (2) the complexity that comes along with the advantages of the hierarchy being understood by people creating & managing concepts within an implementation and programmers consuming the data.

In the end, I think we’re better to keep things simple for now – i.e., just try to go from a single concept class per concept to supporting multiple – and relationships between concept classes could be introduced later (perhaps initially through a module… for example, a module that uses a standard ontology resource like UMLS to enhance searches by understanding relationships between concept classes), allowing us to see how valuable they are in real world usage before committing to the complexity.

Great to see you thinking deeply about this, though.

[jtatia (Jai Tatia)]

Thanks for you’re feedback @burke I guess its true. The coding related to creating a hierarchy based system is not as hard as actually classifying all the concepts properly into a hierarchy and maintaining it. It would require a lot of effort. Anyways I’ll get back to working on the proposal. I had one question. Should changes in UI also include changes in legacyui or only focus on the refapp ?

[jtatia (Jai Tatia)]

Hey @burke, have you had a chance to look at my proposal for Multiple Classes per Concept ? Would love to get your feedback on it before i submit it in pdf form tomorrow .