A skeleton design theory for spatial data infrastructure

Earth Sci Inform (2009) 2:299–313DOI 10.1007/s12145-009-0034-7

RESEARCH ARTICLE

A skeleton design theory for spatial data infrastructureMethodical construction of SDI nodes and SDI networks

Rolf A. de By · Rob Lemmens · Javier Morales

Received: 7 July 2009 / Accepted: 25 September 2009 / Published online: 12 December 2009© Springer-Verlag 2009

Abstract In this paper, we look into the theory of de-signing geoservice systems, i.e., SDI networks and theirconstituent SDI nodes. As the field of SDI is stronglyabout bridging between geoservice systems, interoper-ability and harmonisation, it is not surprising that stan-dardisation efforts are of crucial importance in it. Theseefforts have historically addressed abstract and con-crete content models for data and metadata exchange,as well as abstract and concrete behavioural modelsfor computational processes. The list of standards thatare in use in the SDI field continues to expand, andreaches out to neighbouring fields such as sensor nets.We argue that given these trends, the resulting levels ofstandardisation in actual systems, and the complexity ofgeoservice systems in general, it appears only naturalto look into the possibility to define a standardiseddesign theory for SDI and its nodes, which addresses thefunction base and the communication base. Specifically,we provide an overview of those components that needto be designed, and what are their relationships. Wedo so in an abstract way, focussing on the concern ofinformation content in this paper, and only hinting at anappropriate theory of realisation based on our skeletontheory.

Communicated by: H.A. Babaie

R. A. de By (B) · R. Lemmens · J. MoralesITC, Enschede, The Netherlandse-mail: deby@itc.nl

R. Lemmense-mail: lemmens@itc.nl

J. Moralese-mail: jmorales@itc.nl

Keywords Catalog · Design · Formal method ·Geoservices · Implementation · Spatial datainfrastructure

Motivation and paper organisation

Our ever changing world is one with growing concernsfor sustaining the human and natural condition, as wellas one with growing potential for spatial monitoringand understanding of ongoing earth processes in thenatural and man-made environment (Davis et al. 2008).One of the important tools of our time to understandthese spatial processes and exploit spatial understand-ing is spatial data infrastructure (SDI).

It needs to be emphasised at the same time that SDImust be seen as a, still maturing, enabling technologywith a somewhat unspecified client base. One impor-tant and potentially large application domain is that ofsocietal networks: communities of (groups of) civilians,public administrators and professionals that share in-formation on a theme of interest. Such theme my havesocietal relevance in health, education, crime, publicadministration practice, or environmental surveillance.Land use change in the Amazon Basin is a point in case,as it draws (and requires!) attention from myriad stake-holders. Green pressure groups may identify disallowedsugar cane plantations or may want to report illegallogging. The SDI may provide the base data to backup their claims, for instance by putting on record theland cover history of the disputed locality. We expectthat SDI used in this sense supports transparency of themanagement of public space.

We consider SDI enabling because it can provide thegeospatial substrate on which relevant social functions

300 Earth Sci Inform (2009) 2:299–313

can be based (Davis et al. 2008). For instance, com-munity members may want to share news, experiences,recommendations and even advice, and may want toassociate any of these with precise or even uncertainspatial tags. It follows that models for network membercommunication are important to develop, and shouldbe addressed in appropriate and well-understood pro-tocols. In this sense, SDI provides one of the impor-tant bases from which to develop community supportsystems.

In context of the philosophy of single-creation–multiple-use (Bernard et al. 2005), the SDI domainis well-known for its relentless focus on the applica-tion of standards (Crompvoets and Bregt 2003), andof ontologically steered mapping mechanisms (Arpinaret al. 2006). The two enable the exchange of data,computations, and computation outcomes—all of thoseseen as services—between constituent systems of theSDI, which in the remainder of this paper are calledSDI nodes. The terms SDI and SDI node are definedbelow.

The standardisation efforts have historicallyaddressed abstract and concrete content modelsfor (spatial) data and metadata exchange, as well asabstract and concrete behavioural models for (spatio-)computational processes. The list of standards (in use)continues to expand, and reaches out to neighbouringfields such as sensor nets.

Given these efforts, the resulting levels of standardi-sation in actual systems, and the complexity of geoser-vice systems in general, it appears only natural to lookinto the possibility to define a standard design theoryfor SDI and its nodes. After all, given the high inci-dence of adoption of, often the same, standards, hopescan be had that even the realisation of the systemscan be made subject to some level of standardisation.This paper makes an attempt to break into this area.We believe that it is important to do so as an ac-cepted design theory will emphasise the need for high-level, platform-independent designs that over time willlead to more robust and better understood systemimplementations.

To us, an SDI node is a moderately to highlycomplex information system with usually a long life-time expectancy, in which geospatial resources fea-ture rather prominently. Its design and subsequentimplementation approach should respect this expectedlifespan, in terms of abstraction, documentation andformal transformation and derivation. We argue thatSDI node design and implementation itself shouldbe a domain of methodical standards and mappings,both of which must be understood deeply, and appliedrigorously.

We define an SDI as a collaborative network of sys-tem and human actors that exploit contributed data andcomputational resources, many of which are spatially ex-plicit, for one or more targeted objectives, making use ofservice offerings and consumptions. An SDI functionsas an organising mechanism for data, computationalmodels and classification schemes across data themesand application domains, tackling issues of identifi-cation, interoperation, and exploitation of spatial re-sources held by its community. SDI nodes are thesystem nodes of the SDI network, which is completedby non-system nodes, of which humans are the mostimportant to mention here.

In a not too distant future, SDI is expected to shapeas a support technology for systems of a more ar-gumentative kind, in which stakeholders can expresstheir views, backed up by ‘spatial proof’ or ‘spatialannotation’. It is also in this light that we argue for theimportance of communication as a fundamental SDIcharacteristic.

Our definitions are intentionally ignoring the non-technical characteristics of SDI, not because theyare unimportant, but because they receive appropri-ate attention elsewhere (de Man 2006; Masser 2005;Williamson et al. 2003), because they are not subjectto design scrutiny, and also because they are difficult toquantify in an explicit, formal design framework that isthe subject of this paper.

Present-day practice executes SDI node design andrealisation in a rather ad hoc and sometimes evenunstructured way. There are multiple reasons for this.First of all, SDI development is a new field nestled in arelatively new engineering domain (Craglia et al. 2008;Vieira et al. 2008). Secondly, a design theory for GIS-centric systems is lacking, certainly when comparedwith the design theory for database-centric systems.In the latter, much more standardisation has takenplace between different platforms, not in the leastbecause of the earlier standardisation work on SQLand derivatives (Codd 1970; Astrahan and Chamberlin1975), leading to the present situation in which ab-stract, platform-independent designs are rather easilyrealisable.

Approaches to realise SDI can be either top-down,bottom-up, or by-accident. Top-down approaches oftenaddress a wide thematic coverage for a larger adminis-trative entity, being goal-unspecific, addressing all or-ganisational (legal, financial, institutional) matters andcan be potentially client- or market-ignoring. Thesesystems are true SDIs-by-design, but their number issmall (Bernard et al. 2005; Annoni et al. 2008). Bottom-up approaches often derive from a well-understoodclientele and their service demand, for a relatively small

Earth Sci Inform (2009) 2:299–313 301

thematic and/or geographic coverage. These systemshave been realised in some numbers (Masser 1999;Lance 2003; Williamson et al. 2003). Finally, SDIs-by-accident arise typically where legacy systems have beenfound to hold exploitable spatial resources and havebeen made to deliver such as services. A number ofthese systems has been realised as well. The latter twoapproaches constitute, in our opinion, a rather naturalevolutionary development suiting the field of SDI best.

Another reason for the somewhat immature state ofSDI engineering lies in its mix of system paradigms.Historically and effectively, SDI is much about shar-ing and exchanging data, notwithstanding the fact thatother service promises may include offerings to usecompute power, storage space, run an application, helpto find services, or orchestrate a new service from exist-ing ones. So, SDI can be firmly placed in the domain ofdata and information systems, and thus fits in the realmof a state-based paradigm. This is actually more true ofSDI node design than of design of SDI as a network,which brings us to another paradigm. If an SDI con-stitutes a network, that network needs to be designed,which materialises to the precise specification of formsof communication—in protocols, interfaces, services—between actors in the network. That is, we need a com-munication process paradigm. Thirdly, the SDI fieldassociates strongly with principles of the geosemanticweb, which claims potential to develop services to itsexpanding clientele that were not foreseen at designtime, and will be generated on the basis of deep (spatialand thematic) understanding of needs and context. Wecall this the introspective paradigm.

Yet another reason for the lack of a fundamentalSDI design theory hides in the rich and growing spec-trum of implementation platforms (database engines,image repositories, GIS server engines, metadata en-gines, middleware and portal technology) that can beused for SDI implementation. Relative luxury thoughthis may seem, and notwithstanding the massive effortin standardisation of recent years, these systems are notbased on a single theory of spatial information. Thiscauses the need to implementors to be aware of allsorts of idiosyncracies between these systems and theirmodels, and in our view, forces them to focus on thosedetails far too early in their design and implementationwork.

Overseeing the above, a necessary step, in our view,is to add formal rigour to the design and implemen-tation process for SDI systems. We argue that sucha rigourous, formal approach to SDI node develop-ment is naturally state- and function-based as nodescaptures spatial resources such as data sets, spatio-computational models, and so on. A formal approach

to development of SDI as a network , in contrast, isnaturally process-based. This leads to the situation thatan SDI node must display two formal faces: state andfunctionality on the one hand, and process behaviouron the other hand. We also argue that, given currenttechnology, the introspective paradigm to SDI designis best handled as a third phase in the design. In thisway, almost naturally the system extendibility and therequired system abstraction is addressed last.

Our approach to SDI design is presented inSection “What constitutes an SDI design philos-ophy?”, providing a somewhat axiomatic statementplus arguments of what we believe is needed for thefield. A theoretic framework for state- and function-based SDI design is subsequently presented in Sec-tion “The vertical perspective: developing state-and-function systems”. A similar framework forcommunication-based design is described in Section“The horizontal perspective: developing a communi-cating system of systems”. The interplay between thetwo is discussed in Section “Merging horizontal andvertical designs”. Achieving system introspection andorchestration by design is the topic that we address inSection “The introspective perspective: developing anadaptive and extensible system of systems”. Howsuch designs can be properly integrated with boththe vertical and horizontal perspective is discussed inSection “Merging in the introspective design”.

What constitutes an SDI design philosophy?

It is a justified question whether the field of SDI is inneed of a separate design theory. After all, distributedinformation systems (DISs) have been in place for afew decades already, and one can argue that an SDIis just that. One may not be able to pinpoint a singledesign theory for large-scale DISs, but the scientificcommunity certainly has produced a few results in themethod and formalism domain for their design.

Yet at the same time, SDI is sufficiently distinctfrom DIS, warranting special treatment in its designas well. We recognise at least the following importantdistinctions:

Geospatial data characteristics Geospatial data formsthe fuel of any SDI, and comes with (quality)characteristics that make its direct application of-ten non-trivial. Typical DIS mostly operate on aprinciple that the system state represents the world-as-we-know-it, while such an assumption can bedisastrous in many use cases in SDI context.

302 Earth Sci Inform (2009) 2:299–313

Infrastructural foundation An SDI intends to providea data sharing framework for multiple purposes,such as the economy, the environment and societyat large. So SDI is strongly aimed at enabling ‘otherbusiness’. Typical DISs target a single business, orat least a confined set of use cases.

Use case understanding Where a typical DIS is oftendeveloped for a number of well-defined and well-understood use cases, for instance fitting inside asingle enterprise perspective, the use case under-standing for an SDI is often partial at the start only,and assumptions are made that other promisinguses will develop over time.

Organismal growth In line with above remark, SDIdoes not typically develop from a master planwith defined outer boundaries, but rather maystart small and dedicated and evolve over timeinto wider directions that were unforeseen at thestart. This comes naturally with all of the abovedistinctions.

Because system development is an expensiveprocess, appropriate documentation is beneficial whensystem redesign is called for. It also pays off if the sys-tem needs to demonstrate some level of introspection,for which see below. An important abstraction mech-anism in IT system design is the move away from plat-form idiosyncracies. Provided that standards adherenceis well established between platforms, as is the casewith DBMSs, and more and more also with geospatialplatforms, a platform-independent design will alwayspay off in the long term.

It is through transformational design techniquesthat abstract designs can be methodically and cor-rectly mapped onto a platform of choice. Such stepsare illustrated as arrows in Fig. 1. In that figure,the top level represents abstract designs that areplatform-independent. A design theory should include

state-and-functionsystem specification

communicationsystem specification

introspectionsystem specificationPIMs

state-and-functionsystem realisation

communicationsystem realisation

introspectionsystem realisationPDMs

Fig. 1 Overview of SDI design philosophy, showing state/funtionsystems, communication systems and introspection system, atboth platform-independent and platform-dependent levels

formalised transformations that turn abstract specifi-cations eventually into robust implementations. Suchtransformations are not deterministic functions, as theywill need to accommodate design alternatives along theway.

Current SDI initiatives are strongly focussed on dataprovision, sharing and portrayal, guided by the princi-ple of ‘create-once-use-many-times’. We expect themto become much richer functional entities, which, insearch of a wider clientele, will need to provide meansof introspection. The publish-find-bind paradigm is afirst step in that direction, as it makes a small step inthe domain of metadata exploitation. Introspection canonly be achieved if the system does not only provideaccess to its data, but opens up selected parts of itsstructure, which is fundamentally captured in a designprocess.

The methodical design of a complex system, or sys-tem of systems, should only be undertaken througha carefully selected list of concerns, which are ad-dressed independently from each other. A classical list-ing should contain the following concerns: informationcontent, information structure, performance, distrib-ution, interaction, functionality and security, thoughmore could be identified. In the present paper, wefocus on only two: information content and interaction.We also leave aside transformation techniques in thispaper.

The sequel of the paper discusses abstract designonly. We do not here discuss mapping such designsonto platforms, though this obviously required. In thesections, we aim at identifying the components that anabstract design should contain, and the relationshipsthat exist between them. This is done in the followingsequence:

1. State-and-function systems, in which we focus onhow to specify an SDI node as a system that holdsinformation, and provides functions that operate onthat information. We call this the vertical perspec-tive because such systems are realised often in asoftware stack.

2. The Communication system, in which we focuson how to specify the communication patterns be-tween SDI nodes, abstractly constructing a largersystem, the SDI. We call this the horizontal per-spective to emphasise peer SDI nodes communicat-ing with each other.

3. The Introspective system, in which we focus onaugmenting the specified SDI system with meansto query itself for service possibilities and allow thedynamic creation of new services.

Earth Sci Inform (2009) 2:299–313 303

The vertical perspective: developingstate-and-function systems

In the vertical perspective, we focus on how to developa single SDI node. Eventually, its role in the SDI is thatof service provider and consumer, but to get there itneeds to hold and maintain resources such as data andcomputational sources, as well as facilities to offer andconsume services.

Preliminaries

In designing and realising state-and-function systems,one typically defines a state space and a function collec-tion. In so doing, a prominent tool is a collection of syn-tactic types T and a collection of syntactic expressionsE . These allow us to make explicit system structure,function signatures, and eventually function definition.We do not elaborate on possible choices for T andE here, except to indicate some minimal requirementsthat would need to be met. A full definition of E wouldinclude variables, constants, identifiers, and an arrayof operators and functions for manipulation of values.Such a definition would be followed by the definitionof the ‘well-typed’ relation : ⊆ E × T indicating whichexpressions are properly typed, and what their type is.

On the types collection T , we will assume the pres-ence of a fixed set of base types, which might includevoid,1 int, real, bool, geometry, and image. Forwhat follows, we also must assume the presence of asyntactic name set A , members of which we will beusing as attribute names in records and record types.From types in T , we will be allowed to construct morecomplex types through the use of type constructors. Thefollowing type constructors are at least present, andprovide an inductive, albeit partial, definition for T :

[function type constructor] ∀σ1, σ2 ∈ T ⇒(σ1 → σ2) ∈ T

[set type constructor] ∀σ ∈ T ⇒IPσ ∈ T

[pair type constructor] ∀σ1, σ2 ∈ T ⇒(σ1, σ2) ∈ T

[record type constructor] ∀i|ai ∈ A , σi ∈ T⇒ 〈a1 : σ1, . . . ,

an : σn〉 ∈ T

1The type void represents the empty type; it is included here forpurely technical definitional purposes only. The type has only onevalue, ⊥ : void ( where ⊥ is pronounced as “bottom”).

An expression of function type is a function, where σ1

denotes input type and σ2 the output type, respectively.An expression of set type IPσ denotes a set, with mem-bers of type σ . The pair type constructor comes with aspecial equivalence axiom:

(σ,void) ≡ (void, σ ) ≡ σ,

for any type σ .

Proper states

An SDI node, at a sufficiently abstract level, can becharacterised by a state space S and a function spaceF. We can characterise both as follows. The data storeof the node, holding amongst others all the spatial datasources, is seen as a complex object with data type σ .The definition of σ is the field of spatial data modelling,and we will discuss this in some more detail below.Values s of type σ are possible states of the data store,and because it is typically unacceptable to allow all suchvalues, during the data modelling phase, we identifyconstraints γi(s) that the stored data should obey al-ways. The conjunction

∧i γi(s) of all these constraints

is called γ here.This leads us to a definition of the system state

space S:

S def= {s : σ | γ (s)

}. (1)

The state space is the collection of allowable systemstates. All the designer’s work is in providing properdefinitions of σ , the database structure, and γ , the staticconstraints. From these, the state space S follows.

If the state space of our SDI node is managed as aspatial database, σ classically is a record type of whichthe attribute names function as table names, and thetypes associated with those names are themselves set-of-record types. But this is just the classical set-up, andwe will discuss extensions appropriate to SDI nodesbelow in Section “The introspective perspective: devel-oping an adaptiveand extensible system of systems”.

Proper dynamics

In a similar vein, the function space for the SDI nodemust be seen as a collection of functions that encapsu-late the complex object, and that provide access to it.Such access can be for information retrieval, updates,or combinations thereof. This, obviously, is a ratherclassical view of an information system. To formalisethis perspective on our system, we need to define thepossible dynamics of the system, both in how it replies

304 Earth Sci Inform (2009) 2:299–313

to external requests as in how it reflects requests toupdate itself.

For the time being, we adopt a simplistic model forcapturing allowed dynamics of our SDI node, in thesense that we define only a model for allowed one-step changes. In SDI design practice, this model oftensuffices in capturing most of the dynamic constraints.

This leads to the definition of the system state changespace U :

U def= {(p, q) : (σ, σ ) | (p, q) ∈ S2 ∧ φ(p, q)

}. (2)

The state change space is the collection of allowablesystem state changes, indicating that a state p can turninto state q if and only if (p, q) ∈ U . The formalisationamounts to providing the definition of φ(p, q). Similarto γ for static constraints, φ(p, q) is a conjunction ofseparate dynamic constraints φi(p, q). Each of theseexpresses a specific condition that restricts the new stateq depending on old state p.

Proper functions

The definition of U serves as a backplane of properbehaviour for a collection of functions F that are yetto be defined. These functions must obviously be well-behaved with respect to S and U . These conditions arecaptured in the definition of function space F, in whichwe assume that σ is the defined state structure (as perabove):

F def= {f : (σ, σin) → (σ, σout) |σin, σout ∈ T ∧∀si, so : σ, ti : σin, to : σout |si ∈ S ∧ f (si, ti) = (so, to)

⇒ (si, so) ∈ U}

(3)

A function f is in the function space F if and only if

– it takes as input an allowed system state si : σ andadditional input ti : σin from which it produces anallowed output state so : σ and additional output ti :σin, and

– the one-step state change (si, so) is allowed.

Any function meeting these conditions is an allowedfunction. In practice, a system will offer to its outsideworld a finite collection of functions, known as thesystem’s interface I ⊆ F. Functions in I fall into twocategories: queries and updates. Queries are special in

the sense that they will not (ever) change the systemstate. A function f ∈ F is a query if and only if:

∀si, so : σ, ti : σin, to : σout |f (si, ti) = (so, to) ⇒ si = so.

Finally, we remark that by virtue of the conclusion(si, so) ∈ U in the definition of F, and the definition ofU , we can conclude that an allowed function f can onlyreturn an allowed system state so ∈ S.

Spatial data modelling

Spatial data infrastructures are about sharing geospa-tial data and computational resources, but we have notstated much about the geospatial domain yet. This isobviously important. In this short section, we look atthe geospatial dimension of state-and-function systemdesign.

Spatial data modelling is conceptual data modellingfor information systems, with specific attention for theassignation of spatial semantics to conceptually iden-tified information content. In plain terms, this meansthat we attribute some object classes with one or morespatial characteristics.

For example, creeks may be associated with alinestring attribute, or under a more detailed modelwith a multilinestring attribute, representing all water-ways is a creek watershed. One might even consider toadditionally assign a polygon attribute to delineate thatwatershed as an area. Observe that the above affectsour definition of σ in Eq. 1.

Attribution of spatial characteristics to object classesis only a starting point. Under the state-and-functionparadigm, we continue with identifying constraints tobe expressed over our spatial attributes, as well as overcombinations of related spatial attributes.

Continuing from the previous example, a multi-linestring model for a creek should have all segmentsconnected, while its polygon attribute should allow onlyhole-free polygons, by nature of watersheds. Moreover,the (multi)linestring representation should be spatiallyincluded in the polygon representation. Observe thatthis all addresses the γ part of Eq. 1.

On the function side, finally, we will need to de-vise spatial functions on our information system thataccommodate information needs of the end-users, andfunctions that robustly allow spatial data updates withinthe system. We hope to address the design method forsuch functions in an upcoming paper.

As to spatial update functions, for example, onefunction that allows adding a segment to the creek wa-terway multilinestring will need to verify that the added

Earth Sci Inform (2009) 2:299–313 305

segment is actually connected to the old multilinestring.Moreover, in presence of the polygon representation,that polygon may require expanding to continue sat-isfying the topological constraint of spatial inclusion.Observe that this part addresses which functions f wewill have in collection F of Eq. 3.

Outlook to the horizontal perspective

The vertical perspective defined and discussed aboveconsiders an SDI node to be a complex object systemthat holds a state, and offers functions operating on thestate. At some point, we assume that all the SDI nodeshave been defined in this way.

We continue in the horizontal perspective to lookat how the SDI nodes can effectively form an SDI.Crucial to the community of nodes is a proper definitionof possible forms of communication between them. Tothis end, we apply a process algebraic formalism, suchthat we can describe the SDI nodes and their rolein that communication process, effectively describingallowed ‘conversations’ and appropriate exchange ofinformation.

This brings us to a new paradigm where the things ofstudy are processes, not states or functions.

The horizontal perspective: developinga communicating system of systems

Proper behaviours

Under the horizontal perspective, we define what areallowed forms of communication, or ‘interactional be-haviour’, between nodes in the SDI network. The SDInodes are considered independent systems with theirbehaviour defined in a declarative way. Such a declara-tive definition is what we call a process specification.

In the formalism that we adopt here, a process spec-ification defines a set of possible behaviours, in whicha behaviour is a sequence of actions, ordered in time.An action is either an observable communication or itis an (unobservable) internal event of the node, viewedas a process. A communication indicates a channelover which the communication can take place plus acommunication parameter as placeholder for the com-munication content.

Each SDI node is thought to exist in a world ofits own, and all that it exposes is its behaviour asservices. Services manifest themselves as offerings orconsumptions, and a typical scenario is that one SDInode offers a service that at some point in time is con-sumed by another SDI node. In that service consump-

tion event, information may be exchanged between thetwo nodes. Expanding from the above, we add thathuman users can be service consumers also, and thatmore than two nodes/users can be involved in a singleservice consumption. Moreover, the metaphor of ser-vice offering-and-consumption is an intuitive one fittingservice-oriented philosophy, but some of these eventsare better viewed as the synchronisation of actions thattake place at different systems, involving informationexchange. In other words, there may not be so clearlyvisible roles of consumer or offerer.

Single services, not necessarily offered by the sameSDI node, can be strung together to form a service chainthat satisfies requirements stated by the designer. Inthis context, a service chain represents some intendedprocess logic.

Where service, process, action, channel and commu-nication parameter are terms of the specification world,the terms service execution, process execution, processstep, connection and communicated value are respectiveinstantiation terms in the real-time execution world.A service execution within a chain is called a processunit. Observe that service chains cannot normally beuniquely assigned to a single node, and are betterviewed as ‘behaviour of the SDI network’. Intuitively,a service chain is a designed collaboration between SDInodes.

The behaviour of a service chain has the followingprinciples:

– connections among process units exist only momen-tarily; as a result of the process unit execution, otherconnections between subsequent process units maybe created,

– accessible resources vary over time,– process units interact using synchronous communi-

cation through interfaces, and– the basic mechanism of interaction is message

exchange.

A family of formalisms that provides significantexpressive power to capture these notions is that ofprocess algebras (Bergstra and Klop 1987), with the π -calculus (Milner et al. 1992; Parrow 2001) being onespecific formalism. We have adopted it in this paper,as it has been shown to be extendable and it allowsdynamic adaptation of the process over time, whichappears potentially suitable for applications display-ing a.o. introspection. Ongoing research links the π -calculus with languages for web service specification,such as WS-BPEL, WS-CDL and XLANG, as a seman-tical foundation (Lucchi and Mazzara 2005; Feng et al.2008).

306 Earth Sci Inform (2009) 2:299–313

The formalisation of communication between SDInodes has been neglected by the SDI developmentcommunity, resulting in underdeveloped use of SDIsystems. The premise here is that a precise definitionof the communication logic enables the exploitation ofSDI nodes and produces outputs resulting from instan-tiating process chains that more fully adhere to userrequirements. It follows that the proper specification ofan SDI from the horizontal perspective requires a two-fold approach.

This puts us into position to indicate what are thedesign targets on the process communication front,having indicated S, U and F on the state-and-functionfront.

– For each SDI node i, the process specification Bi

specifies the node’s communication possibilities.This gives us a collection of process specifications,{ Bi }i, one for each SDI node.

– For each service chain j, the process specificationC j specifies the service chain’s behaviour. Collec-tively, we will accumulate a set of such behaviours{ C j } j.

We will add a few comments on these two collectionsafter the technical discussion on process formalismbelow.

Process formalism

In this section, we discuss process specifications in moredepth as they are somewhat unfamiliar in the SDIdomain. Key to the behaviour specification of an SDIare process specifications such as Bi indicated above.

Given the principles listed above, we will tacitly as-sume that members of the set of expressions E , definedabove, can be used as names of communication ports,variables or as data values. These expressions allow usto represent inputs and outputs that can be attachedas prefixes to a service specification. Prefixes stand forconditions associated with the instantiation of a service.

A prefix is either an input, output or silent prefix, andalways follows the α . S form. Prefixes can take thespecific forms shown in Fig. 2.

These prefixes cover the simple conditions that areattached to a unit of behaviour, explicitly specifyingactions that precede the definition. This provides uswith the basis to present an example of two communi-cating SDI nodes. Here, on the left we indicate a serviceconsumer (or client), and on the right a service provider(or server). Their communication over a channel c isdefined through parallel composition (expressed with| , and defined below):

c̄req . C | c(gcap) . P. (4)

This behaviour specification indicates that the con-sumer can send a request message req, after whichit behaves as C, where behaviour C still needs to bespecified. The provider process accepts a message inplaceholder gcap, for get_capabilities, and then contin-ues as behaviour P, defined below.

P def= (τ . BS + τ . IS).

This specification, in turn, states that the provider per-forms an internal operation, that cannot be influencedexternally, represented by τ , and then behaves as aBusy Server service BS and processes the request. Al-ternatively, it internally rejects the request and behavesas an Idle Server service IS. Two extra notational ele-ments appear in these statements:

Parallel Composition P | Q denotes processes P and Qexecuting in parallel, where possible synchronisingon common channels. I.e., P and Q can interactduring the execution or may as well act indepen-dently from each other.

Choice: P + Q denotes a behaviour in which either Por Q is executed.

To illustrate the use of the language, we presentthe formalisation of a simple but typical example ofan OGC Web Service (OWS) interaction, namely a

Fig. 2 Action prefixes of the applied process algebra

Earth Sci Inform (2009) 2:299–313 307

find-bind protocol, in which a user connects via a geo-portal to find a geoservice offered by a server, and thenconsumes it. That server may offer various services.This is an example of a service chain process C j, as wewill discuss in Section “Revisiting the design targets forcommunication processes”. The chain involves threeSDI components: the user node, the geoportal, and theserver. A specification of all the components of thischain can be formalised as follows:

OWS_SERVICEi()

def= [gconn][gcap][gserv][cri][sri](

USER(gconn, gcap, gserv)

|!GEOPORTAL(gconn, gcap, gserv, cri, sri)

|!GEOSERVERi(cri, sri))

(5)

This service chain OWS_SERVICEi is defined asthe composition of various constituent elements of thedesired service. It starts by defining a set of globalchannels that are used by the different service compo-nents to interact. The channel gconn serves for userconnection and identification, allowing, a.o., the userto identify herself and the geoportal to assign a set ofprivileges. The channels gcap and gserv represent theinterface the geoportal makes available to service users.They respectively serve to carry a request for metadata(a get_capabilities request) and a request for a specificgeoservice (a get_service request). Both channels aretherefore passed as arguments to the GEOPORTALand USER services. To be clear a get_service requestrepresents a service call from a client to one of theoperations offered by OGC-compliant services. Thechannels cri and sri represent the interface betweenthe geoportal and a geoservice provider. They are alsopassed as parameters to those respective services.

USER(gconn, gcap, gserv)

def= [rc][ro](gconn(userid, . . .)

|gcap(req_c, rc)

|rc(res_c).gserv(req_o, ro))

(6)

The USER service creates two restricted channels rcand ro that are used by the geoportal service to sendresponses to the user. The gconn channel is used tocreate a connection to the geoportal. Once connected,the USER service makes a metadata request using theget capabilities channel gcap and waits for the responsethrough the rc private channel. The metadata request

content is represented by the req_c parameter. Whena response arrives over the private channel rc(res_c),it is processed and (if applicable) a geoservice re-quest is sent over the channel gserv, providing againa response channel ro. The parameter req_o in thegeoservice request gserv(req_o, ro) can be instantiatedwith any of the operations exposed by OGC compliantservices. For example a ‘GetFeature’, or a ‘GetMap’ or a’DescribeFeatureType’ operation.

GEOPORTAL(gconn, gcap, gserv, cr1, sr1, cr2, sr2)

def= [rgc1]rgs1][rgc2][rgs2](

gconn(userid, . . . ).P_CONNECT(. . .)

|gcap(req_c, rc).(P_CAPABILITIES(req_c, rgc1).

rc(res_c)

|GEOPORTAL(gcap, gserv, cr1, sr1, cr2, sr2))

|gserv(req_oi, roi).(GEOSERVER1(req_o1, rgs1).

ro1(res_o1)

|GEOSERVER2(req_o2, rgs2).ro2(res_o2)

|GEOPORTAL(gcap, gserv, cr1, sr1, cr2, sr2)))

(7)

The GEOPORTAL service exposes three processesthat are respectively used to connect to the geopor-tal, to query metadata and to consume a geoservice.Upon receiving a metadata request gcap(req_c, rc)the geoportal instantiates the capabilities processP_CAPABILITIES(req_c, rgc1).rc(res_c) and creates aduplicate of itself to become available for otherrequests. The result of processing a capabilities re-quest is returned to the user using the correspond-ing response channel rc(res_c). Alternatively, whenthe geoportal process receives a geoservice requestgserv(req_o, ro), the geoserver process is instantiated.The set of pairs cri and sri represent the channels usedby the geoportal to communicate with various serviceproviders. In the specification above, we have depictedtwo possible geoserver services, GEOSERV ER1 andGEOSERV ER2. Again the geoportal replicates itselfupon receiving a geoservice request, so that it becomesavailable for further requests.

We continue by specifying one more level ofdetail for the GEOSERVER process. Clearly, aGEOSERVER service can evolve into different ser-vices, depending on context and inputs. To differentiatebetween the cases, we use the Match (=) operator thatallow us to express guard conditions. In our particularexample, we assume that IS can evolve into different

308 Earth Sci Inform (2009) 2:299–313

services, a web coverage service WCS, a web featureservice WFS or a web map service WMS, etc.

GEOSERVER1(cr1, sr1)

def= (cr(req_c, rgc1) . CSW(. . .)

| sr1(req_o1, rgs1) .([req_o1 = ‘gc’] . WCS(. . .)

+ [req_o1 = ‘df’] . WFS(. . .)

+ [req_o1 = ‘gm’] . WMS(. . .)

+ [req_o1 = . . .]).rgs1(res_o1)

|GEOSERVER1(cr1, sr1))

(8)

The geoserver process can be triggered with twodifferent inputs. If the input cr(req_c, rgc1) is received,the metadata service CSW(. . .) is instantiated. Whenthe GEOSERVER1 process receives a geoservice re-quest sr1(req_o1, rgs1), it checks for the type of in-put. The process can be invoked with different values.Equation 8 depicts three values: gc, df and gm. The pa-rameter values represent a GetCoverage, DescribeFea-tureType and GetMap operation request respectively.The replacement of the given parameter will trigger theinstantiation of one of three potential Server servicesWCS, WFS or WMS. Equation 8 also contains the term[req_o1 = . . .], which depicts that a other parametervalues can be used. We have purposely omitted some ofthe detail of the specification. All details of the servicecan be presented in a full-fledged specification of theservice, but this falls beyond the purpose and scope ofthis paper.

Revisiting the design targets for communicationprocesses

After this discussion of the formalism for communi-cation process specification, we can make more ex-plicit how members of the sets { Bi }i (the SDI nodeprocesses) and { C j } j (the service chains; indices jdistinct from indices i) can be specified, and how thisresults in the overall behaviour of the SDI network.

The design targets are the process specification Bi

for each SDI node i, as well as the service chains C j.For either of these processes one typically encountersthe specification template

Service def= ! c(x) . Si,

where Service is either a Bi or a C j, c is the inputchannel at which the service is listening, and Si denotesthe actual service process. Service chain processes C j

may be ‘hosted’ by a separate chaining server.

To do justice to the formalism, we need to also in-troduce a final notation, known as guarded generalisedsum, denoted by

∑. Its informal definition states that

∑

i

πi Pi = π1 P1 + · · · πn Pn,

where each πi is an input, output or silent prefix, andeach Pi is another process expression. We assume thatn is known from context.

This now allows us to finalise the behaviour B of theoverall SDI network as

B def=∑

i

πi Bi +∑

j

π jC j.

The prefixes function as guards, allowing to identify theproper subprocess.

A mirror look at state-and-function systems

At this stage, the question is how an SDI node seen as astate-and-function system relates to the same node seenas a communicating process. We provide an intuitiveanswer to this question only.

If we take another look at the client-server commu-nication expressed in the process expression (4), wherec is the name of the channel over which the clientcommunicates with the server, one may look at it asthe name of the service offered. That, in a state-and-function system, translates to a corresponding functionf being offered in the system’s function set F. So,naïvely channel names (like c) correspond with func-tion names (like f ), and our design should indicatethat correspondence. This can be achieved, obviously,by a naming convention that is enforced in the designmethod.

Caring to take a somewhat less naïve look, we couldfunctionally interpret the action c̄r as a request forservice by the client, thus something that could berealised as a remote procedure call. In the same vein,the action c(gcap) could be read as the reception of aservice request by the server.

This example shows that in our specification, wehave separated service requests from service responses,the latter not occurring yet in our example. So, thisconstitutes an important footnote to the one-to-onecorrespondence of channel names and function names:in the above specifications, the channel c corresponds tothe service request (only), and another channel may beassociated with the service response. Again, a namingconvention can ease the art of specification by linkingrequests and responses somehow name-wise.

A second footnote is that a single function might as-sociate with different channels, each channel using the

Earth Sci Inform (2009) 2:299–313 309

function somewhat differently, for instance, throughspecific choice of passed-on parameter values.

Outlook to the introspective perspective

Given the above framework, we can in principle designand realise single SDI nodes, so also a community ofthem, as well as design and realise the communicationinfrastructure for the community. This typically sealsthe case.

But there is more to a spatial data infrastructurebecause the resources available in it (data and re-lated computational sources) come with one importantcharacteristic: the resources’ metadata. The metadatais critical because it is fundamental to decisions ofaptness-for-use of the resources that they describe,whether true data, models or other geospatial services.As a consequence, a service specification may need todisplay intelligence in exploiting these resources, andchange its process structure accordingly. It is for thisreason that we also address the need for introspectivefunctionality.

As we will demonstrate in a lightweight mode, ourchoice of formalism above is an appropriate one totackle these issues.

The introspective perspective: developing an adaptiveand extensible system of systems

SDI nodes and their introspection

A first issue is how a single SDI node can be de-signed and realised to display also introspective prop-erties. Our approach is to refine the framework ofSection “The vertical perspective: developing state-and-function systems”. More specifically, we sketchhow state-and-function systems can display local intro-spection.

The fundament for this is to identify descriptiveinformation about the system state and functionality asbeing part of the state itself. In blunt terms: metadata isjust data to be represented inside the system state. Thisis expressed in

σ ≡ σdata ⊕ σmeta,

where σ corresponds with same from Eq. 1, and ⊕denotes type concatenation. The type language mayrequire extension to facilitate the definition of σmeta.For instance, one can imagine the inclusion of addi-tional types like iso19115 (for data), iso19119 (forservices), WS-BPEL or OWL-S (for service chains), andderivatives (such as iso19115 profiles) of this. Those

types will typically take the form of XML schemas, eachof which will be subject to a specific constraints.

Further, we distinguish between intrinsic and extrin-sic metadata. Intrinsic metadata can be automaticallyderived from the data structure or service functionality,such as bounding box and attribute type names. Ex-trinsic metadata are annotations, such as service accesspoint and organisational contact details.

Continuing with the reformulation of Eq. 1, γ (s) de-serves a similar treatment. A simple syntactic analysiswill lead to reformulation as

γ (s) ≡ γdata(s) ∧ γbridged(s) ∧ γmeta(s).

This expresses that fact that some constraints are puredata constraints, a number are bridged constraints, andothers are pure metadata constraints.

Pure data constraints are well-known. Bridged con-straints express consistency between stored data andmetadata, essentially forcing the metadata to be correctdescriptors of the data, as well as of the functionsoffered by the SDI node. Bridged constraints typicallyaffect only intrinsic metadata. Metadata constraints arethose amongst the metadata, some of which are in-herent to the metadata type definition (e.g., iso19115),others reach beyond it. They may for example restrictcoordinate system expressions (e.g., by valid EPSGcodes), data attribute types (based on formal classifi-cation), and service quality parameter types.

Just like we detailed the definition of constraint γ

above, we could detail out the definition of the dy-namic constraint φ(p, q) of Eq. 2. Interestingly, wheredynamic constraints are often uncommon on ordinarydata, they are not so much on metadata. Especiallywhen it comes to lineage characteristics one expectsthat a formulation of φmeta(p, q) expresses some formof historic monotonicity on the lineage properties.

After this extension of the state space definition, weturn to look at the functions offered by the SDI node.We use the same distinction as before, and recognisepure data functions, bridged functions and metadatafunctions.

The data functions operate only on the σdata part ofthe state, and are the ‘routine functions’. More interest-ing are the bridged functions, which query/update bothdata and metadata. They are typically needed in twoscenarios:

1. When metadata intelligence is required to deter-mine output of the function, for instance, when themetadata is required to determine which data isused for the result;

2. When an update on the data requires the metadatato be updated as well, typically as a consequence

310 Earth Sci Inform (2009) 2:299–313

of existing bridged constraints. One can view thisclass of functions as ordinary update functions thattrigger metadata updates.

The metadata functions are also an interesting class.These function operate on metadata only. Again, twoscenarios appear to be the most likely:

1. Metadata queries probe the system for its resourcecharacteristics, and form an important foundationfor initial communication between systems. Onemay think of getCapabilities requests, and othersin that family.

2. Metadata updates in their pure form are thosewhich affect extrinsic metadata, such as the changeof organisational contact details or the change ofURL as service access point.

SDI network introspection

With SDI node-specific introspective functionality inplace, as per above, these nodes can be addressed forordinary data and computational services, but also forintrospection. This brings service chaining and serviceorchestration into view.

In service chaining, services of different providersare joined to form a more encompassing service. Theconditions of joining should be verified, and are usu-ally expressed as conditions over the metadata of theservice providers. This verification should be done atdesign time, and lead, where necessary, to run-timemetadata conditions. One also expects that the servicechain is monitored by a system itself, typically differentfrom the main service providers in play. Such a servermight be called a metaserver. Metaserver functionalityis typically restricted to a subset of SDI nodes. Withinthe SDI network a hierarchy of nodes must be de-fined, properly controlling the workflows and dataflowswithin it.

Things become even more interesting when serviceswithin a service chain are not decided upon at time ofdesign of realisation, but are dynamically determinedat run-time. In this context, we then speak of ser-vice orchestration, and in light of the present paper ofthe design of the orchestration. The metaserver thatmonitors the (now more dynamic) service chain needsto exploit the full introspective capability of potentialservice providers to identify one or more realisations ofthe chain.

It is interesting to note that the π -calculus for-malism with which we described communication mech-anisms in Section “The vertical perspective: developingstate-and-function systems” intrinsically provides for

such dynamics. We finish this section with an illustra-tion to that extent.

A typical introspective scenario is followed in thepublish-find-bind paradigm. Timewise, this should readthe ‘publish——find-bind paradigm’, as publishing hap-pens at a separate point in time. It involves a communi-cation of a provider to register a service with a catalogserver.

In the second and third legs, find-bind, a catalogservice is requested to identify appropriate service pro-visions for getting the overall wanted service. At thisstage, the service that eventually will be consumed isunknown. In terms of our Section “The vertical per-spective: developing state-and-function systems” for-malism, this means that the channel associated with thateventual service consumption cannot yet be named.

The scenario unfolds for instance in a communica-tion between a Catalog Server and an XService Server.The communication between the two takes the shapeof the following composed process, leading to synchro-nisation over channel f :

f̄ b . CS | f (z).z̄a . XS.

This statement expresses that the Catalog Serverservice, having found a candidate service b , sends thisinformation along channel f (for ‘found’); the XServiceServer receives the link through channel f and thenuses it as a channel itself(!), as expressed in z̄a, uponwhich it behaves as XS. One should understand thisbehaviour as a variable z that gets instantiated, and issubsequently interpreted as a channel (=service) name.

As a point in case, Fig. 3 illustrates a scenario inwhich a service chain implements map schematisation,similarly to what is often done for city transport maps.In this case, we are providing a schematic overviewof navigable waters, distorting intentionally the spatialcorrectness as in the London underground map. Themap allows river boat travellers to view their options.The service chain involves the SDI nodes A, B, C and D.For each node, we specified a communication patternsimilar to that of process expression 4. For example,the fundamental communication patterns of A and Bare specified as:

A def= ! c̄1r . c4(s) . c5(u) . c6(v)

B def= ! c1(r) . c̄2s . c3(u) . τ . c̄4v

And services C and D being defined in similar style.The service orchestration in this scenario is typically ofthe form

A | B | C | D.

Earth Sci Inform (2009) 2:299–313 311

Fig. 3 Service chainingscenario for mapschematisation (adaptedfrom Hobona et al. (2009))

A metaserver of type Workflow Server will be re-sponsible for such orchestration, for which it makesuse of allowed workflow patterns in the SDI network.Additional metaserver functionality is the computationof metadata propagation in the service chain. Suchmetadata calculations will be restricted to proper statesand dynamics as defined in Sections “Preliminaries”and “Proper states” (on specific metastates/dynamics).

Discussion and future work

Merging horizontal and vertical designs

Our discussion of horizontal and vertical designs hasbeen intentionally abstract, for two reasons. First, spacelimitations prohibit the provision of full details on thedesign methods. We are currently developing a fullmethodical framework with a prominent role for ageospatially flavoured UML using OCL as the con-straint language. Designs in that framework will be sub-jected to property-preserving transformations, allowingdesign alternatives, to arrive at trustworthy state-and-function systems. Similarly, work on process-algebraicdesigns for communication within SDI is underway.

A more important, second reason for our choiceof abstraction lies in the required correspondence be-tween functions from the one perspective, and ser-vices and communications from the other perspective.That correspondence appears natural at first, but isnon-trivial when one gets to the details. Specifically,

one needs to decide whether a service request-and-consumption is better specified as a single synchronousaction in the SDI, or as a pair (request, response)of such actions. The methodological ramifications ofeither choice are unclear, and deserve further study.

Merging in the introspective design

Of specific interest in geospatial web service systemsare the advanced metadata formats, and what can bedone with them. Again, the spatial data and metadatadeserves special attention as the aptness-for-use is gen-erally a complex question, even more so than in regularweb service systems (Schwinger et al. 2008).

It is an open issue how spatial web services arebest characterised to allow their full exploitation. Itis unlikely that the full semantics of the specificationcan ever be totally captured in metadata. The sameholds for service chains, service orchestrations andservices that offer service orchestrations. Here, onequickly reaches the realms, as well as boundaries, ofthe web beyond Web 2.0 (Raman 2009), for instancewhen introspection into the introspective capabilities isrequired.

Summary of the paper

This paper is about the ‘design theory of SDI systems’.We believe that such a theory is not in existence,and that given the demanding requirements in SDI—full interoperability, advanced data types, advanced

312 Earth Sci Inform (2009) 2:299–313

functionality, deep semantics, and long lifetimeexpectancy—we must urgently make a start atconstructing such a theory. It will hopefully allow usto build our SDI systems in more controlled ways, orrebuild them in those ways.

In the paper, we pass in review the various char-acteristics of a proper design theory. In brief, theseare completeness, abstraction, separation of concerns,repeatability, implementability, formal mathematical ba-sis and last but not least solid grounding in the geoin-formation domain. Under these conditions, methodsof transformational design can be developed, and weprovide illustrations of these.

Why do we emphasise the need for a design theoryin the SDI domain? Well, SDI systems are typicallycomplex, and are being built to last. They will outlivethe technology and standards that we use for theirimplementation today, and when we are going to ‘up-grade’ these systems later in their life cycle, it willbe extremely useful to be able to fall back to maturedesign documents, in which the technology-of-the-dayhas been factored out through abstractions. The designof a complex system should, after all, be largely inde-pendent of the state-of-the-art technology.

But a design theory can serve other purposes thanproviding rationale for design and development steps ofa system. It can also be used as a yardstick against whichto hold already implemented systems, in retrospect, soas to understand more fully what the system is achiev-ing, and what not. This is important because many SDIsare not at all the result of fundamental top-down de-sign, and their history is rather more one of organismalgrowth and fine-tuning between its components.

Any design theory applies a generic paradigm for theartifacts that are its domain of study. We look at an SDIas a community of collaborating and communicatingsystems, each of which displays geoinformation needsand/or offerings. This gives us two important dimen-sions to SDI:

1. SDI as a network of communication, and2. SDI as a constellation of network nodes.

Consequently,The development of a design theory for SDI does not

need to fall on infertile ground. After all, communica-tion networks have been built before, and commonlywith a design theory in the background. Likewise, webservices-enabled information systems, which SDI nodesare, are also commonplace nowadays, and much of theirdesign is based on appropriate formalisms.

Acknowledgements We are indebted to two anonymous re-viewers of this paper, for their suggestions for improvements, andpointing out a number of inconsistencies in the original paper.We thank Fred Fonseca and Clodoveu Davis for their invitationto submit and their patience in handling our submission.

References

Annoni A, Friis-Christensen A, Lucchi R, Lutz M (2008) Re-quirements and challenges for building a European spatialinformation infrastructure: INSPIRE—Towards the spatialsemantic web. In: van Oosterom P, Zlatanova S (eds) Creat-ing Spatial Information Infrastructures, CRC Press, Taylorand Francis, pp 1–18

Arpinar IB, Sheth A, Ramakrishnan C, Usery EL, Azami M,Kwan MP (2006) Geospatial ontology development and se-mantic analytics. Trans GIS 10(4):551–575

Astrahan MM, Chamberlin DD (1975) Implementation of astructured English query language. Commun ACM 18(10):580–588

Bergstra J, Klop J (1987) ACP: a universal axiom system forprocess specification. Cent Wiskd Inform 15:3–23

Bernard L, Kanellopoulos I, Annoni A, Smits P (2005) TheEuropean geoportal—one step towards the establishmentof a European spatial data infrastructure. Comput EnvironUrban 29(1):15–31

Brodersen L (2008) Geo-communication and information design.Forlaget Tankegang A/S

Carrara P, Fortunati L, Fresta G, Gomarasca M, Piazza BL,Poggioli D (2004) A methodological approach to thedevelopment of applications in a SDI environment. In:Proceedings of the 7th AGILE Conference on GeographicInformation Science, Heraklion, Greece

Codd E (1970) A relational model of data for large shared databanks. Commun ACM 13(6):377–387

Craglia M, Goodchild MF, Annoni A, Câmara G, Gould M,Kuhn W, Mark D, Masser I, Maguire D, Liang S, Parsons E(2008) Next-generation Digital Earth: a position paper fromthe Vespucci initiative for the advancement of geographicinformation science. International Journal of Spatial DataInfrastructures Research 3:146–167

Crompvoets J, Bregt A (2003) World status of national spatialdata clearinghouses. J Urban Reg Inf Syst Assoc 15(APA1):43–50

Davis C, Fonseca F, Câmara G (2008) Understanding globalchange: the role of geographic information science in theintegration of people and nature. In: Proceedings workshopSDI for the Amazon, position paper

de Man W (2006) Understanding SDI; complexity and institu-tionalization. Int J Geogr Inf Sci 20(3):329– 343

Feng Z, Yin J, Zhou J (2008) E-business processes compositionbased on pi-calculus technology. International Symposiumon Information Science and Engineering 2:224–227

Georgiadou Y, Puri SK, Sahay S (2005) Towards a potentialresearch agenda to guide the implementation of spatial datainfrastructures—a case study from India. Int J Geogr Inf Sci19(10):1113–1130

Hobona G, Jackson M, Gould M, Higgins C, Brauner J, MatheusA, Foerster T, Nash E, Lemmens R et al (2009) Estab-lishing a persistent interoperability test-bed for European

Earth Sci Inform (2009) 2:299–313 313

geospatial research. In: Haunert J, Kieler B, Milde J (eds)Proceedings of the 12th Agile internationational conference:advances in GIScience, IKG, Leibniz University of Hanover,Hanover, Germany, p 10

Kroiß C, Koch N (2008) UWE metamodel and profile: userguide and reference. Tech. Rep. 0802, Institute for Informat-ics Ludwig-Maximilians-Universität München, München,Germany, version 1.0

Lance K (2003) Spatial data infrastructure in Africa. GIS Devel-opment July:6 pp

Lehto L (2007) Schema translations in a web service-based SDI.In: Proceedings of the 10th AGILE international confer-ence on geographic information science, Aalborg University,Denmark

Lucchi R, Mazzara M (2005) A pi-calculus based semantics forWS-BPEL. Journal of Logic and Algebraic Programming70:96–118

Maguire DJ, Longley PA (2005) The emergence of geoportalsand their role in spatial data infrastructures. Comput Envi-ron Urban Syst 29:3–14

Masser I (1999) All shapes and sizes: the first generation ofnational spatial data infrastructures. Int J Geogr Inf Sci13(1):67–84

Masser I (2005) GIS Worlds—creating spatial data infrastruc-tures. ESRI, Redlands

Milner R, Parrow J, Walker D (1992) A calculus of mobileprocesses, part I/II. Journal of Information and Computation

100:1–77. http://www.lfcs.informatics.ed.ac.uk/reports/89/ECS-LFCS-89-85/

Mohammadi H, Rajabifard A, Binns A, Williamson IP (2006)Bridging SDI design gaps. Coordinates Magazine 2(5):26–29

Open Geospatial Consortium Inc (2004) Geospatial portal ref-erence architecture—a community guide to implementingstandards-based geospatial portals, version 0.2 edn. OGC04–039, OGC

Parrow J (2001) An introduction to the π-calculus. In: BergstraJA, Ponse A, Smolka SA (eds) Handbook of Process Alge-bra, chap 8. Elsevier, Amsterdam, pp 479–543

Raman T (2009) Toward 2w , beyond Web 2.0. Commun ACM52(2):52–59

Schwinger W, Retschitzegger W, Schauerhuber A, Kappel G et al(2008) A survey on web modeling approaches for ubiquitousweb applications. International Journal of Web InformationSystems 4(3):234–305

Vieira PR, Lunardi OA, Correia AH, Issmael LS (2008) Spatialdata infrastructure for Amazon. In: Proceedings workshopSDI for the Amazon, position paper

Wagner R (2006) A roaming-enabled SDI (rSDI): balancing in-terests, opportunities, investments and risks. In: ProceedingsGSDI–9 conference, Santiago de Chile, Chile

Williamson I, Rajabifard A, Feeney MEF (eds) (2003) Devel-oping spatial data infrastructures—from concept to reality.CRC, Boca Raton