Biogeography [1] is a scientific discipline that studies the distribution of living beings on earth, as well as the processes that have originated it, that modify it and that can make it disappear. It is an interdisciplinary science, which is both a branch of geography and biology, receiving its foundations of specialties such as botany, zoology, ecology or evolutionary biology and other sciences such as geology. Currently there is a steadily growing wealth of biogeographic and biological data from a wide range of disciplines that being available from on-line information systems [2,3,4] around the world. In particular, as the number of species and geographic regions under study and also the participating institutions and research groups continue growing, addressing elaborate research issues about the complex interrelationships among these data becomes increasingly difficult. In the case that the information sources cannot be properly coordinated, data access and information discovery can sometimes become a daunting task. This drives the need to further facilitate the information integration across data sources, taking into account different querying interests in a diversity of fields and disciplines.
SNDB 2 supported by the Ministry of Science, Technology and Productive Innovation of Argentina and OBIS 3 supported by the Intergovernmental Oceanographic Commission of UNESCO, are currently two of main reference databases for ocean biologists, ecologists, and other researchers in Argentina. Both use Darwin Core Standard (DwC) [5] which is a general purpose vocabulary designed to facilitate the transfer and integration of biodiversity data. Though the DwC is defined in an RDF [6] document 4 , integration of biodiversity data in the Semantic Web (SW) [7] is in its early stages. One of the major challenges for DwC in the SW context is the lack of a well-defined ontology. Without rigorous relationships between concepts and the properties that define them, connections between biodiversity data and related semantically rich information, such as literature and genomes, are difficult to traverse [8,9,10,11].
To facilitate the integration of these two databases, we present the design of BioOnto, an ontology that enables the integration following the Single Ontology approaches which uses one global ontology providing a shared vocabulary for the specification of the semantics and all information sources are related to one global ontology. The choice of this approach is due to the fact that it is ratified for many years as demonstrated in [12] its implementation is successful in cases where the nature of the data is similar. In addition, BioOnto is designed to link data together with other systems compliant with the RDF which follows the principles established by Linked Open Data initiative (LOD) 5 .
The paper is organized as follows: Section 2 shows the state of art and the problems of integration that exist today. Section 3 describes the architecture, design considerations, and features of BioOnto. Section 4 presents a use case that demonstrates how the information from both data sets are integrated to better understand the behavior of a particular specie. Finally Section 5 presents the conclusions and the future work.
In this section we will review the work related to the integration of biodiversity and biogeography domain. The first work consulted is [13] developed by OBIS-ENV-DATA, which proposes an extension of DwC to expand OBIS with environmental data to effectively manage combined datasets, although this generates advantages in the incorporation of environmental data, still persists the integration problem which has the DwC standard itself. In MarineTLO [14] the authors defined a core ontology for publishing marine data concerning to the European iMarine project 6 , which is suitable for setting up warehouses that can serve complex queries. The main objective is to assemble information from different datasets to give more details of a particular marine species. However the DwC standard is not used to build the underlying ontology, limiting the possibility of integrating biodiversity data that respects the DwC standard. BiSciCol [15] describes an architecture to convert biodiversity data (in standard tabular formats) such as Darwin Core-Archives [16] into RDF representations. In this case an ontology is described using the terms of the DwC but there are no examples of inferences or queries that may be of help to researchers interested in integrating different databases; on the other hand, currently the project page is not accessible. We plan to use DwC standard to capture complex aspect of biodiversity domain. In [17] the authors describe RDF-based data structures that are to be employed in the creation of a centralized repository of metadata from the heterogeneous data sources in the RITMARE research network 7 . A different approach is taken in [18] where the authors propose the creation of micro-linked open data clouds formed by oceanographic LOD-compliant datasets. A number of ontology design patterns called GeoLink Modular Oceanography Ontology are designed in [19] for the Oceanography domain. The resulting patterns are sufficiently modular, and thus arguably easier to extend than foundational top-level ontologies. Currently, the GeoLink project is in the middle of populating the patterns with actual data and a very preliminary evaluation demonstrated that the patterns together can serve as an integrating layer of heterogeneous oceanographic data repositories.
Current research is trying to address the existing gap to integrate biological, oceanographic and biogeographic data. However, critical look at the available literature indicates that there are limitations related to: (1) the absence of robust, standardized, and widely-accepted vocabularies and ontologies for linkable biodiversity and biogeography data. ( 2) the disagreements presently governing the use of identifiers in biodiversity and biogeography data is a major impediment to integrate these data.
The proposed architecture, showed in Figure 1, is divided into three layers: (1) Input Data representing the databases OBIS and SNDB in which the data can be downloaded in CSV format, then this information is converted to RDF using OpenRefine tool [20] where data inside these files are cleaned and converted to standardized data types (dates, numerical values, etc.). Data are converted to RDF triples using RDF Refine8 , which is an extension of OpenRefine. The columns of the CSV file are mapped as instances of DwC classes. Every resource must have a URI that can be used to link that resource to other resources both within this dataset and others anywhere on the web. The base URI that is common to the main classes is: bio-onto:http://www.cenpat-conicet.gob.ar/ontology/. In the CSV file we have a column with unique identifier, "ID", to use as unique values in identity URIs. We use GREL (General Refine Expression Language9 ) to generate a new URI, the expression that we defined is "occurrence/"+value.urlify() this concatenates to the base URI the string "ocurrence/" along with the value of the ID, then a URI generated after applying the expression would look like this: bio-onto:occurrence/valueID. The resulting RDF to describe an occurrence is:
SUBJECT PREDICATE OBJECT bio -onto : occurrence / f6bbf85d -85 ea -4605 rdf : type dwc : Occurrence dwc: is an abbreviation for the real namespace http://rs.tdwg.org/dwc/terms/, Table 1 describes the mapping performed together with the columns of CSV file used to generate the main URIs. The complete mapping can be consulted at10 . (2) Global Ontology and Storage in which the RDF triples are stored in GraphDB 11 . This is a highly efficient and robust graph database with OWL inferences and SPARQL [21] support. Then the users can access the data resources easily using the different visualizations provided by GraphDB12 . (3) Information Retrieval which provides a transparent interface to the non-expert user, so that they can perform queries without needing to know details of the SPARQL query language.
Figure 1. Proposed Architecture: the data of both datasets are converted to RDF, then the mapping corresponding to the classes defined in the ontology is performed. Finally the data can be queried through SPARQL queries.
The development of the ontology is initiated within CENPAT 13 . The different research lines at CENPAT include marine biology, aquatic resource management, oceanography, paleontology, and biological diversity, among others. A working group at CENPAT is focused on working with issues related to the management and conservation of marine resources, this research group called CESIMAR acronym for (Center for the Study of Marine Systems) have a long tradition on studying the biology and behavior of marine mammals. Because most of the research done generates a large volume of data, but depending on its nature, they are published in SNDB (if they are biological data) or OBIS (if they are biogeographic data). Up to date there has not been developed a tool which allows integrating both databases. For example it is of great interest to know which species coexist in a certain marine region, or to establish trophic relations between marine mammals. After several interviews with the domain-experts, the key targets of the ontology model are specified to: (1) Establish marine regions, determined by maximum and minimum latitudes. (2) Establish which species of marine mammals are prey or predator and (3) Determine which species coexist in the economic areas pertaining to Argentina, in particular to see whether the commercial fishing does alter the ecological balance of the sea species.
Regarding to the methodological strategy of our approach, we keep in line with the tradition that considers ontology as an engineering artifact that is useful to model some aspects of the world. That is why we adopted the methodology defined in [22]. The main stages are: (1) Analysis: We planned to use the ontology first with the DwC classes, we decided to first try and represent these objects as concepts and then see if some concepts were lacking or inadequate and eventually adjust the structure. (2) Building the ontology: The building process is iterative. Basically it can be broken down: finding conditions to constrain the concepts, introducing the properties and/or concepts needed to build the conditions and building the subsumption hierarchies of concepts and prop-erties. (3) Evaluation: For the evaluation we take into account two important aspects highlighted in [23], consistency of the ontology since an inconsistent ontology would yield questionable results, this task is performed using Ontology Debugger14 a plugin for Protégé and Pellet reasoner 15 , we test the consistency after each set of changes we make, even if the changes are supposed to be simple. Another factor to evaluate is the complexity, one way to evaluate this is to ask the reasoner to classify the ontology. If this test takes too much time, it is likely that the ontology will not be usable in real conditions. If such is the case, corrections are to be made. Since usually the ontology size cannot be reduced, the general idea is to write simpler restrictions on properties. This means using a less complicated logic if possible. For instance, using existential restrictions instead of qualified cardinality restrictions helps keeping the complexity lower for the reasoner. (4) Maintenance: After complexity test is performed with adequate performance, we check the ontology's performance in real use. This is done by testing the applications exploiting the ontology and evaluating the performance, both in terms of execution speed and results quality. The analysis of the results help us fine tune the ontology to our exact needs.
At this point we might think that the integration of both databases is solved since both are converted to RDF, their integration should be simple given that a URI can indicate what kind of entity it identifies. But this is not enough, it is necessary to impose a layer of computationally tractable meaning, where the relationships that hold between them can be accurately interpreted and used in an automated way. For example, establishing relationships between instances of classes through an inverse property, defining cardinality restrictions or establish subsumption relationships. Description Logics (DL) [24] is an adequate means of representing ontologies. Furthermore, OWL is based on DL, so we decided to describe our ontology using DL and to implement it in OWL-DL [25]. Both of these flavors are well-supported by existing reasoners and is particularly suitable for the type of reasoning we intend to perform at this stage of the work. BioOnto is based primarily on the DwC classes and terms, but also classes and properties defined by domain experts.
As we mentioned earlier DwC [5] is a body of standards for biodiversity informatics. It provides stable terms and vocabularies for sharing biodiversity data. DwC is maintained by TDWG 16 (Biodiversity Information Standards, formerly The International Working Group on Taxonomic Databases). These terms are organized into nine categories (often referred to as classes), six of which cover broad aspects of the biodiversity domain. Occurrence refers to existence of an organism at a particular place at a particular time, Location is the place where the organism were observed (normally a geographical region or place), the Event class is the relationship between Occurrence and Location this registers sampling protocols and methods, dates, time and field notes, Taxon refers to scientific names, vernacular names, etc. of the organism observed. The remaining categories cover relationships to other resources, measurements, and generic information about records which in our case are not used. Specifically for the record level, DwC recommends the use of a number of terms from Dublin Core17 .
The main classes of the ontology are taken from the vocabulary specified in DwC, as well as some of classes and properties therein. The BioOnto structure and properties assigned to its classes provide a series of useful reasoning tasks that can be formed by SPARQL queries (see Section 4 for examples). The general model of BioOnto can be seen in Figure 2. The class hierarchy of the OWL ontology consists of seven key classes: Occurrence represents instances where the presence of an organism at a Location is observed. It functions primarily as a node that connects Taxon to Events. Location is a spatial region or named place. For DwC, a set of terms describing a place, whether named or not. Event functions primarily as a node to connect one or more Occurrences to an Event, and one or more Events at a Location. Taxon represents a unit of biodiversity e.g. species, genus, family, etc. Agent foaf:Agent class is imported directly into BioOnto. An agent (e.g. person, group, software or physical artifact). Region is an area of the ocean delimited by a latitude and longitude. Dataset is an identification of the data set belonging to OBIS or SNDB. BioOnto defines a number of properties used to link classes (see Table 2), and also reuses some properties of some commonly used terms like Basic Geo Vocabulary (WGS84 lat/long 18 ) and FOAF 19 . In this way BioOnto accrues most of the scientific and technical vocabulary required to achieve a semantic understanding of the most commonly used terms in biogeography and biodiversity, the ontology in OWL can be seen in 20 .
Table 2. Object properties that link the main classes in the BioOnto model. Some properties like is predator of has an inverse property linked by an owl:inverseOf relationship. For each property, the intended subject class is declared the rdfs:domain of the term and the intended object class is declared the rdfs:range of the term.
This section develops use cases that are relevant to researchers dedicated to the conservation of the marine species and the study of animal behavior. One of the most common problems faced by the scientists is to determine which species coexist in the Argentinean Exclusive Economic Zone (AEEZ 21 ). One of the species that is of particular interest to scientists in the Argentine sea littoral is Mirounga Leonina or (Southern Elephant Seal), because of the relevant information that provides with respect to the sea. For this reason, Mirounga Leonina are used as oceanographic sampling platforms [26], they are ideal carriers of electronic devices that register parameters like salinity, position, depth and temperature, providing huge amounts of information associated with the key habitats.
The data collected by different individuals during their migration is captured by these devices, and are available in OBIS. In some cases, new biodiversity related knowledge may be discovered by the scientists using SNDB, (e.g. determine which fish species live in the same region than the elephant seals). This information may not exist in OBIS records, and therefore it is highly desirable to be able to integrate this information from SNDB in a transparent way. The following subsections show examples where the axioms that were defined in the ontology to enable them to answer these questions.
Scientists recently discovered that a large percentage of Southern Elephant Seal feeding is the Lanternfish [27]. Then it is possible to define axioms in OWL to establish the relationship predator/prey, a knowledge that was only implicit in the ontology. Using rolification and the chain axiom property it can be expressed the above inference in OWL with the following three axioms expressed in Manchester OWL [28] syntax:
(1) R_Elephant some Self (2) R_Lanternfish some Self Where R Elephant and R LanternFish are object properties, and it is required to add atoms of the form U(t,u), where U is the universal property, (i.e., owl:topObjectProperty). In this way after executing the reasoner, all instances of the class ElephantSeal will be related through the property is predator of with all instances of the class LanternFish. This approach was taken from [29] where instead of using SWRL to define rules, we use OWL axioms.
To determine the species that inhabit the AEEZ, we can use (since the data are georeferenced by latitude and longitude) axioms OWL to infer that a certain specie is present in the AEEZ, for this we use the object property into eez and the following axioms expressed in Manchester OWL syntax.
FILTER regex ( STR (? class ) , " Mammalia " ) }
In this section we show examples that respond to the questions raised by researchers studying animal behavior. In the case of predator/prey relations is interesting because it allows to determine by reasoning, the species that are part of the food chain obtaining the species of OBIS and SNDB. In addition to this reasoning, we can determine when a species is considered a top predator, if it is not prey to any other species. Regarding to the marine regions, we offer the possibility that the user can define a specific marine region to perform some type of analysis. Reasoning allows to identify the species that were observed there and determine, for example if the existence of a specie in that region is due to the fact that it is feeding from another one.
We have presented the initial steps performed in the ontology design called BioOnto developed with researchers from CENPAT. The proposed model enables interoperability and a common knowledge representation among databases SNDB and OBIS, allowing the retrieval of information that cannot be gathered by any of the individual information sources alone. Specifically, we presented the preliminary results of the ontology that (1) allows establishing predator/prey relationships between marine species, (2) define marine geographic regions and determine what species live there.
We are currently working on the integration of other databases (e.g. FishBase23 ) which are required in research tasks within the CENPAT to answer questions about the balance of species and their relationship with commercial fishing.
We know that this databases could be integrated into the input data layer since the proposed architecture is flexible to integrate data in structured or semi-structured format. Furthermore in future works we will consider to link our ontology with relevant marine ontologies 24 .
Any instance of the Location class that is within the maximum and minimum values of latitude and longitude, will be related by the property into eez with an instance of ArgentineanEEZ class called AEEZ which represents the exclusive economic zone of Argentina.
This section shows an example of simple SPARQL queries that allow to explore the data of both datasets, in particular we will make use of the information associated to the species as well as to their location. The following query allows to retrieve the location of all mammals containing the two datasets. This particular query is important because it allows in the future to work with interfaces that allow the visualization of georeferenced data. To run this query through the SPARQL interface of GraphDB, see 22