708kb feb 25 2013 01:28:16 pm

Using Ontologies for an Intelligent

Patient Modelling, Adaptationand Management System

Matt-Mouley Bouamrane1,2, Alan Rector1, and Martin Hurrell2

1 School of Computer ScienceManchester University, UK

{mBouamrane,Rector}@cs.man.ac.uk2 CIS Informatics, Glasgow, UK

[email protected]

Abstract. Health Information Management Systems (HIMS) face con-siderable technical and organisational barriers before successful deploy-ment in hospitals. In addition, many existing systems have significantlimitations, including: lack of flexibility and adaptability to complex re-quirements and processes and a general lack of “intelligence”. They offerbasic patient management functionalities but do not go far beyond corefunctionalities. Due to their rigid architectures, these systems are hardto maintain and update. Recent advances in knowledge representation,including ontologies, can offer powerful and appealing solution to theseproblems. In this paper, we describe our current work on using ontolo-gies for adapted information collection and patient representation. Wedescribe the iterative transformation of a basic risk assessment softwareinto a “knowledge-aware” system. We argue that using ontologies is bothconceptually appealing and a pragmatic solution to implementing a shiftfrom simple management systems to intelligent systems in healthcare. Inturn, we believe such systems will efficiently support clinicians in theirdaily activities and will result in improved delivery of tailored patientcare.

1 Introduction

The use of Information Management Systems in Healthcare (HIMS) offer manyadvantages including: reducing information and tasks duplication, reducing pa-per trails, reduction of administrative tasks, provision of centralised informationleading to improved retrieval of patient medical information and records and re-duction in waiting time. HIMS may also reduce the incidence of clinical adverseevents, many of whom arise from insufficient information about a patient’s med-ical history. Computer-based screening systems have had measurable benefitsin reducing omission and errors arising as the result of clinicians dealing withinformation of high complexity. As an example, physician computer order entryhave proved useful in error prevention and preventive intervention through theuse of structured entry, rule-based reminders and triggering of alerts relating to

R. Meersman and Z. Tari (Eds.): OTM 2008, Part II, LNCS 5332, pp. 1458–1470, 2008.c© Springer-Verlag Berlin Heidelberg 2008

Using Ontologies for an Intelligent Patient Modelling 1459

allergies and adverse drug interaction [1,2,3]. Likewise, in his survey of patient-computer interview systems, Bachman highlights that face-to-face informationcollection with a clinician is often less complete than computer-based historytaking [4].

Despite of their potential advantages, HIMS still face considerable challengesbefore successful deployment in hospitals. Potential issues include: the perceivedlack of immediate return on investment from trust managers, resistance to pro-cess changes from staff and clinicians, the initial effort required to deploy a HIMSin a hospital which often leads to disruption of service due to the necessity forstaff training and technical breakdowns, software incompatibility and the lackof enterprise-wide solutions, leading to the complexity and overheads involvedin integrating various individual departmental software solutions. In additionto these technical and organisational barriers, many existing commercial sys-tems also suffer from a significant number of limitations. We identify amongthem: lack of flexibility and adaptability to complex requirements and processesand a general lack of “intelligence”. Many existing commercial HIMS are “me-chanical” systems, based on a combination of database systems and distributedtechnologies. They offer basic patient management functionalities but do notgo far beyond these core functionalities. Due to their rigid architectures, thesesystems are hard to maintain and update.

In this paper, we propose to overcome some of the challenges commonlyfaced by patient management systems by transforming “mechanical” systemsinto “knowledge-aware” systems. Our solution involves adding a layer of on-tologies on top of the functionalities commonly required from the managementsystem. The benefit of the approach is two fold. First, the resulting system ismore convenient to update as modifying the ontology layer can be done with-out the need for additional and costly software engineering work. The cleanseparation between system functionalities and the knowledge base used by thesystem means that the latter can me modified if the face of evolving knowl-edge or changing requirements. Secondly, the ontology layer enables the systemto perform operations, such as decision support, which were cumbersome toimplement when using database and distributed system technologies on theirown. We illustrate our approach by describing the iterative steps performed totransform an existing preoperative assessment system into a “knowledge-aware”system. The paper presents two of a total of four expected iterations: (i) theimplementation of an adaptive questionnaire and (ii) patient modelling systemusing ontologies. Future iterative steps will consist in developing a (iii) clinicalrule ontology and (iv) an information relevance ontology. The paper is organisedas follows: the next section describes a basic patient risk assessment softwareand its main limitations. We then describe the first two iterative transformationsteps towards a “knowledge-aware” system. The first one consists of developinga context-sensitive patient questionnaire based on an ontology. The second oneconsists in generating a patient model ontology, which can be used as a serviceprovider to a number of client interfaces. We conclude with a discussion of thebenefits of the current approach and directions for future research.

1460 M.-M. Bouamrane, A. Rector, and M. Hurrell

2 A Basic Risk Assessment Software

2.1 System Description

Figure 1 presents a basic risk assessment software. This is an existing systemfor preoperative assessment of patients prior to elective (i.e. non-emergency)surgery currently used in the preoperative clinic of Utrecht Hospital, Nether-lands. The user interface consists of a web-based form which connects to thesystem server through a standard browser (Fig. 2). The aim of the software isto gather patient medical history so an informed patient risk assessment can beperformed by anaesthetists prior to surgery so potential complications can beanticipated and pre-emptive actions taken where necessary. The patient medicalhistory essentially consists of: general health condition, history of past surgery,cardiovascular and respiratory history, medication and miscellaneous health con-ditions, including allergies. The patient answers a number of questions from astatic questionnaire which contains around 50 questions. A limited number ofquestions are implemented using conditional branching through the use of IF-THEN constructs.

In an hospital setting, data input is typically performed by a nurse, who willread questions as they come up on the screen. In certain cases, patient who arejudged to have the necessary abilities (physical, technical and cognitive) can fillin the questionnaire in a dedicated computer room, under the supervision ofpreoperative nurses. Patients can therefore request support and seek clarifica-tion whenever necessary. Other options currently under consideration include:providing the software to general practitioners in primary care as a decisionsupport tool for potential referral to specialist care and using the software as aphone-based screening tool prior to potential admission to hospital.

In addition to collecting information about a patient’s medical history, a pre-operative nurse or junior doctor will usually carry a physical examination andadd in the system additional information about the patient including: height,weight, nutrition, verbal response etc. A number of tests (e.g. blood test) canalso be requested and the results are entered in the system. All the informa-tion collected concerning the patient is stored into a database (Fig. 1). A ruleengine then uses a combination of best-practice and local rules on the patientdata to derive a number of scores. These scores range from simple calculations(e.g. Body Max Index 1) to more sophisticated algorithms to derive predictors ofoverall perioperative2 outcomes such as the ASA (American Society of Anaes-thesiologists) physical status classification3, cardiac scores (e.g. Goldman andDetsky cardiac risk index [5]), etc. Risk scores and predictors are then combinedto produce an overall risk assessment score (step 4. in Fig. 1). The risk assess-ment essentially consists of: perioperative and postoperative cardiac, respiratory

1 BMI = Weight / (Height)2 in metric units.2 Period surrounding a patient’s surgical procedure, typically including ward admis-

sion, anaesthesia, surgery and recovery.3 Ranging from ASA I (healthy patient) to ASA V (moribund).


Fig. 1. A basic patient risk assessment software

Fig. 2. Web-based preoperative questionnaire

and infection risks. Finally a preoperative form is produced in HTML and PDFformats, which can be printed out for archival purposes.

2.2 System Limitations

The system presented has been in use for over three years. It has resulted in sig-nificant improvements in work processes, including reduction of paper trail, stan-dardised workflow and risk score calculation, centralised information leading toimproved efficiency in retrieving and accessing patient records, reduced incidence


of unnecessary tests, etc. However, the system still has many shortcomings. Wehere discuss the system’s main limitations:

Patient Information Gathering. The challenge is to provide brief generalquestionnaires that suite the majority of patients while, at the same time,capturing sufficient details about the minority of patients with special prob-lems for which more information is critical. The system needs to make infor-mation for the majority quick and efficient without sacrificing completeness.This is obviously very difficult to achieve using static questionnaires. Con-ditional branching can, to some extent, be used to alleviate this problem.However, this method quickly becomes hard to manage in more complexcases. Another issue is that systems designed on branching are hard to main-tain since dependencies are usually hard coded in the implementation. Thesequence of potentially related questions can not easily be altered and ad-ditional questions can not be introduced without considerable engineeringwork.

System Maintenance. As highlighted by [6], a major challenge faced by HIMSare continuously evolving work processes and practices due to emergingguidelines, advances in healthcare and organisational changes. In a systemsuch as the one previously described, patient data stored in the database haveno longer any intrinsic meaning. The data can only be correctly used andinterpreted via surrounding software components used to input data and ex-tract data from the database. This means that even small structural changesto the system will often require significant software engineering work. Up-dating the system on clinical sites will generally cause delays and disruptionsto the service.

Clinical Rule Management. There are in existence more clinical rules andguidelines than anyone could possibly manage. Also, many hospitals usetheir own local rules in addition to other rules and guidelines. The existingsystem currently uses the same rules and calculates the same scores regard-less of patient profile (although it will obviously reach different outcomesgiven different circumstances). However, there is a strong clinical case forchoosing to run different risk scores depending on the specifics of a patientor a particular procedure. An example consists in using different rules to cal-culate the cardiac risks of a cardiac patient (i.e. undergoing cardiac surgery)and a non-cardiac patient.

Display of Critical Information. A thorough documentation of a patient’smedical history is widely recognised as providing good indicators of potentialintra-operative and postoperative complications. However, for a risk assess-ment to be effective, the clinician must not be overloaded with information.As an example, a BMI value may be sufficient for the clinician to form ajudgement about the safety of a procedure without the need for him toknow the specific height and weight details of a patient, while the details ofprevious surgery may only be useful if their are relevant to a planned proce-dure, etc. The challenge here is to prominently display critical informationwhile reducing or perhaps even hide less relevant information.


3 An Ontology-Driven Adaptive Questionnaire

A solution to the challenge of making the information collection process quickfor the majority and efficient without sacrificing completeness, is to develop anadaptive questionnaire. By “adaptive” we mean a dynamic modification of thebehaviour of the application (i.e. structure of the questionnaire) in response touser interaction (context-sensitive self-adaptation) [7]. Previous method used toimplement context sensitive adaptation in medical questionnaire include, condi-tional branching, using tree models and finite state machines [8,9,10]. Limitationsof these proposed methods include complexity, scalability and lack of flexibilityfor system maintenance. Our proposed solution to context-sensitive adaptation isto use an ontology as the basis for adaptation of information collection. The pro-posed method permits to iteratively capture finer-grained information with eachsuccessive step, should this information be relevant according to a questionnaireontology. The proposed method intends to replicate the investigating behaviourexhibited by clinicians when presented with items of information which may because for concern or require further attention. While the system has the poten-tial to reduce the number of questions and thus save time and costs for healthypatients, the emphasis is rather on collecting more information whenever rele-vant so a proper informed patient risk assessment can be performed. We arguethat this method is robust, scalable and highly configurable and although themethod is presented in a medical context, the principles are generic. The system

Fig. 3. First iterative step towards a knowledge-aware system: an ontology-driven adap-tive questionnaire


implementation is illustrated in Fig. 3 while technical details have been describedin elsewhere [11,12] Note that the main difference with Fig. 1 is that an ontologyis now responsible for managing user interaction. This is thus the first iterativestep in transforming the previous “mechanical” risk assessment system into a“knowledge-aware system”.

4 Patient Medical History Modelling

There is currently extensive work on developing information models, electronicpatient health records and terminologies and ontologies in the medical domain[13, 14, 15, 16, 17]. Specific applications of ontologies include modeling medicalerrors [18], clinical examinations in oral medicine [19], etc. In our system, theinformation collected by the adaptive questionnaire could be directly input ina database, as is the case in the original system described in Fig. 1. However,as previously mentioned, this means that the medical data in isolation have lostall intrinsic meaning. We refer to this information representation as the “Datalevel” representation, with the associated lack of flexibility in the structure of therisk assessment system previously highlighted in section 2.2. In the new systemimplementation, the information collection based on an ontology creates the op-portunity to simultaneously generate a patient profile automatically generatedfrom the medical ontology and thus to preserve the semantics of the informationcollected. This information representation is what we describe as the “Seman-tic level” and constitutes the second iterative step in transforming the patientsystem into a knowledge-aware system.

The main benefit of this approach is that a single information repository,a semantic patient medical profile, can now provide a number of services tovarious clients: to input data in the database, as input to a rule engine, a clinicaldocument or a patient record, as illustrated in Fig. 4. This system design providesgreater flexibility to the current implementation as new software components canbe added and older one withdrawn without affecting the whole structure of thesystem. If the type of information collected about the patient remains static,changes to the clients of the patient profile ontology are restricted within theinterface layer of Fig. 4. If the type of information collected about the patient isupdated, changes will occur both in the OWLPatientModeler and the interfacelayer. However, the latter changes are typically incremental (e.g. a new itemof information about the patient is now required) and therefore updates to thesystem ought to be manageable.

4.1 Patient Medical History Ontology

We here want to stress to the reader that the patient semantic medical profilegenerated by our system is not in any case a patient medical record. It is instead aformal representation of the information collected during the preoperative ques-tionnaire. The main difference here is essentially one of scale. While attemptingto model any potential item of medical information for any patient is extremely


Fig. 4. Second iterative step towards a knowledge-aware system: a patient profile on-tology now provides a number of services to various clients

challenging, doing so in a very constrained domain is somehow more manage-able, as we will shortly demonstrate using a practical example. The preoperativequestionnaire currently in use in the system is composed of between 30 to 90questions (the variation is due to the adaptive behaviour of the questionnaire).Thus, the scope of the information which needs to be modelled is well defined andthus constrained and manageable. Figure 5 illustrates a patient profile generatedby the system. We here describe in more details the type of medical informationmodelled by the patient medical profile ontology using the example of a specificpatient.

Medical Condition. Many items of information of relevance to clinicians con-sist of Boolean-type information regarding a patient’s medical history. Moreprecisely: the absence or presence of specific conditions. Example include:“has the patient got diabetes?”, ”is the patient epileptic?”, etc. For this typeof information, modeling is done through the use of the hasPresence andhasAbsence functional properties. The syntax of information is :{hasAbsencesome MedicalCondition} as illustrated by items labelled 1 in Fig. 5. Re-member that this only models information obtained through the preopera-tive questionnaire. The purpose of this information is to flag down to the


Fig. 5. OWL Patient Profile as viewed through the Protege-OWL User Interface


clinicians the potential existence of certain medical conditions. In case of apositive response, this is likely to be followed up by further investigation intothe condition (e.g. “ what type of diabetes?”, “does the patient take medica-tion?”). The exact nature of further investigations will usually depends onlocal hospital policies. Hence, the advantage of a flexible information col-lection system as described in section 3. In keeping with the open worldassumption of OWL4, a medical condition is only assumed to be absent if aquestion was specifically asked to the patient (e.g. the answer to the question“do you have diabetes?” was explicitly stated as “No”).

Specific Medical Event. In some cases, critical information for the clinicianis whether a patient has had an occurrence in the past of a specific med-ical event, such as a heart attack, stroke, etc. This information is mod-elled in the ontology through the use of the special classes PastHealthEventand PastSurgery. For specific event (items 2), information syntax is in theform: {hasPresence\Absence some (PastHealthEvent that consistsOf someSpecificEvent}. For specific surgery (items 3), information syntax is in theform: {hasPresence\Absence some (PastSurgery that hasLocation someSpecificAna-tomicLocation}. In the example of Fig. 5, the ontology tells usthat the patient has never had any of: anaesthetic complications, blood clot,heart attack, stroke, or heart surgery but she did have appendix surgery.

Qualitative Information. Qualitative information can be expressed as shownby example 4: the patient has asthma with mild symptoms. What actuallycorresponds to mild symptoms can be asserted in the questionnaire ontology,thus giving the flexibility to see those criteria being adapted to specific sites.

Temporal Information. In many cases, it is important to know whether someinformation about the patient is currently true or if it was true in thepast even if it is no longer true. Information which fall under this remitinclude smoking, drug taking, medication, etc. In order to express these nu-ances, we use the following classes: TRUE-atPresent (e.g. “smoker”), TRUE-atPresent-And-TRUE-InThePast,TRUE-atPresent-And-FALSE-InThePast,FALSE-atPresent-And-TRUE-InThePast (e.g. patient is an “ex-smoker”),an finally: FALSE-at-Present-And-FALSE-InThePast (e.g. “never smoked”).This is illustrated by the items labelled 5: the patient is an ex-smoker, sheuses to take medication for asthma but no longer does and is currently tak-ing some anti-inflammatory medication. More specific information, such asthe exact date of an event can also be specified if necessary.

Cardinal Information. It is possible to express cardinal information (e.g. num-bers and ranges) in an OWL ontology using cardinal restrictions. In this caseit is important to specify what is the nature on the units used so the informa-tion in the patient ontology remains self-explanatory. Therefore, one needsto define unit classes. These are essentially of two types: temporal unit andquantity units. Thus, item 6 says that this patient’s age is 29 and the unit tointerpret this value is Year. Another advantages in defining unit classes is that

4 Information which is not asserted in the ontology can not be inferred to be false.


this information is stored in a single location and can easily be updated to suitnew guidelines or local trust rules.

Range Information. Items 7 tell us that the patient did not have a chest X-ray or ECG (electrocardiogram) within the last 6 months but she did havea blood test.

Combining more Complex Information. This last example shows how tocombine the previous syntaxes to express more complex information: items 8,tells us that the patient currently drinks alcohol and that her alcohol intake isless than 3 units of alcohol per day. Once again, what exactly constitutes analcohol unit can be asserted in the ontology, providing a convenient methodfor updating the system.

4.2 System Description

In order to achieve system flexibility and maintenance requirements highlightedin section 2, the system illustrated in Fig. 4 is implemented along independentself-contained software components. The interaction loop is as follows: the useranswers the current medical question currently being asked, the ActionManagerdispatches this information to the adaptive engine which consults the question-naire ontology to extract the next question which is returned to the ActionMan-ager. The ActionManager hands out the next question (an OWL class) to theUIDisplayManager whose purpose is to interpret the information in the questionclass and to render it appropriately on the user interface (e.g. depending whetherit is a multiple choice questions, whether the user is allowed one or several an-swers, etc.) Simultaneously, the action manager hands out the current questionand corresponding answer classes to the OWLPatientModeler, whose purpose isto produce the patient semantic medical profile described in the previous section.The system is implemented using Java technology, the UIDisplayManager, theOWLPatientModeler and the adaptive engine are implemented using the OWL1.1 API [20].

5 Discussion and Future Work

We have presented 2 of 4 iterative steps towards transforming a “mechanical”patient risk assessment system into a “knowledge-aware system”. Using an on-tology for context-sensitive adaptation means that the information collectionprocess can be tailored to patients’ individual circumstances and thus enablesfiner-grained information collection. In the second step, we have argued thatusing a patient ontology to model the information collected offer several advan-tages. The first is that the semantics of the information collected are preservedand self-contained in the ontology and thus remains interpretable regardless ofsurrounding technology and software implementation. Then, the patient seman-tic medical profile can be used to provide services to a number of software clients.This design has significant implication for system flexibility, maintenance andupdate. For compatibility with other HIMS, we are currently into the process of


mapping the concepts in the patient ontology to the IOTA terminology (Interna-tional Organization for Terminologies in Anaesthesia). The IOTA terminologyis itself mapped to the SNOMED-CT terminology5. In order to complete thetransformation of the system into a fully-fledged knowledge-aware system, 2 it-erative steps remain: to develop an ontology of clinical rules in order to inferwhich are the most relevant given specific patients’ circumstances or a partic-ular procedure. Although this may a-priori sound a daunting task, it is quitemanageable in practice. Any one hospital will typically use a very limited num-ber of clinical rules and risk scores for preoperative risk assessment (e.g. between10 to 30 cardiac, respiratory, nutrition risk scores, etc.) This means that the taskof developing the clinical rule ontology is manageable while the ontology can beiteratively updated to meet new requirements. The final step will be to developan information relevance ontology, to ensure that the most critical clinical in-formation is prominently displayed given patients’ specific circumstances andsurgical procedures, while minimising less relevant information.

References

1. Bates, D.W., Leape, L.L., Cullen, D.J., Laird, N., Petersen, L.A., Teich, J.M.,Burdick, E., Hickey, M., Kleefield, S., Shea, B., Vliet, M.V., Seger, D.L.: Effectof computerized physician order entry and a team intervention on prevention ofserious medication errors. Journal of the American Medical Association 280, 1311–1316 (1998)

2. Kuhn, K., Giuse, D.: From hospital information systems to health informationsystems problems, challenges, perspectives. Methods of Information in Medicine 40,275–287 (2001)

3. Kuperman, G.J., Gibson, R.F.: Computer physician order entry: Benefits, costs,and issues. Annals of Internal Medicine 139, 31–39 (2003)

4. Bachman, J.W.: The patient-computer interview: a neglected tool that can aid theclinician. Mayo Clinic Proceedings 78, 67–78 (2003)

5. Palda, V.A., Detsky, A.S.: Perioperative assessment and management of risk fromcoronary artery disease. Annals of internal medicine 127(4), 313–328 (1997)

6. Lenz, R., Kuhn, K.A.: Towards a continuous evolution and adaptation of infor-mation systems in healthcare. International Journal of Medical Informatics 73(1),75–89 (2004)

7. Jameson, A.: Adaptive interfaces and agents. In: Human-computer interactionhandbook: fundamentals, evolving technologies and emerging applications, pp.305–330. Lawrence Erlbaum Associates, Inc., Mahwah (2003)

8. Houziaux, M.O., Lefebvre, P.J.: Historical and methodological aspects of computer-assisted medical history-taking. Informatics for Health and Social Care 11(2), 129–143 (1986)

9. van Ginneken, A.M., de Wilde, M., Blok, C.: Generic computer-based question-naires: an extension to opensde. In: Fieschi, M., Coiera, E., Li, Y.C. (eds.) Pro-ceedings of 11th World Congress on Medical Informatics, MEDINFO, pp. 688–692.IOS Press, Amsterdam (2004)

5 http://www.nlm.nih.gov/research/umls/Snomed/snomed main.html


10. Vahabzadeh, M., Epstein, D., Mezghanni, M., Lin, J.L., Preston, K.: An electronicdiary software for ecological momentary assessment (ema) in clinical trials. In: Pro-ceedings of 17th IEEE Symposium on Computer-Based Medical Systems, CBMS2004, Bethesda, US, pp. 167–172. IEEE Computer Society, Los Alamitos (2004)

11. Bouamrane, M.M., Rector, A., Hurrell, M.: Ontology-Driven Adaptive MedicalInformation Collection System. In: An, A., Matwin, S., Ras, Z.W., Slezak, D.(eds.) Foundations of Intelligent Systems. LNCS (LNAI), vol. 4994, pp. 574–584.Springer, Heidelberg (2008)

12. Bouamrane, M.M., Rector, A., Hurrell, M.: Gathering precise patient medical his-tory with an ontology-driven adaptive questionnaire. In: Proceedings of Computer-Based Medical Systems, CBMS 2008, Jyvaskyla, Finland, pp. 539–541. IEEE Com-puter Society, Los Alamitos (2008)

13. Iakovidis, I.: Towards personal health record: current situation, obstacles andtrends in implementation of electronic healthcare record in europe. InternationalJournal of Medical Informatics 52, 105–115 (1998)

14. Dieng-Kuntz, R., Miniera, D., Ruzicka, M., Corbya, F.C.O., Alamarguya, L.: Build-ing and using a medical ontology for knowledge management and cooperative workin a health care network. Computers in Biology and Medicine 36(7-8), 871–892(2006)

15. Rector, A., Rogers, J.: Ontological and practical issues in using a Description Logicto represent medical concept systems: experience from GALEN. In: Barahona, P.,Bry, F., Franconi, E., Henze, N., Sattler, U. (eds.) Reasoning Web 2006. LNCS,vol. 4126, pp. 197–231. Springer, Heidelberg (2006)

16. Yu, A.: Methods in biomedical ontology. Journal of Biomedical Informatics 39(3),252–266 (2006)

17. Hu, B., Dasmahapatraa, S., Dupplawa, D., Lewisa, P., Shadbolta, N.: Reflectionson a medical ontology. International Journal of Human-Computer Studies 65(7),569–582 (2007)

18. Stetson, P.D., McKnight, L.K., Bakken, S., Curran, C., Kubose, T.T., Cimino,J.J.: Development of an ontology to model medical errors, information needs, andthe clinical communication space. Journal of American Medical Informatics Asso-ciation 9(6 suppl. 1), s86–s91 (2002)

19. Gustafsson, M., Falkman, G.: Experiences in modeling clinical examinations inoral medicine using owl. In: Proceedings of the OWLED 2007 Workshop on OWL:Experiences and Directions, Innsbruck, Austria (2007)

20. Horridge, M., Bechhofer, S., Noppens, O.: Igniting the owl 1.1 touch paper: Theowl api. In: Proceedings of the third International Workshop of OWL Experiencesand Directions, OWLED 2007, Innsbruck, Austria (2007)

708kb feb 25 2013 01:28:16 pm

Documents