OWL 2 Web Ontology Language:
Requirements

1 Overview

This document describes use cases and requirements that motivate further development to the Web Ontology Language evident in OWL 2. The use cases stem from a variety of domains that have been exploring the use of OWL for knowledge management as well as from implementers of OWL tools and services. What is captured here is not an exhaustive list of capabilities for OWL requested by these groups, but rather the motivations for those features that had common support and could be added to the language while staying within other design goals such as decidability, scalability, implementability. Rationale for selections is provided so as to provide the reader insight into the presence, absence or restricted use of desirable features.

The first section of the document (Use Cases) lists use cases collected from the OWLED series and other literature that characterize some of the most important and common motivations behind the development of OWL 2. The second section (Requirements) summarizes the main requirements that have been requested by users and implementors. The third section (Features & Rationale) points to the main new features that have been added to OWL 2 and their rationale. It provides simple illustrating examples, links to the Use Cases that motivated these extensions, and to the syntax defined in the other documents.

Note (Christine): the proposed skeleton/structure is built according to the main OWL 2 features required - whatever user/implementor/theoretical reasons - and that seem, at this time, on the way to be accepted by the WG for OWL2. This is a first suggested draft and structure in progress.2 Use Cases Motivated by Domains and Applications

In this section, we discuss a collection of use cases across multiple domains such as health care delivery, life sciences, clinical research and trials, manufacturing, earth and space sciences, and telecommunications. For each domain, we discuss the applications and stakeholders involved. This helps motivate the requirements and the features of the OWL 2.0 lanuage as discussed in later sections.

2.1 Domain: Health care

Knowledge management in health care aims to support physicians, nurses and other clinical staff to provide high quality clinical care to patients in various settings such as in-patient, out-patient and emergency settings. Key applications and functionalities supported in clinical information systems along with various users and stakeholders are as follows.

2.1.1 Applications

The key applications that form the core components of a health are delivery infrastructure are discussed next. For each application we identify motivate needs and requirements for information and knowledge representation languages.

2.1.1.1 Electronic Medical Record (EMR)

The EMR is the core component of any health care IT infrastructure that seeks to represent clinical information about a patient. EMRs pose significant challenges in terms of (A) common and consistent reporting of clinical observations and treatments and (B) standardization and interoperability to enable sharing of clinical data across applications and institutional boundaries that enable decision support and clinical quality reporting. There is a need for representation of clinical descriptors that capture various types of information in an EMR such as clinical observations, conditions, lab tests, medications and treatments. A formal representation of these clinical descriptors present a requirement languages for information and knowledge modeling that are precise, unambiguous and computationally tractable.

2.1.1.2 Enterprise Terminology Services

The need for standardization and consistent representation of clinical descriptors in an EMR is a key requirement for using and composing concepts from controlled medical terminologies such as Snomed-CT, LOINC, RxNorm and others. In order to achieve interoperability, the healthcare IT industry has attempted to use these terminologies to represent a wide variety of clinical descriptors. Over and above interoperabiliyt, this also enables consistent use of clinical descriptors to trigger clinical decision support and to represent clinical quality metrics. However, there has been wide variability, as different systems have used concepts from different terminologies with different granularities combined in multiple ways to reresent the same clinical data. There is a need for knowledge representation languages that provide the ability to specify a rich set of relationships between concepts, the ability to create new concepts based on the composition of pre-existing concepts and the ability to infer equivalence of the same concept representd in multiple ways.

2.1.1.3 Clinical Decision Support (CDS)

CDS tools have been widely used by healthcare organizations to provide support to the physician at the point of care. CDS logic is typically represented using some form of decision rules, which typically consist of clinical descriptors as a part of the antecedent, and recommended actions such as ordering a lab test, recommending a treatment or inference of a particular clinical condition, such as fracture in some location of the body. These rules typically levarage concepts and possible compositions of concepts from a terminology, e.g., Snomed-CT or Foundation Model of Anatomy to specify the logic in a decision rule. There is a need for a knowledge representation language to represent logic in a precise, standardized and computable formalism.

2.1.1.4 Clinical Quality Metrics

Managers and administrators at healthcare organizations are interested in monitoring the quality of care provided at their institutions. For this purpose all clinical transactions are stored in a centralized data warehouse or repository and analyzed for the occurrence of various clinical descriptors such as the number of times a particular test was ordered, the number of patients who have their LDL values in the normal range etc. They crucial challenge is similar to the one discussed above, in that, there is a need for consistent definition of these metrics and retrievel of clinical transactions in a uniform and consistent manner for further analysis. There is a need for knowledge representation languages that can represent these clinical descriptors on one hand, and map them to underlying clinical data on the other.

2.1.1.5 Clinical Documentation

Typically physicians dictate their impressions of a patient encounter into a recording machine which gets transcribed into unstructured textual notes by means of speech processing software. An alternative approach provides for development of templates and tools to document a patient's clinical condition in a structured manner using rich and expressive clinical descriptors. This enhances the ability to share clinical data across applications, enable automatic decision support and measurement and evaluation of clinical quality metrics.

2.1.2 Users and Stakeholders

2.1.2.1 Clinical/Biomedical Informatician

2.1.2.2 Information Modeler/Architect

2.1.2.3 Subject Matter Expert

2.1.3 Use Cases

2.1.3.1 Use Case (New) - Problem Oriented Medical Record (POMR) Ontology

There have been multiple attempts to design a formal description of the medical record of a patient. There have been attempts to define information models such as the HL7 RIM, Archetypes, medical terminologies such as Snomed and ontologies such as Galen. The fundamental motivation for the design and philosophy of the Problem-Oriented Medical Record (POMR) is the belief that the medical record is the central medium of communication and the first repository of knowledge in the practice of clinical medicine. The traditional structure / organization of the POMR is: Screening Data (collected in order to discover problems, problem list, initial plans (organized by problem) and progress notes (outcomes and follow-up). There have been attempts to use OWL to represent the medical record.

2.1.3.2 Use Case (New) - Specifying decision logic in CDS Rules

(From: H. Goldberg, V. Kashyap and K. Spackman, Creation and Usage of a "Micro Theory" for Long Bone Fractures: An Experience Report, Proceedings of KR-MED 2008)

Typically, a physician creates a clinical descriptor that is of sufficient granularity to support a management plan—the clinical descriptor is an index for the general management plan for a given pathology. Within the contemporary electronic health record, the clinical descriptor may be reused as data to drive point-of-care decision support, or as warehouse data to support reporting. For instance, if we need to report the number of patients who had a fracture of the proximal femur, we should also include the number of patients who had a fracture of the femoral neck. In both cases, the original descriptor should support detailed classification schemes. With respect to bone fractures, it is desirable to describe fractures in detail with respect to the bone features involved—the clinical detail drives the management plan. The clinical detail may describe either a fracture involving an anatomic landmark or a functional region where all fractures act similarly. It is equally important that the clinical descriptor not admit any nonsensical description. While fractures may involve bony landmarks, we generally do not describe fractures of the periosteum — the bone lining—or the bone marrow. While these are parts of bones, they are not generally parts through which fractures are described to occur. The GALEN project used constraints called sanctions to specify the values that could sensibly be applied to relations such as has-location. Our ontology fragment should logically defining the set of all and only locations for fractures. Given a need to document, to classify, and possibly to obtain reference information, useful questions that might be posed include:

1. What bone regions and features are contained in the Distal Epiphysis of the Femur?
2. What parts of the Distal Epiphysis of the Humerus are covered by Articular Cartilage?
3. Is a fracture of the Femoral Neck also a fracture of the Proximal Femur (i.e., is a fracture through an anatomic feature a fracture of a functional region)?
4. Is a fracture of the Trochlea a fracture of the Distal Epiphysis of the Humerus?
5. Is a fracture of the Trochlea an intra-articular fracture?
6. Is a fracture of the Trochlea an intra-articular fracture of the Distal Epiphysis of the Humerus?

The above questions create requirement for:

• Propagation of location of a fracture over regional parts; and
• Transitive transfer for location of a fracture.

These requirements are related to the OWL 2.0 features of:

• representation and reasoning over role chains and
• representation and reasoning over transitive relationships.

2.1.3.3 Use Case #1 - Brain image annotation for neurosurgery

The application concerns the preparation of surgical procedures in neurosurgery. Specifically, the aim is to assist the user in labelling the cortical gyri and sulci in the region surrounding the lesion, whose resection is the primary objective. Providing anatomical landmarks, especially in eloquent cortex, is highly important for surgery. Besides brain images annotation is useful in terms of documentation of the clinical cases, and with respect to the ability of retrieving similar cases for decision support in future procedures. A shared ontology of brain anatomy is also needed to integrate multiple distributed image sources indexed by anatomical features. It is useful for large-scale federated systems for statistical analysis of brain images of major brain pathologies.

2.1.3.4 Use Case #7 - The Systematized Nomenclature of Medicine (SNOMED CT)

The Systematized Nomenclature of Medicine, Clinical Terms (SNOMED CT) is a work of clinical terminology with broad coverage of the domain of health care, and it has been selected as a national standard for use in electronic health applications in many countries, including the U.S., U.K., Canada, Australia, Denmark, and others. SNOMED was originally published in 1976, while SNOMED CT became available in 2002 as a major expansion resulting from the merger of SNOMED RT with the U.K.'s Clinical Terms version 3. A major distinguishing feature differentiating it from prior editions is the use of description logic (DL) to define and organize codes and terms. Another major distinguishing feature of SNOMED is its size and complexity. With over 350,000 concept codes, each representing a different class, it is an order of magnitude larger than the next largest DL-based ontology of which we are aware. The size of the OWL XML/RDF form of SNOMED is approximately 248 MB, and this is just the DL representation without all the synonyms, mappings, subsets, and other special-purpose components of the terminology. Without property chain inclusion axioms, adoption of OWL by the SNOMED community would have required awkward workarounds with their attendant complications and complexities - effectively killing movement in that direction. With [them], we have a clear path to using OWL 2 for further development and integration with other biomedical ontologies. Like the FMA given the common use of SNOMED cross-references, keys would be highly useful.

 Note (Micheldumontier). Please elaborate on the requirement for property chain inclusions - give example, and describe the workaround.

2.1.3.5 Use Case # 9- Kidney Allocation Policy in France

Allocation in France falls under the responsibility of the Agence de la biomedicine. It includes general rules such as: donor-recipient ABO blood group identity, unique registration on the national waiting list and definition of some organ specific nation-wide allocation priorities. For each kidney recipient, minimal HLA matching and forbidden antigens can be specified. Pediatric recipients get a priority for pediatric donors. Kidneys are proposed by order of priority to (1) urgent patients, (2) patients with panel reactive antibodies level ≥ 80% included in a specific acceptable antigen protocol or ≤1 HLA mismatch with the donor, then (3) zero mismatch patients, and (4) patients with low transplantation accessibility. This real-life application and allocation system show how distinguishing between adults and children has strong implications in health care: at hospital, patients under 18 (child) depend on pediatric services while over 18 (adult) depend on adult services; only children less than 16 years waiting for a transplant have a priority on the waiting list.

2.2 Domain: Life Sciences

2.2.1 Applications

2.2.2 Users and Stakeholders

2.2.2.1 Scientific Database Leadership

2.2.2.2 Subject Matter Expert

2.2.3 Use Cases

2.2.3.1 Use Case #2 – The Foundational Model of Anatomy

The Foundational Model of Anatomy (FMA) is the most comprehensive ontology of human ‘canonical’ anatomy. Anatomy plays a prominent role in biomedicine and many biomedical ontologies and applications refer to anatomical entities. FMA is a tremendous resource in bioinformatics that facilitates sharing of information among applications that use anatomy knowledge. As its authors claim, the FMA is “a reference ontology in biomedical informatics for correlating different views of anatomy, aligning existing and emerging ontologies in bioinformatics...” . Anatomy, together with Gene and Disease reference ontologies constitute the backbone of the future Semantic Web for Life Sciences. The FMA should benefit to state that some properties are exclusive (e.g.; proper-part and bounded-by). Since many biomedical ontologies and applications refer to the FMA anatomical entities through cross-references, keys would be highly useful.

  Note (Micheldumontier). First, anatomy is more about the health sciences, than the life sciences. Second - please expand on the notion of "exclusive" properties, and what value they might have - illustrate with a clear example. Third, it is wholly unclear how "keys" would be useful in the identified context - please provide sufficient detail.

2.2.3.2 Use Case #3 - Classification of chemical compounds

Functional groups describe the semantics of chemical reactivity in terms of atoms and their connectivity, which exhibit characteristic chemical behavior when present in a compound. In this use case the authors take a first step towards designing an OWL-DL ontology of functional groups for the classification of chemical compounds, highlight the capabilities and limitations of OWL 1.0 and the proposed OWL 1.1 in terms of domain requirements. They also describe the application of expressive features in the design of an ontology of basic relations and how, an upper level ontology, can be used to guide the formulation of life science knowledge. They report on experiences to enhance existing ontologies so as to facilitate knowledge representation and question answering.

2.2.3.3 Use Case #5 - OBO ontologies for biomedical data integration

The Open Biomedical Ontologies (OBO) consortium is pursuing a strategy to facilitate the integration of biomedical data through their annotation using common controlled ontologies. Existing OBO ontologies, including the Gene Ontology, are undergoing coordinated reform, and new ontologies are being created on the basis of an evolving set of shared principles governing ontology development. The result is an expanding family of OBO ontologies designed to be interoperable and to incorporate accurate representations of biological reality. Within that effort the OBO ontology of relations is designed to define a set of basic relations with their semantics. OBO qualifies each relation using characteristics of being transitive, symmetric, reflexive, anti-symmetric. Property axioms to express these features are required for accurate knowledge representation.

2.2.3.4 Use Case #8 - Simple part-whole relations in OWL Ontologies

Representing part-whole relations is a very common issue for those developing ontologies for the Semantic Web. OWL does not provide any built-in primitives for part-whole relations (as it does for the subclass relation), but contains sufficient expressive power to capture most, but not all, of the common cases. The study of part-whole relations is an entire field in itself - "mereology" - this note is intended only to deal with straightforward cases for defining classes involving part-whole relations. Several extensions of whole needed for part-whole are discussed in this study, namely, needs of qualified cardinality restriction, reflexivity, propagation from parts to whole

2.3 Domain: Manufacturing

2.3.1 Applications

2.3.2 Users and Stakeholders

2.3.2.1 Manufacturing Technical Standards Developer

2.3.2.2 Manufacturing Business Standards Developer

2.3.3 Use Cases

2.3.3.1 Use Case #4 - Querying multiple sources in an automotive company

Large companies often store information and knowledge in multiple information systems using various models and formats. A main issue is to retrieve the relevant knowledge for a specific concern from the different sources. The aim of the application is to query multiple data and knowledge sources for a large automotive company faced to this problem.

2.4 Domain: Earth and Space Sciences

2.4.1 Applications 2.4.2 Users and Stakeholders 2.4.2.1Knowledge management in earth and space science Researcher From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents 2.4.3 Use Cases 2.4.3.1 Use Case #6 – Spatialinformation systems aims to support domain scientists, information and topological relationships atdata specialists, teachers, and lay personnel in providing access to data concerning the Ordnance Survey Ordnance Survey is Britain's National Mapping Agency. It currently maintains a continuously updated database of the topography of Great Britain. The database includes around 440 million man-made andnatural landscape features. These features include everything from forests, roads and rivers down to individual houses, garden plots, and even pillar boxes. In additionworld. Not only do applications need to this topographic mapping, entire new layers of information are progressively being addedprovide access to the database, such as aerial photographic images which precisely match the mapping;data providing the addresses of all properties; and integrated transport information. Here for the topological and spatial relationships, andin many other places, “we need to be ablesingle discipline areas, they also must provide access to say whether a property is reflexive, irreflexive, asymmetric or antisymmetricdata concerning multiple disciplines in orderways that are appropriate to capture the true intentionsa wide range of our axioms”. [ Ordnance ] Requires : Reflexive, Irreflexive, Asymmetric, [Antisymmetric] 2.5 Domain: Clinical Researchusers. Key applications and Clinical Trials This domain consists of informationfunctionalities supported in earth and knowledge related to a patient's clinicalspace science information in the context of his or her participation insystems along with various users and stake holders follow below.

2.4.1 Applications

2.4.1.1 Virtual Observatory (VO)

A clinical research study orvirtual observatory is a clinical trial, which may be characterized bysuite of software applications on a set of clinical processes or protocols. 2.5.1 Applications Key applications in this domain are clinical trials management,computers that keep track of various patient, trialallows users to uniformly find, access, and investigator related information across multiple clinical trials, detectionuse resources (data, software, document, and resolutionimage products and services using these) from a collection of adverse events, 2.5.1.1 Clinical Trials Management This application supports the ability to acquire, storedistributed product repositories and manage clinical data of patients participating in a clinical trial. It also seeks to track the progress ofservice providers. A patient throughVO is a clinical trial based on well defined clinical processesservice that unites services and protocols. 2.5.1.2 Adverse Event Detection/ or multiple repositories.

 Note {DeborahMcGuinness}. We need to figure out how best to deal with typical and  Resolutionother publications that are the sources for our requirements and/or definitions such as this  application tries to detect adverse eventsone above.

2.4.2 Users and Stakeholders

2.5.2.1 Subject Matter Expert This user type2.4.2.1 Earth and Space Science Researcher

2.4.2.2 Computational Scientist / Software Engineer

2.4.2.3 Existing Implementation Owner of Earth and clinical trial investigators are responsible for running clinical trialsSpace Science Application

2.4.3 Use Cases

2.4.3.1 Use Case #18 – Virtual Solar Terrestrial Observatory

2.4.3.2 Use Case is based on#19 – Semantic Provenance Capture

2.4.3.3 Use Case #6 – Spatial and topological relationships at the Ordnance Survey

Ordnance Survey is Britain's National Mapping Agency. It currently maintains a target class with a restriction on onecontinuously updated database of the object propertiestopography of Great Britain. The class Representation of equivalences between object properties Representation of mappings between an object propertydatabase includes around 440 million man-made and a property chain Representation of mappings between classes in an information modelnatural landscape features. These features include everything from forests, roads and concepts in a controlled terminology Furthermore in some cases, one needsrivers down to map conceptsindividual houses, garden plots, and even pillar boxes. In the source terminologyaddition to concepts in the target terminology. (e.g., RxNorm), where the concepts may not exist at all in the target terminology. Inthis case a mediating ontology, e.g., Drug ontology may be used to definetopographic mapping, entire new classes requiredlayers of information are progressively being added to createthe relevant mappings. For e.g., let's assume that the source terminology contains a medication class called WeightReductiondatabase, such as aerial photographic images which doesn't exist either in the mediating ontology or inprecisely match the target terminology. This can be achieved by defining an equivalent class inmapping; data providing the Drug Ontology as Drugs that may treat Obesityaddresses of all properties; and identify mappings from this composite class to concpets inintegrated transport information. Here for the target terminology. These examples are illustrated in http://esw.w3.org/topic/HCLS/ClinicalObservationsInteroperability/DrugMapping.htmltopological and spatial relationships, and give rise to the following requirements: The ability to map a medication classin a source terminology tomany medication instances in a target terminology, via a mediating ontology The abilityother places, “we need to map a medication class in a source terminologybe able to say whether a defined class expression in the mediating ontology, which in turnproperty is mapped to many medication instancesreflexive, irreflexive, asymmetric or antisymmetric in the target terminology 2.5.3.2 Use Case #10– Eligibility Criteria for Patient Recruitment This use case is based on an ongoing W3C task force on Clinical Observations Interoperability where the goal isorder to enable re-use and sharingcapture the true intentions of our axioms”.

2.5 Domain: Clinical data created in healthcare delivery in theResearch and Clinical Trials

context. In particular the first application chosen to demonstrate feasibilityThis domain consists of information and knowledge related to a patient's clinical information in the interoperability approach is thatcontext of patient recruitment.his or her participation in this case,a sample set ofclinical trial protocols available from http://www.clinicaltrials.gov each ofresearch study or a clinical trial, which containsmay be characterized by a listset of eligibility (inclusion and exclusion criteria). These eligibility criteriaclinical processes or protocols.

2.5.1 Applications

Key applications in this domain are used for identify eligible patientsclinical trials management, that keep track of various patient, trial and potentially form conditionsinvestigator related information across multiple clinical trials, detection and resolution of adverse events,

2.5.1.1 Clinical Trials Management

This application supports the ability to acquire, store and manage clinical data of patients participating in a SPARQL query or could be represented as OWL classes. Theyclinical trial. It also needseeks to be mapped as per the discussion intrack the use case above. A listprogress of requirementsa patient through a clinical trial based on an analysis of thesewell defined clinical trial protcols is available from http://esw.w3.org/topic/HCLS/ClinicalObservationsInteroperability?action=AttachFile&do=get&target=FunctionalRequirements_v1.xls In particular, one of theprocesses and protocols.

2.5.1.2 Adverse Event Detection and Resolution

This application tries to detect adverse events and clinical trials requires thatconditions in response to a particular drug. It monitors the enrollment datedata for unusal signs of aclinical trial participantevents that can be within 30 days aftercorrelated with starting the patient has been startedon a particular therapy. This motivateddrug. It uses knowledge created by experts to determine an appropriate response to the need for N-ary datatypes with inequality expressions? Requires : Datatypes extension 2.5.3.3 Use Case #11 – Multiple UCsadverse reaction

2.5.1.3 Patient Recruitment

This applicaion seeks to determine a set of datatype extensions Many Use casespatient cohorts that would benefit from datatype extensions are listed, some simply requiring datatypes restrictions like intervals, other ones requiring N-ary extensions. Requires : Datatypes extension [ N-ary ] 3 Use Cases - Organized by Requirement Note (Christine). The present initial list of UCs, obviously only includesqualify for a clinical trial, based on the moment those I knew the best, issued from the OWLED TF (extracted from TdM-UserReqTF.pdf), mainly in the HCLS domain. It shows the proposed organisation along UCs/Requirements/ Features & Rationale as agreed atclinical data associated with a patient and the UFDTF Teleconsinclusion and exclusion criteria associated with the cross references between their items. Obviously other UCs are welcome, each UC being entered accompanied by linksclinical protocol.

2.5.2 Users and Stakeholders

2.5.2.1 Subject Matter Expert

This user type is similar to some specific a) Reference - whatever OWLED or other litterature b) Requirements c) Features d) Examples hopefully writena Business Manufacturing Standards Developer and is an expert in OWL 2 syntax question (dlm) - how does this setvarious domains of use cases compare toclinical medicine such as neurology, internal medicine and others. These users typically work in conjunction with clinical informaticians, where they provide the use cases we havedomain knowledge and the informatician works on creating the who reads our documents page? I suggest that we add at least some of thoseappropriate representations in this requirements document <dlm July 1, 2008***some knowledge representation language. The following list of Use Casesprimary concern for this user is not exhaustive. Each Use Case, pointsthe ability to represent the related papers available onlinetypes of knowledge and the ability to reason with and query information represented in a selection of some of the most important requirements mentionnedlanguage In those papers. 3.1 Use Case #1 - Brain image annotationparticular, it will be an important requirement for neurosurgery [HCLS]the application concernsOWL 2.0 to represent the preparationfollowing types of surgical procedures in neurosurgery. Specifically, the aim isclinical knowledge:

• Clinical Researcher/Clinical Trials Investigator: Clinical researchers and clinical trial investigators are responsible for running clinical trials and studies that seek to assistevaluate the usereffects of a drug on a patient cohort. They are interested in labellinginformation and knowledge such as the cortical gyridiagnostic tests and sulciimaging studies associated with a disease, therapeutic interventions and their impact/efficacy in treating a disease, side effects, costs and benefits associated with a drug.
• Clinical Guidelines Formulator: Academic researchers and professional societies synthesize the region surrounding the lesion, whose resection isavailable evidence regarding the primary objective. Providing anatomical landmarks, especially in eloquent cortex, is highly important for surgery. Besides brain images annotation is useful in termsdiagnosis and management of documentationa disease to generate human-readable clinical guidelines. There are now approaches that seek to semi-automatically created executable representations of these guideline. The clinical cases,information and with respectknowledge of interest to this user aare: the abilityresults of retrieving similar cases for decision support in future procedures. A shared ontologyclinical trials, cost and benefits of brain anatomy is also needed to integrate multiple distributed image sources indexed by anatomical features. It is useful for large-scale federated systemsa drug for statistical analysisa disease, the characteristics of brain imagesa clinical trial, such as the type, e.g., double blind randomized clinical trial, the sample size and power of major brain pathologies. [ MEDICAL REQ ] [ Ontology with rules ] [ Brain Imaging ] Requires : Disjoint Union, Disjoint Classes, Qualified Cardinality Restrictions, Disjoint Properties, Property chain inclusion axioms, N-ary predicate [rules] Question (Christine): should we mention delayed requirements such as those within brackets? 3.2 Use Case #2 –the Foundational Modeltrial, the relationships between recommendations made in the guideline and the results and evidence strength of Anatomy [HCLS]the Foundational Modelclinical trial.

2.5.3 Use Cases

2.5.3.1 Use Case (New): Interoperation of Anatomy (FMA)Clinical Information across Healthcare and Clinical Trials

2.5.3.2 Use Case #5 - OBO ontologies#10– Eligibility Criteria for biomedical data integration [HCLS]Patient Recruitment

2.5.3.3 Use in electronic health applications inCase #11 – Multiple UCs of datatype extensions

Many countries, including the U.S., U.K., Canada, Australia, Denmark, and others. SNOMED was originally published in 1976, while SNOMED CT became available in 2002 as a major expansion resultingUse cases that would benefit from datatype extensions are listed, some simply requiring datatypes restrictions like intervals, other ones requiring N-ary extensions.

Requires: Datatypes extension

3 Use Cases - Organized by Requirement

The mergerfollowing list of SNOMED RT withUse Cases motivating the U.K.'s Clinical Terms version 3. A major distinguishing feature differentiating it from prior editionsOWL 2 extensions is the use of description logic (DL)not exhaustive. These UCs correspond to define and organize codes and terms. Another major distinguishing feature of SNOMED is its size and complexity. With over 350,000 concept codes, each representing a different class, it is an order of magnitude larger than the next largest DL-based ontology of which we are aware. The size of theOWL XML/RDF form of SNOMED is approximately 248 MB,2 new features - whatever user/implementor/theoretical reasons - and that seem, at this is justtime, on the DL representation without allway to be accepted by the synonyms, mappings, subsets, andWG for OWL 2. Some features or details are still under discussion. Other special-purpose components ofextensions (such as rules, custom datatypes, etc.), possibly needed in the terminology. Without property chain inclusion axioms, adoption of OWL byfuture, are indicated within brackets.

The SNOMED community would have required awkward workarounds with their attendant complications and complexities - effectively killing movementgeneral organisation is based along UCs / Requirements / Features & Rationale. In that direction. With [them], we have a clear paththe Use Cases section below, each Use Case (Use Case #i) is linked to usingsome (of the most important) OWL 2 for further developmentRequirements (Rj) and integration withpoints to the related papers available online ([paper]). On the other biomedical ontologies. Likeside, in the FMA givenfollowing Requirements section, each requirement is related to the common use of SNOMED cross-references, keys would be highly useful. [ SNOMED REQ ] Requires : Property chain inclusion axioms, Keys 3.8motivating Use Case #8 - Simple part-whole relationsCases, while in OWL Ontologies [HCLS] Representing part-whole relationsthe next section Features & Rationale, each feature is a very common issue for those developing ontologies forillustrated by some example(s) issued from the motivating use cases reported in the Use Cases section. Finally, two tables summarize the Semantic Web. OWL does not provide any built-in primitives for part-wholerelations (as it does forbetween them. The subclass relation), but contains sufficient expressive power to capture most, but not all, offirst table shows the common cases.links between Use Cases and Requirements (OWL 2 Features). The second table provides the study of part-wholerelations is an entire field in itselfbetween Use Cases - "mereology"Requirements - Features & Rationale illustrated by a simple example. This note is intended onlytable can be ordered byDomain or Feature, so as to deal with straightforward cases for defining classes involving part-whole relations. Several extensions of whole needed for part-whole are discussed in this study, namely, needs of qualified cardinality restriction, reflexivity, propagation from partsallow the reader to whole [ Part Whole ] Requires : Qualified cardinality restriction, Reflexivity, Property chain inclusion axioms Profiles 3.9 Use Case # 9- Kidney Allocation Policy in France [HCLS] Allocationnavigate within the overall document according to his preference.

This is a first suggested draft in France falls underprogress.

3.1 Use Case #1 - Brain image annotation for neurosurgery [HCLS]

The donor, then (3) zero mismatch patients, and (4) patients with low transplantation accessibility. This real-lifeapplication concerns the preparation of surgical procedures in neurosurgery. Specifically, the aim is to assist the user in labelling the cortical gyri and allocation system show how distinguishing between adults and children has strong implicationssulci in health care: at hospital, patients under 18 (child) depend on pediatric services while over 18 (adult) depend on adult services; only children less than 16 years waitingthe region surrounding the lesion, whose resection is the primary objective. Providing anatomical landmarks, especially in eloquent cortex, is highly important for a transplant have a priority onsurgery. Besides brain images annotation is useful in terms of documentation of the waiting list. [ Agence Biomedecine ] [ Transplant Ontology ] Requires : Negative Property Assertion, Datatypes extension 3.10 Use Case #10 –clinical Trial [HCLS] DESCRIPTION TO BE DONE: Vipul => keep it as a particular UC or mergecases, and with Use Case #11 which includes it since 9 JUly teleconf? if separate, its description or/and refrence haverespect to be provided bythe author. Requires : Datatypes extension 3.11 Use Case #11 – Multiple UCs on datatype [HCLS] Many Useability of retrieving similar cases that would benefit from datatype extensions are describedfor decision support in [ N-ary ] . Somefuture procedures. A shared ontology of them require datatypes restrictions like intervals, other ones require N-ary extensions.brain anatomy is also needed to integrate multiple distributed image sources indexed by anatomical features. It is useful for example,large-scale federated systems for statistical analysis of brain images of major brain pathologies.

3.2 Use Case #12#2 – Protégé report on the experiences of OWL users [Tool] [ Protege ] reported in 2005 on Protégé experiences withThe developmentFoundational Model of OWL support, and onAnatomy [HCLS]

The experiencesFoundational Model of Anatomy (FMA) is the user community with OWL at that time. While the overall feedback from the community was positive, their experience suggested that there were considerable gaps between the user requirements, the expressivitymost comprehensive ontology of OWL,human ‘canonical’ anatomy. Anatomy plays a prominent role in biomedicine and users’ understanding of OWL.many biomedical ontologies and applications refer to summarize, based on their experiences, Protégé developpers suggestedanatomical entities. FMA is a number of extensions to a future version of OWL namely, Integration of user-defined datatypes (esp. for numeric ranges) Qualified Cardinality Restrictions Management of disjointness (owl:AllDisjoint) More flexible annotation properties (at least as best practices) This report underlinedtremendous resource in bioinformatics that onefacilitates sharing of the omissions in the OWL languageinformation among applications that users complain about most oftenuse anatomy knowledge. As its authors claim, the FMA is poor representation of numeric expressions. Almost all groups, except“a reference ontology in biomedical informatics for those developing traditional medical terminologies, sorely need to be able to express quantitative information. Typical examples include the length between 1mmcorrelating different views of anatomy, aligning existing and 2mm, age greater than 18 years, pressureemerging ontologies in bioinformatics...” . Anatomy, together with Gene and Disease reference ontologies constitute the rangebackbone of 1030mbthe future Semantic Web for Life Sciences. The FMA should benefit to 1035mb. Such range declarationsstate that some properties are needed to classify individualsexclusive (e.g.; proper-part and to build class definitions such as Adult ,bounded-by). Since many biomedical ontologies and should therefore be supported by reasoners. User base points out that the current OWL datatype formalism is much too weak to support most real worldapplications and that many potential users therefore cannot adopt OWL. It also points out some limitations relatedrefer to annotations or metamodelling from an implementors perspective: " Despitethe value of annotationFMA anatomical entities through cross-references, keys would be highly useful.

3.3 Use Case #3 - Classification of information about a property enables tools to control the values that annotation properties can acquire. Without range constraints it is difficult to providechemical compounds [HCLS]

Functional groups describe the user with appropriate input widgets.semantics of chemical reactivity in a similar sense, it is often helpful to declare meta-classes so that classes can be categorized into typesterms of atoms and different interfaces be pro-vided for each type. Currently, using these features means that the ontology will be forced into OWL Full. " [ Protege ] Requires : Datatypes extension, Annotations, Metamodelling 3.13their connectivity, which exhibit characteristic chemical behavior when present in a compound. In this use case #13 Web service modelling [Telecom] People often want to usethe authors take a class to specifyfirst step towards designing an OWL-DL ontology of functional groups for the valueclassification of some property. An example originating atchemical compounds, highlight the Universitycapabilities and limitations of Karlsruhe [ Web Service ] isOWL 1 and the proposed OWL 1.1 in service modeling. Services are modeled as instancesterms of domain requirements. They also describe the a:Service class. For each concrete service (i.e., for each instanceapplication of a:Service), the users wanted to state whatexpressive features in the inputdesign of an ontology of basic relations and how, an upper level ontology, can be used to guide the service is. Here is an exampleformulation of a service description: (1) a:Service rdf:type owl:Class (2) a:Person rdf:type owl:Class (3) s1 rdf:type a:Service (4) s1 a:input a:Person s1 is an individual duelife science knowledge. They report on experiences to (1)enhance existing ontologies so as to facilitate knowledge representation and (3),question answering.

3.4 Use Case #4 - Querying multiple sources in an automotive company [Automotive]

Large companies often store information and a:Person isknowledge in multiple information systems using various models and formats. A class duemain issue is to (2); hence, in (4) we haveretrieve the relevant knowledge for a relationship between an individualspecific concern from the different sources. The aim of the application is to query multiple data and knowledge sources for a class. Hence, you need some kind of metamodelinglarge automotive company faced to solvethis problem. One way would be that the name 'Person' may refer both to Person asFor this applications a class and as an individual denoting Personaslanguage with a whole (Class Individual) [ Web Service ]profile facilitating multiple databases querying and easy represention of Parts Library ISO 13584 Standard (PLIB) ontologies of Products, which is particularly used for e-business catalogues, would be really helpful.

3.5 Use Case #14 Managing vocabulary in collaborative environments [Designer] It can be useful to relate schema elements (classes/properties) with each other in order#5 - OBO ontologies for biomedical data integration [HCLS]

The Open Biomedical Ontologies (OBO) consortium is pursuing a strategy to capture pragmatic relationships between them. An example observed in applications of Semantic MediaWiki (a simple but widely used OWL-based semantic content management system with light-weight expressiveness) [ OWL1.1 Wiki ] is that users wish to relate schema elements to indicate domain-specific relationships, and generally to organise ontological vocabulary. Examples are statements such as: "The property is_located_in is infacilitate the class Deprecated_Properties and was replaced by property has_location ." "Objectsintegration of biomedical data through their annotation using common controlled ontologies. Existing OBO ontologies, including the class City should have a value for the property population ." (expressed by relating class and property) TheseGene Ontology, are merely pragmatic descriptions,undergoing coordinated reform, and no logical relationshipnew ontologies are being created on schema-level is intended. However, in collaborative vocabulary creation, it is relevant that users can express such intended relationships.the basis of an important aspectevolving set of Semantic MediaWiki is that users can also query for semantic information, and thisshared principles governing ontology development. The result is currently realised as intended by punning. Semantic MediaWiki has already been extended by using off-the-shelf OWL reasoners, and it would be desirable if such systems wouldan expanding family of OBO ontologies designed to be ableinteroperable and to deal with the useincorporate accurate representations of punning in such simple cases;(Class/Property Individual) [ Wiki ] [ Punning ] Requires : Metamodelling 3.15 Use Case #15 UML Association Class [Designer] The Unified Modeling Language (UML) includes a modeling element known as an Association Class which combinesbiological reality. Within that effort the featuresOBO ontology of relations is designed to define a UML Class and a UML Association (UML's construct for defining class to class relationships Association ). The Association Class allows a modeler to define a relation as an association and reify it simultaneously. This is convenient when one wants to model attributesset of basic relations themselves. One way to suppotwith their semantics. OBO qualifies each relation using characteristics of being transitive, symmetric, reflexive, anti-symmetric. More generally OBO format offers constructs such case might be Class and Objectas is_reflexive, is_symmetric, is_cyclic, is_anti_symmetric, etc. that are used in the OBO obtologies. Converting OBO ontologies requires the new OWL 2 property punning(Class ObjectProperty).axioms reflexive, irreflexive, asymmetric to map corresponding OBO constructs, otherwise they should be transformed into annotations.

3.6 Use Case #16 Database federation [Designer] Some life sciences application designer has been building a database federation scheme. The scheme involves designing an XML schema that describes#6 – Spatial and topological relationships at the fieldsOrdnance Survey [Earth and values inSpace]

Ordnance Survey is Britain's National Mapping Agency. It currently maintains a varietycontinuously updated database of databases,the topography of Great Britain. The database includes around 440 million man-made and associated query tools that,natural landscape features. These features include everything from a query interface, can write queries (in several variants of SQL)forests, roads and rivers down to databases that have relevant information. Those resultsindividual houses, garden plots, and even pillar boxes. In addition to this topographic mapping, entire new layers of information are presentedprogressively being added to the database, such as a single integrated view. He hears that OWLaerial photographic images which precisely match the mapping; data providing the addresses of all properties; and Semantic Web technologies might be a suitable technologyintegrated transport information. Here for implementingthe same functionalitytopological and making it available using Web standards, but doesn't know where to start. This application illustrates common needs of a wide community of users that would like to use their databasesspatial relationships, and can easily query themin many other places, “we need to be able to say whether a convivial way. This motivates a profile where conjunctive query answeringproperty is implemented using conventional relational database systems (see Profiles OWL-DB ).reflexive, irreflexive, asymmetric or antisymmetric in order to capture the true intentions of our axioms”.

3.7 Use Case #17 Tools developpers [Tool] Requires : Declaration [ OWL1.1 Tools ] [ DIG2 ] [ OWL API ] 4 Requirements 4.1 R1: Disjoint Union While OWL provides means to define#7 - The Systematized Nomenclature of Medicine (SNOMED CT) [HCLS]

The Systematized Nomenclature of Medicine, Clinical Terms (SNOMED CT) is a setwork of subclassesclinical terminology with broad coverage of the domain of health care, and it has been selected as a disjointnational standard for use in electronic health applications in many countries, including the U.S., U.K., Canada, Australia, Denmark, and complete covering, this cannot be done concisely. This isothers. SNOMED was originally published in 1976, while SNOMED CT became available in 2002 as a shortcoming givenmajor expansion resulting from the common usemerger of such constructs in domain models. Motivating use cases: Use Case #1, Use Case #2, Use Case #3, Use Case #4 Resulting OWL2 feature: DisjointUnion 4.2 R2: Disjoint Classes Disjointness among classes abounds in domain models yet OWL has no single construct (akin to AllDifferent) to assert that a set of classes are mutually disjoint. Motivating use cases: Use Case #1 Use Case #2, Use Case #3 Resulting OWL2 feature: DisjointClasses 4.3 R3: Negative Property Assertion NeedSNOMED RT with the ability to state facts about an individual stating property values thatU.K.'s Clinical Terms version 3. A major distinguishing feature differentiating it does not have. Motivating use cases: Use Case #9 Resulting OWL2 feature: NegativeObjectPropertyAssertion 4.4 R4: Local reflexivity OWL does not allowfrom prior editions is the definition of a subclass of processes that are processes that auto-regulate themselves. Expressing this requires local reflexivity. Motivatinguse cases: Use Case #5 Resulting OWL2 feature: Self Restriction 4.5 R5: Qualified Cardinality OWL allows for the definitionof a person with at least three children (informal syntax: atleast 3 hasChildren), but notdescription logic (DL) to define and organize codes and terms. Another major distinguishing feature of a personSNOMED is its size and complexity. With at least three Girl (atleast 3 hasChildren Girl). Expressingover 350,000 concept codes, each representing a different class, it is an order of magnitude larger than the latter class requiresnext largest DL-based ontology of which we are aware. The qualificationsize of the targetOWL XML/RDF form of SNOMED is approximately 248 MB, and this is just the property hasChildren. Ontology modelers have repeatedly identifiedDL representation without all the importance of Qualified Cardinilaty Restrictions (QCRs)in various applications as illustratedsynonyms, mappings, subsets, and other special-purpose components of the terminology. Without property chain inclusion axioms, adoption of OWL by many use cases such as those listed below. Motivating use cases: Use Case #1 Use Case #2, Use Case #3the SNOMED community would have required awkward workarounds with their attendant complications and complexities - effectively killing movement in that direction. With [them], we have a clear path to using OWL 2 for further development and integration with other biomedical ontologies. Like the FMA given the common use Case #4of SNOMED cross-references, keys would be highly useful.