To address the problems of both structured coordination of linked and modularised ontologies and to query a large dynamic ontology system, we propose a basic granularity framework and a set of functions to query such a granulated system. The granularity framework enforces a constrained and structured modularization. This facilitates automation of both dividing a large body of represented information as well as relinking the pieces. The functions enable basic cross-granular querying in a transparent and scalable way, as they rely on the unambiguous management layer provided by the granularity framework, and are reusable for ontologies represented and stored in di erent formats.
Modularization of ontologies and modularization of the subject domain to have
di erent ontologies require, to some extent, di erent methodologies and
technologies to address successfully. Tried and tested approaches are, for instance,
manual modularization of conceptual data models as is customary in software
development with UML Packages [
In the remainder of the paper, we rst introduce a motivating example in section 2, after which we introduce a basic granularity framework in section 3. In section 4 we introduce the set of functions to perform granular queries over the to be loosely linked and coordinated ontologies at di erent levels of granularity. We close with conclusions and future work in section 5. 2
Early attempts to group and coordinate bio-ontologies and related medical
information systems focussed primarily on identifying which perspectives one can
take on the chosen subject domain, which levels of granularity one can identify,
and how many of them would be practically useful [4{6]. The largest and most
ambitious e ort to date is OBO Foundry's approach to coordinated evolution
of ontologies [
B 1 2 λ λ
v s 3 o t λ c n a r e r g th 1 λ λ3 λ5 ouF ,)p
s a b C S
g gy gy l
o n eb (s th R O O c
n s ,n sa ce en eu
o s ta iego fto )i le
O G S
= R tw
A an ton o t i
t fo re is e e ega ta e gu it
h n re t i o l h b n A o a d t s om fo A
n d h o
l N m e R
C o =
M .R = la aO
O n n
; d i a (
R io R A ta ,y C d g
o n l u o R sn o t
F n c e ) 7 r l
v e re
M o d gn bb F r
O n =
i A e
t h ta a ce .
A ,e P
p = d r n y h i O it l
o w s
w T O d ra ll R
d e P log ,) ]; t n m gy e o u o s feo l(co ton
l l e b v ta itc i n
( t y e e r p o edf 1 o
t d s r t
C ,n
t P ca rk re L a
C m
r i d d o a , n n ew )) m 2 re In O ( a i( O s G v f e ra ; i
p r . la s s l
a 1 u a re
l ig ra c a .g o io F g su in rg (e iB B g c o te
o ts f e y t
o
I l 1 n g R i
o P a n c h Q1: \What are the cell components of blood?", which can be decomposed into smaller tasks where Blood resides in another level as the cells it has as parts Q2: \which organs have macrophages?", i.e. for each macrophage (and its subclasses in the Cell-level), which organ (or its subclasses in the Organ-level) are they part of? Q3: \Which hormones are located in the kidney, and where in the kidney?" This query uses three di erent perspectives, being a structural one for Kidney (an organ) with its parts, one for location (a spatial perspective), and a functional one for Hormone (a molecule with a speci c function).
That is, we need ways to select and retrieve entities, levels, and perspectives, and combine such queries into more complext ones. 3
Basic granularity framework for relating the ontologies
To enhance coordination of the modules that contain the ontologies or sections
of an ontology at di erent levels of granularity, we introduce a simpli ed, yet
e ective, granularity framework. A comprehensive theory of granularity with
de nitions, constraints, and proofs|i.e., with model-theoretic semantics|is
presented in [
De nition 1 (Granularity framework G) A granularity framework is a
tuple = f ; ; ; ; ; ; RE ; RL; RC ; RG; uses g where
{ is the domain, that can be divided up into a particular subject domain s
and the encompassing granularity frame f that contains the other elements
of the granularity framework;
{ denotes granular perspective (granulation hierarchy), where its instances
are denoted with 1; : : : ; n;
{ denotes granular level, where its instances are denoted with 1; : : : ; n;
{ is the granulation criterion (a combination of at least two properties) by
which one granulates a particular perspective, where its instances are denoted
with 1; : : : ; m;
{ is a type of granularity from the taxonomy of types of granularity [
Salient constraints are that each perspective must have at least two levels, a
level must be contained in exactly one perspective (8x( (x) ! 9!yRE (x; y))),
that the multiplicity (cardinality) for RL is 1:1, and a perspective can be
identi ed by the combination of the criterion and type of granularity it adheres to
(8x( (x) ! 9!y; (RC (x; y) ^ RG(x; ))) where is a shorthand for any of the
eight types of granularity). The components of G enable one to represent
explicitly the distinction between, e.g., an is-a taxonomy of structural body parts
versus a partonomy of body parts (`is-a vs. part-of' is dealt with by and
and the `human structural anatomy' by and ), and to manage various
distinct perspectives within one domain. There are three perspective depicted in
Fig.1-B, each with at least three levels. As levels for the partonomic granular
perspective for humans, we have in Fig.1-B, e.g., 2 = Organ in 1, where its
contents are provided by the FMA by means of selecting the Organ entity type as
root and recursively querying for the taxonomic subtypes of organ (about 3000
entity types). The molecule levels in the three perspectives, on the other hand,
are not well covered by the FMA, therefore this gap is lled by other ontologies,
such as PRO and ChEBI in 5 in Fig.1-B. That is, the contents at each level
are intended to be (or assumed to be) complimentary to one another, where
the G provides the machinery for a structured coordination and linking; hence,
one knows what is linked where and how, which then is, at least in theory, easy
to generate again when an ontology is developed independently and at certain
time intervals updated and re-connected. Likewise, adding a new level lled with
another ontology can be done transparently and non-disruptive for the other
perspectives and levels. Thus, we have four principal components for a granulated
information system: the types of granularity [
The next step is cross-ontology reasoning over such ontologies linked by
granularity, which already has been noted as a requirement [
Set of perspectives in a domain granularity framework i.e., 1; : : : ; n 2 P Set of levels in a domain granularity framework, i.e., 1; : : : ; m 2 DL Set of levels i; : : : ; k (i; k m, i 6= k) of a particular i Selected level i, output of the function selectL Set of selected levels, output of the function selectLs Set of selected levels, output of the function selectDL Collection of universals residing in a particular level i
Intersection of the contents of two levels i and j (with i 6= j) Selection of one level. Selecting a level within a perspective is a four-step process: retrieve the desired perspective, select a perspective, retrieve the levels in the selected perspective, and then select the desired level; subscripts denote what is selected.
F1. Goal: retrieve all granular perspectives 1; : : : ; n contained in the domain granularity framework df . Input is a df and output is an unordered set of perspectives of that domain, P . Speci cation: getP : f 7! P (F.1) F2. Goal: select a granular perspective i from the perspectives retrieved with getP . Input is the set of perspectives of the domain, P, output is a set with one perspective i 2 P. Speci cation: selectP = i : P 7! P (F.2) F3. Goal: retrieve all granular levels 1; : : : ; n contained in the selected perspective i. Input is a i 2 P and output is an ordered set of levels of that perspective, L. Speci cation: getL : P 7! L (F.3) F4. Goal: select a particular granular level i from the levels retrieved with the getL function. Input is the set of levels of the perspective, L, output is a set, li, with a single element from L. Speci cation: selectL = i : L 7! L (F.4) Although one could choose to add a function to select a level from DL (all speci ed levels) only, this is prone to user-mistakes, the above four functions can more easily be reused for other selection and retrieval functions, and they can be abstracted into one compound user-interface operation anyway.
To select the Cell-level as declared in Fig.1-B for query Q2, one uses getP to retrieve f 1; 2; 3g, selectP = 1 to obtain the human structural anatomy perspective, and with getL the levels of that perspective (f 1; : : : ; 5g), and, last, selectL = 3 for the Cell-level. The same procedure can be used for selecting the Organ-level, but with the last step being selectL = 2 .
Selection of multiple levels. Two options to select multiple levels are distinguished: 1) selecting several levels to subsequently retrieve and combine its contents for further processing, and 2) conditional selection that considers the contents as well. Option 1 can be subdivided into two similar operations: selecting more than one level from one perspective and selecting levels from di erent perspectives. Both can be accomplished with a sequence of sub-functions. In addition to those introduced in the previous section, we have: F5. Goal: select 1 granular levels contained in one granular perspective. Input is set of levels L retrieved with getL, output is a set of selected levels lsi from L such that lsi L holds. Speci cation: selectLsV i : L 7! L (F.5) F6. Goal: perform a selection of 1 levels from 1 perspectives. Input is the set of perspectives, P, and for each perspective the set of levels, L, from which one selects, and output is a set of levels contained in df , DL, denoted with lssi, where lssi DL. Speci cation: selectDLV i V i : P L 7! DL (F.6) Thus, selectL is extended for multi-level selection within one perspective, using the binary operator ^ to select multiple levels, which has been written in shorthand notation, V, such that V i = 1 ^ ::: ^ k where i contains j levels, k j, and RE ( i; i). Note that lsi is not a proper subset of L because it is possible that a user wants to select all levels in the chosen perspective. The 1-level selection is a special case of the multi-level one, but labelled di erently to avoid overloading terms.
For selection of more than one level from more than one perspective, selectLs
cannot be extended to selecting levels from multiple perspectives, because one
has to nest selection of at least one other perspective and have some way to
distinguish levels belonging to di erent perspectives. A mapping of (F.6) to a
formal notation and implementation algorithm can be achieved with a loop in
two near-equivalent ways: either to select all desired perspectives and
subsequently one or more levels for each selected perspective, or repeat the two-step
process of selecting a perspective & retrieve levels and then selecting levels.
Retrieving the contents of a level. Retrieving the contents of a
particular granular level is conceptually straightforward with a getC function, but
this hides many details, in particular the need to use the structure of the level's
contents given the di erent types of granularity. This is elaborated on afterward.
F7. Goal: retrieve the contents, i.e., entity types and their relations, of a selected
granular level i. Input is the selected level, where i 2 L and output is a set of
predicates, E 2 E , that takes into account the structure of the contents in the
level. Speci cation: getC : L 7! E (F.7)
F8. Goal: intersect the retrieved contents of selected granular levels i; j (with
RE ( i; i), RE ( j ; j ), and i 6= j). Input are the contents of the selected levels
Ei and Ej (obtained with getC for each level), and output is the intersection,
set I 2 I, where I E . Speci cation: intersect : L L 7! I (F.8)
getC takes a particular granular level as argument and returns the contents of
that granular level, irrespective of how the contents themselves may be structured.
Without having represented explicitly which type of granularity is used for the
perspective and levels, one cannot know this other than manually hardcoding
this information, which is laborious and error-prone. However, if we have, for
instance, two granular perspectives that both devise the levels where entity types
in ner-grained levels are always part of those residing in coarser levels and for
both hierarchies the contents is a taxonomy, such as types of organs and types
of molecular processes, then the mechanism of granulation is the same (just
applied to di erent subject domain information). One can exploit this sameness
in approach of granulation by identifying each principal granulation mechanism
and relate the mechanism to the levels and perspectives, so that one has to
de ne only once how the contents of a level should be retrieved. For the types
of organs and types of molecular processes, this amounts to a straight-forward
recursive query. To achieve this e ciency, we can reuse the taxonomy of types
of granularity [
Once the content is retrieved, it can be used for further processing, such as intersecting contents of two levels. To this end, the intersect function (F.8) is introduced, which rst retrieves the contents of each level with getC and subsequently intersects them. For instance, to answer a query like \retrieve those molecules that are also hormones" we have, among others, the molecule Insulin in the molecule-level 5 of 1 in Fig.1-B but also in 3 of the function-perspective 2 where it is categorised as a hormone. Obviously, this can be scaled up to intersection of more than two levels.
Type selection to retrieve its levels. We introduce ve functions to achieve
unambiguous selection of types (universal/class/concept) from an ontology and
to query for the level(s) it resides in to simplify scalability and reusability.
F9. Goal: select a type from the ontology (subject domain). Input is a type,
C 2 ds, and the output of the selection ensures that the selected type resides in
some level i already, hence C 2 E. Speci cation: selectE : s 7! E (F.9)
F10. Goal: given a selected type C, retrieve the level i that C resides in. Input
is a type C 2 ds and output of the function is a level that is a subset of L.
Speci cation: grain : s 7! L (F.10)
F11. Goal: given a selected type C, retrieve all the levels 1; : : : ; j (in di erent
perspectives 1; : : : ; k, k = j) that C resides in. Input is a type C 2 ds, and
output of the function is a set of levels that is a subset of DL. Speci cation:
grains : s 7! DL (F.11)
F12. Goal: given multiple selected types C1; : : : ; Cn, retrieve their levels 1; : : : ;
j within one perspective i. Input are types C1; : : : ; Cn 2 ds, uses grain as
nested function, and output of the function is a set of levels within one
perspective (a subset of L). Speci cation: grainM : s 7! L (F.12)
F13. Goal: given multiple selected types C1; : : : ; Cn, retrieve their levels 1; : : : ;
j among multiple perspectives 1; : : : ; k. Input are types C1; : : : ; Cn 2 ds, uses
grains as nested function, and output of the function is a set of levels as subset
of DL. Speci cation: grainsM : s 7! DL (F.13)
The basic function to retrieve the level an entity resides in, is grain. Its neat
simplicity, however, does not su ce [
In a more complex subject domain than the OBO Foundry setting depicted
in Fig.1, such as human infectious diseases that could rely on the granulations of
the OBO Foundry, we then can retrieve all levels of, say, Cholera toxin, with the
grains function and retrieve f 2 9; 6 2g; that is, using the granulation from
[
Cross-granular queries and other functions. The functions (F.1-F.13)
introduced in the preceding subsections enable formulation of more complex
queries, such as Q1-Q3 in section 2. It is possible to de ne many more
functions for a granularity framework, also because, in principle, the same approach
could be taken for knowledge bases and, among others, ontology-enhanced Data
WareHouses (DWH) or modularized ontology-driven information systems. DWH
implementations in particular focus on querying the information system with
advanced queries. Functions for such queries can be easily added. For instance,
with P still the set of perspectives, and adding C as the set of criteria, then
crit : P 7! C enables us to retrieve the criterion of a granular perspective,
tgP : P 7! to retrieve the type of granularity of a perspective, and plain
functions to query the entity types and relations of the ontology proper are also
still possible [
Looking at prospects for immediate use, the functions obviously could be
hard-coded and pre-computed as is customary in bioinformatics, be it as
successive steps or also with additional compound queries. However, with the
granularity framework, one has a management structure in place so that (i) queries
can be executed that suits the user on-demand as opposed to being limited to
the imagination of the software developer, and (ii) F.1-F.13 are de ned in an
implementation-independent and a reusable way so that practicalities of a
software system can be hidden from the domain experts so as to avoid burdening
them to learn yet another query language, to re-write the whole query for each
permutation (e.g., macrophages in tissues), and to keep in mind which levels
there are whereas that can be added to the informationsystem now. At present,
Q1-Q3 can be performed by standard relational database management systems
(RDBMS), such as the FMA in PostgreSQL [
To address the problems of both structured coordination of linked and
modularised ontologies and to query a large dynamic ontology system like proposed
by the OBO Foundry, we proposed a basic granularity framework and a set of
functions to query such a very large granulated system. The granularity
framework enforces a constrained modularization so that dividing a large body of
represented information as well as re-linking the pieces is amenable to
automation. The proposed functions enhance cross-granular querying in transparent and
scalable way, because they rely on the unambiguous management layer provided
by the granularity framework, and are reusable for ontologies represented and
stored in di erent formats. We are currently working on transforming the theory
of granularity [