ISPRS, Vol.34, Part 2W2, “Dynamic and Multi-Dimensional GIS", Bangkok, May 23-25, 2001
represents the output data set. The proposed model dose not
modify the data model of catalog as mentioned in the OGC’s
catalog implementation specification. Relationship between the
catalog and the actual feature, which is mentioned by the
catalog, is represented by an association relationship. The
association links the GC_CatalogEntry class and the Feature
object class. Servicefeature, as a sub-class of feature, works
exactly the same way with catalog in the proposed model.
However, in this case, the catalog is maintained in the hosting
server of the marketplace. Meta-data of a service is stored as
the attribute of a GC_Catalog. The meta-data of service can be
generalized as input data set of the service, output data set (if
any), available operations on the input data set, parameters of
the operations, available output data format, and application
example of the service.
5.2 Common requesting language for services
Clients require services from various service providers by using
a common language. Encoding with the language, the mediator
transmits the message to an appropriate service provider. The
language is not used to retrieve data or to execute a function
directly on the service providers. Rather, this is designed to
request a service from the providers. In the other words, the
language aims to provide significant information about the
requirements of the service, instead of executing the service at
the service providers. The language should is enough to
accommodate the huge range of services in the marketplaces.
Basic form of the language is shown as below:
Service = Data + Parameter
Data = Operant + Operator + Constraint
Figure 3. Proposed data model for services in Spatial Internet Marketplace
For a specified service, the service providers need to know the
input “Data” to the service and the parameter specified by the
users. Furthermore, required “Data” can be specified by the
entire data set (Operant) plus the selection criteria (Operator +
Constraint). For instant, a data query service: "Get all parcels in
Hong Kong and the Owners is Chan. Data returned in format of
DXF”. In this data querying service “Get”, "Parcel” is the data
set to retrieve and this is known as the “Operant” data set.
There are two Operators: “in" and “owners”, they are used to
strain out unnecessary information. Constraints to these two
operators are "Hong Kong” and “Chan” respectively. “DXF” is
known as the parameter of the service. Another example is a
function service: “Map all commercial area in the Land Use Map
in red.” Operant, operator and constraint in this service “Map” is
known as “Land Use”, "in”, and “commercial area” respectively.
Parameter to this service is “red”.
With this generic language structure, all different of services can
be specified. Structures of data maintained in the catalog can
be developed accordingly:
Service table for data service:
Service-ID
Location
Parameter
& Type
Type
Data
schema
table
Service Table for function service:
230