KNOWLEDGE-MASHUPS AS NEXT GENERATION WEBBASED

SYSTEMS

Converging Systems Via Self-explaining Services

Thomas Bopp, Birger K

uhnel

University of Paderborn, Germany

Thorsten Hampel

University of Vienna, Austria

Christian Prpitsch, Frank L

utzenkirchen

University of Duisburg-Essen, Germany

Keywords:

Converging systems, webservices, mediation, knowledge organization, digital repository.

Abstract:

Webservice-based architectures are facing new challenges in terms of convergence of systems. By example

of a web service integration of a digital repository/library, systems of knowledge management in groups,

and learning management systems this contribution shows new potentials of ﬂexible, descriptive webservices.

Digital libraries are understood in their key position as searching, structuring, and archiving instances of

digital media and they actively provide services in this sense. The goal of this article is to introduce services

suitable for everyday use for coupling different classes of systems. Conceptually, the requirements of a possible

standard in the area of convergence of knowledge management, digital libraries, and learning management

systems are discussed. The results are publish and search services with negotiation capabilities with a low-

barrier for adoption.

1 INTRODUCTION

Mashups - the integration of different web-based ser-

vices and tools is one of the key challenges of our

modern information society - not only the Web 2.0 de-

velopment. Thus, a big challenge for the information

society lies in the combination and cooperation of dif-

ferent tools, systems and services. In this context ser-

vice oriented architectures (SOA) play an important

role and show that the understanding of computer sy-

stems as monolithic applications changes towards ﬂe-

xible, multi-layered service infrastructures. The em-

phasis of such systems is the interaction between

different web-based services using established stan-

dards. A common base for interoperability are web

services that allow integration of services through an

asynchronous, web-based protocol (SOAP). Web ser-

vices are self-explanatory and offer functionality on a

high abstraction level.

A critical look on existing software architectures

however shows a different picture than the one des-

cribed above. Service-oriented architectures are used

within certain classes of systems, but there are only a

few interoperable services between different classes.

Most of these services offer one-way reading capabi-

lities (e.g. search services of Amazon and Google),

but do not allow to write (the state of the system is

not affected). On the other hand, if a system offers a

broad range of functions, it lacks mechanisms for a

ﬂexible integration of those services, because there is

no standardized API for most systems. Therefore, the

idea of SOA respective web services allowing the ﬂe-

xible and scalable integration of web-based services

is not achieved in todays architectures.

Starting from scenarios of interoperability (Bopp

et al., 2006) of digital repositories, knowledge ma-

nagement systems, and planning systems, we un-

derstand a digital repository as a persistent locati-

on for documents. The repository provides document

(search) and allows their storage (publish and archi-

307

Bopp T., Kühnel B., Hampel T., Prpitsch C. and Lützenkirchen F. (2007).

KNOWLEDGE-MASHUPS AS NEXT GENERATION WEBBASED SYSTEMS - Converging Systems Via Self-explaining Services.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - DISI, pages 307-314

DOI: 10.5220/0002360003070314

 SciTePress

ve). Our research project mistel deals with conver-

gence of systems and ways to establish new standardi-

zed web services between the system classes of know-

ledge management, digital repository and planning

system. The sample implementation connects DuE-

Publico, sTeam, and ELM, but our approach is not

bound to these speciﬁc systems. Moreover, we iden-

tiﬁed different requirements and restrictions to be ab-

le to incorporate as many systems as possible. The-

refore, it is important to interoperate on different le-

vels and to ﬁnd the minimal common base for such

a connection. In this context for example a keyword

search serves as a minimum search capability a sy-

stem must offer for a service provider, as well as a

service client. In order to match the different capa-

bilities of the connecting systems we introduce a ne-

gotiation phase, which serves as an additional expla-

nation for web services. Based on the results of this

phase the service client may decide in which way it

contacts the service provider. Therefore, mistel crea-

tes a new unterstanding of web-based integration of

services which can be described as a mixture of low

level mashups and high level web service integration.

Our web services are ﬂexible enough to communicate

different levels of interoperability. On the other hand

they are easy to use (such as mashups) to be integra-

tied in most application out of the knowledge mana-

gement/digital library domain.

2 SERVICE ORIENTED

ARCHITECTURE

The Web 2.0 movement is mainly identiﬁed by new

social ways of user-centred forms of semantic struc-

turing of web content. Here, tags and folksonomies

stand for social forms of contextualization and or-

ganization of the web. Simultaneously, a new gene-

ration of successful web based tools, such as Flickr,

YouTube, or MySpace implement the ideas of user-

generated content and show the user new possibilities

of powerful ways of interaction on the net (for exam-

ple rich-client user interfaces such as Flickr).

Even more important in our understanding is the

paradigm seeing an application or tool not as a sin-

gle application in web 2.0, but understanding web

based applications as ﬂexible services. Unfortunately

this idea is so far only focused on a small number of

applications such as the above-mentioned tools. The

broad spectrum of existing E-Learning environments,

knowledge management, planning systems and digital

The term folksonomy is generally attributed to Thomas

Vander Wal.

libraries are still separated in its system classes with

only very limited and inﬂexible possibilities for mas-

hup.

Nevertheless, E-Learning-systems and infrastruc-

tures nowadays have reached a high standard. At

the same time, it becomes obvious that the interac-

tion between different classes of systems and an in-

tegration of other classes into an E-Learning-system

becomes the critical task of for the next generati-

on of cooperative tools on the web. In the exam-

ple of a university-wide infrastructure, E-Learning-

infrastructures span a number of service providers and

service-consumers, and are highly process oriented.

In this context various systems from study organiza-

tion, examination administration, to planning/ autho-

ring systems, and knowledge organization are invol-

ved. Here, digital repositories take a special role, be-

cause previously media as part of learning systems

was limited to the speciﬁc system. We see that the

above-mentioned idea of Web 2.0 as a mashup of dif-

ferent services and tools is not only limited to classi-

cal tools and services on the web nor is limited to new

business models for services on the web. The idea of

service integration is the crucial task for todays ser-

vice architectures, such as the architecture for organi-

zing knowledge as part of a university infrastructure.

The same ideas can be transferred to most infrastruc-

tures of larger organizations.

The mistel approach solves the problems of

knowledge-SOA from that end. With the new para-

digm of service oriented architectures there is the pos-

sibility of opening up digital repositories for new sce-

narios of use. In this context, the consequences of

a coupling between digital repositories and coope-

rative learning environments have to be explored. A

digital repository is regarded as a natural partner in

ﬁnding, structuring, and persistently archiving digi-

tal media. Previously, it has been shown by scenarios

(Bopp et al., 2006) how services of a digital reposito-

ry can be integrated into modern forms of cooperative

knowledge management. The focus of this integrati-

on lies in the combination of different systems in a

standardized way. Such a coupling must fulﬁl a num-

ber of requirements, mostly in the negotiation of the

provided services.

As part of the next chapter we will show how the

above-mentioned integration of different classes of

systems as a knowledge-SOA, a mashup of services,

is accomplished. Here, new forms of ﬂexible web ser-

vices have to be developed.

ICEIS 2007 - International Conference on Enterprise Information Systems

308

3 DIGITAL LIBRARIES,

REPOSITORIES AND

LEARNING OBJECTS

The presented approach to interoperating systems as-

sumes a lose coupling of service-oriented architectu-

res. Its central service provider is the digital reposi-

tory/digital library, which provides access to docu-

ments and collections of documents. In this context,

we distinguish between single documents (standalo-

ne), derivatives of a document, and collections of do-

cuments. In general, documents are not isolated, but

there may exist connections between different docu-

ments. For example, one document might be a versi-

on of another document in a different language (this

is a derivative of the original document). Another ex-

ample are several HTML-document including images

and stylesheets, which all together describe a single

topic and thus can be considered a single document.

This is important, when searching for documents, be-

cause such a collection should be displayed as a sin-

gle search result. Moreover, it must be retrieved as a

whole, because of the dependencies between the con-

tained documents.

Starting with scenarios of inquiry, and publishing,

the search for documents should enable a user to ﬁnd

appropriate documents, collections, and derivatives.

Thus, if there are several derivatives found of a do-

cument, the user must be able to identify those do-

cuments and choose one of them (for example in a

language the user is able to read and in a format that

can be processed). Technically, the system must al-

so be able to display collections of documents and to

import those documents as a whole.

Besides the digital repository/library, Learning

Object Repositories (LORs), Learning Management

Systems (LMS), Knowledge Management, and Plan-

ning Systems have been considered. Digital librari-

es are able to store any kind of document, but LORs

are focused on learning objects and often restricted

to a limited set of learning object formats and meta-

data formats (Neven and Duval, ). They are capable

of consistently extracting parts of SCORM-Learning-

Environments (Dodds, 2004) out of their contexts.

Searching for documents is usually done as a keyword

search, which is also the easiest method.

LMS differ from digital libraries/repositories by

their editing capabilities for learning objects. The or-

ganization in a LMS is typically hierarchical and can

technically be seen as a classiﬁcation.

The requirement for providing standardized and

open interfaces is derived from the interconnection

and the task sharing of the participating systems. Even

a simple life-cycle of a learning-unit from creation

in the planning/authoring-system, transfer to a LMS,

and ﬁnally to archival storage in a digital reposito-

ry/library already shows a couple of required interfa-

ces. This also includes search functionality for ﬁnding

learning units in all those places.

Currently, there are only a few existing solutions,

which can be considered for interconnecting diffe-

rent classes of systems. The standardized import and

export is limited to the context of E-Learning with

SCORM (Edutella (Nejdl et al., 2002), Ariadne GLO-

BE (Simon et al., 2005), and ADL CORDRA (Rehak

et al., )), which is not suitable to transport any kind

of document. There are no standardized interfaces for

transferring documents between arbitrary systems.

The standard OAI-PMH (Lagoze and de Sompel,

2001) of the Open Archives Initiative deﬁnes how me-

tadata of digital repositories can be exchanged. Howe-

ver, an exchange of documents itself is not speciﬁed.

Moreover, it is not suited for usage within E-Learning,

because metadata formats like Dublin Core are not ap-

plicable because of missing didactic details.

Some digital libraries/repositories like Aleph (Ex

Libris), or the open source system DuEPublico offer

proprietary interfaces for distributed searching in se-

veral installations of these systems. These interfaces

are not appropriate for searching in different reposi-

tories, because they are arranged around the peculia-

rities of the speciﬁc system. Importing documents is

not possible with any of the described systems.

In conclusion, there is an absence of standardized

interfaces between different classes of systems. Exi-

sting standards are not adequate in terms of openness

for using them in the context of the three classes de-

scribed above. Thus, we can derive requirements to-

wards an open architecture: It needs to be independent

from the organization of documents within a reposi-

tory, and must not depend on a certain metadata stan-

dard. Moreover, it should be easy to implement and

be able to adapt to different requirements. Therefore,

it should be possible to describe the capabilities of a

system/service.

4 INTEGRATION OF SERVICES

The goal of our work is to achieve integration of ser-

vices between different systems, which obviously re-

quires a common basis. Here, the starting point is

searching through a digital repository with its docu-

ments. In contrast to other functions search is a pu-

blic service of a repository, which generally does not

require authentication of users (only for certain docu-

ments or areas).

1 illustrates the coupling of the different systems.

KNOWLEDGE-MASHUPS AS NEXT GENERATION WEBBASED SYSTEMS - Converging Systems via

Self-explaining Services

309

Planning System

Digital Library

Knowledge

Organization

Research,

Publish, Archive

Transport

Learning Unit

Research,

Publish, Archive

Figure 1: Coupling Knowledge Management, Digital Libra-

ry and Planning System.

Initially, we identiﬁed the most important services

between the systems as publish, search, and archive

in the digital library. The only connection between

planning system and knowledge management is ex-

port/transport of learning units.

The integration of services was initially imple-

mented as a prototype to attain technical expertise and

test the ﬁrst version of our speciﬁcation. The followi-

ng substantial characteristics have been considered in

this ﬁrst version:

• Simplicity: The service needs to be simple in use

in order to integrate a large number of systems.

An extension of the functionality should be pos-

sible with different layers of complexity. A low-

barrier solution is very important for widespread

adoption of the speciﬁcation.

• Openness: Existing standards need to be conside-

red. This includes transmission protocols, encryp-

tion and compression methods, and metadata for-

mats.

• Adaptability: If possible, the absence of certain

features should not result into the exclusion of a

system. In fact, a common base should be found

that enables communication between systems.

Technically, web services offer a basis for a loo-

se coupling of systems, which meets all the require-

ments described above. Especially, it must be pointed

out that the implementation of the services guarantee

the openness of the system and do not use any speciﬁc

functionality of any of the systems. The negotiation

between the system’s capabilities is the central qua-

lity of our approach. This includes the goal to gua-

rantee communication between service provider and

service requester by ﬁnding a common basis for the

participants. The solution for this is a meta service

which encapsulates different services and standards,

and provides additional information about the indivi-

dual services. This meta service handles the commu-

nication in three phases. In the ﬁrst phase the service

requester connects and authenticates (the authentica-

tion is handled within the SOAP header).

Serviceprovider Client

Connection

establishment

Create

session

Authentication

informationen

Explain-request

for service

Session identiﬁer

Create XML-

skeleton for

service

explain("service")

XML-skeleton

Complete

XML-skeleton

If necessary

request further

information

Assemble

informationen

listClassiﬁcation("ID")

XML-answer

Using the

actual service

Using the

actual service

XML-documents

Figure 2: 3-phase communication-structure between client

and service-provider.

In the second phase the interoperability is negotia-

ted by examining the capabilities of the participating

systems. Finally, in the third phase a service is called

based on the interoperability observations from the

previous phase. The actual call of the service might

take several communication steps.

The negotiation and description of the provided

services takes place in the second phase. This is

characterized by an explain-function, which is simi-

larly part of the SRW speciﬁcation (SRW, 2005).

The SRW-explain method solely describes the SRU-

Server, e.g. the Endpoint URL of the web service and

its port number, the supported SRW version, or the

name and description of the server. Unlike this proce-

dure, the explain method, which is introduced in this

article, is strictly related to the individual services. For

each of the provided services all parameters are des-

cribed by an XML description, which basically mat-

ches the syntax of a query for this service. For exam-

ple, a search query includes the format of the meta-

data for the result of the query and the classiﬁcations

used for searching.

The following ﬁgure 2 illustrates this 3-phase

communication pattern between the client, wanting to

ICEIS 2007 - International Conference on Enterprise Information Systems

310

use the service and the service provider. The descripti-

on and negotiation takes place in the second phase by

using an XML-skeleton as the exchange-dataformat

of the explain-method.

4.1 Search

As a common basis for the integrated services each re-

pository allows certain types of search queries. Usual-

ly, this includes the classical keyword search, which

is the easiest possible type of query in terms of usage

and implementation. Such a simple search does only

return unspeciﬁc results. Thus, it is advantageous to

support a simple syntax as well as one or more com-

plex query syntax.

In general, we have to distinguish between the

query which is send from the client to the service and

the result of this query. Both have to follow certain

speciﬁcations and standards. Therefore, a system has

to support different syntaxes for the query and meta-

data standards for the result. A well established stan-

dard for metadata is Dublin Core (Dublin Core Meta-

data Initiative, 2005), which only supports a small set

of metadata (simple DC) compared to LOM (IEEE,

2002). Therefore, it can be considered a simple stan-

dard, which is easily supportable by any application.

Moreover, it is possible to ﬁnd a transformation from

the metadata of knowledge organization and planning

system to Dublin Core. Typically, a digital reposito-

ry uses much more metadata to describe a document

than other systems.

There are already a few existing standards for

search queries. For example, SRW (SRW, 2005) spe-

ciﬁes searching for documents with paging and as-

sembly of the result. Our approach is to use such stan-

dards within our service layer and to offer several pos-

sibilities for searching, retrieving and publishing do-

cuments. Therefore, it is necessary to negotiate which

methods and standards to use when calling a service.

To start the negotiation process for the search-

function, the user’s client has to call the function ex-

plain which is provided as part of our mistel-web ser-

vice. The explain-function requires the name of the

function, the client wants to get information about in-

put parameters, e.g. search for the search explanati-

on. The code listing 3 shows the exemplary XML-

skeleton code that the client receives upon the call

of explain(

”

search“). The XML response uses some

syntax expressions, which are freely adopted from the

XML Schema Deﬁnition (XSD). The code in listing 3

offers two different search methods (keyword or SRW)

which are encapsulated by the tag (method). Within

the method tags you will ﬁnd tags for all necessary

parameters for the respective method. The choice tags

are derived from XSD syntax and mean that the client

can choose between the two different methods key-

word or srw. The attribute id denotes the name of the

tags, the choice should be applied to. The remaining

two attributes minOccurs and maxOccurs describe the

amount of tags the client has to choose. In the search

example, the choice tag for method has minOccurs=1

and maxOccurs=1 which means, that the client has

choose at least one method but also not more than

one i.e. exactly one of the two available methods. The

choice tag is always used when the client has the pos-

sibility to choose from different available options.

A keyword-search needs at least one keyword to

search for, which is wrapped by the query tag. This

tag has the attribute use=“required” which means the

client has to provide the information within this tag.

The following choice tag offers the different metada-

ta formats for the search result, that are available. In

the example the client has to choose exactly one of

the two possibilities. The block of querymeta is labe-

led by use=“optional” meaning that all information

grouped within this tag are not necessary. The optio-

nal information are the maximum number of results

(maxresults), the offset for the start of the resultset

(startresults), the direction to sort the results ascen-

ding or descending according to a given ﬁeld (sort-

by) or a transformation stylesheet for displaying the

resultset (transformation). This stylesheet is determi-

ned by a speciﬁc URL, where it is stored. The second

method, the SRW-search only needs a SRW-query as

input, because all further information are encoded in

this query.

The whole explain-XML-code of the search-

method uses the textstring ### as a placeholder for

content, the client has to add to the marked places in

the XML-skeleton. A method getExplainPlaceholder

can be called to query this character string.

4.2 Publish

Despite the fact that there are a lot of different stan-

dards for searching documents, there is still no stan-

dard how to publish documents to digital repositories.

Due to that, we propose a method for publishing do-

cuments in this section which obviously has some si-

milarities to a search. For publishing, various parame-

ters have to be negotiated:

• What should be published?

• Where to publish it?

• Which metadata describe the document?

• Who publishes?

Metadata as well as the target are important for pu-

blishing and searching. Additionally the document to

KNOWLEDGE-MASHUPS AS NEXT GENERATION WEBBASED SYSTEMS - Converging Systems via

Self-explaining Services

311

1 <s ear c h xmlns =" ht t p : //www . syst e mkonv e rgen z . de">

5 <c h o ice id =" c l a ssif i catio n s " minOccurs ="0 " maxOccurs=" u nbounde d ">

</ ch o i c e>

10 <metadat a format =" rdf" />

</ ch o i c e>

< s t a r t r e s u l t s us e =" opti o n a l ">###</ s t a r t r e s u l t s>

15 <c h o ice id =" sort b y s " minOccurs="0" maxOccurs=" 1 ">

</ ch o i c e>

20 <c h o ice id =" lo c a tions " minOccurs =" 1 " maxOccurs="1 ">

</ ch o i c e>

</ t r a n s f o r m a t i o n>

25 </ q uery meta>

</ method>

</ method>

30 </ ch o i c e>

</ s e a r c h>

Listing 1: XML-Code of the explain for the “search”-method

Service: Keyword-Search

Classiﬁcations

List of available classiﬁcations

for search

Metadata formats

List of available metadata-formats for the

answer

Query-Metainformation

Pagination-, sort- and

transformationinformation

Service: SRW-Search

Only needs a SRW-Query

1 <s ea r c h xmlns=" http: // www. s y stem k o nver g enz . de ">

5 <c h o ice id =" c l a ssif i catio n s " minOccurs ="0 " maxOccurs=" u nbounde d ">

</ ch o i c e>

10 <metadat a format =" rdf" />

</ ch o i c e>

< s t a r t r e s u l t s us e =" opti o n a l ">###</ s t a r t r e s u l t s>

15 <c h o ice id =" sort b y s " minOccurs="0" maxOccurs=" 1 ">

</ ch o i c e>

20 <c h o ice id =" lo c a tions " minOccurs =" 1 " maxOccurs="1 ">

</ ch o i c e>

</ t r a n s f o r m a t i o n>

25 </ q uery meta>

</ method>

</ method>

30 </ ch o i c e>

</ s e a r c h>

Listing 1: XML-Code of the explain for the “search”-method

Service: Keyword-Search

Classiﬁcations

List of available classiﬁcations

for search

Metadata formats

List of available metadata-formats for the

answer

Query-Metainformation

Pagination-, sort- and

transformationinformation

Service: SRW-Search

Only needs a SRW-Query

1 <s ea r c h xmlns=" http: // www. s y stem k o nver g enz . de ">

5 <c h o ice id =" c l a ssif i catio n s " minOccurs ="0 " maxOccurs=" u nbounde d ">

</ ch o i c e>

10 <metadat a format =" rdf" />

</ ch o i c e>

< s t a r t r e s u l t s us e =" opti o n a l ">###</ s t a r t r e s u l t s>

15 <c h o ice id =" sort b y s " minOccurs="0" maxOccurs=" 1 ">

</ ch o i c e>

20 <c h o ice id =" lo c a tions " minOccurs =" 1 " maxOccurs="1 ">

</ ch o i c e>

</ t r a n s f o r m a t i o n>

25 </ q uery meta>

</ method>

</ method>

30 </ ch o i c e>

</ s e a r c h>

Listing 1: XML-Code of the explain for the “search”-method

Service: Keyword-Search

Classiﬁcations

List of available classiﬁcations

for search

Metadata formats

List of available metadata-formats for the

answer

Query-Metainformation

Pagination-, sort- and

transformationinformation

Service: SRW-Search

Only needs a SRW-Query

1 <s ea r c h xmlns=" http: // www. s y stem k o nver g enz . de ">

5 <c h o ice id =" c l a ssif i catio n s " minOccurs ="0 " maxOccurs=" u nbounde d ">

</ ch o i c e>

10 <metadat a format =" rdf" />

</ ch o i c e>

< s t a r t r e s u l t s us e =" opti o n a l ">###</ s t a r t r e s u l t s>

15 <c h o ice id =" sort b y s " minOccurs="0" maxOccurs=" 1 ">

</ ch o i c e>

20 <c h o ice id =" lo c a tions " minOccurs =" 1 " maxOccurs="1 ">

</ ch o i c e>

</ t r a n s f o r m a t i o n>

25 </ q uery meta>

</ method>

</ method>

30 </ ch o i c e>

</ s e a r c h>

Listing 1: XML-Code of the explain for the “search”-method

Service: Keyword-Search

Classiﬁcations

List of available classiﬁcations

for search

Metadata formats

List of available metadata-formats for the

answer

Query-Metainformation

Pagination-, sort- and

transformationinformation

Service: SRW-Search

Only needs a SRW-Query

1 <s ea r c h xmlns=" http: // www. s y stem k o nver g enz . de ">

5 <c h o ice id =" c l a ssif i catio n s " minOccurs ="0 " maxOccurs=" u nbounde d ">

</ ch o i c e>

10 <metadat a format =" rdf" />

</ ch o i c e>

< s t a r t r e s u l t s us e =" opti o n a l ">###</ s t a r t r e s u l t s>

15 <c h o ice id =" sort b y s " minOccurs="0" maxOccurs=" 1 ">

</ ch o i c e>

20 <c h o ice id =" lo c a tions " minOccurs =" 1 " maxOccurs="1 ">

</ ch o i c e>

</ t r a n s f o r m a t i o n>

25 </ q uery meta>

</ method>

</ method>

30 </ ch o i c e>

</ s e a r c h>

Listing 1: XML-Code of the explain for the “search”-method

Service: Keyword-Search

Classiﬁcations

List of available classiﬁcations

for search

Metadata formats

List of available metadata-formats for the

answer

Query-Metainformation

Pagination-, sort- and

transformationinformation

Service: SRW-Search

Only needs a SRW-Query

1 <s ea r c h xmlns=" http: // www. s y stem k o nver g enz . de ">

5 <c h o ice id =" c l a ssif i catio n s " minOccurs ="0 " maxOccurs=" u nbounde d ">

</ ch o i c e>

10 <metadat a format =" rdf" />

</ ch o i c e>

< s t a r t r e s u l t s us e =" opti o n a l ">###</ s t a r t r e s u l t s>

15 <c h o ice id =" sort b y s " minOccurs="0" maxOccurs=" 1 ">

</ ch o i c e>

20 <c h o ice id =" lo c a tions " minOccurs =" 1 " maxOccurs="1 ">

</ ch o i c e>

</ t r a n s f o r m a t i o n>

25 </ q uery meta>

</ method>

</ method>

30 </ ch o i c e>

</ s e a r c h>

Listing 1: XML-Code of the explain for the “search”-method

Service: Keyword-Search

Classiﬁcations

List of available classiﬁcations

for search

Metadata formats

List of available metadata-formats for the

answer

Query-Metainformation

Pagination-, sort- and

transformationinformation

Service: SRW-Search

Only needs a SRW-Query

Listing 3: XML-Code of the explain for the search-method “search”.

be published needs to be transferred to the service of

the digital repository/library. In this context the for-

mat of the document is important: is it a single do-

cument without any further relations, a collection of

documents, or a derivative of an existing document.

The transfer of documents also needs negotiation

between the service provider and service consumer

about the supported protocols. There are several dif-

ferent protocols for document transfer including http,

ftp, webdav and soap. Again, those standards are used

within our services instead of inventing new techno-

logies for upload and download. Generally, we distin-

guish between push and pull of documents. The ser-

vice provider might download the document, which is

provided by the service consumer at some location, or

might provide a location for uploading the document.

A SOAP attachment is useful for publishing small do-

cuments, because this method lacks streaming func-

tionality. When a document is published it also needs

to be classiﬁed within the structure of the reposito-

ry. Information about the target system is required,

which explains the used classiﬁcations and metadata

formats. Then, it is possible to choose a classiﬁcation

and metadata format.

In order to receive the XML-skeleton of the requi-

red parameters of the publish method, the client has to

call the explain method of the web service using the

parameter publish. The given listing 4 shows a possi-

ble example of a XML-skeleton received from the ex-

plain method. The structure is quite similar to the one

shown in listing 3 and also uses choice-blocks and use

attributes.

In general, one can divide a publish process into

three different possibilities: adding a new document,

changing or overwriting existing document or dele-

ting one. These three options are grouped into the ac-

tions choice-block, whereas the minOccurs=0 indica-

tes, that no action is also allowed. This implies, that

the action of adding a new document is used as default

action. After that, the client has to specify the kind

of document he wants to upload. In the example he

has three different types (document, collection, versi-

ons) from which he has to choose exactly one. The

type document is used for a single ﬁle (e.g. a PDF do-

cument), whereas collection and versions stand for a

package of several ﬁles. The type collection should

be used for packages of ﬁles, that need a special con-

version or treatment on the server, because they con-

sist of different types of ﬁles (e.g. SCORM packages).

In contrast, versions should be used for packages that

contain different formats of the same ﬁle (e.g. a ger-

man and an english version of a document).

After that, the source block starts, that contains

all the necessary information about how to receive

the document that should be published. Most of the-

se information are of course required. The packaging

block provides the client with a list of available packa-

ging or compression formats that the server accepts.

Within the optional mimetype tag the client may add

the speciﬁc mimetype of the document he wants to

publish. The following choice block of locations gi-

ves a list all possible types of transportation that are

supported by the server and the client has to choose

exactly one and specify the location where to ﬁnd the

document he wants to publish. Additionally he is able

to use the checksum tag to add a MD5 checksum to

test the data integrity after transfer.

The remaining tags are used to describe the pro-

perties the new document should receive in it’s new

environment after publishing it. Essential is that the

ICEIS 2007 - International Conference on Enterprise Information Systems

312

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

1

5 <a c t i o n i d ="### " o p e r a t i o n =" update " />

</ ch o i ce>

<ty p e>document</ type><ty p e>c o l l e c t i o n</ t y p e><ty pe>v e r s i o n s</ typ e>

</ ch o i ce>

10 <s o ur c e us e =" requ i r ed ">

<packaging>z i p</ packagin g><pa c k a g i n g>t a r

</ ch o i ce>

15 <c h o ic e i d ="l o cations " minOccurs="1" maxOccurs=" 1">

</ ch o i ce>

20 <checksum a l g o ri t h m ="md5 ">###</ checksum>

</ ch o i ce>

</ so u r ce>

25 <metad a t a format =" dc">###</ met a d a t a>

</ ch o i ce>

30 </ ch o i ce>

35 </ ch o i ce>

Listing 3: listClassiﬁation for PATH

Add / Delete / Update

Speciﬁcation of the operation

Distinction of the type

Currently in three different ones

Speciﬁcation of the source

Packet formats

Supported formats

Mime-type of the document

Source of the document

Could be available as download or SOAP

attachment

Checksums

For veriﬁcation of a correct transmission

Name

For the document

Metadata formats

Which are supported by the target system

Classiﬁcations

For classiﬁng the new document

Permissions

For the new document on the target

system

Name

For the document

Metadata formats

Which are supported by the target system

Classiﬁcations

For classiﬁng the new document

Permissions

For the new document on the target

system

Name

For the document

Metadata formats

Which are supported by the target system

Classiﬁcations

For classiﬁng the new document

Permissions

For the new document on the target

system

Metadata formats

Name

For the document

Metadata formats

Which are supported by the target system

Classiﬁcations

For classiﬁng the new document

Permissions

For the new document on the target

system

Listing 4: XML-Code of the explain for the publish-method “publish”.

document acquires a name on the server. The client

is able to add a list of metadata information to the

published document and should add at least on classi-

ﬁcation from the given list. The value of the maxOc-

curs attribute is unbound, which means, that the maxi-

mum number of classiﬁcations is not restricted. Each

classiﬁcation itself is also labeled with the bounding

attributes which might allow, that one type of classiﬁ-

cation is used several times with different values. By

using the mistel web service, it is possible to get mo-

re detailed information about one classiﬁcation type.

With the concluding choice block the client should

determine the permissions for the document. The ser-

ver lists all available permissions which are speciﬁed

by an unique ID, e.g. r, w and x and the client has to

set these accordingly to the desired state.

5 EVALUATION

The focus of this paper is to give a good overview

of the proposed new mistel web service integrating

different classes of systems of the knowledge mana-

gement and digital library domain. Hence, we are not

able to present our sample application in great detail.

Currently we integrated the mistel web service in our

mediarena composer application, which is a powerful

cooperative knowledge management system (Niehus

et al., 2006) (see http://ﬂywheel.open-steam.org/). As

part of using this tool for the cooperative structuring

of so called virtual knowledge spaces users are able to

search for relevant documents in various digital libra-

ries directly from the mediarena application. As pro-

posed in this paper mediarena also allows the storage

of documents (e.g. learning materials) in the digital

library. Our ﬁrst user experiences show that the seam-

less integration (reducing discontinutes in the use of

digital media) is a great success - even on a relatively

low level of supported search functionality. - As part

of the Web 2.0 movements mistel proves, that the ﬂe-

xible integration of web-based services inﬂates a great

potential on user centred tools and services.

6 RELATED WORK

Melnik et al. choose a different approach to cou-

ple services of digital libraries (Melnik et al., 2000).

An infrastructure for mediation between the services

is used to translate the queries (in this case search-

queries) in order to make them understandable for the

service provider. Therefore, it is possible to couple a

client with various target systems, that use different

formats and protocols.

The eduSource Project (Hatala et al., 2004) fol-

lows the IMS DRI speﬁciation (Global Learning Con-

sortium, 2003) and in this context implements ECL

(eduSource Communication layer) as a communica-

tion layer. Besides this ECL protocol a gateway fra-

mework is provided to include existing protocols and

formats. Here, it is distinguished between different

layers, which include the communication protocol,

the query language (for example ECL or OAI), and

the metadata. These layers are basically quite similar

KNOWLEDGE-MASHUPS AS NEXT GENERATION WEBBASED SYSTEMS - Converging Systems via

Self-explaining Services

313

to the different phases of negotiation described in this

work.

7 CONCLUSION

This article describes the integration of different ser-

vices into a uniﬁed framework, which focuses on an

extended descriptiveness of the services. This enables

a loose coupling of services with negotiation about

formats and protocols. Our speciﬁcation does not dic-

tate the usage of a speciﬁc standard, but suggests the

intersection of available metadata ﬁelds, query stan-

dards and classiﬁcations. In order to guarantee a com-

munication between service provider and service con-

sumer each service needs to support the most simple

methods like keyword search and simple Dublin Co-

re. On this basis interoperability is achieved between

services of different systems.

Apart from the negotiation capabilities of our ser-

vice speciﬁcation, we introduced a method for publis-

hing documents. Minimum requirements are a small

set of metadata, the name of the document, and the do-

cument itself. The transfer of the document data is ac-

complished using standard protocols like http or ftp.

Furthermore, the metadata can be negotiated between

service provider and service consumer.

The combination of search and publish ser-

vices successfully enables a loose coupling of di-

gital libraries, knowledge management systems, and

planning/authoring systems. Technically, publish and

search is similar to exporting and retrieving docu-

ments. Thus, the minimum requirement of exchan-

ging documents is fulﬁlled with the described speci-

ﬁcation. With dynamic negotiation of communication

between service provider and consumer we also met

the requirements of simplicity, openness and adapta-

bility.

ACKNOWLEDGEMENTS

The project is funded by the Deutsche Forschungsge-

meinschaft (DFG).

REFERENCES

Bopp, T., Hampel, T., Hinn, R., Ltzenkirchen, F., Prpitsch,

C., and Richter, H. (2006). Alltagstaugliche medien-

nutzung erfordert systemkonvergenz in aus- und wei-

terbildung. In E-Learning - alltagstaugliche Innovati-

on?, volume 38 of Medien in der Wissenschaft, pages

87–96.

Dodds, P. (2004). Scorm 2004 overview. Technical report,

Advanced Distributed Learning (ADL).

Dublin Core Metadata Initiative (2005). Dcmi meta-

data terms. http://dublincore.org/documents/

dcmi-terms.

Global Learning Consortium (2003). Digital re-

pository interoperability - core functions in-

formation model. http://www.imsglobal.

org/digitalrepositories/driv1p0/imsdri_

infov1p0.html.

Hatala, M., Richards, G., Eap, T., and Willms, J. (2004).

The interoperability of learning object repositories

and services: Standards, implementations and lessons

learned. In Proceedings of the 13th international

World Wide Web Conference on Alternate Track Pa-

pers & Posters, pages 19–27, New York, NY, USA.

ACM Press.

IEEE (2002). Draft standard for learning object metadata.

http://ltsc.ieee.org/wg12.

Lagoze, C. and de Sompel, H. V. (2001). The open archi-

ves initiative: building a low-barrier interoperability

framework. In Proceedings of the 1st ACM/IEEE-CS

joint Conference on Digital Libraries, pages 54–62,

New York, NY, USA. ACM Press.

Melnik, S., Garcia-Molina, H., and Paepcke, A. (2000). A

mediation infrastructure for digital library services. In

Proceedings of the Fifth ACM International Confe-

rence on Digital Libraries, pages 123–132.

Nejdl, W., Wolf, B., Qu, C., Decker, S., Naeve, A., Nils-

son, M., Palmer, M., and Risch, T. (2002). Edu-

tella: A p2p networking infrastructure based on rdf.

In Proceedings of the 11th International Conference

on World Wide Web, pages 604–615, New York, NY,

USA. ACM Press.

Neven, F. and Duval, E. Reusable learning objects: A survey

of lom-based repositories. In Proceedings of the 10th

Conference on Multimedia, pages 291–294.

Niehus, D., Hampel, T., and Sprotte, R. (2006). me-

di@rena: An eclipse based rich client application for

open-steam and its real world usage. In Proceedings

of the World Conference on Educational Multimedia,

Hypermedia and Telecommunications, pages 1304–

1309.

Rehak, D., Dodds, P., and Lannom, L. A model and infra-

structure for federated learning content repositories.

In Proceedings of the 1st Workshop on Interoperabili-

ty of Web-based Educational Systems.

Simon, B., Massart, D., van Assche, F., Ternier, S., Duval,

E., Brantner, S., Olmedilla, D., and Miklos, Z. (2005).

A simple query interface for interoperable learning re-

positories. In Simon, B., Olmedilla, D., and Saito, N.,

editors, Proceedings of the 1st Workshop on Interope-

rability of Web-based Educational Systems, pages 11–

18, Chiba, Japan. CEUR.

SRW (2005). Srw/u - search / retrieve web services. http:

//www.loc.gov/z3950/agency/zing/srw.

ICEIS 2007 - International Conference on Enterprise Information Systems

314