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