From OntologPSMW
Contents |
The Team:
(1A1)
The purpose of this section is to set out the
major design decisions and the technology choices
which are important to the creation of
ontology repositories.
(1B1A)
Ontology repositories support the storage,
search, retrieval and integration of multiple
ontologies.
(1B1B)
Ontology repositories support macro-level
storage, query and retrieval (across the collection
of ontologies) and micro-level operations
(within individual ontologies). At each
level we would like to support both text
search, and semantic search (variously
faceted search, SPARQL, ontology and
ontology language literate search).
Some ontology repositories have used the
same technologies for both macro-level
and micro-level operations.
(1B1C)
A key decision is the choice of a representation
of the ontologies. Current practice includes:
text, frames (e.g., OBO), graphs (e.g., RDF),
and various types of logic,
e.g., description logics (e.g., OWL-DL), first
order logic (e.g., Common Logic), sorted logics,
possibly higher order logic (HOL).
Other possibilities include the
use of UML (e.g., in the OMG Ontology Definition Metamodel).
(1B1D)
Ontologies have been stored in long narrow relations,
e.g., "triple stores" of RDF triples
(subject, relationship, object), relational databases,
customized data stores.
Increasingly implementors are using "quad stores" in
order to support Named Graphs. "Column stores"
such as MonetDB and Vertica have also been used
to store ontologies.
(1B1E)
For the purposes of ontology integration it helps
to have all of the ontologies in the repository
encoded in a common representation. However, this
requires the sometimes difficult and lossy translation of
ontologies among various representations into the
common representation. Some ontology repositories
store ontologies in their native representation,
with some metadata to identify the representation language.
(1B1F)
We also need some way to support ontology interoperation
by specifying the mappings among entities, e.g.,
with relationships such as same_as, is_a, and part_of.
Other mapping relationships include: see_also, similar_to.
Some ontology mapping consistency checking tools check that
mappings between partially ordered ontologies, e.g., taxonomies,
preserve the partial orders.
(1B1G)
Many ontology repositories which support partially ordered ontologies (taxonomies
and partonomies) may decide to materialize
the transitive closure of the partial order relation.
This provides faster query evaluation at the expense
of additional ingestion costs, storage, and maintenance.
(1B1H)
Provenance of definitions in ontologies is important to
the credibility, scientific attribution, and regulatory compliance
of ontologies. In particular, many definitions are embodied in
legislation, administrative regulations, court decisions,
professional society standards.
(1B1I)
Provenance and other metadata are distinguishing features of
recent ontology repositories. Such metadata ranges from
authorship, and creation date, version information, to evaluation
and usage reports. Other metadata may include intended use (context).
(1B1J)
Modularization support is useful for large ontologies, and for
facilitating reuse and mapping of portions of ontologies.
(1B1K)
In a distributed setting, ontology repository developers increasingly
are adopting Service Oriented Architectures (SOA),
providing access, search, etc. capabilities via web services.
Two major approaches to SOA are REST and SOAP.
REST is built on HTTP, with a small
set of operators (GET, PUT, POST, DELETE) and the use of
URL (or URI) addresses for all objects of interest. SOAP
is based on XML RPCs. REST is much simpler to implement
and should be adequate for typical ontology repository functions.
SOAP is supported by a wide variety of software tools.
Both SOA approaches are currently being used.
(1B1L)
Finally, an ontology repository typically facilitates
access to a variety of ontology related tools:
creation, editors, pretty printers, visualization tools,
differencing tools, modularization tools, import / export,
version management, access control, inference engines,
explanation, summarization.
(1B1M)
Version 2.0, April 29, 2008
(1B1N)
