## 6 Converting from a Relational Database to the Ontology  
Geospatial data is typically stored in relational databases, which contain many records. In order to use the ontology in real world situations, it should be possible and straightforward to automatically transfer the data from the databases to the ontology.  
According to LBCS implementation guidelines, geospatial databases containing the LBCS classifications should associate each parcel with category codes for each of the dimensions [32]. To populate the ontology with this data, one individual of the Parcel type should be created for each parcel in the database, and then the properties should be asserted with individuals (punned classes) from the LBCS ontology. Each parcel should be represented by an individual like the one shown in Figure 5.  
Note that it is not necessary (or advisable) to transfer all the information contained in the geospatial database. The aim is for the ontology to supplement the database, not replace it. For example, it may not be wise to transfer the geometric data, since it is usually very large and no benefit can be gained from this as OWL reasoners cannot deal with this type of information. It should be remembered that each Parcel individual contains some identifiers referring to the corresponding geometric representation contained in another data repository and this is sufficient to maintain the relationship between the ontology and the geospatial database.  
Very simple reasoning can be used to obtain the individual corresponding to each LBCS category. Supposing that the user wanted to obtain the individual corresponding to the code C and dimension D, this could be done by querying the ontology for the members (one only, in fact) of the anonymous class \"D and hasLBCSCode value C\", as shown in Figure 6. Other methods that do not use reasoning can also be easily developed, in order to keep the computational complexity to a minimum. As previously stated, OWL uses the Open World Assumption, and therefore to use universal and some cardinality restrictions, it is necessary to \"close\" the world. This can be achieved when transferring  
Figure 5: Links between the GIS_Parcel and LBCS ontologies. The link between the GIS_Parcel ontology and LBCS ontology through 5 OWL object properties classifies parcels using the LBCS taxonomy. The datatype property hasShapeIdentifier links the Parcel with the respective ShapeFile by a unique identifier.  
data from the database to the ontology by stating in each individual the number of asserted categories (cardinality) in each dimension, as can be seen in Figure 7.  
As previously described in Section 5.4, the ontology can also be populated with data from databases that use other land use classification systems. The instantiation of the classes representing the other classification system categories can be easily achieved if each of these categories has an identifier that is used in the land use database. If this is the case, it is only a matter of creating an individual for each parcel in the database, with the types of that individual being the classes corresponding to the codes that are present in the database entry. All the procedures described in this section can easily be implemented by using, for example, the functions offered by OWL API or other RDF libraries or tools. These methods can also be used to transfer information from the popular Esri Shapefile format, by considering each polygon/line/point a parcel and extracting the land use categories from the attributes of each item.