Roaming enabled SDI _rSDI_ by niusheng11


									A Roaming-enabled SDI (rSDI):
-Balancing interests, opportunities, investments and risks-
Roland M. Wagner

con terra GmbH, Münster, Germany

After the introduction of the OGC WMS specification in 2000, the number of up and
running WMS increased on a daily basis. However, it is still unsure what shape the final
SDI will take. Will it have a central entry point? Will the SDI have a hierarchical or a
peer-to-peer structure? If charges and access control will apply, will a user need a single
account within the network or will he need a separate account for each instance? Users
and customers expect their SDI applications to be supplied with top quality spatial
information within a large coverage. On the other hand, an SDI application developer
will only invest in value-added SDI applications, if both his market and the number of
early adopters within it are large enough. Therefore, a roaming mechanism, which
shares coverage and automatically provides the best available spatial information
beyond that of a single provider, is needed to bridge user’s expectations and providers’
abilities. Another infrastructure facing a similar situation was that of mobile
telecommunications. The investment required to achieve the critical mass of co verage
was immense, as were the risks of failure (Jenkins 2004). Aware of the need for larger
coverage, the small number of early adaptors in each market, and the large investments
involved, the CEOs agreed to apply the roaming concept. Competing providers started
to set up roaming agreements to enable visiting users from other providers to share
coverage and therefore reduce the level of investment in the critical starting phase. In
spite of the technical connectivity and the transparency of the common infrastructure,
the market presence of independent providers remained untouched. The business model
still contains sufficient leeway for competition. The provider market structure is peer-to-
peer, without a hierarchy. Private and former public providers have the same start- up
The approach is structured in four chapters. In the first chapter, the relationships
between the provider and end user are modelled. Existing or upcoming business
models for data and service providers are analysed to identify the typical business
model. The model describes business roles and business processes. The second chapter
models the provider to provider relationship. Because this is a B2B relationship,
certain factors, such as trust, can vary. Moreover, the types of licensing will vary within
the value chain. The third chapter introduces the roaming concept. The technical
workflow shifts to a foreign gateway, in which the foreign network provider takes on a
new role and transfers the incoming request to the home network provider to check the
accounts. If sufficient, the foreign provider will serve the customer. The last chapter
comprises deployment examples for business networks. In many cases, a single
organisation supplies multiple providers. These organisations may be not visible to
customers, to avoid conflicts of interests. It seems that joint trust and billing centres
could reduce operative costs, if the market is initially small. A full peer-to-peer
deployment should always be possible, to avoid any non-dissolvable dependencies
between competing providers. Also, virtual providers may be part of an rSDI.

1   Introduction

1.1 Demand
Users and customers expect their SDI applications to be supplied with top quality
spatial information with a large accessible coverage. Therefore harmonized content and
interoperable interfaces, e.g. SDI 1.0 (Nebert, Reed and Wagner, 2006) are relevant. On
the other hand, an SDI application developer will only invest in value-added SDI
applications, if both his market and the number of early adopters within it are large
This demand can be solved by a very capable provider (e.g. Google), or by an organized
business network with many smaller or medium size institutions.
Therefore, a roaming mechanism, which shares coverage and automatically provides the
best available spatial information beyond that of a single provider, is needed to bridge
users' expectations and providers’ abilities.

1.2 Business Cases from other Domains
Another infrastructure facing a similar situation was that of mobile telecommunications.
The investment required to achieve the critical mass of coverage was immense, as were
the risks of failure (Jenkins 2004). Aware of the need for larger coverage, the small
number of early adaptors in each market, and the large investments involved, the CEOs
agreed to apply the roaming concept. Competing providers started to set up roaming
agreements to enable visiting users from other providers to share coverage and therefore
reduce the level of investment in the critical starting phase.
Consumers were now able to use their (own) application (mobile phone) – not only in
their home network, but also in foreign networks. The call charges for roaming turned
out to be acceptable.
In spite of the technical connectivity and the transparency of the common infrastructure,
the market presence of independent providers remained untouched. The business model
still contains sufficient leeway for competition. The provider market structure is peer-to-
peer, without a hierarchy. Private and former public pro viders have the same start- up
Many other infrastructures, such as the Visa card, liberalised gas, or fixed line
telecommunication display similar approaches to sharing the risk and the investment in
their infrastructure.

2 Relationship Provider & End-User
This chapter aims to describe the relationship between a provider and an end-user in a
spatial data infrastructure (SDI), from a business perspective. In order to do this, the
new upcoming 'SDI' technology needs to be mapped to classic economic roles and
mechanisms. Because an SDI is considered in this final stage as an infrastructure,
economic roles and mechanisms for infrastructures can be re- used and adopted.
Established infrastructures like electricity, GSM telecommunication or Internet
infrastructures and their economic roles and mechanisms are helpful as metaphors,
although their products are different. Many roles and mechanisms in an infrastructure
are independent from the concrete product. Existing business cases show that a single
provider often offers two very different products (e.g. gas and electricity) with the same
business model (infrastructure), although very different technical delivery
infrastructures are used (e.g. gas pipelines and electricity cables).
Although the business sectors mentioned show that a kind of Framework Business
Model does exist in a sector, each operator need to create his own Applied Business
Model. If a common, cross-operator infrastructure should be used, e.g. for GSM, the
applied business model needs to fit into the framework business model. Another term
for business model is operation model.
Note: This approach aims to structure the framework business model as a common
denominator. Applied business models may use only a subset of roles and functions.
This corresponds also to the introduction of rights-enabled SDI, which can be
implemented through stable steps, using also only subsets.

2.1 Ope ration Roles
The OGC GeoDRM Reference Model (Vowles et. al, 2006) (GeoDRM RM) has
identified and described a first set of roles for rights-managed SDI. Although these roles
are only an intermediate result, this paper references them where possible. On the other
hand, new roles have in the meantime been identified and different definitions of roles
introduced, to reflect the advanced definition. A new separation between general roles
and specialized roles was introduced to refine roles, which offer only a subset of sharing
functions. These roles are discussed in detail in paragraph 2.3.
Table 1 shows the general roles. Some roles were derived from the GeoDRM RM, and
then generalized. These roles are denoted by the use of brackets in the last column. An
example is the 'manager' role, which was defined as a license manager in the GeoDRM
RM. If licensing is considered to be a specialized precondition along with user
identification and pricing, a general role would be the “manager” to manage all accounts
(identity, licensing and pricing).
After a more detailed examination of responsibilities the provider in the GeoDRM RM
was renamed 'deliveryman'. Although the name could be refined further, its main task is
to cover the delivery of products. The GeoDRM RM 'provider' is non-ambiguous in this
context. The reduction of responsibility in this last business phase is also useful for
showing outsourced or roamed delivery (see chapter 4). Another important factor is the
usage-dependent pricing and count-down licensing cases. In this case, a single (!)
account is needed to manage the current amount of money or, for instance, countdown
hits. This requirement is much more difficult to solve within the delivery phase due to
the large potential number of deliveryman institutions. Therefore this responsibility
shifts to the “manager” role.

 General Role                                  Descripti on                             GeoDRM
                 A promoter is an operator of product catalogues with product
                 descriptions, e.g. OGC CS-W and ISO 19115/ 19139 metadata
                 A broker establishes new contracts with accounts
                       on behalf of an agent or                                          (x)
     Broker            on his own responsibility as a reseller
                 A manager maintains accounts on behalf of the provider and the
                 consumer. The current state of the account is accessible for the
    Manager      account owner, the consumer and for other authorized ro les.             (x)
                 Examples are: broker for setting up a new account and deliveryman
                 for reporting a delivery.
                 A deliveryman is responsible for the delivery of products, e.g. via
                 web services.                                                            (x)

                 An owner owns intellectual p roperty.                                    X
     Ow ner
                 A consumer is a legal entity and acquires rights to access and use
                 offered products.                                                        (x)
                 An individual person who accesses and uses a product. An examp le is
                 an emp loyee of a co mpany who acts on behalf the company.               X
    End User
                 Contract party for consumer
                 [Co llect ion Ro le]

                                  Table 1: General Roles

It also reflects real- world examples of outsourced delivery by contracted institutions.
The term 'provider' as used within this document denotes a collective role, i.e. it may
include several roles. The provider is the contract partner for a consumer. As there are
several possible business constellations, the provider collection role is described in the
chapter 5 'Deployment Examples'.

2.2 Business Processes & Phases
The identified roles correspond to defined responsibilities within the business network.
A business process describes the order of interactions between these roles. The business
phase describes a collection of business processes. Currently the following business
phases have been identified:
     Search & Find
     Establishment
     Management
     Delivery
Like the number of roles, the use of phases depends on the business model applied. If
only a subset of phases is used, short cuts link the remaining phases together. Some
business phases, e.g. search & find, are repeatable, while others can only be repeated in

some cases, e.g. establishment in the case of an upgrade. Figure 1 illustrates the simple
example of the search & find and delivery phases for a non-rights- managed SDI.

         Figure 1: Use of roles and components in a non-rights- managed SDI.

This simple example corresponds to most existing SDIs. Each service offers a
capabilities (capa) document and an exception (excp) document on request or in the case
of a mismatch. A content owner loads an OWS service, which is operated by a
deliveryman, and registers his content with metadata in a catalogue, which is operated
by a promoter. The role “provider” is neglected. An end-user searches in a search & find
phase for potentially interesting items (2). If he finds an item, he may link his
specialized OWS client (OWC) to the described service and request the content (15).

Within a rights- managed SDI, the establishment phase is the minimum requirement for
setting up contracts between the consumer and the provider or owner. Figure 2
illustrates the roles and phases used. A newly established account might be checked by a
consumer prior to or after delivery (17). The broker transfers the new account data to
the within the business network contracted manager (6). In the case of an upgrade, a
consumer may also augment his established contract by using the functions of the
establishment phase again (16). Although the consumer may not manage his accounts
directly, the deliveryman may check them with a manager, if sufficient rights (identity,
pricing, licensing) are available. Therefore the deliveryman is authorized to check the
consumer’s accounts within the business network (11).

          Figure 2: Usage of roles and components in a rights- managed SDI.

The roles and phases may not in principle be supported by electronic services; figure 2
illustrates some software components as a clarification. The catalogue service (e.g.
OGC CS-W 2.0 AP ISO) supports the search & find phase. A consumer may use a
suitable catalogue client. The establishment phase is supported by a broker service and
suitable client. The management phase is supported by a manager service and a suitable
client. The delivery phase is supported by a GeoRM gatekeeper service, which protects
an OWS service. A suitable OWS client and a GeoRM gatekeeper client are therefore
required to deliver the product.

The following paragraphs describe each business phase in detail.

2.2.1 Search & Find Phase
The purpose of the first phase is to inform a consumer about available products (data
sets, services and accounts) with metadata. Additional information about access
mechanisms and preconditions (user identification, pricing, licensing) is given in this
phase. Catalogues are helpful in the case of large metadata bases, because they offer a
query mechanism. Metadata can be regarded as product descriptions. This phase does
not produce any legally binding results and can be repeated.
This phase can be skipped if a product and the corresponding product ID are known or
published elsewhere (e.g. capabilities).
The result is a set of product descriptions and product IDs.

2.2.2 Establishme nt Phase
Once a suitable item is found and sharing preconditions apply, a user needs to establish
a (business) relationship with a provider. In this phase, the consumer receives a legally
binding offer for the desired product. The offer may be negotiated if it includes potential
options, which should be set by a consumer. If both parties are in agreement, a new
(business) relationship is established by contract, which results in accounts being set up.
Otherwise the process will be aborted. Examples for accounts are identification,
licensing and pricing accounts. A simple case is a “click-though license” contract. In
this case, the account is temporary (single session) and e xpires. The sharing functions
used (identification, licensing, pricing or other) depend on the business model applied.
It should be possible to establish a separate account for each sharing function, but also
with a single interaction for click-through licenses. The first case applies to known
consumers, who may already have some established accounts, (e.g. identification
account established, but pricing account needed). The second case applies to rare
interactions with a particular provider, e.g. click-though case.

The summarized interactions between consumer and broker are
    Get Offer
    Negotiate Offer (optional)
    Agree Offer.

The result of the establishment phase is a legally binding contract with identity, pricing
and/or licensing accounts.

2.2.3 Management Phase
Once a new account is established between a consumer and a provider, the account
needs to be maintained. The account allows all authorized parties and roles to view the
records. Some records may change due to usage-based accounting. Some records may
be editable to allow quick adjustments, such as adding a new telephone number. In
many cases, this phase may be omitted.
Another important task is to issue key tokens and contact information to delivery sites
and to consumer clients. A valid token is required for a delivery request (see delivery
phase). The tokens can be divided into “General Tokens”, which cover all sharing
functions, or “Specialized Tokens”, which cover only a specific sharing function. An
example is a licensing token. Therefore, these information elements are the results of a
management phase interaction.
The result is updated record or access key tokens for delivery.

2.2.4 Delivery Phase
Finally, the desired product can be delivered upon request. Key tokens are required to
show the contracted rights. The key tokens and thematic request may be validated by
comparing them to the issued keys from the manager.
Depending on the business model applied, the tokens might be checked for validity at
the manager with the current account state by the gatekeeper component (11). This is
always required in the case of prepaid pricing or count-down licenses.
It is expected that the delivery of data happens much more often in a spatial data
infrastructure than the establishment or management.
The result is the delivered product and a receipt for the consumer. The manager also
receives a receipt, which may be used for documentation and accounting.

2.3 Sharing Functions
Although the described business phases apply generally to virtually all business
transactions, the owner may introduce different functions to support or protect the
shared access. Examples of sharing functions are identification, pricing and licensing.
Other functions are expected. The degree of usage depends on the applied business
model and may be different in each business phase or even in each business process. For
example, because the owner has great interest in promoting his data sets, the access to a
catalogue will be not be protected by any identity control in the search & find phase.
This might be different in the establishment phase, if the business model requires an
established identity account prior to accessing the desired data. Therefore, a new
identity account first needs to be established, or an existing one might be referenced by
valid specialized tokens. A “click-though” business case may require no identification
functions at all. The sharing functions are described in detail below. Figure 3 illustrates
the sharing functions in green, which might support all components.

          Figure 3: Business phases and supported sharing functions (green).

2.3.1 Identification
The sharing function identification offers access control by identity for known users. A
new identification account can be established at a broker and can to be maintained by a

2.3.2 Pricing
The sharing function pricing is required if products are subjects for trading. Therefore a
(new) pricing account needs to be established or referenced by tokens prior to accessing
the product. Two typical mechanisms are expected: post-paid and pre-paid. If the
business model uses pre-paid, the account balance needs to be positive. This needs to be
checked according to the expected price-per-transaction prior to delivery. The pre-paid
approach requires online transactions.

2.3.3 Licensing
The sharing function licensing is required if additional legal conditions apply to the
usage. Different terms of use may apply in different contexts. An example is the right to
use a service for private purposes, but not for commercial purposes. Some rights might
be processed and enforced by machines. Others need to be managed, but are subject to
enforcement by legal means.
The creative common concept with categorized license types is recommended for
further information (Creative Commons, 2006a).

2.3.4 Specialized Roles
Some roles may be specialized to support only some sharing functions. An example is a
trust centre, which offers user identity support only. Specialized roles are useful in the
introduction phase of a SDI, because most applied business models will not need all
sharing functions from the very beginning. Another reason for introducing specialized
roles is the choice of electronically supported or manually (or even parallel) operated
services. Some software solutions might support only a subset of sharing functions and
phases, which might be suitable for current business needs. Table 2 describes the
identified general and specialized roles.

   Generalized       Specialized
                                       Descripti on
      Role              Role
                                       A broker establishes new contracts with accounts
                                             as an agent on behalf of a provider or
                                             as a reseller at h is own responsibility.
      Broker                           These new accounts are to be registered at a manager within the
                                       business network.
                                       An identity broker is specialized in establishing contracts with
                                       identity accounts only. A user profile for preferences might also
                     Identity Broker   be set up.
                                       A pricing bro ker is specialized in establishing contracts with a
                                       pricing account only. An example might be a pre -paid or a post-
                     Pricing Broker    paid account.
                                       A license broker is specialized in establishing contracts with a
                                       licensing account only.
                    Licensing Broker
                                       A manager maintains accounts on behalf of the provider. The
                                       current state of the account is accessible for the account owner
                                       and for other authorized ro les. An example is a bro ker, for
                                       setting up a new account or a delivery man, for reporting a

                                       A manage also issues tokens to provide evidence to authorized

                                       An identity manager maintains identity accounts only. An
                                       example could be a change of an address.
                    Identity Account
                        Manager        An identity manager also issues user identity tokens to provide
                                       identity evidence to authorized roles.

                                       A pricing manager maintains pricing accounts only. A usage
                                       dependant pricing will be tracked and/or delivery requests may
                    Pricing Account    be blocked (prepaid) by this manager.
                                       A pricing manager also issues pricing tokens to provide pricing
                                       evidence to authorized roles.
                                       A license manager maintains licensing accounts only. A usage
                                       dependant license will be tracked and/or blocked by this
                       Licensing       manager.
                                       A licensing manager also issues license tokens to provide
                                       licensing evidence to authorized roles.

                        Table 2: General and Specialized Roles

Specialized roles can be merged if a subset of sharing functions is supported. If all
known sharing functions are supported, the role represents a general role. Table 3 shows
some examples for merged specialized roles.

                                  A merged specialized broker establishes new contracts with
                                  identity and license accounts
                      Identity          as an agent on behalf of a provider or
                         &              as a reseller by his own responsibility.
                       Broker     These new identity and license accounts are registered at
                                  manager within the business network.
                                  An identity & licensing manager maintains identity & licensing
                                  accounts only.
                      Identity    An identity & licensing manager also issues identity & licensing
                         &        tokens to provide identity and licensing evidence to authorized
                     Licensing    roles.

                           Table 3: Merged Specialized Roles

2.4 General and Specialized Components
The concept of general and specialized roles may be supported by electronic services.
Therefore, specialized components are required, which cover only certain processes or
complete phases.
The following sub-components are the result of deriving the discussed sharing
functions, identified phases and roles. Figure 4 highlights in green the resulting
components identity (3), pricing (4) and license (5) broker; identity (7), pricing (8) and
license (9) administration and identity (12), pricing (13), licensing (14) checker with
their interfaces. The dispatcher extracts the OWS context specific request / response
messages. An example for a context specific request is an “OGC WMS 1.1.0 getmap
request”. A component which supports all specialized functions is named a general
[phase] component, e.g. a general broker component.

    Figure 4: Business phases and supported sharing functions components (green).

2.5 Examples
The described roles and sharing functions for the framework business model need to be
selected according to the applied business model. This paragraph shows an example. I n
this case, all phases are supported electronically. The identity sharing function is used in
some phases. The purpose of this business case is to have a known community, which
might be tracked for marketing purposes only. Therefore a “monkey99” identity is
The catalogue is not protected, because all product descriptions are offered to
everybody. A wide audience can be expected if no identity preconditions apply. A new
identity account may be established by using an identity broker (3). This identity
account can be managed with an identity administrator service within the management
service (7). Authorized roles/components may ask (11) for an authentication check (12)
via an identity token. The establishment of an identity account happens only o nce. The
management of that account happens from time to time, e.g. to change a password. A
new key token may also be requested from a client at the manager site any time. A
consumer who already has an established and accepted account (see roaming) and
therefore possesses valid tokens bypasses the establishment and management phases. A
non-authorized request to the gatekeeper will be thrown back to the client, but with
relevant broker contact point data (16) or detailed error information, e.g. an expired
token and a manager address for renewing the token (17).

 Figure 5: Applied business model supports all phases electronically, but uses only the
                              identity sharing function.

3   Relationship Provider & Provide r

Chapter 2 describes the relationship between the provider and the end-user. It uses
additional roles to separated concerns. This chapter will introduce an additional major
relationship “provider - provider”. It also uses the well-established mechanism of
cascading to integrate these providers.
Figure 6 shows a consumer who uses two independent providers (blue, magenta). This
figure shows the maximum usage of sharing functions and electronic supported phases.
According to the cascading rule, a catalogue can be cascaded to retrieve product
description from both providers (2). The establishment phase may also be cascaded.
Two new accounts may be established with a single user action. An example is a click-
through license case, which covers two layers from two providers. The single click
establishes two contracts. If the license type is the same, e.g. creative commons by-nc-
nd ( nc-nd/2.5/) (Creative Commons 2006a), the
license content can be integrated automatically into a single view. Therefore the concept
of license types is crucial for the automated integration of licenses.

                Figure 6: Integration of distributed entities by cascading

Only a sub-set of functions and components may be used, depending on the applied
business model.

3.1 Business relationship
The degree of transparency between both providers may also depend on the legal
business relationship, which was defined in the business network contract. Therefore the
view has to be adjusted.

3.1.1 Agent Case
In an agent case, the transparency to the underlying provider should be high. A
consumer has a contract relationship between himself and the blue provider and a
separate relationship between himself and the magenta provider. Accounts and requests
may be tunnelled through an intermediate provider (blue), if he is trusted by both
remaining parties. This scenario applies also to “value-add” institutions, which do not
license content, but conduct processing on behalf of a consumer.

3.1.2 Reseller Case
In a reseller case, the transparency should be low. In this case the content chain consists
of two serial contracts: consumer- blue provider and blue provider - magenta provider.

3.2 Example: Additional sales with external agent brokers
An example of a possible business relationship is an external broker to enhance sales.
The blue broker was contracted by the magenta provider to offer magenta products as an
agent, although the magenta provider still operates his own broker. This example is
illustrated in figure 7.

                    Figure 7: Additional sales with external brokers.

If a consumer would like to establish a new contract, the blue broker makes an offer on
behalf of the magenta provider. The contract will be established between the consumer
and the magenta provider, and the blue broker only supports the contracting phase. After
the contract is established, the blue broker transfers the new contract to the magenta
manager and is out of business, but should still receive a share from the magenta
provider for his efforts.

4 Roaming Concept
The roaming concept is an organizational business network which has some impact on
software architecture and harmonized interfaces. Moreover, the roaming concept is a
specialized case of the general provider – provider relationship, which was described in
chapter 3. This chapter reduces the degree of freedom in some aspects. The roaming
concept restores the simple initial situation, which was shown in figure 1, with the
exception of a single establishment phase, but rights-enables the SDI.

It is helpful to use the GSM terminology home and visited networks to describe the
relationships between the consumer and the home provider (blue), who holds an
established contract, and that with a visited environment (magenta), which is granted to
the consumer on the basis of a roaming agreement between the visited/foreign network
provider (magenta) and the home provider (blue). Of course roaming fees may apply.
Figure 8 illustrate the establishment of a new contract between the blue provider and a
consumer. In this case the provider (blue) is a virtual provider without any delivery of
his own. Prior to his offer, the virtual provider established corresponding business
network relationships (roaming agreements) with other providers, e.g. the magenta
provider. That is why a foreign catalogue with foreign product coverage may be
cascaded or referenced. The consumer client is still provider neutral in the search & find
phase (which is not restricted by any preconditions). Once the contract is established,
the clients change into a blue-provider-trusted component because of obtained tokens.

              Figure 8: Establishment of a contract with a virtual provider.

Once establishment has been made and a potentially positive prepaid amount rendered,
the consumer may once more find interesting products in the (cascaded) catalogue. An
interesting product may be offered by the magenta provider. The reseller situation is not
transparent to the consumer. Figure 9 shows the ensuing interactions. The consumer
tries a delivery via his gatekeeper client and his key tokens, which holds account keys
for the blue provider. The key tokens were already obtained during the processes
depicted in figure 8. The magenta gatekeeper receives the delivery request, and sends a
request to his magenta manager. That manager knows about the established business
network relationship between the blue and magenta providers and therefore asks the
blue manager for the consumers' accounts. Because the roaming agreement has been
established, the magenta manager is authorized.
If the requested product in the visited network is the sa me type as the earlier contracted
product types and all conditions (e.g. positive credit amount) are still valid, , the request
will be granted. In this case the preconditions are:

     (identificat ion visited , pricing visited , licensing visited ) = (identification home, pricing home, licensing home)

The requested product fits into the established contract between the consumer and the
blue provider. In the case of roaming, the home provider turns into a reseller broker,
although delivery is carried out directly from the visited network to the consumer.

 Figure 9: Supplied consumer (search & find, delivery) by foreign (magenta) provider.

The manager – manager process may possess a number of short cuts, depending on
certain factors. If the conditions are post-paid only with the same license conditions, an
online on-the- fly check might not be necessary. The automated reseller relationship
within the established contracts (consumer and roaming agreement) needs to be
examined in more detail. The licensing precondition in particular needs clear decision
mechanisms for automated contracting. One approach would be the introduction of
harmonized license types, which also have a hierarchical relationship. The Creative
Commons approach already offers some hierarchical license types (Creative Commons
2006b). In that case the preconditions are:

     (identificat ion visited , pricing visited , licensing visited ) ≤ (identificat ion home, pricing home, licensing home)

In this case products which are unknown to home provider may also be automatically
contracted as long the preconditions are lower than the preconditions in the established
contract. If the preconditions exceed the agreed preconditions in the contract, the
request could be thrown back with the linkage to the home broker (16) via the manager-
manager and gatekeeper response for upgrading the contract. A consumer may check
and manage his account any time (17) and renew his tokens.

5 Deployment Examples for Business Networks
This section presents an example of the establishment of a business network. A business
network needs to be established prior to any service being offered to consumers. A basic
business network contains only the four minimum phases and a single instance of a role.
A roaming business network additionally contains other instances of roaming partners,
via roaming agreements. In many cases, a provider sub-contracts another institution to
share risk and investments. Figure 10 shows an example.

           Figure 10: Example A of the establishment of a business network.

In this case the provider and the manager ware working closely together, because the
management of accounts is considered a critical role. Therefore their relationship will be
contracted first (A). All other roles are sub-contracted to independent institutions.
In the next step (B), the provider contracts the owner of an IPR to provide products to
the consumer. The following step is to load this data into a delivery environment.
Therefore an institution will be contracted as a deliveryman (C). An external broker is
contracted prior to the promotion of the new product, (D). Finally, after all the required
roles are set within the business network, a promoter will be contracted to publish the
new product (E). Consumers are welcomed.

Figure 11 shows another approach to set up a business network. In this case the provider
role has direct contract relationships to all other roles.

           Figure 11: Example B of the establishment of a business network.

Of course it is also possible to cover all roles within a single institution, which could be
example C. In this case the roles correspond often to internal organizations, e.g.
departments. Although the examples A, B and C show different approaches, the result
has to be a basic business network.

Orthogonally to the described consumer business phases, the contracting of partners
within a business network underlies the same business phases as for the “consumer –
provider” relationship. A broker needs to be licensed by a provider to sell products as an
agent. Also a broker would need to check his licensing and pricing account with a
manager service from time to time. Because most roles are independent partners, which
are connected via the Internet, identity management between the organizational borders
is also needed. Therefore, most components may also be used for the internal business
network, search & find, management and delivery. This aspect needs further elaboration
and may have secondary priority in terms of electronic support. If additional
requirements for the interfaces can be derived, which are close the requirements in a
consumer-provider relationship, it is recommended to extent the interfaces to support
both relationships.

As already mentioned, the next step should be to elaborate the establishment of the
business network with introduced patterns. Also, the concept of license types is crucial
for automated processing. A hierarchical structure for license types would enhance the
flexibility of an rSDI.
In general, it is time to think about an operation model for SDI, otherwise other
technologies will grow.

Acknowledge ments
First of all I would like to thank the company con terra GmbH for providing the
sophisticated and practical context and the required resources. Therefore I would like to
thank Albert Remke, Christian Elfers and Jens Voigt. Second I would like to thank the
OGC GeoDRM WG with Graham Vowles et al. and the OWS4.geoDRM team with
Joshua Lieberman et al. I retrieved many thoughts also from the INSPIRE Drafting
Team “Data and Service Sharing”, which has a majority of lawyers within the team.
Finally, I would like to thank Rüdiger Gartmann for many valuable discussions.


Term                     Definiti on
Basic Business Network   A basic business network contains the minimu m required number of
                         role instances to cover the a full business cycle
Business Cycle           A collection of the min imu m nu mber of business phases; usually
                         contains establishment and delivery
Business Network         A network of contracted institutions covering all required ro les. The
                         provider is the initiator of this network and is as a contract partner of
                         a consumer responsible for the network
Business Phase           A collection of detailed business processes
Contract                 General definit ions elsewhere; a contract includes all preconditions
                         (licensing, pricing and access keys) together with part ies (e.g.
                         consumer, provider).
General Token            A general token is a collection of specialized tokens
Specialized Token        A specialized token corresponds to a specific sharing function, e.g. a
                         license token for a license function


Creative Commons (2006a), nd/2.5/ .

Creative Commons (2006b)

Jenkins, Gareth (2004) “GSM White Paper Brilliant past, bright future”, Deutsche Bank
Research, .

Nebert, Doug; Reed, Carl and Wagner, Roland M. (2006) “Proposal for a Compatible
SDI Standards Suite, “SDI 1.0”, GSDI9.

Vowles, Graham et al. (2006) “GeoDRM Reference Model”, OGC, 2006, in voting,
public version for comments, .




To top