GeoWorld

Moving Beyond the Geo-Relational Model BUILDINGTHEGEOWEB A lthough the relational database (and the associated relational data model) has served well for more than 40 years, it has limitations, as evidenced by the rise of NoSQL databases in arenas such as Big Data and social media. Anyone who has had to migrate a complex application based on a physical table model knows that the process can be long, complicated and painful. Although tables are clearly expressive, they're also very low level, and the expression of modestly complex notions such as taxonomies, entity relationships BY RON LAKE and objects with complex valued properties (e.g., geometry or time) can be daunting. There's no canonical way of representing these constructs that's widely supported, leading to difficulties in creating a business-information model. Such complexity also is reflected in common GIS products supporting the geo-relational model. Objects typically are restricted to a single geometric property type (e.g., road is a line), so all such objects can appear in a single table. Associating geometric properties with categories of a classification isn't supported or requires user programming. A Better Way? Ron Lake is president, Galdos Systems Inc.; e-mail: rlake@ galdosinc.com, blog: www. galdosinc.com/ archives/category/ media-center/blog. 30 Object data models have existed since at least the 1980s, and many attempts have been made to map these to relational databases. Mapping frameworks, such as Hibernate, or object-relational databases, such as Oracle (8i onward) and Postgres, partly resolve these issues—they make it easier to have objects with modestly complex typed attributes. The CSW-ebRIM data model, the joint OGC/OASIS specification, offers another approach. It offers a powerful, extensible, fully geographic data model with intuitive and high-level support for object relationships, collections and classifications. It offers a significant advance on geo-relational models and databases. In CSW-ebRIM, the core entity is a Registry Object, which can have any number of properties that, in turn, can include any number of geometryvalued properties. A road, for example, could have a centerline property that's a curve as well as an area G E O W O R L D / O C T O B E R / N O V E M B E R 2 O 1 3 property that's a polygon. In fact, any Registry Object can have geometric properties. CSW-ebRIM also provides a set of more specialized constructs, including Typed Associations, Classification Schemes, Extrinsic Objects, ExternalLink Objects and Registry Packages. All these can have multiple properties, including any number of geometric properties. CSW-ebRIM supports the notion of a RegistryRepository (RegRep) in which Registry Objects have associated Repository content that can be binary, XML or any other MIME type. This provides a basic and flexible mechanism for type extensibility. Extrinsic Objects are typed objects with properties, which have associated content managed in the local Repository. ExternalLink Objects also are typed objects with properties, but their associated content is in a remote repository not controlled by the owner of the ExternalLink Objects. These objects can be seen as descriptors of the repository content or considered data entities with the repository content being a component. At this level, CSW-ebRIM looks much like an object model with geographic support, with every Registry Object being automatically assigned a globally unique ID. Why It Works The power and simplicity of CSW-ebRIM stems from its direct support for classification schemes (taxonomies) and typed associations. Taxonomies of any breadth and depth are easy to create, modify and apply to the classification of Extrinsic Objects, ExternalLink Objects or other taxonomies and taxonomic categories. Associations can be explicitly created and used to relate Extrinsic Objects to one another (e.g., road crosses bridge) or define mappings among taxonomies. Unlike in a relational model, there's no translation of these high-level constructs to low-level tables. With CSW-ebRIM, programmers work directly in the model using well-understood and intuitive concepts such as association, collection and classification. When issuing a query, there's no need to translate the logical model into a table model and generate SQL—CSW-ebRIM does all of that. Users can immediately ask (programmatically or otherwise) to find all buildings classified as "under construction" and then combine this with free text and geospatial criteria. The query model is simple, expressive and intuitive. CSW-ebRIM enables data administrators to view data in structured or unstructured ways. Properties can be added to objects without regard for any notion of schema, and data administrators can create domainspecific object types (e.g., custom-typed Extrinsic Objects) and ask that the model be enforced.

• Cover