Geoff, the geospatial form and function vocabulary, is a comprehensive RDF-based spatial object classification scheme based on a separation of the concepts of form and function. Geoff is based on our analysis of the extensive (over 50 million spatial object instances) Digital Landscape Model (DLM) Core model maintained by Ordnance Survey Ireland (OSi). We propose Geoff as there are currently no open geospatial form and function classification systems that cover the full range of geospatial objects (from buildings and roads to lakes and other natural features) modelled as Linked Data or in any other formalism. Geoff is a generalization of the DLM Core schema and adopts the GeoSPARQL ontology. Geoff was initially developed to make these classifications available for OSi's geospatial Linked Data as they facilitate the publications of more expressive models of spatial features. For example, to state that a church building (form) is now used as apartments (function). Geoff is now presented to the wider community for reuse and extension to meet their own needs. Geoff supports geospatial queries based on form and function and interlinking of geo-information datasets using different form and function code lists. The Geoff ontology follows Linked Data publishing best practice in terms of available metadata, documentation, and quality assurance.
Publishing geospatial Linked Data is growing in popularity with a wide range of national initiatives across Europe, e.g., in Switzerland1, Spain2, France3 , and Ireland4. The initial geospatial concepts modelled have focused on boundaries and placenames [1], but as geospatial Linked Data becomes established, we expect a wider array of
geospatial information will be published. New vocabularies are thus needed to express
the different types of features and diverse foci of the next generation of geospatial
datasets. For example, building on our previous boundary datasets [
One important geospatial information system (GIS) classification taxonomy for both the built and natural environment [3], [4] is the specification of a spatial entity’s form (which characterizes its physical shape and appearance) and the related concept of a spatial entity’s function (which specifies the type of use of a spatial feature). For example, a building may have the form “church” and the function “apartments” in the case of an older church that was converted into apartments. Standardization agencies such as ISO [5] are active in GIS domain and have published standardized taxonomies for form and function. Unfortunately, to the authors’ knowledge, none of these classification systems has yet been made available as RDF, RDFS, or OWL to facilitate geospatial Linked Data publication that includes these fundamental GIS concepts in an interoperable way.
In this paper, we present and describe Geoff5, the geospatial form and function vocabulary based on over a decade of data model development within OSi on form and function modelling within their Prime2 [7] national spatial data infrastructure that has assessed both existing public spatial form and function standards. Geoff also draws upon the OSi’s experience in classifying 50 million spatial features in DLM Core. In line with the principles of reuse and minimal extension, Geoff is designed to be used to sub-classify any individuals of the class GeoSPARQL Feature [6] (which is an abstract class for representing any geospatial entity such as buildings, rivers, and cities) and to link them with a set of function types defined in Geoff based on existing industry practice (the Irish national spatial infrastructure OSi DLM Core) where that is more comprehensive than existing standards. Geoff form and function types will be easy to extend as new use cases emerge. These extensions can be performed locally or as proposed revisions to Geoff itself. We demonstrate the vocabulary’s suitability as a solution by elaborating on its deployment within OSi as part of the Irish national spatial object identifier publication initiative, which has resulted in over 200 thousand buildings in Galway published with geolocation and form and function6.
The rest of this paper is structured as follows: Section 2 describes the current state of the art in form and function classification, section 3 provides an overview of the Geoff vocabulary, Section 4 describes an example application of Geoff in Ireland’s new geospatial Linked Data spatial entity publishing initiative, Section 5 evaluates Geoff under the headings; impact, reusability and accessibility, design and implementation. Finally, Section 6 provides conclusions and discusses future directions for Geoff.
Geoff: A Linked Data Vocabulary for Describing the Form and Function of Spatial Objects 3 2
A fundamental principle in ontology engineering is the reuse of vocabularies to avoid semantic heterogeneity. It was envisaged that existing form and function standards could be used as a basis for semantically annotating the OSI DLM core data. However, none were found in the geospatial domain. We, therefore, explored other non-geospatial standards. Form and function are concepts that are well understood in architecture.
The main classification systems for structural entities in the AEC domain are the US OmniClass [3] and UK UniClass2 [4]. Both are based on the ISO 12006-2 [5] classification for construction. OmniClass has a rich set of types for classifying entities, spaces, elements, products, etc. with a focus on the construction phase of buildings, landscape, and infrastructure. Both form and function can classify entities. UniClass2 also provides classifications for the built environment, but with a different range, including regions, complexes, spaces, and activities, the definition of which are too fine-grained at this point for the OSi, which classifies at a building level. However, it may be useful in future iterations as existing work is exploring the conversion of footprint polygons into wall products. UniClass2 does not classify entities by form. Instead, entities appear to be defined using terminology that reflects their form in a table called “Entities”. UniClass has 452 entities (not called forms) defined and 78 functions (defined for elements, which are components of a structure), OmniClass has been described above.
Due to the different approach to classification in UniClass2 (i.e., entities without any description of form, and function described only for elements), direct comparisons between it and the Geoff form and function concepts become difficult. There is a more closely aligned mapping between OmniClass and OSi’s classification of form and function in this respect. In either case, there is a lack of an open, freely available OWLbased spatial object classification scheme that clearly defines form and function for geospatial features, including buildings and infrastructure. This work seeks to address this through the development of OSi form and function types into a single OWL vocabulary. Also considering OSi has classified the form and function values for each of their (> 3.5 million) buildings and is in the process of publishing a subset of their building data as RDF (currently > 200 thousand buildings published), the classification of the form and function of their buildings may be of interest to others who wish to classify buildings. We describe Geoff, which provides this classification, in the next section. 3
Geoff is designed to provide a Linked Data vocabulary to separate the concepts of form and function for geospatial features, as is standard practice in geospatial information systems. Additionally, it provides the most comprehensive set of reusable identifiers for forms and functions that have been published to date in any encoding scheme by spanning both the GIS domain (OSi DLM Core) and the AEC domain (OmniClass), through the definition of a comprehensive hierarchy of standard GIS forms. Functions are additionally sub-classified according to their likely forms. This scheme provides support for an extensible classification of features when a feature’s function has been identified and links functions with their typical forms. This provides support for bidirectional inference (as far as is possible within the limitations of OWL 2’s EL profile).
Finally, we have manually identified links between the related GIS forms and AEC forms to support interworking between GIS-AEC applications, e.g., so a construction company could load a national spatial data representation of buildings and use that as the basis for further construction design. Knowledge engineers with a background in Building Information Modelling within ADAPT were responsible for driving this knowledge engineering activity. The vocabulary and links were validated both by subject matter experts in the OSi and by demonstrating the artefacts before deployment. • • geoff:Form describes “the physical composition of an object; what it actually is” geoff:Function describes “what an object does, or is used for”
Each form is a spatial entity and, as such, is modelled as a sub-class of the Open Geospatial Consortium standard GeoSPARQL [6] class geo:Feature. To minimize ontological commitment, geoff:Function is not linked to any specific external vocabulary or ontology of location functions as we are unaware of any single authoritative source of such knowledge.
An object property geoff:hasFunction that links a specific geospatial feature to its function (or functions) is provided. By examination of DLM Core, we have identified some cases where no specific function is (or can) be associated with a feature or form
Geoff: A Linked Data Vocabulary for Describing the Form and Function of Spatial Objects 5 (e.g., a ruin). For these cases, we propose a sub-class of geoff:Form called geoff:NonFunctionForm (see Fig. 1). The second property supplied is geoff:hasTypicalForm, and since this is an association between an individual (subject) and a Form class (object), it is outside OWL EL. However, this is valuable information to record, we model the property as an annotation property. This makes the property at least available for querying through SPARQL, even if it is outside the formal logical model of Geoff.
The final component of Geoff is a pattern for specifying specific sub-classes of form based on the identified function of a specific spatial feature. To enable this, geoff:Function has 281 named individuals, each describing a specific type of function that can be assigned to a geospatial feature. A comprehensive set of functions appropriate to each form is specified in Geoff as defined classes. For example, the geoff:PowerlineOverheadElectricityFunction class has individual members such as 110kV power transfer function. Following this scheme, we introduced 337 specific (i.e., lowest level) form classes that can be assigned to a geospatial feature (Fig. 2). Given that we propose an ontology, users can easily extend these definitions for their purposes. Following Linked Data best practices, Geoff has the following metadata related to provenance and licensing included; dc:title, owl:versionIRI, owl:versionInfo, dc:date, dc:creator, dc:description, dc:rights and cc:license. Classes defined according to Live OWL Documentation Environment (LODE) requirements and each have rdfs:label values (@en) and rdfs:comment to classes. This is the same for properties.
In Listing 1, the class for form “Church” is shown. To assign the formID, it is necessary to create an individual. It is also at the individual level we assign the different function to a form. In Listing 2, the function “Catholic Church” is given. It should be noted that the numbering for the forms and functions is a direct result of the numbering within the DLM core data set. Each form and function is stored in a table, and has a unique integer identifier localized to that table. Therefore, the number provides nothing more than an idea of the sequence of the form or function in that table. As within the OSi Prime2 governance model these numbers are the authoritative identifiers and therefore are unlikely to change, so these predicates are considered authoritative. :Form84 rdf:type owl:Class ; rdfs:subClassOf :BuildingSingle ,
:Site ; rdfs:comment "A spatial feature with the shape of Church" ; rdfs:label "Church"@en , "Church" .
:function81 rdf:type owl:NamedIndividual , :BuildingSingleFunction , :SiteFunction ; :hasTypicalForm :Form84 ; rdfs:comment "The function Catholic Church" ; rdfs:label "Catholic Church"@en , "Catholic Church" .
The OSi’s geospatial data is being converted and made available as RDF. This began
with the publication of boundary data in 2017 [
The central component of the platform is an Oracle Spatial and Graph7 version 12.1
server which hosts the OSi Prime2 data and is also a native triplestore with geospatial
inferencing available. It should be noted that this work is conducted on the DLM Core
distribution of Prime2, which is a non-normalised subset of Prime2 provided to OSi
customers. Most of the concepts carry over and it is expected that only small changes
will have to be made to Geoff to represent Prime2 directly. Prime2 has therefore been
the main driver of the ontology development. The process of generating the original
boundary vocabulary was presented previously in [
The analysis resulted in both a vocabulary for the geospatial objects required, as well as R2RML mappings to generate the RDF data from the master tabular data stored in Oracle. The vocabularies and data dumps (generated in RDF using these R2RML mapping) are made available on the geohive national spatial data website (data.geohive.ie). The generated RDF data is also published on an instance of Fuseki running on Oracle, exposing an endpoint to a Pubby8 instance adapted to also display geospatial data based upon OSi base maps9 (see Fig. 3 & Fig. 4), making the RDF data available to browsers in a human-readable form. The endpoint also exposes the authoritative geospatial data, providing a catalogue of URIs, which can be interlinked with other Linked Data datasets. Currently, the focus of OSi is to make their building data more open.
The Prime2 buildings descriptions contain information about the buildings geospatial coordinate (the centroid of the building’s footprint), a polygon footprint, names of buildings (in English and Irish), a GUID, addresses, way segments (i.e., where the entrance joins the road network), the status of the building (in use, derelict, etc.), and form and function. For each of these values, the OSi also maintains provenance information detailing who made changes, who authorized those changes, and when those changes took place [15]. Of this data, the OSi is currently only making openly available a subset, which includes its name (rdfs:label), geospatial coordinate (geo:wktLiteral), form and function (geoff:Form and geoff:Function), and most recent change to one of those values (a sub-property of the data property prov:wasGeneratedAt called osi:lastUpdate). 7 https://www.oracle.com/technetwork/database/options/spatialandgraph/overview/index.html 8 https://github.com/chrdebru/pubby (forked from https://github.com/pubby to include maps) 9 https://www.osi.ie/services/mapgenie/
Geoff: A Linked Data Vocabulary for Describing the Form and Function of Spatial Objects 7
This subset provides an important basis for interlinking building data with the authoritative data the OSi collects and more recent work has specifically looked at converting the geospatial data into ifcOWL [16], to further semantically enrich the OSi 10 http://data.geohive.ie/page/building/e1b361b0-11c8-495d-8803-e7771b618a38 building data. For each OSi building resource (>3.5 million), a human-readable URI is created to provide unique identification along with geospatial data and form and function. In Listing 2 the result of this process is shown in turtle format. Here a building is defined with an Irish and English name, a geospatial point (defined using geo:asWKT), a lastUpdate and a geoff:hasForm and geoff:hasFunction relation assigning it a form and function value (like that in Listing 1). A full list of form and function values can be found in the ontology. Using this approach, form and function values are assigned to each building.
<http://data.geohive.ie/resource/building/ffa0e12b0b0f48719b72cb6f860ee96f> rdfs:label "Carrickemond Church"@en ; geoff:hasFunction geoff:function81; osi:lastUpdate "2015-06-19T16:37:55"^^xsd:dateTime ; geo:hasGeometry
<urn:osi:build:geom:pnt:e487c4baa50941508de62bc6aaba762e1998-1225T00:00:00> ;
a geo:Feature, osi:Building, geoff:Form84 .
Listing 2 Example Building Resource for the form Church (1 of 2355 Church form individuals) PREFIX geo: <http://www.opengis.net/ont/geosparql#> PREFIX geoff: <http://ontologies.geohive.ie/geoff#> PREFIX qudt: <http://qudt.org/1.1/schema/qudt#> SELECT * WHERE { ?building geo:hasGeometry ?feature . ?building geoff:hasFunction geoff:function81 . ?feature geo:nearby(53.3442497253418 -6.240039825439453 2 qudt:Kilometer) . } Listing 3 Example GeoSPARQL query for all building resources with function “Catholic Church” (geoff:function81) within 2 kilometers of a specific geospatial point (using a property function) 4.1
Data uplift is the conversion of structured or semi-structured data into Linked Data based upon semantic-web technologies. Our process for supporting geospatial semantic uplift is based on a standard methodology for ontology development11, which consists of defining the scope, reuse of existing ontologies and vocabularies, enumeration of terms, definition of classes, properties and constraints, and finally the creation of instances. Ontology development is required where analysis determines no existing vocabulary can be found to satisfy the data exchange requirements defined within the scoping stage, or to support the interlinking process where multiple ontologies have been found. For Geoff, ontology development consisted of an analysis of the DLM Core data schema [15], as well as an iterative development life cycle using the Protégé tool [12]. This process involved periodic reviews by members of the OSi to ensure proper 11 https://protege.stanford.edu/publications/ontology_development/ontology101.pdf
Geoff: A Linked Data Vocabulary for Describing the Form and Function of Spatial Objects 9 alignment with the Prime2 data schema. For data uplift, mappings must then be generated, either directly or through the use of mapping tools, such as R2RML, to support data conversion. We do not address the development of these mappings here, as these will be presented in a parallel publication, but we do provide an analysis of the RDF generated in the next section along with an evaluation of the Geoff ontology. 5
This section first presents an assessment of the Geoff vocabulary according to (i) potential impact, (ii) reuse and availability, and (iii) design & implementation. The sections below summarize these evaluations under a set of statements. Secondly, we provide an analysis of the distribution of instances in Geoff classes from a real-world dataset to gain insight into Geoff’s ability to model the domain. i) Impact: Geospatial information systems use form and function as important semantic attributes of features, for example, to enable function-based search across a range of otherwise unrelated feature types. GIS professionals expect to have form and function support in geospatial Linked Data. Geoff is the first geospatial feature and function vocabulary to be published in RDF. Before Geoff, there were no existing geospatial entity form and function classification schemes in RDF, except as embedded in the entity type classification, e.g., the DBpedia12 subclasses of dbo:Building, which does not meet the needs of the GIS domain or give the same expressivity. Combined with the OSi Linked Data building registry, the additional semantics provided by Geoff enable new levels of interoperability between GIS data and AEC domain data which is necessary as future advances in remote drones, smart construction, self-driving vehicles and integrated energy grids leveraging the massive sensing power of national spatial data infrastructure. ii) Reusability and Availability: Geoff is currently used by OSi for their publication of the National Irish buildings Linked Data (which is ongoing). However, building open data is being published by a growing number of national and regional agencies such as the recent publication by the city of Zurich of its 50000 detailed 3D buildings as open data13. Unfortunately, none of this open data is Linked Data due in part to a lack of vocabularies. This lack is the problem that Geoff addresses. The W3C Linked Building Data community group14 is starting to address Linked Data for building models and could adopt Geoff as it has no work to date on form and function models.
To facilitate reuse, Geoff is published as a LODE-conformant self-describing vocabulary, so metadata is provided and all entities have RDFS lables and comments sufficient to generate HTML documentation for the vocabulary in the W3C style. This paper also describes Geoff and provides additional background for users. Geoff can be (imported and) extended in two ways: (i) by adding new individuals for new forms and functions and (ii) by defining new inverse functional ID properties to represent different 12 https://wiki.dbpedia.org/ 13 https://80.lv/articles/zurichs-3d-buildings-available-as-open-data/, https://80.lv/articles/zurichs-3d-buildings-available-as-open-data/ 14 https://w3c-lbd-cg.github.io/lbd/ standard codes for individual forms or functions (both OSi and OmniClass codes are already supplied). For users of this resource to create their extensions, there would be required a process of integration and publication of future versions of Geoff. Geoff (vocabulary, metadata, and documentation) is published at a persistent w3id URI here15 and is licensed as CC 4.0 BY, and thus commercial reuse and sharing are permitted. iii) Design and Implementation: Geoff has been validated using the OOPS! [13] ontology validation service, it supports LODE metadata and self-documentation, the W3C Data on the Web Best Practices16 such as versioning, metadata, vocabularies licensing, identifiers and quality having been validated by the Luzzu data quality framework17 for the quality dimensions of Understandability, Consistency, Syntactic Validity, and Licensing. In developing Geoff, we aimed at maximizing the reuse of existing standards. Geoff reuses OGC’s GeoSPARQL ontology to model geospatial features and the Dublin Core Element Set version 1.1 and OWL for metadata. To demonstrate its applicability, Geoff has been deployed and validated internally for OSi’s dataset of circa 3.5 million buildings. Currently, a subset of these have been published (over 200 thousand) with the intention of extending to include most if not all of the 50 million spatial entities OSi currently tracks in Ireland. 5.1
In this section, we demonstrate the application of Geoff to classify individuals from a real GIS dataset (OSi’s DLM Core) to gain insight into Geoff ’s fitness for distinguishing between individuals. This is a vocabulary quality indicator. Table 2 below presents a breakdown and analysis of the data generated through an R2RML-based conversion process from DLM Core to Geoff. It shows the numbers of different forms identified in the vocabulary and their relationship to the OSi DLM Core. The “DLM Core Table Name” is the name of a table in DLM Core which corresponds with the Class. The “Form” column gives the number of distinct form classes associated with that table. Tables for structures, water, and ways are merged into a single class. The “Function” column gives the number of distinct functions associated with those forms. The “Individuals” column gives the number of individuals which belong to that class in DLM Core, ranging from >22 million individuals for “Division Line” (which has 9 subclasses which are not illustrated here for brevity) to just 2 individuals for “Building Group”. The forms “Building_Group”, “Building_Unit” and “Way_Point” are modelled in the database as having the function value “Not_Applicable”. “Not_Applicable” asserts that a function does not apply to that form, rather than simply unknown, it is modelled in Geoff as a member of the NonFunctionForm class. Units and groups are collections of buildings, therefore a single function is not applicable.
It can be seen from this table that Geoff is a more generalized representation of form and function than is represented within DLM Core. Nonetheless, Geoff presents the first vocabulary of its kind which geospatial agencies can now represent their internal 15 https://github.com/perma-id/w3id.org/tree/master/geoff 16 https://www.w3.org/TR/dwbp/ 17 https://eis-bonn.github.io/Luzzu/
Geoff: A Linked Data Vocabulary for Describing the Form and Function of Spatial Objects 11 geospatial data sets form and function. Except for “Division Line”, whose 9 subclasses are not studied in detail here, each Geoff class represents around 1-10% of the total instances which is an appropriate granularity, especially given the hierarchy. As noted previously, even though this is a GIS-oriented dataset, there is a rich representation of form and function values for buildings. This provides evidence for the opportunities presented by integrating form and function within the AEC domain. A Semantic Web resource for describing forms and functions of features did not exist, even though these notions are prevalanet within Geospatial datasets such as the OSi. Another problem in this domain is that non-RDF standards have different perspectives on form and function, which need to be aligned. We address this gap and challeng with the Geoff geospatial form and function vocabulary, which sets out to provide an open, freely available OWL-based spatial object classification scheme which clearly defines form and function as distinct concepts for geospatial features like manmade structures, e.g., buildings. The ontology is being used to classify form and function for the Ordnance Survey Ireland’s over 50 million spatial objects, with current development efforts focused on publishing c. 3.5 million building descriptions as Linked Data. Geoff has been developed to make these classifications available to the OSi. The Geoff vocabulary follows Linked Data publishing best practices in terms of metadata, documentation and quality assurance. Future work will explore in more detail the linking of Geoff to other standards for form and function, such as OmniClass, as well as the definition of rules (SHACL) to support data set validation.
Acknowledgment. This research has received funding from Ordnance Survey Ireland and the ADAPT Centre for Digital Content Technology, funded under the SFI Research Centres Programme (Grant 13/RC/2106) and co-funded by the European Regional Development Fund.