Intellectual Analysis of Making Decisions Tree in Information Systems of Screening Observation for Immunological Patients Lyubomyr Chyrun[0000-0002-9448-1751]1, Eugene Leshchynskyy[0000-0001-7627-5252]2, Vasyl Lytvyn[0000-0002-9676-0180]3, Antonii Rzheuskyi[0000-0001-8711-4163]4, Victoria Vysotska[0000-0001-6417-3689]5, Yuriy Borzov[0000-0002-0604-0498]6 1Ivan Franko National University of Lviv, Lviv, Ukraine 2LvivSoft, Lviv, Ukraine 3-5Lviv Polytechnic National University, Lviv, Ukraine 6Lviv State University of Life Safety, Lviv, Ukraine chyrunlv@gmail.com1, leshhynskyy@gmail.com2, vasyl.v.lytvyn@lpnu.ua3, antonii.v.rzheuskyi@lpnu.ua4, Victoria.A.Vysotska@lpnu.ua5, uob1968@gmail.com6 Abstract. The aspects of the design of an immunological patient screening ob- servation information system related to the required system functionality are discussed. Practical solutions for individual operational challenges are suggest- ed. Functional requirements for the designed information system are defined. Based on the outlined functional needs, the appearance of the kernel of the in- formation system is determined, namely, in what form the entered data will be stored. Some functions of rules set formation for Machine learning and Neural Network building based on Making Decisions Tree, which have to be resolved by system, are defined. Practical solutions are proposed for specific tasks that are entrusted to the information system. Keywords. Information system, Intellectual Analysis, Data mining, Immuno- logical Patients, Making Decisions Tree, Machine learning 1 Introduction Data mining is an integral part of the knowledge discovery in data bases process [1]. It allows us to uncover the essence of hidden dependencies in the data, to identify interactions between the properties of objects, information about which is stored in databases, to highlight the patterns inherent in a particular set of data [2]. The urgency of the problem of data exploration and processing is confirmed by the widespread practical and commercial use of intellectual analysis systems [3]. Most often they are used in the scientific field and business [4]. Hierarchically organized data and work with them is an important place in human life [5]. The structure of such data is char- acterized by the specific relations of its elements, namely, features of imitation and Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0) 2019 IDDM Workshops. subordination between elements of the hierarchy [6]. Therefore, when creating an information system for the subject area, characterized by these features, an important issue to be paid attention to is the storage of not only data but also their structure [7]. 2 Analysis of current research The relatively new methodology of rough sets is naturally adapted to work with im- perfect data [8]. The theory of rough sets was developed by Z. Pawlak [1] as a math- ematical tool for overcoming data contradictions and revealing hidden patterns or patterns in them. A fundamental principle of the example learning algorithm using rough sets is to identify redundancy among the available features that describe the example [9]. This is how strong signs that influence the classification of an example are revealed. Next, remove the columns whose attributes do not affect the classifica- tion [10]. Only the attributes on which the classification of the table examples is de- pend on the analysis [11]. The remaining attributes are called redundant [12]. In other words, a reducer is a subset of all table attributes that provide the same classification result for all table instances as the entire set of examples [13]. Finding a reducer is an NP challenge [14]. However, there are enough effective methods to solve this task within an acceptable time [15]. Such methods include, in particular, Boolean reason- ing [16-19], Johnson's algorithm [20-23]. 3 Statement of the problem The life cycle of information begins with its creation [24-29]. Therefore, as noted in [1], information about the patient can be obtained and pre-systematized to fill in the questionnaire of the established sample. A survey of the real questionnaire was also conducted and the shortcomings encountered in filling it out were identified [30-33]. It was also noted that the information submitted to the questionnaire has a clearly defined hierarchical structure [34-38]. To automate and simplify the process of filling out the questionnaire, the following provisions were defined [39]: 1. Determine the ratio of subordination of one item of the questionnaire to anoth- er (to actually determine the appearance of the hierarchy) [40]; 2. To determine the domains of possible values to limit the “free” entry of data for the relevant items of the questionnaire [41]. A variant of practical solution to the problem of collecting and entering information by filling and saving the corresponding “electronic” analogue of the questionnaire was also proposed [42]. This avoided many inconveniences and uncertainties and, in general, automated the process of "converting" data to electronic form [43]. It should be noted that the following [1] had several "structural" disadvantages, namely: 1. The structure of the stored data had a linear appearance and did not in any way reflect the existing hierarchical dependencies between the corresponding items of the questionnaire [44]; 2. Regardless of the number of questionnaire items filled in per patient, the values of all items were stored (even if these were blank). Obviously, this approach, despite the meager amount of "unnecessary" data, does not set a good tone when designing an information system [45]. In [46], a variant of hierarchical information using frames was proposed. In [1], as a practical extension of the idea outlined in [47], the mechanism of processing and stor- ing data of a completed questionnaire based on the use of frames was considered. 4 Functional requirements definition Entering information. As noted above, the life cycle of information begins with its creation. It should be noted that in item # 6 of the questionnaire (Fig. 1) it is envis- aged to enter information about the stage of treatment (“primary”, “repeated”). So, let's distinguish the following tasks: 1. Entering the data of the patient being examined for the first time (“primary”); 2. Entering the data of the patient who has come for re-examination ("re- examination"). By the way, there can be several such calls. Fig. 1. Fragment of questionnaire form In the first case it is necessary to fill in the questionnaire of the established sample. The second is the same, but it can be assumed that the "repeated" questionnaire does not undergo significant changes, so it would be convenient to re-enter the question- naire only to correct the data entered in the primary card. Therefore, when making a "repeat" patient, it would be convenient to find the appropriate primary questionnaire, make a copy of it and edit the last one. Therefore, the data entered should be stored in a convenient way: 1. Search for the required primary (or last completed) questionnaire; 2. Display of the entered data in the form of the second questionnaire. Development environment. The prototype of the information system was imple- mented using the Web interface [1]. Recall that in this case, after filling in the ques- tionnaire, pressing the "Save" button initiates the process of registration of the entered data in a special object REQUEST and transfer it for processing to the system server. The REQUEST object looks like a hash table [1]. Therefore, the look of the stored data should be easy to generate by simply pro- cessing the data in the corresponding hash table. Accounting information. With the advent of data entry and storage tools, the sys- tem begins to perform database functions. There is a need for accounting that is natu- ral for databases, for example: 1. Search of patients' cards according to a number of specified parameters (possi- bility to make a sample); 2. Removal and editing of completed questionnaires; 3. Backup and backup of the questionnaire; 4. Playback of stored data in a user-friendly way; 5. Obtaining a “hard” copy of the patient's card; 6. Archiving of data. Analysis and statistics. Because the system is designed as a screening system, the look of the data should make it easy to find the information you need. This can be used both to sample according to specified criteria (for research) and to prepare re- ports of the required form. Transformation. To date, the classification of diseases is defined in the document on the international classification of diseases MKH-10 [1]. Obviously, there is an opportunity to review and modify existing provisions in this classification. This will change the form in which the data is to be obtained (although the content of the in- formation may not change). It is logical to assume that the stored data should also be brought in a new form as required. We substantiate the importance of this point in the example. Antiallergic drugs Atrovent Anti-allergic drugs B-adrenomimetics Atrovent Berotech Berotech Budesonide Budesonide Ventolin Ventolin Salbutamol Salbutamol Lecrolin antileukotriene Lecrolin Baconage topical steroids Baconage Becotide Becotide Cromoglin Cromoglin Kromosol Kromosol Fig. 2. An example of transformation Fig. 2 illustrates the need for various transformations in the structure of the question- naire. The second column on the left contains is a list of some drugs, and suppose you need to enter an additional classification for these drugs, which leads to the appear- ance of an additional column on the right. If certain drugs were prescribed to the pa- tient and the relevant data were entered into the questionnaire prior to structural trans- formation, then obviously, after transformation of the questionnaire, the stored data should be modified and brought to the appropriate appearance. We illustrate the previous case with the help of a tree (Fig. 3). Anti-allergic drugs antileukotriene B-adrenomimetics topical steroids Atrovent Budesonide Salbutamol Baconage Cromoglin Berotech Ventolin лекролін Becotide Kromosol Tree restructuring Anti-allergic drugs B-adrenomimetics antileukotriene topical steroids Atrovent Budesonide Salbutamol Baconage Cromoglin Berotech Ventolin лекролін Becotide Kromosol Fig. 3. An example of transformation in a tree structure So, with the questionnaires already filled in, you need to review them and modify the hierarchical dependencies between the data. Obviously, the data form should allow it to be done quickly and conveniently. In summary, it can be said that the form of presentation in the designed system should allow the following operations to be performed efficiently and conveniently: 1. Formation (creation) of data by processing the hash table; 2. Search for analysis and statistics; 3. Implementation of transformations; 4. Interpretation of the data entered in order to: 5. Obtaining a “hard” copy of the data in a convenient form; 6. Displaying data for editing purposes; 7. Displaying data for the purpose of introducing a 'repeat' patient. 5 Method of storing hierarchical data using N-tree Let's take a closer look at the data storage process that has been implemented so far. Let, in Fig. 4 provides a form in which to obtain information about the availability of a patient referral for examination. Institution data yes Doctor data Pointing yes Diagnosis when pointing no no Fig. 4. The form in which you need to get information about the presence of directions We construct an interface (questionnaire form) that corresponds to this form (Fig. 5). In Fig. 5 also lists the names of the corresponding visual form controls. APPOINTMENT_7 INSTITUTION DOCTOR DIAGNOSIS Fig. 5. The interface corresponding to the form in fig. 4 Following the principles of object-oriented programming, the PATIENT class was created, whose properties were all the data provided in the questionnaire (Fig. 6). PATIENT APPOINTMENT_7 INSTITUTION DOCTOR DIAGNOSIS Fig. 6. Structure of the PATIENT class As stated above, the structure of the class PATIENT is linear and in no way reflects the hierarchical dependence that exists between the individual items of the question- naire. REQUEST={APPOINTMENT_7 : ’yes’, REQUEST={APPOINTMENT_7 : ’no’, INSTITUTION : ’NAME’, INSTITUTION : ’’, DOCTOR : ’therapist’, DOCTOR : ’therapist’, DIAGNOSYS : ’no’} DIAGNOSYS : ’no’} PATIENT 1 PATIENT 2 APPOINTMENT_7 : ‘yes’ APPOINTMENT_7 : ‘no’ INSTITUTION : ‘NAME’ INSTITUTION : ‘’ DOCTOR ; ‘therapist’ DOCTOR ; ‘therapist’ DIAGNOSIS ; ‘no’ DIAGNOSIS ; ‘no’ Fig. 7. The process of storing data In Fig. 7 depicts a data retention process for two different patients. In both cases, when trying to save the completed questionnaire data, they are formed into a REQUEST object and passed to the server for processing, then PATIENT physical objects are created and, since the class structure is static, in PATIENT 1 and PATIENT 2 objects Stores the values of all properties available in REQUEST. For the first patient, the value of "Point" (APPOINTMENT_7) is marked as "yes", so it is advisable to keep hierarchically subordinate to him the INSTITUTION, DOCTOR and DIAGNOSYS items. For the second patient, the value of "Pointing" is marked as "no", so saving the remaining points is not appropriate, but due to the static structure of the class "PATIENT", their values are stored (even when they are empty). In [1], a mechanism for storing questionnaire data using a frame was proposed, but the disad- vantage of this was the need to view all frame slots, regardless of whether or not the slot data was required. Consider the mechanism of storing the input data using the N- ary tree. For example, consider the fragment of the questionnaire shown in Fig. 8. Date of examination data Patient data Institution data allergist Doctor therapist yes Pointing other data yes Diagnosis when pointing no no Fig. 8. Fragment of the questionnaire Let us now depict this fragment as an N-ary tree (Fig. 9). Questionnaire Date of examination Patient Pointing yes no Institution Doctor Direction diagnosis another allergist therapist another doctor Fig. 9. Presentation of the questionnaire from fig. 8 in the form of an N-ary tree From Fig. 9 it can be seen that certain values of the individual items of the question- naire make it possible to descend to the next level of the hierarchy. For "Pointing" this value is "Yes" and for "Doctor" the value is "Other". Now suppose some data were collected in the questionnaire and the corresponding REQUEST objects were sent to the server for processing. Patient №1 Patient №2 REQUEST={‘Date of examination’ : ’10.06.19’, REQUEST={‘Date of examination’ : ’10.06.19’, ‘Patient’ : ‘Petrenko P.P.’, ‘Patient’ : ‘Ivanenko I.I.’, ‘Pointing’ : ’yes’, ‘Pointing’ : ’no’, ‘Institution’ : ’NAME’, ‘Institution’ : ’’, ‘Doctor’ : ’other’, ‘Doctor’ : ’’, ‘Other Doctor‘: ‘surgeon‘, ‘Other Doctor’ : ‘’, ‘Directional diagnosis’ : ’no’} ‘Directional diagnosis’ : ’no’} Make a tree traversal down, given the importance of the individual items of the questionnaire, which give access to the next level of the hierarchy. The procedure for traversing tree nodes: 1) Questionnaire 2) Date of examination 3) Patient 4) Pointing 5) Institution 6) Doctor 7) Other doctor 8) Directional diagnosis Patient card 1 Patient card 2 Анкета : А1 Анкета : А2 Date of examination : 10.06.19 Date of examination : 10.06.19 Patient : Petrenko P.P. Patient : Ivanenko I.I. Pointing : yes Pointing : no Institution : NAME Doctor: Other Other doctor: surgeon Directional diagnosis: no Fig. 10. The process of processing a REQUEST object using a tree As can be seen from Fig. 10, a top-down tree is traversed corresponding to the hierar- chical structure of the questionnaire. However, for individual nodes, the next level of the hierarchy can be accessed only with a certain parent node value defined. Thus, for the first patient, the value of "Pointing" is defined as "yes", therefore, the transition to a lower level takes place and the units "Institution", "Doctor" and "Diagnosis at refer- ral" are taken for consideration. Since the value "Other" is set for the Doctor node, the value of "Other Doctor" is considered at the subordinate level. For the second patient, the value "no" for "Direction" does not allow access to the next tree level, so subordi- nate nodes are not considered at all. Thus, for the second patient, only the data with the contents will be stored on the card. Note that this approach not only saves space, but also eliminates the need to consider "unnecessary" data. So, the general idea is that when processing each typed questionnaire, you need to crawl from top to bottom of a given tree, taking into account the "bypass" values for the corresponding nodes of the tree. The question is: how to build such a tree? We use a frame for this purpose. For the example above, the frame will look like this (Figure 11): Patient_id: Exam Date, Patient, Referral / Is Directing: Institution, Doctor / Other, Diagnosis of referral Doctor: Another doctor Fig. 11. The frame view for the questionnaire from fig. 8 As can be seen from the picture, the frame is actually a two-dimensional list, which specifies the tree structure and the "bypass" values for the corresponding items of the questionnaire. In each frame of the frame, the first element denotes the parent node, and all subsequent elements in the row represent child nodes. In Fig. 12 illustrates the process of constructing a tree from a given frame. Date of Patient_id Patient Direction / yes examination Pointing Institution Doctor / Other Direction diagnosis Doctor Another doctor 5) search - found 1) create Patient_id 3) create 2) create Date of examination Patient Pointing 4) create 7) create 6) create 8) create Institution Doctor Direction diagnosis 9) search - found Another doctor 10) create Fig. 12. The mechanism of construction of N-pillar tree from a frame As can be seen from the figure, the tree of the desired structure is constructed by se- quentially viewing the corresponding frame. The first element (Direction, Doctor) of each frame of the frame (except for the first line where all elements must be created) is searched for a node already built that corresponds to this element, after which the found node descendants are built. Note that in the process of construction, it is neces- sary to store the "bypass" values for the elements in which it is defined. Thus, the scheme of storing only the necessary data becomes quite convenient and transparent. The sequence of this process is shown in Fig.13. Set the frame to the desired structure Questionnaire Build a tree based on a ES T frame QU RE Bypass the built tree top-down. While at each tree node, consider the corresponding element in REQUEST, comparing the value of the element with the "bypass" value of the tree node. Fig. 13. Data storage scheme As to the appearance in which the data will be stored for the moment, let's say: by- passing the tree, we will write each considered pair "element - value of element" in a separate line (like the one shown in Fig. 9). Until now, we have considered the case where the questionnaire item had only one value, which allowed to move to the next level of the hierarchy (the value "yes" for "Pointing" and "other" for "Doctor"). How- ever, there may be situations where multiple values (or even each) lead to a lower level. For example, consider the fragment of the questionnaire depicted in Fig. 14. congenital (antena- HIV / AIDS tal) infec- known By etiolo- tious herpes viruses I, II acquired (postnatal) gy (HerSVI,II) un- known Fig. 14. Fragment of the questionnaire illustrating the “gravitas” of some points of the ques- tionnaire Note that the values "congenital" and "acquired" are mutually exclusive, and the choice of each leads to the next level of hierarchy ("infectious"). In this situation, the infectious and other subordinate levels are the same for the two values, but they may be different. Consider how the previously described storage mechanism works in this case. But we are modifying the frame somewhat, as some of the questionnaires now have more than one "bypass" value. The questionnaire interface, corresponding frame and tree are shown in Fig. 15. ID_ETIOLG ETIOLG_KNOW INF INF_VIL Interface INF_HSV Frame Patient_id: ID_ETIOLG / known ID_ETIOLG / known: ETIOLG_KNOW / antenatal; ETIOLG_KNOW / Postnatal ETIOLG_KNOW / antenatal: INF / is ETIOLG_KNOW / Postnatal: INF / is INF / is: INF_VIL; INF_HSV Patient_id Tree ID_ETIOLG/know ETIOLG_KNOW/antenatal ETIOLG_KNOW/postnatal INF/yes INF/yes INF_VIL INF_HSV INF_VIL INF_HSV Fig. 15. Interface, frame, and tree for multiple bypass values As you can see in the picture, the idea of defining a tree structure with a frame re- mained, but now the tree node is further identified by a "bypass" value. Now let's consider the process of data storage directly (see Fig. 16). Patient 2 Patient 1 REQUEST={ ID_ETIOLG : ’known’, REQUEST={ ID_ETIOLG : ’known’, ETIOLG_KNOW : ‘antenatal’, ETIOLG_KNOW : ‘postnatal’, INF : ’yes’, INF : ’yes’, INF_VIL : ’yes’} INF_VIL : ’yes’} The procedure for traversing a tree: 1) Patient_id 2) ID_ETIOLG WALKING WALKING 3) ETIOLG_KNOW (antenatal) AROUND THE AROUND THE 4) INF TREES TREES 5) INF_VIL 6) INF_HSV 7) ETIOLG_KNOW (Postnatal) Patient_id: A1 4) INF Patient_id: A2 ID_ETIOLG: Known 5) INF_VIL ID_ETIOLG: Known ETIOLG_KNOW: antenatal 6) INF_HSV ETIOLG_KNOW: Postnatal INF: yes ETIOLG_KNOW: Postnatal SAVING THE PATIENT INF_VIL: yes INF: yes CARD ETIOLG_KNOW: antenatal INF_VIL: yes Fig. 16. Scheme of the process of data storage for the case of several "bypass" values The process of data storage takes place according to the scheme already considered (Fig. 13), but it can be noticed that the value of the element ETIOLG_KNOW is stored in the card twice (exactly two mutually exclusive values are provided for this item of the questionnaire). This happens for the following reason: when bypassing the tree for the first patient while in the node ETIOLG_KNOW / antenatal, REQUEST looks for the key ETIOLG_KNOW, takes its value (antenatal), comparing the latter with the bypass value of the node (antenatal) gives a positive result and moves to the next level of the hierarchy; however, in the further crawl, being at the node ETIOLG_KNOW / postnatal, again in REQUEST the key ETIOLG_KNOW is searched, its value (again "antenatal") is taken, comparing the latter with the bypass value of the node (postnatal) gives a negative result, there is no transition to the next level, but since the call to the ETIOLG_KNOW / postnatal node has been completed, this is recorded in the patient card as another line ETIOLG_KNOW: antenatal. A similar situation occurs with the second patient, however, the order in which the lines in the card are followed differs slightly from the first patient (due to tree crawling). The identified deficiency can be corrected by removing unnecessary (unnecessary) branches with a root in the corresponding "multivalued" node before processing the questionnaire data. This process is illustrated in Fig. 17. Patient 1 Patient 2 REQUEST={ ID_ETIOLG : ’known’, REQUEST={ ID_ETIOLG : ’known’, ETIOLG_KNOW : ‘antenatal’, ETIOLG_KNOW : ‘postnatal’, INF : ’yes’, INF : ’yes’, INF_VIL : ’yes’} INF_VIL : ’yes’} REMOVAL OF “NON- Patient_id Patient_id REQUIRED” TREES OF TREES ID_ETIOLG/known ID_ETIOLG/known ETIOLG_KNOW/antenatal ETIOLG_KNOW/postnatal ETIOLG_KNOW/antenatal ETIOLG_KNOW/postnatal INF/yes INF/yes INF/yes INF/yes INF_VIL INF_HSV INF_VIL INF_HSV INF_VIL INF_HSV INF_VIL INF_HSV DELETING WALKING AROUND THE TREE Patient_id: A1 AND CARD SAVING Patient_id: A2 ID_ETIOLG: Known ID_ETIOLG: Known ETIOLG_KNOW: Antenatal ETIOLG_KNOW: Postnatal INF: yes INF: yes INF_VIL: yes INF_VIL: yes Fig. 17. Removal of unnecessary tree branch with root in "multivalued node" 6 Interpretation of stored data It has been determined that the input of the input data is required for several purposes. Consider the process of interpreting data to obtain a "hard" copy of a patient's card. It is clear that such a copy can be obtained by printing the corresponding text file on paper. At present, patient data is stored as a sequence of rows of element-value ele- ment pairs, and it is obvious that this form of data does not reflect the hierarchical dependencies defined between the items of the questionnaire. An acceptable print layout might be, for example, the shape shown in Fig. 18. It is easy to see that the written sequence of rows corresponds to the sequence of traversing the corresponding tree from top to bottom. A general diagram of the process of obtaining a card for printing is shown in Fig. 19. Acceptable printable card for patient Card obtained by crawling a tree Patient 1 Patient_id: A1 Immunodeficiencies by etiology: known ID_ETIOLG: Known type of immunodeficiency: antenatal ETIOLG_KNOW: antenatal infectious immunodeficiencies: INF: yes HIV / AIDS INF_VIL: yes The order of the items following the lines is the same Fig. 18. Matching the tree-to-bottom crawl sequence of the data display sequence Information about the level of elements of the hierarchy and Saved card Ukrainian analogues of Latin names Показати більше ID_ETIOLG: Immunodeficiencies by etiology: Level 1 Patient_id: A1 ETIOLG_KNOW: Type of immunodeficiency: Level 2 ID_ETIOLG: Known INF: infectious immunodeficiencies: Level 3 ETIOLG_KNOW: antenatal INF_VIL: HIV / AIDS: Level 4 INF: yes Reading information INF_VIL: yes about an element of the hierarchy Forming a card for printing Level 1 tab Patient 1 - Immunodeficiencies by etiology: known Level 2 tab ------ immunodeficiency type: antenatal ----------- infectious immunodeficiencies: Level 3 tab ---------------- HIV / AIDS Level 4 tab Fig. 19. Receiving a card for printing by adding a tab to the saved card Therefore, you can retrieve the print card from the saved card by adding indentations on the left. The amount of indentation is determined by the specified hierarchical element level. 7 Conclusions For the projected information system, a number of necessary executable functions were defined, based on which the functional requirements to the kernel of the system were formed and the question was asked: in what form the data should be stored in order to allow the system to efficiently solve the tasks assigned to it. The main unre- solved issues up to this point were: how to store only the required data and how to save information about the hierarchical structure of this data? To solve the first prob- lem, an approach based on the use of n-tree arrays and frames was proposed, as well as some specific situations that were encountered. With regard to the second problem, it was solved in part by the example of obtaining a "hard copy" of the patient's card. At the practical level, the problems of hierarchical data editing and transformation implementation remain unresolved. Thus, we can conclude that the approaches de- scribed in the article are general and can be applied to any subject areas with hierar- chical organization of information. References 1. Pawlak, Z.: Rough sets: Theoretical aspects of reasoning about data. In: Springer Science & Business Media, 9. (2012) 2. Iturrioz, J., Azpeitia, I., Díaz, O.: Generalizing the like button: empowering websites with monitoring capabilities. In: Proceedings of the 29th Annual ACM Symposium on Applied Computing, 743-750. (2014). 3. Maggi, F., Robertson, W., Kruegel, C., Vigna, G.: Protecting a moving target: Addressing web application concept drift. In: International Workshop on Recent Advances in Intrusion Detection, Springer, Berlin, Heidelberg, 21-40. (2009). 4. Christensen, J. H.: Using RESTful web-services and cloud computing to create next gener- ation mobile applications. In: the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and applications, 627-634. (2009). 5. Neugschwandtner, M., Neugschwandtner, G., Kastner, W.: Web services in building au- tomation: Mapping knx to obix. In: Int. Conf. on Industrial Informatics, 87-92. (2007). 6. Tkachenko, R., Izonin, I., Kryvinska, N., Chopyak, V., Lotoshynska, N., Danylyuk, D.: Piecewise-linear Approach for Medical Insurance Costs Prediction using SGTM Neural- Like Structure. In: CEUR Workshop Proceedings, 170-179. (2018) 7. Tepla, T., Izonin, I., Duriagina, Z., Tkachenko, R., Trostianchyn, А., Lemishka, І., Kulyk V., Kovbasyuk, Т.: Alloys selection based on the supervised learning technique for design of biocompatible medical materials. In: Archives of Materials Science and Engineering, 93/1, 32-40. (2018) 8. Vysotska, V., Lytvyn, V., Burov, Y., Gozhyj, A., Makara, S.: The consolidated infor- mation web-resource about pharmacy networks in city. In: CEUR Workshop Proceedings, 239-255 (2018) 9. Kravets, P.: The control agent with fuzzy logic. In: Perspective Technologies and Methods in MEMS Design, MEMSTECH'2010, 40-41 (2010) 10. Bisikalo, O., Ivanov, Y., Sholota, V.: Modeling the Phenomenological Concepts for Fig- urative Processing of Natural-Language Constructions. In: CEUR Workshop Proceedings, Vol- 2362, 1-11. (2019) 11. Babichev, S., Taif, M.A., Lytvynenko, V., Osypenko, V.: Criterial analysis of gene expres- sion sequences to create the objective clustering inductive technology. In: 2017 IEEE 37th International Conference on Electronics and Nanotechnology, 244-248. (2017) 12. Babichev, S., Gozhyj, A., Kornelyuk A., Litvinenko, V.: Objective clustering inductive technology of gene expression profiles based on SOTA clustering algorithm. In: Biopoly- mers and Cell, 33(5), 379–392. (2017) 13. Babichev, S.A.: An evaluation of the information technology of gene expression profiles processing stability for different levels of noise components. In: Data, 3(4), art. 48. (2018) 14. Shakhovska, N. B., Noha, R. Y.: Methods and tools for text analysis of publications to study the functioning of scientific schools. In: Journal of Automation and Information Sci- ences, 47(12). (2015) 15. Bobalo, Y., Stakhiv, P., Mandziy, B., Shakhovska, N., Holoschuk, R.: The concept of elec- tronic textbook "Fundamentals of theory of electronic circuits. In: Przegląd Elektrotech- niczny, 88 NR 3a/2012, 16-18. (2012) 16. Shakhovska, N., Shvorob, I.: The method for detecting plagiarism in a collection of docu- ments,” Computer Sciences and Information Technologies (CSIT), 142-145. (2015) 17. Arzubov, M., Shakhovska, N., Lipinski, P.: Analyzing ways of building user profile based on web surf history. In: Computer Sciences and Information Technologies (CSIT), 1, 377- 380. (2017) 18. Mukalov, P., Zelinskyi, O., Levkovych, R., Tarnavskyi, P., Pylyp, A., Shakhovska, N.: Development of System for Auto-Tagging Articles, Based on Neural Network. In: CEUR Workshop Proceedings, Vol-2362, 106-115. (2019) 19. Shakhovska, N., Basystiuk, O., Shakhovska, K.: Development of the Speech-to-Text Chatbot Interface Based on Google API. In: CEUR Workshop Proceedings, Vol-2386, 212-221. (2019) 20. Nazarkevych, M., Klyujnyk, I., Nazarkevych, H.: Investigation the Ateb-Gabor Filter in Biometric Security Systems. In: Data Stream Mining & Processing, 580-583. (2018). 21. Lytvynenko, V., Wojcik, W., Fefelov, A., Lurie, I., Savina, N., Voronenko, M. et al.: Hy- brid Methods of GMDH-Neural Networks Synthesis and Training for Solving Problems of Time Series Forecasting. In: Lecture Notes in Computational Intelligence and Decision Making, 1020, 513-531. (2020) 22. Rusyn, B., Lytvyn, V., Vysotska, V., Emmerich, M., Pohreliuk, L.: The Virtual Library System Design and Development, Advances in Intelligent Systems and Computing, 871, 328-349 (2019) 23. Rusyn, B., Lutsyk, O., Lysak, O., Lukeniuk, A., Pohreliuk, L.: Lossless Image Compres- sion in the Remote Sensing Applications. In: Int. Conf. on Data Stream Mining & Pro- cessing (DSMP), 195-198 (2016) 24. Emmerich, M., Lytvyn, V., Yevseyeva, I., Fernandes, V. B., Dosyn, D., Vysotska, V.: Preface: Modern Machine Learning Technologies and Data Science (MoMLeT&DS- 2019). In: CEUR Workshop Proceedings, Vol-2386. (2019) 25. Rusyn, B., Vysotska, V., Pohreliuk, L.: Model and architecture for virtual library infor- mation system. In: Computer Sciences and Information Technologies, CSIT, 37-41 (2018) 26. Lytvyn, V., Sharonova, N., Hamon, T., Cherednichenko, O., Grabar, N., Kowalska- Styczen, A., Vysotska, V.: Preface: Computational Linguistics and Intelligent Systems (COLINS-2019). In: CEUR Workshop Proceedings, Vol-2362. (2019) 27. Burov, Y., Vysotska, V., Kravets, P.: Ontological Approach to Plot Analysis and Model- ing. In: CEUR Workshop Proceedings, Vol- 2362, 22-31. (2019) 28. Vysotska, V., Lytvyn, V., Burov, Y., Berezin, P., Emmerich, M., Basto Fernandes V.: De- velopment of Information System for Textual Content Categorizing Based on Ontology. In: CEUR Workshop Proceedings, Vol- 2362, 53-70. (2019) 29. Veres, O., Rishnyak, I., Rishniak, H.: Application of Methods of Machine Learning for the Recognition of Mathematical Expressions. In: CEUR Workshop Proceedings, Vol- 2362, 378-389. (2019) 30. Furgala, Y., Rusyn, B.: Peculiarities of melin transform application to symbol recognition. In: International Conference on Advanced Trends in Radioelectronics, Telecommunica- tions and Computer Engineering, 251-254. (2018) 31. Kapustiy, B., Rusyn, B., Tayanov, V.: Peculiarities of application of statistical detection criteria for problems of pattern recognition. In: Journal of Automatioin and Inrormation Science, 37(2), 30-36. (2005) 32. Rusyn, B., Kosarevych, R., Lutsyk,O.,Korniy,V.: Segmentation of atmospheric clouds im- ages obtained by remote sensing. In: International Conference on Advanced Trends in Ra- dioelectronics, Telecommunications and Computer Engineering, 213-216. (2018) 33. Kapustiy, B., Rusyn, B.,Tayanov, V.: A new approach to determination of correct recogni- tion probability of set objects. In: Upravlyaushchie Sistemy i Mashiny, 2, 8-12. (2005) 34. Rusyn, B., Prudyus, I., Ostap,V.: Fingerprint image enhancement algorithm. In: The Expe- rience of Designing and Application of CADSM, 193-194. (2001) 35. Rusyn, B., Torska, R., Kobasyar, M.: Application of the cellular automata for obtaining pitting images during simulation process of thei growth. In: Advances in Intelligent Sys- tems and Computing, 242, 299-306. (2014) 36. Varetskyy, Y., Rusyn, B., Molga, A., Ignatovych, A.: A new method of fingerprint key protection of grid credential. In: Advances in Intelligent and Soft Computing, 84, 99-103. (2010) 37. Pukach, P., Il’kiv, V., Nytrebych, Z., Vovk, M., Pukach, P.: On the Asymptotic Methods of the Mathematical Models of Strongly Nonlinear Physical Systems. In: Advances in In- telligent Systems and Computing, 689, 421- 433. (2018) 38. Pukach, P.: Investigation of bending vibrations in Voigt-Kelvin bars with regard for non- linear resistance forces. In: Journal of Mathematical Sciences, 215(1), 71-78. (2016) 39. Lavrenyuk, S., Pukach, P.: Mixed problem for a nonlinear hyperbolic equation in a domain unbounded with respect to space variables. In: Ukrainian Mathematical Journal, 59(11), 1708-1718. (2007) 40. Pukach P.: Qualitative Methods for the Investigation of a Mathematical Model of Nonline- ar Vibrations of a Conveyer Belt. In: J. of Mathematical Sciences, 198, 31-38. (2014) 41. Nytrebych, Z., Malanchuk, O., Il’kiv, V., Pukach, P.: Homogeneous problem with two- point conditions in time for some equations of mathematical physics. In: Azerbaijan Jour- nal of Mathematics, 7(2), 180-196. (2017) 42. Nytrebych, Z., Il’kiv, V., Pukach, P., Malanchuk, O.: On nontrivial solutions of homoge- neous Dirichlet problem for partial differential equations in a layer. In: Kragujevac Journal of Mathematics, 42(2), 193-207. (2018) 43. Lytvyn, V., Vysotska, V., Rusyn, B., Pohreliuk, L., Berezin, P., Naum O.: Textual Content Categorizing Technology Development Based on Ontology. In: CEUR Workshop Pro- ceedings, Vol-2386, 234-254. (2019) 44. Basyuk, T.: The main reasons of attendance falling of internet resource. In: Proc. of the X- th Int. Conf. Computer Science and Information Technologies, CSIT’2015, 91-93. (2015). 45. Lytvyn, V., Vysotska, V., Rzheuskyi, A.: Technology for the Psychological Portraits For- mation of Social Networks Users for the IT Specialists Recruitment Based on Big Five, NLP and Big Data Analysis. In: CEUR Workshop Proceedings, 2392, 147-171. (2019) 46. Vysotska, V., Burov, Y., Lytvyn, V., Oleshek, O.: Automated Monitoring of Changes in Web Resources. In: Lecture Notes in Computational Intelligence and Decision Making, 1020, 348–363. (2020) 47. Demchuk, A., Lytvyn, V., Vysotska, V., Dilai, M.: Methods and Means of Web Content Personalization for Commercial Information Products Distribution. In: Lecture Notes in Computational Intelligence and Decision Making, 1020, 332–347. (2020)