Very large data sets are increasingly common both in science and industry. However, incorporating multiple data types from multiple sources to solve major problems is a signi cant interoperability challenge. Furthermore, documents and other artifacts created in the past can be as important as recently created data sets, but interoperability with such legacy data can also be di cult. The problem with such data sets is not only the di erences in recording media and formats but also the enormous changes in terminology over time. Data sets run the risk of rapid obsolescence as the meaning and formats of the data elds are forgotten or no longer available. Semantic technologies based on logic, databases and the Semantic Web can address the problem of meaningful access to and integration of data both today and over decades and centuries. This paper discusses an initiative to develop and deploy a new federated interoperability infrastructure called the Open Ontology Repository (OOR). The OOR is intended to enable communities to manage the full metadata management lifecycle. The OOR grew out of the Ontolog community that has existed for over 6 years and continues to grow in both size and diversity. An initial OOR server based on BioPortal has been deployed, and further development will emphasize technological solutions that build on existing ontology repositories as well as proven architectures and standards. Nevertheless, many research challenges remain to achieve the requirements that have been identi ed. This paper reports on the research challenges of the OOR initiative and the requirements that gave rise to them. Ultimately, it is hoped that the OOR initiative will result in the deployment of a robust, federated knowledge repository that can collectively correct for multiple points of failure and can foster collaborative stewardship of knowledge and metadata.
Many communities, companies and governments are producing very large data sets that are increasingly complex and diverse. These data sets are very well suited for particular narrowly-de ned, discipline- and sector-speci c purposes. In principle, these data sets could be used for solving more broadly-de ned problems. However, incorporating multiple data types from multiple sources to solve these problems remains a signi cant challenge.
While the data sets that are currently being developed typically engender the greatest level of enthusiasm by the communities that are creating them, data sets created in the past can have equal importance for related communities. The problem is not just the di erences in formats but also the enormous changes in terminology over time. Current data sets run the risk of rapid obsolescence as the meaning of the data elds is forgotten even by the individuals who introduced them.
To ensure that data remains usable, it is important that it be annotated with metadata. As the structure and processing of data has become more complex, metadata has also more complex, and the the role of metadata has become increasingly important. There is a critical need for a robust, scalable infrastructure for metadata. This infrastructure would facilitate data interoperability, sharing, search, retrieval, and long-term preservation.
Scienti c research communities exemplify the problems of increasingly large and complex data
sets. The importance of metadata for scienti c research communities was recognized in a recent
joint report of the National Academies of Science and Engineering, and the Institute of Medicine[
Given the recognition of the importance of metadata by the National Academies, the an infrastructure for managing metadata has the potential for having a major impact on the conduct of modern data-intensive scienti c research. However, simply creating the infrastructure and making it available will not automatically ensure that it is utilized in spite of the mandates in the National Academies report cited above. One can also say the same about metadata and ontologies in industry and government. While ontology search engines, registries and repositories have been developed, and they have had a signi cant impact on some communities, such as many in biomedicine, they have yet to achieve general acceptance by most of the communities that could bene t from the infrastructure.
This paper discusses an initiative to develop and deploy a new federated interoperability
infrastructure for metadata called the Open Ontology Repository (OOR). The OOR grew out of
the Ontolog community, and at a recent Ontolog meeting, the state of the art of ontology
repositories was evaluated and the research challenges were identi ed[
The National Academies report[
Another concern raised in the National Academies report is the need for incentives to ensure that researchers make their data accessible. As the report makes clear, researchers must also provide metadata, and research communities are strongly encouraged to institute ways to reward researchers who do this. While the OOR will certainly not solve the problem of ensuring that researchers release their data; nevertheless, a common, easily used infrastructure for metadata registration and storage would reduce some of the barriers for researchers and research communities to provide standard metadata annotations for their data. 2
The purpose of an Open Ontology Repository is to provide an architecture and an infrastructure that enables support for a) the creation, sharing, searching, and management of ontologies, and b) linkage to database and XML Schema structured data and documents. The next section elaborates on this purpose by giving detailed requirements and goals. However, it is important to clarify that the scope of the OOR is limited to providing an infrastructure that enables metadata management. Thus the initiative aims to achieve the following goals: (1) a formal speci cation of the architecture, including formal speci cations for interfaces and required services to enable federation and interoperability among OOR instances, and (2) a reference implementation of at least one OOR instance providing a basic set of services and supporting a basic metadata lifecycle. The intention is that individual communities will develop their own OOR instances with additional domain- and community-speci c services, yet the instances will nevertheless be able to interoperate. 3
At the Ontology Summit 2008[
To enable communities to support discovery, innovation and learning well into the future, the OOR collaboration will provide mechanisms for communities to manage the full metadata life cycle. The OOR infrastructure will enable creation, sharing, searching, and management of ontologies, including database and XML Schema data de nitions. Complementary goals include fostering the ontology community, the identi cation and promotion of best practices, and the provision of interfaces for services relevant to ontologies. Examples of anticipated services include automated semantic interpretation of content expressed in knowledge representation languages, the creation and maintenance of mappings among disparate ontologies and content, and inference over this content.
The OOR will provide an infrastructure to enable e cient logic programming-based reasoning
methods that amalgamate Semantic Web-based ontologies and rules with extended Prolog and
Answer Set Programming, to be used for reasoning over the ontologies, instances, and rules of the
repository. [
The following are the core requirements for the OOR[
9. The repository should enable communities to manage all phases of the ontology lifecycle. 3.2
The OOR initiative is developing requisite ontology-based architectures, including interfaces for
ontology lifecycle management, theories and implementations of ontology modularity, upper and
middle ontologies, and methods for automatically and semi-automatically aligning and mapping
ontologies. Logical relationships between ontologies will be supported within the repository,
including mutual consistency, extension, entailment, semantic mappings, intelligent search, and decision
support. [
The OOR will provide interfaces for internal and external services and applications including: ontology creation tools, ontology editors, ontology di erencing tools, ontology modularization tools (clustering, etc.), ontology export, ontology visualization (e.g., graph visualization), version management and access control. While the emphasis is on the metadata level, it is awkward to exclude all instance data. Depending on the ontology, instance data will also be included. For knowledge-rich domains, ontologies can include all of the data as well as the metadata. For other domains, the data will be managed by special-purpose applications, and the ontology will be only part of the database, playing the roles that are most appropriate, such as encoding access policies and procedures, enabling discovery and interoperability, helping to ensure integrity, and assuring that data remains accessible and understandable over time periods of decades or more.
To facilitate knowledge discovery the repository shall provide metadata capabilities to support search capabilities, governance process, and management. The repository will support discovery by at least the following criteria: domain, author/creator/source, version, language, terminology and controlled vocabularies, quality, mapping, and inference. The interfaces for discovery will be suitable for both specialist and non-specialist users, using GUIs, web services, and language-based APIs. 3.3
The OOR distinguishes between gatekeeping and quality control. Gatekeeping criteria are a set of minimal requirements that any ontology within the OOR has to meet. The latter are intended to enable the users of the OOR to quickly nd ontologies that t their needs; the criteria are not supposed to ensure the quality of the ontologies. The metadata in the OOR must meet the following criteria: (1) The metadata are submitted in a publicly described language and format. (2) The metadata are read accessible. (3) The metadata are expressed in a formal language with a well-de ned syntax. (4) The authors of the metadata provide the required provenance and other annotations. (5) The metadata have a clearly speci ed and clearly delineated scope. (6) Successive versions of the metadata are clearly identi ed. (7) The metadata is organized into ontologies that are appropriately named. (8) The ontologies specify the process that is employed to create and maintain them.
Ontologies may be regarded as engineering artifacts. Consequently, there must be support for versioning and con guration management. The Ontology Metadata Vocabulary (OMV), Dublin Core, ISO 11179, ISO 19763, and other existing approaches to provenance and versioning support will be used as the basis for annotating ontologies in the OOR. An empirical approach will be used to identify and evaluate repository metadata. Proposals for repository metadata already exist, and they will be evaluated using use-case scenarios. These scenarios both motivate the use of the repository metadata and help establish best practices.
Metadata occurs on many levels. While it is not always possible or necessary to distinguish these levels, it is expected that the metadata in the repository will usually be organized according to Figure 1. In this gure data is from 3 di erent domains. In the rst, data is in the form of image data, in the second data, is sensor data, and in the third, data is a knowledge base. The dashed line separates the data being managed by the OOR and data managed separately from the OOR. Both image data and sensor data requires domain-speci c storage, retrieval and processing software and hardware so it is managed separately. Knowledge bases, on the other hand, are well suited to storage, retrieval and processing by the OOR. Each data set is annotated with metadata that is speci c to the data set. This metadata includes provenance information as well as any structural and processing speci cations that are speci c to the data set. Each domain has its own ontology that speci es those aspects of the metadata annotations that are not covered by the OOR ontology. The domain-speci c ontologies and data set-speci c metadata are annotated as artifacts in the repository. This is called repository metadata in the gure. The semantics of the repository metadata is speci ed by the OOR ontology.
The organization shown in Figure 1 is well suited for data sharing and interoperability within one domain, but not for cross-domain interoperability. Achieving the latter requires that the domain ontologies be related to each other. Although the gure does not explicitly show this, the various ontologies will be related to each other in a web of interconnections. Ontology matching and mediation is an active area of research. The OOR will support the speci cation of relationships between ontologies, both at the level of whole ontologies (e.g., ontology importing) and at lower levels of granularity (e.g., declarating that two resources in di erent ontologies are the same). While ontology matching is outside the scope of the OOR, suitable interfaces will be provided for ontology matching modules.
To support the sharing and reuse of ontologies within the repository the OOR will store both ontologies and metadata for ontologies. The metadata will allow users to: determine whether an ontology is suitable for a user purpose; capture the design rationales that underlie the ontology;
nd information about author, author credentials, and source of ontology reference material; retrieve ontologies for use in domain applications; retrieve ontologies to be integrated with other ontologies; retrieve ontologies that will be extended to create new ontologies; determine whether or not an ontology can be integrated with given ontologies; determine whether a set of ontologies retrieved from the repository can be used together; and determine whether an ontology in the repository can be partially shared.
There will be policies for creation and modi cation of metadata and documentation of ontologies and the management of the persistence and sustainability of ontologies. Users (including end-users, ontology and repository developers, subject matter experts and stakeholders) should participate in the collaborative ontology development life cycle and in decisions regarding what metadata are suitable for ontologies in the repository. The metadata will include both logical metadata (logical properties of the ontology independent of any implementation or engineering artifact) and engineering metadata (properties of the ontology considered as an engineering artifact). 3.5
It is not su cient for the OOR just to store ontologies; it also needs to enable the evaluation of the ontologies within it. The OOR will o er functionalities like those on social networking sites which would allow users to comment on ontologies and rank them. Further, the OOR will enable selective views of the repository using tags provided by subcommunities that characterize ontologies with respect to their chosen criteria. For example, such a view might select ontologies for speci c elds of research or industries, or ontologies satisfying speci c quality criteria or levels of organizational approval.
The OOR will develop methods, practices, services, and artifacts to support automated and
human reviewed evaluation and comparison of ontologies stored in the repository. [
Ontology engineering is a rapidly developing research area. There are both computational and
storage challenges as the size of a knowledge base grows, since the computational complexity
of logical inference is much greater than the complexity of traditional database query processing.
Ontology repositories constitute a sub eld within ontology engineering, and has its own community
and conferences. In a recent meeting, the state of the art of ontology repositories was evaluated
and research challenges were identi ed[
Existing ontology repositories tend to have many of the same features, such as registration,
submission and upload; browsing and search; description and documentation; metrics and statistics. There
are many missing features, but the most noticeable is the lack of structure among the ontologies.[
While ontologies are claimed to be a mechanism for interoperability and communication between data sources, ontologies themselves are nearly always built in isolation. There is no common representation of metadata annotations of ontologies and no common ways to identify versions of ontologies. The various ontology repositories use a variety of techniques and do not enforce any standard conventions. 4.2
The number of existing representation languages for metadata and ontologies is enormous and
growing. One can use text, XML, frames, graphs, OWL DL, HOL, UML and SQL to name
just a few. Languages for representing relationships between ontologies are also emerging. The
development of the Common Logic standard (ISO/IEC 24707:2007) is especially important because
it can act as a common language for most of the existing ontology representation languages. The
challenge to the ontology community to develop tools for CL. The particular challenge for ontology
repositories is to Construct a repository of rst-order ontologies that will serve as a testbed for
ontology evaluation and integration techniques, and that can support the design, evaluation, and
application of ontologies in rst-order logic. The Common Logic Ontology Repository (COLORE)
being developed by Michael Gruninger is a prominent example of such an e ort.[
Experience has shown that the following to be the factors that are well correlated with reuse:[
Therefore, it is important to have well-speci ed policies for vocabulary management, metadata,
and provenance speci cation to enable trust. It is also critical to have a commitment to forming,
accommodating, serving, and working with a community of users. This emphasizes the importance
of outreach and education, including the identi cation and promotion of best practices. Since the
OOR will be an open, federated architecture and infrastructure, it is intended to be utilized by
communities to host their own ontologies as well as allowing the communities to adapt previously
established ontologies for their own purposes. The challenge is to develop appropriate educational
mechanisms for a very diverse set of communities. An important example is the Ontolog Forum
which has been engaging in educational and outreach activities for 6 years, reaching over 40 distinct
communities. Examples include communities in bioinformatics, national command and control, and
intelligence. [
Ultimately the OOR initiative should provide:
Community collaboration environment (shared les, email archives, and web pages, either public or secure);
Training and workshops in metadata technologies and techniques, particularly dealing with semantic tools and services, including vocabulary and ontology development, metadata standards and their application, as well as metadata-enlightened architectural development and analysis;
5
This paper introduced the OOR initiative, focusing on the requirements and research challenges that have been identi ed by the OOR community. The requirements represent the consensus of a large collection of individuals from diverse communities in academics, industry and government. However, the ultimate success of the initiative will be determined not by whether it succeeds in achieving its stated requirements, but rather by whether data- and knowledge-intensive communities use the OOR architecture as the basis for their own metadata management. Consequently, the most important challenge may turn out to be education and outreach. 6
This report is the result of contributions by a large number of individuals who have been involved in the Ontology Summits, the Ontolog and OOR meetings, and particularly the following individuals: Leo Obrst, Mark Musen, Mike Dean, Peter Yim, Michael Gruninger, Elisa Kendall, Bart Gajderowicz, Mathieu d'Aquin, Steve Ray and Katherine Goodier. 2009.