OWL 2 Web Ontology Language:
Requirements
W3C Editor's Draft 22 July 2008
- This version:
- http://www.w3.org/2007/OWL/draft/ED-owl2-requirements-20080722/
- Latest editor's draft:
- http://www.w3.org/2007/OWL/draft/owl2-requirements/
- Previous version:
- http://www.w3.org/2007/OWL/draft/ED-owl2-requirements-20080721/ (color-coded diff)
- Authors:
- Evan K.
Wallace, NIST
- Christine
Golbreich, University of Versailles Saint-Quentin
- Vipul
Kashyap, Partners Health System, Inc.
- Michel Dumontier, Carleton
University
- Contributors:
- Deborah
McGuinness, Rensselaer Polytechnic Institute
- Bijan
Parsia, The University of Manchester
Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
OWL 2 extends the W3C OWL Web Ontology Language
with a small but useful set of features that have been requested by
users, for which effective reasoning algorithms are now available,
and that OWL tool developers are willing to support. The new
features include extra syntactic sugar, additional property and
qualified cardinality constructors, extended datatype support,
simple metamodelling, and extended annotations.
This document describes some of the motivating use cases and
corresponding requirements that led to the changes to OWL seen in
OWL2. These use cases and requirements are based on both user and
tool developer experience much of which was documented and
discussed as part of the
OWLED
Workshop Series.
May Be Superseded
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/.
Please Comment By 2008-07-29
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.
No Endorsement
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.
Patents
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 an editors' draft in progress.
It represents input of a number 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 is going and engender
feedback as to how it should mature.
1 Overview
This document describes use cases and requirements that motivate
further development to the Web Ontology Language evident in OWL 2.
The use cases stem from a variety of domains that have been
exploring the use of OWL for knowledge management as well as from
implementers of OWL tools and services. What is captured here is
not an exhaustive list of capabilities for OWL requested by these
groups, but rather the motivations for those features that had
common support and could be added to the language while staying
within other design goals such as decidability, scalability,
implementability. Rationale for selections is provided so as to
provide the reader insight into the presence, absence or restricted
use of desirable features.
The first section of the document (Use Cases) lists use cases
collected from the OWLED series and other literature that
characterize some of the most important and common motivations
behind the development of OWL 2. The second section (Requirements)
summarizes the main requirements that have been requested by users
and implementors. The third section (Features & Rationale)
points to the main new features that have been added to OWL 2 and
their rationale. It provides simple illustrating examples, links to
the Use Cases that motivated these extensions, and to the syntax
defined in the other documents.
2 Use Cases Motivated by Domains and
Applications
In this section, we discuss a collection of use cases across
multiple domains such as health care delivery, life sciences,
clinical research and trials, manufacturing, earth and space
sciences, and telecommunications. For each domain, we discuss the
applications and stakeholders involved. This helps motivate the
requirements and the features of the OWL 2.0 lanuage as discussed
in later sections.
2.1 Domain: Health care
Knowledge management in health care aims to support physicians,
nurses and other clinical staff to provide high quality clinical
care to patients in various settings such as in-patient,
out-patient and emergency settings. Key applications and
functionalities supported in clinical information systems along
with various users and stakeholders are as follows.
2.1.1 Applications
The key applications that form the core components of a health
are delivery infrastructure are discussed next. For each
application we identify motivate needs and requirements for
information and knowledge representation languages.
2.1.1.1 Electronic Medical Record
(EMR)
The EMR is the core component of any health care IT
infrastructure that seeks to represent clinical information about a
patient. EMRs pose significant challenges in terms of (A) common
and consistent reporting of clinical observations and treatments
and (B) standardization and interoperability to enable sharing of
clinical data across applications and institutional boundaries that
enable decision support and clinical quality reporting. There is a
need for representation of clinical descriptors that capture
various types of information in an EMR such as clinical
observations, conditions, lab tests, medications and treatments. A
formal representation of these clinical descriptors present a
requirement languages for information and knowledge modeling that
are precise, unambiguous and computationally tractable.
2.1.1.2 Enterprise Terminology
Services
The need for standardization and consistent representation of
clinical descriptors in an EMR is a key requirement for using and
composing concepts from controlled medical terminologies such as
Snomed-CT, LOINC, RxNorm and others. In order to achieve
interoperability, the healthcare IT industry has attempted to use
these terminologies to represent a wide variety of clinical
descriptors. Over and above interoperabiliyt, this also enables
consistent use of clinical descriptors to trigger clinical decision
support and to represent clinical quality metrics. However, there
has been wide variability, as different systems have used concepts
from different terminologies with different granularities combined
in multiple ways to reresent the same clinical data. There is a
need for knowledge representation languages that provide the
ability to specify a rich set of relationships between concepts,
the ability to create new concepts based on the composition of
pre-existing concepts and the ability to infer equivalence of the
same concept representd in multiple ways.
2.1.1.3 Clinical Decision Support
(CDS)
CDS tools have been widely used by healthcare organizations to
provide support to the physician at the point of care. CDS logic is
typically represented using some form of decision rules, which
typically consist of clinical descriptors as a part of the
antecedent, and recommended actions such as ordering a lab test,
recommending a treatment or inference of a particular clinical
condition, such as fracture in some location of the body. These
rules typically levarage concepts and possible compositions of
concepts from a terminology, e.g., Snomed-CT or Foundation Model of
Anatomy to specify the logic in a decision rule. There is a need
for a knowledge representation language to represent logic in a
precise, standardized and computable formalism.
2.1.1.4 Clinical Quality
Metrics
Managers and administrators at healthcare organizations are
interested in monitoring the quality of care provided at their
institutions. For this purpose all clinical transactions are stored
in a centralized data warehouse or repository and analyzed for the
occurrence of various clinical descriptors such as the number of
times a particular test was ordered, the number of patients who
have their LDL values in the normal range etc. They crucial
challenge is similar to the one discussed above, in that, there is
a need for consistent definition of these metrics and retrievel of
clinical transactions in a uniform and consistent manner for
further analysis. There is a need for knowledge representation
languages that can represent these clinical descriptors on one
hand, and map them to underlying clinical data on the other.
2.1.1.5 Clinical
Documentation
Typically physicians dictate their impressions of a patient
encounter into a recording machine which gets transcribed into
unstructured textual notes by means of speech processing software.
An alternative approach provides for development of templates and
tools to document a patient's clinical condition in a structured
manner using rich and expressive clinical descriptors. This
enhances the ability to share clinical data across applications,
enable automatic decision support and measurement and evaluation of
clinical quality metrics.
2.1.2 Users and Stakeholders
2.1.2.1 Clinical/Biomedical
Informatician
(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?
2.1.2.2 Information
Modeler/Architect
(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.
2.1.2.3 Subject Matter Expert
(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:
- Internal Medicine: An internist would be interested in
knowing the symptoms, diagnostic tests and diagnoses for a patient
in a clinical setting. He or she would also like to refer a patient
to a specialist, e.g., neurologist, and the ability to represent
clinical descriptors that describe referral criteria.
- Neurology: Neurologists work with internists for
management of neurological diseases and are interested in
performing and knowing the differential diagnosis of a patient,
diagnostic and other interventions given to a patient, the
prognosis for a patient; and the cost/benefit for a particular
intervention given to a paitent
2.1.3 Use Cases
2.1.3.1 Use Case (New) - Problem Oriented
Medical Record (POMR) Ontology
There have been multiple attempts to design a formal description
of the medical record of a patient. There have been attempts to
define information models such as the HL7 RIM, Archetypes, medical
terminologies such as Snomed and ontologies such as Galen. The
fundamental motivation for the design and philosophy of the
Problem-Oriented Medical Record (POMR) is the belief that the
medical record is the central medium of communication and the first
repository of knowledge in the practice of clinical medicine. The
traditional structure / organization of the POMR is: Screening Data
(collected in order to discover problems, problem list, initial
plans (organized by problem) and progress notes (outcomes and
follow-up). There have been attempts to use OWL to represent the
medical record.
- A
Problem Oriented Medical Record Ontology proposes an OWL-based
specification in an intial attempt to create a formal specification
of the POMR. In doing so, it leverages ontologies such as Galen and
the HL7/RIM. This has been developed using Notation 3 Rules and
OWL.
-
An OWL representation of HL7/RIM is an initial OWL-based
representation of HL7/RIM
-
RDF/OWL Representation of HL7/RIM v3.0 is an ongoing task with
the Clinical Observations Interoperability Task Force (part of the
W3C Interest Group on the Healthcare and Life Sciences) which seeks
to represent the HL7/RIM in OWL.
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?
2.1.3.2 Use Case (New) - Specifying
decision logic in CDS Rules
(From: H. Goldberg, V. Kashyap and K. Spackman, Creation and
Usage of a "Micro Theory" for Long Bone Fractures: An Experience
Report, Proceedings of KR-MED 2008)
Typically, a physician creates a clinical descriptor that is of
sufficient granularity to support a management plan—the clinical
descriptor is an index for the general management plan for a given
pathology. Within the contemporary electronic health record, the
clinical descriptor may be reused as data to drive point-of-care
decision support, or as warehouse data to support reporting. For
instance, if we need to report the number of patients who had a
fracture of the proximal femur, we should also include the number
of patients who had a fracture of the femoral neck. In both cases,
the original descriptor should support detailed classification
schemes. With respect to bone fractures, it is desirable to
describe fractures in detail with respect to the bone features
involved—the clinical detail drives the management plan. The
clinical detail may describe either a fracture involving an
anatomic landmark or a functional region where all fractures act
similarly. It is equally important that the clinical descriptor not
admit any nonsensical description. While fractures may involve bony
landmarks, we generally do not describe fractures of the periosteum
— the bone lining—or the bone marrow. While these are parts of
bones, they are not generally parts through which fractures are
described to occur. The GALEN project used constraints called
sanctions to specify the values that could sensibly be applied to
relations such as has-location. Our ontology fragment should
logically defining the set of all and only locations for fractures.
Given a need to document, to classify, and possibly to obtain
reference information, useful questions that might be posed
include:
- What bone regions and features are contained in the Distal
Epiphysis of the Femur?
- What parts of the Distal Epiphysis of the Humerus are covered
by Articular Cartilage?
- Is a fracture of the Femoral Neck also a fracture of the
Proximal Femur (i.e., is a fracture through an anatomic feature a
fracture of a functional region)?
- Is a fracture of the Trochlea a fracture of the Distal
Epiphysis of the Humerus?
- Is a fracture of the Trochlea an intra-articular fracture?
- Is a fracture of the Trochlea an intra-articular fracture of
the Distal Epiphysis of the Humerus?
The above questions create requirement for:
- Propagation of location of a fracture over regional parts;
and
- Transitive transfer for location of a fracture.
These requirements are related to the OWL 2.0 features of:
- representation and reasoning over role chains and
- representation and reasoning over transitive
relationships.
2.1.3.3 Use Case #1 - Brain image
annotation for neurosurgery
The application concerns the preparation of surgical procedures
in neurosurgery. Specifically, the aim is to assist the user in
labelling the cortical gyri and sulci in the region surrounding the
lesion, whose resection is the primary objective. Providing
anatomical landmarks, especially in eloquent cortex, is highly
important for surgery. Besides brain images annotation is useful in
terms of documentation of the clinical cases, and with respect to
the ability of retrieving similar cases for decision support in
future procedures. A shared ontology of brain anatomy is also
needed to integrate multiple distributed image sources indexed by
anatomical features. It is useful for large-scale federated systems
for statistical analysis of brain images of major brain
pathologies.
[MEDICAL REQ]
[Ontology with
rules] [Brain
Imaging ]
Requires: Disjoint Union, Disjoint Classes, Qualified
Cardinality Restrictions, Disjoint Properties, Property chain
inclusion axioms, [N-ary predicate, rules]
Question (Christine): should we mention delayed requirements such as those within brackets ?
2.1.3.4 Use Case #7 - The Systematized
Nomenclature of Medicine (SNOMED CT)
The Systematized Nomenclature of Medicine, Clinical Terms
(SNOMED CT) is a work of clinical terminology with broad coverage
of the domain of health care, and it has been selected as a
national standard for use in electronic health applications in many
countries, including the U.S., U.K., Canada, Australia, Denmark,
and others. SNOMED was originally published in 1976, while SNOMED
CT became available in 2002 as a major expansion resulting from the
merger of SNOMED RT with the U.K.'s Clinical Terms version 3. A
major distinguishing feature differentiating it from prior editions
is the use of description logic (DL) to define and organize codes
and terms. Another major distinguishing feature of SNOMED is its
size and complexity. With over 350,000 concept codes, each
representing a different class, it is an order of magnitude larger
than the next largest DL-based ontology of which we are aware. The
size of the OWL XML/RDF form of SNOMED is approximately 248 MB, and
this is just the DL representation without all the synonyms,
mappings, subsets, and other special-purpose components of the
terminology. Without property chain inclusion axioms, adoption of
OWL by the SNOMED community would have required awkward workarounds
with their attendant complications and complexities - effectively
killing movement in that direction. With [them], we have a clear
path to using OWL 2 for further development and integration with
other biomedical ontologies. Like the FMA given the common use of
SNOMED cross-references, keys would be highly useful.
Note (Micheldumontier). Please elaborate on the requirement for property chain inclusions - give example, and describe the workaround.
[SNOMED REQ]
Requires: Property chain inclusion axioms,
Keys
2.1.3.5 Use Case # 9- Kidney Allocation
Policy in France
Allocation in France falls under the responsibility of the
Agence de la biomedicine. It includes general rules such as:
donor-recipient ABO blood group identity, unique registration on
the national waiting list and definition of some organ specific
nation-wide allocation priorities. For each kidney recipient,
minimal HLA matching and forbidden antigens can be specified.
Pediatric recipients get a priority for pediatric donors. Kidneys
are proposed by order of priority to (1) urgent patients, (2)
patients with panel reactive antibodies level ≥ 80% included in a
specific acceptable antigen protocol or ≤1 HLA mismatch with the
donor, then (3) zero mismatch patients, and (4) patients with low
transplantation accessibility. This real-life application and
allocation system show how distinguishing between adults and
children has strong implications in health care: at hospital,
patients under 18 (child) depend on pediatric services while over
18 (adult) depend on adult services; only children less than 16
years waiting for a transplant have a priority on the waiting
list.
[Agence
Biomedecine] [Transplant Ontology]
Requires: Negative Property Assertion, Datatypes
extension
2.2 Domain: Life Sciences
2.2.1 Applications
2.2.2 Users and Stakeholders
2.2.2.1 Scientific Database
Leadership
(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.
2.2.2.2 Subject Matter Expert
(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:
- Systems Neurophysiology: Systems neurophysiologists try
to learn more about the normal functioning of brain circuits and
their malfunction in Parkinsons Disease. They try to represent
knowledge and query information related to wiring diagrams in brain
systems, chemicals/neurotransmitters used by neurons for
communications, proteins that recognize these chemicals and the
reponses elicited, properties of neurons in a particular part of
the brain. In particular, there is a great emphasis on partonomic
and spatial knowledge and it would be of interest to these users to
understand what aspects of OWL 2 support representation of these
types of knowledge.
- Cellular and Molecular Neurobiology: Cellular and
molecular neurobiologists try to represent knowledge and query
information relted to proteints implicated in a neurological
disease, e.g., Parkinsons, impact of the disease on protein
expressions, protein folding, protein regulations and other
interactions; cell signaling pathways and the proteins implicated
in a disease and different types of biomarkers for a disease.
2.2.3 Use Cases
2.2.3.1 Use Case #2 – The Foundational
Model of Anatomy
The Foundational Model of Anatomy (FMA) is the most
comprehensive ontology of human ‘canonical’ anatomy. Anatomy plays
a prominent role in biomedicine and many biomedical ontologies and
applications refer to anatomical entities. FMA is a tremendous
resource in bioinformatics that facilitates sharing of information
among applications that use anatomy knowledge. As its authors
claim, the FMA is “a reference ontology in biomedical informatics
for correlating different views of anatomy, aligning existing and
emerging ontologies in bioinformatics...” . Anatomy, together with
Gene and Disease reference ontologies constitute the backbone of
the future Semantic Web for Life Sciences. The FMA should benefit
to state that some properties are exclusive (e.g.; proper-part and
bounded-by). Since many biomedical ontologies and applications
refer to the FMA anatomical entities through cross-references, keys
would be highly useful.
Note (Micheldumontier). First, anatomy is more about the health sciences, than the life sciences. Second - please expand on the notion of "exclusive" properties, and what value they might have - illustrate with a clear example. Third, it is wholly unclear how "keys" would be useful in the identified context - please provide sufficient detail.
[FMA]
Requires: Disjoint Union, Disjoint Classes, Qualified
Cardinality Restrictions, Disjoint Properties, Keys
2.2.3.2 Use Case #3 - Classification of
chemical compounds
Functional groups describe the semantics of chemical reactivity
in terms of atoms and their connectivity, which exhibit
characteristic chemical behavior when present in a compound. In
this use case the authors take a first step towards designing an
OWL-DL ontology of functional groups for the classification of
chemical compounds, highlight the capabilities and limitations of
OWL 1.0 and the proposed OWL 1.1 in terms of domain requirements.
They also describe the application of expressive features in the
design of an ontology of basic relations and how, an upper level
ontology, can be used to guide the formulation of life science
knowledge. They report on experiences to enhance existing
ontologies so as to facilitate knowledge representation and
question answering.
[Chemistry]
Requires: Disjoint Union, Disjoint Classes, Qualified
Cardinality
2.2.3.3 Use Case #5 - OBO ontologies for
biomedical data integration
The Open Biomedical Ontologies (OBO) consortium is pursuing a
strategy to facilitate the integration of biomedical data through
their annotation using common controlled ontologies. Existing OBO
ontologies, including the Gene Ontology, are undergoing coordinated
reform, and new ontologies are being created on the basis of an
evolving set of shared principles governing ontology development.
The result is an expanding family of OBO ontologies designed to be
interoperable and to incorporate accurate representations of
biological reality. Within that effort the OBO ontology of
relations is designed to define a set of basic relations with their
semantics. OBO qualifies each relation using characteristics of
being transitive, symmetric, reflexive, anti-symmetric. Property
axioms to express these features are required for accurate
knowledge representation.
[OBO] [RO] [OBO2OWL]
Requires: Reflexive, Irreflexive, Asymmetric, Property
chain inclusion axioms, [Antisymmetric]
2.2.3.4 Use Case #8 - Simple part-whole
relations in OWL Ontologies
Representing part-whole relations is a very common issue for
those developing ontologies for the Semantic Web. OWL does not
provide any built-in primitives for part-whole relations (as it
does for the subclass relation), but contains sufficient expressive
power to capture most, but not all, of the common cases. The study
of part-whole relations is an entire field in itself - "mereology"
- this note is intended only to deal with straightforward cases for
defining classes involving part-whole relations. Several extensions
of whole needed for part-whole are discussed in this study, namely,
needs of qualified cardinality restriction, reflexivity,
propagation from parts to whole
[Part
Whole]
Requires: Qualified cardinality restriction,
Reflexivity, Property chain inclusion axioms
2.3 Domain: Manufacturing
2.3.1 Applications
2.3.2 Users and Stakeholders
2.3.2.1 Manufacturing Technical Standards
Developer
(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.
2.3.2.2 Manufacturing Business Standards
Developer
(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?
2.3.3 Use Cases
2.3.3.1 Use Case #4 - Querying multiple
sources in an automotive company
Large companies often store information and knowledge in
multiple information systems using various models and formats. A
main issue is to retrieve the relevant knowledge for a specific
concern from the different sources. The aim of the application is
to query multiple data and knowledge sources for a large automotive
company faced to this problem.
[Auto]
Requires: Disjoint Union, Qualified
Cardinality
2.4 Domain: Earth and Space
Sciences
Knowledge management in earth and space science information
systems aims to support domain scientists, information and data
specialists, teachers, and lay personnel in providing access to
data concerning the natural world. Not only do applications need to
provide access to data in single discipline areas, they also must
provide access to data concerning multiple disciplines in ways that
are appropriate to a wide range of users. Key applications and
functionalities supported in earth and space science information
systems along with various users and stake holders follow
below.
2.4.1 Applications
2.4.1.1 Virtual Observatory
(VO)
A virtual observatory is a suite of software applications on a
set of computers that allows users to uniformly find, access, and
use resources (data, software, document, and image products and
services using these) from a collection of distributed product
repositories and service providers. A VO is a service that unites
services and / or multiple repositories.
Note {DeborahMcGuinness}. We need to figure out how best to deal with typical and other publications that are the sources for our requirements and/or definitions such as this one above.
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/ ) are 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/ ).
Organizations like the Federation of Earth Science Information
Partners (ESIP - http://www.esipfed.org/ ) are looking
to semantic technologies to support services ranging from
ontology-enhanced search to fairly detail oriented integration of
databases.
2.4.2 Users and Stakeholders
2.4.2.1 Earth and Space Science
Researcher
From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents
A scientist who is interested in using semantic technologies to
perform information ontology-enhanced search over a repository or
set of repositories of scientific information. The subject matter
expert may need to review the science terms in the ontology to
determine adequate coverage, they may need to enhance the ontology
to include terms that are new to the ontology, 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 critical support
for these users is browsing capabilities, targeted search, and
expressive power for representing mapping across terms and for
refining terms.
2.4.2.2 Computational Scientist /
Software Engineer
Much of earth and space science revolves around sophisticated
queries for data (that is largely numerical) but that is generated
by complicated processes. These users need to be able to have
expressive power for representing numerical ranges and scientific
units and mathematical conversion processes. They also benefit from
being able to express reasonably detailed scientific processes such
as those described in the volcano and atmosphere example of the
SESDI project (Semantically-Enabled Scientific Data Integration).
(http://gsa.confex.com/gsa/2007GE/finalprogram/abstract_122252.htm
)
2.4.2.3 Existing Implementation Owner of
Earth and Space Science Application
From http://www.w3.org/2007/OWL/wiki/Who_Reads_Our_Documents
These users already have OWL 1.0 applications deployed and have
significant amounts of programs written that connect to legacy
databases and web services. They need to have migration support
tools including translators and documentation concerning transition
from both the language and the documents.
2.4.3 Use Cases
2.4.3.1 Use Case #18 – Virtual Solar
Terrestrial Observatory
From http://www.ksl.stanford.edu/KSL_Abstracts/KSL-07-01.html
and deployed at http://vsto.org . The Virtual Solar
Terrestrial Observatory is a National Science Foundation and
National 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 number of online repositories of
scientific data. The background OWL ontology contains term
descriptions for science terms including instruments,
observatories, parameters, etc. Users essentially need to specify a
description of the data they wish to retrieve which includes either
a specific instrument class or a description of that class, a date
range for the data taken, and the parameters. In order to specify
that in relevant science terms, scientists need to be able to
represent numerical ranges and comparisons (thus going beyond the
numeric support of OWL 1). The application also needs to expand to
include spatial descriptions. It would use representational power
if provided for spatial/geographic containment.
2.4.3.2 Use Case #19 – Semantic
Provenance Capture
From http://spcdis.hao.ucar.edu/. In
an effort to provide better search capabilities over meta
information in addition to scientific data, the SPCDIS effort is
providing infrastructure to capture declarative descriptions of
scientific provenance information at data ingest time. The initial
domain of the effort is solar coronal physics. This effort requires
(among other things) extended annotations (4.13 R13 in the
requirements document) as well as datatype restriction (4.10
R10).
2.4.3.3 Use Case #6 – Spatial and
topological relationships at the Ordnance Survey
Ordnance Survey is Britain's National Mapping Agency. It
currently maintains a continuously updated database of the
topography of Great Britain. The database includes around 440
million man-made and natural landscape features. These features
include everything from forests, roads and rivers down to
individual houses, garden plots, and even pillar boxes. 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 addresses 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 capture the true intentions of our axioms”.
[Ordnance]
Requires: Reflexive, Irreflexive, Asymmetric,
[Antisymmetric]
2.5 Domain: Clinical Research and
Clinical Trials
This domain consists of information and knowledge related to a
patient's clinical information in the context of his or her
participation in a clinical research study or a clinical trial,
which may be characterized by a set of clinical processes or
protocols.
2.5.1 Applications
Key applications in this domain are clinical trials management,
that keep track of various patient, trial and investigator related
information across multiple clinical trials, detection and
resolution of adverse events,
2.5.1.1 Clinical Trials
Management
This application supports the ability to acquire, store and
manage clinical data of patients participating in a clinical trial.
It also seeks to track the progress of a patient through a clinical
trial based on well defined clinical processes and protocols.
2.5.1.2 Adverse Event Detection and
Resolution
This application tries to detect adverse events and clinical
conditions in response to a particular drug. It monitors the data
for unusal signs of clinical events that can be correlated with
starting the patient on a particular drug. It uses knowledge
created by experts to determine an appropriate response to the
adverse reaction
2.5.1.3 Patient Recruitment
This applicaion seeks to determine a set 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.2 Users and Stakeholders
2.5.2.1 Subject Matter Expert
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 knowledge:
- Clinical Researcher/Clinical Trials Investigator:
Clinical researchers and clinical trial investigators are
responsible for running clinical trials and studies that seek to
evaluate the effects of a drug on a patient cohort. They are
interested in information and knowledge such as the diagnostic
tests and imaging studies associated with a disease, therapeutic
interventions and their impact/efficacy in treating a disease, side
effects, costs and benefits associated with a drug.
- Clinical Guidelines Formulator: Academic researchers and
professional societies synthesize the available evidence regarding
the diagnosis and management of a disease to generate
human-readable clinical guidelines. There are now approaches that
seek to semi-automatically created executable representations of
these guideline. The information and knowledge of interest to this
user aare: the results of clinical trials, cost and benefits of a
drug for a disease, the characteristics of a clinical trial, such
as the type, e.g., double blind randomized clinical trial, the
sample size and power of the trial, the relationships between
recommendations made in the guideline and the results and evidence
strength of the clinical trial.
2.5.3 Use Cases
2.5.3.1 Use Case (New): Interoperation of
Clinical Information across Healthcare and Clinical
Trials
This use case is based on an ongoing W3C task force on
Clinical Observations Interoperability where the goal is to
enable re-use and sharing of clinical data created in healthcare
delivery in the Clinical Trials context. This requires clinical
data represented using a healthcare specific 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 specific data models (e.g., CDISC/SDTM) and clinical
trials specific controlled terminology (e.g., NCI Thesaurus). A set
of mapping expressions expressed as N3 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:
- Representation of equivalences between a source class and a
target class with a restriction on one of the object properties of
the class
- Representation of equivalences between object properties
- Representation of mappings between an object property and a
property chain
- Representation of mappings between classes in an information
model and concepts in a controlled terminology
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 case a mediating ontology, e.g., Drug ontology
may be used to define new classes required to create the relevant
mappings. For e.g., let's assume that the source terminology
contains a medication class called WeightReduction which
doesn't exist either in the mediating ontology or in the target
terminology. This can be achieved by defining an equivalent class
in the Drug Ontology as Drugs that may treat Obesity and
identify mappings from this composite class to concpets in the
target terminology. These examples are illustrated in
http://esw.w3.org/topic/HCLS/ClinicalObservationsInteroperability/DrugMapping.html
and give rise to the following requirements:
- The ability to map a medication class in a source terminology
to many medication instances in a target terminology, via a
mediating ontology
- The ability to map a medication class in a source terminology
to a defined class expression in the mediating ontology, which in
turn is mapped to many medication instances 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 is to enable re-use
and sharing of clinical data created in healthcare delivery in the
Clinical Trials context. In particular the first application chosen
to demonstrate feasibility of the interoperability approach is that
of patient recruitment. In this case, a sample set of clinical
trial protocols available from http://www.clinicaltrials.gov
each of which contains a list of eligibility (inclusion and
exclusion criteria). These eligibility criteria are used for
identify eligible patients and potentially form conditions in a
SPARQL query or could be represented as OWL classes. They also need
to be mapped as per the discussion in the use case above. A list of
requirements based on an analysis of these 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 the clinical trials requires that the
enrollment date of a clinical trial participant be within 30 days
after the patient has been started on a particular therapy. This
motivated the need for N-ary datatypes with inequality
expressions?
Requires: Datatypes extension
2.5.3.3 Use Case #11 – Multiple UCs of
datatype extensions
Many Use 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]
3 Use Cases - Organized by
Requirement
The following list of Use Cases motivating the OWL 2 extensions
is not exhaustive. These UCs correspond to OWL 2 new
features - whatever user/implementor/theoretical reasons - and
that seem, at this time, on the way to be accepted by the WG for
OWL 2. Some features or details are still under discussion. Other
extensions (such as rules, custom datatypes, etc.), possibly needed
in the future, are indicated within brackets.
The general organisation is based along UCs / Requirements /
Features & Rationale. In the Use Cases section below, each Use
Case (Use Case #i) is linked to some (of the most important)
OWL 2 Requirements (Rj) and points to the related papers available
online ([paper]). On the other side, in the following
Requirements section, each requirement is related to the motivating
Use Cases, while in the next section Features & Rationale, each
feature is illustrated by some example(s) issued from the
motivating use cases reported in the Use Cases section. Finally,
two tables summarize the relations between them. The first table
shows the links between Use Cases and Requirements (OWL 2
Features). The second table provides the relations between Use
Cases - Requirements - Features & Rationale illustrated by a
simple example. This table can be ordered byDomain or
Feature, so as to allow the reader to navigate within the
overall document according to his preference.
This is a first suggested draft in progress.
Note (cg). The list of UCs, initially composed of those I knew the best
mainly in the HCLS 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 are welcome,
each UC being entered accompanied by links to some specific
a) Requirements
b) Reference - whatever OWLED or other litterature
c) Feature with short illustrative example(s) hopefully writen in OWL 2 syntax
3.1 Use Case #1 - Brain image annotation
for neurosurgery [HCLS]
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]
3.2 Use Case #2 – The Foundational Model
of Anatomy [HCLS]
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.
[FMA]
Requires: Disjoint Union, Disjoint Classes, Qualified
Cardinality Restrictions, Disjoint Properties, Keys,
Profiles
3.3 Use Case #3 - Classification of
chemical compounds [HCLS]
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 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.
[Chemistry]
Requires: Disjoint Union, Disjoint Classes, Qualified
Cardinality Profiles
3.4 Use Case #4 - Querying multiple
sources in an automotive company [Automotive]
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. For this applications a language
with a 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.
[Auto]
Requires: Disjoint Union, Qualified Cardinality,
Profiles
3.5 Use Case #5 - OBO ontologies for
biomedical data integration [HCLS]
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. More
generally OBO format offers constructs such as 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 axioms reflexive, irreflexive, asymmetric to map
corresponding OBO constructs, otherwise they should be transformed
into annotations.
[OBO]
[RO] [OBO2OWL]
Requires: Reflexive, Irreflexive, Asymmetric, Property
chain inclusion axioms, [Antisymmetric]
3.6 Use Case #6 – Spatial and topological
relationships at the Ordnance Survey [Earth and Space]
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 and natural landscape features. These features
include everything from forests, roads and rivers down to
individual houses, garden plots, and even pillar boxes. 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 addresses 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 capture the true intentions of our axioms”.
[Ordnance]
Requires: Reflexive, Irreflexive, Asymmetric,
[Antisymmetric]
3.7 Use Case #7 - The Systematized
Nomenclature of Medicine (SNOMED CT) [HCLS]
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.
[SNOMED REQ]
Requires: Property chain inclusion axioms,
Keys
3.8 Use Case #8 - Simple part-whole
relations in OWL Ontologies [HCLS]
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
[Part
Whole]
Requires: Qualified cardinality restriction,
Reflexivity, Property chain inclusion axioms Profiles
3.9 Use Case # 9 - Kidney Allocation
Policy in France [HCLS]
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
3.10 Use Case #10 – Clinical Trial
[HCLS]
DESCRIPTION TO BE DONE: Vipul
=> keep it as a particular UC or merge with Use Case #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
3.11 Use Case #11 – Multiple UCs on
datatype [HCLS]
Many Use cases 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
3.12 Use Case #12 – Protégé report on the
experiences of OWL users [Tool]
[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, and
users’ understanding of OWL. To summarize, based on their
experiences, Protégé developpers suggested 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 underlined that one of the omissions in the OWL
language that users complain about most often is 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 Adult, 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 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 value of
annotation 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 type of information about a
property enables tools to control the values that annotation
properties can acquire. Without range constraints it is difficult
to provide the user with appropriate input widgets. In a similar
sense, it is often 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
3.13 Use Case #13 Web service modelling
[Telecom]
People often want to use a class to specify the value of some
property. An example originating at the University of Karlsruhe
[Web Service] is in
service modeling. Services are modeled as instances of the
a:Service class. For each concrete service (i.e., for each instance
of a:Service), the users wanted to state what the input to the
service is. Here is an example 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 due to (1) and (3), and a:Person is a class
due to (2); hence, in (4) we have a relationship between an
individual and a class. Hence, you need some kind of metamodeling
to solve this problem. One way would be that the name 'Person' may
refer both to Person as a class and as an individual denoting
Personas a whole (Class ↔ Individual)
[Web Service]
[Punning]
Requires: Metamodelling
3.14 Use Case #14 Managing vocabulary in
collaborative environments [Designer]
It can be useful to relate schema elements (classes/properties)
with each other in order 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 in the class
Deprecated_Properties and was replaced by property
has_location."
- "Objects of the class City should have a value for the
property population." (expressed by relating class and
property)
These are merely pragmatic descriptions, and 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 intended by punning. Semantic MediaWiki has
already been extended by using off-the-shelf OWL reasoners, and it
would be desirable if such systems would be able to deal with the
use 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 combines the features of 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 attributes of relations themselves. One way to
suppot such case might be Class and Object Property punning(Class ↔
ObjectProperty).
[UML]
[Punning]
Requires: Metamodelling
3.16 Use Case #16 Database federation
[Designer]
Some life sciences application designer has been building a
database federation scheme. The scheme involves designing an XML
schema that describes the fields and values in a variety of
databases, and associated query tools that, from a query interface,
can write queries (in several variants of SQL) to databases that
have relevant information. Those results are presented as a single
integrated view. He hears that OWL and Semantic Web technologies
might be a suitable 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 wide community of users that would like to use 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 ).
[Who reads?]
Requires: Profiles
3.17 Use Case #17 Tools developers
[Tool]
TO BE DONE
[OWL1.1
Tools] [DIG2] [OWL
API]
Requires: Declaration
3.18 Use Case #18 - Virtual Solar
Terrestrial Observatory [Earth and Space]
Note(cg): To me moved up close to other datatype UCs
A virtual observatory is a suite of software applications on a
set of computers that allows users to uniformly find, access, and
use resources (data, software, document, and image products and
services using these) from a collection of distributed product
repositories and service providers. A VO is a service that unites
services and / 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/ ) are 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 National
Science Foundation and National 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 number of
online repositories of scientific data. The background OWL ontology
contains term descriptions for science terms including instruments,
observatories, parameters, etc. Users essentially need to specify a
description of the data they wish to retrieve which includes either
a specific instrument class or a description of that class, a date
range for the data taken, and the parameters. In order to specify
that in relevant science terms, scientists need to be able to
represent numerical ranges and comparisons going beyond the numeric
support of OWL 1. The application also needs to expand to include
spatial descriptions. It would use representational power if
provided for spatial/geographic containment.
[VSTO]
Requires: Qualified Cardinality, Datatype Restriction,
[Defaults]
3.19 Use Case #19 – Semantic Provenance
Capture [Earth and Space]
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 SPCDIS effort is
providing infrastructure to capture declarative descriptions of
scientific provenance information at data ingest time. The initial
domain of the effort is solar coronal physics. This effort requires
(among other things) extended annotations as well as datatype
restriction.
[NCAR]
Requires: Datatype Restriction, Extended
Annotations
4 Requirements
UNDER PROGRESS: TO BE COMPLEMENTED.
Each requirement of a subsection to be described at least by one short sentence.
4.1 R1 : Disjoint Union
While OWL provides means to define a set of subclasses as a
disjoint and complete covering, this cannot be done concisely. This
is a shortcoming given the common use 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
Need the ability to state facts about an individual stating
property values that it does not have.
Motivating use cases : Use Case #9
Resulting OWL2 feature:NegativeObjectPropertyAssertion
4.4 R4: Local reflexivity
OWL does not allow the definition of a subclass of processes
that are processes that auto-regulate themselves. Expressing this
requires local reflexivity.
Motivating use cases : Use Case #5
Resulting OWL2 feature: Self Restriction
4.5 R5: Qualified Cardinality
OWL allows for the definition of a person with at least three
children (informal syntax: atleast 3 hasChildren), but not of a
person with at least three Girl (atleast 3 hasChildren Girl).
Expressing the latter class requires the qualification of the
target of the property hasChildren. Ontology modelers have
repeatedly identified the importance of Qualified Cardinilaty
Restrictions (QCRs)in various applications as illustrated by 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
4.6 R6: Reflexive, Irreflexive,
Asymmetric
In mereology, the partOf relation is defined to be
transitive (if x is a part of y and y is a part of z, then x is a
part of z), reflexive (every object is a part of itself), and
antisymmetric (if an object as a part which in turn has part
itself, then they are the same). Many applications, particularly
those where it is necessary to describe complex structures such as
life science applications, require extensive use of part-whole
relations axiomatized according to these principles. Similarly,
other relations encountered in ontology modeling require similar
axiomatizations, possibly with different sets of characteristics
(see, e.g., [OBO]
[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 #6 Use Case
#8
Resulting OWL2 feature: Reflexive,
Irreflexive, Asymmetric
4.7 R7: Disjoint properties
Need the ability to state that roles are disjoint. This would
mean that the same pair of individuals could be related by at most
one among a set of disjoint properties or the ontology/KB would be
inconsistent. Thus if goodCop and badCop were disjoint roles then
Lennie (a Cop) would be able to take only one of these roles with
respect to any one suspect.
Motivating use cases : Use Case #1 Use Case #2
Resulting OWL2 feature: Disjoint properties
4.8 R8: Property chain / property
composition
Some properties are best defined as a composition of other
properties. In this way users can define properties that "inherit"
values from another individual or define other properties as a
chain of relations (as with hasUncle).
Motivating use cases : Use Case #1 Use Case #5 Use Case
#7 Use Case #8
Resulting OWL2 feature: Property chain inclusion
4.9 R9: Keys
Motivating use cases : Use Case #2 Use Case #7
Resulting OWL2 feature: Keys
4.10 R10 Datatype restriction
OWL provides very limited expressive power for describing
classes whose features include concrete values such as integers and
strings. In OWL, it is possible to express restrictions on datatype
properties qualified by a unary datatype (typically an XML Schema
simple datatype). For example, one could state that every French
citizen has a Passeport Number which is an xsd:string value ranges:
age greater than 18 years, pressure in the range of 1030mb to
1035mb. As illustrated by use cases in this document, datatype
restrictions are required by many users.
Motivating use cases : Use Case #9 Use Case #11 Use Case
#12 Use Case #18
Resulting OWL2 feature: Datatype restriction
4.11 R11: N-ary datatype (?)
To be updated according to the WG decision cf. discussion on MList
[N-ary]
In OWL it is not possible either to represent the following
statements:
- Relationships between values for one object: a square is a
rectangle whose length equals width;
- Relationships between values for different objects: people who
are older than their boss; As illustrated by use cases listed
below, N-ary datatypes 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 say that class Eagle was created by "C. Welty" in 1994,
ID. This was already possible in OWL 1 and is still possible in OWL
2 by means of entity annotation (informally, by annotations of the
entity Eagle by creator: C. Welty, year: 1994)
- Statement about the Eagle specy as a whole, expressing
that "eagles are listed in the IUCN Red
List that is, Eagle denoting an individual of the
RedListSpecies class. RedListSpecies is then a metaclass.
Modeling with metaclasses is commonly called metamodelling
capabilities.
In certain applications, one would simply like to use the same
term (name) for a class (Eagle viewed as a class) and for an
instance (Eagle viewed as an individual of the Red List of
species), while not needing to have whole the inferences 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 Gene Ontology. Such simple metamodelling
capabilities is a common requirement in life sciences
applications.
CG: Use Case #12 is not really a satisfying example: though punning could be used to represent
domain range and hierarchy for annotation as required by Use Case #12, this would not
be 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 allow to associate (metalogical) information,
such as a label or a comment like a textual description of the
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 allow for the
annotation of both entities and axioms.
Motivating use cases : Use Case #12 Use Case #19
Resulting OWL2 feature: Annotation
4.14 R14: Declarations
TBD (CG)
Motivating use cases
Resulting OWL2 features: Declaration
4.15 R15: Profiles
Requirements
Large Life Sciences ontologies like the FMA, NCI Thesaurus,
SNOMED CT, Gene Ontology or other OBO ontologies are mainly
concerned by scalability issues of the language and do not
necessarily need the whole expressivity of OWL. On the other side,
applications involving conventional database systems or Database
software companies, are mainly concerned by interoperability of the
language with conventional relational DBMS and products. While
other ones, such as the busines rules community and more generally
conventional rule systems developpers and companies, rather favor
the interoperability of the ontology 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 the
moment are of three kinds:
- a scalable language for large but rather simple ontologies that
enables good time performance in reasoning
- a language close to database perspective and easy to
interoperate with conventional database systems
- a language close to the rule perspective and easy to
interoperate with conventional rulesystems
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
4.16 R16: Anonymous
Individual
TBD
Motivating use cases :
This may be motivated by the "Ontologies in OWL for Rapid Enterprise
Integration" paper from OWLED 2007. One of their requested
extensions was for individual-denoting functions, where some
of their examples could be satisfied with anonymous individuals
with particular property assertions. I have sent the authors
an email asking about this. -EKW-
Resulting OWL feature: Anonymous individual
5 Features & Rationale
The use cases and requirements presented in the previous section
motivated a number of new features that the OWL 2 specification
should meet as a standard ontology language for the Semantic Web.
These features can be classified into different categories:
- extra syntactic sugar to make some common statements easier to
say, e.g., the disjoint union of classes
- new constructs that increase the expressivity for properties,
e.g., qualified cardinality restrictions or property chain
inclusion
- mechanisms to define new datatypes, e.g., data type
restrictions and facets for restricting a datatype to a subset of
its values
- simple metamodeling capabilities to express metalogical
information about the entities of an ontology
- extended annotations capabilities to annotate entities,
ontologies and also axioms
- other major innovations: new language profiles (sublanguages),
declarations, RDF mapping
Under Progres: TO BE COMPLEMENTED.
Each feature is supposed to be accompanied by
* a short introduction informal sentence
* its syntax + link to the Syntax doc
* simple example(s) issued from Use Cases
* Theoretical Perspective
* Implementation Perspective
* UCs corresponding to the given examples
5.1 Syntactic sugar
"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 shorthands that provide
more concise ways to state disjointness among classes. These
shorthands are: DisjointUnion and DisjointClasses.
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 superclass from a set of mutually disjoint
subclasses.
DisjointUnion :=
'DisjointUnion' '(' { Annotation }
Class ClassExpression ClassExpression { ClassExpression } ')'
Examples.
| DisjointUnion(BrainHemisphere
LeftHemisphere RightHemisphere ) (Ax1) |
BrainHemisphere is a disjoint union of
LeftHemisphere and RightHemisphere. |
| DisjointUnion(Lobe FrontalLobe
ParietalLobe TemporalLobe OccipitalLobe
LimbicLobe) (Ax2) |
Lobe is a disjoint union of FrontalLobe
ParietalLobe TemporalLobe OccipitalLobe and
LimbicLobe. |
| DisjointUnion(Cell NucleatedCell
NonNucleatedCell) (Ax3) |
Cell is a disjoint union of NucleatedCell and
NonNucleatedCell. |
The above axioms mean:
Ax1: A lobe is one of the following types: frontal,
parietal, temporal, occipital, limbic.
Ax2: A Cell is either a nucleated cell or a non-nucleated
cell, and cannot be at 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
- 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 statements in combination with unionOf, 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 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 : Use Case #1 Use Case #2,
Use Case #3, Use Case #4
DisjointClasses on its part only states that all classes from
the set are pair-wise disjoint. It is a shortand for several
owl:disjointWith statements in OWL 1.
DisjointClasses :=
'DisjointClasses' '(' { Annotation
} ClassExpression ClassExpression { ClassExpression } ')'
Examples.
| 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 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
5.2 New constructs for
Properties
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:
5.2.2 F5: Qualified
cardinality
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 |
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.
5.2.3.1 Reflexive Property
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.
5.2.3.2 Irreflexive Property
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
5.2.3.3 Asymmetric Property
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
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.
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
5.2.6 F9: Key
Implementation Perspective
Motivating use cases:
5.3 New datatypes mechanisms
5.3.1 F10: Datatype
restriction
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
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 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
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
5.4 Simple metamodeling
capabilities
5.4.1 F12: Punning
Implementation Perspective
Motivating use cases:
5.5 Extended annotations
5.5.1 F13: Annotation
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.
Implementation Perspective
Motivating use cases:
5.6 Other main innovative
features
5.6.1 F14: Declaration
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 properties and implementation possibilities. These
profiles are described in details in the Profile
document.
OWL-EL++
- Captures expressive power used by many large-scale ontologies,
e.g.; SNOMED CT, 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 power of simple ontologies like thesauri,
and (most of) expressive power of ER/UML schemas
- Features include limited form of existential restrictions,
subClass, equivalentClass, disjointness, range and domain,
symmetric properties, …
- Missing features include existential quantification to a class
(ObjectSomeValuesFrom), self restriction(ObjectExistsSelf),
nominals (ObjectHasValue)(ObjectOneOf),universal quantification to
a class (ObjectAllValuesFrom),
ObjectMinCardinality, ObjectExactCardinality), disjunction
(ObjectUnionOf, DisjointUnion) etc.
cf. the Profile document for an exhaustive list
missing features
OWL-R
- Includes support for most OWL features
- But with restrictions placed on the syntax of OWL DL
- But standard semantics only apply when they are used in a
restricted way
- OWL-R comes in two varieties, OWL-R DL and OWL-R Full.
- Can be implemented on top of rule extended DBMS e.g., SQL (see
Implementation
Perspective below)
[CG: References to be added about Theory]
Theoretical Perspective
- OWL-EL++: Maximal language for which reasoning (including query
answering) known to be worst-case polynomial
- OWL-DB: Maximal language for which reasoning (including query
answering) is known to be worst case logspace (same as DB)
- OWL-R: Allows for scalable (polynomial) reasoning using
rule-based technologies
[CG: References to be added about Implem]
Implementation Perspective
- OWL-EL++ enables efficient implementations since reasoning,
including query answering, known to be worst-case polynomial
[ref]
- OWL-DB enables conjunctive query implementation using
relational DB systems
- can be achieved on top of standard relational database
technology
- E.g., Oracle’s OWL Prime implemented using forward chaining
rules in Oracle 11g
- Query answering can be implemented using query rewriting
- Resulting SQL queries capture all information from axioms
- Can use queries with standard DBMS and relational data
- OWL-R enables the implementation of reasoning using rule
systems
- reasoning algorithms can be implemented by forward chaining
rules applied to triples of the RDF serialization.
- such rule approaches can be used to compute consistency,
classification, and instance checking in polynomial time.
- Conjunctive query answering in OWL-R can be implemented by
extending a standard relational database system with rules
Motivating use cases: Use Case #2 Use Case #3 Use Case
#4 Use Case #8 Use Case #16
5.6.3 F16: Anonymous
individual
Implementation Perspective
Motivating use cases:
6 Tables
UNDER PROGRESS: TO BE COMPLEMENTED.
6.1 OWL 2.0 Features motivated by Use
Cases/Requirements and Gaps in OWL 1.0
| 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 common Gyrus connection |
Two towns are connected to each other if they share a common
border |
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 anatomical
region cannot be part of itself |
The property partOf in general is an irreflexive property |
Irreflexive Object Property |
Not supported |
Not supported in OWL |
IrreflexiveObjectProperty(anatomicalPartOf) |
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
not both. |
Disjoint Union |
Cell = NucleatedCell or NonNucleatedCell, NucleatedCell
disjointWith NonNucleatedCell |
Verbose OWL specifications |
Hemishpere = disjointUnion(LeftHemisphere,
RightHemisphere) |
None |
More compact representation |
| A bacterial cell can subdivide itself |
An author cites himself or herself in a publication |
local Reflexivity Restrictions |
Not supported |
Not supported in OWL |
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 is connected to another cell cannot be
contiguous to it |
Connected regions are not contiguous to each other |
Disjoint Object Property |
Not supported |
Not supported in OWL |
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 XML Schema
datatypes |
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 patient must have had an MRI of the
contralateral breast, no more than 6 months prior to study
entry. |
A student should enroll in a particular course within 6 months
of admission to the school |
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 Space Sciences |
| All material on the Earth is in one of three states: Solid,
Liquid, Gas |
All material on the Earth is in one of three states; Solid,
Liquid, Gas |
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 |
6.2 Use Cases / Requirements
| 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 |
6.3 Use Cases / Requirements /
Examples
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 : 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]
[Ontology with
rules] [Brain
Imaging ]
|
| 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]
[Agence
Biomedecine]
|
| 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 |
7 References
- [SROIQ]
- The
Even More Irresistible SROIQ. Ian Horrocks, Oliver Kutz,
and Uli Sattler. In Proc. of the 10th Int. Conf. on Principles of
Knowledge Representation and Reasoning (KR 2006). AAAI Press,
2006.
- [SHOIQ]
- A
Tableaux Decision Procedure for SHOIQ. Horrocks, I., and
Sattler, U. In Proc. of 19th International Joint Conference on
Artificial Intelligence (IJCAI 2005) (2005), Morgan Kaufmann, Los
Altos.).
- [Next Steps]
-
Next Steps to OWL. B. Cuenca Grau, I. Horrocks, B.
Parsia, P. Patel-Schneider, and U. Sattler. In Proc. of OWL:
Experiences and Directions, CEUR, 2006.
- [Medical Req]
- Web ontology
language requirements w.r.t expressiveness of taxononomy and axioms
in medicine. Christine Golbreich, Olivier Dameron,
Bernard Gibaud, Anita Burgun. In Proc. of ISWC 2003, 2003.
- [Ontology with Rules]
- Ontology enriched by
rules for identifying brain anatomical structures.
Christine Golbreich, Olivier Dameron, Bernard Gibaud, Anita Burgun.
In RIF 2004, Washington, 2004.
- and Annex.
- [Brain Imaging]
- Towards an Hybrid
System Using an Ontology Enriched by Rules for the Semantic
Annotation of Brain MRI Images In Proc. of RR 2007
- The Brain
Anatomy Case Study Christine Golbreich, Olivier Bierlaire,
Olivier Dameron, Bernard Gibaud. In Proc. of Protege
2005.
- [FMA]
-
The Foundational Model of Anatomy A
- - The Foundational
Model of Anatomy B
-
- The Foundational Model of Anatomy C.
- [Chemistry]
-
Describing chemical functional groups in OWL-DL for the
classification of chemical compounds Natalia Villanueva-Rosales
and Michel Dumontier..
-
Modelling Life Sciences knowledge with OWL1.1
- [Auto]
-
An exploratory study in an automotive company.
- [OBO]
- The
OBO Foundry: coordinated evolution of ontologies to support
biomedical data integration. Barry Smith et al. .
- [RO]
- -8-
Relations in Biomedical Ontologies. .
- [OBO2OWL]
- OBO to OWL: Go to
OWL1.1!
- OBO and OWL:
Leveraging Semantic Web Technologies for the Life Sciences (ISWC
2007).
- [Ordnance]
-
Experiences of using OWL at the Ordnance Survey.
- [SNOMED REQ]
- An
examination of OWL and the requirements of a large health care
terminology.
- [Agence Biomedecine]
- Changing Kidney
Allocation Policy in France: the Value of
Simulation.
- [Transplant Ontology]
- Construction of the
dialysis and transplantation ontology.
- [Little Web]
-
A little semantic web goes a long way in biology Wolstencroft,
K., Brass, A., Horrocks, I., Lord, P., Sattler, U., Stevens, R.,
Turi, D.: In: Proceedings of the 2005 International Semantic Web
Conference (ISWC 2005), pp. 786-800. Springer, Berlin Heidelberg
New York (2005) .
- [Part Whole]
- Simple
part-whole relations in OWL Ontologies Alan Rector, Chris
Welty. W3C Editor's Draft 11 Aug 2005 .
- [OWL1.1 Tools]
- Supporting
Early Adoption of OWL 1.1 with Protege-OWL and FaCT++. Matthew
Horridge and Dmitry Tsarkov and Timothy Redmond. In OWL:
Experiences and Directions (OWLED 06), Athens, Georgia.
- [OWL API]
- Igniting
the OWL 1.1 Touch Paper: The OWL API Matthew Horridge and Sean
Bechhofer and Olaf Noppens (2007). In OWL: Experiences and
Directions (OWLED 07), Innsbruck, Austria.
- [DIG2]
- DIG
2.0 Reference Middleware Timo Weith¨oner, Thorsten Liebig,
Marko Luther, and Sebastian B¨ohm In OWL: Experiences and
Directions (OWLED 07), Innsbruck, Austria.
- [Protege OWL]
- The Protégé OWL
Experience Holger Knublauch, Matthew Horridge, Mark Musen, Alan
Rector, Robert Stevens, Nick Drummond, Phil Lord, Natalya F. Noy2,
Julian Seidenberg, Hai Wang. In OWL: Experiences and Directions
(OWLED 05), Galway, Ireland, 2005.
- [N-ary]
- N-ary
Data predicate use case.
- [Web Service]
-
Preference-based Selection of Highly Configurable Web Services
Steffen Lamparter, Anupriya Ankolekar, Stephan Grimm, Rudi Studer:
WWW-07, Banff, Canada, 2007.
- [Wiki]
-
Reusing Ontological Background Knowledge in Semantic Wikis
Denny Vrandecic, Markus Krötzsch, Proceedings 1st Workshop on
Semantic Wikis. Budva, Montenegro, June 2006 .
- [UML]
- Association.
- [Punning]
- Punning Use
Cases.
- [Who reads?]
-
Who reads our documents?.
- NIF.
- NIF
Data-Integration slides.
- [VSTO]
- The
Virtual Solar-Terrestrial Observatory: A Deployed Semantic Web
Application Case Study for Scientific Research. McGuinness,
D.L.; Fox, P.; Cinquini, L.; West, P.; Garcia, J.; Benedict, J.L.;
Middleton, D..
- VSTO2.
- VMO.
- [NCAR]
- Semantic
Provenance Capture in Data Ingest Systems.
Theory references for punning to be added
- Steffen Lamparter, Anupriya Ankolekar, Stephan Grimm, Rudi
Studer: Preference-based Selection of Highly Configurable Web
Services, WWW-07, Banff, Canada, May 2007. PDF
- B. Motik: On the Properties of Metamodeling in OWL, ISWC 2005,
Galway, Ireland, 2005. PDF
- 3.0 3.1 Markus Krötzsch, Denny Vrandecic, Max Völkel, Heiko
Haller, Rudi Studer: Semantic Wikipedia, Journal of Web Semantics
5: 251–261. September 2007. PDF
- Denny Vrandecic, Markus Krötzsch: Reusing Ontological
Background Knowledge in Semantic Wikis, Proceedings 1st Workshop on
Semantic Wikis. Budva, Montenegro, June 2006. PDF
Retrieved from "http://www.w3.org/2007/OWL/wiki/Punning"
Theory references for N-ary to be added