Chapter 2 Context Setting & Related Work
2.1 OGC/ISO and IT Standards (Services) Stack
2.1.2 SOA-Related Metadata
Different components and activities in an OGC specified SOA require different levels of description in order for the architecture to function as envisaged. Descriptions can occur at a feature-level (i.e., at the most atomic level) within a data service, or can describe the entire dataset that is being made accessible through the service. Both of these types of descriptions are generally considered to be associated with “dataset level metadata”. Two other types of metadata are also used by the OGC standards, i.e., “high level service metadata” and “registry metadata” (Lesage, 2007). From a semantic perspective, all of these metadata variants (i.e., “feature”, “dataset”, “service” and “registry” metadata) are important because each has the capacity to reference ontological content (defined later in section 2.2). Some of this ontological content should be drawn from a Feature Type Catalogue as will be discussed and demonstrated later in Chapter 4 of this thesis.
Dataset Level Metadata
Although a feature can be annotated by metadata, more usually in current OGC-based service implementations, metadata is used to describe an entire dataset, or groups of datasets, rather than the individual features that might make up a dataset (Batcheller et al., 2007). In most cases the
30
metadata record sits separate from the data, which it then references (Batcheller et al.,2007). If the metadata is applied to individual features that are encoded according to Application Schema the metadata is embedded in the schema instance document (that represents the encoded data). Regardless of how metadata is applied, the OGC implements the ISO 19115 metadata abstract specification for a metadata (MD_Metadata) entity (OGC, 2011).
In reality ISO metadata is a collection of related entities (see Figure 2.3 for the UML diagram showing the various metadata components). These high level components include descriptors for information such as dataset contact details (in MD_Identification); data distribution and licensing requirements (in MD_Distribution); data quality and lineage (in DQ_DataQuality) and data maintenance (in MD_MaintenanceInformation). ISO 19115 also provisions in a few places (e.g., within
MD_ContentInformation) for the identification of specific Feature Types that are inherent in a dataset and can also encompass references to Feature Type Catalogues that are the source of Feature Type definitions (ISO, 2003). These latter facilities are not well exercised currently in the science domain and there is conflicting guidance about how to use the available Feature Type semantic provisions in the ISO 19115 metadata (Maue, 2009).
31 Service Level Metadata
As explained earlier, all services deployed in a SOA must carry a service description (i.e., services metadata). Services that conform to OGC standards describe themselves using high level ‘Capability Documents’which are accessed by clients issuing a “GetCapabilities” service request (Whiteside and Greenwood, 2010). Service ‘Capability Documents’ describe the service interface in sufficient detail so that an automated process can read the description and invoke an operation that the service advertises. It also describes the data content of the service (or the data it operates on) in a way that enables service requestors to dynamically compose requests for service. This content description component is optional, depending on whether the service contains or operates on data. Additional description units provide information specific to particular types of services as well as specific instances of services (Percivall, 2003). As is the case for dataset level metadata, there is a lack of guidance in the OGC standards about where Feature Type information should be stored in service descriptions.
It should be noted here that outside of the OGC standards environment, the Web Services
Description Language (WSDL: Christensen et al., 2001) is commonly used by the software industry in conjunction with the Simple Object Access Protocol (SOAP: Gudgin et al., 2007) and XML Schema to describe and orchestrate Web services, instead of Capability Documents. Whilst WSDL is not a mandatory component of OGC service descriptions, the OGC services suite now also accommodates the inclusion of WSDL and SOAP (Whiteside and Greenwood, 2010).
Registry Level Metadata
Registry metadata on the other hand is used to describe “registry objects” and how they are organised in the (registry) repository. Registry objects are any registered resources. The OGC information model for defining this metadata is a profile of the OASIS (2002) ebXML registry information model (ebRIM). This registry profile, coupled with the OGC Catalogue Services Specification (Nebert et al., 2007), specifies the information content and the framework for developing interfaces and the service bindings required to publish and access digital catalogues (registries) of metadata. Implementations of the OGC Registry (Catalogue) services are often referred to as OGC Catalogue Services for the Web (CSW: Nebert et al., 2007). A registry is typically
maintained by an authorized registration authority who assumes responsibility for complying with a set of policies and procedures for accessing and managing registry content (ISO 11179-6 (ISO, 2005d)).
32
The application interface of the OGC CSW(ebRIM) profile supports multiple query patterns including browse and drill-down (by category), or filtered queries against specified registry objects. Service offerings are the main resources managed in the registry and these are associated with other objects that help to provide a full and flexible description of the service (e.g., service taxonomies that classify the service in order to distinguish different service types, interface definitions, dataset descriptions and application schemas). Arbitrary relationships among catalogued items can be expressed by creating links between any two resource descriptions. MD_Metadata type entities are permissible and routinely included registry objects (Martell, 2007). There is a specific CSW profile, called the “ISO Metadata Application Profile” (Voges and Senkler, 2007) which uses ISO 19115 metadata. Not surprisingly, and as for the other levels of metadata, the encoding of Feature Type information in registry metadata is also lacking a standardised approach.