as both an object relation and a data relation. How-
ever due to equivalences in relation purpose these re-
lations were not migrated to the DCO variants which
provided benefit in scoring as the error was no longer
present. Goal 5 (Table 11) is based on components
where again we see little difference with the only be-
ing no domain specific content in the DCO Survey
Ontology.
With success demonstrated using the traditional
FOCA method we consider the structural numbers of
each ontology and contrast them with our criteria for
choosing an ontology which will be outlined below.
This is the criteria that was used when choosing a
foundational ontology to base the DCO on.
The first criteria we want to define is based on the
number of terms and relations in the ontology, where
we prefer to have fewer of each for two main reasons.
Firstly, upper level ontologies are meant to be derived
into a domain level ontology and thus will have more
terms and relations added over time and large ontolo-
gies introduce performance penalties potentially re-
sulting in an ontology that is intractable for a reasoner
(Horrocks, 2005). Secondly, in terms of understand-
ability, the fewer terms a person must know to use an
ontology the easier it is to get started. Additionally,
it will reduce reliance on documentation and expert
knowledge making it easier to design and organize
derived ontologies. Furthermore large ontologies may
deter usage of the ontology altogether.
The second criteria we care about is usage and
popularity. Popularity of an upper level ontology is
important when considering its purpose for unifying
ontologies (Herre, 2010). We want to look at what
people are using to see what is working and how many
domains are being captured by the upper level ontol-
ogy. If only one domain is using a particular ontology
it is possible that it has not met the needs of others.
Additionally greater popularity increases the likeli-
hood that ontology developers will have experience
with the ontology.
Finally, we move on to a more formal definition
for upper level ontologies which is used for the pur-
pose of ensuring that the base is kept generic, again
to satisfy our definition. Thus we say an upper level
ontology must be free from any domain specific terms
or relations. We are not interested in ontologies that
take the role of defining thousands of terms to satisfy
a large number of domains since it is unlikely such an
ontology could satisfy each domain realistically.
Starting with the first criteria we compared on-
tology sizes. The sizes are summarized in Table 6.
As one would expect the class count is larger in both
versions of the DCO based Survey Ontology variants,
however, what is noted is that in both derived forms
the number of relations were dramatically reduced.
Therefore when looking at both classes and relations
the size difference is insignificant. This means any
implementation is not too large by our standards and
this is because when the world of ontologies is consid-
ered as a whole, ontologies with thousands of classes
are not uncommon making a difference in size of 70
relatively small and unlikely to deter ontology devel-
opers.
When looking at relations one can see the dra-
matic effect reuse makes. For object relations the De-
rived Survey Ontology added only 25 of the 41 rela-
tions defined in the Survey Ontology. The other rela-
tions had equivalents that already existed in the DCO.
Similarly, the Derived Survey Ontology adds only 21
of the 26 data properties again using equivalents de-
clared in the DCO. Therefore in terms of growth the
DCO maintains a small number of relations through
reuse of major data collection requirements such as
time, units, and data structures.
Our second criteria involves looking at domain
specific content. We note that the Survey Ontology in-
cludes domain specific content as of this writing but
we acknowledge that it is not tied into the structure
of the ontology and could be removed without major
refactoring. Therefore, we will not dive deeply into
this criteria as it is not something the DCO will af-
fect.
Lastly, is usage and popularity. Both ontologies
are in their infancy, however, the DCO’s base provides
familiarity since any OBO user or developer is already
familiar with our design to an extent. An OBO user
would already know of the basic design, classes, and
how the ontology is structured since it based on the
BFO. To use the DCO they would only need to learn
about Subjects, Classifiers, and Datums. We argue
this provides significant benefit in terms of usage and
popularity since the core of the ontology is well es-
tablished. The Survey Ontology does not have this
advantage since it uses no base ontology and defines
terms exclusively in its own hierarchy. This would
mean developers would need to completely learn the
structure before use.
4.1 FOCA Evaluation Table Notation
Defined
Here are some brief definitions for table components
so one can more easily navigate the results. Ma-
jor differences between versions are bolded to show
changes across the variants. All Justifications are pre-
sented in the same order as the score columns mean-
ing the first justification for a question refers to the
Survey Ontology while the last justification refers