Coastal Informatics: Web Atlas Design and Implementation

Dawn J. Wright Oregon State University, USA

Ned Dwyer University College Cork, Ireland

Valerie Cummins University College Cork, Ireland

Information science reference Hershey • New York 53

Chapter 4 Coastal Atlas Interoperability

Yassine Lassoued University College Cork, Ireland

Trung T. Pham University College Cork, Ireland

Luis Bermudez Southeastern University Research Association, USA

Karen Stocks University of California San Diego, USA

Eoin O’Grady Marine Institute, Ireland

Anthony Isenor Defense R&D Canada – Atlantic, Canada

Paul Alexander Marine Metadata Interoperability Initiative & Stanford Center for Biomedical Informatics Research, USA

ABSTRACT This chapter defines the coastal web atlasesinteroperability problem, introduces interoperability standards, and describes the development of a semantic mediator prototype to provide a common access point to coastal data, maps and information from distributed coastal web atlases. The prototype showcases how ontologies and ontology mappings can be used to integrate different heterogeneous and autonomous atlases (or information systems), using international standards such as ISO-19139 for metadata encoding and the Open Geospatial Consortium’s Catalogue Service for the Web specification. Lessons learned from this prototype will help build regional atlases and improve decision support systems as part of a new International Coastal Atlas Network (ICAN).

DOI: 10.4018/978-1-61520-815-9.ch004

INTRODUCTION between or among other organizations or regions. Use of the word “seabed” in Europe versus use Advances achieved in Web mapping technologies of the word “seafloor” to describe the same fea- are allowing a much wider audience to develop ture in North America is a good example of this and use Web geographic information systems scenario. From both human and computational and, in particular, coastal web atlases (CWAs), standpoints, users need assurance that the con- which were discussed in Chapter 1. While mul- cepts, terminology, even the abbreviations that tiple benefits are derived from these tailor-made are shared between two or more individuals, atlases (e.g., speedy access to multiple sources systems, or organizations are understood by all of coastal data and information, economic use of to mean the same thing. In this way the quality of time by avoiding individual contact with different data retrieval and subsequent data integration are data holders), the potential exists to derive added greatly increased, as they are based on meaning value from the interoperability of disparate CWAs, rather than on mere keywords. to optimize decision-making at a variety of levels Several communities including the database, and across themes. artificial intelligence and geosciences communi- Within the context of coastal Web atlases, ties have studied interoperability methodologies interoperability can be briefly defined as the in the past two decades. These include database ability of several autonomous, heterogeneous and integration (e.g., Yétongnon et al., 2006) and distributed CSWs to communicate and exchange mediation (e.g., Wiederhold, 1992) approaches. resources (information, metadata, data or maps) Several mediation systems and prototypes have or be used together despite their differences. In a also been developed: examples of such systems are wider context, interoperability has been defined in TSIMMIS (Garcia-Molina et al., 1997), PICSEL ISO 2382-1 (ISO/IEC, 1993) as the “capability to (Goasdoue et al., 2000), Information Manifold communicate, execute programs, or transfer data (Kirk et al., 1995), and AGORA (Manolescu et among various functional units in a manner that al., 2001). requires the user to have little or no knowledge of This chapter discusses standards and tools, the unique characteristics of those units.” defines and proposes solutions on the use of Interoperability of coastal web atlases will help controlled vocabularies and ontologies, and pro- to unify the discovery and access of information vides an overview of the International Coastal to users (e.g., scientist, coastal resource manag- Atlas Network (ICAN) prototype. The solution ers) and categorize results using a convenient vo- proposed here is based on ontology mediation and cabulary. Data discovery relies on documentation on information that is shared via web services. provided as part of metadata (notably discovery metadata), such as the dataset title, abstract, extent, keywords, etc. In the context of distributed INTEROPERABILITY: resources, this information is present in different WHY IT MATTERS heterogeneous formats, and systems, according to several existing metadata models and standards. In recent years significant momentum has occurred While various efforts exist to provide a unified in the development of Internet resources for deci- common form to harmonize different standards sion makers, scientists and the general public who (see section 4.3), problems still arise with meta- are interested in the coast, where worldwide, 20% data semantics. of humanity live within a 25 km range, and 39%, Metadata terms may be agreed upon within or 2.2 billion people, live within a 100 km range an organization or a region, but not necessarily (e.g., Wright 2009). Given that no CWA functions

54 Coastal Atlas Interoperability

alone as an island, and is often part of a larger possibly archiving data, e.g., Geography universe of resources that is needed for effective Markup Language (GML). marine spatial planning, resource management, • The structure level involves standard data and emergency planning, CWAs must build a structures, e.g., a GML application schema common approach toward managing and dis- or a database schema. seminating the coastal data, maps and information • The semantic level deals with meaning that they contain (Wright et al., 2007). Sometimes and data standards (Asch et al., 2004). more than one CWA may be needed in order to Semantic interoperability aims to solve address regional problems such as hazard mitiga- semantic conflicts between different sys- tion, climate change, intergovernmental marine tems, generally using standards and map- spatial planning, etc. As an example, if there is a ping (correspondence) rules. dataset missing in one atlas, it may be immediately located within another. Often, similar datasets from different atlases cover different areas and can be STANDARDS combined in order to build a dataset that covers a wider area. For instance local high-resolution Efforts to create standards for the exchange of bathymetry data from different atlases one can geospatial information over the past years have participate in building a regional high-resolution produced a number of national and international bathymetry dataset. standards related to data and metadata formats and models, and to web services. Standards supporting geospatial interoperability have been developed LEVELS OF INTEROPERABILITY by a number of national and international standardization organizations and consortiums, which The levels of interoperability required for CWAs will be discussed in this section. are not less than those required for interoperating amongst two or more distributed heterogeneous Objectives systems in the wider context of information systems. Because information systems heterogeneity An important aspect of interoperability consists may occur at several levels, interoperability, also, of the design an implementation of web services can be defined at several levels. Bishr (1998) pro- that support data and metadata exchange. Con- vides an overall discussion of GIS interoperability sequently, one way to facilitate interoperability and a definition of interoperability at various is to standardize these three components. Such abstraction levels: system, syntactic, structure standardization will help harmonize data and and semantic. metadata access, delivery and interpretation. It is difficult or practically impossible to achieve • The system level involves protocols for absolute interoperability, i.e. interoperability networks, Web services and operating where a system can communicate with any system systems, e.g., FTP and HTTP protocols. using any data and exchange protocol standards. At the system level, users may connect to Therefore, it is crucial to set one’s feet on the the host or transfer data files between sys- ground first, before developing interoperable or tems. Users may also download data files interoperability systems, by setting the standards in some standard format. to cope with. Such standards will define the • The syntactic level involves standard for- ground basis for interoperability and the extent mats and languages for transporting and to which mediation or translation efforts will be

55 Coastal Atlas Interoperability

spent. As a matter of fact, interoperability typically frastructure for structured documents, thus relies on two things: standardization and media- facilitating syntactic interoperability; tion. While standardization aims to harmonize • Resource Description Framework (RDF) data formats and models, query languages and (Powers, 2003), a data model for referring exchange protocols, mediation aims to translate to objects (“resources”) and how they are from one model, language or format to another related to each other; such a data model un- and integrate responses from different systems. derpins the Ontology Web Languages (c.f. It is obvious then that the more data formats and next point); models and query languages are standardized the • Ontology Web Language (OWL) (Lacy, less effort we need to spend in mediating between 2005), which facilitates formal descrip- systems; hence the need for standards as a way tion of concepts, terms, and relationships to set a ground basis for interoperability and to within a given domain; OWL and RDF fa- minimize translation and mediation efforts. cilitate structural semantic interoperability by linking concepts and vocabularies from Standardization Bodies different domains or organizations; • Web services (Cerami, 2002), which are Several national and international organizations software systems intended to support in- and consortiums have been active in developing teroperable interactions between systems interoperability standards over the past decades. or machines over a network; web services Each organization or consortium tackles some support system and syntactic interoperabil- levels of interoperability within one more or less ity by defining common protocols and for- broad application area or domain (Web resources mats for data exchange. in general, geographic information, marine information, etc.). For instance, while W3C defines International Organization standards for data exchange on the Web in general, for Standardization OGC focuses on geospatial information. The aim of this section is to introduce a num- ISO [http://www.iso.org] is the most established ber of national and international standardization and recognized developer and publisher of Inter- organizations and consortiums of relevance to national Standards. ISO is composed of national Web GIS or CWAs interoperability. The list is standards institutes of 160 countries, one member not meant to be exhaustive; rather it focuses on per country. the key organizations. ISO/TC211 (ISO/T211, 2009) is the ISO technical committee specialized in geographic World Wide Web Consortium information and geomatics. ISO/TC211 develops specifications for the methods, tools and services W3C (http://www.w3c.org) is an open inter- for managing, acquiring, processing, analyzing, national organization whose goal is to lead the accessing and presenting geospatial data. ISO/ World Wide Web to its full potential by developing TC211 also provides a framework for developing common protocols. W3C open standards support interoperable spatial applications allowing geo- the development of technologies for advancing spatial data to be shared and exchanged between the Internet by ensuring interoperability, such as: different systems. ISO/TC211 is responsible for the 191XX se- • eXtensible Markup Language (XML) ries of standards for representing and exchanging (Ray, 2003), which provides a syntactic in- geographic information. The committee currently

56 Coastal Atlas Interoperability

has approximately 40 standards in development members working together to develop European including the following: standards, which are also adopted as national standards in each of the thirty member states. • ISO 19103 - Conceptual schema language CEN/TC 287 is the CEN technical committee • ISO 19104 – Terminology specialized in geographic information. CEN/TC • ISO 19107 - Spatial Schema 287 developed various standards for support- • ISO 19108 - Temporal Schema ing interoperability in the fields of geographic • ISO 19111 - Spatial referencing for information, such as the metadata, services and coordinates encoding standards amongst others. • ISO 19112 - Spatial referencing by geographic identifies INfrastructure for Spatial • ISO 19113 - Quality principles InfoRmation in Europe (INSPIRE) • ISO 19114 - Quality evaluation procedures • ISO 19115 - Metadata (ISO/TC211, 2003) INSPIRE (INSPIRE, 2009) is an EU initiative • ISO 19119 – Services aiming to develop a spatial information infra- • ISO 19127 - Geodetic codes and parameters structure for Europe. It is envisaged that such an • ISO 19128 - Web Map Server Interface infrastructure will deliver to the users integrated • ISO 19136 - Geography Markup Language spatial information services. Such services will (ISO/TC211, 2007) facilitate identification of, and access to, spatial • ISO 19138 - Data quality measures or geographical information from a wide range of • ISO 19139 - Metadata - Implementation sources ranging from the local to the global levels, Specification (ISO/TC211, 2006) in an interoperable way and for a variety of uses. INSPIRE envisages “a distributed network of data- A complete list of these standards can be ac- bases, linked by common standards and protocols cessed through the ISO/TC211 web site: www. to ensure compatibility and interoperability of data isotc211.org. and services” (Smits et al., 2002). INSPIRE aims to achieve its goals by defining a set of common Open Geospatial Consortium rules and an architectural framework for implementing them. Such an architectural framework is OGC (OGC, 2009) defines standards, both for based on the deployment of interoperable spatial data models and for Web services. It promotes information services over the Internet. The role interoperability in the fields of geographic data by of these services is to facilitate (1) the production defining standard interfaces and implementation and publication, (2) the discovery and delivery of, guidelines for geospatial data and geo-processing and ultimately, (3) the use and understanding of services. The OGC web services specifications are geographic information. compliant with the W3C Web service standards. Geographic Metadata Standards European Committee for Standardization Geographic metadata standards harmonize geographic metadata formats, models, structures CEN (CEN, 2009) is a business facilitator in Eu- and semantics with the aim to facilitate metadata rope, aiming to provide a platform for the develop- sharing and interpretation and data discovery and ment of European Standards and other technical access. Several national and international metadata specifications. CEN is composed of thirty national

57 Coastal Atlas Interoperability

standards have been developed over the past few the twelve remaining elements listed and defined years. Below is an introduction to the key ones. below as per (ISO/TC211, 2003).

Dublin Core Metadata • Identification information contains infor- Element Set (DCMES) mation to uniquely identify the data, e.g., citation for the resource, an abstract, key- The Dublin Core Metadata element Set (ISO/TC words, spatial and temporal extents, points 46/SC 4, 2003) is a vocabulary of fifteen properties of contact, etc. for use in resource description. The name “Dublin” • Constraint information contains informa- is due to its origin at a 1995 invitational workshop tion pertaining to the restrictions placed on in Dublin, Ohio; core because its elements are data. broad and generic, usable for describing a wide • Data quality information contains a gener- range of resources. al assessment of the quality of the dataset. DCMES consists of the following fifteen It also contains the scope of the quality as- comprehensive metadata elements, organized sessment and is an aggregate of lineage and alphabetically: contributor, coverage, creator, date, data quality elements: completeness, the- description, format, identifier, language, publisher, matic accuracy, logical consistency, tem- relation, rights, source, subject, title, and type. poral consistency, and positional accuracy. DCMES trades richness for wide visibility. • Maintenance information contains infor- Its simplicity, as pointed out in (ISO/TC 46/SC mation about the scope and data updating 4, 2003), can be both a strength and a weakness. frequency. On the one hand, simplicity facilitates metadata • Spatial representation information defines creation and improves interoperability. On the the mechanisms used to represent spatial other hand, it does not accommodate the semantic information in a dataset. and functional richness and precision supported • Reference system information defines the by complex metadata schemas. Because of such spatial and temporal reference systems simplicity, DCMES is not intended to replace any used in the dataset. other metadata standard. Rather it should co-exist • Content information contains information with metadata standards that offer other or richer identifying the features catalogue used semantics and functionalities. and/or information describing the content of a coverage dataset. ISO-19115 and ISO-19139 • Portrayal catalogue information contains information identifying the portraying cat- The ISO-19115 (ISO/TC211, 2003) international alogue used. standard defines general-purpose metadata for • Distribution information contains informa- geographic information. It defines metadata tion about the distributor of, and options elements, provides a schema and establishes a for obtaining, a resource. common set of metadata terminology, definitions • Metadata extension information con- and extension procedures. tains information about user specified ISO-19115 defines thirteen top-level metadata extensions. elements, the main being called the Metadata • Application schema information contains entity set information. This element encapsulates information about the application schema information about metadata, such as the language, used to structure the dataset. standard name, version, etc.; and is an aggregate of

58 Coastal Atlas Interoperability

The ISO-19115 standard specifies a set of Various XML grammars have been developed metadata elements, their types and relationships over the past years in order to standardize data among themselves. What it defines is a metadata structures in several disciplines and domains such model, which facilitates structural and semantic as geography, mathematics, music, etc. The ge- interoperability. However, since various imple- ography Markup Language or GML (Lake et al., mentations are possible, it does not guarantee 2004) is one of such XML grammars designed to syntactic interoperability. ISO-19115 has been describe geographic data. implemented in several ways since its publication, and the GIS community ended up with a number Geography Markup Language (GML) of heterogeneous implementations, which raised the problem of interoperability again. A standard GML (Lake et al., 2004) is the XML grammar implementation was then needed, and ISO-19139 defined by OGC to express geographic features. (ISO/TC211, 2006) was the answer. GML is used as an exchange data format for the ISO-19139 is an XML implementation of delivery of geographic data on the Web, by Web ISO-19115. The choice of XML (Ray, 2003) as Feature Services (WFS) (Vretanos, 2005). The standard metadata format is not random as XML is GML schemas are the set of XML schemas that the data exchange format for the Web. It consists define the GML grammar. They offer a set of pre- of a set of XML schemas (XSD) (van der Vlist, defined elements for the encoding of geographic 2002) implementing the metadata model specified feature classes, geometries, temporal properties, by ISO-19115 and prescribing the formats of the topologies, etc. GML defines features distinct from metadata records. geometry objects. A feature is an application object that represents a physical entity, e.g., a building, a Geographic Data Standards river, or a person. A feature may or may not have geometric aspects. A geometry object defines a Extensible Markup Language (XML) location or region instead of a physical entity, and hence is different from a feature. XML (Ray, 2003) is a general-purpose specifica- In order to expose an application’s geographic tion that provides a syntactic infrastructure for data with GML, a community or organization structured documents. As a markup language, creates a GML application schema specific to the XML uses a set of annotations to text in order application (the application schema). This GML to define its structure or display. XML is recom- Application Schema is an XML schema descrip- mended by W3C and is widely used as the Web tion (van der Vlist, 2002) that builds on (extends) data exchange format. the GML schemas in order to describe the object The structure of an XML document can be types whose data are exposed by the application. defined using an XML schema language. Several By doing so, organizations or communities define XML schema languages exist. XML Schema, or the common structure (feature classes, properties, XML Schema Description, or XSD (van der Vlist, associations, data types, etc.) for their data being 2002) is one of such several schema languages, exchanged by WFS servers. For instance, a com- recommended by W3C. An XML schema ex- munity could define that a station is a feature, and presses a set of rules to which an XML document that it has properties location, name and obser- must conform in order to be considered valid. vation data as properties. Examples of common XSD rules include element and attribute types, GML application schemas are the Climate Science cardinality and element structures. Modeling Language (CSML, 2009) for atmo-

59 Coastal Atlas Interoperability

Figure 1. Principle of a client interaction with an OGC web service

spheric and oceanographic data and GeoSciML distributed geospatial data sources. Several web (GeoSciML, 2009) for geoscientific data. services have been recommended by OGC, such GML is widely accepted by industry, govern- as Web Map Service (WMS), Web Feature Service ment and academia and it has been endorsed by (WFS), Web Coverage Service (WCS), Catalogue ISO-19136 standard (ISO/TC211, 2007); however, Service for Web (CSW). The main of these services because of the specialization of the schema by each will be introduced in Section 4.4. community and because GML is very general, it is often difficult to achieve interoperability (Ber- mudez, 2009). Each schema that is created will OPEN GEOSPATIAL SERVICES require the development of new tools (software, visualization capabilities etc.) and also translation The typical client interaction with an OGC Web between one GML extension to another. service can be summarized in the follow four steps as illustrated in Figure 1. Information Exchange Standards 1. The client contacts the server and queries it The major information exchange standards are about its capabilities, i.e. supported opera- developed around Web services (Cerami, 2002). tions and resources, using a GetCapabilities Web services are an emerging technology that al- request; lows different Web-based applications to interact 2. The server sends back to the client an XML in order to exchange data and software. Such document containing the functionalities interaction relies on the use of XML as a data supported by the service; such a document format, Simple Object Access Protocol (SOAP) is called the GetCapabilities response; (Snell et al., 2001), Web Service Description 3. The client requests data possibly using opera- Language (WSDL) and Universal Distribution tions within the capabilities of the server; Discovery and Interoperability (UDDI) open 4. The server provides the user with the re- standards (Cerami, 2002) over an Internet proto- quested data. col backbone. Through Web Services, distributed and heterogeneous data sources or systems can be Such processing is identical for the various shared and interoperated within an organization OGC services. However request types and syn- or across the Internet. taxes vary depending on the type of service in OGC has driven the development of, and question. In the following subsections we intro- recommended, several geographic Web services duce three key OGC services (CSW, WMS and designed specifically for the purpose of deliver- WFS) and their main request types. ing geographic resources on the web. OGC web services are the foundation of an interoperable framework for web-based discovery, access, integration, exploitation and visualization of

60 Coastal Atlas Interoperability

Catalogue Service for the Web (CSW) across the Internet. WMS supports the networked interchange of web based map layers, which are Catalogue services are the main technology for generally rendered in a digital image such as JPEG, locating, managing and maintaining distributed GIF, PNG, etc. Typically, a client submits an HTTP geospatial data and services. The OGC CSW (Ne- request to a WMS server including a number of bert and Whiteside, 2005), is a key international standard parameters. The server then returns the standard for interoperable distributed catalogue responses based on those parameters. The WMS services. It defines a common interface for dis- specification defines the three operations defined covering, retrieving and querying metadata about below. Mandatory operations are followed by the geographic data and services. An OGC catalogue star symbol (*), others are optional. service is an online repository for storing, index- ing, publishing and searching metadata records. • GetCapabilities* – returns an XML docu- CSW supports the ability to publish and ment that contains information about the search collections of data and services metadata server and the data that are available; by means of various operations or request types. • GetMap* – returns a map image; The operations supported by CSW are introduced • GetFeatureInfo – returns thematic infor- below. Mandatory operations are followed by the mation of a specific feature on the map. star symbol (*). Others are optional. As per the common functioning of an OGC • GetCapabilities* – for retrieving service service, the GetCapabilities request allows a metadata from a server; WMS client to retrieve metadata about the WMS • DescribeRecord* – for discovering ele- including supported operations and data holdings ments of the information model supported (spatial extent, thematic layers, styles available, by the service; etc.). Knowing what is available from the WMS, • GetDomain – for retrieving information the user can now request a specific map for a about the valid values of one or more specific area using a GetMap request. The server named metadata properties. will return a map image in JPEG, GIF, PNG, or • GetRecordById* – for extracting a meta- other format. Given a map, the client can request data record by its unique identifier; data about the feature represented by a given • GetRecords* – for searching metadata re- point (x, y) on that map, using a GetFeatureInfo cords, possibly using filters, such as key- request. The response from the server can be a word, location and time search; text, XML/GML, HTML, or Word file containing • Transaction – for creating, modifying and attribute information for the selected feature(s). deleting catalogue records; • Harvest – for retrieving an accessible re- Web Feature Service (WFS) source from a specified location, possibly periodically in order to refresh the infor- WFS (Vretanos, 2005) is an OGC specification mation in the catalogue. defining a common interface for delivering geospatial features on the Web. Geospatial features Web Map Service (WMS) delivered by WFS are encoded in GML (c.f. Section 4.3.4). WFS supports several operations, The OGC WMS specification (de la Beaujardière, which are introduced below. 2004) defines a common interface for dissemi- nating digital maps, rendered from spatial data,

61 Coastal Atlas Interoperability

• GetCapabilities – returns the capabilities 3. Transactional WFS – supports all the of the WFS, indicating which feature types operations of a basic web feature service the WFS can service and what operations and in addition it would implement the are supported on each feature type. Transaction operation. The GetGmlObject • DescribeFeatureType – describes using an and LockFeature operations remain optional XML schema, the structure of a feature for a transaction WFS. type the WFS can service. • GetFeature – retrieves feature instances, Web feature services constitute the basis for with the possibility for the user to speci- system and syntactic interoperability of geospa- fy which feature properties to fetch and tial data services by harmonizing data exchange to constrain the query both spatially and protocols on the Web, query languages and data non-spatially. formats. • GetGmlObject – retrieves element instances (GML objects) given their iden- tifiers (XLinks that refer to their XML CONTROLLED VOCABULARIES IDs), with the possibility for the client to AND ONTOLOGIES specify whether nested XLinks embedded in returned element data should also be Why are They Needed? retrieved. • Transaction – allows a client to modify The standards presented in this chapter and the features using create, update, and delete technologies used to implement these standards, operations on geographic features. are oriented toward achieving interoperability • LockFeature – allows an authorized client between CWAs. These standards address the to lock one or more instances of a feature structure and information requirements, which type for the duration of a transaction. This provide CWAs with the necessary syntactic and ensures that serializable transactions are structure level interoperability (see section 4.2). supported. To move toward semantic interoperability, the systems need to understand the actual data content As one might notice, it is not specified here being passed within these standard structures. which operations are mandatory and which are In many cases, the data content passed between optional. Rather, three types of WFS are defined systems is based on numeric data values. These depending on the operations they support: values are supported through the use of words or terminology, which identifies the data values to 1. Basic WFS – implements the GetCapabilities, the community-of-interest. In many professional DescribeFeatureType and GetFeature opera- communities, the terminology used to describe the tions, therefore is considered as a READ- data is often discipline-specific. In many cases, ONLY WFS. the different communities describe similar data 2. XLink WFS – supports all the operations of differently. a basic web feature service and in addition As a simple example, consider the use of the implements the GetGmlObject operation for word “altitude” (Miller et al., 2009). Altitude local and/or remote XLinks, and offers the refers to the height of something (such as an option for the GetGmlObject operation to airplane in flight) above a reference point (like be performed during GetFeature operations. ground level). Although altitude is a common term, architects would not consider ‘altitude’ as

62 Coastal Atlas Interoperability

proper terminology for describing the level of a check existing or imported metadata descriptions rooftop. Most likely, the architect would use the for consistency and correctness, including things word “height”. Similarly, if someone were in a like spelling and hyphenation. boat looking downward into the water, they would Controlled vocabularies may be defined in- describe the distance to the bottom as “depth”. ternal or external to a metadata standard (Isenor The three words – altitude, height, and depth and Spears, 2007). An internally controlled vo- – are all similar in that they represent measures cabulary often represents the allowed content for of distance relative to specified levels; but they a metadata attribute described by the standard. As are all used differently. As well, they are associ- an example, consider ISO 19115. This standard ated with different communities-of-interest. The allows for different kinds of reference dates to collective set of terms used by a community is describe the data resource. The specific kind of called a vocabulary. date is noted by using a metadata attribute called “datetype”. The allowed content of datetype is Definition of Controlled Vocabulary made up of the set {creation | publication | revi- sion}. These three terms are the only permissible Vocabularies provide a mechanism for communi- content for this metadata attribute. These three cation- be it written, oral or electronic- because the terms represent a controlled vocabulary, defined meaning of the terms are known and agreed upon internal to the ISO 19115 standard. by the community members. When a vocabulary A metadata standard is intended to have broad is formally managed, it becomes a controlled support across many communities. Thus, the vocabulary. In this case, “managed” means the controlled vocabularies defined internal to the terms are stored and maintained using agreed standard are intended to have broad applicability. upon procedures. Procedures should exist for Controlled vocabularies defined external to the adding terms, modifying terms and, more rarely, standard typically have support within smaller deprecating terms from a controlled vocabulary. communities-of-interest. These externally defined Controlled vocabularies are very powerful controlled vocabularies provide the details re- when combined with formal metadata standards quired by the community-of-interest to distinguish (e.g., ISO 19115). This is because the terms the subtleties of the data, which the vocabulary within the controlled vocabulary can be used as describes. the content for specific metadata elements that In terms of a CWA, the externally defined make up the standard. In many cases, the con- controlled vocabulary will allow an agreed upon trolled vocabulary terms completely define the meaning for the exchanged data. This means the allowable content for a particular metadata ele- thematic data, feature data, and the supporting ment. This control helps avoid misspellings and numerical data will be described using terminology inconsistencies in the metadata content. Moreover, contained within the vocabulary, and accessible to in the world of computers, the controlled vocabu- the larger community. As well, community mem- lary offers enhanced capabilities because it can bers will be able to use the controlled vocabulary be incorporated into automated procedures. For in mappings to other controlled vocabularies. This example, in a data system a controlled vocabu- is very powerful, as it allows the community to lary can simplify system input and contribute to establish a semantic-based link to other similar quality control of that input. Input is simplified communities. by providing users or other systems with a list of allowed entries for the specific metadata elements. Similarly, the controlled vocabulary can be used to

63 Coastal Atlas Interoperability

Types of Controlled Vocabularies Definition of Ontology

Various forms of controlled vocabularies exist, The term “ontology” has many definitions depend- but all can help improve data understanding by ing on the area of discourse. In computing, an restricting and better defining data content. To ontology is defined in (Sowa, 1999) as follows. provide the type of functionality noted above, the controlled vocabulary must be in a form that “The subject of ontology is the study of the cat- allows computer processing. The exact form of egories of things that exist or may exist in some the controlled vocabulary will vary, but in general domain. The product of such a study, called an there are three broad categories of controlled ontology, is a catalog of the types of things that vocabularies (Isenor and Neiswender, 2009) ex- are assumed to exist in a domain of interest D from tracted from (Neiswender, 2009): “flat, multi-level the perspective of a person who uses a language and relational vocabularies. L for the purpose of talking about D. The types in the ontology represent the predicates, word senses, • Flat controlled vocabularies provide a set or concept and relation types of the language L of used terms. Some flat controlled vocabu- when used to discuss topics in the domain D. An laries will provide additional information informal ontology may be specified by a catalog about each term (e.g., glossary). of types that are either undefined or defined only • Multi-level controlled vocabularies build by statements in a natural language. A formal upon a flat controlled vocabulary by as- ontology is specified by a collection of names for signing each term to a category (e.g., concept and relation types organized in a partial taxonomy). ordering by the type-subtype relation.” • Relational controlled vocabularies provide a set of terms, and capture how they are as- In some views, an ontology is simply a con- sociated with each other (e.g., ontology).” trolled vocabulary that is expressed in a particular structured format called OWL (Web Ontology ONTOLOGIES Language). Most sources, however, require that an ontology explicitly defines concepts, and ex- As one progresses through the categories of presses relationships between concepts in class controlled vocabularies, the functionality of the and subclass relationships (Gruber, 1993). vocabulary improves. At the apex is the ontology. Depending on which perspective one adheres The ontology provides a means for describing to, ontologies can include some of all of the fol- the complex internal relationships between the lowing: terms in the vocabulary and declaring machine- processable definitions for vocabulary terms • Classes (general concepts), that can be reasoned with. A coastal and marine • Instances of concepts, controlled vocabulary in the form of an ontology • Relationships among concepts, has been identified as a critical component for the • Properties of the concepts or relationships, integration (or interoperability) of CWAs (O’Dea including functions, processes, constraints, et al., 2007). and rules.

In summary, an ontology is a set of concepts in some domain of study, their properties and the relationships between them. As an example, con-

64 Coastal Atlas Interoperability

Figure 2. Marine habitat ontology other within an ontology, allowing data connected to one set of vocabulary terms to be searched, accessed or otherwise related using the other vocabulary’s terms. A suite of tools exist to develop/define ontologies, express them in a standard structure, and work with them once developed (Alexander, 2009). Servers also exist for describing and sharing ontologies so that they can be discoverable by the larger community. Some of the ontology registries and libraries that are relevant to the coastal data community include the MMI Ontol- ogy Registry and Repository (ORR, 2009), the sider a hypothetical ontology that defines marine OntoSelect Ontology Library (Buitelaar, 2004) habitat types (c.f. Figure 2). Estuary, estuarine and the Protégé Ontology Library (POL, 2009). water column, tide pool, rocky shore, and coastal Search engines like Swoogle can also help with habitat might be classes of habitats within this on- finding ontologies; the W3C SWEO Community tology. The Chesapeake Bay would be an instance Project on Linking Open Data maintains a list of of an estuary. One could define the relationship ontology search engines (SWSE, 2009). between a tide pool and a coastal habitat by saying that a tide pool “is a” coastal habitat – this defines Ontology Languages tide pools as a subclass of coastal habitats. Or, to define a different kind of relationship, one could An ontology language can be briefly defined say that the estuarine water column “is part of” as a formal language for building and encoding an estuary. An example of a property might be ontologies. The ontology community has speci- the requirement that, by definition, estuaries must fied several ontology languages over the past few have an average salinity of less than full seawater, years. Efforts of the Web Ontology Working Group or and that a rocky shore must be intertidal, and of W3C focused on the specification of standard it must have a hard substrate. Another kind of web-based ontology languages. This led to a property, a rule, can define how concepts in one series of XML-based languages and models the ontology map to those in another ontology, for most important of which are Resource Descrip- example a rule might indicate that “habitat type” tion Framework (RDF), RDF Schema (RDFS), in one ontology maps to the multiple fields of Web Ontology Language (OWL), and Simple “geoform” and “biotope” in another ontology. Knowledge Organization System (SKOS), which Ontologies are important for interoperabil- we will discuss in this section. ity because they allow complex concepts to be expressed, described, and related in a structured Resource Description and, ideally, machine-readable way. The ability Framework (RDF) to express relationships between concepts also makes them critically useful for creating interoper- The Resource Description Framework (RDF, ability between systems that each uses a different 2009) is, as defined by W3C, “a general-purpose vocabulary to cover the same domain area. The language for representing information in the Web”. participating vocabularies can be mapped to each RDF was designed to describe resources on the web by means of statements. A statement in RDF

65 Coastal Atlas Interoperability

Figure 3. Illustrative example of a generic RDF resource description

describes a resource using properties and property object node. Nodes are RDF URI (Uniform Re- values. A resource is a web page or a real world source Identifier) references, RDF literals, or blank object like a publication, a person or an institution. nodes. Blank nodes may be given a document- A property is a relationship that associates to a local, non-RDF URI references identifier called resource some “value”, for example name, author, a blank node identifier. etc. The associated value is called property value, Predicates are RDF URI references and can e.g., “Seán Murphy” or “http://www.w3schools. be interpreted as either a relationship between com”. In RDF, values may be atomic in nature the two nodes or as defining an attribute value (text strings, numbers, etc.) or other resources, (object node) for some subject node. An example which in turn may have their own properties. of a generic RDF graph is illustrated in Figure 3. A collection of these properties that refer to the A more realistic and intuitive example is given same resource is called a description. An RDF in the graph of Figure 4, which represents the statement is defined as a triple (subject, predicate, following statements: object). The subject refers to the resource being described, the predicate to the property and the • The title of Painting 1 is “Mona Lisa”; object to the property value. • The author of Painting 1 is Artist 1; RDF provides a syntax-independent model for • The name of Artist 1 is “Leonardo da representing resources and descriptions. An RDF Vinci”; description can be represented as a directed labeled • The birth date of Artist 1 is 15 April 1452. graph. The so-called RDF graph has nodes and labeled directed arcs that link pairs of nodes and An XML syntax for RDF graphs, called this is represented as a set of RDF triples, where RDF/XML (Beckett, 2004), has been developed each triple contains a subject node, predicate and by W3C. The purpose of it is to provide a common

Figure 4. Illustrative example of a resource description for a painting resource

66 Coastal Atlas Interoperability

machine processable and extensible encoding for tion Framework (RDF). Encoding this information RDF graphs. In RDF/XML, nodes and predicates in RDF allows it to be passed between computer are represented in XML terms: element names, applications in an interoperable way. Using RDF attribute names, element contents and attribute also allows knowledge organization systems to values. For instance, an RDF/XML encoding of be used in distributed, decentralized metadata the previous painting example would be something applications. Decentralized metadata is becom- similar to the following: ing a typical scenario, where service providers want to add value to metadata harvested from RDF Schema (RDFS) multiple sources.

RDF provides a way to express statements about SKOS Data Model resources. However, RDF user communities The SKOS data model views a knowledge orga- need also the ability to define the vocabularies nization system as a concept scheme comprising (terms) they intend to use in those statements, a set of concepts. These SKOS concept schemes specifically, to indicate that they are describing and SKOS concepts are identified by URIs, en- specific kinds or classes of resources, and will use abling anyone to refer to them unambiguously specific properties in describing those resources. from any context, and making them a part of the For instance, a given organization http://www. World Wide Web. SKOS concepts can be: example.com (referred to as “ex”) would want to describe the classes ex:painting and ex:artist from • Labeled with zero or many lexical the example above, and define properties such (UNICODE) labels in different natural lan- as ex:title, ex:author, ex:name and ex:birthdate guages (e.g., English, French, etc.); in any to describe them. RDF itself provides no means language, one of these labels can be speci- for defining such application-specific classes and fied as the preferred label; properties. Instead, such classes and properties can • Assigned one or more lexical codes, called be described as an RDF vocabulary, using exten- notations, used to uniquely identify the sions to RDF provided by the RDF Vocabulary concept within the scope of a given con- Description Language, referred to as RDF Schema cept scheme; (RDF-S or RDFS) (Brickley, 2004). RDF Schema • Documented using notes of various types further extends RDF by adding more modeling such as scope notes, definitions, editorial primitives often found in ontology languages like notes, etc.; classes, class inheritance, property inheritance, • Linked to each other using hierarchical and domain, range restriction. associative semantic relationships such as Related Term, Broader Terms, Narrower Simple Knowledge Organization Term, etc.; System (SKOS) • Grouped into collections which can be labeled and/or ordered; SKOS (Miles, 2009) is a common data model • Mapped to other SKOS concepts in differ- for knowledge organization systems such as ent concept schemes, using four basic types thesauri, classification schemes, taxonomies, of mapping links: hierarchical, associative, subject-heading systems, and taxonomies within close equivalent and exact equivalent. the framework of the Semantic Web. SKOS provides a standard way to represent knowledge An example of SKOS data expressed as an RDF organization systems using the Resource Descrip- graph is illustrated below. The graph is expressed

67 Coastal Atlas Interoperability

in TURTLE, the Terse RDF Triple Language Web Ontology Language (OWL) (Beckett, 2008), a textual syntax that allows RDF graphs to be completely written in a compact and OWL, the Web Ontology Language (McGuinness, natural text form, with abbreviations for common 2004), is used to explicitly represent ontologies, usage patterns and data types. i.e. the meaning of terms in vocabularies and the relationships between those terms. It has more facilities for expressing meaning and semantics rdf:type skos:Concept ; than XML, RDF, and RDF-S, and thus OWL skos:prefLabel “Gravel”@en ; goes beyond these languages in its ability to skos:altLabel “G”@en ; represent machine interpretable content on the skos:broader ; Web. OWL adds more vocabulary for describing skos:inScheme . properties and classes: among others, relations rdf:type skos:Concept ; between classes (e.g., disjointedness), cardinality skos:prefLabel “Folk Class”@ (e.g., “exactly one”), equivalence, richer typing en ; of properties, characteristics of properties (e.g., skos:altLabel “Folk Sediment symmetry, transitivity), and enumerated classes. Class”@en ; OWL provides three increasingly expressive skos:topConceptOf . sublanguages (McGuinness, 2004): OWL Lite, rdf:type skos:ConceptScheme OWL DL and OWL Full, OWL OWL Full be- ; ing an extension of OWL DL which is in its turn dct:title “Marine Geology an extension of OWL Lite (c.f. Figure 5). Only Thesaurus” ; OWL Lite and OWL DL guarantee computational skos:hasTopConcept . completeness, i.e., all computations performed on the statements of an OWL Lite or DL ontology In this example, it is expressed that A is a will finish in finite time. concept called, in English, “Gravel” (preferred label) or alternatively “G”. Concept A has a • OWL Lite is intended to support applica- broader concept B, called “Folk Sediment Class” tions with basic expressiveness require- or preferably “Folk Class”. Both concepts A and ments. It supports the basic constructs, B belong to a concept scheme S called “Marine including hierarchy of classes and simple Geology Thesaurus”, concept B being a top level cardinality constraints (values 0 and 1). concept of this scheme, i.e. is not narrower than • OWL DL is intended to support appli- any other concept in S. cations requiring the maximum expressiveness while retaining computational Usage completeness (i.e., all conclusions are guar- SKOS may be used on its own, or in combination anteed to be computable) and decidability with formal knowledge representation languages (all computations will finish in finite time). such as the Web Ontology language (OWL) to Its name is due to its correspondence with express and exchange knowledge about a domain. description logics, a field of research that However, SKOS is not a formal knowledge rep- has studied the logics that form the formal resentation language. foundation of OWL. OWL DL includes all OWL language constructs, but they can be used only under certain restrictions. For

~~~~68 Coastal Atlas Interoperability~~~~

~~~~Figure 5. The OWL sublanguages~~~~

instance, a class cannot be an instance of ogy. A mediator allows transparent access to the another class in OWL DL. distributed databases, by offering users a common • OWL Full practically allows “to say any- virtual ontology, G, called global ontology. The thing”. For example, in OWL Full, a con- global ontology is linked to the local ontologies cept could be a class and an individual at using mappings. Users pose queries over the the same type. It is intended for applica- global ontology. The mediator uses the ontology tions requiring maximum expressiveness mappings to translate the a user query into queries

with no computational guarantees. over DB1, …, DBn. Responses are then collected, restructured and translated according to ontology ONTOLOGIES FOR G, then integrated and returned to the user. INTEROPERABILITY This scenario is quite common in interoperability and mediation problems. The International In the literature, several approaches propose Coastal Atlas Network (ICAN) community de- ontology-based solutions for interoperability both veloped a coastal web atlas mediator that uses a in the general context of information systems and similar approach, which will be described below. databases (Bianchini et al., 2003 & Maedche et al., 2003) and in the context of geographic information systems (Heydari, 2009 & Kemp 2007). Such THE ICAN INTEROPERABILITY approaches use ontologies as a way to express the APPROACH structure and semantics of the information being exchanged and/or as a way to map between het- The ICAN community developed an ontology- erogeneous ontologies/data schemas (structures based mediator for coastal web atlases. The & semantics) or between controlled vocabularies current version of the ICAN prototype (ICAN, or also between categories/hierarchies. 2009) supports the OGC Catalogue Service for Figure 6 illustrates an ontology-based interop- the Web (CSW). Each atlas delivers metadata erability scenario. In this architecture, distributed records through a CSW. heterogeneous databases, DB1, …, DBn, use different structures and semantics. The structure and semantics of one of these databases, DBi, are expressed using an ontology Oi, called local ontol-

~~~~69 Coastal Atlas Interoperability~~~~

Figure 6. Interoperability scenario with ontology Architecture mappings. A user query is posed over a virtual common ontology, called global ontology. A mediator The ICAN approach uses ontologies for both uses mappings between the global ontology and facilitating interoperability and semantic data the local ones (O , …, O ) to rewrite the user’s 1 n discovery. Metadata records for a given atlas use query into queries supported by the local databases the terms of an ontology, called local ontology. (DB , …, DB ). Responses are integrated by the 1 n For instance the Marine Irish Digital Atlas uses mediator and returned to the user conforming to its own ontology; the Oregon Coastal Atlas uses the global ontology. another one. The approach relies on a common ontology (global ontology) that defines common terms (keywords) for users of the ICAN mediator (c.f. Figure 7). Mappings between the global ontology and the local ones allow the mediator to translate terms from the global ontology to a local one. The ICAN solution is based on a global atlas that offers a virtual catalogue service, called global catalogue, which acts as a CSW mediator and which offers unified and transparent access to the Figure 7. ICAN global theme ontology. Terms atlases’ CSWs. As illustrated in Figure 8, users highlighted in Blue are those selected by the user of the global CSW are provided with the global ontology. The user formulates a CSW request using an area of interest and keywords defined in the global ontology. The global CSW rewrites the user’s request into CSW requests over the local atlases’ CSWs using their local ontology terms, executes the so-obtained requests, and collects metadata records (responses) from local CWAs. This architecture facilitates extendibility as new catalogue services can be added and removed at any time without affecting the global CSW, provided that they come with the ontologies for the terms used by their metadata records and that Figure 8. ICAN ontology-based CSW mediation mappings between these terms and the global architecture ontology’s terms are provided. A user of the ICAN mediator may select one or more keywords and an area of interest (bounding box) and submit a search request to the mediator. The mediator translates the terms selected by the user into local terms and submits a request to the local atlases using terms from their ontologies. Results of such requests are then gathered and returned to the user (c.f. Figure 9).

~~~~70 Coastal Atlas Interoperability~~~~

~~~~Figure 9. ICAN mediator interface. Results from MIDA and OCA corresponding to the keywords selected in Figure 8~~~~

Global and Local Ontologies As OWL comes with a powerful mechanism for linking concepts both within and across on- A (global or local) CSW uses an ontology, which tologies, mappings are defined in separate OWL defines the terms used as values in its metadata ontologies. For each local ontology, a mapping records (for example thematic keywords, places, ontology defines the mappings between the local etc.). In the initial CSW mediator prototype, the ontology and the global one. A mapping ontology ontologies define the terms for keywords provided imports both a local and the global ontology and as part of metadata. Conforming to the ISO-19115 defines relationships between their concepts. An standard, five types of keywords are defined: dis- example showing extracts of the MIDA and the cipline, theme, place, temporal, and stratum. For OCA mapping ontologies is illustrated in Figures each atlas, an ontology of terms related to these 10 and 11. five keyword types is defined. Such an ontology In Figures 10 and 11 terms preceded by prefix is called local ontology. Relationships between the “global” are from the global ontology. Those terms contained within one ontology are provided preceded by prefixes “mida” and “oca” are respec- as part of the same ontology. Figure 8 shows the tively from the MIDA and OCA ontologies. Rela- ICAN global ontology for theme keywords. tionships represented with thin lines are defined as part of the local ontologies. Those represented Ontology Mappings with thick lines are defined as part of the mapping ontologies. For example, Coastal Protection and Ontology mappings link the global ontology to Shore Stabilization are defined in the MIDA and the local ontologies. This link is crucial as it is the OCA mapping ontologies as narrower terms than only means to allow the CSW mediator rewrite Human Responses to Coastal Change. user requests expressed with terms from the global ontology into requests over the local CSWs using their own terms (i.e., terms from local ontologies). Therefore they act as semantic translators.

~~~~71 Coastal Atlas Interoperability~~~~