Semantic Locations in Online Communities

Martin Gruhn, Stefan Föll, Jens Pontow, David Linner, and Ilja Radusch

Technische Universität Berlin,

Sekr. FR 5-14, Franklinstrasse 28/29, 10587 Berlin, Germany

martin.gruhn@inf.tu-dresden.de, {foell,jpontow}@cs.tu-berlin.de,

{david.linner,ilja.radusch}@tu-berlin.de

Abstract

Humans usually think of a location not as pair of

coordinates but rather in a semantic way as place. In

this paper, we are presenting a concept to integrate

places in a framework for the development of user-

centered community platforms. We follow a grassroots

approach for collecting places and introduce an ontol-

ogy-based place model along with concepts for map-

ping geographic coordinates to places. Furthermore, a

place cloud is established as an intuitive user interface

for localization, place visualization, and the retrieval

of multimedia contents based on places. The prototypi-

cal implementation of our concepts proofs that places

are well suited for personalization and the semantic

annotation of multimedia contents in a social environ-

ment.

1. Introduction

Spatial information has made its way into most con-

text-aware and user-centered software: The user’s posi-

tion and static places (e.g., home and workplace) occur

as part of his or her profile, and also other entities such

as pictures, blog entries, or videos carry the location

they belong to (“geo-tagging”). Such information is

then presented to the user as metadata or even used for

content adaption and recommendation in general.

However, a location can be expressed differently de-

pending on the underlying location model. For in-

stance, the widespread Global Positioning System

(GPS) provides geographic coordinates, which are usu-

ally not interpretable by humans until they are dis-

played as points on a map. At the moment, this is

common practice in web-based systems mostly utilizing

Google Maps [1] as map service. However, humans

often think of a location in a more practical and seman-

tic way as place.

The nature of a place is influenced by the specific in-

dividual or user group. Additionally, a place is not nec-

essarily bound to one continuous area. For example, the

“Technische Universität Berlin” can be seen as one

place which is spread across several locations in the

city. A professor might rather call it his “workplace”

instead, and a group of students that traveled across

Europe might think of the route as a place labeled

“Europe Trip”. On the other side, operators and devel-

opers of collaborative and user-centered environments

often wish to know the type of a place. For instance, if

it is indoors or outdoors, or if a user is currently at

home without interest about where this specific loca-

tion may be. Finally, we need to be able to answer

questions about relations between places, e.g., prox-

imity, containment, or semantic affiliation.

The semantic information on locations or places wan-

ing from the human’s perspective can obviously not be

provided by generic positioning technologies, no mat-

ter whether they are network based (e.g., using GSM

Cell ID), badge systems (e.g., using IR beacons), or

using satellites (e.g., GPS). On the one hand, a location

model that deals with places should be combined and

cooperate with a positioning system to be able to map a

place to a location provided by common positioning

techniques. On the other hand, it does not need to be

bound to a specific positioning system. However, it is

not only an issue of getting ones position as place.

Moreover, we need to collect places as such along with

general and personal information about them.

The paper is structured as follows. Chapter 2 dis-

cusses related work and shows issues and features that

influenced our approach. In Chapter 3, we explain con-

cepts and requirements for our system. Next, the frame-

work’s architecture is covered in Chapter 4. Finally, we

document a prototypical implementation in Chapter 5.

International Conference on Semantic Computing

0-7695-2997-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICSC.2007.41

224

International Conference on Semantic Computing

0-7695-2997-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICSC.2007.41

224

International Conference on Semantic Computing

0-7695-2997-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICSC.2007.41

224

International Conference on Semantic Computing

0-7695-2997-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICSC.2007.41

224

International Conference on Semantic Computing

0-7695-2997-6/07 $25.00 © 2007 IEEEDOI 10.1109/ICSC.2007.41

224

2. Related work

Becker and Dürr distinguish geometric and symbolic

location models in [1] and define general requirements.

In geometric models locations are defined by coordi-

nate tuples relative to a reference coordinate system.

Symbolic location models define positions in the form

of abstract symbols, for instance, a room number or an

address. They identify the existence of topologic rela-

tions such as containment and spatial connection as an

important requirement that location models should ful-

fill. However, the authors point out the lack of the pos-

sibility for exact distance calculations and position

definitions with symbolic models. Leonhardt [3] pro-

poses a hybrid model where symbolic and geometric

models are combined. Consequently, locations can be

referenced by a symbolic identifier without loosing the

advantages of a geometric model. As a conclusion, a

user-centric location model has to consider a hybrid

approach.

In his position paper [4] Hightower argues that appli-

cations want to reason about place not coordinates. He

defines place as a human-readable labeling of positions

with both communal and personal labels for potentially

overlapping geometric volumes. He mentions the im-

portance of grassroots contributors and proper user

interfaces, although he emphasizes that places still have

to be defined manually and challenges the research

community with finding a solution to learn and label

places automatically.

The Reno application [5] on mobile phones lets the

user label places and links them to GSM Cell IDs in-

ternally. By this, the application can automatically in-

form friends or relatives of the user’s current location

represented by his or her place label. Nomatic*Gaim

[6] is an instant messaging platform that uses place

labels to indicate presence information. Additionally,

these labels and the geometric coordinates where they

have been reported are gathered. With statistical infer-

ence over the collected data, the system is able to de-

termine the probabilities for the label of a given

position. However, while in the Reno approach places

are user specific only, Nomatic*Gaim goes one step

further and aims at finding commonly used labels. Yet,

it does not consider the opportunity to classify places in

a way that machines could reason about them without

further processing and lacks the distinction between

generic and personal places, and places that belong to

one user group.

Also Roth highlights the role of place (he uses se-

mantic location as a synonym for place) for mobile

information access in [7]. He uses places in a frame-

work for location-based services and implemented a

decentralized infrastructure serving them as described

by Hadig and Roth in [8]. Furthermore, Roth dealt in

[9] with the semi-automatic extraction of places from

data sources that are provided by land survey offices.

While this is a step in the direction of a generic place

information system, it does not include the impact of

social or user specific views on places.

There are existing commercial web applications (e.g.,

[10], [11], [12]) that interpret location in a user-centric

way and integrate some concepts as mentioned above

already. For instance, Socialight [10] aims primarily at

mobile devices but can be used with a normal web

browser (e.g., on a laptop), too. Users can create sticky

notes at a specific place defined either by geographic

coordinates, an address, or a partial address (e.g., ZIP

code only). If just coordinates are given, the location is

mapped to an address and vice versa. These notes may

also be enriched with images and classified freely by

tag words. In return, users can search for stickies in a

specific area or subscribe to stickies at his or her posi-

tion permanently. The locations of sticky notes are also

shown on a map using Google Maps [1]. However, the

commercial web applications mentioned above have

one problem in common: Places are always anchored to

geographic coordinates (at least for visualization on a

map), or to an address or a part of it. For example, it is

impossible to relate to the city of Berlin as a whole or

to a place that refers to separate areas.

The existing commercial web applications show that

place is a relevant concept for user-centered systems to

describe location. However, scientific works as well as

these systems still lack a generic solution that serves

and maps not only general places but also personalized

and virtual places combined with components for

proper visualization and caption of place data.

3. Requirements

Place-awareness is an important feature for online

communities with mobile users. The user interprets

location as place depending on his or her understand-

ing, or in the context of a social community. Places can

be used in an online community to better describe and

recommend multimedia content, and to let people know

where they are. In return, the online platform is used to

gather knowledge about places. To support the user in

communication, sharing and retrieving interesting mul-

timedia content, place-awareness has to be combined

with a pervasive environment that allows building of

social networks and the classification of content. In the

following sections, requirements for supporting place-

awareness will be described along with requirements

for personalization and adaption, and the classification

of resources. An overview of the concepts to be men-

tioned is given in Figure 1.

225225225225225

Figure 1 Overview of concepts and features

3.1 Place-awareness

Requirements for the integration of place awareness

are divided into the following subtasks: The specifica-

tion of a place model defines how place data is struc-

tured, a mapper maps locations from other location

models to places, and visualization treats the presenta-

tion of places in a user interface. First, we require a

place model that allows the classification of places to

be able to distinguish between someone’s home or a

common place and other more general places (e.g.,

outdoor and indoor places). Topologic relations be-

tween places such as containment (e.g., Germany is in

Europe) and spatial proximity (e.g., Brazil is close to

Mexico) as well as semantic relation (e.g., my work-

place belongs to the “Technische Universität Berlin”)

must also be possible. A place refers to one or many

areas (e.g., a room or an area defined by a circle or a

polygon) that may be unconnected or overlap.

Occasionally, we need to map a location originating

from another location model to a place. This is always

the case when a user’s position is provided only by

GPS and therefore defined within the World Geodetic

System WGS 84 (the coordinate reference system used

by GPS). Also Google Maps, commonly deployed as

map service, uses geometric coordinates in WGS 84 for

defining positions. For compatibility and interoperabil-

ity reasons, it should further be possible to map ad-

dresses (consisting of country, ZIP code, Street name,

and house number) or even other external resources

such as a “Plaze” [11] to a place. However, there are

external frameworks that are specialized for mapping

tasks (e.g., [13]), and also web services that map an

address to WGS 84 coordinates already. Thus, the most

important feature is to map coordinates to our places.

Concerning the visualization of spatial information,

different approaches have to be considered. Usually, a

map is the first choice. In case of displaying one exact

position of some entity, it is an intuitive and familiar

view for the user. On the other side, there are some

issues when dealing with places that naturally do not

belong to one exact coordinate pair. Places may be

fuzzy and distributed over several areas. Hence, an

alternative visualization technique independent from a

map must be taken into account. It should concentrate

on places themselves and not their area. Also places of

almost virtual nature (e.g., the “Europe Trip” example

in the introduction) must be displayed properly as well

as relations between places.

3.2 Classifying resources

Media diversity is a central characteristic of today’s

multimedia authoring systems. Interactions among us-

ers in social networks are based upon the exchange of

arbitrary media data such as prevalent media types

(e.g., text, video, or images) or even the semantic de-

scription of contents (e.g., FOAF, RSS, or RDF). For

that purpose, rich metadata comprising semantic classi-

fication and description of contents are required to

cope with variety and amount of user generated data.

Thereby, places are used to describe contents seman-

tically. Furthermore, places themselves describe loca-

tions. This is why the distinction of different place

types (classifying places) is important. Professionals

should be able to mark up places explicitly in a ma-

chine readable way. In addition, we believe that a nor-

mal user does not want to “classify” his or her places –

he or she does not even know what classify means from

a technical perspective. Therefore, a free classification

as with folksonomies should be possible also with

places. If classification is meant as added value for the

user only, further components might not be necessary.

Otherwise, if machines are to evaluate or reason about

the place type, components that match folksonomy

terms to ontology concepts are required.

3.3 Personalization and adaption

Personalization and recommendation of content tai-

lored to interests and preferences of users are vital for

the provision of customized information. Users should

only be confronted with content they are likely to ap-

preciate. Underlying recommendation procedures must

take place transparently for the user to benefit system

acceptance and user discharge. In contrast to traditional

classification principles, e.g., hierarchical tree struc-

tures, we prefer so-called folksonomies, which are built

up collaboratively with the help of tag words. They are

suitable for the usage of personal and unrestrictive user

vocabularies and the need for frequent changes on con-

tent classification. Furthermore, ratings of users present

a form of feedback which may influence future recom-

mendation processes.

Personalization of places is necessary to define per-

sonal places or places that are visible to a specific user

group only. This is due to the fact that there are places

that almost everyone knows and, for instance, places

that only make sense for or should only be visible to

226226226226226

some friends. Self-organization of user communities is

desirable as the management of community member-

ships and the discovery of new relationships within

social networks can only be reasonably handled by

users to a certain extent. Relevant data such as informa-

tion about the user’s identity, his or her contextual

states (e.g., current location) as well as activities in the

social network (e.g., tags on user-generated content)

may be used to adaptively infer user memberships in

virtual communities. For instance, users sharing the

same interests (e.g., a hobby) could be associated

automatically with the same community. Moreover, the

integration of a flexible and meaningful right manage-

ment is needed to guarantee privacy and control of

visibility of personal information. The assigned rights

should be automatically applied to changing social

network structures.

Context-awareness represents an appropriate means

to provide users with information that is most suitable

to their current situation. Therefore, needs for acquisi-

tion, modification, and management of user context

data, especially place or even social, emotional, and

informational states of the user have to be taken into

account. In order to enable context-aware data retrieval

and delivery, we focus on a generic way of aggregating,

filtering, and interweaving relevant contextual data.

That way, context information can help building mean-

ingful structure overlays on stored media content. Us-

ers finally benefit from increased situation awareness

without the need to submit context data explicitly, e.g.,

users may be automatically provided with multimedia

content created by people staying at the same location.

Because current positioning devices (e.g., GPS re-

ceivers) do not serve place information directly, there

must be other ways of locating users or other entities.

A manual approach is letting the user him- or herself

define his or her position as place directly, although an

entire manual procedure has to be considered with cau-

tion. If there is a way offered to the user to choose the

position manually with little effort, this can be a rea-

sonable possibility. On the back side, it might build a

barrier many users would not overcome (users are lazy)

and as a consequence we do not have any information

about their position. A fully automated approach can

hardly be realized: It would include an automatic map-

ping, for instance, of geographic coordinates provided

by a GPS receiver to a place. But even there are man-

ual steps involved if the mapping is not clear enough,

either because the current place does not exist or the

result was ambiguous. Hence, a full automated location

sensing is not practical. Instead, we have to support the

user in choosing the position in a semi-automatic man-

ner.

4. Framework architecture

The requirements described in the previous sections

already implied that places and community services

have to be combined. Based on these needs, we de-

signed a framework for the development of multimedia

authoring systems that benefit from places and social

networks. It extends the framework described in [14]

with several components, in the following referred to as

the PICA Subsystem (Place Information System for

Context-aware Applications). The prototype inter-

weaves places in the management of meta-information

about multimedia content and social relationships.

Place and other metadata classify content and users in

order to improve the quality and convenience of infor-

mation retrieval.

External DBs

PICA Subsystem

Back-end

Online Community Framework

WebAccess

PlaceManager

ModelAdapter

ContentManagement

CommunityManagement

Personalisation andRecommendation

Front-end

Visualiser Locator

Mapper

Place OntologyGIS

PlaceCloud

`

Figure 2 Architecture

The functional building blocks composing the whole

system are illustrated in Figure 2. PICA has front-end

components that are applied for visualizing and locat-

ing a user in a place cloud, and back-end components

that deal with the place management and that rely on

external databases. Further functional building blocks

in the Online Community Framework are Community

Management (ComMan), responsible for all meta-

information about people, and Content Management

(ContMan), addressing all meta-information about con-

tent. With the Personalization and Recommendation

(PerRec) component they enable the integration of so-

cial networking and multimedia features in the system.

WebAccess contains functional entities used for a web

client interface. In the following sections, all functional

elements and their roles in the overall system are de-

scribed more in detail.

4.1 Place management

The PICA Subsystem consists of several components.

The central functional entity is the Place Manager. It

provides a generic interface offering functionality to

retrieve place information. In most cases, it does not

227227227227227

make sense to get the whole place model since it is

supposed to be quite big and ever growing. Hence, the

Place Manager offers a function to retrieve a partial

place model, e.g., information about a specific place

and all directly related places. Additionally, places can

be retrieved with geographic coordinates, and the Place

Manager allows adding new places as well as altering

existing places. Thereby, it relies on two other compo-

nents: The Model Adapter and the Mapper. They are

described in the following.

Access to the Place Ontology is provided through the

Model Adapter. It is based on a simple but extensible

place specification (T-Box), using OWL [15], that in-

cludes classes for different place types such as home,

workplace, indoors, outdoors and a generic class for

unspecified types. There are three possible relations

between places: “is-in” for containment, “close-to” for

spatial proximity and “belongs-to” for a logical connec-

tion (e.g., equality) between places. Places are then

stored as individuals in the Place Ontology (A-Box).

The Model Adapter component is able to retrieve

places and related data from the ontology and to insert

new places. It also handles the import of personal place

ontologies and is responsible for storing places persis-

tently.

4.2 Place mapping

A hybrid approach (see Section 2) to link a place to

its actual location would make sense if we integrated a

geometric model into the place model to be able to map

coordinates provided by GPS to places directly. How-

ever, the anchor of a place should not be restricted to

geographic coordinates only. For variability reasons,

we also think of linking a place to externally defined

locations, e.g., to a “Landmark” [1] or a “Plaze” [11].

As a consequence, we do not follow an integrated hy-

brid approach in the model itself. The place model is

designed to be absolutely independent from other loca-

tion models. Thus, the mapping does not take place in

the model but externally, so we are equally open for

external frameworks that are specialized in mapping

tasks (e.g., [13]).

The Mapper can map geographic coordinates to

places and also store new mapping information when

new places are created. Each place the Mapper is re-

sponsible for is connected to one or many areas that are

defined as shapes within WGS 84. The Mapper then

finds out which shapes include some given coordinates.

Furthermore, it allows for altering and adding shapes to

an existing place. For the storing and retrieval of

shapes, the Mapper uses a Geographic Information

System (GIS) that complies with the Web Feature Ser-

vice (WFS) specification of the OpenGIS Consortium

[16].

Figure 3 Place mapping

Because the Mapper is not aware of the containment

relation between places, and because they might over-

lap although they are not related within the place

model, it sometimes produces ambiguous and redun-

dant results. This is typically the case for points that are

covered by more than one feature. The ambiguity re-

sulting from overlapping but unrelated places cannot be

resolved, that is neither by the mapper nor with the

place model. On the other hand, redundant places can

be removed with the knowledge about the containment

hierarchy of places. Figure 3 shows an example: The

Mapper is queried for the location depicted as a cross,

and returns places A, B, and C (Step 1). The informa-

tion about place relations stored in the Place Model is

then applied (Step 2) to find the most specific places B

and C that are finally handed over to the Place Man-

ager.

As a result, the WGS 84 Mapper may return multiple

unrelated but most specific places. The application or

the user must then decide what place to use. However,

it can be assumed that places that overlap but are not

related with an is-in relationship are usually connected

with a close-to relationship. Hence, they could easily

retrieved by the Place Manager and would be included

in each partial place model at least with depth one, e.g.,

for visualization purposes.

4.3 Personalization and Community

management

PerRec is intended to determine and recommend re-

sources most appropriate to users. The system is com-

posed of a generic component that provides core

functionality to enable personalization of contents and

users based on user activities. These activities serve as

a data source for the determination of interests. Inter-

ests are obtained by using two different approaches, a

content-based approach and an approach based on col-

laborative filtering. The content-based approach is de-

rived from the idea of recommending content that is

similar to what a user enjoyed in the past. The collabo-

rative filtering approach tries to find patterns in the

user’s behavior to cluster users and make recommenda-

tions within these clusters of people. Based on unique

228228228228228

identifiers of items and statistical comparisons among

the histories of the users, items that have received a

positive feedback by one user are recommended to a

group of users with similar histories. Places are used to

recommend entities at the same place or other places

close by.

ComMan addresses all relevant functionality for the

management of users and their membership within

communities. The component manages not only basic

information about the user identities, it also stores

places that belong only to one user or a community and

thus shall not be visible to everyone. Thus, they are

stored in a separate ontology (A-Box) that is combined

with the general place ontology when needed. This

model could include the user’s home and workplace as

well as the favorite bar of a community. ComMan sup-

ports three kinds of social relationships: Friendships,

user-managed communities, and autonomously-

managed communities. In general, communities are

user groups that share any contents. User managed

communities are explicitly created and moderated by a

certain user. In contrast to the user-managed communi-

ties, autonomously-managed communities are not ex-

plicitly created by users. Instead, the collaborative

filtering approach of PerRec is utilized to determine

groups of people with similar interests. Thus, users are

recommended to other users that are likely to share the

same interests.

4.4 Content management

ContMan addresses storage of resources and meta-

information describing them. Resources are separated

into composite and atomic ones. For instance, video

clips are atomic resources. In contrast, composite re-

sources are supposed to be combined of multiple other

atomic or composite resources. Based on this separa-

tion, resources are represented in a hierarchal tree

structure, where each resource inherits metadata from

resources standing next to it. Metadata about multime-

dia content comprises semantic annotations, context

data and user-related data.

We utilize tags and rates on resources as semantic

annotations as referred to in Section 3.3. Consequently,

folksonomies are collaboratively formed and help to

improve the navigation between media resources that

have common characteristics. Additionally, the fre-

quency of occurrence as well as the semantics of at-

tached tagging words supports content classification.

Rates are numeric values limited by an upper and lower

boundary and assigned to resources by users. These

values express the quality of resources from the user’s

point of view. ContMan orders resources depending on

the rates of all other users to present more interesting

resources first. PerRec also depends on the rates gener-

ated by users to provide collaborative filtering.

Context data assigned to a resource usually reflects

the context of the user when creating this resource. In

contrast to semantic annotations described above, con-

text data is generated automatically. In particular, this

includes the place the resource belongs to. If the user

carries a GPS receiver or manually defines his or her

position in the form of coordinates, they will be at-

tached, too. We are storing all available spatial infor-

mation because, otherwise, important data might get

lost in a mapping process.

4.5 The place cloud

In Section 3.1 is explained that the visualization of

places on a map raises problems. Because topologic

relations are given, a graph structure is imposed with

places as nodes and relations as edges as depicted in

Figure 4 (“close-to” relations are represented by simple

edges, “is-in” relations by an arrow). This way, we are

not restricted to spatial constraints but can mark up

places that lie in and belong to each other clearly, and

we can show a place that is connected to multiple areas

just as one virtual place. Nevertheless, visualization

components are independent from the place model and

mapping components, so many different ways of dis-

playing places are possible.

For localizing a user by letting him or her manually

define the current place, the graph is used to “browse”

through the place structure. However, the user needs

support otherwise there is the risk that the procedure of

choosing the position would take too long and the user

aborts. If the user carries a GPS receiver his or her co-

ordinates are mapped to a place. Alternatively, they can

be defined in a map provided with the front-end

(“manual GPS”).

Figure 4 Example of a place graph

Several other techniques can be combined to give a

good starting point and to enable the user to choose his

or her current place in few steps. For example, IP loca-

tors usually give a rough idea about the location (at

least the country, sometimes even the exact address).

Depending on the context-aware environment we could

229229229229229

also suggest the place a user is most frequently or his or

her last position (possibly not using the same place but

the place containing it), or the home city.

5. Prototype

As a showcase for the features offered by our frame-

work, we have extended Online Community Life

(OCL), a community-based blogging portal for travel

diaries initially introduced in [14]. Travels are usually

associated with rich experiences and impressions users

want to communicate with others. Therefore, we assist

travelers to generate multimedia contents and places

along their way and share these contents with commu-

nities and friends.

Figure 5 Screenshot of Online Community Life with the

place cloud on the bottom right

5.1 Online community features

The OCL website (Figure 5) marks the entry point to

the blogging portal. Users can create accounts, blogs or

entries, upload multimedia, and annotate and rate con-

tent. Additionally, the management of user communi-

ties and profile administration is possible with the help

of this interface. Besides classical blogging characteris-

tics such as authoring and sharing of personal informa-

tion, additional features addressing user mobility and

context-aware media retrieval particularly using places

are considered.

Users may create blogs with multimedia resources for

special topics. They can be associated with read and

write rights, and distinct rights can be allocated for all

various communities a user is member of. Depending

on these rights and the user’s relationships, others can

contribute to blogs by generating new entries. Blog

entries may consist of textual descriptions and multi-

media attachments (Photo, Audio, Video, and Text).

Furthermore, users may comment and rate other en-

tries.

5.2 Collecting place data

We implemented a place cloud that visualizes a part

of all places as graph. When clicking on one place, the

cloud is re-rendered with the selected place as center

and directly related places (depth one). This way, the

user is able to “browse” through all available places to

his or her current place if it has not been recognized

correctly. In case an adequate place does not exist, the

user can define a new one. PICA supports him or her

during the creation process by automatically offering

relations that might suit. For example, it suggests an

“is-in” relation to a place the user is currently in. Fur-

thermore, he or she can restrict the visibility of a place

to a community which is appropriate for places such as

“home” and “workplace”. If a restricted place is con-

nected with a “belongs-to” relationship to a public

place, both places are shown as one place with the re-

stricted place name as label and the public place ap-

pearing only in tooltip-style on a mouseover event.

OCL offers a map service in addition to the place

cloud. It enables the user to manually define his or her

position in the form of WGS 84 coordinates. The coor-

dinates are used for initializing the partial place graph.

More important, the coordinates are used for updating

the Mapper (see Section 4.1) when new places are cre-

ated or the area of an existing place is altered. The lat-

ter occurs if a user redefines his or her position (as

place) although the current coordinate pair is not al-

ready known to the Mapper as part of the respective

place area. In this case, they are used as center point for

building a circular area with a constant radius that is

then added to the existing place shape.

Furthermore, it is possible to create a new place

based on all locations where entries of one particular

blog have been created. Again, imagine a blog that

contains a travel diary of a Europe trip. A new place

“Europe Trip” could be created that is linked to areas

the traveler has visited.

5.3 Place-based content retrieval

When a new blog or entry is created, it is associated

with the current place of the user as well as the position

in the form of geographic coordinates. This is impor-

tant because for the place-based retrieval of blog items,

both the assigned place and places that are mapped

from the item coordinates are considered. This would

also include blogs and entries that are not associated to

the given place explicitly but lie in its area. For exam-

ple, a blog with the location shown in Figure 3 would

be retrieved for Place B, Place C, and for Place A be-

cause it contains Place B. A more practical example:

230230230230230

Choosing the place “Europe Trip” mentioned above to

view contained entries would not only result entries of

the travel diary but also entries that have been created

close to the travel route although they are not associ-

ated to this place specifically.

Altogether, for the place-based content retrieval, ar-

eas are used that are user defined and enhanced dy-

namically by mapper updates. In contrast, existing web

services for location-based information retrieval (e.g.,

offered by Google [17] and Yahoo [18]) look for in-

formation only in static areas typically defined by the

City name or a ZIP code.

6. Conclusion

The implemented prototype shows that our place in-

formation system PICA harmonizes well with the user-

centered community platform Online Community Life.

Places give additional value to the user for the retrieval

of multimedia contents and offer a personalized and

semantic view on spatial information. The online com-

munity enables collaborative gathering of places, and

the place cloud has proved to be an intuitive user inter-

face for the interaction with places.

Prospective work includes the visualization of places

on a map, because maps represent an intuitive way of

dealing with location in general and should be com-

bined with places. Furthermore, the caption of place

information is still a manual process. Automatic place

recognition could be employed especially on mobile

devices to raise the acceptance and practicability of the

system.

7. References

[1] Google Inc., “Google Maps”. Available at:

http://maps.google.com. [Accessed: July 13, 2007].

[2] C. Becker and F. Dürr, “On location models for ubiqui-

tous computing”, in Personal and Ubiquitous Comput-

ing, 2005, Vol. 9, No. 1, pp. 20-31.

[3] U. Leonhardt, “Supporting Location-Awareness in

Open Distributed Systems”, PhD thesis at the Depart-

ment of Computing, Imperial College of Science, Tech-

nology and Medicine, University of London, 1998.

[4] J. Hightower, “From Position to Place”, in Proceedings

of The 2003 Workshop on Location-Aware Computing,

Oct. 2003, 2003, pp. 10-12.

[5] I. Smith, S. Consolvo, A. LaMarca, J. Hightower, J.

Scott, T. Sohn, J. Hughes, G. Iachello, and G. Abowd,

“Social Disclosure of Place: From Location Technology

to Communication Practices”, in Pervasive Computing:

Third International Conference, PERVASIVE 2005,

Munich, Germany, May 8-13, 2005. Proceedings,

Springer Verlag, Berlin, Heidelberg, 2005, pp. 134-151.

[6] D. J. Patterson, X. Ding, and N. Noack, “Nomatic: Lo-

cations By, For, and Of Crowds”, in LoCA 2006, LNCS

3987, Springer Berlin/Heidelberg, 2006, pp. 186-203.

[7] J. Roth, “The Role of Semantic Locations for Mobile

Information Access”, in INFORMATIK 2005 - Informa-

tik LIVE! Band 2, Beiträge der 35. Jahrestagung der

Gesellschaft für Informatik e.V. (GI), Bonn, 19. bis 22.

September 2005, 2005.

[8] T. Hadig and J. Roth, “Accessing Location and Prox-

imity Information in a Decentralized Environment” in

International Conference on E-Business und Telecom-

munication Networks (ICETE 2004), Setúbal (Portu-

gal), 25.-28. Aug., 2004.

[9] J. Roth, “Modelling Geo Data for Location-based Ser-

vices”, in 3. GI/ITG KuVS Fachgespräch Ortsbezogene

Anwendungen und Dienste am 7. und 8.9.2006 in Ber-

lin, FU Berlin, 2006, pp. 20-25.

[10] Kamida Inc., “Socialight”. Available at:

http://socialight.com. [Accessed: July 13, 2007].

[11] Plazes AG, “Plazes. Still Beta”. Available at:

http://beta.plazes.com. [Accessed: July 13, 2007].

[12] Qype GmbH. “Qype”. Available at: http://www.qype.de.

[Accessed: July 13, 2007].

[13] C. Jacob, I. Radusch, S. Arbanowski, and K. Kim,

“Storing, Interpreting and Querying Context-aware Lo-

cation Information”, in Proceedings of the 5th Work-

shop on Applications and Services in Wireless Networks

(ASWN 2005), Paris, France, June 29th - July 1st,

IEEE, 2005, pp. 85-92.

[14] S. Foell, J. Pontow, D. Linner, I. Radusch, “Classifying

Multimedia Resources Using Social Relationships”, in

Proceedings of the 8th IEEE International Symposium

on Multimedia (ISM 2006), San Diego, USA, December

11-13, 2006, pp. 690-695.

[15] W3C, “W3C Recommendation. OWL Web Ontology

Language Overview”, February 10, 2004. Available at:

http://www.w3.org/TR/owl-features/. [Accessed: July

13, 2007].

[16] Open Geospatial Consortium, “Web Feature Service

Implementation Specification”. Available at:

http://www.opengeospatial.org/standards/wfs.

[Accessed: July 13, 2007].

[17] Google Inc., “Google local”. Available at:

http://local.google.com. [Accessed: July 13, 2007].

[18] Yahoo Inc., “Yahoo! local”. Available at:

http://local.yahoo.com. [Accessed: July 13, 2007].

231231231231231