Developing a Spatial Decision Support Knowledge Portal

stagetofuΤεχνίτη Νοημοσύνη και Ρομποτική

29 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

57 εμφανίσεις



Developing
a Spatial Decision Support
Knowledge Portal

Technical Report















Naicong Li

The Redlands Institute

University of Redlands

August 24, 2008


Funding support for the research reported in this document is provided in part

by the Army Research Office under contract number W911NF
-
04
-
C
-
0050.



Table of Contents

1.

Introduction and Proje
ct Background Information
................................
................................
.........
3

2.

The Challenge

................................
................................
................................
.............................
4

3.

Ontology
-
Based Approach

................................
................................
................................
...........
4

4.

Content of the SDS Knowledge Portal and Its Organization

................................
............................
5

4.1

The Conceptual Framework


SDS Ontologies

................................
................................
........
7

4.1.1

Organizing Ontologies into Major Knowledge Components

................................
.............
7

4.1.2

Concepts and Their Properties and Relations in the SDS Ontologies
................................
.
8

4.1.3

Controlled Vocabulary for the Body of Knowledge on SDS
................................
.............

10

4.2

Resources Related to

SDS

................................
................................
................................
...

11

5.

Information Retrieval on SDS Knowledge Portal

................................
................................
..........

13

5.1

User interface of the SDS Knowledge Portal
................................
................................
.........

13

5.2

Semantic Browsing and Conventional Browsing

................................
................................
...

14

5.3

Semantic and conventional search

................................
................................
......................

18

6.

Architecture of the SDS Knowledge Portal
................................
................................
...................

21

7.

Design Considerations for the SDS Knowledge Portal
................................
................................
...

22

7.1

Design considerations for the Portal a
rchitecture

................................
................................

22

7.2

Design considerations for the SDS ontologies

................................
................................
......

24

7.2.1

Basis for the classification of concepts in the SDS ontologies

................................
.........

24

7.2.2

Modular Design and Potential Re
-
Use of Already Developed Ontologies

........................

25

7.2.3

What and How Much to Include in the Ontologies

................................
........................

25

7.2.4

Formal Representation vs. Natural Language Description

................................
.................

26

8.

Conclusions and future work

................................
................................
................................
......

27

References

................................
................................
................................
................................
.......

28




3


1.

Introduction
a
nd Project Background Information

The Spatial Decision Support (SDS) Knowledge Portal project was initiated in 2007 by the Redlands
Institute at the University of Redlands, with support from the Army Research Office. The objectives
of this p
roject include:



Developing a systematic representation of the existing body of knowledge in the field of SDS;



Promoting semantic clarity of commonly used terms within a user community, in the areas
including decision process, methods and techniques, funct
ionalities of Spatial Decision Support
Systems (SDSS); and



Organizing a representative set of existing SDS reference resources including literature, tools,
and case studies.

Another objective for this project is to
develop

a good theoretical
and methodolog
ical framework

for an ensuing project, which is to develop a library of modular, reusable SDS
S

components
.

A large
number of SDSS related software, algorithms, and tools have been developed to date. With few
exceptions, these components have been built i
ndependently from scratch for each application, are
not easily reusable, and their performance is not independently verifiable. The lack of component
modularity contributes to the lack of reusability in these tools (Goodchild and Glennon, 2008).
Developi
ng reusable SDSS components depends on a high level of understanding of the
SDS

including the identification of the fundamental granules of the SDS process. Such an understanding
is difficult to achieve, given the lack of systematic integration and presentation of knowledge in SDS.

The SDS Knowledge Portal project is aimed to addre
ss this problem.

At the invitation of the University of Redlands, a number of researchers, experts and practitioners
joined this research effort early 2008, participating in two collaborative workshops and providing
individual contributions. An informal SDS Consortium was
formed in May 2008. The
current
content
of this Knowledge Portal reflects the collective effort of the SDS Consortium members.

In this work, we adopt the following definition of SDS, which is agreed upon by the SDS Consortium
members:

Spatial decision s
upport is the computational or informational assistance for making better
informed decisions about problems with a geographic or spatial component. This support assists
with the development, evaluation and selection of proper policies, plans, scenarios, pr
ojects,
interve
ntions, or solution strategies.

The SDS Consortium,

http://www.institute.redlands.edu/sds/

The potential users for such a knowledge portal would
first be
the SDS Consortium members,
including the Redlands Institute
. Many of our projects have

the aspect of assisting various
organizations
make informed decisions, and one of our focus areas of research is spatial decision
support. We
therefore
need a sound understanding of the existing body of knowledge in this field.
Constructing a knowled
ge
portal to actually organize

this body of knowledge enables us to achieve
4


this goal beyond

what a literature review could. Besides ourselves
, our clients would also
potentially benefit from this e
ffort. For example, the SDS Knowledge Portal
could serve a
s a learning
platform for our clients to better understand the decision process

and explore the available
resources
. For the same reason, this portal could also benefit decision makers and practitioners in
general. Last but not least, it could be a valua
ble research tool for university researchers and
students alike.

2.

The C
hallenge

The knowledge in the field of SDS is vast, including the understanding of spatial decision process and
its phases (Malczewski 1999); methods and techniques used during a deci
sion process (Malczewski
1999, Leung 1997, Wu 1998, Aerts et al. 2003, Church et al. 2004, Malczewski 2006), participation
and collaboration dimensions of the decision process (Armstrong 1993, Jankowski and Nyerges
2001, Sieber 2006, Jankowski et al. 2006)
; systems functionality (Densham 1991); and data, data
models, and process models needed to solve a decision problem in the application domains
(Malczewski 2006).

Besides the change of integrating
the information from different knowledge
domains
, we also
face a situation
where multiple overlapping fields of study
have been

developed
by

various research communities, including

SDSS,
group spatial decision support systems (
G
S
DSS
),

participatory geographical information systems (
PGIS
), public participation
geographic information
s
ystems (PPGIS), planning support systems (PSS), Intelligent spatial de
cision support system (ISDSS),
s
patial expert support system (SESS),
etc. (Malzcewski 1999, Sieber 2006). Terminologies used in
these research communities

someti
mes
refer to

the
same or similar concepts
with
different naming
conventions, which inhibits mutual understanding and sharing of information.
The
third

challenge
of this project arises from

the
lack of
a common
conceptual
framework for

synthesizing and
pre
senting this vast body of knowledge.

Clearly
neither an

individual nor a single research group can, in a short period of time, organize and
synthesize the entire content of all the related information. What we can do, however, is to create
a sound
concept
ual

framework for organizing this knowledge, fill it with the initial, essential content
within the give time frame, and let the content develop further over time.

This
conceptual
framework
should also
facilitate

easy information retrieval
from this body
of knowledge.

The SDS
Knowledge Portal therefore ne
ed
s

to be built

on such a conceptual framework.

3.

O
ntology
-
B
ased
A
pproach

In this work, we develop a set of
domain specific
ontologies (
Guarino 1998
)
for SDS and use it as
the

conceptual framework to

organize the body of knowledge

on SDS,

and drive

information retrieval
from

it. For our purposes, w
e adopt
the following

practical definition of ontology:


5


A domain specific ontology is constructed on the basis of a controlled vocabulary
whose meaning is

agreed upon by the members of a particular user community.
Such an

ontology is a classification system, contains the conceptual categories
(and subcategories) in this domain, and for each category, the defining attributes
of this category, and the variou
s relations that this category bears to other
categories. A category has instances sharing the same defining attributes and
relations of this category; the difference in their attribute values make them
distinct individuals.

Ontologies

promote semantic c
larity by providing a common vocabulary for the essential
concepts
used by a community
within

an application domain
. In

our case
the

concepts are those related to
spatial decision,
used by people involved in spatial decision making process
es
.
Once adopte
d by
a

user community, the concepts, or rather their natural language expressions, together with their
definition become a common vocabulary, or a form of standard, which provides the members in this
user community with a tool to speak with less ambiguity,

reduce misunderstanding, and therefore
facilitate

information exchange.

Ontologies are also a useful tool to

explicate
and formalize
expert knowledge, in this case
the
knowledge
of

the

researchers,
expertise

of the practitioners, etc. in the field of spatial decision
support.

Such formalization
is necessary for the

automatic
retrieval of
relevant information

in
the
SDS Knowledge P
ortal
.

Besides facilitating retrieval of
the
information explicitly coded in th
e ontology, ontologies also
enable

infere
ncing on the store
d

information
to derive

implicit knowledge. Although this
capability

is not being
exploited

for the SDS Knowledge Portal at the time of this writing, it could be in
the
future
improvement

of this
Portal.

4.

Content of th
e SDS Knowledge Portal and Its O
rganization

The content of the SDS Knowledge Portal consists of
the following:

1.

T
he body of knowledge
about

the field of SDS.
This knowledge is “embodied” by a set of
essential concepts of spatial decisions, decision process, decision methods and techniques,
SDSS functionalities,
etc., and concepts
that support the description of the above mentioned
concepts, such as data and pro
cess related concepts, decision related concepts, decision
process participants, etc.

These concepts, and th
e relations among them, capture

our
understandi
ng of spatial decision making and the means for supporting such decision
making.

2.

The information abo
ut various useful resources for spatial decision support, such as
li
terature, tools, case studies, data models, process models, spatial decision process

workflow templates, and so on.

6


As we mentioned abo
ve,
w
e use a set of ontologies as the

conceptual fram
ework
to contain and

organize

the knowledge and information in this

Portal
.
The essential concepts about SDS and their
interrelations are described in this set of ontologies. The information about the resources for SDS in
turn
is

organized by this set of

ontologies as well, in the sense that all the resources items are
instances of some concept in the SDS ontologies. The content of these ontologies
can be considered
as a
semantic
graph, with concept nodes and relational links among them. The commonly
un
derstood
parent
-
child category relation

in a typical hierarchical structure

is but one of the many
kinds of possible relations among the
se

concept nodes.
Figure
1

below shows a sub graph showing

that

Choice

, which is a major phase of the decision proce
s
s, has a sub step “Alternative R
anking

,
for which there are some commonly used decision methods such as
“Analytical Hierarchy P
rocess

,
“Simple Additive Weighting M
ethod

,
“Value/Utility Function M
ethod

, etc.

These methods belong
to a method category called

Multiattribute

Combination R
ule

, which is a

subcategory of
“Multiattribute E
valuati
on M
ethods

, which is a subcategory of
“Spatial D
ecision

Methods and
T
echniques

. This
sub graph

also shows that EMDS,
which is an instance of
“Spatial Decision
Support S
ystems

, can support the decision process phase

Choice


by implementing the methods
of the category of
“Multiattribute Combination R
ule

. It also shows other concepts related to
EMDS, such as

EMDS Conso
rtium


as its
“M
aker

, and

Keith Reynolds


as the
“Contact P
erson

.

(Note that this
graph only shows
a small subset of the relations that EMDS bears to other concept
nodes.)



Figure
1
.

An example sub graph in the SDSS ontologies


7


4.1

The Conceptual
Framework


SDS O
ntologies

To develop the set of SDS ontologies
, w
e analyzed a representative set of SDS literature to identify
major knowledge components

in SDS
. We
c
ompiled

essential concepts
about SDS
and the important

relations among these concepts
,

an
d we created

a
common vocabulary referring to these concepts.

These

concepts are partitioned into
30 or so
faceted ontologies

based on what they describe.

4.1.1

Organizing
Ontologies i
nto Major Knowledge Components

Large numbers of ontologies
are

confusing to look at
, therefore the 30 some

ontologies
themselves
are further partitioned into

major SDS
knowledge
components. Below is a list of these knowledge
components, and a description of the main content of each component:

Component

Content

Intr
oduction

Definition of spatial decision support, the related fields of study, the basic concepts
related to the notion of decision

Decision context

The cont
ext in which to frame a decision
: decision problem types, application
domains, institutional,
legal, social, cultural
, geographic

contexts of a decision

Spatial decision process

Knowledge about spatial decision processes: m
ajor phases and sub steps during a
structured spatial decision process; typical spatial decision process workflow
s for
different application domains

Methods and techniques

Methods and techniques used during a spatial decision process

Technology

Technology available for SDS, including equipment and software, especially spatial
decision support systems and tools. Related
information on information systems,
general SDSS functionalities

Decision process participants
and roles

Collaborative dimension of decision making process, decision process participant
roles

Domain data and knowledge

Data, data models, processes, proces
s models

Resources

SDS s
oftware systems and tools,
related
literature, case studies,
related websites
,
data source
s, data models,
decision process workflow templates, organizations and
people referred to elsewhere in the Knowledge Portal

(some of the cont
ent here is
also under some other components)


Table
1
.

Main
Components of
SDS

Knowledge o
n
t
he
Portal


Each

component

contains
one or more ontologies that describe its content.

For example,

the

“S
patial Decision P
rocess

com
ponent contains two
ontologies:



The ontology for spatial decision process phases and steps



The ontology fo
r sp
atial decision process workflow templates

Figure
2

shows a

complete list of ontologies, organized in a hierarchical fashion

into the above
mentioned major components,

as displayed on the SDS Knowledge Portal:

8



Figure
2
.

SDS ontology S
et


4.1.2

Concepts
and Their Properties and Relations in t
he
SDS
Ontologies

As mentioned
above, the concepts in the
SDS
ontologies are organized in a graph format, with the
concepts being the nodes in the graph.
Each such concept node has an internal structure
representing the meaning of this concept. This internal structure consists of a set of properties for
this concep
t
,
including:



The commonly used English term



Synonyms
,

if any



Abbreviations or acronyms
,

if any



Descriptions



Sources of description



Other
descriptive properties depending on the type of the concept


9


For example, below is a screen capture showing how the co
ncept of “
Simple Additive Weighed
Summation

in the methods ontology is defined:




Figure
3
.

Properties of a concept



Beside the
name and description
-
related properties mentioned above,
this figure shows that
a
concept
can
also
have

other
properties
that
are characteristic of

this type of concept
. For example,
for

M
ultiattribute
Evaluation Methods

, to which

Simple
Additive Weighting Method


belongs,
the defining properties include
the
decision type
,
decision maker interaction level
, etc.

Besides properties, concepts are further defined by explicitly specified relations among concepts.
For example, a
method

relates to a
process phase

or
step

if it is often used in that phase or step, and
relates to a
decision problem type

if it is used to
solve that type of problem.
Methods concepts also
have
the
input

and
output

relations
, as shown in the figure above,
specifying

what kind of objects
10


this

met
hod accepts as input or produces as output.
In this example, a
cceptable input types,

Attribute S
c
ore


and

Criterion W
eight


are themselves concepts defined in
the “
Data


ontology
and
in the “
Decision


ontology respectively.

Ordinal
R
anking


(of the design alternatives being
evaluated)
as
the acceptable output type is a

concept defined in
the “
Decis
ion


ontology
.

By default, any properties define
d

for

a parent concept will be inherited by it
s

child concept
s
. For
example,

Multiattribute

Evaluation Method


is a category of methods that has many subcategories
in

multiple levels. If we state in the ontology that

Multiattribute

Evaluation Method


has a relation
used for decision process phases/steps

to the

Choice


phase of the decision process, then all the
subcategories under the

Multiattribute

Evaluation Meth
od


category will inherit this relation to the

Choice


phase, meaning they can all be used for that decision process phase.

Some of the relations in the SDSS ontologies are specified to be
transitive
. For example,
commonly
followed by

is a relation
among

concepts for decision process phases and steps
. We use this relation
to state that the phase

Intelligence


(the phase for assessing current situation)
is

commonly
followed by

the phase

Design


(designing alternative solutions to the problem). We also state that
the phase

Design


is

commonly followed by

the phase

Choice


(the phase for evaluating the
design alternatives and choose one). We then state that
commonly followed by
is a transitive

relation. We could then use a
n

inference engine to infer that
the “
Intelligence


phase happens
before

Choice

, even though this relation is not explicitly coded in the ontology.

Some p
airs of the relations in the SD
S ontologies are specified to be
inver
se

of each other.
The
following are some of the examples:




for decision process phases/steps

and
commonly used methods and techniques

specify the
reciprocal relations between a method and process phase/step.



methods and techniques implemented

and
implemen
ted by tools

specify the reciprocal relations
between a tool and a method.



used for decision process phases/steps

and
commonly used tools

specify the reciprocal relations
between a tool and a process phase/step.

With

inverse relations, we can specify a val
ue for one relation (e.g. from a tool to a method) and the
inference engine will
automatically infer the value for

the corresponding inverse relation (from a
method to a tool).

Inferences using transitive and inverse relations are trivial inferences. We c
ould write more
sophisticated rules in the SDS ontologies to do more complex inferences to 1) guarantee the internal
consistency of the ontologies and 2) deduce implicit knowledge from the explicitly coded knowledge
in the ontologies. However this is an a
rea that we have yet to explore in future work.

4.1.3

Controlled V
ocabulary

for the Body of K
nowledge

on SDS

As we mentioned in section
1
, one of the purposes of this project is to promote semantic clarity
of
commonly used terms within an SDS
user community. One of the earlier
tasks

in this project
was

to
collect the commonly used terms
(words or phrases)
expressing the essential concepts

in the field of
SDS. These terms become the label property of these concepts in the ontol
ogies, i.e. they
are the
11


natural language expressions referring to these concepts. Natural language expressions are
ambiguous most of the time. However, with the description property for the concepts and other
properties and relations defined for the concepts, the meaning

of the terms in the context of this
SDS Knowledge Portal becomes unambiguous. A set of such terms therefore form a controll
ed
vocabulary, and if adopted, becomes the common vocabulary of the adopting community. Such
adoption would facilitate collaborati
ons among the community members by reducing
miscomm
unication and misunderstanding.

To accommodate natural language usage variations,
the concepts in the SDS ontologies also have,
besides a main term, a set of synonyms if any,
and
abbreviation
or

acron
ym if

any; t
he terms in this
controlled vocabulary
are

augmented with synonyms, abbreviations and acronym.

Notice that the synonym
-
related information in the SDS ontologies
is

domain specific. Since natural
language terms are ambiguous, a word could have severa
l different sets of synonyms, each for a
p
articular sense this word has, and
many of them would not be relevant for the body of knowledge
on SDS. A general purpose lexical thesaurus such as WordNet (
Fellbaum 1998
)
would therefore not
b
e suitable for our p
urpose here (not only
does
it contain too many irrelevant information,
but
it
may also be lacking the domain specific senses in word meaning).

Including only the domain specific
synonyms in definitions of concepts is crucial for increasing the accuracy of
search results during the
semantic search on the SDS Knowledge Portal (see section 5.
3 below
).

When sorted alphabetically by the main term, this set of the controlled vocabulary constitute
s

a
glossary for the body of knowledge on SDS.
The glossary

is one of the resources this SDS Knowledge
Portal provides. Unlike conventional glossari
es, the terms in this glossary are

define
d

with a richer
content, since the display of each term in fact is the display of the concept it refers to, not only wit
h
the

description for the term
, but also all the other properties and relations (to some other concepts)
defined for
the

concept
that this term refers to
.

Generation of this controlled vocabulary (or glossary) from the SDS ontologies is automatic. It is one
of

the functions provided by the ontology editor (TopBraid Composer
,
http://www.topquadrant.com/topbraid/composer/index.html
).

4.2

Resources R
elated to SDS

Besides SDS ontologies
representing

the body of knowledge in the field of SDS, the Portal also
manages

information on

a representative set of

resources for SDS. These resources include
literature, SDS systems and tools, case studies, related online resources

(web sites)
, etc. The items
of

these resourc
es

(e.g.
information on an SDS system or tool
)

could
be in fact considered part of the
SDS ontologies, since they are the instances of
a
certain resource type

(
e
.g.
SDS systems and tools)
,
which is a defined
concept in the SDS ontologies.
This means that
these resource items can have a
rich set of formally defined properties which relates them to other relevant concepts in the
ontologies,
as well as to

items in other types of resources.
For example, a tool description might
include where in the spatial de
cision process it is used, which method(s) it implements, which
problem type it addresses,
which
application domain it is used for, its input/output requirements, its
functional components,
which case studies in which it was applied, etc.

Below is a diagr
am of the
12


kind of properties and relations that are formally defined in the ontologies for
SDS systems and
tools
.
The properties defining the concept of SDS systems and tools are listed in the box, and the
relation properties are also displayed as arrows g
oing to the related concept types.




Figure
4
.

Properties and Relations Defined for SDS S
yste
ms and T
ools


Since the

resource

items are
formally defined and related to other essential concepts in the SDS
ontologies (such as concepts related to decision
process, methods, data, d
ata models, process
models, etc.
), they can be browsed
as any other concepts in the SDS ontologies
,
In fact,
one
of the
main components
of SDS

ontologies deal with resources
--

see the description in Table

1

and the last
branch of
the ontology hierarchy in Figure
2
. They can be searched semantically as well, with the
search criteria specified with the concepts they relate to.

I
n our
overall
SDS resource collection
, we c
urrently we have about 300 items in our literature
resource col
lection (and we are in the process of incorporating more publications cited in
Malczewski 2006), 50 or so SDS related systems and tools, and 20 or so case studies.
In most cases,
the resource items are
references

to the actual resource items

themselves
, e
xcept for a number of
13


literature items
for which

w
e actually store the documents.
As the word “portal” in
SDS Knowledge
Portal

indicates, what we have developed is a portal where, among other things, the
information

about SDS resources
is

organized, and l
inks to the actual resources are provided, usually through
URL links.

More details about the organization and retrieval of

information on

SDS resources are
discussed in
the next section on the information retrieval functionality of the SDS Knowledge Portal
.

5.


Information R
etrieval on SDS Knowledge Portal

Organizing the content on the SDS Knowledge Portal with ontologies enables semantic browsing and
searching of the content.
In the following, we present
the
user
interface

of the Portal

and discuss its
information retrieval capabilities through semantic browsing and searching
, as well as the
architecture of the Portal.

5.1

User interface of the SDS Knowledge Portal

The user interface of the SDS Knowledge Portal has
the format as shown by

the screen capture in
Figure
5

below:



Figure
5.

The SDS Knowledge Portal


14


The user interface of the Portal has
three main areas:



A “conventional” navigation bar
on top
with various tabs for various
information components,
including Ontology
,
Glossary,
Reference Library, Tools, Case studies, Online Resources, etc.

The
Ontology tab is the active one in the
figure above
.



A browsing
/
navigation and searching
panel

on the left
.
The

figure above
it is shown

as
the

ontology browsing/navigation area, with the concept
spatial decision support

selected.



A detailed content display area to the right
. Currently in the figure,
this area

displays the
definition (properties) of the concept
spatial decision support.

Figure
6

below
shows the screen capture when the glossary tab is active:




Figure
6
.

Glossary D
isplay in SDS Knowledge Portal


5.2

Semantic B
rowsing

and Conventional B
rowsing

The SDS Knowledge Portal
provides

both sema
ntic and conventional browsing capabilities.
By
semant
ic browsing we mean content browsing guided by the structure of an ontology.
It assumes
that the content has already been organized based on the structure of the ontology. In the case of
the SDS Knowl
edge Portal,
the SDS ontologies guide both the
browsing of the essential concepts on
15


SDS (about spatial decision process, methods, etc) and browsing of the resources (
information on
tools, case studies, lit
erature, data models, etc.).
The information retri
eved through s
emantic
browsing
is highly relevant because it only shows the information that user is asking for.


The
structure of the ontologies guide
s

the content browsing in two ways:


1.

The user can browse the content by navigating in the ontology hierar
chy. Although the
internal struc
ture of the ontologies is graph
-
like,
the Portal currently display
s

it as a
hierarchy in the navigation panel area. The hierarch
y

is initially displayed

with the major
knowledge components

collapsed
.

The user can expand a node and see more subcategories
underneath. He can click on a concept and
to see the definition of this concept, as shown in
Figure
7

below:



Figure
7
.

Browsing the Ontology H
ierarchy


The field names in the content display area
on the right are in fact the names of the properties,
relations defined for this concepts. In many cases they are self explanatory, but the user can also
hover over a field name to see the definition of the field name, as shown in Figure
6

above.

Browsing

resources can also be done through the ontology hierarchy. All the resources are
categories under the Resources knowledge comp
onent in the ontology hierarchy, as shown below:

16





Figure
8
.

Resource information
in the Ontology H
ierarchy


2.

Beside
s

browsing the content through the hierarchical relations among the concepts
through the ontology hierarchy, the user can also browse the content through other
association links that are defined for the concepts in the ontology.
For example,
while
examinin
g the information about EMDS, which is a spatial decision support system, the user
sees the following content
:

17




Figure
9
.

Detailed information on EMDS


As discussed in the section
4
,
SDS systems and tools are defined by a set of
properties and relations
.
The values of these properties and relations for EMDS are displayed in the Figure
9

above. The user
can follow

the relation links to jump to th
e related concepts, for example, one may
click on

EMDS
Consortium


to see information on EMDS’s tool maker,
o
r
go to

Multiattribute
Combination Rule


to see the methods that EMDS implements.

The SDS Knowledge Portal also provide
s

the conventional browsing capabilities. When the user
goes to one of the resource tabs, e.g. Reference Library (for literature on SDS
), Tools, or Case
Studies, a complete list of resource items for the selected resource types will
be displayed
. Figure
10

below shows the brow
s
ing list of SDS
literature

under the
Reference Lib
rary

tab:

18




Figure
10
.

Browsing the Reference L
ibrary


5.3

Semantic
and conventional
search

The SDS Knowledge Portal
provides conventional search
capability on documents on database
content, as well as a rudimentary semantic search capability.

The
search form on the left in the
example above

in the Figure
10

sho
ws the conventional search functionality on litera
ture items in
the Reference Lib
ra
r
y. T
he user can enter search criteria for a literature item by filling ou
t the
search form.

Different resource type
s have different search criteria, implemented in their o
wn search forms.
Figure
11

below shows the search form for SDS systems and tools
, which the user has filled out,
indicating that he is looking for a tool that can be applied to silviculture, that
can perform

trade
-
off
analysis
and/
or

what
-
if analysis, and

that runs on
the
Windows XP platform. The search engine
found five such tools from the Portal’s

available

information on tools resources.


19



Figure
11
.

SDS systems and to
ols search form and search results


Clicking on any of
the tools
in the
Search Results
list will bring up a

page displayin
g

the details about
the tool, in the same format as shown in Figure
9

above.

The operation for searching case studies is similar: the user fills out a search form specifying his
search criteria. Figure
12
below shows an example
in which

the user is looking for a case study
where the decision problem type is

impact assessment

, the application domain is

forestry

, and
the tool used is

EMDS

. The search en
gine found one such case study

in the Portal’s info
rmation
content.

20



Figure
12
.

Case Studies Search F
orm

and S
earch
R
esults


The SDS Knowledge Portal also has some semantic search capability. By semantic search we mean
search
ing

not just on keyword

strings
, but more intelligent querying based

on
concept
s.
It should be
pointed out that
even
with

the
conventional search
mechanism

mentioned above
,

the Portal
is
leveraging

the content of the SDS ontologies.
The

search criteria for an SDS resource type are in fact
a subset of the
properties and relations de
fined for that type of
resources in the SDS ontologies.
This can be seen by comparing the search form for the tools in Figure
11

and the tools instance
property

diagram

in Figure
4

(notice that the screen capture in Figure
11

does not include all the
prop
erties and relations defined for tools).

Another area
in which
semantic search
ing

is used concerns term search
ing
.
A keyword

could be the
natural language term for the concept, which could also be referred to by some abbreviation,
acronym, and synonym
(
s
)
. When a concept is defined in the SDS ontologies, the term, abbreviation,
acronym,
and
synonyms are all the language
-
relat
ed properties of this concept. One of things the
search engine does during semantic search is to expand the query expression accordi
ng to the
concept definitions in the ontologies. For example, when the user enters
a keyword “
simple
additive weighting method
” to find
the publications in which this spatial decision method is
21


mentioned,
the search engine would
first find the relevant co
ncept for this search term, retrieve all
its

language related properties, and expand the search query to include its abbreviation (“SAW”) and
its synonyms (“weighted summation”, “weighted linear combination method”, etc.)

before
searching among the documen
ts in the SDS reference library. Currently this level of semantic search
is used on the SDS Portal when the user enters
a
keyword string in the search form for the reference
library. It is also used when the user clicks on the References link inside a con
cept details page, in
which case all the strings specified for the language related properties of the current concept are
gathered together
to

construct a query to
be sent to the search engine.

Another place it is used is
when the user searches for a conce
p
t in the SDS ontology hierarchy by entering a concept name (see
Figure 5 above),

Another level of semantic search would be
to utilize

the relationships among the concepts in the
ontologies. For example, if the user enters a search string for a concept, t
he query could also be
expanded to search the child concepts of this concept. This level of query expansion will be among
the tasks for fu
ture improvement of the Portal.

6
.

Architec
ture of the SDS Knowledge Portal

Currently we have a simple architecture
for the SDS Knowledge Portal. It consists of the following
main functional components:



SDS domain knowledge ontologies, with SDS resource instances
, in OWL language
(
http://www.w3.org/TR/owl
-
features/
)



Ontology
-
to
-
web
application publisher



Ontology
-
guided

web browser,
which
interfaces with the user, performs various browsing
and search functions

on the content of the ontologies
. It consists of

o

A set of HTML pages, one for each concept, exported and transformed from the
ontologies by the Ontology
-
to
-
web
application publisher

o

An xml document
presenting

the hierarchical structure in the ontologies

to enable
browsing of the ontology hierarchy
, exported and translated from the ontologies by
the Ontology
-
to
-
web application publisher



SDS resource
database, expo
rted from the SDS resource instances in the SDS ontologies

22


Figure
13

below illustrate
s

this architecture:


Figure
13
.

Architect
ure of the SDS Knowledge Portal

The set
of
SDS ontologies is discussed in section 4 above.

The content of the ontologies



the
concepts and its properties and relations


is
periodically published to
the web, producing the user
front end with
the
browsing and searching capabilities

discussed in section 5 above.
The following
section will discuss the Portal architecture in
more detail.

7
.

Design C
onsideration
s

for

the SDS Knowledge Portal

In this section
we discuss some of the design considerations
for

the SDS knowledge portal. There
are two areas of considerations:
the design of the Portal itself, and
the design of the SD
S ontologies
.

7
.1

Design considerations
for

the Portal architecture

A use case analysis was conducted
during

the early phase of the Portal design. Three main use cases
were identified:



The user learns

about SDS through a glossary

23




The user learns and explo
res

the knowledge on SDS through browsing the structure of the
ontologies



The user browse
s
or searches for SDS resource items such as tools, case studies,
publications, online resources.

Each

use

cas
e has several alternative patterns in which the user
could interact with the Portal. From
the use case analysis, we derived the following m
ain conside
rations in the design of the SDS

Knowledge Portal:



Conceptual

clarity in how the content is presented to the user.



H
igh

level of

relevance in information retrieval results

Both of these considerations are to be achieved by leveraging

the power of ontologies
. This is
discussed in section 5.2

above
. In the current design

however
, the power of the ontologies is not
used to its
full
potential, due to the limit

of our
funding and programming
resources for this project.
The main weakness in the architecture described in Figure
13

is the separation of the web browser
fr
om the ontologies. Even though

the content of the ontologies have
been
“translated”

and
preserved
in

the content of w
eb pages, it is no longer in the original ontology

language

format
, and
cannot be queried easily.

To compensate the lack of
the
ontology
query capability
,

we
exported
the SDS resource items to a
set of
dat
abase
tables,
one
for
each
SDS resource type, with the
records

back
-
linked to the
corresponding
resource item HTML pages.
When the user searches for resource items using a
search form (see section 5.3
)
, the relevant resource table is searched for the
records that meet the
search criteria.

When the user selects an item in the search results list, the relevant HTML page for
the item is displayed.

Thus ontology query on SDS resource items is performed through searching
forms.

We also translated the onto
logy hierarchy into xml format to be displayed in the ontology hierarchy
navigation ar
ea on the web page
for browsing
(see Figure
7

in section 5.2). This xml tree structure is
also used for searching concepts in the ontology hierarchy.

These interim soluti
ons enable

the exi
s
ting semantic browsing and search capabilities
on the Portal
as
discussed in section 5. However s
emantic reasoning
on the Portal is still
unfeasible
. The ideal
situation would
be
that the web browser has access to an ontology reasoning

service, which can
access the ontologies and perform reasoning on the content of the ontologies.
We would then be
able to query the ontologies using an

ontology query language (SPARQL for example
,

http://www.w3.org/TR/rdf
-
sparql
-
query/
)
,

for information
that is not explicitly coded in the
ontologies but could be obtained by reasoning against the content of the ontologies.

24


7
.2

Design consideration
s

for

the SDS ontologies

In this section we discuss a few considerations on the design of the SDS ontologies
.

7
.2
.1

Basis for the c
lassification

of
concepts

in the SDS ontologies

There are many different ways of classifying things in the world
,

and concepts in our mind. In the
case of the SDS ontologies, the classification of concepts is motivated by two consider
ations:



Classification motivated by conceptual dimensions



Classification based on user needs

Concepts in an ontology are usually classified based on a particular conceptual
dimension
/perspective
. There are many such dimensions from which we could classify

the concepts
in SDSS ontologies
. The methods and techniques concepts, for example, can be grouped according
to their major functions
in decision making. F
or example, the methods under
multiattribute
evaluation meth
od

all have the functionality needed b
y the decision process phase
alternative
evaluation
.


But the same set of methods can be classified from a different
conceptual dimension
.
For example,
they

can be classified according to whether they involve multiple or single objective
decision making,

whether they can handle uncertainty issues in decision making, and if they can,
what type of uncertainty issues (probabilistic vs. fuzzy)
(Malczewski 1999).
Currently

the concepts
in the method ontology
are

organize
d

in one
dimension

--

based on their f
unctions
;
information
about the other dimension (regarding single vs. multiple
objective decision making, etc.)

is encoded
as properties of these methods
, t
hus creating “implicit” classes
). However
our framework
would
allow

easy addition of other
dimensions

for
explicitly
organizing the methods, which basically
involves adding an extra level under the methods category for
a
different
dimension
, and each
method can appear under different
dimension

branches.

Of course any dimension we implement in
o
ur ontologies need
s

to display a conceptual clarity in
its

inclusion of concepts and
in
the

way

they

are classified.

Another
deciding factor

in
the way of
partitioning the concepts in the SDS ontologies

is more
practicality driven. It

involves
the user ne
eds
consideration

of the
SDSS K
nowledge
P
ortal
.
We

need
to consider what
the user would

most likely
be looking for when browsing our Knowledge Portal.
Since the ontologies are the organization “glue” of the resources on our Portal, they need to be
struct
ured in a way to make it easy
for the users
to navigate
through the body of knowledge, and
find
the kind of resources

they are looking for. Again
the issue
of
different
dimensions/
perspectives
is at play here, since different types of users may be looking

for dif
ferent things, and they will
probably use

different
browsing/searching
paths
while

looking for things.
In our case,

we

would like
to first consider the type of users who come to the Knowledge Portal with a
particular
decision
problem
in mind, and
who hope to

gain an

understanding of
the relevant decision process, and to
find

re
sources for solving the
ir decision

problem
(
s
)
.

Prior to the second
collaboration
workshop

by
the SDS Consortium members
, the organization of ontologies was explored only
wit
h

the
consideration of the logical relations among the ontologies themselves, i.e.,
whether ontology A
should
import

ontology B (
since
ontology B
defines

more fundamental concepts
that are referred to
by the concepts in
ontology A)
. During the second wo
rk
shop, the concern about the user ne
e
d was
25


elevated
, and
the consortium members
agreed to
a top level structure for the ontologies
that better
meet
s

the

anticipated

user need.
This struct
ure can be seen by
the first level of the ontology
hi
erarchy on the Knowledge Portal, as in Table
1

and Figure 2 above.

Again this top level
organization
does not preclude the possibility of organizing the ontol
ogies from alternative user
perspectives

in the future.

7
.
2.2

Modular
Design and Potential Re
-
Use

o
f Already Developed Ontologies

When developing a domain specific ontology, it is a good practice to re
-
use what’s already been
developed as much as possible. The advantage of such practice includes 1) time saving; and

more
importantly, 2) facilitating

i
nteroperability
and information exchange
among different
systems

(
ref
)
.
Where we cannot

find already developed, good quality ontologies to meet our need, we have to
d
evelop o
ur own
. However, even i
n this case, we should try to re
-
use
what’s already
developed for
part of our set of ontologies, usually the upper level ontologies (i.e. the ontologies th
at contain
some basic concepts [such as measuring unit]

that can be referred to by ot
her ontologies
)
, if we can
find some well established and commonly u
sed ones
. In our case, however, due to
project

time
con
straint
s,

we do not have
enough
time to do a thorough assessment of the existing upper level
ontologies
, and
we
also
want
to keep our

ontologies light
weight
during the development phase (not
importing

a big

set of external ont
ologies).

T
herefore we have not yet done so. Since we do pl
an to
use some well
-
known upper
-
level ontologies in the future (one such candidate is the SWEET
ontologies developed by JPL
[Raskin & Pan 2005]
), we have taken a modular
design approach in our
development effort. We have kept the ontologies small
--

which is also a good practice

in ontology
development


each
one
dealing with a relatively clear branch of the knowledge. In doing so, we
were able to isolate out concepts th
at are not SDS domain specific, but
needed for the definition of
the domain specific concepts, such as Organization, Person (needed by several other domain specific
ontologies with concepts such as case studies, tools, reference documents, decision partici
pants,
etc.), Information System (needed by more domain specific ontolog
ies with concepts such as SDSS),
dat
a related concepts (as needed, for example, to specify

input and output of a SDS method or tool).

These non
-
domain
-
specific concepts are grouped in
to a few upper level ontologies, and they are
developed just enough to cover our needs, with details that we d
o not need left out. Our intent
ion
is to replace them in the future with
some
external
,

well
-
developed upper
-
level ontologies.

7
.
2.3

What
and

How Much to Include in t
he Ontologies

Another design consideration in our SDSS ontologies development concerns the
decision on

how
much to include

in our ontologies. As mentioned above, the field of study we are dealing with is
vast, and we cannot afford
to be comprehensive. This concerns both the breadth and depth of the
ontology coverage. In the dimension of the breadth, we need to
determine which areas of study

to
include (and within an area, which topics). In the dimension of the depth, we need to d
etermine
how fine
ly

grained our classification should be
for a topic (how many sub
-
category levels down
should we expand a category). In our case, both considerations are evaluated based on project
needs, time constraints, and our research

focus. For exa
mple, we ha
ve a

fairly fine
-
grained decision
methods ontology, especially when the methods

are implementable by software

technolog
y
.
However the methods dealing with the human psychology

and

conflict resolution are not
well
26


represented well in the ontolog
y, due to our time constraints, and due to our research focus on
computerized methods and tools. Another example where we have not gone into the level of
details as we could have is the ontology for data related concepts, which currently include both dat
a
related concepts and data model related concepts. The concept of data model could have many
attributes specified for it
,

but
this effort was

left as future work.
The same consideration applies
for
the ontology of process and process m
odels.

Similarly,
we ne
ed to mak
e decisions on
what and how
m
any

properties and relations we need to define for a concept. This issue is discussed in the next
section.


7
.
2.4


F
ormal

Representation vs. Natural Language D
escription

The balance between using
a
formal (logical) representation and
a
natural language description

to
represent the meaning of
a concept

is also a consideration in the SDS ontologies development.
Since we are dealing with

complex concept
s

(such as decision process steps)

which, if defin
ed
completely
and
formally, would
be
1)
very d
ifficult and time consuming,
and
2) difficult to
understand for human readers. We therefore rely
heavily

on natural language descriptions to
present the meaning of a concept. However in order for a computer sy
stem to “understand” the
meaning of a concept
to the degree such
that it can perform necessary operations on it
,

such as
semantic search, we need to formally define the part of the meaning of the concept that the
computer system needs to operate on. How m
uch we need to formalize (using logical expressions
to define the meaning of a concept) depends on what and how much we want the computer to do.
For example, if we want the system to automatically retrieve the information on what spatial
analysis unit an
SDS tool operates on, then we need to formally code the

spatial analysis unit


property of SDS tools. If we want
the system to automatically retrie
ve the methods that an SDS tool

implements, then we need to formally code the relation property

“methods im
plemented” between
a tool and a method.
In the SDS ontologies, we therefore have a set of properties defined for

each
important type of concept
, based on the needs of the Knowledge Portal for its concept navigation
and search functionalities. Below is a
d
iagram of the properties and relations defined for
spatial
decision process phase/step concept type
, and the
spatial decision method concept type
. The
properties and relations are listed in the box representing a concept type, and the relations are also
displayed as arrows going to the related concept types. (A similar diagram for the definition of
SDS
systems and tools
resource type can be seen in Figure
4 above
.)

27



Figure
14
.

Properties and relations that are formally defined for spatial decision
process
phases/steps, a
nd for spatial decision methods


8.


Conclusions and future work

In this project, we have developed a set of ontologies to represent the body of knowledge
on

spatial
decision support

(SDS)
. This set of ontologies is an initial attempt at capturing the essential
concepts in the SDS field of study, their properties and relations among them, as well as information
about the SDS resources. We have also developed a web
-
enabled SDS Knowledge Po
rtal
to present

SDS related knowledge and information. The SDS ontologies provide a conceptual framework for
organizing the content on the Portal, as well as guiding the content browsing and search on the
Portal.
Although this work is far from complete,
we hope our work
provides

a good theoretical and
methodological foundation for the future growth of the SDS Knowledge Portal.

There are several important areas that need to be addressed in our future work:



Fill in the missing definitions of some of the con
cepts

in the SDS ontologies
, and improve the
existing
definitions for the concepts if needed.



Review the existing relations among different concept types and determine if there are
others
to be added.



Add a

T
ime


ontology to the set of ontologies. This i
s needed for d
efining process models
which have

a temporal component.



Refine the ontology for

Decision Problem Types

.



Develop those ontology branches where currently there is only a concept place holder. This
includes:

28


o

Decision
Context Ontologies

such a
s institutional, legal, social, cultural, geographical
contexts;

o

Process
Models

ontology
;

o

O
ntology for collaboration
-
related concepts
.



Expand the SDS resource collection

and update exiting
SDS resources related information

for
literature, tools, case studi
es, datasets
, data m
odels, process models, spatial decision
workflow templates for different application domains.



Establish the relations between literature resource items with other concepts in the
ontologies. Currently the relations are defined

but

the
relation values for each item needs
to be filled out.



Collect user community
-
specific terminologies and relate them to the core terminologies
currently used in the ontologies.



Further automate the process of publishing the content of the ontology to the Po
rtal.



Add

semantic reasoning capability

to the Po
rtal to enhance its querying and searching
capabilities
.

References

Aerts, J. C., E. Esinger, G. B. Heuvelink and T. J. Stewart (2003). “Using integer linear
programming for multi
-
site land
-
use
allocation.” Geographical Analysis 35: 148

69.

Armstrong, M. P. (1993). “Perspectives on the development of group decision support systems
for locational problem solving.” Geographical Systems 1: 69

81.

Church, R. L., M. P. Scaparra and R. S. Middleton (
2004). “Identifying critical infrastructure: The
median and covering facility interdiction problems.” Annals of the Association of
American Geographers 94: 491

502.

Densham, P. J. (1991). “Spatial decision support systems.” In D. J. Maguire, M. F. Goodc
hild and
D. W. Rhind (eds.) Geographical Information Systems: Principles and Applications. New
York, John Wiley and Sons, pp. 403
-
12.

Fellbaum, C. (Ed.)., 1998. WordNet: An Electronic Lexical Database. The MIT Press.

M. F. Goodchild and A. Glennon (2008).
“Representation and computation of geographic
dynamics.” In K.S. Hornsby and M. Yuan (eds.): Understanding Dynamics of Geographic
Domains. Boca Raton: CRC Press, pp. 13
-
30.

Guarino, N. (1998). “Formal Ontology and Information Systems.” In N. Guarino (Ed.
),
Proceedings of FOIS’98, Trento, Italy. Amsterdam: IOS Press, pp. 3
-
15.

Jankowski, P. and T. Nyerges (2001). Geographic Information Systems for Group Decision
Making. Taylor & Fransis.

29


Jankowski, P. et al. 2006.
Design consideratio
ns and evaluation of

a collaborative, spatio
-
temporal decision support system
, Transactions in GIS, 10(3), pp.335
-
354


Leung, Y. (1997). Intelligent Spatial Decision Support Systems. Berlin, Springer
-
Verlag.

Malczewski, J. (1999) GIS and Multicriteria Decision Analysis. New Y
ork, John Wiley and Sons.

Malczewski, J. (2006) “GIS
-
based multicriteria decision analysis: A review of the literature.”
International Journal of Geographical Information Science, 20(7): 703
-
726.

Raskin, R. G. and M. J. Pan (2005) Knowledge representation

in the Semantic Web for Earth and
Environmental Terminology (SWEET), Computers and Geosciences, 31, pp. 1119
-
1125.

Sieber, R. (2006). “Public participation geographic information systems: A literature review and
framework.” Annals of the Association of Am
erican Geographers 96(3): 491
-
507.

Wu, F. (1998) “SimLand: A prototype to simulate land conversion through the integrated GIS and
CA with AHP
-
derived transition rules.” International Journal of Geographical
Information Science 12(1): 63

82.