Getting Involved and Maintenance Policy

Printer-friendly version

How you can contribute to Diabetes Treatment Support Ontology

Our ontology at present is successful at taking in a patient’s parameters, selecting a drug for them, displaying the drug’s toxicity, selecting an alternative drug for the initial drug, displaying its toxicity and determining whether that particular patient group or cohort has been studied in the ADA guidelines. Going forward, there are various ways we can get the broader community involved in our project.


The current system we have in place for toxicity is quite limited, we are only looking at two drug’s toxicity (Metformin and Phenformin), and manually extracting this information from PubChem snippets. You could help us in automating this process, and not only looking at Pubchem, but a variety of papers in PubMed. We also need help with finding all the relevant toxicity information on a drug and its similar drug - in deciding which studies and toxicities would be useful and relevant. There are various other portions we could use help in expanding our system - for instance in adding metabolite information to the drugs and their possible toxicities or adding contraindication scenarios to the system (for instance for a patient that would have a contraindication to Metformin). We could also use the help of domain experts from the medical field in order to give guidance on which toxicity information would be directly useful to them. However, if we were to expand this system, understanding the question of connecting drugs to their metabolites and their toxicities could be more broadly useful in the field of toxicology, as it can be applied to many other diseases and drugs - and perhaps could find links in certain drug structures and their toxicities from metabolites, which could be helpful to be aware of when designing new drugs.


As of now, the recommendation is really simple and only focuses on the pharmaceutical section of ADA guideline, we are interested in expanding it to include other guidelines like AACE. We also implemented our model for the recommendation using SIO and that is still an ongoing process. We currently adopted DMTO’s style of using SWRL rules, but some rules can be replaced with restrictions on properties, and this is also something we would like to look into as future work. We would be very interested in having subject matter experts assist us in (a) extending our set of sample patients, (b) identifying the right course of action(s) that could help those patients, and (c) evaluating the recommendations that the system suggests for those patients to help
us improve on the results.


We currently have two representations for the descriptive statistics on the cohorts ( patient populations ) utilized in research studies. One approach is rooted in classic OWL principles and uses the notion of associating every instance with a name and interconnecting statistics to the features via hasMeasure properties, however, this might not translate figuratively for a layman as we associate measures with characteristics like Disease. Our second approach is inspired by James McCusker’s paper on “A Provenance-Driven Semantics of Aggregation”, and we are instantiating StudyGroup’s as owl:Class and associating descriptions and restrictions on the same. For the second approach, you could help in automatically identifying features which might count as additional class membership restrictions like for a MalePatient set we only want to allow male patients. We would like feedback on which approach is more intuitive, and if neither what other approaches to represent aggregative values would be feasible. We would like some pointers to tools that are capable of extracting tables ( Table1’s containing population descriptions ) from PDFs ( of research studies) and do a good job at doing so.

Maintenance Policy
Team Maintenance:

  • Any/all changes to the use case, concept map, ontology, and SPARQL queries will be made available on the Diabetes Treatment Support Ontology website
  • Archives of the changes made to the use case, concept map, ontology, and SPARQL queries will be categorized and present on the website.
  • The following hierarchy will be enforced for changes made to artifacts: use case --> concept map --> ontology --> SPARQL queries. If any changes are made to artifacts higher in the hierarchy (e.g., the use case is highest), changes should be cascaded to all artifacts lower in the hierarchy

Community Maintenance:

  • Ontology permissions are as stated in the MIT License provide below (these allow for forking and branches of the ontology to be made for all permissible reasons)
  • Members of the ontology team carry permission to make changes to the site; however, suggestions are welcome at:
  • Additional changes to the ontology are welcomed however to be accepted the ontology must successfully answer the competency questions present on the website (failure to do so indicates fundamental structure errors in the ontology that need to be submitted).
  • The code should be accompanied by tests and documentation.
  • One branch per feature or fix with sufficient commit messages.
  • Ontology must have a version number, creator credits, and modification data present in the annotation header.

Click to Read Project License

This was developed as a part of the Ontology Engineering course supervised by Prof. Deborah McGuinness and Ms. Elisa Kendall at RPI in Fall'18