Disease Information and Semantic Web

Transcription

1 Rheinische Friedrich-Wilhelms-Universität Bonn Institute of Computer Science III Disease Information and Semantic Web Master s Thesis Supervisor: Prof. Sören Auer, Heiner OberKampf Turan Gojayev München, December 13, 2014

2

3 Declaration of Authorship I hereby certify that this thesis has been composed by me and is based on my own work, unless stated otherwise. No other person s work has been used without due acknowledgement in this thesis. All references and verbatim extracts have been quoted, and all sources of information, including graphs and data sets, have been specifically acknowledged. München, December 13, 2014 Turan Gojayev

4

5 Contents 1 Introduction Motivation and Background Problem definition Related Work Approach Structure of the thesis Basics Semantic Web Triples, Ontologies, Reasoners SPARQL BioPortal The structure of dataset on BioPortal Ontology Repository Ontology Metadata Mappings Disease Ontology, Symptom Ontology and UMLS as a starting point Human-Disease Ontology Symptom Ontology Unified Medical Language System (UMLS) Diseases and Symptoms Disease Information Symptom Information Data Overlap Disease-Symptom Relationships UMLS group ontologies Non-UMLS ontologies Data Model Disease and Symptom Graphs 35 i

6 Contents 7.1 Disease Graph Default approach Adapted approach Symptom Graph Default approach Adapted approach Summary 41 Bibliography 43 List of Figures 47 List of Tables 49 Listings 51 ii

7 1 Introduction 1.1 Motivation and Background From ancient times people tried to observe the changes in the health and stored this information (or simply recorded it on surfaces of different materials). Over time, using these recorded pieces of knowledge they gradually learned to understand these conversions and different causes that lead to them, as well as how to cure them. Records showing the changes that bring to a certain state of health play vital role in spotting the problems and their sources. With the evolution of science the means of storing this knowledge have been replaced by new technology, its accuracy and volume have increased considerably. Today s clinical data contain knowledge about thousands of different types of diseases, symptoms, information about body parts, etc. There are also many attempts to organize this information in a useful manner. However, scientists do not always agree on which terms to use for various reasons and it results in the existence of many vocabularies in the same domain with huge overlap. Thus, it is very important to have a relationship between these dictionaries. With the representation of scientific vocabularies in Semantic Web, making these connections is very straightforward. BioPortal [1], being world s largest ontology repository for Biomedicine, contains more than 400 ontologies and more than 6 million classes that define the terms in them. It also stores millions of mappings between terms of different dictionaries. Nevertheless, the ontologies cover different fields of biomedical domain and therefore it is not possible, for instance, to do a search only in a data about diseases. In other words, the data is not mainly arranged around specific concepts. Having all data sorted by the concepts can help users or applications to find the required data in a much easier way. Especially, we are interested in identification of the disease and symptom data within the BioPortal ontologies. Furthermore, relationships between data of different type of concepts can be very useful. For example, one might be interested in all the symptoms that indicate the disease pneumonia or all the body parts where disease cancer might occur. Absence 1

8 1 Introduction 1.2 Problem definition of categorization of the data is the main reason why it is difficult to look for this kind of knowledge. If we had a data organized around the concepts of disease and symptom, we could look for the connections between them and declare the connecting properties as subproperties of a general one, which could be called has_symptom and would point to the symptoms for diseases. With the help of links between predicates that carry semantic information, we can query symptoms for diseases without knowing the exact property that is used in a specific ontology. Despite presence of subproperty relations between different predicates used in triples of BioPortal ontologies, these relations are for the properties that carry either a lexical information or definition. For instance, different predicates used for storing labels for classes are linked to a common skos:preflabel predicate using rdfs:subpropertyof. Another example is the usage of skos:definition predicate as a representative for the properties that give a definition of the classes. These relations are very useful for querying the ontologies with a common query form. 1.2 Problem definition As it was already mentioned in the previous section, in spite of presence of many different field vocabularies on BioPortal, data is not categorized. The second problem, which is also partially dependent of the first problem, is the relationships between different types of data. Difficulties in identification of the type of data is that, for instance, in the case of diseases and symptoms data sets partially overlap. One can try to identify diseases, symptoms and relationships between them without solving the first problem, just by analysing the predicates used in ontologies. However, more than 2600 distinct properties were used in BioPortal ontologies and going through this list and guessing if the subjects and objects corresponding to the predicate are about diseases or symptoms will take a lot of time. Moreover, semantics of predicates are imprecise. For instance, related_to in MEDLINEPLUS is used for disease-disease, disease-symptom and symptom-symptom kind of triples. Therefore, the solution of the first problem reduces the amount of work required to solve the second problem. 1.3 Related Work Unified Medical Language System[2], which is a system encorporating main vocabularies for biomedical domain, defines semantic types and relationships between types. The ontologies that are part of UMLS, such as Systematized Nomenclature of Medicine Clinical Terms(SNOMED CT)[3], MedDRA[4], etc. contain a large number of classes having semantic type disease or symptom. There also has already been a work in arranging the data in biomedical ontologies around the concept of disease [5]. Human-Disease Ontology(DO) is an ongoing project that intends to create a single structure for the classification of disease which unifies the representation of disease among the many and varied terminologies and vocabularies, into a relational ontology that permits inference and reasoning of the relationships between disease terms 2

9 1 Introduction 1.4 Approach and concepts. DO contains more than 8600 disease classes and the terms have extensive references to Medical Subject Headings(MeSH)[6], International Classification of Diseases(ICD)[7], SNOMED CT and other very prominent medical ontologies. In addition to that, DO contains relations to Foundational Model of Anatomy (FMA), Human Phenotype Ontology(HP) [8], Symptom Ontology(SYMP) [9] and other ontologies that contain knowledge about disease attributes. This knowledge is not in a structured format, but rather in textual definitions. For instance, there are 388 distinct diseases containing information about symptoms in the definition (in total 777 such definitions). Moreover, SYMP was designed around the symptom concept by same author. Generic Human Disease Ontology (GHDO) [10] is proposed as a model with four dimensions of data: disease types, symptoms, causes and treatments. This ontology is designed in such a way that disease types may be divided into sub-types, causes for diseases can have two main branches(genetic and environmental). Also for each disease there are different treatments and symptoms indicating it. Nonetheless, there was no such ontology published from the proposed model. Yet in another work [11] one more ontology model for storing disease and symptom relationships is proposed, but the actual work and results are left for future. [12] tries to relate DO and SYMP by finding the links between diseases and symptoms. Authors propose an algorithm for linking classes, but it assumes that one can already get symptoms for a selected disease from a health website or server, or a database and as a result they have symptoms for 11 diseases. Also [13] proposes a Disease-Symptom Ontology model, but it contains a few manually entered relationships between diseases and symptoms. Our main goal is not to have related classes mapped to each other, but rather to understand the semantics of the data on BioPortal, where ontologies contain vocabularies from various fields and in this way, this task is different from general ontology alignment [14]. The ontologies that are part of UMLS and contain classes with semantic types disease and symptom, in many cases also have relations between them. For having different disease-symptom specific predicates mapped to the same common superproperty, we have to understand the semantics of those relations. As we will see later in the further chapters, there are many properties connecting diseases to symptoms, however, just a few of these predicates can be used for linking diseases to their specific symptoms. 1.4 Approach We can see from related work that there are already ontologies on BioPortal where data is centered around disease (DO) or symptom (SYMP) concepts, or contain of both types of knowledge(umls ontologies). UMLS group ontologies also contain relationships between these two types of data. Furthermore, there is a large number of mappings between classes on BioPortal. However, all this knowledge is not analysed as a whole and we try to address this issue in the current work. In this thesis we try to integrate disease and symptom related data, as well as their relationships by analysing BioPortal ontologies. We select disease and symptom datasets as a starting point and then, using them and existing BioPortal mappings we retrieve more of disease and symptom information. Some parts of resulted datasets 3

10 1 Introduction 1.5 Structure of the thesis overlap, showing that notions of disease and symptom are not precise. We try to separate these knowledge bases as much as possible. With this data in hand, we look for the connections between these two datasets and try to find predicates that link diseases to their specific symptoms. In addition, we link these predicates to a common property using rdfs:subpropertyof in order to make querying on the resulted ontology easier. Since we retrieve a large number of classes using mappings, we create a graph consisting of classes as nodes and mappings as edges between them. We do this procedure both for disease and symptom data. Also we assume that these mappings are correct and linked classes represent the same disease on disease graph or the same symptom on symptom graph. Thus, we find connected components of those graphs and treat them as a same disease or symptom class. This also increases the number of disease classes linked to symptom classes. Using this approach we try to arrange data around specific concepts on a repository with many ontologies. Although we consider only disease and symptom data, we believe that one could repeat the same process for other concepts, for instance, body parts as well. One of the key moments is the selection of the correct starting data. 1.5 Structure of the thesis In next chapter we briefly describe Semantic Web technologies. In Chapter 3 we explain what is BioPortal, what functionalities and what kind of data it contains, and how the data is structured on it. In Chapter 4 we describe what knowledge we have at the beginning of our work, which information do we select as a starting point to retrieve more of relevant data. In particular, we talk about Unified Medical Language System which plays an important role in fetching required data and also in grouping them. Chapter 5 starts with the description of how we combine BioPortal mappings with the data we select as starting point in oreder to retrieve more data. We show an overview of all knowledge that we acquire by this method and how we define core part and potential part of the data. Later we face the problem of data overlap between disease related and symptom related resources, and we also describe how we separate them. In Chapter 6 we try to find the connection between disease and symptom data. We do this for both core and potential parts of the disease and symptom related knowledge. We analyse the triples and select the predicates that connect these data, decide which part of those triples to keep in our data model. Also from those triples we choose disease-symptom specific knowledge that represents the symptoms occurring with the given disease. We find which properties indicate this sort of data and define a predicate hassymptom and use it to store this information in our data model. 4

11 1 Introduction 1.5 Structure of the thesis In Chapter 7 we show how we build a graph out of disease and symptom data. Later, we group pieces of data into clusters in order to have similar data packed together. We do this separately for disease and symptom graphs in two different ways and we talk about the differences of those approaches. 5

12

13 2 Basics 2.1 Semantic Web The World Wide Web (WWW) is a web of data. At the time of creation it was mainly intended for the human consumption. Development of the technologies has lead to the point where the WWW has become not only the web of data for human, but also for the applications. However, the way the data is represented was meant for the human users and thus is not very appropriate for the applications. For example, when there is a link to another resource on a web page, context surrounding the Uniform Resource Locator (URL) gives a user idea about the meaning of the link that it represents. Yet not all the applications might have text analysis facilities that will help them to understand the semantics of this connection. Semantic Web, in its turn, adds meaning to the content. It is a web of data described and linked in ways to establish context or semantics that adhere to defined grammar and language constructs [15]. Nonetheless, it is not a substitute for the WWW, rather an extension to it through standardized semantics Triples, Ontologies, Reasoners Triples, or statements, can be considered foundational units of the Semantic Web. Triple gets its name from the number of components it contains. Each triple states a fact and consists of subject, predicate and object. The subject of the triple is the resource statement describes. The object of the triple is the resource, blank node or a literal value, such as a string, number, date, etc. statement relates to the subject. The predicate provides a relationship between subject and object. Triples can define the structure of the information, limits on that structure, instance data and etc. A set of such triples is called a Resource Description Framework [16](RDF) graph. RDF is 7

14 2 Basics 2.1 Semantic Web a general framework, and can be considered a grammar that defines how to represent any information in the Web. Resources are identified by a Uniform Resource Identifier (URI) and provide a mechanism to identify resources on the web uniquely. Difference between URIs and URLs is, URI does not always refer to a physical resource on a Web, whilst URLs always can be dereferenced. Figure 2.1 visualises piece of data from Human-Disease Ontology. Blue rectangles represent the classes and light red rounded rectangles show string values that carry type of information specified by the labels on elbows. In total there are 4 triples represented on the picture. They all have the same subject which is the URI http: //purl.obolibrary.org/obo/doid_ Four different predicates relate this URI to a label for the class represented this URI, subclass information, synonym for the label of class and cross-reference to another ontology. Two objects, "Alzheimer s disease" and "Dementia of the Alzheimer s type" carry string value and thus are literals. The other two objects are resources. All these data are represented and stored using OWL [17](Web Ontology Language). It is intended for use by applications that process the Web documents, rather than presenting them to human users. The current version of this language is OWL2 [18]. An ontology is simply a collection of triples, that define different concepts, their relationships and constraints. It can be compared to a database in case of relational databases. Ontologies can have data from one specific domain, or can be a hybrid of several different fields. There are many rich ontologies that can be used for applications directly or in an adapted manner. Of course, an application can also create an ontology Figure 2.1: Example data from DO 8

15 2 Basics 2.1 Semantic Web from scratch, but usually they make use of existing ontologies to link data to a wellknown, commonly used data sources. Ontologies are stored using one of the serialization formats (Turtle [19], N-Triples [20], RDF/XML [21] or others). The data in Semantic Web can be split into two parts: stated and inferred. We have shortly described what can be stated in the ontologies. But what adds semantic to Semantic Web is actually the possibility of inferring additional information from the stated data. Predicates used in triples can be considered functions that have specific domain and range constraints, as well as properties that let us infer not explicitly stated knowledge. This inference is done by a software piece, which is called a reasoner SPARQL SPARQL for the RDF plays the role of SQL for the relational databases. It is a query language designed for querying RDF databases. SPARQL queries can include one or more triples where the subject, predicate and/or object can be variables. These queries are being sent to the SPARQL endpoints [22]. On the endpoint the triples in the query are being compared to the stored ones in specified RDF graphs. Listing 2.1 shows an example of SPARQL query. This query results in all the triples in graph that contain as a subject the URI Four of these triples are shown in Figure 2.1. Listing 2.1: SPARQL query example SELECT * from < WHERE { < } 9

16

17 3 BioPortal BioPortal is a Web-based application that gives its users an easy access to the contained ontologies. At the moment of writing, with 402 ontologies and 6,062,730 classes in those ontologies, it tends to be the world s most comprehensive repository of ontologies in biomedical domain. With the functions that enable users browse, find and filter ontologies, search for specific terms within those ontologies, submit new ones and explore the mappings among them, BioPortal is one of the many tools that NCBO[23] offers. Ontologies in BioPortal cover various fields of biomedicine. For instance, Human- Disease Ontology contains information about human related diseases, Human Phenotype Ontology about phenotypic features encountered in human hereditary and other disease, Symptom Ontology about symptoms, Protein Ontology [24] provides an ontological representation of protein-related entities by explicitly defining and showing the relationships between them, etc. Besides the diversity of the domain of ontologies in BioPortal, they also differ in size, expressivity and quality. Three main formats are used for storing the ontologies: 1. OBO, the text file format used by OBO-Edit[25], the open source, platformindependent application for viewing and editing ontologies. 2. OWL, which is a W3C recommendation for representing ontologies on the Semantic Web. 3. RRF, the format mainly used by US National Library of Medicine to distribute the vocabularies that constitute the UMLS. BioPortal allows its users to publish, review ontologies, browse through them, through the classes or through the mappings between ontologies via the interface. Once an ontology is selected, one can view the metrics, e.g. number of classes, individuals, properties, classes without definition, etc. calculated on that ontology. Moreover, users can always make applications that use ontologies from BioPortal and enter this information. This 11

18 3 BioPortal 3.1 The structure of dataset on BioPortal lets other people see what are the current projects that use those ontologies, and if those ontologies are really important for the projects they might be considering to create. Through the RESTful API available at BioPortal lets users make queries for given query terms, use any of the ontologies to annotate a text with the classes from those ontologies, get different resources that are stored in BioPortal. Moreover, SPARQL endpoint [26] allows users make more complicated queries that are more adjustable to specific projects. 3.1 The structure of dataset on BioPortal The data on BioPortal consists of three essential parts as specified in [27]: Ontologies Metadata Mappings Ontology Repository The essential part of data in BioPortal is contained in the actual ontologies that are uploaded by the users. Several versions of ontology can be kept in the repositories. There are many ontologies with thousands or even with ten thousands of classes. The predicates used in ontologies by the authors also have a very broad range. At the moment of writing, we have found 2657 distinct predicates on BioPortal. Some of those predicates are mapped to common properties (by means of rdfs:subpropertyof predicate), what makes query process easier. For instance, the predicates that stand for preferred labels of the terms, are mapped mapped to skos:preflabel, or properties that stand for the synonyms of the terms, are mapped to skos:altlabel. These subproperty declarations are saved in a "globals" graph and one can make use of them by querying from that graph Ontology Metadata BioPortal uses a specifically designed ontology for storing metadata information. It imports a number of other ontologies and includes classes to describe an ontology itself, its versions, metadata properties about the ontology, creators of an ontology, user-contributed content, such as notes, reviews, mappings, and views [28]. The two main entities in the metadata are meta:virtualontology and omv:ontology. meta:virtualontology represents a container for all versions of an ontology and an omv:ontology represents a particular ontology version [27]. Figure 3.1 from [27] describes the connections between these two elements. 12

19 3 BioPortal 3.1 The structure of dataset on BioPortal Figure 3.1: Metadata: Virtual Ontologies and Version Ontologies. [27] Mappings The mappings on a BioPortal are stored on a different graph. These mappings can be uploaded by users separately from the ontologies and this lets all the users add mappings between existing ontologies. Each mapping is created between two classes and contains such information as target class, target ontology, source class, source ontology, relation type, etc. In the further sections we will show how we use these information for our purposes. There are several sources for the mappings on BioPortal: 1. Lexical Mappings (LOOM[29]) - these are created by a software, based on the similarity notion between preferred labels or preferred and alternative labels. Any labels with no more than 3 characters are excluded. 2. CUI Mappings from UMLS - contains mappings based on the Concept Unique Identifier (CUI) from UMLS network. 3. User submitted Mappings (REST) - mappings that are created manually by users. 4. URI-based Mappings - these are the mappings between classes with the same URI in different ontologies. 5. Xref OBO Mappings - mappings that are created based on the OBO xref property. 13

20 3 BioPortal 3.1 The structure of dataset on BioPortal 6. CUI Mappings from no UMLS - mappings based on CUI from ontologies that are not part of UMLS. 14

21 4 Disease Ontology, Symptom Ontology and UMLS as a starting point. As it was already mentioned in Chapter 3, BioPortal contains around 400 ontologies and the domains of those ontologies cover such subjects as anatomy, phenotype description, experimental conditions, health, etc. Since disease and symptom information within the BioPortal repository is the main focus of this thesis, we are interested in those, that can be related to one or to both of them. There are a number of ontologies that store the knowledge about diseases. However, users should be familiar with them beforehand, in order to be able to look up for the terms, definitions or any other kind of data about diseases they might be interested in. Therefore, it s important to have an overview over this information. In this chapter we describe some of these ontologies and in the next chapters we will show how we make use of them and BioPortal mappings to combine disease and symptom related knowledge, and retrieve it in a simple way. 4.1 Human-Disease Ontology Human-Disease Ontology represents a comprehensive knowledge base of inherited, developmental and acquired diseases. It integrates disease and medical vocabularies through the usage of cross-mappings and integration of MeSH, ICD, NCI s thesaurus, SNOMED CT and OMIM disease specific terms and identifiers. The DO is utilized for disease annotation by major biomedical databases (e.g., Array Express, NIF, IEDB), as a standard representation of human disease in biomedical ontologies (e.g., IDO, Cell line ontology, NIFSTD ontology, Experimental Factor Ontology, Influenza Ontology), and as an ontological cross-mappings resource between DO, MeSH and OMIM(e.g., GeneWiki). DO has been incorporated into open source tools (e.g., Gene Answers, 15

22 4 Disease Ontology, Symptom Ontology and UMLS as a starting point. 4.2 Symptom Ontology FunDO) to connect gene and disease biomedical data through the lens of human disease. At the moment of writing it contains 8681 disease classes, 2260 of which have textual definitions annotated with disease attributes, such as symptom, phenotype, anatomical location and etc. has_symptom property used in triples to annotate the textual definitions with symptom information and only definitions of 388 distinct classes are annotated with this predicate. 4.2 Symptom Ontology The Symptom Ontology was developed as part of the Gemina project[9]. It is created around the concept of a symptom being: "A perceived change in function, sensation or appearance reported by a patient indicative of a disease". SYMP is organized primarily by body regions with a branch for general symptoms. The Symptom Ontology in July 2008 was submitted for inclusion and review to the OBO Foundry and was adopted. It also continues to undergo active development to incorporate Basic Formal Ontology structure. 4.3 Unified Medical Language System (UMLS) UMLS, started in 1986 by US National Library of Medicine is a system for integrating major vocabularies and standards from biomedical domain, such as SNOMED CT, MeSH, ICD, LOINC, RxNorm and several others. UMLS consists of sources called Metathesaurus, Semantic Network and SPECIALIST lexicon. Metathesaurus is a huge vocabulary that contains 1 million unique concepts about biomedicine with 5 million concept names from more than 100 terminologies, classifications and thesauri, and more that 17 million relationships between concepts. Metathesaurus is organized by concept(meaning). Each concept is given a unique id (CUI) and can have several names, since these concepts might come from different vocabularies, and ids are designed for linking all these names to the same thing. CUIs are given permanently and might change only if it is discovered that several CUIs actually represent the same concept. Semantic Network provides a categorization of the concepts that appear in Metathesaurus and also the relationship between them. It consists of semantic types and semantic relations. Each concept is assigned at least one of the semantic types. Semantic types are the nodes in the semantic network and the relations are the links between them. A portion of this network is depicted in Figure 4.1. There are semantic types for biologic functions, for organisms, for anatomical structure, clinical findings and etc. In total there are 133 semantic types and 54 semantic relationships defined. 16

23 4 Disease Ontology, Symptom Ontology and UMLS as a starting point. 4.3 Unified Medical Language System (UMLS) Figure 4.1: A Portion of the UMLS Semantic Network: Relations 17

24

25 5 Diseases and Symptoms In Chapter 4 we have discussed Human-Disease Ontology, Symptom Ontology and UMLS Metathesaurus and Semantic Network. Now we use these sources of information and BioPortal mappings to get an overview of the disease and symptom information available at BioPortal. The method we apply in this chapter does not guarantee to gather all the disease and symptom related knowledge, that can be found on BioPortal, but rather focuses on the data that is located at the neighborhood of the selected ontologies. Neighborhood of the ontologies should be understood as a data that can be reached via the mappings from the classes of this ontology. First, we select those ontologies in BioPortal, that we are sure about the existence of the required knowledge in them. In biomedical domain, classes and expressions play important roles in ontologies, in contrast to the instance data within other domains. Therefore, we retrieve the relevant classes to us in the selected ontologies and define them as core classes. Then, we request the mappings that contain a selected class as a mapping source for each of the core classes. We store the targets of these mappings as potential classes, together with the sources of mappings and ontologies they come from. Later on, we decide which of them to keep, based on other facts that will appear in the course of analysis. 5.1 Disease Information BioPortal contains ontologies from diverse fields of biomedical domain. We are mainly interested in those that contain data about diseases and/or symptoms. For the disease information we select Human-Disease Ontology and those ontologies that are filtered as UMLS group on BioPortal. Since DO contains knowledge only about the diseases, we simply consider each of the OWL classes in DO a disease. Besides, there are classes in 138 ontologies that can be reached from the classes of DO via mappings. 19

26 5 Diseases and Symptoms 5.1 Disease Information For retrieval of diseases from UMLS group ontologies, we use semantic type T047 which stands for "Disease or Syndrome" and predicate hassty (Listing 5.1). Listing 5.1: Retrieval of disease classes from UMLS ontologies prefix owl: < select distinct?s from <ontology> where{?s a owl:class; < < } There are 31 ontologies filtered as UMLS group on BioPortal, but only the ones that are listed in Table 5.1 contain classes with semantic type T047. Table 5.1 also shows the number of distinct classes in those ontologies that have semantic type T047, number of classes that can be reached from these classes via mappings, and the number of ontologies those classes appear in. We define the classes with semantic type T047 and the ones in DO as core disease classes, as it was discussed before. The classes that we get via the mappings we call potential classes. Core disease classes in each UMLS group ontology are distinct, but between potential disease classes, there are many overlaps. Acronym #core_classes #connected_classes #connected_ontologies SNOMEDCT MDR RCD ICD10CM OMIM ICD9CM MeSH ICD NDFRT ICPC2P CRISP COSTART WHO-ART LOINC MEDLINEPLUS ICPC AIR Table 5.1: UMLS ontologies that contain classes with semantic type T047("Disease or Syndrome") ("core classes"),number of core classes, number of classes mapped from core classes, number of ontologies the mapped classes are located in. 20

27 5 Diseases and Symptoms 5.2 Symptom Information By applying this method to all ontologies in Table 5.1 we get 219 ontologies and classes involved of these classes have at least one mapping to another class. These mappings have different mapping sources as mentioned in Section In many cases the same mapping might have origin in several of the mapping sources. Once we have the disease information, we might create an overview of the ontologies that shows the connections(mappings) between them. We should remind that we do not claim to have all the disease related knowledge on BioPortal, but rather the data that resides in the neighborhood of the selected ontologies. An overview of the ontologies containing disease information and connections between them is depicted in Figure 5.1 using Gephi [30] visualization tool for graphs. Each node in the graph represents a different ontology at BioPortal. The sizes of the nodes are proportional to the number of disease classes (core and potential) found in that ontology. The colors, changing from red to blue, represent the degree of the node(number of mappings that include the classes of ontology) in the graph. 5.2 Symptom Information The other kind of data we are interested in is the symptom information on BioPortal. We use the same method that was applied in Section 5.1 to fetch the required knowledge. Instead of DO, however, this time we use Symptom Ontology as an ontology which contains only classes about symptoms. The number of distinct classes in SYMP is 936 and the 7105 classes from 119 ontologies are used as a target for mappings from these classes. Also we use UMLS semantic type T184("Sign or Symptom") for further obtaining the symptoms from UMLS group ontologies. The number of symptoms found in those ontologies is shown in Table 5.2. As in the case of diseases, here we also define the classes that we get by using semantic type and the ones in SYMP as core symptoms. The rest of them we consider potential symptom classes. In total we find symptom classes in 161 ontologies and of them are mapped at least to one another class. Figure visualizes the proportion of core symptom classes in each of the selected ontologies as a starting point for symptoms. The picture for the ontologies with symptoms classes and mappings to those, is depicted in Figure Data Overlap In previous sections of this chapter we showed how we get disease and symptom information in BioPortal and visualized relative portions of the classes for each UMLS group ontology. Core sets of the classes are unique for each ontology in the context of disease or symptom information. Nonetheless, some part of the disease and symptom classes overlap between themselves. Disease set contains distinct classes, out of 21

28 5 Diseases and Symptoms 5.3 Data Overlap Figure 5.1: Disease Ontologies Graph which appear in the core. For symptom information, we have classes in the core of set with classes. The overlap between classes means, that the notions of "Disease" and "Symptom" are not well separated. There are four distinguishable cases, as labeled in Figure 5.3 with A, B, C and D. The occurrence of a class in the core of disease set means that it is either from DO or has semantic type T047. If a class is found in the core of symptom set, this indicates that the class is either from SYMP or has semantic type T classes that reside in the intersection of cores of sets (A in Figure 5.3), come from the UMLS group ontologies and have both semantic type T047 and T184, meaning that they can be considered both diseases and symptoms. At this point we asked our expert in medical domain for the help in denoting those classes either by disease, or by symptom. 189 out of 471 were labeled as disease, 234 were labeled as symptom, and on 48 of those classes our expert could not make decision and therefore, we labeled those as both disease and symptom. Since these 471 classes appear in core of both sets, we remove the ones labeled as disease by expert from the core of symptom set, and the ones labeled as symptom from the core of disease set. We decided to keep 48 classes on which we hesitate in both sets and they will be considered a symptom and a disease at the same time. 22

29 5 Diseases and Symptoms 5.3 Data Overlap Figure 5.2: Symptom Ontologies Graph Figure 5.3: Data overlap between disease and symptom data 23

30 5 Diseases and Symptoms 5.3 Data Overlap Acronym #core_classes #connected_classes #connected_ontologies SNOMEDCT MDR RCD ICPC2P ICD10CM OMIM ICD9CM LOINC WHO-ART MeSH ICD ICPC COSTART NDFRT CRISP AIR MEDLINEPLUS Table 5.2: UMLS ontologies that contain classes with semantic type T184("Sign or Symptom") ("core classes"),number of core classes, number of classes mapped from core classes, number of ontologies the mapped classes are located in. We stored the core classes together with the mappings, where they are playing the role of source. This means, that the targets of those mappings were included among the potential classes of that set. Thus, when we remove classes from the core, we have to remove potential classes that were used as target for the mappings that use the core classes as a source. Here we have to take care that these potential classes were used only in the mappings with the classes that we are going to remove. If they also appear in the mappings with other core classes, we keep them. Removing 234 classes from disease set leaves us with classes and removal of 189 classes from symptom set leaves us with classes. The classes appearing in a core of one set and among potential classes of the other, can be removed from the set, which contains it among potential classes, since it appears to be there due to the mappings. We assume, that predicate hassty is a stronger indication about the origin of a class than mappings. Removal of the some core classes mentioned above, also changes the number of potential classes. After that process, we have 4713 classes in core of disease set that are also potential symptom classes (C in Figure 5.3), and 1918 classes other way around (B in Figure 5.3). Thus, we can remove 4713 classes from symptom set and 1918 classes from disease set. For the last case, where potential classes from each set (D in Figure 5.3) overlap, we are left with 5139 classes. To disambiguate the type for these classes, we retrieve the classes from BioPortal that they are mapped to. We regard them as disease if they are mostly mapped to the classes in the core of disease set, as symptom otherwise. This way we consider 2847 classes a disease and 2292 classes a symptom class. After deletion 24

31 5 Diseases and Symptoms 5.3 Data Overlap of these classes, we have classes in disease set and classes in symptom set. Since the separation process does not change the sets drastically, we don t present new overviews for the connections between ontologies for the selected data. 25

32

33 6 Disease-Symptom Relationships One of the important questions and motivational points for us was the identification of diease-symptom relationships and their retrieval from the ontologies in BioPortal. In Chapter 5 we showed how we get and identify classes as a "Disease" or as a "Symptom". Now, we can use this acquired information to find the connections between them. Without this knowledge, we would have to analyse all the data on BioPortal, which could have taken too much time. One could suggest to find the predicates used in ontologies to connect diseases to symptoms, by separate analysis of each predicate. However, more than 2600 distinct properties are used in BioPortal ontologies. Moreover, some of the predicate names consist of just a URI, which also makes it difficult to answer the question, whether a property is used to connect diseases and symptoms, or not. Having the disease and symptom classes at hand, we look for the direct connections between them in the ontologies. Here we have two separate cases for UMLS group ontologies and the rest of them, that contain classes from both disease and symptom sets. We are searching disease-symptom relationships only between classes that occur in the same ontology. Although we have two different situations, we use the same method to retrieve the relations. We make an assumption, that if there is a structured disease-symptom relation, such that indicates that the certain disease class has the certain symptom class as a symptom, it should be stored in a one triple as a direct connection. Therefore, we check the triples of the form < entity1 > < predicate > < entity2 >, where either < entity1 > is a disease class and < entity2 > is a symptom class, or the other way around. 27

34 6 Disease-Symptom Relationships 6.1 UMLS group ontologies 6.1 UMLS group ontologies To find the disease-symptom connections in UMLS group ontologies, we iterate over those ontologies and for each we make the SPARQL query shown in Listing 6.1. Listing 6.1: Retrieval of disease-symptom connections from UMLS ontologies SELECT distinct?subject?predicate?object FROM < WHERE {?subject < < < < } As we have already described in Chapter 5, we remove part of the classes from the sets of disease and symptoms. When we get results for the query shown in Listing 6.1, they also include the classes with both semantic types. We filter out the results by removing the data that contain deleted classes. Table 6.1 shows the resulting predicates for the direct disease-symptom connections in the triples of UMLS group ontologies and the number of diseases that were used as subject in those triples. To find symptom-disease connections, we simply change the positions of?subject and?object in the third constraint of the SPARQL query in Listing 6.1 and again filter out the results of the queries. The predicates for the direct symptom-disease connections in the triples of UMLS group ontologies and the number of times the symptoms were used as a subject of the triple are shown in Table 6.2. As we can see from the Tables 6.1 and 6.2, the predicates ending with SIB are ones that are used more than others in total. The abbreviation SIB means that the classes used as subject and object in a triple, have sibling relationship in a Metathesaurus source vocabulary. RN, RB and RO are used to show narrower, broader and other than synonymous, narrower, or broader relationships, in a given order. Since we are looking for relations, that would indicate the co-occurrence of the symptom and disease, these predicates can not be regarded as those we need. They rather show structural relationships between different classes. Although we have tried to separate the disease set from the symptom set, these connections imply, that the notions of "disease" and "symptom" are not perfect and they overlap. Another frequently used relationship is the rdfs:subclassof predicate, which shows hierarchical relationship between different classes in the ontology. As in the case of the predicates mentioned above, this is also the case that shows us the imperfect notions of "disease" and "symptom" in those ontologies. Being more specific, there are many classes in the UMLS group ontologies, that have semantic type "Disease or Syndrome", however, they appear to be the subclasses of a class with the semantic type "Sign or Symptom", and vice versa. As it was shown in Chapter 5, there are also classes with both semantic types. 28

35 6 Disease-Symptom Relationships 6.1 UMLS group ontologies Count Predicate Table 6.1: Predicates in triples of the form < disease > < predicate > < symptom > and number of diseases used as subject of the triple in UMLS group ontologies 29

36 6 Disease-Symptom Relationships 6.1 UMLS group ontologies Table 6.2: Predicates in triples of the form < symptom > < predicate > < disease > and number of usages of symptoms as a subject of such triple in UMLS group ontologies 30

37 6 Disease-Symptom Relationships 6.2 Non-UMLS ontologies In some ontologies, the subclass relationships are even more complex. Figure 6.1 shows these connections between classes having semantic type T047, T184 and both in Medical Subject Headings (MeSH) ontology. Green circles represent the classes with semantic type "Sign or Symptom", red dots the classes with semantic type "Disease or Syndrome" and blue circles represents a class that has both semantic types. Moreover, there are also such predicates, as classified_as, mapped_to, classifies, and etc. that are not specific to the disease-symptom relations, rather to structural knowledge. Among the predicates that are listed in Tables 6.1 and 6.2, we consider only has_manifestation relevant for disease-symptom relationships, and manifestation_of for the symptom-disease relationships. These two properties are inverse predicates and thus connect the same classes. We include these relationships as hassymptom connections in our data model. 6.2 Non-UMLS ontologies We repeat the same process for the non-umls ontologies. In this case, since we don t have semantic types, we simply iterate over the ontologies and for each ontology we are looking at the triples, where symptom classes are used as an object. Table 6.3 shows the predicates that were used in triples, where potential disease class is a subject and potential symptom class is an object, together with the number of distinct disease classes used with these predicates. (a) before (b) after Figure 6.1: Subclass relationships between disease-symptom data in Medical Subject Headings, before and after separating disease set from symptom set. 31

38 6 Disease-Symptom Relationships 6.3 Data Model Table 6.3: Predicates in triples of the form < disease > < predicate > < symptom > and number of usages of diseases as a subject of such triple in non-umls ontologies Table 6.4 contains information about the predicates used in triples, where potential symptom class is a subject and potential disease class is an object, together with the number of distinct symptom classes used with these predicates. As we can see from Tables 6.3 and 6.4 most frequently used predicate to connect the potential disease and symptom classes is rdfs:subclassof, and as we discussed before, we don t consider it a disease-symptom specific relationship. Also the other properties like is_a and disjointwith are used for structural information between classes and thus, we disregard all these properties. 6.3 Data Model With all the data we have retrieved, we can try to create a model that subsumes disease and symptom information, as well as the information about their co-occurrence. Although we could not find too much of the latter type of knowledge on BioPortal with our method, we will try to group diseases and symptoms together, to get more information connected. In Chapter 7 we describe this in more detail Table 6.4: Predicates in triples of the form < symptom > < predicate > < disease > and number of usages of symptoms as a subject of such triple in non-umls ontologies 32

39 6 Disease-Symptom Relationships 6.3 Data Model First of all, we store all disease and symptom URIs as classes and indicate which type the class has with predicate hastype. We use predicate from for each class to show in which ontologies it occurs. One class URI might occur in one, as well as in many different ontologies. To represent the mappings between classes, we use the mapping sources as a predicate. Also we define these predicates as a subproperty of a predicate ismappedto to make it possible to query the mappings without discriminating their sources. For each class we also store the preferred labels as strings using the predicate skos:preflabel. One class might have one or more preferred labels. Together with the properties listed above, we also put the subclass information in our data model. We store the subclass relationships among disease classes, among symptom classes and between disease and symptom classes. The last piece of data that we also represent in our data model, are the symptoms for diseases. We use predicate hassymptom for this purpose. Listing 6.2 shows triples for one class from OMIM ontology. Listing 6.2: View from Disease-Symptom Ontology < a owl:class ; mapping:umls_cui < < ; disy:hassymptom < disy:hastype disy:disease ; disy:islocatedin bioontology:omim ; skos:preflabel "ichthyosiform erythroderma, corneal involvement, and deafness"^^xsd:string. } 33

40

41 7 Disease and Symptom Graphs In previous chapters we have shown how we search disease and symptom related data on BioPortal, also how we search the symptoms for diseases. As it was mentioned in Chapter 5, we had some overlap between disease and symptom data in the first step. After separating these data, we are left with disease and symptom classes. However, this does not imply that all of the classes are for distinct diseases or classes are about completely different symptoms. Many of the classes might actually be about the same disease or symptom, but have synonymous labels. In fact, many classes even have exactly the same label, but just different URIs. Thus, in this chapter we will try to group the classes for disease and symptom data. This will also result in connection of more disease and symptom classes. 7.1 Disease Graph In Chapter 5 we have described how we use BioPortal mappings to get more data. Although there are 6 mapping sources, only 2 of them: Loom and UMLS_CUI are mainly used with disease classes. If we consider these classes vertices and the mappings between them edges, we can create a disease graph Default approach Considering the disease data as a graph, one very natural way of grouping the classes would be to cluster them in the form of connected components of the graph. Connected component, or simply component in undirected graph is a subgraph in which any two vertices are connected to each other by paths. By using different mapping sources, or combination of all of them, we can create different components and group the class URIs in the components as classes that represent the same disease. 35

42 7 Disease and Symptom Graphs 7.1 Disease Graph (a) All (b) Loom (c) UMLS_CUI Figure 7.1: Histogram of connected component sizes for different mapping sources in disease graph. Figure 7.1 shows histograms of sizes for different clusterings of the disease graph. For a better picture, we have depicted log of the sizes and counts. In Figure 7.1(a) all mappings were used as edges to create the graph. For this case we get clusters and the biggest cluster contains disease classes. In Figure 7.1(b) only loom mappings were used to create the graph and we get clusters with biggest cluster containing disease classes. Figure 7.1(c) shows the results for the case where only umls_cui mappings are used as edges in the graph. Here we have clusters with biggest cluster of size disease classes. Obviously, this is not the best way of clustering disease classes. Since we want to group different disease classes about the same disease or syndrome in the same cluster, it s highly improbable that there are or distinct disease classes for the same disease. In many cases classes of specific diseases might have mappings to more general diseases and vice versa. Especially many classes from the hierarchy of the same ontology might have mappings among themselves. 36