Distinguishing Ontological Frameworks

8/7/2019 Distinguishing Ontological Frameworks

1/16

1

Distinguishing Ontological FrameworksBy Philip Boxer

Introduction

In his paper on the lightweight enterprise, Richard Veryard uses stack architectures to give an account

of the relationships between the various service platforms offered by businesses, and the ultimate

customers of those services [1]. He has the following to say about the height within a stack at which a

business positions itself:

One reason for the difficulty comes from the complexity of the business environment, which

generates complexity in the business stack. The height and configuration of each platform is a

difficult strategic question: too low and you leave a value deficit, too high and you lose the

economies of scale or scope, too inflexible and you cant respond to change.

The stack architecture is a way of aligning supply-side services to users demand-side needs, and just as

SOAs help align services to users needs, so too does mashup technology as a way of generating

lightweight solutions to users problems. In general, however, this approach raises a number of

questions about the nature of the stack itself:

How many layers? How can this geometry be both adapted and adaptable? What is the

appropriate granularity in each layer? What is the rate of change within each layer? How much

coupling is there between layers? What are the trust and security requirements in each layer?

What is the appropriate technology for each layer?

Richard offers a number of viewpoints from which these questions might be answered, including those

of integrating processes or content, of structures of service delegation or of desirable effects for theultimate customer. Implicit in all of these is the ontology underlying the way the stack is built.

In his later paper on Web 2.0 [2], he goes slightly further by clarifying the differing demands on supply-

side and demand-side ontologies:

The supply side needs to be based on a fairly stable canonical data model, which provides integrity

across the architecture. The demand-side may be based on a highly dynamic emergent ontology,

produced using such technologies as tagging and the semantic web. This is sometimes known as

Folksonomy.1

There has to be a relationship between the canonical and emergent ontologies associated with a stack.

So how are we to think about this relationship? This paper argues that there are different kinds of

strategy for relating the supply-side and demand-side, which make different kinds of assumption aboutthe ontological frameworks needing to be supported by the stack architecture.

1See Explaining and Showing Broad and Narrow Folksonomies, Thomas Vander Wal,

http://www.personalinfocloud.com/2005/02/, Feb 2005. For a fuller commentary see Collaborative thesaurus

tagging the Wikipedia way, Jakob Voss, Wikimetrics research papers, Vol 1 issue 1. April 2006. Essentially, a

demand-side ontology emerges from a collaborative tagging process.
http://www.personalinfocloud.com/2005/02/http://www.personalinfocloud.com/2005/02/http://www.personalinfocloud.com/2005/02/


2/16

2

Types of ontological framework

In addressing the question of ontologies and the nature of the stacks within which they emerge, a good

starting-point is the following on semantics [my italics]:

On the way to information systems integration in an ever growing distributed world,

developers come face to face with one of the earliest and most venerable disciplines:semantics. SOAs, armed with suitable descriptive languages and powerful reasoning

algorithms, provide a solid and standardized basis that facilitates the design and

implementation of semantics-enabled IT infrastructures. Nevertheless, at the current state of

the art, although service-oriented infrastructures are rapidly becoming a reality, the adoption

of specific frameworks to address the semantic layer is still at an early stage. Many kinds of

difficulties hinder the acceptance of semantic-oriented artifacts, technologies, methodologies,

practices, and standards.Above all, we believe that the lack of awareness of what semantics is,

why it is important, and how it could be modeled constitute the most significant obstacles in its

application to the semantic layer of service-oriented infrastructures.[3]

This paper defines ontology as a representation of a set of concepts within a domain and the

relationships between those concepts, used to define the domain and to reason about its properties.2

Viewed from the perspective of formal semantics, this approach to defining ontology assumes that

meaning can be defined strictly in terms of some combination of behaviors, referents and axioms3 in a

way that can be made speaker-independent if not domain independent. In their paper on why it is that

standards are not enough in managing interoperability, Lewis et al [4] construct the following stack to

point out the limits of standards:

Figure 1: Why standards are not enough

Essentially, ontologies are defined within the first three layers of this stack, with behaviors defined by

the content of level 1, referents by layer 2 in relation to 1, and axioms by layer 3 in relation to layers 2

and 1, but ultimately by the way all three layers reference layer 0 the world itself. This leaves open

the question of how the definition of these layers is embedded within a particular organizational context(layer 4). An examination of OWL-S has shown the limitations of this process of definition, and its

ultimate dependency on the social context within which definitions are situated [5]. This dependency is

2Adapted from http://en.wikipedia.org/wiki/Ontology_(computer_science).

3These are operational, denotational and axiomatic semantics respectively see

http://en.wikipedia.org/wiki/Formal_semantics_of_programming_languages

layer 1: Machine Level Interoperability(lexis)

layer 2: Syntactic Interoperability(language syntax)

layer 3: Semantic Interoperability(shared understanding of meaning)

layer 4: Organizational Interoperability(shared understanding of organizational processes)


3/16

3

not only on the definition of the domain itself, but also on the scope for social agreement on any

hypothesized definitions about the ontology of that domain. Practically speaking, this means that such

an ontological approach is limited, at best, to the first three layers, and even there limited in its scope.

So what does this mean for the stack architecture?

The approach taken here is first to consider the organizational layer 4 to be discursive in nature,

understood in terms of discourse semantics [6, 7]. This discursive layer is then placed within a

pragmatic situation in which some particular effect is being generated in relation to some context of use

associated with the customers of the organization. This adds layers 5 and 6, layer 5 being a constraining

of layer 4 according to the pragmatics of addressing layer 6 [8] (see Appendix I for definitions of the

terms used in Figure 2):

Figure 2: The layers of a stack architecture

Layers 1-3 are definable in terms of a formal semantics, represented by the pyramid in Figure 2. There

can be any number of these pyramids, depending on how they have been defined by their systems, but

each one corresponding to a framework based on layers 1-3. This is a type I ontological framework(arrow 1 in Figure 2). An example would be a balance enquiry service provided by a bank. The

relationships established between these type I ontological frameworks that are specific to an

organization then define a type II ontological framework (arrow 2 in Figure 2). An example would be a

mashup combining a booking service, a credit card charge, a hotel availability service and a mapping

service.4 Such a mashup would support a particular customers need to link together systems in order to

make a booking that satisfies their need for a weekend break. Note that this is a type II ontological

framework which leaves the customer with the task of managing the pragmatics of determining the

usefulness of the outputs of the service.

Finally the relationship between these type II frameworks and their particular pragmatics of use by the

customer define a type III ontological framework (arrow 3 in Figure 2): the way the service is delivered

to the customer is mediated by data that is specific to his or her needs, as we find in social mashups, but

also in situational applications such as supporting a particular doctors clinic. In each case, the

ontological framework is defined not only by the formal semantics of a given service (which may take

4http://www.programmableweb.com/mashups/directoryshows a directory of mashups in the public domain.

layer 1: Machine Level Interoperability(lexis)

layer 2: Syntactic Interoperability(language syntax)

layer 3: Semantic Interoperability(shared understanding of meaning)

layer 4: Discursive Interoperability

(shared understanding of organizational processes)

layer 5: Pragmatic Interoperability(the way the situation is engaged with)

layer 6: Context-of-use(the context in which the effect is experienced)

formal

semantics

2

1

3
http://www.programmableweb.com/mashups/directoryhttp://www.programmableweb.com/mashups/directoryhttp://www.programmableweb.com/mashups/directoryhttp://www.programmableweb.com/mashups/directoryhttp://www.programmableweb.com/mashups/directory


4/16

4

the form of an API), but by the way that ontology is then modified by constraints particular to

constraints introduced by discursive and pragmatic considerations.

Ontological Framework 1.0

In its use of the ATAM method, the Mitre Corporation concluded that it found the ATAM [9]a useful

method for assessing a software architecture against known quality criteria established by the contract

and the stakeholders[10]. The overall approach used by ATAM is as follows:

Figure 3: The ATAM Method

Essentially the method asks a number of questions (quoting from the Mitre paper):

What are the driving architectural constraints, and where are they documented; what

component types are defined; what component instances are defined by the architecture; how

do components communicate and synchronize; what are the systems partitions; what are the

styles of architectural approaches; what constitutes the system infrastructure; what are the

system interfaces; what is the process/thread model of the architecture; what is the deployment

model of the architecture; what are the system states and modes; what variability points are

included in the architecture; how far along is the architectures development; and what is the

documentation tree?

These are good questions to ask of any system within the context of the requirements that it is designed

to support, and reflect an approach that is ultimately going to be able to establish the formal semantics

of the system. Even without reaching that degree of formalism, however, examining the quality

attributes of the way a system meets its requirements tells a great deal about the way the architecture

is able to support demands to provide new services, for example:

Flexibility compatibility with other systems; Scalability number of links supported;

Modularity framework architecture; Interoperability with external interfaces; Extensibility

ability to accommodate growth and changes in future increments; Consistency easy to use

consistent HMI; Portability Linux, NT platforms; Reliability ensure compliance and providemetrics on progress to meet availability; and Producibility produce different configurations of

the final system to satisfy operational conditions.

But it is still a single system being examined within a Type I ontological framework. What are the

challenges that have to be faced when dealing with a system of systems environment in which a single

organizational model cannot be assumed for the way services are to be combined?


5/16

5

Ontological Framework 2.0

A mashup is a Web technology-based lightweight composite application created by sourcing

capabilities from established content and systems functionality[11]. The architecture supporting

mashups has the following characteristics [12]:

Figure 4: Mashup reference architecture

The normal user interface to a Type I ontological framework is the yellow layer at the bottom. Added to

this are the layers associated with the Community Environment across whom mashups are being

supported. Thus, continuing to quote from Gartner [12], these mashups have the following

characteristics:

Lightweight composite applications using Web Oriented Architecture (WOA); Content orFunctionality is Sourced from Existing Systems; Result is an explicit mixture of sourced content

and functionality; Presentation layer Web Browser-based Integration. Noninvasive and

Emergent; Opportunistic vs Systematic Applications; Dynamic and Tactical.

The core benefits expected from their use include faster application development, heavy reuse of

existing capabilities, achievable composite applications, and the promise of user-driven application

development.

The importance of shared discursive practices common sense

There are a number of suppliers active in this field [13] and a number of issues that have to be

considered in preparing for their use, most important of which is the difficulty of determining where

the enterprise stops and the Web begins[14]. From the point of view of the web user, this is a

question of how the enterprise is defined. It is no accident that the first generation of mashups have

formed ecosystems of applications that cluster around such applications as Amazon, Google and MSN.

The following landscape shows this, based on data from programmableweb [15]:


6/16

6

Figure 5: Interoperability landscape for mashups

These mashups define Type II ontological frameworks because the ontology of each individual (Type I)

service is sufficiently commonsensical to allow their layer 4 organization to be imposed in a way that is

independent of the way the mashup is used in particular situations [16-18]. These are the emergent

ontologies associated with folksonomies (see footnote 1 above), since while the different combinations

of service will reflect differing pragmatics, the overlapping patterns of mashup will reflect emergent

forms of social (discursive) organization across the population of mashup users.

Planning for situational applications

The way IBM refers to mashups is as a new breed ofsituational application[19] that solve business

challenges that were low priority or unaffordable from a pan-enterprise perspective. This is the

challenge ofthe long tail[20] where applications become increasingly one-off as they adapt to the

specific (pragmatic) needs of the user. We are therefore dealing with the increasing economies in the

economics of alignment brought about by web-enablement (see Appendix II for definitions of these

economics contrasted with those for scale and scope). This is the world of end-user computing, of

which the distinguishing characteristics are user communities of interest that also characterize multi-

sided markets [21]. This creates what IBM refers to as a Situational Applications Environment(SAE) that

combines internal and external (to the enterprise) services in situational applications that have

important implications for (community-based) governance, tools and infrastructure.

Thus for an enterprise to design for leveraging web-based services and content as resources for

mashups, it needs to be able to consider a number of questions:Requirements - what mashups will be valuable to the enterprise; Design - how are systems to be

configured, and what enabling technology and standards are to provide the best platform;

Governance - how is lifecycle management to be applied to the community of mashups

themselves; Security - there has to be a systematic security policy and technology layer that will

protect value; Deployment - how will technology link with the governance and security needs;

and Testing - how are composite applications to be tested within the above context?


7/16

7

All of these questions imply taking a demand-side view of the services and their potential variety of

uses. And as long as the ontologies of the individual services overlap sufficiently across the relevant

community of users, then this will create value beyond developing applications one-by-one. IBM argues

that under these conditions, these situational applications need three distinct types of role [22]:

Mashup enabler: The mashup enabler writes the widgets and adds them to the catalog. Theydialogue with the assemblers to anticipate their needs and add the appropriate services both

retroactively and proactively. This is usually an individual from the IT department or someone

with sufficient technical skills to write software.

Mashup assembler: This is typically a nonprogrammer that's a line-of-business user or subjectmatter expert. The mashup assembler builds mashups by wiring together the mashup

consumables that have been created by the mashup enabler.

Knowledge workers: This is the community that uses the application for its intended purposeand employs community mechanisms on the application, such as ratings and comments, to

provide feedback so the application can be improved on the next iteration.

The primary focus of concern shared by these roles is data fusion: the bringing together of processesand data around the particular situation in a way that is relevant to the particular situation being

addressed creating understanding and insight into the nature of the situation itself. This is the

underlying issue presented by situational applications, relating to how the ontological framework is

defined. Thus IBM points out [my italics]:

Qualitative surveys suggest that the number one enterprise IT concern today is data

integration within the enterprise virtual organization. (In this context, I use the term virtual

organization to mean a composition of federated business units, each contained within its own

administrative domain.) Like many enterprise IT managers who find themselves up to the task

of integrating legacy data sources (for example, to create corporate dashboards that reflect

current business conditions), mashup developers are faced with the analogous challenges of

deriving shared semantic meaning between heterogeneous data sets. Therefore, to get an idea

for what mashup developers have in store, you need look no further than the storied

integration challenges faced by enterprise IT.[23]

This is the challenge of data fusion. Once the user goes beyond the position of shared common sense

that characterizes the world of collaborating enterprises, whether that common sense is particular to an

enterprise, or more widely shared, the user must consider the challenges of composing data and

processes from disparate sources.


8/16

8

Ontological Framework 3.0 managing data fusion

The GAO report on Geospatial Information [24] had the following to say on the multiple challenges of

bringing together geospatial data in a way that was relevant to Wildland Fuels and Fire Management:

1. Geospatial data is not consistently available and not compatible across different agencies, statesand local entities.

2. Agencies are developing multiple duplicative systems, many of which are not interoperable.3. There are inadequate infrastructures for accessing and manipulating data.4. There exist major differences in the quality of GIS know-how available locally.5. There is low awareness within the Wildland Fuels and Fire community of the new products and

services available.

The recommendation the GAO report made was to develop an enterprise architecture. Such a type I

framework would have had a significant impact on 1, 2 & 3 above, and insofar as they were deployed in

a way that supported web-enabled use (such as through an SOA approach), they would also have begun

to meet the demands of the community in 4 & 5 above, at least for reporting and visualization purposes.

The GAO recommendations were slow in being implemented by most of the federal agencies whomanaged land, but standardization and interoperability were facilitated by the fact that most people

used ESRI software5. But an enterprise architecture alone would not have been able to support the

situational needs of this community, given the multiple enterprises involved (see Appendix III for a

summary of the limitations of an enterprise architecture exemplified by Zachman).

The distinguishing characteristics of data fusion

The distinguishing characteristic of the forms of data fusion being undertaken by the Wildland Fuels and

Fire community was the presence of allometric scaling across the inputs and outputs of its models (see

Appendix IV). This was indicative of the complexity in the systems being observed, and was what

prevented the use of a general ontology (qua common sense) in how data could be fused across models.It was this complexity that challenged the universal approach to ontology that characterizes the Type I

and Type II ontological frameworks.

Related to the need for allometric scaling was the nature of the scales themselves. To assert the

commensurability of two systems, there must be a scaling relation between measurements of the two

systems. For the purposes of data fusion, a criterion of commensurability needs to be established

between the input and output variables mediated by a particular system or model that each system or

model must establish commensurability across its inputs and outputs. When applied to projective

analysis, this gives a criterion for establishing whether or not a particular data fusion is possible: it has

to establish scale commensurability and scope consistency between the input and outputs of each

model, tool and dataset being used in support of a situational application, placing primary emphasis on

the nature of the observations being fused.

5Seehttp://en.wikipedia.org/wiki/ESRI
http://en.wikipedia.org/wiki/ESRIhttp://en.wikipedia.org/wiki/ESRIhttp://en.wikipedia.org/wiki/ESRIhttp://en.wikipedia.org/wiki/ESRI


9/16

9

Conclusion

The data fusion associated with Type III frameworks contrasts with Type I and II approaches based on

defining the ontology of the data that is being fused in terms of its formal semantics. Thus inputs and

outputs are semantically matched [25], something that is referred to elsewhere as syntactic

interoperability [26] in order to contrast it with semantic interoperability that assumes a unified

classification of spatial features [27]. This produces definitional structures of extraordinary complexity

that suffer from the same limitations as OWL-S in being able to yield automated translation [5, 28]. Thus

most available approaches to semantic integration in fact require ad-hoc non-systematic subjective

manual mappings that can take the layer 4 and 5 modifications of ontology into account, but at the

expense of their universality [29].

Such approaches to ontology mapping start from a universal position from which to make such

mappings. The alternative is to model the way the data is to be used in order to define the semantics of

the data fusion process itself. This places the emphasis instead on establishing the ontology of the

observations themselves within their context-of-use, and ensuring the scale commensurability and

scope consistency between inputs and outputs at each stage of the modeling process. This subordinatesthe formal semantics to the pragmatics of the modeling situation. This is an approach to ontology

argued for in Searles status functions [30]and Peirces triadic relations [31].


10/16

10

Appendix I Stratification

A number of terms are being used relating to the stratification. What follows is a glossary of these

terms. Two definitions are provided in each case, one as it relates to linguistics and the other in terms

on the stratification:

Linguistics Stratification

Lexis The storage of language in our mental

lexicon as prefabricated patterns that can

be recalled and sorted into meaningful

speech and writing.6

The repertoire of usable behaviors.

Syntax The rules of a language that show how

words of that language are to be

arranged to make a sentence of that

language.7

All possible combinations of usable behaviors.

Behavioral

Semantics

An approach to the meaning of sentences

based on the analysis of somecombination of the axioms they obey,

their referents and the behaviors they

entail.8

What each possible behavioral combination

denotes in a socio-technical system.

Discourse

Semantics

Meaning beyond the sentence boundary

associated with naturally occurring

language use.9

How each possible behavioral combination

may influence the interactions among the

actors of a given socio-technical system.10

Pragmatics the ways we reach our goal in

communication11

How actors choose among behavioral

combinations in order to generate

anticipated effects in the environment of a

given socio-technical system.

6Seehttp://en.wikipedia.org/wiki/Lexis_%28linguistics%29

7Seehttp://en.wikipedia.org/wiki/Syntax

8Seehttp://en.wikipedia.org/wiki/Formal_semantics_of_programming_languages

9Seehttp://en.wikipedia.org/wiki/Semanticsfor a general treatment of semantics, and

http://en.wikipedia.org/wiki/Discourse_analysisfor its particular relation to discourse.10

Seehttp://en.wikipedia.org/wiki/Discoursefor different ways of applying this approach to social systems.11

Seehttp://en.wikipedia.org/wiki/Pragmatics
http://en.wikipedia.org/wiki/Lexis_%28linguistics%29http://en.wikipedia.org/wiki/Lexis_%28linguistics%29http://en.wikipedia.org/wiki/Lexis_%28linguistics%29http://en.wikipedia.org/wiki/Syntaxhttp://en.wikipedia.org/wiki/Syntaxhttp://en.wikipedia.org/wiki/Syntaxhttp://en.wikipedia.org/wiki/Formal_semantics_of_programming_languageshttp://en.wikipedia.org/wiki/Formal_semantics_of_programming_languageshttp://en.wikipedia.org/wiki/Formal_semantics_of_programming_languageshttp://en.wikipedia.org/wiki/Semanticshttp://en.wikipedia.org/wiki/Semanticshttp://en.wikipedia.org/wiki/Semanticshttp://en.wikipedia.org/wiki/Discourse_analysishttp://en.wikipedia.org/wiki/Discourse_analysishttp://en.wikipedia.org/wiki/Discoursehttp://en.wikipedia.org/wiki/Discoursehttp://en.wikipedia.org/wiki/Discoursehttp://en.wikipedia.org/wiki/Pragmaticshttp://en.wikipedia.org/wiki/Pragmaticshttp://en.wikipedia.org/wiki/Pragmaticshttp://en.wikipedia.org/wiki/Pragmaticshttp://en.wikipedia.org/wiki/Discoursehttp://en.wikipedia.org/wiki/Discourse_analysishttp://en.wikipedia.org/wiki/Semanticshttp://en.wikipedia.org/wiki/Formal_semantics_of_programming_languageshttp://en.wikipedia.org/wiki/Syntaxhttp://en.wikipedia.org/wiki/Lexis_%28linguistics%29


11/16

11

Appendix II Glossary of Economic terms

The following terms are used to refer to the different kinds of economics that have to be managed by an

enterprise:

Economic definition

Economies of Scale The cost advantages that a firm obtains due to expansion of its scale of

operation.12

Economies of Scope Whereas economies of scale primarily refer to efficiencies associated with

supply-side changes, such as increasing or decreasing the scale of production,

of a single product type, economies of scope refer to efficiencies primarily

associated with demand-side changes, such as increasing or decreasing the

scope of marketing and distribution, of different types of products.13

Transaction Costs The costs to the supplier of engaging in a transaction with a customer

associated with providing a particular service or product. The nature of these

costs depends on the nature of the economies of scale and scope available to

the supplier.14

Economies of

Alignment

A supplier has to be able to assemble the capabilities it needs to be able

engage in a transaction. The costs of doing this are the costs of alignment.

Under changing conditions of demand, the supplier is incurring these costs

each time it seeks to re-align its capabilities to the opportunities it is pursuing.

Economies of alignment refer to the cost advantages that the supplier obtains

in the way it incurs these costs. [32-34]

12Seehttp://en.wikipedia.org/wiki/Economies_of_scale

13Seehttp://en.wikipedia.org/wiki/Economies_of_scope

14Seehttp://en.wikipedia.org/wiki/Transaction_cost
http://en.wikipedia.org/wiki/Economies_of_scalehttp://en.wikipedia.org/wiki/Economies_of_scalehttp://en.wikipedia.org/wiki/Economies_of_scalehttp://en.wikipedia.org/wiki/Economies_of_scopehttp://en.wikipedia.org/wiki/Economies_of_scopehttp://en.wikipedia.org/wiki/Economies_of_scopehttp://en.wikipedia.org/wiki/Transaction_costhttp://en.wikipedia.org/wiki/Transaction_costhttp://en.wikipedia.org/wiki/Transaction_costhttp://en.wikipedia.org/wiki/Transaction_costhttp://en.wikipedia.org/wiki/Economies_of_scopehttp://en.wikipedia.org/wiki/Economies_of_scale


12/16

12

Appendix III The Zachman Framework Architecture 1.0

The Zachman Framework can be approached in terms of the following dimensions (which are the

dimensions corresponding to Governance (N), Capabilities (S), Demands (E) and Know-how (W) [35]:

Figure 6: defining enterprises within ecosystems

When applied to the Zachman Framework, it identifies gaps. The Zachman framework is defined by

reference to a single enterprise, whether virtual or not. So an extra row is needed to account for the

collaborative processes between enterprises (the pragmatics row in Figure 2). An extra column is alsoneeded to deal with there being multiple contexts-of-use, each one of which may require its own

supporting enterprise logic. And an extra column is needed to address the way data is related to events

through the particular modality of reality being used by the enterprise(s). This gives leads to the

following:

Figure 7: the modified Zachman framework

SCOPE(Competitive context)

Planning

BUSINESS MODEL(Conceptual)

Owning

SYSTEM

MODEL(Logical)

Designing

TECHNOLOGY

MODEL(Physical)

Building

DETAILED

REPRESENTATIONS(out-of-modelling -context)

Subcontracting

DATA(WHAT)

e.g. data

MOTIVATION(WHY)

e.g. strategy

TIME(WHEN)

e.g. schedule

PEOPLE(WHO)

e.g. organisation

NETWORK(WHERE)

e.g. network

FUNCTION(HOW)

e.g. function

USE CONTEXT(WHO for WHOM)

e.g. particular client

The WHAT The WHYThe WHO/MThe HOW

COLLABORATIVE

MODEL(Pragmatic)

Governing

EVENT(WHAT)

e.g. things done

contexts-

of-use

modelling

context

contexts-of-

governance

modality

of reality


13/16

13

In order to give an account of this more complex understanding of the enterprise, able to address the

needs of distributed collaboration [36], a correspondingly more complex modeling method is needed.

This is provided by a method of projective analysis which can use five different layers of representation

including synchronization and demand, instead of the more usual three corresponding to structure-

function, trace and hierarchy:

Figure 8: the five layers of representation supported by projective analysis

The full five layers are:

Structure/Function: The physical structure and functioning of resources and capabilities. Trace: The digital processes and software that interact with the physical processes. Hierarchy: The formal hierarchies under which the uses made of both the physical and the

digital are held accountable. Synchronization: The lateral relations of synchronization and coordination within and between

Agencies and the services they provide on the ground.

Demand: the nature of the environment giving rise to demands on the way the operations areorganized to deliver effective and timely services.


14/16

14

Appendix IV the concept of scale and scope in ecology

The content of this appendix is derived from the work of Schneider [37, 38].There are a number of

definitions of scale, which were originally treated as equivalent to defining hierarchy (e.g. cell, tissue,

organ, organism). Examples are as follows:

Measurement scale [39] distinguishes variables quantified on a nominal scale(presence/absence), an ordinal scale (ranks), an interval scale (equal steps, such as degrees

centigrade), and a ratio scale (equal steps and known zero, such as degrees kelvin).

Cartographic scale is the ratio of the distance on a map to the distance on the ground. A meter-wide map of the world has a scale of about 1:39,000,000.

Scale refers to the extent relative to the grain of a variable indexed by time or space [40, 41].Variables so indexed have a minimum resolvable area or time period (grain or inner scale) within

some range of measurement (extent or outer scale). For example, a tree-coring device resolves

annual changes over periods of thousands of years.

In multiscale analysis, the variance in a measured quantity, or the relation of two measuredquantities, is computed with a series of different scales. This is accomplished by systematicallychanging either the separation (lag) between measurements or the averaging interval (window

size) for contiguous measurements [42].

Ecological scaling [43, 44] refers to the use of power laws that scale a variable (e.g., respiration)to body size, usually according to a non-integral exponent. Respiration typically scales as

mass0.75; hence, a doubling in body size increases oxygen consumption by 20.75 = 1.7, rather

than by a factor of 2.

Powell [45] defined scale as the distance before some quantity of interest changes.When applied to observation instruments, we get scope, or ratio of extent to resolution. This leads to

scaling between measurements of differing scope, where a power law applies. Thus isometric scaling

uses an exponent of 1, whereas allometric scaling uses indices other than 1. For Euclidean scaling, the

exponent is an integer or a rational, whereas organisms use fractal scaling, which use exponents that are

not rational numbers.

Incommensurability

Incommensurability was put forward by Kuhn originally to indicate the necessity of a paradigm shift in

the way the two systems are understood. He later modified this to localize it to particular concepts

within a framework [46]. Fleck approached this issue of incommensurability differently, placing the

emphasis instead on error, which when viewed historically, revealed anomalies that required the

emergence of subsequent theories to account for in order to be given the status of being true [47, 48].

Later arguments by Lakatos and MacIntyre place the focus more on the system of concepts and changes

in their internal consistency in order to give an account of incommensurability [49].


15/16

15

References

1. Veryard, R., Towards the Lightweight Enterprise: Business Modeling and Design for SOA and

Enterprise Mashups. CBDi Journal, 2006.

2. Veryard, R., Web 2.0 and Enterprise Architecture: Increasing synergy between Web 2.0 and SOA.

CBDi Journal, 2007.

3. Veter, G., Models for semantic interoperability in service-oriented architectures. IBM Systems

Journal, 2005.

4. Lewis, G.A., et al. Why Standards Are Not Enough to Guarantee End-to-End Interoperability. in

Seventh International Conference on Composition-Based Software Systems. 2008. Madrid.

5. Metcalf, C. and G.A. Lewis, Model Problems in Technologies for Interoperability: OWL Web

Ontology Language for Services (OWL-S), 2006, Software Engineering Institute.

6. Martin, J.R. and D. Rose, Working with Discourse: Meaning beyond the clause. Open Linguistics

Series, ed. R. Fawcett, London: Continuum.

7. Martin, J.R., English Text: System and Structure1992, Philadelphia: John Benjamins.

8. Boxer, P., et al. Systems-of-Systems Engineering and the Pragmatics of Demand. in Second

International Systems Conference. 2008. Montreal, Que.: IEEE.

9. Clements, P., R. Kazman, and M. Klein, Evaluating Software Architectures: Methods and Case

Studies2001: Addison-Wesley.

10. Byrnes, C. and I. Kyratzoglou,Applying Architecture Tradeoff Assessment Method (ATAM) As

Part Of Formal Software Architecture Review, 2007, The Mitre Corporation.

11. Bradley, A., 'Mashups' and their relevance to the Enterprise, 2007, Gartner Research.

12. Bradley, A., Reference Architecture for Enterprise 'Mashups', 2007, Gartner Research.

13. Bradley, A. and D. Gootzit, Who's Who in Enterprise 'Mashup' Technologies, 2007, Gartner

Research.

14. Linthicum, D.S., SOA Watch: How Mashups fit with SOA, 2008, SOAInstitute.org.

15. Boxer, P.J., Interoperability Landscapes, inAsymmetric Design2006.

16. Veryard, R., Enterprise Mashups and Situated Software, 2006.

17. Veryard, R., Collaborative Composition, 2005.

18. Veryard, R., Situated Software, 2004.

19. Cherbakov, L., A.J.F. Bravery, and A. Pandya, SOA meets situational applications, Part 1:

Changing computing in the enterprise, 2007, IBM.

20. Anderson, C., The Long Tail: Why the Future of Business is Selling Less of More2006, New York:

Hyperion.

21. Evans, D.S., A. Hagiu, and R. Schmalensee, Invisible Engines: How Software Platforms Drive

Innovation and Transform Industries2006, Cambridge: MIT.

22. Watt, S., Mashups - The evolution of the SOA, Part 2: Situational applications and the mashup

ecosystem, 2007, IBM.

23. Merrill, D., Mashups: The new breed of Web app, 2009, IBM.

24. GAO, Geospatial Information: Technologies hold promise for Wildland Fire Management, but

Challenges Remain, 2003, US Government.

25. Woolf, A., et al. Semantic Integration of File-based Data for Grid Services. in Fifth IEEE

International Symposium on CLuster Computing and the Grid, Vol 1. 2005.


16/16

16

26. Sen, S., Semantic interoperability of geographic information, in GIS Development2005.

27. Li, Y. and G. Benwell, On the Classification of Categories of Spatial Features, in 14th Annual

Colloquium of the Spatial Information Research Centre, University of Otago2002: Dunedin, New

Zealand.

28. Kalfoglou, Y. and M. Schorlemmer, Ontology mapping: the state of the art. Knowledge

Engineering Review, 2003. 18(1): p. 1-31.29. Kavouras, M.,A unified ontological framework for semantic integration, in International

Workshop on Next Generation Geospatial Information2003.

30. Searle, J.R., Making the Social World: The Structure of Human Civilization2010: Oxford University

Press.

31. Murphey, M.G., The Development of Peirce's Philosophy1993: Hackett Publishing Company.

32. Langlois, R.N., Transaction-cost Economics in Real Time. Industrial and Corporate Change, 1992.

1(1).

33. Antonelli, C., The Economics of Governance: Transactions, Resources and Knowledge, in DRUID

Summer Conference2003.

34. Williamson, O.E., The Economics of Governance. American Economic Review, 2005. 95(2): p. 1-18.

35. Boxer, P.J., East-West Dominance, inAsymmetric Design2006.

36. Boxer, P., et al., The Double Challenge in Engineering Complex Systems of Systems. News at SEI,

2007: p.http://www.sei.cmu.edu/library/abstracts/news-at-sei/eyeonintegration200705.cfm.

37. Schneider, D., The rise of the concept of scale in ecology. BioScience, 2001. 51(7).

38. Schneider, D.,Applied Scaling Theory, in Ecological Scale: Theory and Applications1998,

Columbia University Press: New York.

39. Stevens, S.S., On the theory of scales of measurement. Science, 1946. 103: p. 677-680.

40. Wiens, J.A., Spatial scaling in ecology. Functional Ecology, 1989. 3: p. 385-397.

41. Schneider, D., Quantitative Ecology: Spatial and Temporal Scaling1994, San Diego: AcademicPress.

42. Milne, B.,Applications of fractal geometry in wildlife biology, in Wildlife and Landscape Ecology:

Effects of Pattern and Scale, J.A. Bissonette, Editor 1997, Springer-Verlag: New York.

43. Calder, W.A., Ecological scaling: Mammals and birds. Annual Review of Ecology and Systematics,

1983. 14: p. 213-230.

44. Peters, R.H., The Ecological Implications of Body Size1983: Cambridge University Press.

45. Powell, T.M., Physical and biological scales of variability in lakes, estuaries, and the coastal

ocean, in Perspectives in Ecological Theory, J. Roughgarden, R.M. May, and S.A. Levin, Editors.

1989, Princeton University Press. p. 157-176.

46. Chien, X., Thomas Kuhn's Latest Notion of Incommensurability. Journal of General Philosophy ofScience, 1997. 28: p. 257-273.

47. Fleck, L., Genesis and Development of a Scientific Fact, ed. T.J. Trenn and R.K. Merton1979,

London: University of Chicago Press.

48. Babich, B.E., From Fleck's Denkstil to Kuhn's paradigm: conceptual schemes and

incommensurability. International Studies in the Philosophy of Science, 2003. 17(1).

49. Miner, R., Lakatos and MacIntyre on Incommensurability and the Rationality of Theory-change,

in Twentieth World Congress of Philosophy1998: Boston, Masachusetts.
http://www.sei.cmu.edu/library/abstracts/news-at-sei/eyeonintegration200705.cfmhttp://www.sei.cmu.edu/library/abstracts/news-at-sei/eyeonintegration200705.cfmhttp://www.sei.cmu.edu/library/abstracts/news-at-sei/eyeonintegration200705.cfmhttp://www.sei.cmu.edu/library/abstracts/news-at-sei/eyeonintegration200705.cfm

Documents

Distinguishing Ontological Frameworks