Warning:
This wiki has been archived and is now read-only.

UCRDraft

From OWL
Jump to: navigation, search

__

[Hide Review Comments]

Document title:
OWL 2 Web Ontology Language
Requirements (Second Edition)
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
Abstract
The OWL 2 Web Ontology Language, informally OWL 2, is an ontology language for the Semantic Web with formally defined meaning. OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents. The OWL 2 Document Overview describes the overall state of OWL 2, and should be read before other OWL 2 documents.
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.
Status of this Document
This document is meant to supplement the use cases and requirements provided as part of the initial OWL Recommendation in OWL Web Ontology Language Use Cases and Requirements. Currently this document is only an editors draft.

Copyright © 2008-2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.


Contents

 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.
 NOTE:
 Christine is being EDITING
 cgolbrei@gmail.com


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.

After an introduction presenting a sample of multiple applications and users of OWL in various domains, 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 OWL 2 [Syntax documents.

2 Multiple Applications and Users

In this section, we discuss multiple domains needs 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 language as discussed in later sections.

2.1 Health Care and Life Sciences

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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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 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.

  • Clinical Research and Clinical Trials

Applications in Clinical Research and Clinical Trials consists of information and knowledge related to a patient 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. 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

  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. 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
  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.1.2 Users and Stakeholders

  • 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?

  • 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 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.

  • Internal Medicine or Neurology Experts

(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:

  1. 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.
  2. 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
  • 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.

  • Neurophysiologists or Cellular and molecular Experts

(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:

  1. 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.
  2. 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.
  • Clinical Experts

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:

  1. 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.
  2. 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.

Use Cases: Use Case #1 Use Case #2 Use Case #3 Use Case #5 Use Case #7 Use Case #8 Use Case #9 Use Case #10 Use Case #11 Use Case #N1 Use Case #N2 Use Case #N3

2.2 Manufacturing

2.2.1 Applications

2.2.2 Users and Stakeholders

  • 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.

  • 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?

Use Cases: Use Case #4

2.3 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.3.1 Applications

  • 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.3.2 Users and Stakeholders

  • 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.

  • 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 )

  • 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.

Use Cases: Use Case #6 Use Case #18 Use Case #19

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 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

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. Monocyclic and polycyclic ring structures are important parts of molecules that participate in several kinds of chemical reactions. Some way such as self restrictio, allowing some local reflexivity, would be helpful to express that ring structures are auto-connected that is, rings are a kind of chemical structure which isConnectedTo to itself.

[Chemistry]

Requires: Disjoint Union, Disjoint Classes, Local reflexivity, 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 (DB)

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: Local reflexivity, 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 [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. The required property chain inclusion axioms allow to encode inheritance of properties along another property, e.g., part-of, which is of utmost importance in anatomy. For example, with axioms such as has-locationproper-part-of < has-location injury to finger can be inferred as injury to hand. As reported in [SNOMED EL+] by re-engineering SNOMED-CT in that way, the number of anatomical classes dropped from 54,380 to 18,125, and the time needed by the CEL reasoner [CEL] (version 0.94)from 900.15 seconds to 18.99 seconds.
Like the FMA given the common use of cross-references between SNOMED and other biomedical ontologies via concepts ID, keys would be highly useful as well.

[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

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 (a registration number is assigned at the registration of the waiting list which uniquely identifies a patient on the 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 restriction, Keys

3.10 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: N-Ary

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 restriction, N-Ary

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. "The user communities anxiously await an extension to the OWL specification to represent user-defined datatypes with XML Schema facets such as xsd:minInclusive." 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: Qualified cardinality restriction, Datatypes restriction, 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 (OWL-DB)

3.17 Use Case #17 - Tools developers [Tools]

TO BE DONE

[TOOLS] [DIG2] [OWL API] [Syntax Problem]

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

3.20 Use Case (New#1) - Problem Oriented Medical Record (POMR) Ontology [HCLS]

Note(cg): More precise Requirements to be specified
For example,  Custom Datatypes and Lists would be useful for HL7 ([http://esw.w3.org/topic/HCLS/ACPPTaskForce?action=AttachFile&do=get&target=RIMV3OWL.owl. 
Should we put requirements which are delayed or open ?

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.

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.

3.21 Use Case (New#2) - Micro Theory for Long Bone Fractures[HCLS]

 Note(cg): To me moved up close to other Property chain inclusion UCs
 Ref to be moved in the list of References

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

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

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

Requires: Property chain inclusion axioms

3.22 Use Case (New#3): Interoperation of Clinical Information across Healthcare and Clinical Trials [HCLS]

Comment(cg): Requirements more specifically in relation to OWL 2 should be clarified/abstracted from this UC
Suggest to remove requirements already met by OWL 1, e.g. equivalence, from the list below 

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

4 Requirements

UNDER PROGRESS: TO BE CHECKED/COMPLEMENTED

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 #4

Resulting OWL2 feature: DisjointUnion

4.2 R2: Disjoint Classes

Disjointness among classes abounds in domain models yet OWL has no single construct 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 assert 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 Use Case #3

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 Use Case #N2

Resulting OWL2 feature: Property chain inclusion

4.9 R9: Keys

Keys, most often aka inverse functional datatype properties, are clearly of vital importance to many applications in order to uniquely identify individuals of a given class by values of (a set of) key properties.

Motivating use cases: Use Case #2 Use Case #7 Use Case #9

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 Use Case #19


Resulting OWL2 feature: Datatype restriction

4.11 R11: N-ary datatype

To be updated according to the WG  decision cf. discussion on the Working Group MList

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 #10 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.

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. 1) Should add a note ? 2) Should add other Requirement ?

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 

Motivating use cases: Use Case #17

Resulting OWL2 features: Declaration

4.15 R15: Profiles

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 rules systems

Motivating use cases: 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:

  1. extra syntactic sugar to make some common statements easier to say, e.g., the disjoint union of classes
  2. new constructs that increase the expressivity for properties, e.g., qualified cardinality restrictions or property chain inclusion
  3. mechanisms to define new datatypes, e.g., data type restrictions and facets for restricting a datatype to a subset of its values
  4. simple metamodeling capabilities to express metalogical information about the entities of an ontology
  5. extended annotations capabilities to annotate entities, ontologies and also axioms
  6. 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.

5.1.1 F1: DisjointUnion

DisjointUnion defines a class as the union of other classes, all of which are pair-wise disjoint. It is a shorthand for owl:disjointWith statements used in combination with owl:unionOf to define a complete superclass from a set of mutually disjoint subclasses.

DisjointUnion := 'DisjointUnion' '(' { Annotation } Class ClassExpression ClassExpression { ClassExpression } ')'

Examples.

  • HCLS
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


5.1.2 F2: DisjointClasses

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.

  • HCLS
DisjointClasses( LeftLung RightLung ) (Ax5) Nothing can be both a Leftlung and a RightLung.
DisjointClasses( UpperLobeOfLung MiddleLobeOfLung LowerLobeOfLung ) (Ax6) UpperLobeOfLung MiddleLobeOfLung LowerLobeOfLung are pairwise disjoint.

The FMA exhibit a huge number of such classes [4 C]: 3736 classes of template Left X vs Right X (e.g. Left lung vs Right lung) 13989 classes of template X left Y vs X right Y (e.g. Skin of right breast vs Skin of left breast) 25 classes with template Male X vs Female X (e.g. Male breast vs Female breast) 75 classes X male Y vs X female Y (e.g. Right side of male chest vs Right 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


5.1.3 F3: NegativeObjectPropertyAssertion NegativeDataPropertyAssertion

OWL 2 provides the shortands NegativeObjectPropertyAssertion and NegativeDataPropertyAssertion for asserting negative facts. While an ObjectPropertyAssertion (resp. DataPropertyAssertion) axiom states 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.

  • HCLS
NegativePropertyAssertion( livesIn ThisPatient Paris ) (Ax7) ThisPatient does not live in Paris.
NegativePropertyAssertion( hasAge ThisPatient 5^^xsd:integer ) (Ax8) ThisPatient 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.

Implementation Perspective

Being syntactic sugar, it's possible to take an ontology that is OWL 1 except for NegativePropertyAssertion

and preprocess it into an equivalent OWL 1 ontology without it.

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 addresses 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.


5.2.1 F4: Self Restriction

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.

  • HCLS
ExistsSelf( regulates) class of all individuals that regulates themselves
ExistsSelf( isConnectedTo) (Ax9) individuals, e.g., a ring structure, isConnectedTo itself
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.

Additionaly, 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: Local reflexivity is already supported by existing tools, e.g., FACT++. According to developpers, local reflexivity was relatively easy to implement [TOOLS] – for any individual x that must have a relationship along a reflexive property, an appropriately labelled edge <x, x> has been added to the model.

Motivating use cases: Use Case #5 Use Case #3


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.

5.2.2.1 Object Property Cardinality Restrictions

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.

  • HCLS

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.


  • Automotive industry
MaxCardinality( 5 hasPart Door ) (Ax13) Class of objects having atmost 5 Door
ExactCardinality( 2 hasPart FrontDoor ) (Ax14) Class of objects having exactly 2 FrontDoor
ExactCardinality( 2 hasPart RearDoor ) (Ax15) Class of objects having exactly 2 RearDoor
ExactCardinality( 1 hasPart TrunkDoor ) (Ax16) Class of objects having exactly 1 TrunkDoor

Ax13: this restriction allows representing that cars have atmost 5 doors Ax14 Ax15 Ax16: these restrictions allow expressing for example that five-door card have exactly three doors, two front doors, two rear doors, plus one trunk

5.2.2.2 Data Property Cardinality Restrictions

DataMinCardinality := 'MinCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'

DataMaxCardinality := 'MaxCardinality' '(' nonNegativeInteger DataPropertyExpression [ DataRange ] ')'

DataExactCardinality := 'ExactCardinality' '(' nonNegativeInteger DataExactCardinality [ ClassExpression ] ')'

Examples.

  • HCLS
MaxCardinality( 1 hasSSN ) (Ax17) Each object can have at most one Social Security Number

Theoretical Perspective

As already said above, qualified cardinality restrictions are present in the SROIQ desctiption logic underlying OWL 2 since they were required in various applications e.g.; [Medical Req] [Little Web] and did not pose theoretical or practical problems to be added [SHOIQ]. It was known from a long time that resulting logic is decidable and QCR was already supported by DAML+OIL, the predecessor of OWL 1.

Implementation Perspective:

QCRs do not pose implementation problem either. It has been successfully implemented both in earlier editor, e.g.; OilED, and reasoner, e.g., FACT++, that already processed ontology with QCRs, before OWL 1 recommendation. Current versions of tools under development for OWL 2, e.g.; Protégé 4, FACT++, PELLET, RACER, KAON2 also deals with QCRs [TOOLS] [OWL API].

Motivating use cases : Use Case #1 Use Case #2 Use Case #3, Use Case #4


5.2.3 F6: Reflexive, Irreflexive, Asymmetric

New characteristics can be asserted on Object Properties in OWL 2: Reflexivity, Irreflexivity, Asymmetry.

5.2.3.1 Reflexive Property

A reflexivity axiom asserts that 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.

  • HCLS
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

  • HCLS
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.
  • Earth and Space
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

  • HCLS
AsymmetricProperty( proper_part_of )(Ax24) The property proper_part_of is asymmetric.

Ax24: if p is a proper part of q then q cannot be a proper part of p

Theoretical Perspective

see F4 Theoretical Perspective above

Implementation Perspective This was similar to the approach taken to support local reflexivity, and was relatively straight forward. Implementation of the algorithms for irreflexive and asymmetric properties is based on the previously implemented extensions for local reflexivity and disjoint properties, and essentially 'came for free'. [TOOLS]

Motivating use cases: Use Case #1 Use Case #2 Use Case #3 Use Case #5 Use Case #6 Use Case #7


5.2.4 F7: Disjoint properties

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

  • HCLS
DisjointProperties( connectedTo contiguousTo ) (Ax25) connectedTo is disjoint with contiguousTo

Ax25: Properties connectedTo and contiguousTo of Use Case #1 are exclusive, that is do not hold at the same time. According to the definition of these properties ([2]), when two anatomical entities are linked via an actual third anatomical entity, they are stated to be connected. On the opposite, when they are not related by an actual entity but are adjacent via a conventional entity, they are said to be contiguous. Consequently, two parts cannot be both connected and contiguous.

Theoretical Perspective see F4 Theoretical Perspective above

Implementation Perspective: In FACT++, the processing of disjoint properties was split into static and dynamic parts. A dynamic analysis is applied to nodes that are merged during the reasoning process, and all other cases are handled by static analysis [TOOLS].

Motivating use cases: Use Case #1 Use Case #2 Use Case #3


5.2.5 F8: Property chain inclusion

OWL 2 allows to chain several object properties by 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

  • HCLS
SubPropertyOf( PropertyChain( locatedIn partOf ) locatedIn ) (Ax26) 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 S1S2 ◦ ,..., ◦ 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

The most challenging aspect of implementing an OWL 2 reasoner, was the implementation of property chain inclusion axioms. Several optimisations were necessary to ensure acceptable reasoner performance [TOOLS].

To conclude: 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]. In terms of extending existing OWL 1.0 reasoners and editing tools to cope with OWL 2, it has been found that the effort required to implement such extensions was perfectly acceptable, and minimal in comparison to the task of developing such tools from scratch [TOOLS].

Note(cg): Not sure it's rigorously exact for all features, should be checked by implementors
What feature is not yet implemented, if any.
Contributions would be welcome to provide UpTodate complements, e.g.; about DIG 2,  P4, Pellet.

Motivating use cases: Use Case #1 Use Case #5 Use Case #7


5.2.6 F9: Key

OWL 2 allows to define key properties for a given class by means of the new construct KeyFor.

A KeyFor axiom states that a set of object or data properties are keys for (named) instances of a class that is, when two (named) instances of the class coincide on all the values of the key properties, these two individuals are the same.

KeyFor := 'KeyFor' '(' { annotation } ObjectPropertyExpression | DataPropertyExpression { ObjectPropertyExpression | DataPropertyExpression } ClassExpression ')'

  • HCLS
KeyFor( a:hasSSN a:Patient ) Each patient is uniquely identified by his social security number.
ClassAssertion( a:Patient a:ThisPatient ) a:ThisPatient is an instance of a:Patient.
PropertyAssertion( a:hasSSN a:ThisPatient "123-45-6789" ) a:ThisPatient has the social security number "123-45-6789".

The first axiom makes a:hasSSN the key for individuals in the class a:Patient that is, each instance of a:Patient is required to have a unique value for a:hasSSN. If the values of a:hasSSN were the same for two instances of Patient, these two individuals would be equal.

Theoretical Perspective

TO BE COMPLETED, CHECKED 

Keys in general have the following properties [Easy Keys]:

  1. Missing key values raise an error (optional)
  2. Functionality constraints on keys (optional)
  3. If X and Y have the same key values, then X=Y.

The first feature is not expressible directly in first order logic. The second feature, Functionality, can be expressed in OWL (both for data and object properties). The third feature, in its general form, can lead to unfeasibly difficult reasoning in OWL (given what is currently known and anticipated). However, a more restricted form limited to named individuals, can be expressed in first order logics as a DL Safe rule e.g., the following DL safe rule expresses that keyProperty (whatever data or object property) is a key property:

keyProperty(X, Z), keyProperty(Y, Z) implies X = Y.

(for details see Semantics for Key)

Implementation Perspective

TBD

Motivating use cases: Use Case #2 Use Case #7 Use Case #9


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

  • HCLS
DatatypeRestriction(xsd:integer minInclusive 18) (Ax27) new datatype with a lower bound of 18 on the XML Schema datatype xsd:integer.

Ax27: At hospital, patients under 18 (child) depend on pediatric services while over 18 (adult) depend on adult services

Theoretical Perspective

Implementation Perspective See Unary Datatypes Implementation Report and implementation matrix for status on built-ins listed in OWL 1.0 docs and facets listed in member submissions.

Motivating use cases: Use Case #9 Use Case #11 Use Case #12 Use Case #18 Use Case #19


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

  • HCLS
AllValuesFrom( admissionTemperature currentTemperature inferior) (Ax28) individuals whose admissionTemperature is inferior to currentTemperature.
AllValuesFrom( admissionbodyWeight + 2 currentbodyWeight inferior) (Ax29) individuals whose currentbodyWeight is more than 2 above admissionbodyWeight.

Ax29: A patient is admitted with chest pain. Next day: if the patient's current body weight is more that two pounds above the admission body weight you look for congestive cardiac failure and give diuretics

Theoretical Perspective

N-ary can be used to compare values of data properties for a single given object e.g., in any patient, the systolic blood pressure is always greater or equal than the diastolic blood pressure. They cannot be used to compare values of data properties for different objects (e.g., defining the class of individuals whose body weight is superior than their mother's) which leads to undecidability.

Implementation Perspective

TBD

Motivating use cases: Use Case #10 Use Case #11


5.4 Simple metamodeling capabilities

5.4.1 F12: Punning

OWL 2 provides a simple form of metamodelling based on punning, that is the same name can be used for different types of entities, with certain restrictions, more percisely:

  • the name used for an individual can also be used for a class, datatype, object property, data property or annotation property
  • the name used for a class or a datatype can also be used for an individual, object property, data property or annotation property
  • the name used for an object property or data property or annotation property can also be used for an individual, class or datatype

The same name cannot be used for an ObjectProperty and an DatatypeProperty or for a Class and a Datatype.

Examples

  • Telecom
Declaration( Class( a:Person ) ) (Ax30-1) a:Person is declared to be a class
ClassAssertion( a:Service a:s1 ) (Ax30-2) a:s1 is an instance of a:Service.
PropertyAssertion( a:hasInput a:s1 a:Person )(Ax30-3) a:s1 has input a:Person.

Axiom (Ax30-1) declares a:Person to be a class.
Axiom (Ax30-2) asserts that a:s1 is an individual of the class a:Service.
Axiom (Ax30-3) states that the individual a:s1 is connected by a:hasInput to the individual a:Person.
Thus the name 'Person' refers both to Person as a class in (Ax30-1) and as an individual denoting Person as a whole in (Ax30-3). The same name denotes both a class and an individual. This is possible in OWL 2 thanks to punning (Class ↔ Individual, in the example).

  • Collaborative environment (Wiki)
Declaration( Class( a:Deprecated_Properties ) ) (Ax31-1) a:Deprecated_Properties is declared to be a Class
Declaration( ObjectProperty( a:is_located_in ) ) (Ax31-2) a:is_located_in is declared to be an ObjectProperty
ClassAssertion( a:Deprecated_Properties a:is_located_in ) (Ax31-3) a:is_located_in is an instance of a:Deprecated_Properties.

Axiom (Ax31-1) declares a:Deprecated_Properties to be a class
Axiom (Ax31-2) declares a:is_located_in to be an ObjectProperty
Axiom (Ax31-3) states that a:is_located_in is an individual of the class a:Deprecated_Properties.
Thus the name 'is_located_in' refers both to is_located_in as an object property in (Ax31-2) and as an individual of the class a:Deprecated_Properties in (Ax31-3). The same name denotes both a property and an individual. This is possible in OWL 2 thanks to punning (Property ↔ Individual, in the example).

Note: this example is issued from Use Case #14 but this should have been expressed without metamodelling, by an annotation deprecated property of the property a:is_located_in.

Theoretical Perspective

According to OWL 1 Direct Model-Theoretic Semantics:

  • (i) the vocabulary VC of classes names and VD of datatypes names are disjoint that is, the same name (URI)

cannot be used for a class and a datatype;

  • (ii) the vocabularies VDP of data property names, VIP of object property names, VAP of annotation property names, (plus VOP

the set of URI references for the built-in OWL ontology properties) are pairwise disjoint thats is, the same name cannot be used for a data property, an object property and an annotation property.

Besides, in order to retain decidability OWL DL imposed additional conditions on the vocabulary:

  • (iii) the sets VC of classes names and VIP of object property names and the set of individuals names are disjoint that is,

the same name cannot be used for a property or a class and an individual. In other words, metamodelling was not supported by OWL DL. On the opposite, OWL full did not impose this resctriction, but Sthe style of metamodelling adopted in OWL full led to undecidability.

In OWL 2, following the proposal of simple [Metamodelling] based on punning, conditions (iii) have been relaxed while retaining decidability. Below the list of punning (at this time) allowed in OWL 2.

In the following
X | Y:
Z | W
should be interpreted as "a URI u used as an object of type X or Y can also be used as an object of type Z or W"

  • individual and :

class | datatype | object property | data property | annotation property

  • a class or datatype:

individual | object property | data property | annotation property

  • object property | data property | annotation property:

individual | class | datatype

Punning ObjectProperty ↔ DatatypeProperty and Class ↔ Datatype is forbidden, that is rthe same name cannot be used for or .

Implementation Perspective

Motivating use cases: Use Case #12 Use Case #13 Use Case #14 Use Case #15

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.

Theoretical Perspective

Implementation Perspective

Motivating use cases:

5.6 Other main innovative features

5.6.1 F14: Declaration

Theoretical Perspective

Implementation Perspective

Motivating use cases:


5.6.2 F15: Profiles OWL-EL++, OWL-DB, OWL-R

OWL 2 defines several profiles, sublanguages with useful computational 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, object property inclusion (SubObjectPropertyOf), possibly involving property chains, and data property inclusion (SubDataPropertyOf)

transitive properties, keys (KeyFor) …

  • Missing features include value restrictions, Cardinality restrictions (min, max and exact), disjunction and negation
  • Related to [EL++] [EL++ Update]

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

  • Query answering can be implemented using query rewriting (see Implementation Perspective below )

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
      • Related to DLP [DLP] and pD* [pD*]
  • 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)

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

Implementation Perspective

[CG: References to be added about Implem]
  • 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

Theoretical Perspective

Implementation Perspective

Motivating use cases:

6 Tables

UNDER PROGRESS: TO BE COMPLEMENTED. 

6.1 Use Cases ↔ Requirements

Use Case Disjoint Union Disjoint Classes Negative property Local reflexivity Qualified Cardinality Reflex., Irrefl., Asymm. Disjoint properties Property chain Keys Datatype restriction N-ary datatype Meta-
modeling
Extend. annot. Declarations Profiles Anonym. Individual
UC#1
*
*
-
-
*
-
*
*
-
-
-
-
-
-
-
-
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
-
-
-
-
-
-
-
-
-
-
-
-
-
*
-
-
UC#18
-
-
-
-
*
-
-
-
-
*
-
-
-
-
-
-
UC#19
-
-
-
-
-
-
-
-
-
*
-
-
*
-
-
-

6.2 Use Cases / Requirements / Features 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".

[Note(cg): is it worth to make possible automatic ordering? ]
Use Cases Requirement/Feature Domain
Users
Feature Example 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 R4 R5 R15
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 Qualified Cardinality
R1 R15
Auto

ExactCardinality( 2 hasPart RearDoor )

Class of objects having exactly 2 RearDoor

[Auto]
UC#5 Local reflexivity
R6 R8
HCLS ExistsSelf( regulates) (Ax9)

class of all individuals that regulates themselves

[OBO]

[RO] [OBO2OWL]

UC#6 Irreflexive property Earth
&Space
IrreflexiveProperty( flowsInto )

Nothing flowsInto itself.

[Ordnance]
UC#7 Property chain
R9
HCLS SubPropertyOf( PropertyChain( locatedIn partOf ) locatedIn )

anything locatedIn a part is locatedIn the whole, e.g. a disease.

[SNOMED REQ]
UC#8 Reflexive property
R5 R8
HCLS ReflexiveProperty( partOf )

[Part Whole] argues about partOf as a reflexive property e.g. that a "car is a part of a car".

[Part Whole]
UC#9 Negative property
R9 R10
HCLS NegativePropertyAssertion( hasAge ThisPatient 5^^xsd:integer )

This patient is not five years old.

[Transplant Ontology]

[Agence Biomedecine]

UC#10 R11 HCLS ex [N-ary]
UC#11 N-ary
R10
HCLS AllValuesFrom( admissionTemperature currentTemperature inferior)

individuals whose admissionTemperature is inferior to currentTemperature.

[N-ary]
UC#12 Datatype restriction
R5 R12 R13
Tool DatatypeRestriction(xsd:integer minInclusive 18)

new datatype with a lower bound of 18 on the XML Schema datatype xsd:integer, e.g. to describe the class Adult.

[Protege]
UC#13 Metamodelling Telecom Declaration( Class( a:Person ) )

a:Person is declared to be a class
ClassAssertion( a:Service a:s1 )
a:s1 is an instance of a:Service
PropertyAssertion( a:hasInput a:s1 a:Person )
a:s1 has input a:Person.

[Web Service]

[Punning]

UC#14 Metamodelling wiki (Designer) Declaration( ObjectProperty( is_located_in ) )

is_located_in is declared to be an ObjectProperty
ClassAssertion( Deprecated_Properties is_located_in )
is_located_in is an individual of the class Deprecated_Properties.

[Wiki]

[Punning]

UC#15 Metamodelling Designer ex [UML]

[Punning]

UC#16 Profiles Designer ex [Who reads?]
UC#17 Declaration Tool ex [TOOLS]

[DIG2] [OWL API] [Syntax Problem]

UC#18 Datatype
R10
Earth&Space ex [VSTO]
UC#19 Annotation
R10
Earth&Space ex [NCAR]

Legend:

R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16
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



6.3 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

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.
[Syntax Problem]
Problem with OWL Syntax. Boris Motik and I. Horrocks, OWLED 2006, 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 .
[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.
[CEL]
CEL—A Polynomial-time Reasoner for Life Science Ontologies. F. Baader, C. Lutz, and B. Suntisrivaraporn. In U. Furbach and N. Shankar, editors, Proceedings of the 3rd International Joint Conference on Automated Reasoning (IJCAR'06), volume 4130 of Lecture Notes in Artificial Intelligence, pages 287–291. Springer-Verlag, 2006.
[SNOMED EL+]
Replacing SEP-Triplets in SNOMED CT using Tractable Description Logic Operators. B. Suntisrivaraporn, F. Baader, S. Schulz, K. Spackman, AIME 2007
[EL++]
Pushing the EL Envelope. Franz Baader, Sebastian Brandt, and Carsten Lutz. In Proc. of the 19th Joint Int. Conf. on Artificial Intelligence (IJCAI 2005), 2005.
[EL++ Update]
Pushing the EL Envelope Further. Franz Baader, Sebastian Brandt, and Carsten Lutz. In Proc. of the Washington DC workshop on OWL: Experiences and Directions (OWLED08DC), 2008.
[DL-Lite]
Tractable Reasoning and Efficient Query Answering in Description Logics: The DL-Lite Family. Diego Calvanese, Giuseppe de Giacomo, Domenico Lembo, Maurizio Lenzerini, Riccardo Rosati. J. of Automated Reasoning 39(3):385–429, 2007.
[DLP]
Description Logic Programs: Combining Logic Programs with Description Logic. Benjamin N. Grosof, Ian Horrocks, Raphael Volz, and Stefan Decker. in Proc. of the 12th Int. World Wide Web Conference (WWW 2003), Budapest, Hungary, 2003. pp.: 48–57
[pD*]
Completeness, decidability and complexity of entailment for RDF Schema and a semantic extension involving the OWL vocabulary. Herman J. ter Horst. J. of Web Semantics 3(2–3):79–115, 2005.
[Metamodeling]
On the Properties of Metamodeling in OWL. Boris Motik, ISWC 2005, Galway, Ireland, 2005. PDF
On the Properties of Metamodeling in OWL (Journal of Logic and Computation). Boris Motik. On the Properties of Metamodeling in OWL. Journal of Logic and Computation, 17(4):617–637, 2007.
 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
  • 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