A Land Use Planning Ontology: LBCS

Abstract

Urban planning has a considerable impact on the economic performance of cities and on the quality of life of their populations. Efficiency at this level has been hampered by the lack of integrated tools to adequately describe urban space in order to formulate appropriate design solutions. This paper describes an ontology called LBCS-OWL2 specifically developed to overcome this flaw, based on the Land Based Classification Standards (LBCS), a comprehensive and detailed land use standard to describe the different dimensions of urban space. The goal is to provide semantic and computer-readable land use descriptions of geo-referenced spatial data. This will help to make programming strategies available to those involved in the urban development process. There are several advantages to transferring a land use standard to an OWL2 land use ontology: it is modular, it can be shared and reused, it can be extended and data consistency maintained, and it is ready for integration, thereby supporting the interoperability of different urban planning applications. This standard is used as a basic structure for the “City Information Modelling” (CIM) model developed within a larger research project called City Induction, which aims to develop a tool for urban planning and design.

1. Introduction

Any territory has potential that must be recognised and used for the benefit of its population. Through adequate spatial planning, it is possible to prevent the waste of territorial resources whilst maximising satisfaction of the population’s needs. Planning therefore plays a key role in spatial and social organisation [1].

Urban and regional planners usually develop long and short term plans to guarantee efficient management of land use and to promote the growth and revitalisation of urban, suburban, and rural communities. Before making plans for the development of these communities, planners study and report on the existing land use for business, residential, and community purposes. One of the core goals of the City Information Modelling (CIM) model [2] developed within the City Induction project [3] is to provide a tool for manipulating land use knowledge to benefit such plans. The City Induction project aims to design and build a tool to assist the urban development process. It is targeted at district planning and the goal is to promote the generation of more sustainable urban environments. In order to achieve these goals, the tool should be able to access information about the site context and assist in the elaboration of an intervention programme, as well as in the development and assessment of design solutions that meet the programme requirements.

It is important to have reliable and up-to-date geo-referenced information, firstly, in order to identify the requirements of the plan, and subsequently to establish appropriate recommendations. The CIM is intended as a standard for developing computable representations of the physical and functional characteristics of the urban environment which will serve as a repository of information for urban planners and designers to use throughout the urban development process.

Many classification systems are used in land use planning. Land use standards are usually developed and modelled by geographic institutes regulated by the state to deal with the specific character of the territory and regional policy norms. There are also significant differences between the variety of standards available.

The Land Based Classification Standards (LBCS) model was developed by the American Planning Association [4] and was the system adopted by the City Induction project due to its unique capacity for spatial representation. LBCS provides a cutting-edge land classification with the following qualities: (a) precise classification, due to its multi-dimensional character, describing space according to five different, complementary dimensions—function, activity, structure, site development and property rights; (b) the fact that it is independent of spatial units of measurement (parcels, buildings, etc.); and (c) flexibility in terms of detail, due to its hierarchical nature. Basically, LBCS represents a way of organising the terminology used for classifying land use and therefore does not depend on having a relational or any other form of database, but typically is implemented within a relational database of geo-referenced spatial units. The American Planning Association provides some relational models in the implementation section of the LBCS site [4].

In recent years, society has been witnessing the development of the next generation Internet. The Semantic Web [5] is an extension of the current web which, whilst preserving valuable web characteristics, introduces interesting new features: it is open and decentralised and uses new technology to make data on the web machine-interpretable based on a powerful mechanism, namely inference. Knowledge in the Semantic Web is represented by ontologies, which are semantic formal models that describe relevant concepts, as well as the relationships and the constraints between them. The inference mechanism of the ontology, as well as the open characteristics of the Web, are strong enough arguments to motivate and justify the design of an ontology for any land use classification standard and in particular, the design of a LBCS ontology for the Semantic Web. It is modular and can be easily extended, it can be shared and reused, information can be inferred and data consistency maintained, and it is ready for integration, thereby fostering interoperability between distributed urban knowledge and different applications.

This article describes the development of the LBCS-OWL2 ontology using the Protégé ontology authoring tool [6], and how it can be used for classifying georeferenced spatial units that are stored in a shapefile, for instance. The Web Ontology Language (OWL) is the W3C standard language for modelling ontologies in the Semantic Web. OWL2 [7] is an extension of the first OWL version and contains several new features, some of which are used in this research, such as punning meta-modelling. Punning techniques are described in Section 4.1. The ontology design issues in question are not specific to the LBCS but can serve as useful guidelines for the development of an OWL ontology for any other land use classification standard, particularly if it has a hierarchical structure similar to the LBCS.

The article is organised as follows: related work is discussed in Section 2; the LBCS land use standard is described in Section 3; Section 4 is dedicated to the presentation of LBCS-OWL2, which constitutes the backbone of the CIM, enabling semantic and computer-readable descriptions of geo-referenced spatial data to be developed; Section 5 exemplifies the use of the LBCS-OWL ontology, together with an illustration of the inference and querying capabilities provided by OWL2 formal semantics; Section 6 describes how data can be transferred from LBCS relational databases, or from other land use systems such as the NLUD standard, to the LBCS ontology proposed here; and Section 7 and Section 8 summarise the results and present the conclusion.

A shorter version of this paper was initially published in [8].

2. Related Work

The use of ontologies has been a hot topic for researchers involved in the development of computational tools for urban planning, mostly due to their capacity to externalise, share, integrate, and reuse urban planning knowledge. The recent interest in ontologies in the field of urban planning derives partly from the increasing relevance of communication, negotiation, and argumentation in decision-making processes [9,10]. Urban planning has evolved from a rationalistic model to a transactional model in which public participation, multi-stakeholder partnerships and strategic planning have become a byword. Ontologies can thus be seen as a way of responding to the difficulties that arise out of these new models, enabling them to become inter-operative across systems and people [10,11,12,13,14]. At present, several research groups are developing work in the field of urban ontologies, some of the most relevant of which are listed below.

2.1. HarmonISA

The main goal of the HarmonISA research project [15,16] is the automatic semantic integration of land use and land cover data for the three regions of Friuli Venezia-Giulia (Italy), Slovenia, and Carinthia (Austria). Some OWL ontologies were created corresponding to different land cover classification systems in Italy (Moland), Slovenia (Slovenia CORINE) and Austria (Realraumanalyse). Two other OWL ontologies were also developed, one for the USA Anderson system and the other for the EU CORINE system. These classification systems are better suited to land cover than land use and are prepared for classifying data derived from aerial photography. The land use and land cover concepts are closely related and sometimes interchangeable, but the classification systems that were harmonised are, in fact, designed for land cover.

2.2. COST C21 Action

The main objective of the European COST C21 [10] Action, known informally as “Towntology” [12], which brings together a large group of experts from across Europe, is to “increase knowledge of and promote the use of ontologies in the domain of urban development, with a view to facilitating communications between information systems, stakeholders, and urban experts at European level” [17]. The research work of this group is mainly guided by the assumption that urban practice is inherently based on shared conceptualisations, even though these may be implicit. These conceptualisations can be regarded as ontologies although they remain in the pre-formalisation stage. They are also known as pre-ontologies. The work of the COST C21 is to reveal such underlying ontologies, understand how they are constructed by actors, and propose appropriate methods of formalising and using them [17]. The research was progressively reframed to address three main questions: (1) How can ontologies support urban interoperability at all levels (both between systems and people)? (2) Which sources can be used to initiate, populate, and maintain urban ontologies? (3) What are the potential applications of ontologies in the urban domain?

The present limitations of CityGML [18] in terms of supporting high-level interoperability between different urban applications are discussed within the context of COST C21. It has been suggested that 3D representations may play a central role in communications between decision-makers and the population when complemented with higher level urban ontologies interconnecting urban information. CityGML has been successfully integrated with OSM, a soft-mobility ontology, and with OTN, an Ontology of Transportation Networks [19], both developed in OWL. OSM can supplement the soft-mobility aspects lacking in OTN and CityGM was useful for visualisation and communication.

2.3. Other Research

There are also cases of interoperability in the fields of archaeology [20] and air quality [21]. In addition, ontologies have been used as a way of supporting communication between experts and the lay public via the elaboration of a shared understanding of given concepts [22]. Outside deliberative practices, there has been some research into the automatic extraction and indexation of concepts from reference sources, which can be an alternative and efficient way of rapidly developing and populating urban ontologies [23,24].

3. The Land Based Classification Standards (LBCS)

Land use is typically studied by geographers and urban planners, and refers to how the land is being used by humans. In urban development processes it is important to know what can be achieved by using land use to plan the space where people live. However, there is a recurring misconception. Land use planning is sometimes interpreted as a process whereby planners tell people what to do, whereas in fact the objective of land use planning is to make a systematic assessment of the physical, social, and economic factors to assist land users and planners in selecting the best sustainable options to meet society’s needs. The importance of this has created the need to explain the classification standards used in the context of this research, namely the LBCS, in more detail.

The Land Based Classification Standards [25] were developed by the American Planning Association (APA) basically to provide planners with a consistent model for classifying land uses based on their characteristics. The purpose of the standard was to provide a common classification and to minimise redundant data collection and production by a range of local, regional, state, and federal agencies. The first version of LBCS was launched in 2000 and the standards have since been updated periodically. Following Guttenberg’s approach in which he argues that urban planners will need several additional dimensions of land use information [26], LBCS developed 5 different dimensions to represent activities, economic land use functions, structural uses, site development status, and the nature of land ownership. Activity refers to the actual use of land, based on its observable characteristics. “It describes what actually takes place in physical or observable terms (e.g., farming, shopping, manufacturing, vehicular movement, etc.). An office activity, for example, refers only to the physical activity on the premises, which could apply equally to a law firm, a nonprofit institution, a court house, a corporate office, or any other office use” [25]. Function refers to the economic function or type of enterprise using the land. “Every land-use can be characterized by the type of establishment it serves. Land-use terms, such as agricultural, commercial, industrial, relate to establishments. The type of economic function served by the land-use gets classified in this dimension; it is independent of actual activity on the land. Establishments can have a variety of activities on their premises, yet serve a single function. For example, two parcels are said to be in the same functional category if they serve the same establishment, even if one is an office building and the other is a factory” [25]. Structure refers to the type of structure or building on the land. Site development status refers to the nature of the overall physical development of the land. Finally, ownership refers to the relationship between land use and land rights. The multi-dimensional concept of the LBCS allows for very precise information on land use. Parks and open spaces, for example, often accommodate a complex mix of activities, functions and structures and current land use standards containing only one classification dimension cannot adequately describe such a spatial structure.

Moreover, LBCS has a hierarchical system for each dimension which contains a set of categories and subcategories for classifying land use. This hierarchical system makes it very flexible in terms of the level of detail for the available information—categories can be refined or abstracted if needed. LBCS provides a (numerical and colour) coding system to accommodate each dimension category in the hierarchical tree. Each of the five dimensions has nine colour values, one for each top-level category. Within each dimension, the colour value remains constant for the top-level category and all subcategories.

The parcel is one of the most important geospatial elements for planners and is therefore the most common taxonomic unit in land use data. Nevertheless, LBCS is independent of classification units, enabling land use data to be integrated from a variety of scales. LBCS can be equally applied to units such as traffic zones, buildings, parcels, parcel aggregates, grids, and combinations of such units.

The database implementation of LBCS can be described by adding new fields to the land use database. The total number of land use fields in the database should equal the number of dimensions. Dimensions may be added or dropped as needed, depending on the purpose of the data. Relational databases offer an easy platform for implementing a database schema that can store multiple codes required to mirror the multi-dimensional nature of land use.

4. Mapping the LBCS into an Ontology

4.1. Class Hierarchy

The LBCS standard has three qualities that constrain the ontology mapping process: (1) it is multidimensional, with each dimension structured hierarchically; (2) the level of detail used to classify land use may be flexible, meaning that, for example, it is possible to classify the function dimension of a certain land unit as shopping (higher on the function dimension hierarchy) or as goods-shopping (lower on the hierarchy); (3) each concept in the hierarchy has a numerical code (which is unique within the context of a dimension) and a colour code, in addition to the full name and description.

The first quality, the hierarchical nature of LBCS, offers the opportunity to model each concept as an OWL Class and to build the hierarchical taxonomy through the OWL Subclass relation. In contrast, the second and third qualities seem to be better modelled by treating categories as OWL individuals or instances. It was intended to classify parcels and other land units in different abstraction levels, meaning that dimensions, at any abstraction level, should naturally be seen as individuals (or instances). The main reason for this is because there will be object properties that link Land Units to LBCS dimensions and an OWL property always relates two OWL individuals rather than individuals with an OWL class. Regarding the third quality, each category has its own numerical and colour codes. In OWL there are two possible ways of modelling these attributes of LBCS categories, either by using annotation properties in the class or by using data properties, which are asserted in the individual. While the use of properties is compatible with reasoning and allows for the imposition of some structure and restrictions such as range or cardinality, the annotation properties are completely ignored by reasoning and are only there to be read.

Deciding to model a concept as class or as an individual is not a straightforward decision but a very controversial issue [27]. We wanted the best of both worlds and therefore chose to allow the LBCS categories to be viewed both as individuals and classes. One way to solve this dual need is through a weak form of meta-modelling known as punning [7]. Punning, in OWL 2.0, consists of declaring a class and an individual with the same name (IRI), so that this entity is viewed either as a class or as an individual, depending on the context. This means that for every LBCS category class there is an individual with the same identifier (IRI). Punning belongs to the OWL2 specification and is correctly interpreted by reasoners following the inference semantics of OWL. This solution fulfils all the requirements stated above, allowing the user to maintain the subclass relation between the categories and assert properties for them (for example: LeisureActivity hasCode 3000). In addition, since all categories in all taxonomy levels have a corresponding individual, it is possible to assert properties from any punned category (for example: SidneyOperaHouse hasActivity LeisureActivity).

The taxonomy was structured using a base class named LBCSConcept that has five subclasses corresponding to the five LBCS dimensions (Activity, Function, Structure, Site, and Ownership). The taxonomy of concepts as defined in LBCS is built by sub-classing each of the dimensions, as shown in Figure 1. As previously stated, every subclass of a dimension will have an individual with the same name for meta-modelling purposes (except the five concepts corresponding to the top dimensions). All sibling classes were declared disjoint and individuals were also declared different from each other. To refine the semantics of the ontology, a covering axiom was added in the LBCSConcept class, and the subclasses corresponding to the five dimensions were declared disjoint, meaning that every member of LBCSConcept must be an individual of either the Activity, Function, Structure, Site or Ownership classes.

Figure 1. The LBCS class hierarchy. The LBCS concept seen as a class with three annotation properties for registering the full name, description and source. Each class has an individual with the same name.

Figure 1. The LBCS class hierarchy. The LBCS concept seen as a class with three annotation properties for registering the full name, description and source. Each class has an individual with the same name.

The numerical and colour codes were modelled with functional datatype properties (see Figure 2) and not as annotations because they have unique numerical and colour codes and this can be useful in reasoning, for example, in queries like “Give me all the red categories”. Conversely, it is very hard to conceive of queries that would require the full name or description of a class, so these properties were asserted with the annotation properties “label” and “comments” respectively, as recommended by the OWL2 specification [7]. This approach also provides multi-language support, which can be useful in providing human readable information.

Figure 2. The LBCS concept. The LBCS concept seen as an individual with two datatype properties in which information about numerical and colour codes is registered.

Figure 2. The LBCS concept. The LBCS concept seen as an individual with two datatype properties in which information about numerical and colour codes is registered.

4.2. OWL Class and Individual Names and Automatic Ontology Construction

Since the original names of LBCS concepts include spaces and other characters that are not compatible with the entity name rules in OWL, it was necessary to convert these names into more suitable ones. Some fixed rules were devised for the conversion of names to ensure consistency across the ontology:

• (a) The CamelBack notation, recommended for OWL class names, was applied.
• (b) Commas were replaced by underscores.
• (c) Parentheses and everything inside them were removed.
• (d) A letter and a dot were added before each name, identifying the dimension to which the concept belonged (A. for activity, F. for function, S. for structure, SI. for site and O. for ownership).

Two examples are given below to illustrate the name conversion process:

• Regional center (enclosed mall with two or more anchors) was converted into S.RegionalCenter, as it is a subclass of the Structure (S) dimension.
• Agriculture, forestry, fishing and hunting, was converted into F. Agriculture_Forestry_Fishing And Hunting.

Since the LBCS standard has around 1000 concepts and 170 pages of descriptions, it was necessary to develop a mechanism to build the ontology automatically, according to the structure described in the previous sections. This was achieved by parsing the official LBCS standard document [28] with a Java application built solely for this purpose, based on OWL-API 3 [29]. The document pages with the description of the concepts have a very regular structure and the hierarchy level can be inferred from the code numbers, which made this task easier.

5. Land Use Planning: Using the LBCS Ontology

Let us suppose that, in the context of an urban planning framework, it is important to identify and classify a certain portion of land (Figure 3) according to the LBCS classification standard. To make this feasible, all the geographical information associated with a map of the intervention site has to be linked to the land use knowledge provided by the LBCS ontology. The portions of land to be classified have to be coupled with a spatial concept. For the purpose of this research, it was decided to use the concept of the “parcel”, which basically represents “portions or pieces of land, regardless of size” [30]. This concept seems to be appropriate for representing urban elements or features. In practical terms, to enable parcels to be classified on a map, it was necessary to create an ontology, detailed below, in which information about each parcel is represented. This ontology imports the LBCS ontology so that parcels can be classified with land use knowledge. Each parcel can then be associated with concepts that describe the different dimensions of the urban space as activity, function, structure, ownership and landscape. It is important to mention that spatial units other than “parcel” could be used, since LBCS concepts are independent of scale.

Figure 3. Classification of Parcels. Example of a map composed of parcels that can be classified according to land use knowledge.

Figure 3. Classification of Parcels. Example of a map composed of parcels that can be classified according to land use knowledge.

5.1. GIS_Parcel Ontology

A new ontology called GIS_Parcel was created, which imports the LBCS ontology so that parcels can contain both types of information mentioned in Section 5: (a) a link to the geographic spatial data and (b) land use knowledge. Technically, a Parcel class and one object property for each of the five LBCS dimensions (hasActivity, hasStructure, hasOwnership, hasSite and hasFunction) were created, linking the Parcel (domain) to the categories of the corresponding dimensions (range). These properties are not functional, meaning that each individual of Parcel may have multiple categories in each dimension (several functions, for example). Both a functional and an inverse functional dataproperty were also defined to store the Parcel identifier, which can be used, for example, to find the corresponding entity on a map. As will be explained in Section 6, it is not necessary to have the geometric data in the ontology only to maintain a link between each parcel instance and the corresponding geometry.

5.2. Queries

In OWL language it is possible to make queries by defining a class representing the query and asking the reasoner to retrieve all the individuals in that class. These queries can be pre-defined in the ontology or programmatically created in real time as required, using, for example, the OWL API. The expressive power of the OWL language, together with the multidimensionality of the LBCS land use standard, enables very complex queries to be created that can be defined in a very simple and flexible way. These queries can be quite useful for analysing urban space on the basis of the characteristics of its parcels. Queries using the ontologies developed within this research are typically built on restrictions to dimension properties.

We now explain how each type of restriction can help create useful queries relating to parcels in urban space.

• (a) Existential restriction (some): This is perhaps the most common restriction. It enables parcels to be found that have at least one specified category (or any other category that is a subclass of this) in one dimension. For example, the query “hasFunction some F.GeneralSalesOrServices” would retrieve all the individuals (represented as parcels on a map) with that function or a subclass of it, such as F.RetailSalesOrService, F.BarOrDrinkingPlace, etc. Basically, this function allows the user to automatically find a series of smaller-scale urban elements (parcels) by simply asking for its descendants in the hierarchy. This restriction allows for the automatic location of a range of spatial information.
• (b) Universal restrictions (only): This kind of restriction can be useful when used together with existential restrictions to specify that a particular dimension can only have a certain class of categories. For example, the query “hasFunction some F.GeneralSalesOrServices and hasFunction only F.GeneralSalesOrServices” describes parcels that only have GeneralSalesOrServices or one of their subclasses in the function dimension. Note that OWL follows open world assumptions and the world must therefore be closed in order to infer information based on universal restrictions. For this purpose, it is possible to say, for example, that the only dimensions declared so far are the only ones that exist for every parcel, using cardinality restrictions. This topic will be discussed in further detail below, when describing migrating information from relational databases.
• (c) Cardinality restrictions (min, max, exactly): These restrictions allow the user to specify how many different categories a parcel should have in one dimension. It may be useful, for example, to find parcels with more than one function: “hasFunction min 2.”
• (d) Qualified cardinality restrictions: These restrictions are an extension of cardinality restrictions, enabling the class of categories to be stated within the restriction. They can be used, for example, to find parcels that have more than one commercial function and at most one residential function.

Through the logical operators “and”, “or”, and “not”, these restrictions can all be combined to build quite complex queries, for example:

• “hasFunction some F.ResidenceOrAccomodationFunction and
• hasFunction min 2 and
• hasStructure some S.MultifamilyStructures and
• hasOwnership some O.NoConstraints-PrivateOwnership.”

This means “Private residential buildings also with other functions”.

5.3. Consistency Checks

By defining subclasses of the Parcel class and declaring them disjoint it is possible to create concepts that will help the reasoner to automatically detect inconsistencies in the classification. This may help in validating and correcting existing land use classifications and even prevent errors if the categorisation is carried out in real time with a tool that uses the ontology. For example, if the user wants to state that it does not make sense for a Parcel with the site category SiteInNaturalState to include a structure, this can be done as follows:

• (a) Declare an equivalent class named ParcelInNaturalState described by “Parcel and hasSite some SI.SiteInNaturalState and hasSite only SI.SiteInNaturalState.”
• (b) Declare an equivalent class named ParcelWithStructure described by “Parcel and hasStructure some Structure and not (hasStructure some S.NoStructure).
• (c) Declare ParcelInNaturalState and ParcelWithStructure disjoint.

Any parcel that has both SiteInNaturalState and any Structure categories will automatically be deemed inconsistent, and the reasoner can provide detailed justifications for this inconsistency, allowing the user to understand why the classification does not comply with the axioms of the ontology.

5.4. Matching with other Land Use Systems

There are plenty of land use classification systems and if the objective is to work only with the LBCS system and its ontology, some mechanism for mapping one classification system into the other must be devised. The multidimensionality of the LBCS standard and its completeness and good level of detail give this standard remarkable expressive power, which makes matching between other classification systems and LBCS almost always possible. This matching can be accomplished in a modular and flexible way by using ontologies. A new taxonomy can be created representing the other classification system by creating a subclass of the parcel class. These new classes will have existential restrictions in the dimensions properties, matching the classification system with the LBCS. Then, using the original classification data, the new classes can be instantiated, and these individuals will implicitly have the LBCS categories asserted. For reasoning purposes, this is almost the same as having the LBCS categories explicitly asserted in the individuals. Consider, for example, the National Land Use Database (NLUD) [31] classification system. Figure 4 shows how the matching between a NLUD class and LBCS can be achieved.

Figure 4. Matching between NLUD and LBCS. Matching between the NLUD class “ReligiousBuildings” and the LBCS ontology concepts through existential restrictions in the dimensions properties.

Figure 4. Matching between NLUD and LBCS. Matching between the NLUD class “ReligiousBuildings” and the LBCS ontology concepts through existential restrictions in the dimensions properties.

5.5. Automatic Categorisation

A method similar to the one described above can be used to make automatic categorisations through reasoning. Equivalence relations can be established between categories of land use, allowing new categories to be inferred for parcels, based on the categories that have already been asserted (or inferred) for them.

This is accomplished by defining subclasses of parcels and declaring them equivalent. For example, the user might want to state that all the parcels with the Structure category “Utility and other nonbuilding structures” also have the category “Developed site—nonbuilding structure” should be also classified with the Site category “Developed site—nonbuilding structures” and vice-versa. In this case, the following would need to be declared:

• “EquivalentClasses:
• hasSite some SI.DevelopedSiteWithNonBuildingStructures
• hasStructure some S.UtilityAndOtherNonbuildingStructures”

Note that this inference works both ways because an OWL equivalence has been defined, but it is also possible to define a one-way inference. If the intention is to state that if a parcel has the category “A”, it also has the category “B”, “having A” must be declared a subclass of “having B”. For example, if the user wants to declare that if a parcel has the category “Utility and other nonbuilding structures” that also has the category “Developed site—nonbuilding structures”, they would need to declare something like:

• “hasStructure some S.UtilityAndOtherNonbuildingStructures
• SubClassOf: hasSite some SI.DevelopedSiteWithNonBuildingStructures”

These constructs are very useful when dealing with the LBCS standard because of its multi-dimensionality. In this way, relationships can be established between the various dimensions of the standard, allowing for complete categorisation with less effort on the part of the user.

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.

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.

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.

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 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.

Figure 6. How to obtain OWL punned classes. An example of how to obtain the OWL entity (punned class) of a LBCS concept from its numerical code and dimension.

Figure 6. How to obtain OWL punned classes. An example of how to obtain the OWL entity (punned class) of a LBCS concept from its numerical code and dimension.

Figure 7. An individual representing one parcel in the map. The image shows how the world can be “closed” by asserting the cardinality of each property.

Figure 7. An individual representing one parcel in the map. The image shows how the world can be “closed” by asserting the cardinality of each property.

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.

7. Results and Discussion

The results of mapping the LBCS standard into an ontology seem to be promising. By using this ontology, those involved in urban development processes may identify and classify parcels of an intervention site and semantically annotate them with knowledge regarding the use of the land. This enhances the analysis phase of the planning process by using web ontologies to describe the urban context, thus providing a more intelligent and capable system.

This paper describes in detail how the LBCS standard can be implemented and how the resulting ontology can be used. It also describes how relational database implementations of LBCS can be converted into the LBCS OWL ontology. It demonstrates that ontologies can be very useful when dealing with land use information and can offer some advantages over the more traditional tools, for example in terms of the inference and consistency checks offered by OWL reasoning.

However, there are certain aspects that have to be taken into account regarding the use of the LBCS ontology (as with other urban ontologies in real practice scenarios), namely whether those involved in the urban development process need to know how to build axioms and whether they need to know how to build complex queries for the ontology.

This leads to the need to create an interface for the tool with an associated protocol to facilitate operations within the ontology knowledge. Such a tool is already under development, and is partially described in “4CitySemantics, GIS-Semantic Tool for Urban Intervention Areas” [8]. The basic idea is to develop an urban planning system tool which relies on Semantic Web technologies and incorporates the LBCS ontology, amongst others. The base concept of the tool is defined by top-level system ontologies, namely land use, workflow, and population ontologies. These ontologies, called skeleton ontologies, can be extended by user ontologies. For example, the land use ontology is extended with the categorisation of the LBCS land use standard. Furthermore, the land use is linked to geographic features on an underlying map, which is stored as a shape file.

The system tool offers a visualisation map, as can be seen in Figure 8, in which the different assertions are coloured according to its classifications. The tool also incorporates a workflow ontology which acts as a guide for the urban planner. Basically, the idea is to design a top ontology which can be extended with user-defined axioms. The goal is to apply Semantic Web techniques to the development of a system for the urban planning process.

Figure 8. A screenshot of the tool interface. A land use category is selected (left), displaying the features related to this category on the map. Some parcels are selected in the map (right) as the user classifies them with the selected LBCS category.

Figure 8. A screenshot of the tool interface. A land use category is selected (left), displaying the features related to this category on the map. Some parcels are selected in the map (right) as the user classifies them with the selected LBCS category.

In practical terms, this ontology-driven visualisation and classification tool makes a set of editing tasks available that provides those involved in the urban development process with a comprehensive set of features to select, classify, and interpret urban space. The goal is to facilitate the use of all the available information to describe urban space, in order to formulate appropriate design solutions to meet context-driven requirements.

8. Conclusions

The main outcome of this research is the development of the land use ontology LBCS-OWL2. The land use knowledge of this standard was modelled using a Semantic Web ontology using the latest version of the standard W3C Web Ontology Language (OWL 2.0). The proposed ontology facilitates the analytical phase of the description of urban space to assist the development of appropriate design solutions. The LBCS-OWL2 ontology incorporates the following main characteristics:

• (a) A comprehensive and detailed land use standard: LBCS describes urban space in five different dimensions: activity, function, structure, ownership, and site;
• (b) Semantic data integration: the LBCS-OWL2 ontology can be easily integrated into other urban ontologies, as in other urban planning applications. The LBCS ontology can also be linked to relational databases as demonstrated;
• (c) Semantic reasoning and querying: the LBCS ontology allows for queries, which is very useful for analysing urban space taking the characteristics of the land into account;
• (d) The LBCS ontology can be shared, reused, extended, and customised. These are common characteristics of web language ontologies.

Testing the proposed ontology in urban planning seems to offer a promising research field. Considering the usual difficulties faced by planners during the pre-design phases, the proposed ontology could improve the analytical phase and make the synthesis phase consistent by introducing a resourceful way of describing the urban context.

The main goal of future research is the development of additional ontologies in order to strengthen the description of urban space. These ontologies will be tailored and incorporated into the tool described [32], to support decision-making in the early stages of the urban design process.