Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
The OWL Working Group seeks public feedback on these Working Drafts. Please send your comments to public-owl-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internal-review comments and changes being drafted which may address your concerns.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
NOTE TO READERS: You are reading a snapshot of anexample:AllDisjoint8.1UserPerspective8.2TheoreticalPerspective8.3ImplementationPerspectiveif(window.showTocToggle){vartocShowText="show";vartocHideText="hide";showTocToggle();}WARNING:editors' draftDOCUMENTUNDERPROGRESS...MediaWikidoesn'twarneditorsin progress. It represents input ofotherswhomaybeeditingsimultaneouslyPleaseputawarningherebeforeyoumakecomprehensiveorstructuralchanges.Pleasealsoindicatehowlongyouexpecttohavenumber of contributors but has not been vetted by any one of them, and certainly does not represent a consensus view of the material. This frozen copy was made for the working group to review in order to get a sense as to where this document"locked"is going and engender feedback as to howyoucanbereachedwhileyouareediting.it should mature.
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.
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.
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.
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.
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.
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.
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.
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.
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.
(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)
A clinical/biomedical informatician would like to create an ontology that helps in clinical decision support at the point of care. He or she would like to re-use pre-existing controlled vocabularies such as Snomed, Foundational Model of Anatomy, etc. to be able to represent rich clinical descriptors that characterize location of fractures in various parts of the bones. How can OWL 2.0 help the informatician in this regard. Are there new constructs in OWL 2.0 that enable a more compact and understandable rerpesentation of the ontology, both from an authoring and a use perspective?
(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)
An Information Modeler/Architect is typically charged with developing Enterprise Information Models, that would form components of an Information Architecture underlying the SOA based system architecture. The typical MDA (Model Driven Architecture) practitioner falls under this heading. MDA practitioners tend to be senior software architects within an organization, charged with developing an integrated set of platform-independent models of an application or system's business functionality and behavior, so that they can be reused across a variety of implementation platforms. In some sense both the Information Modeler/Architect and the MDA practitioner share the same set of goals. How can OWL 2.0 help these users achieve key benefits such as: (A) standardization of definitions to enable information interoperability across services and applications; (B) minimization of transformations between enterprise models and local application data models and structures; (C) Modeling business vocabularies (and/or ontologies) relevant for a particular domain independently from the software and rules development, and reusing the same consistent vocabulary across multiple applications or services.
(From http://esw.w3.org/topic/HCLS/ParkinsonUseCase)
This user type is similar to a Business Manufacturing Standards Developer and is an expert in various domains of clinical medicine such as neurology, internal medicine and others. These users typically work in conjunction with clinical informaticians, where they provide the domain knowledge and the informatician works on creating the appropriate representations in some knowledge representation language. The primary concern for this user is the ability to represent the types of knowledge and the ability to reason with and query information represented in a language In particular, it will be an important requirement for the OWL 2.0 to represent the following types of clinical and healthcare knowledge:
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.
How can OWL 2.0 enable a better representation of the medical record of a patient and address some of the shortcomings seen in the proposals above?
(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:
The above questions create requirement for:
These requirements are related to the OWL 2.0 features of:
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.
[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 withinbrackets?brackets ?
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.
Requires: Property chain inclusion axioms, Keys
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.
[Agence Biomedecine] [Transplant Ontology]
Requires: Negative Property Assertion, Datatypes extension
(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)
A Prinicipal Investigator (PI) is leading an NIH project which involves gathering and integrating data from many laboratories funded by the NIH, in one area of biomedicine. Although familiar with the construction of ontologies, the PI wants to figure out how he might exploit ontologies to better work with his data, and understand how OWL 2.0 can fit in to the picture. How can OWL 2.0 be used in conjunction with or in migration from relational databases. The PI would be interested in knowing how using OWL 2.0 for implementing an integrated system would be better than existing approaches.
(From http://esw.w3.org/topic/HCLS/ParkinsonUseCase)
This user type is similar to a Business Manufacturing Standards Developer and is an expert in various domains of the Life Sciences, such a systems physiology, cellular and molecular biology and others. These users typically work in conjunction with biomedical informaticians, where they provide the domain knowledge and the informatician works on creating the appropriate representations in some knowledge representation language. The primary concern for this user is the ability to represent the types of knowledge and the ability to reason with and query information represented in a language In particular, it will be an important requirement for the OWL 2.0 to represent the following types of life sciences knowledge:
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.
[FMA]
Requires: Disjoint Union, Disjoint Classes, Qualified Cardinality Restrictions, Disjoint Properties, Keys
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.
Requires: Disjoint Union, Disjoint Classes, Qualified Cardinality
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.
Requires: Reflexive, Irreflexive, Asymmetric, Property chain inclusion axioms, [Antisymmetric]
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
Requires: Qualified cardinality restriction, Reflexivity, Property chain inclusion axioms
(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)
A Manufacturing Technical Standards Developer has some knowledge of manufacturing systems and processes and develops standard data formats, models, and/or protocols which enable integration or replacement of manufacturing systems. Typically could be a systems integrator, solution provider, system developer, or information modeler/architect. Probably has detailed familiarity with XML, EDI and/or some class of communications middleware. May have knowledge of one or more data modeling (e.g. NIAM/ORM or EXPRESS), object modeling (UML), or schema modeling languages.
(From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents)
A Manufacturing Business Standard Developer has knowledge of a particular process, activity, and/or system in a manufacturing business. He might know some details of data related to that process or system but will likely prefer to use office applications (word processor and/or spreadsheet tool) to capture the information. He might be considered similar to a Subject Matter expert user type in the Healthcare and Life Sciences. In the context of developing consensus standards, he can work in conjunction with a competent information modeler or informatician to capture information and interpret the language for others. He has come to appreciate a modeling or ontology language as enabling richer shared understanding and more precise agreement on what is being standardized. To what extent can OWL 2.0 forward the goal of enabling richer shared understanding and more precise agreement on what is being standardized?
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.
[Auto]
Requires: Disjoint Union, Qualified Cardinality
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.
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 andResolutionother publications that are the sources for our requirements and/or definitions such as thisapplicationtriestodetectadverseeventsone above.
from http://lwsde.gsfc.nasa.gov/VO_Framework_7_Jan_05.doc
. Numerous single discipline and clinical conditions in responsemulti-discipline virtual
observatories (e.g., http://vsto.org,
http://vmo.nasa.gov/ ) are beginning to
a particular drug. It monitors theuse semantic technologies to provide data for unusal signs of clinical events that can be correlated with starting the patientaccess and integration.
Some Virtual Observatories are focusing quite heavily on a particular drug. It uses knowledge created by expertsprovenance
encoding at data ingest time (e.g., http://spcdis.hao.ucar.edu/ ).
Organizations like the Federation of Earth Science Information
Partners (ESIP - http://www.esipfed.org/ ) are looking
to determine an appropriate responsesemantic technologies to the adverse reaction 2.5.1.3 Patient Recruitment This applicaion seekssupport services ranging from
ontology-enhanced search to determine a setfairly detail oriented integration of
patient cohorts that qualify for a clinical trial, based on the clinical data associated with a patient and the inclusion and exclusion criteria associated with the clinical protocol. 2.5.2databases.
From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents
A scientist who is similarinterested in using semantic technologies to
perform information ontology-enhanced search over a Business Manufacturing Standards Developer and is anrepository or
set of repositories of scientific information. The subject matter
expert may need to review the science terms in various domains of clinical medicine such as neurology, internal medicine and others. These users typically work in conjunction with clinical informaticians, where they providethe domain knowledge andontology to
determine adequate coverage, they may need to enhance the informatician works on creatingontology
to include terms that are new to the appropriate representations inontology, and they may need to
check existing definitions. They also may need to check for
compliance with particular science vocabularies and thus may need
to look for terms and same-as relationships. Some knowledge representation language. The primary concerncritical support
for this userthese users is the ability to represent the typesbrowsing capabilities, targeted search, and
expressive power for representing mapping across terms and for
refining terms.
Much of knowledgeearth and the abilityspace science revolves around sophisticated
queries for data (that is largely numerical) but that is generated
by complicated processes. These users need to reason with and query information represented in a language In particular, it willbe an important requirementable to have
expressive power for the OWL 2.0representing numerical ranges and scientific
units and mathematical conversion processes. They also benefit from
being able to representexpress reasonably detailed scientific processes such
as those described in the following typesvolcano and atmosphere example of clinical knowledge: Clinical Researcher/Clinical Trials Investigator: Clinical researchersthe
SESDI project (Semantically-Enabled Scientific Data Integration).
(http://gsa.confex.com/gsa/2007GE/finalprogram/abstract_122252.htm
)
From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents
These users already have OWL 1.0 applications deployed and studieshave
significant amounts of programs written that seekconnect to evaluate the effects of a drug on a patient cohort.legacy
databases and web services. They are interested in informationneed to have migration support
tools including translators and knowledge such asdocumentation concerning transition
from both the diagnostic tests and imaging studies associated with a disease, therapeutic interventionslanguage 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 available evidence regardingthe diagnosisdocuments.
From http://www.ksl.stanford.edu/KSL_Abstracts/KSL-07-01.html
and management ofdeployed at http://vsto.org . The Virtual Solar
Terrestrial Observatory is a disease to generate human-readable clinical guidelines. There are now approachesNational Science Foundation and
National Center for Atmospheric Research supported effort that
seekallows researchers to semi-automatically created executable representations of these guideline. The informationfind solar and knowledge of interestsolar-terrestrial data. It
provides an ontology-enhanced interface to this user aare: the resultssemantically-enhanced
web services that help access a number of clinical trials, cost and benefitsonline repositories of
a drugscientific data. The background OWL ontology contains term
descriptions for science terms including instruments,
observatories, parameters, etc. Users essentially need to specify a
disease,description of the characteristicsdata they wish to retrieve which includes either
a specific instrument class or a description of that class, a clinical trial, such as the type, e.g., double blind randomized clinical trial,date
range for the sample sizedata taken, and power of the trial,the relationships between recommendations madeparameters. In the guidelineorder to specify
that in relevant science terms, scientists need to be able to
represent numerical ranges and comparisons (thus going beyond the
results and evidence strengthnumeric support of OWL 1). The clinical trial. 2.5.3 Use Cases 2.5.3.1application also needs to expand to
include spatial descriptions. It would use Case (New): Interoperation of Clinical Information across Healthcare and Clinical Trials Thisrepresentational power
if provided for spatial/geographic containment.
From http://spcdis.hao.ucar.edu/. In
an ongoing W3C task force on Clinical Observations Interoperability whereeffort to provide better search capabilities over meta
information in addition to scientific data, the goalSPCDIS effort is
providing infrastructure to enable re-use and sharingcapture declarative descriptions of
clinical data created in healthcare delivery in the Clinical Trials context. This requires clinical data represented using a healthcare specificscientific provenance information model (e.g., HL7/RIM) and a healthcare specific controlled terminology (e.g., Snomed) be mapped or transformed to clinical data usinc clinical trial specificat data models (e.g., CDISC/SDTM) and clinical trials specific controlled terminology (e.g., NCI Thesaurus). A setingest time. The initial
domain of mapping expressions expressed as N3 Rules are available at: http://esw.w3.org/topic/HCLS/ClinicalObservationsInteroperability/InterOntologyMapping.html . Somethe effort is solar coronal physics. This effort requires
(among other things) extended annotations (4.13 R13 in the
requirements that emerge from these example mappings can be summarized as: Representation of equivalences between a source classdocument) as well as datatype restriction (4.10
R10).
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”.
[Ordnance]
Requires: Reflexive, Irreflexive, Asymmetric, [Antisymmetric]
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.
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,
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.
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
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.
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:
This use case is based on an ongoing W3C task force on
Clinical Observations Interoperability where the most comprehensive ontologygoal is to
enable re-use and sharing of human ‘canonical’ anatomy. Anatomy plays a prominent roleclinical data created in biomedicine and many biomedical ontologieshealthcare
delivery in the Clinical Trials context. This requires clinical
data represented using a healthcare specific information model
(e.g., HL7/RIM) and applications refera healthcare specific controlled terminology
(e.g., Snomed) be mapped or transformed to anatomical entities. FMA isclinical data usinc
clinical trial specific data models (e.g., CDISC/SDTM) and clinical
trials specific controlled terminology (e.g., NCI Thesaurus). A tremendous resource in bioinformatics that facilitates sharingset
of information among applications that use anatomy knowledge.mapping expressions expressed as its authors claim, the FMA is “a reference ontology in biomedical informatics for correlating different viewsN3 Rules are available at:
http://esw.w3.org/topic/HCLS/ClinicalObservationsInteroperability/InterOntologyMapping.html.
Some requirements that emerge from these example mappings can be
summarized as:
Furthermore in some cases, one needs to map concepts in the
source terminology to concepts in the target terminology. (e.g.,
RxNorm), where the concepts may not exist at all in the target
terminology. In this usecase the authors takea first step towards designing an OWL-DLmediating ontology, e.g., Drug ontology
of functional groups for the classification of chemical compounds, highlightmay be used to define new classes required to create the capabilities and limitations of OWL1 andrelevant
mappings. For e.g., let's assume that the proposed OWL1.1source terminology
contains a medication class called WeightReduction which
doesn't exist either in terms of domain requirements. They also describethe application of expressive featuresmediating ontology or in the design of an ontology of basic relations and how, an upper level ontology,target
terminology. This can be used to guideachieved by defining an equivalent class
in the formulation of life science knowledge. They report on experiences to enhance existing ontologies soDrug Ontology as to facilitate knowledge representationDrugs that may treat Obesity and
question answering. [ Chemistry ] Requires : Disjoint Union, Disjoint Classes, Qualified Cardinality Profiles 3.4 Use Case #4 - Querying multiple sourcesidentify mappings from this composite class to concpets in an automotive company [Automotive] Large companies often store information and knowledgethe
target terminology. These examples are illustrated in
multiple information systems using various modelshttp://esw.w3.org/topic/HCLS/ClinicalObservationsInteroperability/DrugMapping.html
and formats. A main issue isgive rise to retrieve the relevant knowledge for a specific concern from the different sources.the aim offollowing requirements:
This use case is based on an ongoing W3C task force on Clinical
Observations Interoperability where the Open Biomedical Ontologies (OBO) consortiumgoal is pursuing a strategyto facilitate the integrationenable re-use
and sharing of biomedicalclinical data through their annotation using common controlled ontologies. Existing OBO ontologies, including the Gene Ontology, are undergoing coordinated reform, and new ontologies are beingcreated onin healthcare delivery in the
basis of an evolving set of shared principles governing ontology development.Clinical Trials context. In particular the result is an expanding family of OBO ontologies designed to be interoperable andfirst application chosen
to incorporate accurate representationsdemonstrate feasibility of biological reality. Within that effortthe OBO ontology of relationsinteroperability approach is designed to definethat
of patient recruitment. In this case, a sample set of basic relations with their semantics. OBO qualifiesclinical
trial protocols available from http://www.clinicaltrials.gov
each relation using characteristicsof being transitive, symmetric, reflexive, anti-symmetric. More generally OBO format offers constructs such as is_reflexive, is_symmetric, is_cyclic, is_anti_symmetric, etc. thatwhich contains a list of eligibility (inclusion and
exclusion criteria). These eligibility criteria are used for
identify eligible patients and potentially form conditions in the OBO obtologies. Converting OBO ontologies requires the newa
SPARQL query or could be represented as OWL 2 property axioms reflexive, irreflexive, asymmetric to map corresponding OBO constructs, otherwiseclasses. They shouldalso need
to be transformed into annotations. [ OBO ] [ RO ] [ OBO2OWL ] Requires : Reflexive, Irreflexive, Asymmetric, Property chain inclusion axioms, [Antisymmetric] 3.6mapped as per the discussion in the use case #6 – Spatial and topological relationships at the Ordnance Survey [Earth and Space] Ordnance Survey is Britain's National Mapping Agency. It currently maintainsabove. A continuously updated databaselist of
the topographyrequirements based on an analysis of Great Britain. The database includes around 440 million man-made and natural landscape features.these features include everythingclinical trial protcols
is available from
forests, roads and rivers down to individual houses, garden plots, and even pillar boxes.http://esw.w3.org/topic/HCLS/ClinicalObservationsInteroperability?action=AttachFile&do=get&target=FunctionalRequirements_v1.xls
In addition to this topographic mapping, entire new layers of information are progressively being added to the database, such as aerial photographic images which precisely match the mapping; data providing the addressesparticular, one of all properties; and integrated transport information. Here for the topological and spatial relationships, and in many other places, “we need to be able to say whether a property is reflexive, irreflexive, asymmetric or antisymmetric in order to capturethe true intentions of our axioms”. [ Ordnance ]clinical trials requires : Reflexive, Irreflexive, Asymmetric, [Antisymmetric] 3.7 Use Case #7 - The Systematized Nomenclature of Medicine (SNOMED CT) [HCLS]that the
Systematized Nomenclatureenrollment date of Medicine, Clinical Terms (SNOMED CT) isa work ofclinical terminology with broad coverage oftrial participant be within 30 days
after the domain of health care, and itpatient has been selected asstarted on a national standardparticular therapy. This
motivated the need for N-ary datatypes with inequality
expressions?
Requires: Datatypes extension
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
[N-ary]
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.
Note (cg). Theresponsibilitylist of UCs, initially composed of those I knew theAgencedelabiomedicine.Itincludesgeneralrulessuchas:donor-recipientABObloodgroupidentity,uniqueregistrationonbest mainly in thenationalwaitinglistanddefinitionofsomeorganspecificnation-wideallocationpriorities.Foreachkidneyrecipient,minimalHLAmatchingandforbiddenantigenscanbespecified.Pediatricrecipientsgetapriorityforpediatricdonors.KidneysHCLS domain, issued from the OWLED TF (extracted from TdM-UserReqTF.pdf), has been extended by other ones that I collected from different documents (papers, http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents ? WG emails about requirements etc.). The organisation is based along UCs/Requirements/ Features & Rationale, as it was decided at the UFDTF Telecon. Cross references links UCs/Requirements/ Features. Obviously other UCs areproposedwelcome, each UC being entered accompanied byorderofprioritylinks to(1)urgentpatients,(2)patientswithpanelreactiveantibodieslevel=80%includedinasome specificacceptableantigenprotocola) Requirements b) Reference - whatever OWLED or=1HLAmismatchother litterature c) Feature with short illustrative example(s) hopefully writen in OWL 2 syntax
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.
[ N-aryMEDICAL REQ]
[Ontology with
rules] [Brain
Imaging ]
Requires: Datatypes extension 3.12Disjoint Union, Disjoint Classes, Qualified
Cardinality Restrictions, Disjoint Properties, Property chain
inclusion axioms, N-ary predicate [rules]
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.
[FMA]
Requires: Disjoint Union, Disjoint Classes, Qualified
Cardinality Restrictions, Disjoint Properties, in OWL DL, properties that are declared as annotation properties are greatly limited in so far that they can neither have range or domain constraints, nor can they be arranged in sub-property hierarchies. This typeKeys,
Profiles
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.
Requires: Disjoint Union, Disjoint Classes, Qualified Cardinality Profiles
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.
[ PunningAuto]
Requires: Metamodelling 3.14Disjoint Union, Qualified Cardinality,
Profiles
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.
[ UMLOBO]
[ PunningRO] [OBO2OWL]
Requires: Metamodelling 3.16Reflexive, Irreflexive, Asymmetric, Property
chain inclusion axioms, [Antisymmetric]
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”.
Requires: Profiles 3.17Reflexive, Irreflexive, Asymmetric,
[Antisymmetric]
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.
Requires: Property chain inclusion axioms, Keys
Representing part-whole relations is a partvery 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 z, then x is a partthe common cases. The study
of z), reflexive (every objectpart-whole relations is a part of itself), and antisymmetric (ifan object as a part whichentire field in turn has part itself, then they are the same). Many applications, particularly those where ititself - "mereology"
- this note is necessaryintended only to describe complex structures such as life science, require extensive usedeal with straightforward cases for
defining classes involving part-whole relations. Several extensions
of whole needed for part-whole relations axiomatized according to these principles. Similarly, other relations encounteredare discussed in ontology modeling require similar axiomatizations, possibly with different setsthis study, namely,
needs of characteristics (see, e.g.,qualified cardinality restriction, reflexivity,
propagation from parts to whole
[ RO ]). Examples include properPartOf and locative relations (typically transitive and irreflexive), causal relations (typically transitive and irreflexive) and membership relations (typically irreflexive). Thus as illustrated by many use cases new charactersitics of properties is a strong requirement. Motivating use cases: Use Case #5 Use Case #6Requires: Qualified cardinality restriction,
Reflexivity, Property chain inclusion axioms Profiles
Allocation in France falls under the ability to state that roles are disjoint. This would mean thatresponsibility of the
same pairAgence 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 individuals couldsome organ specific
nation-wide allocation priorities. For each kidney recipient,
minimal HLA matching and forbidden antigens can be relatedspecified.
Pediatric recipients get a priority for pediatric donors. Kidneys
are proposed by at most oneorder of priority to (1) urgent patients, (2)
patients with panel reactive antibodies level = 80% included in a
set of disjoint propertiesspecific acceptable antigen protocol or =1 HLA mismatch with the
ontology/KB would be inconsistent. Thus if goodCop and badCop were disjoint rolesdonor, then Lennie (a Cop) would only be able to take one role(3) zero mismatch patients, and (4) patients with respect to any one suspect. Motivating use cases: Use Case #1low
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.
[Agence Biomedecine] [Transplant Ontology]
Requires: Negative Property Assertion, Datatypes extension
DESCRIPTION TO BE DONE: Vipul
=> keep it as acompositionofotherproperties.Inthiswayuserscandefinepropertiesthat"inherit"valuesfromanotherindividualparticular UC ordefineotherpropertiesasachainofrelations(asmerge withhasUncle).Motivatingusecases:Use Case#1#11 which includes it since 9 JUly teleconf ? if separate, its description or/and refrence have to be provided by the author.
Requires: Datatypes extension
Many Use Case #7cases that would benefit from datatype extensions are
described in [N-ary]
. Some of them require datatypes restrictions like intervals, other
ones require N-ary extensions. For example,
[N-ary]
Requires: Datatypes extension
[Protege]
reported in 2005 on Protégé experiences with the development of OWL
support, and on the experiences of 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 expressivity of OWL, it is possibleand
users’ understanding of OWL. To express restrictionssummarize, based on datatype properties qualified bytheir
experiences, Protégé developpers suggested a unary datatype (typically an XML Schema simple datatype).number of extensions
to a future version of OWL namely,
This report underlined that one could stateof the omissions in the OWL
language that every French citizen has a Passeport Number whichusers complain about most often is an xsd:string value ranges:poor
representation of numeric expressions. Almost all groups, except
for those developing traditional medical terminologies, sorely need
to be able to express quantitative information. Typical examples
include the length between 1mm and 2mm, age greater than 18 years,
pressure in the range of 1030mb to 1035mb. Such range declarations
are needed to classify individuals and to build class definitions
such as illustratedAdult, and should therefore be supported by
use cases in this document,reasoners. User base points out that the current OWL datatype
restrictions are required by many users. Motivating use cases: Use Case #9 Use Case #11 Use Case #12 Resulting OWL2 feature: Datatype restriction 4.11 R11: N-ary datatype (?)formalism is much too weak to be updated accordingsupport most real world applications
and that many potential users therefore cannot adopt OWL. It also
points out some limitations related to annotations or metamodelling
from an implementors perspective: "Despite the WG decision cf. discussion on MList [ N-ary ]value of
annotation properties, in OWL it is not possible either to represent the following statements: Relationships between values for one object: squares are rectangles whose length equals width; Relationships between values for different objects: people whoDL, properties that are older than their boss;declared as
illustrated by use cases listed below, N-ary datatypesannotation properties are required by users. Motivating use cases: Use Case #11 Use Case #12 Resulting OWL2 feature: N-ary datatype 4.12 R12: Simple metamodeling capabilities For a class Eagle of individuals it might be wanted to represent the two following different statements: Metadata (metalogical information) about the class Eagle that would saygreatly limited in so far that class Eagle was created by "C. Welty"they can
neither have range or domain constraints, nor can they be arranged
in 1994, ID.sub-property hierarchies. This was already possible in OWL 1 and is still possible in OWL 2 by means of entity annotation (informally, by annotationstype of the entity Eagle by creator: C. Welty, year: 1994) Statementinformation about the Eagle specy asa
whole, expressing that "eagles are listed inproperty enables tools to control the IUCN Red Listvalues that is, Eagle denoting an individual of the RedListSpecies class. RedListSpeciesannotation
properties can acquire. Without range constraints it is then a metaclass. Modelingdifficult
to provide the user with metaclassesappropriate input widgets. In a similar
sense, it is commonly calledoften helpful to declare meta-classes so that classes
can be categorized into types 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
People often want to use the same term (name) fora class (Eagle viewed as a class) and forto specify the value of some
property. An instance (Eagle viewedexample originating at the University of Karlsruhe
[Web Service] is in
service modeling. Services are modeled as an individualinstances of the
Red Lista:Service class. For each concrete service (i.e., for each instance
of species), while not needinga:Service), the users wanted to have wholestate what the inferences powerinput to the
service is. Here is an example of metamodelling. For example,a biomedical application may simply likeservice 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 due to have(1) and (3), and a:Person is a colummnclass
due to (2); hence, in (4) we have a database which data are gene classes names, another one which data are molecular functions, e.g.; imported from the Gene Ontology. Such simple metamodelling capabilities isrelationship between an
individual and a common requirement in life sciences applications. CG: Use Case #12 is not really a satisfying example: though punning could be usedclass. Hence, you need some kind of metamodeling
to represent domain range and hierarchy for annotation as required by Use Case #12,solve this problem. One way would notbe good modelling. Should add a note? Motivating use cases: Use Case #12 Use Case #13 Use Case #14 Use Case #15 Resulting OWL2 feature: Punning 4.13 R13: Extended annotations OWL 1 annotations allowthat the name 'Person' may
refer both to associate (metalogical) information, suchPerson as a label or a comment likeclass and as an individual denoting
Personas a textual description of the entity to each ontology entity. Butwhole (Class ↔ Individual)
[Web Service] [Punning]
Requires: Metamodelling
It is alsocan be useful to associate metalogical informationrelate schema elements (classes/properties)
with axioms. For example, one might wanteach other in order to keep information about who assertedcapture pragmatic relationships between
them. An axiom or when. Therefore, it has been requiredexample 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:
These are mainly concerned by interoperability of the language with conventional relational DBMSmerely pragmatic descriptions, and products. While other ones,no logical
relationship on schema-level is intended. However, in collaborative
vocabulary creation, it is relevant that users can express such
intended relationships. An important aspect of Semantic MediaWiki
is that users can also query for semantic information, and this is
currently realised as the busines rules communityintended by punning. Semantic MediaWiki has
already been extended by using off-the-shelf OWL reasoners, and more generally conventional ruleit
would be desirable if such systems developpers and companies, rather favorwould be able to deal with the
interoperabilityuse of punning in such simple cases;(Class/Property ↔
Individual)
Requires: Metamodelling
The ontologyUnified Modeling Language with rules techniques and tools. Consequently, different profiles of languages have been requested by different types of users, ontologists, software developpers, tools implementors, anf for various application scenarios. The main profiles of languages that have emerged at(UML) includes a modeling element
known as an Association Class which combines the moment arefeatures of three kinds: a scalable language for large but rather simple ontologies that enables good time performance in reasoninga language close to database perspectiveUML
Class and easy to interoperate with conventional database systemsa language closeUML Association (UML's construct for defining class to
class relationships Association).
The rule perspectiveAssociation Class allows a modeler to define a relation as an
association and easyreify it simultaneously. This is convenient when
one wants to interoperate with conventional rulesystems Motivating use cases: Use Case #2 Use Case #3 Use Case #4 Usemodel attributes of relations themselves. One way to
suppot such case #8might be Class and Object Property punning(Class ↔
ObjectProperty).
Requires: Metamodelling
Some of their examples could be satisfied with anonymous individuals with particular property assertions. I have sentlife sciences application designer has been building a
database federation scheme. The authorsscheme involves designing an email asking about this. -EKW- Resulting OWL feature: Anonymous individual 5 Features & RationaleXML
schema that describes the use casesfields and requirements presentedvalues in the previous section motivateda numbervariety of
new features that the OWL 2 specification should meet asdatabases, and associated query tools that, from a standard ontology language for the Semantic Web. These featuresquery interface,
can be classified into different categories: extra syntactic sugar to make some common statements easier to say, e.g., the disjoint unionwrite queries (in several variants of classes new constructs that increase the expressivity for properties, e.g., qualified cardinality restrictions or property chain inclusion mechanismsSQL) to define new datatypes, e.g., data type restrictionsdatabases that
have relevant information. Those results are presented as a single
integrated view. He hears that OWL and facets for restrictingSemantic Web technologies
might be a datatypesuitable technology for implementing the same
functionality and making it available using Web standards, but
doesn't know where to start. This application illustrates common
needs of a subsetwide community of its values simple metamodeling capabilitiesusers that would like to express metalogical information about the entities of an ontology extended annotations capabilitiesuse their
databases and can easily query them in a convivial way. This
motivates a profile where conjunctive query answering is
implemented using conventional relational database systems (see
Profiles
OWL-DB ).
Requires: Profiles
TO annotate entities, ontologiesBE DONE
[OWL1.1 Tools] [DIG2] [OWL API]
Requires: Declaration
Note(cg): To me moved up close to othermajorinnovations:newlanguageprofiles(sublanguages),declarations,RDFmapping5.1Syntacticsugar"Syntacticsugar"datatype UCs
A virtual observatory is term for syntactic extensions that makea language friendlier to users yet don't extend the meaningsuite of the language. OWL2 adds syntactic sugar to make some common patterns easier to write. These provide more concise wayssoftware applications on a
set of computers that allows users to state disjointness among clases. There are two new shorthands available in OWL 2 for this: DisjointUnionuniformly find, access, and
DisjointClasses. 5.1.1 F1: DisjointUnion DisjointUnion defines a class as the union of other classes, all of which are pair-wise disjoint. It is a shorthand for owl:disjointWith statements used in combination with owl:unionOf to define a complete superclassuse resources (data, software, document, and image products and
services using these) from a setcollection of mutually disjoint subclasses. DisjointUnion := 'DisjointUnion' '(' { Annotation } Class ClassExpression ClassExpression { ClassExpression } ')' Examples. HCLS DisjointUnion( BrainHemisphere LeftHemisphere RightHemisphere ) ( Ax1 ) BrainHemispheredistributed product
repositories and service providers. A VO is a disjoint union of LeftHemisphereservice that unites
services and RightHemisphere . DisjointUnion( Lobe FrontalLobe ParietalLobe TemporalLobe OccipitalLobe LimbicLobe ) ( Ax2/ or multiple repositories. from http://lwsde.gsfc.nasa.gov/VO_Framework_7_Jan_05.doc
Numerous single discipline and multi-discipline virtual
observatories (e.g., http://vsto.org,
http://vmo.nasa.gov/ ) Lobeare beginning to
use semantic technologies to provide data access and integration.
Some Virtual Observatories are focusing quite heavily on provenance
encoding at data ingest time (e.g., http://spcdis.hao.ucar.edu/ ).
The Virtual Solar Terrestrial Observatory (VSTO) is a disjoint union of FrontalLobe ParietalLobe TemporalLobe OccipitalLobeNational
Science Foundation and LimbicLobe . DisjointUnion( Cell NucleatedCell NonNucleatedCell ) ( Ax3 ) Cell isNational Center for Atmospheric Research
supported effort that allows researchers to find solar and
solar-terrestrial data. It provides an ontology-enhanced interface
to semantically-enhanced web services that help access a disjoint unionnumber of
NucleatedCell and NonNucleatedCell .online repositories of scientific data. The above axioms mean: Ax1:background OWL ontology
contains term descriptions for science terms including instruments,
observatories, parameters, etc. Users essentially need to specify a
lobe is onedescription of the following types: frontal, parietal, temporal, occipital, limbic. Ax2: A Cell isdata they wish to retrieve which includes either
a nucleated cellspecific instrument class or a non-nucleated cell, and cannot be atdescription of that class, a date
range for the same time nucleateddata taken, and non-nucleated Ax3: An Amine Group is exclusively either a Primary Amine Group, a Secondary Amine Group or a Tertiary Amine Group Automotive industry domain DisjointUnion(CarDoor FrontDoor RearDoor TrunkDoor) ( Ax4 ) CarDoor is a disjoint union of FrontDoor RearDoor and TrunkDoor .the above axioms mean: Ax4: A car can have only front doors, rear doors and a trunk door Theoretical Perspective Since DisjointUnion is simply a shorthand for several disjointWith statementsparameters. In combination with unionOf, it does not change the expressiveness, semantics, or complexity of the language. Implementation Perspective Being syntactic sugar, it's possibleorder to take an ontologyspecify
that is OWL 1 except for DisjointUnionin relevant science terms, scientists need to be able to
represent numerical ranges and preprocess it into an equivalentcomparisons going beyond the numeric
support of OWL 1 ontology without DisjointUnion. Implementations, however, may prefer1. The application also needs to take special notices of DisjointUnion for more efficient loading reasons. Motivatingexpand to include
spatial descriptions. It would use casesrepresentational power if
provided for spatial/geographic containment.
[VSTO]
Requires: Qualified Cardinality, Datatype Restriction, [Defaults]
Note(cg): To me moved up close to other Extended annotations UCs
In an effort to provide better search capabilities over meta
information in addition to scientific data, the set are pair-wise disjoint. ItSPCDIS effort is
a shortand for several owl:disjointWith statements in OWL 1. DisjointClasses := 'DisjointClasses' '(' { Annotation } ClassExpression ClassExpression { ClassExpression } ')' Examples. HCLS DisjointClasses( LeftLung RightLung ) (Ax5) Nothing can be both a Leftlung and a RightLung . DisjointClasses( UpperLobeOfLung MiddleLobeOfLung LowerLobeOfLung ) (Ax6) UpperLobeOfLung MiddleLobeOfLung LowerLobeOfLung are pairwise disjoint. The FMA exhibit a huge number of such classes [4 C]: 3736 classes of template Left X vs Right X (e.g. Left lung vs Right lung) 13989 classes of template X left Y vs X right Y (e.g. Skin of right breast vs Skin of left breast) 25 classes with template Male X vs Female X (e.g. Male breast vs Female breast) 75 classes X male Y vs X female Y (e.g. Right side of male chest vs Right sideproviding infrastructure to capture declarative descriptions of
female chest) Theoretical Perspective Since DisjointClasses is simply a shorthand for several disjointWith statements it does not changescientific provenance information at data ingest time. The expressiveness, semantics, or complexityinitial
domain of the language. Implementation Perspective Being syntactic sugar, it's possible to take an ontology thateffort is solar coronal physics. This effort requires
(among other things) extended annotations as well as datatype
restriction.
[NCAR]
Requires: Datatype Restriction, Extended Annotations
UNDER PROGRESS: TO BE COMPLEMENTED. Each requirement of a subsection to be described at least by one short sentence.
While OWL 1 except for DisjointClasses and preprocess it into an equivalent OWL 1 ontology without DisjointClasses. Implementations, however, may preferprovides means to take special noticesdefine a set of DisjointClasses since the tersenesssubclasses as a
disjoint and "groupiness" make for more efficient loading.complete covering, this cannot be done concisely. This
is a shortcoming given the common use of such constructs in domain
models.
Motivating use cases:cases : Use Case #1#1, Use Case #2 5.1.3 F3: NegativeObjectPropertyAssertion NegativeDataPropertyAssertion OWL 2 provides the shortands NegativeObjectPropertyAssertion and NegativeDataPropertyAssertion for asserting negative facts. While an ObjectPropertyAssertion (resp. DataPropertyAssertion ) axiom states#2, Use
Case #3, Use Case #4
Resulting OWL2 feature:DisjointUnion
Disjointness among classes abounds in domain models yet OWL has
no single construct (akin to AllDifferent) to assert that a givenset of
classes are mutually disjoint.
Motivating use cases : Use Case #1 Use Case #2, Use Case #3
Resulting OWL2 feature: DisjointClasses
Need the given individuals, a NegativeObjectPropertyAssertion (resp. NegativeDataPropertyAssertion ) axiom states that a givenability to state facts about an individual stating
property values that it does not hold for the given individuals.have.
Motivating use cases : Use Case #9
Resulting OWL2 feature:NegativeObjectPropertyAssertion
OWL does not changeallow the expressiveness, semantics, or complexitydefinition of the language.a subclass of processes
that are processes that auto-regulate themselves. Expressing this
requires local reflexivity.
Motivating use cases:cases : Use Case #9 5.2 New constructs for Properties#5
Resulting OWL2 feature: Self Restriction
OWL 1 was mainly focused on constructsallows for expressing information about classes and individuals, but paid less attention to properties. As pointed out bythe use cases and requirements above, OWL 1 exhibited some weakness regarding expressivenes for properties. OWL 2 addressed it by complementing OWL 1definition of a person with new constructs that increaseat least three
children (informal syntax: atleast 3 hasChildren), but not of a
person with at least three Girl (atleast 3 hasChildren Girl).
Expressing the expressivitylatter class requires the qualification of the
language for properties, as requested by many users. OWL 2 offers new constructs for expressing additional restrictions on properties, new characteristicstarget of properties, incompatibilitythe property hasChildren. Ontology modelers have
repeatedly identified the importance of properties, properties chains and key properties. 5.2.1 F4: Self Restriction OWL 2 allows to assertQualified Cardinilaty
Restrictions on object properties(QCRs)in various applications as illustrated by means of the new construct ExistsSelf .many
use cases such as those listed below.
Motivating use cases : Use Case #1 Use Case #2, Use Case #3 Use Case #4 Use Case #8
Resulting OWL2 feature: Qualified cardinality
In mereology, the class expression ObjectExistsSelfpartOf relation is defined using an ExistsSelf restriction on an object property denotes the class of all objects that are connectedto themselves via the given object property. It canbe
viewed astransitive (if x is a kindpart of local reflexivity qualityy and y is a part of thez, then x is a
part of z), reflexive (every object property. ObjectExistsSelf := 'ExistsSelf' '(' ObjectPropertyExpression ')' Examples. HCLS ExistsSelf( regulates ) (Ax9) classis a part of all individuals that regulates themselves PropertyAssertion( regulates ThisProcess ThisProcess ) (Ax10) ThisProcess regulates itself. The above axiom means Ax9:itself), and
antisymmetric (if an object as a part which in turn has part
itself, then they are the self restriction ExistsSelf( regulates ) denotes the class of all individuals that regulates themselves. For example in biology (resp. mechanics, electricity etc.) it denotes, among all biomedical (resp. mechanical, electrical etc.) processes (or systems),same). Many applications, particularly
those objects that are auto-regulated. Consequently, the particular individual ThisProcess is an instance of the class ExistsSelf( regulates ) . Theoretical Perspective The description logic underlying OWL-DL is SHOIN. OWL 2where it is based on a more expressive description logic: SROIQ [ SROIQ ]. SROIQ extension of SHOIN was designednecessary to provide all possible useful additionsdescribe complex structures such as
life science applications, require extensive use of part-whole
relations axiomatized according to OWL-DL that were requested by users, while not affecting its decidability and practicability. SROIQ logic extends SHOINthese principles. Similarly,
other relations encountered in ontology modeling require similar
axiomatizations, possibly with reflexive, asymmetric,different sets of characteristics
(see, e.g., [OBO]
[RO]). Examples include
properPartOf and irrelexive roles, disjoint roles, a universal role,locative relations (typically transitive and
constructs R.Self. It also allows qualified number restrictionsirreflexive), causal relations (typically transitive and
negated role assertions in Aboxes. Addditionaly, SROIQ offers complex role inclusion axioms of the form R? S < R or S? R < R to express propagationirreflexive) and membership relations (typically irreflexive). Thus
as illustrated by many use cases new charactersitics of one property along another one, which have proven to be very useful in particular for biomedical ontologies (see F8: Property chain inclusion ). Implementation Perspectiveproperties
is a strong requirement.
Motivating use cases: 5.2.2 F5: Qualified cardinality OWL 2 allows to assert qualified cardinality restrictions on object or dataUse Case #5 Use Case #6 Use Case
#8
Resulting OWL2 feature: Reflexive, Irreflexive, Asymmetric
by means ofNeed the new constructs MinCardinality MaxCardinality ExactCardinality . A qualified cardinality restriction (QCR) defines a restriction onability to state that roles are disjoint. This would
mean that the numbersame pair of instancesindividuals could be related by at most
one among a set of the property and on their classdisjoint properties or data range.the addition that qualified cardinality restriction brings to the initial constructs for cardinality restrictions in OWL 1 isontology/KB would be
inconsistent. Thus if goodCop and badCop were disjoint roles then
Lennie (a Cop) would be able to allow defining restrictions nottake only on the number of instances of the property but also on the class or data rangeone of the instances. In OWL2, both qualified or unqualified cardinality restrictions are possible. An unqualified cardinality restriction is simply equivalentthese roles with
respect to a qualifiedany one where the restricting class is owl:Thing. 5.2.2.1 Objectsuspect.
Motivating use cases : Use Case #1 Use Case #2
Resulting OWL2 feature: Disjoint properties
Some properties are best defined usingas a MinCardinality , MaxCardinality or ExactCardinality restriction on an object property denotes the setcomposition of objectsother
properties. In this way users can define properties that are connected via the given object property to at least, at most,"inherit"
values from another individual or exactly the given number of individuals of the given class. Minimum Cardinality ObjectMinCardinality := 'MinCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')' Maximum Cardinality ObjectMaxCardinality := 'MaxCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')' Exact Cardinality ObjectExactCardinality := 'ExactCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')' Examples . HCLS The following examples are some examplesdefine other properties as a
chain of Objectrelations (as with hasUncle).
Motivating use cases : Use Case #1 Use Case #5 Use Case #7 Use Case #8
Resulting OWL2 feature: Property Cardinality Restrictions fromchain inclusion
Motivating use Casescases : Use Case #2 Use Case #7
Resulting OWL2 feature: Keys
OWL provides very limited expressive power for describing
classes whose features include concrete values such as integers and
strings. In HCLS among many. ExactCardinality( 1 hasDirectPart FrontalLobe ) (Ax11) Class of objects having exactly one direct part of type frontal lobe . MaxCardinality( 3 boundedTo Hydrogen ) (Ax12) Class of objects boundedOWL, it is possible to at most three different Hydrogen (Ax11) similarexpress restrictions allow expressing thaton datatype
properties qualified by a Brain Hemisphere has exactlyunary datatype (typically an XML Schema
simple datatype). For example, one direct part of type frontal, parietal, temporal, occipital, limbic lobecould state that every French
citizen has a Passeport Number which was not possibleis an xsd:string value ranges:
age greater than 18 years, pressure in OWL 1. Automotive industry MaxCardinality( 5 hasPart Door ) (Ax13) Class of objects having atmost 5 Door ExactCardinality( 2 hasPart FrontDoor ) (Ax14) Class of objects having exactly 2 FrontDoor ExactCardinality( 2 hasPart RearDoor ) (Ax15) Classthe range of objects having exactly 2 RearDoor ExactCardinality( 1 hasPart TrunkDoor ) (Ax16) Class of objects having exactly 1 TrunkDoor Ax13: this restriction allows expressing for example that a car has atmost 5 doors Ax14 Ax15 Ax16: these restrictions allow expressing for example that a five-door car has exactly three doors, two front doors, two rear doors, plus one trunk 5.2.2.2 Data Property Cardinality Restrictions Minimum Cardinality DataMinCardinality := 'MinCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')' Maximum Cardinality DataMaxCardinality := 'MaxCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')' Exact Cardinality DataExactCardinality := 'ExactCardinality' '(' nonNegativeInteger DataExactCardinality [ ClassExpression ] ')' Examples . HCLS MaxCardinality( 1 hasSSN ) (Ax17) Each object can have at most one Social Security Number Theoretical Perspective1030mb to
1035mb. As already said above, qualified cardinalityillustrated by use cases in this document, datatype
restrictions are present in the SROIQ desctiption logic underlying OWL 2 since they wererequired in various applications e.g.; [ Medical Req ] [ Little Web ] and did not pose theoretical or practical problemsby many users.
Motivating use cases : Use Case #9 Use Case #11 Use Case #12 Use Case #18
Resulting OWL2 feature: Datatype restriction
To beaddedupdated according to the WG decision cf. discussion on MList [SHOIQ].N-ary]
In OWL it was known fromis not possible either to represent the following
statements:
Motivating use Case #2,cases: Use Case #3,#11 Use Case #4 5.2.3 F6: Reflexive, Irreflexive, Asymmetric New characteristics can be asserted on Object Properties in OWL 2: Reflexivity, Irreflexivity, Asymmetry. 5.2.3.1 Reflexive Property A reflexivity axiom asserts that#12
Resulting OWL2 feature: N-ary datatype
For a given object property is reflexive that is,class Eagle of individuals it might be wanted to
represent the property holds for alltwo following different statements:
In mathematical notation, this is: x ( x R x ) IrreflexiveObjectProperty := 'IrreflexiveProperty' '(' { Annotation } ObjectPropertyExpression ')' Example HCLS IrreflexiveProperty( proper_part_of ) (Ax20) Nothing can be proper_part of itself. IrreflexiveProperty( connectedTo ) (Ax21) Nothing can be connectedcertain applications, one would simply like to itself. IrreflexiveProperty( boundedBy ) (Ax22) Nothing can be bounded by itself. Earthuse the same
term (name) for a class (Eagle viewed as a class) and Space IrreflexiveProperty( flowsInto )(Ax23) Nothing can flow into itself. Note: Ax20 Ax21 Ax22: this correspondsfor an
instance (Eagle viewed as an individual of the Red List of
species), while not needing to have whole the definitioninferences power of
metamodelling. For example, a biomedical application may simply
like to have a colummn in a database which data are gene classes
names, another one which data are molecular functions, e.g.;
imported from the mereological or topological properties anatomicalPartOf connectedTo boundedByGene Ontology. Such simple metamodelling
capabilities is a common requirement in life sciences
applications.
CG: Use Case#1.Otherapplicationsmayusethesetermswithotheracceptionse.g.;inchemistrymoeleculesmaybeself-connected.Ax23:flowsInto#12 isirreflexiveasnorivercanflowintothesameriver5.2.3.3AsymmetricPropertyAnirreflexivityaxiomassertsthatnot really agivenobjectpropertyisirreflexivethatis,ifthepropertyholdsbetweenindividualsxandy,thenitcannotholdbetweenysatisfying example: though punning could be used to represent domain range andx,orinmathematicalnotation,thisis:AsymmetricObjectProperty:='AsymmetricProperty''('{hierarchy for annotation}ObjectPropertyExpression')'ExamplesHCLSAsymmetricProperty(proper_part_of)(Ax24)Thepropertyproper_part_ofisasymmetric.Ax24:ifpisaproperpartofqthenqcannotas required by Use Case #12, this would not be good modelling. Should add aproperpartofpTheoreticalPerspectiveseeF4TheoreticalPerspectiveaboveImplementationPerspectivenote ?
Motivating use cases : Use Case #1 Use Case #2,cases: Use Case #3,#12 Use Case #5#13 Use Case #6#14
Use Case #7 5.2.4 F7: Disjoint properties#15
Resulting OWL2 feature: Punning
OWL 2 provides the new construct DisjointProperties for asserting that several properties are incompatible(exclusive).1 annotations allow to associate (metalogical) information,
such as a disjoint properties axiom takeslabel or a setcomment like a textual description of object properties and states that all properties fromthe
set are pair-wise disjoint;entity to each ontology entity. But it is also useful to associate
metalogical information with axioms. For example, one might want to
keep information about who asserted an axiom or when. Therefore, it
has been required to have extended annotations that is, no pair of individuals can at the same time be connected by two different properties ofallow for the
set. DisjointObjectProperties := 'DisjointProperties' '(' {annotation } ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')' Examples HCLS DisjointProperties( connectedTo contiguousTo ) (Ax25) connectedTo is disjoint with contiguousTo Ax25: Properties connectedTo and contiguousToof both entities and axioms.
Motivating use cases : Use Case #1#12 Use Case #19
Resulting OWL2 feature: Annotation
TBD (CG)
Motivating use cases
Resulting OWL2 features: Declaration
Requirements
Large Life Sciences ontologies like the FMA, NCI Thesaurus,
SNOMED CT, Gene Ontology or other OBO ontologies are exclusive, that ismainly
concerned by scalability issues of the language and do not
hold at the same time. According tonecessarily need the definitionwhole expressivity of these properties ([2]), when two anatomical entities are linked via an actual third anatomical entity, they are stated to be connected.OWL. On the opposite, when theyother side,
applications involving conventional database systems or Database
software companies, are not relatedmainly concerned by an actual entity but are adjacent via ainteroperability of the
language with conventional entity, they are said to be contiguous . Consequently, two parts cannot be both connectedrelational DBMS and contiguous. Theoretical Perspective see F4 Theoretical Perspective above Implementation Perspective Motivating use cases: Use Case #1 Use Case #2 Use Case #3 5.2.5 F8: Property chain inclusion OWL 2 allows to chain several object properties by meansproducts. While
other ones, such as the busines rules community and more generally
conventional rule systems developpers and companies, rather favor
the interoperability of the new construct PropertyChain . A propertyExpressionChain expression defines a chain between several object propertiesontology language with rules techniques
and tools. Consequently, different profiles of languages have been
requested by meansdifferent types of PropertyChain . propertyExpressionChain := 'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')' When used together with SubPropertyOf , an expression defined by PropertyChain provides a means to represent some types of rules. It allows in particular to expressusers, ontologists, software
developpers, tools implementors, anf for various application
scenarios. The propagationmain profiles of one property along another property, e.g.;languages that have emerged at the
propagationmoment are of three kinds:
Motivating use cases: Use Case #2 Use Case #3 Use Case #4
Use Case #8 Use Case #16
Resulting OWL2 feature: Profiles for OWL-EL++, OWL-DB, OWL-R
yTBD
Motivating use cases :
This may be motivated byachainthe "Ontologies in OWL for Rapid Enterprise Integration" paper from OWLED 2007. One ofobjectpropertiesp1,...,pn,thenxisalsoconnectedtheir requested extensions was for individual-denoting functions, where some of their examples could be satisfied withybytheobjectanonymous individuals with particular propertyp.Suchaxiomsarealsoknownascomplexroleinclusions[SROIQ].assertions. I have sent thefullexactsyntaxofPropertychaininclusionaxiomsismorepreciselyauthors an email asking about this. -EKW-
Resulting OWL feature: Anonymous individual
The following: propertyExpressionChain := 'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')' subObjectPropertyExpression := ObjectPropertyExpression | propertyExpressionChain SubObjectPropertyOf := 'SubPropertyOf' '(' { Annotation } SubObjectPropertyExpression ObjectPropertyExpression ')' Examples HCLS SubPropertyOf( PropertyChain( locatedIn partOf ) locatedIn ) If x is locatedIn y ,use cases and y is partOf z , then x is locatedIn z ; for example a disease locatedrequirements presented in the previous section
motivated a part is located innumber of new features that the whole. Theoretical PerspectiveOWL 2 is based on SROIQ which offers complex role inclusion axioms that include axioms ofspecification
should meet as a standard ontology language for the form R ◦ S < R or S ◦ R < RSemantic Web.
These features can be classified into different categories:
UnderdevelopmentforOWL2,e.g.;Protégé4,FACT++,PELLET,RACER,dealswithallthefeaturesabove[TOOLS][OWLAPI].Note(Christine):Notsureit'srigorouslyexactforall,Progres: TO BEcheckedandprecisedCOMPLEMENTED. Each feature is supposed to be accompanied byimplementorsMotivatingusecases:UseCase#1UseCase#5* a short introduction informal sentence * its syntax + link to the Syntax doc * simple example(s) issued from UseCase#75.2.6F9:KeyCases * Theoretical Perspective * Implementation PerspectiveMotivatingusecases:5.3Newdatatypesmechanisms5.3.1F10:DatatyperestrictionOWLallows* UCs corresponding to thedefinitiongiven examples
"Syntactic sugar" is a term for syntactic extensions that make a
language friendlier to users yet don't extend the meaning of the
language. OWL2 adds syntactic sugar to make some common patterns
easier to write. Among these are two new datatypes by specifying restrictions on XML Schema datatypes by means of facetsshorthands that restrainprovide
more concise ways to state disjointness among classes. These
shorthands are: DisjointUnion and DisjointClasses.
DisjointUnion defines a class as the rangeunion of values allowed forother classes, all
of which are pair-wise disjoint. It is a given unary datataype. Facetsshorthand for
owl:disjointWith statements used in incombination with owl:unionOf to
define a DatatypeRestriction can be one of length, minLength, maxLength, pattern, minInclusive, minExclusive, maxInclusive, maxExclusive, totalDigits, and fractionDigits. Examples HCLS DatatypeRestriction(xsd:integer minInclusive 18) new datatype with a lower bound of 18 on the XML Schema datatype xsd:integer. At hospital, patients under 18 (child) depend on pediatric services while over 18 (adult) depend on adult services Motivating use cases: Use Case #9 Use Case #11 Use Case #12 Theoretical Perspective Implementation Perspective Motivating use cases: 5.3.2 F11: N-ary datatype OWL 2 extends the unary datatypes of OWL 1 to n-ary datatypes, thus allowing to compare values of data properties forcomplete superclass from a given object, for example the admisssion temperatureset of a patient to his current temperature. It allows more generally to use n-ary datatypes such as those built from linear expressions. facet := 'length' | 'minLength' | 'maxLength' | 'pattern' | 'minInclusive' | 'minExclusive' | 'maxInclusive' | 'maxExclusive' | 'totalDigits' | 'fractionDigits' restrictionValue := Constant DatatypeRestriction := 'DatatypeRestriction'mutually disjoint
subclasses.
DisjointUnion :=
'DisjointUnion' '(' Datatype facet restrictionValue{ facet restrictionValueAnnotation }
Class ClassExpression ClassExpression { ClassExpression } ')'
ExamplesExamples.
|
BrainHemisphere is |
|
Lobe is |
DisjointUnion(Cell NucleatedCell NonNucleatedCell) (Ax3) | Cell is |
The above axioms mean:
Ax1: A single given object e.g., in any patient,lobe is one of the systolic blood pressurefollowing types: frontal,
parietal, temporal, occipital, limbic.
Ax2: A Cell is always greatereither a nucleated cell or equal than the diastolic blood pressure. Theya non-nucleated
cell, and cannot be used to compare valuesat the same time nucleated and
non-nucleated
Ax3: An Amine Group is exclusively either a Primary Amine Group, a Secondary Amine Group or a Tertiary Amine Group
DisjointUnion(CarDoor FrontDoor RearDoor TrunkDoor) (Ax4) | CarDoor is a disjoint union of |
The above axioms mean:
Ax4: A car can have only front doors, rear doors and a trunk door
Theoretical Perspective
Since DisjointUnion is simply a shorthand for different objects (e.g., definingseveral
disjointWith statements in combination with unionOf, it does
not change the classexpressiveness, semantics, or complexity of individuals whose body weight is superior than their mother's) which leads to undecidability.the
language.
Implementation Perspective
Being syntactic sugar, it's possible to take an ontology that is OWL 1 except for DisjointUnion and preprocess it into an equivalent OWL 1 ontology without DisjointUnion. Implementations, however, may prefer to take special notices of DisjointUnion for more efficient loading reasons.
Motivating use cases:cases : Use Case #11#1 Use Case #12 5.4 Simple metamodeling capabilities 5.4.1 F12: Punning Theoretical Perspective Implementation Perspective Motivating#2,
Use cases: 5.5 Extended annotations 5.5.1 F13: Annotation OWL 2 provides for annotationsCase #3, Use Case #4
DisjointClasses on ontologies, entities, including anonymous individuals, and axioms. Below an extract ofits part only states that all classes from
the syntax usedset are pair-wise disjoint. It is a shortand for axioms: subClassExpression := classExpression superClassExpression := classExpression SubClassOf := 'SubClassOf'several
owl:disjointWith statements in OWL 1.
DisjointClasses :=
'DisjointClasses' '(' { Annotation
} subClassExpression superClassExpressionClassExpression ClassExpression { ClassExpression } ')'
Annotation := AnnotationByConstant | AnnotationByEntity | AnnotationByAnonymousIndividual For detailed syntax refer to Section 9 Annotations of the Syntax document. Theoretical Perspective Implementation Perspective Motivating use cases: 5.6 Other main innovative features 5.6.1 F14: Declaration Theoretical Perspective Implementation Perspective Motivating use cases: 5.6.2 F15: Profiles OWL-EL++, OWL-DB, OWL-R OWL 2 defines several profiles, sublanguages with useful computational propertiesExamples.
DisjointClasses( LeftLung RightLung ) (Ax5) | Nothing can be both a Leftlung and |
DisjointClasses( UpperLobeOfLung MiddleLobeOfLung LowerLobeOfLung ) (Ax6) | UpperLobeOfLung MiddleLobeOfLung
LowerLobeOfLung are |
The NCI thesaurus Features include existential restrictions, intersection, subClass, equivalentClass, class disjointness, range and domain, transitive properties, … Missing features include value restrictions, Cardinality restrictions (min, max and exact), disjunction and negation OWL-DB Captures expressive powerFMA exhibit a huge number of simple ontologies like thesauri, and (most of) expressive powersuch classes [4 C]: 3736
classes of ER/UML schemas Features include limited formtemplate Left X vs Right X (e.g. Left lung vs
Right lung) 13989 classes of existential restrictions,template X left Y vs X right Y
(e.g. Skin of right breast vs Skin of left breast) 25 classes with
template Male X vs Female X (e.g. Male breast vs Female
breast) 75 classes X male Y vs X female Y (e.g. Right
side of male chest vs Right side of female chest)
Theoretical Perspective
Since DisjointClasses is simply a shorthand for several disjointWith statements it does not change the expressiveness, semantics, or complexity of the language.
Implementation Perspective
Being syntactic sugar, it's possible to take an ontology that is OWL 1 except for DisjointClasses and preprocess it into an equivalent OWL 1 ontology without DisjointClasses. Implementations, however, may prefer to take special notices of DisjointClasses since the terseness and "groupiness" make for more efficient loading.
Motivating use cases: Use Case #1 Use Case #2
OWL 2 provides the shortands NegativeObjectPropertyAssertion and NegativeDataPropertyAssertion for asserting negative facts. While an ObjectPropertyAssertion (resp. DataPropertyAssertion) axiom states that a given property holds for the given individuals, a NegativeObjectPropertyAssertion (resp. NegativeDataPropertyAssertion) axiom states that a given property does not hold for the given individuals.
NegativeObjectPropertyAssertion := 'NegativePropertyAssertion' '(' { Annotation } objectPropertyExpression sourceIndividual targetIndividual ')'
NegativeDataPropertyAssertion := 'NegativePropertyAssertion' '(' { Annotation } DataPropertyExpression sourceIndividual targetValue ')'
Examples.
NegativePropertyAssertion( livesIn ThisPatient Paris ) (Ax7) | This patient does not live in Paris. |
NegativePropertyAssertion( hasAge ThisPatient 5^^xsd:integer ) (Ax8) | This patient is not five years old. |
Theoretical Perspective
Since NegativePropertyAssertion is simply a shorthand it does not change the expressiveness, semantics, or complexity of the language.
Motivating use cases: Use Case #9
OWL 1 was mainly focused on constructs for expressing information about classes and individuals, but paid less attention to properties. As pointed out by the use cases and requirements above, OWL 1 exhibited some weakness regarding expressivenes for properties. OWL 2 addressed it by complementing OWL 1 with new constructs that increase the expressivity of the language for properties, as requested by many users. OWL 2 offers new constructs for expressing additional restrictions on properties, new characteristics of properties, incompatibility of properties, properties chains and key properties.
OWL 2 allows to assert restrictions on object properties by means of the new construct ExistsSelf. The class expression ObjectExistsSelf defined using an ExistsSelf restriction on an object property denotes the class of all objects that are connected to themselves via the given object property. It can be viewed as a kind of local reflexivity quality of the object property.
ObjectExistsSelf := 'ExistsSelf' '(' ObjectPropertyExpression ')'
Examples.
ExistsSelf( regulates) (Ax9) | class of all individuals that regulates themselves |
PropertyAssertion( regulates ThisProcess ThisProcess ) (Ax10) | ThisProcess regulates itself. |
The above axiom means
Ax9: The self restriction ExistsSelf( regulates ) denotes the class of all individuals that regulates themselves. For example in biology (resp. mechanics, electricity etc.) it denotes, among all biomedical (resp. mechanical, electrical etc.) processes (or systems), those objects that are auto-regulated. Consequently, the particular individual ThisProcess is an instance of the class ExistsSelf( regulates ).
Theoretical Perspective
The description logic underlying OWL-DL is SHOIN. OWL 2 is based on a more expressive description logic: SROIQ [SROIQ]. SROIQ extension of SHOIN was designed to provide all possible useful additions to OWL-DL that were requested by users, while not affecting its decidability and practicability. SROIQ logic extends SHOIN with reflexive, asymmetric, and irrelexive roles, disjoint roles, a universal role, and constructs ∃ R.Self. It also allows qualified number restrictions and negated role assertions in Aboxes.
Addditionaly, SROIQ offers complex role inclusion axioms of the form R ? S < R or S ? R < R to express propagation of one property along another one, which have proven to be very useful in particular for biomedical ontologies (see F8: Property chain inclusion).
Implementation Perspective
Motivating use cases:
OWL 2 allows to assert qualified cardinality restrictions on object or data properties by means of the new constructs MinCardinality MaxCardinality ExactCardinality.
A qualified cardinality restriction (QCR) defines a restriction on the number of instances of the property and on their class or data range. The addition that qualified cardinality restriction brings to the initial constructs for cardinality restrictions in OWL 1 is to allow defining restrictions not only on the number of instances of the property but also on the class or data range of the instances. In OWL2, both qualified or unqualified cardinality restrictions are possible. An unqualified cardinality restriction is simply equivalent to a qualified one where the restricting class is owl:Thing.
The class expressions ObjectMinCardinality, ObjectMaxCardinality, and ObjectExactCardinality defined using a MinCardinality, MaxCardinality or ExactCardinality restriction on an object property denotes the set of objects that are connected via the given object property to at least, at most, or exactly the given number of individuals of the given class.
ObjectMinCardinality := 'MinCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'
ObjectMaxCardinality := 'MaxCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'
ObjectExactCardinality := 'ExactCardinality' '(' nonNegativeInteger ObjectPropertyExpression [ ClassExpression ] ')'
Examples.
The following examples are some examples of Object Property Cardinality Restrictions from Use Cases in HCLS among many.
ExactCardinality( 1 hasDirectPart FrontalLobe ) (Ax11) | Class of objects having exactly one direct part of type frontal lobe. |
MaxCardinality( 3 boundedTo Hydrogen) (Ax12) | Class of objects bounded to at most three different Hydrogen |
(Ax11) similar restrictions allow expressing that a Brain Hemisphere has exactly one direct part of type frontal, parietal, temporal, occipital, limbic lobe which was not possible in OWL 1.
MaxCardinality( 5 hasPart Door ) (Ax13) | Class of objects having atmost 5 Door |
ExactCardinality( 2 hasPart FrontDoor ) (Ax14) | Class of objects having exactly 2 FrontDoor |
ExactCardinality( 2 hasPart RearDoor ) (Ax15) | Class of objects having exactly 2 RearDoor |
ExactCardinality( 1 hasPart TrunkDoor ) (Ax16) | Class of objects having exactly 1 TrunkDoor |
Ax13: this restriction allows expressing for example that a car has atmost 5 doors Ax14 Ax15 Ax16: these restrictions allow expressing for example that a five-door car has exactly three doors, two front doors, two rear doors, plus one trunk
DataMinCardinality := 'MinCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'
DataMaxCardinality := 'MaxCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'
DataExactCardinality := 'ExactCardinality' '(' nonNegativeInteger DataExactCardinality [ ClassExpression ] ')'
Examples.
MaxCardinality( 1 hasSSN ) (Ax17) | Each object can have at most one Social Security Number |
Theoretical Perspective
As already said above, qualified cardinality restrictions are present in the SROIQ desctiption logic underlying OWL 2 since they were required in various applications e.g.; [Medical Req] [Little Web] and did not pose theoretical or practical problems to be added [SHOIQ]. It was known from a long time that resulting logic is decidable and QCR was already supported by DAML+OIL, the predecessor of OWL 1.
Implementation Perspective QCRs do not pose implementation problem either. It has been successfully implemented both in earlier editor, e.g.; OilED, and reasoner, e.g., FACT++, that already processed ontology with QCRs, before OWL 1 recommendation. Current versions of tools under development for OWL 2, e.g.; Protégé 4, FACT++, PELLET, RACER, KAON2 also deals with QCRs [TOOLS] [OWL API].
Motivating use cases : Use Case #1 Use Case #2, Use Case #3, Use Case #4
New characteristics can be asserted on Object Properties in OWL 2: Reflexivity, Irreflexivity, Asymmetry.
A reflexivity axiom asserts that a given object property is reflexive that is, the property holds for all the individuals, or in mathematical notation, this is:
∀x x R x
ReflexiveObjectProperty := 'ReflexiveProperty' '(' { Annotation } ObjectPropertyExpression ')'
Examples.
ReflexiveProperty( sameBloodGroup ) (Ax18) | Everybody has the same blood group as themselves. |
ReflexiveProperty( part_of ) (Ax19) | Everything is part_of itself |
Note: there are different interpretations of the mereological relations. For example OBO (Use Case #5) states that part_of is reflexive ∀ p p part_of p, while Use Case #1 states that the merological relation anatomicalPartOf between anatomical entities is irreflexive.
An irreflexivity axiom asserts that a given property is irreflexive, that is the property does not hold for any individual, or in mathematical notation, this is:
∀x ¬ (x R x)
IrreflexiveObjectProperty := 'IrreflexiveProperty' '(' { Annotation } ObjectPropertyExpression ')'
Example
IrreflexiveProperty( proper_part_of ) (Ax20) | Nothing can be proper_part of itself. |
IrreflexiveProperty( connectedTo ) (Ax21) | Nothing can be connected to itself. |
IrreflexiveProperty( boundedBy ) (Ax22) | Nothing can be bounded by itself. |
IrreflexiveProperty( flowsInto )(Ax23) | Nothing can flow into itself. |
Note:
Ax20 Ax21 Ax22: this corresponds to the definition of the mereological or topological properties anatomicalPartOf connectedTo boundedBy in Use Case #1. Other applications may use these terms with other acceptions e.g.; in chemistry moelecules may be self-connected.
Ax23: flowsInto is irreflexive as no river can flow into the same river
An irreflexivity axiom asserts that a given object property is irreflexive that is, if the property holds between individuals x and y, then it cannot hold between y and x, or in mathematical notation, this is:
AsymmetricObjectProperty := 'AsymmetricProperty' '(' { Annotation } ObjectPropertyExpression ')'
Examples
AsymmetricProperty( proper_part_of )(Ax24) | The property proper_part_of is asymmetric. |
Ax24: if p is a proper part of q then q cannot be a proper part of p
Theoretical Perspective
see F4 Theoretical Perspective above
Implementation Perspective
Motivating use cases : Use Case #1 Use Case #2, Use
Case #3, Use Case #5 Use Case #6 Use Case #7
OWL 2 provides the new construct DisjointPropertiesfor asserting that several properties are incompatible(exclusive).
A disjoint properties axiom takes a set of object properties and states that all properties from the set are pair-wise disjoint; that is, no pair of individuals can at the same time be connected by two different properties of the set.
DisjointObjectProperties := 'DisjointProperties' '(' { Annotation } ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
Examples
DisjointProperties( connectedTo contiguousTo ) (Ax25) | connectedTo is disjoint with contiguousTo |
Ax25: Properties connectedTo and contiguousTo of Use Case #1 are exclusive, that is do not hold at the same time. According to the definition of these properties ([2]), when two anatomical entities are linked via an actual third anatomical entity, they are stated to be connected. On the opposite, when they are not related by an actual entity but are adjacent via a conventional entity, they are said to be contiguous. Consequently, two parts cannot be both connected and contiguous.
Theoretical Perspective
see F4 Theoretical Perspective above
Implementation Perspective
Motivating use cases: Use Case #1 Use Case #2 Use Case #3
OWL 2 allows to chain several object properties by means of the new construct PropertyChain.
A propertyExpressionChain expression defines a chain between several object properties by means of PropertyChain.
propertyExpressionChain :=
'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
When used together with SubPropertyOf, an expression defined by PropertyChain provides a means to represent some types of rules. It allows in particular to express the propagation of one property along another property, e.g.; the propagation of a property from parts to whole, which is a very common requirement, specially in Life Sciences.
In short, an axiom SubPropertyOf( PropertyChain( p1 ... pn ) p )states that if an individual x is connected with an individual y by a chain of object properties p1, ..., pn, then x is also connected with y by the object property p. Such axioms are also known as complex role inclusions [SROIQ]. The full exact syntax of Property chain inclusion axioms is more precisely the following:
propertyExpressionChain :=
'PropertyChain' '(' ObjectPropertyExpression ObjectPropertyExpression { ObjectPropertyExpression } ')'
subObjectPropertyExpression :=
ObjectPropertyExpression |
propertyExpressionChain
SubObjectPropertyOf :=
'SubPropertyOf' '(' { Annotation }
SubObjectPropertyExpression
ObjectPropertyExpression ')'
Examples
SubPropertyOf( PropertyChain( locatedIn partOf ) locatedIn ) | If x is locatedIn y, and y is partOf z, then x is locatedIn z; for example a disease located in a part is located in the whole. |
Theoretical Perspective
OWL 2 is based on SROIQ which offers complex role inclusion axioms that include axioms of the form R ◦ S < R or S ◦ R < R to express propagation of one property along another one, which have proven to be very useful in particular for biomedical ontologies(see R8: Property chain inclusion). SROIQ allows also complex axioms of the form S1◦ S2 ◦ ,..., ◦ Sn < R under a certain condition of Regularity that prevents a role hierarchy from containing cyclic dependencies.
An OWL 2 PropertyChain expression used within a SubPropertyOf axiom provides a means to represent some types of rules while remaining decidable under special restrictions that is, provided that the Global Restrictions on Axioms listed Section 10 of the Syntax document are respected by the properties defined in the ontology.
Implementation Perspective
Current versions of tools under development for OWL 2, e.g.; Protégé 4, FACT++, PELLET, RACER, deals with all the features above [TOOLS] [OWL API].
Note(Christine): Not sure it's rigorously exact for all, to be checked and precised by implementors
Motivating use cases: Use Case #1 Use Case #5 Use Case #7
Theoretical Perspective
Implementation Perspective
Motivating use cases:
OWL allows the definition of new datatypes by specifying restrictions on XML Schema datatypes by means of facets that restrain the range of values allowed for a given unary datataype. Facets used in in a DatatypeRestriction can be one of length, minLength, maxLength, pattern, minInclusive, minExclusive, maxInclusive, maxExclusive, totalDigits, and fractionDigits.
Examples
DatatypeRestriction(xsd:integer minInclusive 18) | new datatype with a lower bound of 18 on the XML Schema datatype xsd:integer. |
At hospital, patients under 18 (child) depend on pediatric services while over 18 (adult) depend on adult services
Motivating use cases: Use Case #9 Use Case #11 Use Case #12 Use Case #18 Use Case #19
Theoretical Perspective
Implementation Perspective
Motivating use cases:
OWL 2 extends the unary datatypes of OWL 1 to n-ary datatypes, thus allowing to compare values of data properties for a given object, for example the admisssion temperature of a patient to his current temperature. It allows more generally to use n-ary datatypes such as those built from linear expressions.
facet :=
'length' | 'minLength' | 'maxLength' | 'pattern'
|
'minInclusive' | 'minExclusive' | 'maxInclusive'
| 'maxExclusive' |
'totalDigits' | 'fractionDigits'
restrictionValue :=
Constant
DatatypeRestriction :=
'DatatypeRestriction' '(' Datatype
facet restrictionValue { facet restrictionValue } ')'
Examples
AllValuesFrom( admissionTemperature currentTemperature inferior) | all individuals whose admissionTemperature is inferior to currentTemperature. |
AllValuesFrom( admissionbodyWeight + 2 currentbodyWeight inferior) | all individuals whose currentbodyWeight is more than 2 above admissionbodyWeight. |
A patient is admitted with chest pain. Next day: if the patient's current body weight is more that two pounds above the admission body weight you look for congestive cardiac failure and give diuretics
Theoretical Perspective
N-ary can be used to compare values of data properties for a single given object e.g., in any patient, the systolic blood pressure is always greater or equal than the diastolic blood pressure. They cannot be used to compare values of data properties for different objects (e.g., defining the class of individuals whose body weight is superior than their mother's) which leads to undecidability.
Implementation Perspective
Motivating use cases: Use Case #11 Use Case #12
Theoretical Perspective
Implementation Perspective
Motivating use cases:
OWL 2 provides for annotations on ontologies, entities, including anonymous individuals, and axioms. Below an extract of the syntax used for axioms:
subClassExpression :=
classExpression
superClassExpression :=
classExpression
SubClassOf := 'SubClassOf'
'(' { Annotation } subClassExpression superClassExpression ')'
Annotation := AnnotationByConstant | AnnotationByEntity | AnnotationByAnonymousIndividual
For detailed syntax refer to Section 9 Annotations of the Syntax document.
Theoretical Perspective
Implementation Perspective
Motivating use cases:
Theoretical Perspective
Implementation Perspective
Motivating use cases:
OWL 2 defines several profiles, sublanguages with useful computational properties and implementation possibilities. These profiles are described in details in the Profile document.
OWL-EL++
OWL-DB
ObjectMinCardinality, ObjectExactCardinality), disjunction
(ObjectUnionOf, DisjointUnion) etc.
cf. the Profile document for an exhaustive list
missing features
OWL-R
[CG: References to be added about Theory]
Theoretical Perspective
[CG: References to be added about Implem]
Implementation Perspective
Motivating use cases: Use Case #2 Use Case #3 Use Case #4 Use Case #8 Use Case #16
Theoretical Perspective
Implementation Perspective
Motivating use cases:
UNDER PROGRESS: TO BE COMPLEMENTED.
Domain Specific Requirement | Corresponding Generic Requirement | Relevant OWL 1.1 Construct | OWL 1.0 Implementation | OWL 1.0 Gap | OWL 2.0 Implementation | OWL 2.0 Gap | Comments |
---|---|---|---|---|---|---|---|
Domain = Healthcare | |||||||
Each Finger is part of some Upper Limb | Each town is part of some country | SubProperty Chain | Finger < FingerS < HandP < HandS < UpperLimbP < (partOf some UpperLimb) | Cannot Model propagation of values across properties | hasLocation o properPartOf < hasLocation | None | Results in a more compact and intuitive representation |
A hemisphere is an anatomical entity whose direct parts are lobes, each part being of a distinct type (i.e. frontal lobe, etc. | A binary relationship associates exactly 2 classes | Qualified Cardinality Restriction | Complex implementation involving macro substitution | Cannot model Qualified Cardinality Restriction | Hemisphere = AnatomicalEntity and (hasDirectAnatomicalPart only Lobe) and (= 1 hasDirectAnatomicalPart FrontLobe) ... | None | Makes the ontology compact and intuitive |
A brain hemisphere is either a left brain hemisphere or right hemisphere but not both | a brain hemisphere is either a left brain hemisphere or right hemisphere but not both | Disjoint Union | Hemisphere = LeftHemisphere or RightHemisphere, LeftHemisphere disjointWith RightHemisphere | Verbose OWL specifications | Hemishpere = disjointUnion(LeftHemisphere, RightHemisphere) | None | More compact representation |
Two material anatomical entities in the brain are connected to
each other if they share a |
Two towns are connected to each other if they share a |
Not Supported? | Not Supported? | Cannot Model dependencies between properties | None | Cannot model dependencies between properties | Out of Scope for consideration |
Tom (a patient) doesn't have diabetes | Sarkozy is not the President of USA | Negative Property Assertion | Individual(Tom type(Restriction(hasDisease allValuesFrom (complementOf(oneOf(Diabetes)))))) | Verbose OWL specification | NegativeObjectPropertyAssertion(Tom hasDisease diabetes) | None | More compact and intuitive representation |
Tom (a patient) infects himself | An author cites himself or herself in a publication | local Reflexivity Restrictions | Not supported | Not supported in OWL | ObjectExistsSelf(infectedBy) | None | Increased expressivity |
The property anatomicalPartOf is irreflexive as an |
The property partOf in general is an irreflexive property | Irreflexive Object Property | Not supported | Not supported in OWL | |
None | Increased expressivity |
The property anatomicalPartOf is asymmetric as something cannot be a part of and contain as part the same anatomical region | The property partOf in general is an asymmetric property | Asymmetric Object Property | Not supported | Not supported in OWL | AsymmetricObjectProperty(anatomicalPartOf) | None | Increased expressivity |
" " | |||||||
Domain = Life Sciences | |||||||
1" Amine Group bonds with exactly 2 Hydrogen Atoms | A binary relationship associates exactly 2 classes | Qualified Cardinality Restriction | Complex implementation involving macro substitution | Cannot model Qualified Cardinality Restriction | AmineGroup < (= 2 hasBondWith HydrogenAtom) | None | Makes the ontology compact and intuitive |
A cell is either a nucleated cell or a non-nucleated cell but not both. | A cell is either a nucleated cell or a non-nucleated cell but
|
Disjoint Union | Cell = NucleatedCell or NonNucleatedCell, NucleatedCell disjointWith NonNucleatedCell | Verbose OWL |
Hemishpere = disjointUnion(LeftHemisphere, RightHemisphere) | None | More compact representation |
A bacterial cell can subdivide itself | An author cites himself or herself in a |
local Reflexivity Restrictions | Not supported | Not supported in |
ObjectExistsSelf(dividedBy), ObjectExistsSelf(citedBy) | None | Increased expressivity |
Every cell region has the same regional boundary as itself | The property sameBoundary is reflexive | Reflexive object property | Not supported | Not supported in OWL | ReflexiveObjectiveProperty(sameBoundary) | None | Increased expressivity |
A cell region which |
Connected regions are not contiguous to |
Disjoint Object Property | Not supported | Not supported in |
DisjointObjectProperty(contiguousTo connectedTo) | None | Increased expressivity |
High systolic blood pressure is defined as having values >= 140 mmHg | Hot days are those when the temperature > 100F | Datatype Restriction | Has been implemented in an adhoc manner using |
Not supported natively in OWL | HighSystolicBP = DataSomeValuesFrom(bpReading minInclusive 140) | None | Incorporation of XML Schema datatypes into OWL |
" " | |||||||
Domain = Clinical Trials | |||||||
In a clinical trial, the |
A student should enroll in a particular course within 6 months
of |
N-ary Datatypes | Not supported | Not supported in OWL | DataAllValuesFrom(MRIdate, enrollmentDate+60days, lessThan) | None | Incorporation of Binary constraints into OWL |
" " | |||||||
Domain = Telecommunications | |||||||
" " | |||||||
Domain = Manufacturing | |||||||
" " | |||||||
Domain = Earth and |
|||||||
All material on the Earth is in |
All material on the Earth is in |
Disjoint Union | State = Solid or Liquid or Gas, Solid disjointWith Liquid, Liquid disjointWith Gas, Solid disjointWith Gas | Verbose OWL specifications | State = disjointUnion (Solid, Liquid, Gas) | None | More compact representation |
flowsInto is an irreflexive property as one river cannot flow into another | flowsInto is an irreflexive property | Irreflexive Object Property | Not supported | Not supported in OWL | IrreflexiveObjectProperty(flowsInto) | None | Improved expressivity |
Use Case | Disjoint Union | Disjoint Classes | Negative Property Assertion | Local reflexivity | Qualified Cardinality | Reflexive, Irreflexive, Asymmetric | Disjoint properties | Property chain inclusion | Keys | Datatype restriction | N-ary datatype (?) | Simple metamodeling capabilities | Extended annotations | Declarations | Profiles | Anonymous Individual | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
UC#1 | X | X | - | - | X | - | X | X | - | - | - | - | - | - | - | - | UC#2 |
UC#3 | |||||||||||||||||
UC#4 | |||||||||||||||||
UC#5 | |||||||||||||||||
UC#6 | |||||||||||||||||
UC#7 | |||||||||||||||||
UC#8 | |||||||||||||||||
UC#9 | |||||||||||||||||
UC#10 | |||||||||||||||||
UC#11 | |||||||||||||||||
UC#12 | |||||||||||||||||
UC#13 | |||||||||||||||||
UC#14 | |||||||||||||||||
UC#15 | |||||||||||||||||
UC#16 | |||||||||||||||||
UC#17 |
This table provides the relations between Use Cases Requirements Features described in the sections above. Each use case may points to several features required. The requirement/feature higlighted and displayed in bold, is illustrated by an example issued from the associated reference displayed in bold. (This is not to say that the other requirements abbreviated in the line are less important). Each line is tagged by a domain/user profile.
This table can be ordered according to Domain/User or Feature, depending on the preference of "Who reads it".
[TBD:[TBD : Who knows how to make automatic order lines on the Wiki / wants to make it? ]
Use Cases | Requirement/Feature | Domain/Users | Examples | References |
---|---|---|---|---|
UC#1 | DisjointUnion R2 R5 R7 R8 R11 |
HCLS |
DisjointUnion(Lobe FrontalLobe ParietalLobe
TemporalLobe OccipitalLobe LimbicLobe)
Lobe is a disjoint union of FrontalLobe FrontalLobe ParietalLobe TemporalLobe OccipitalLobe LimbicLobe |
[MEDICAL REQ] |
UC#3 | DisjointUnion R2 R5 |
HCLS |
DisjointUnion(Cell NucleatedCell
NonNucleatedCell)
Cell is a disjoint union of NucleatedCell and NonNucleatedCell. |
[Chemistry] |
UC#2 | DisjointClasses R1 R2 R5 R7 R9 |
HCLS |
DisjointClasses( LeftLung RightLung
)
a Lung cannot be LeftLung and RightLung |
[FMA] |
UC#4 | R1 R5 | Automotive | ex4 | ref4 |
UC#5 | R6 R8 | HCLS | ex5 | ref5 |
UC#6 | R4 R5 R6 | Earth&Space | ex | ref |
UC#7 | R8 R9 | HCLS | ex | ref |
UC#8 | R5 R6 58 | HCLS | ex | ref |
UC#9 | Negative Property R10 |
HCLS | NegativePropertyAssertion( hasAge
ThisPatient 5^^xsd:integer ) This patient is not five years old. |
[Transplant Ontology] |
UC#10 | R10 | HCLS | ex | ref |
UC#11 | R10 | HCLS | ex | ref |
UC#12 | R10 R12 R13 | Tool | ex | ref |
UC#13 | R12 | Telecom | ex | ref |
UC#14 | R12 | Designer | ex | ref |
UC#15 | R12 | Designer | ex | ref |
UC#16 | R15 | Designer | ex | ref |
UC#17 | R14 | Tool | ex | ref |
Legend
R1/F1 | R2/F2 | R3/F3 | R4/F4 | R5/F5 | R6/F6 | R7/F7 | R8/F8 | R9/F9 | R10/F10 | R11/F11 | R12/F12 | R13/F13 | R14/F14 | R15/F15 | R16/F16 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Disjoint Union | Disjoint Classes | Negative Property Assertion | Local reflexivity | Qualified Cardinality | Reflexive, Irreflexive, Asymmetric | Disjoint properties | Property chain inclusion | Keys | Datatype restriction | N-ary datatype (?) | Simple metamodeling capabilities | Extended annotations | Declarations | Profiles | Anonymous Individual |
Theory references for punning to be added
Retrieved from "http://www.w3.org/2007/OWL/wiki/Punning"
Theory references for N-ary to be added