DL.org: Coordination Action on Digital Library Interoperability, Best Practices

splashburgerInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 4 χρόνια και 22 μέρες)

168 εμφανίσεις



DL.org: Coordination Action on Digital Library Interoperability, Best Practices
and Modelling Foundations

Funded under the Seventh Framework Programme, ICT Programme


“Cultural
Heritage and
Technology Enhanced Learning”

Project Number
:
231551


Deliverable Title:
Digital Library Technology and Methodology Cookbook: RFC
Version

Submission Due Date:
May
20
10

Actual Submission Date:

???

Work Package:

WP3

Deliverable Status:

DRAFT

Responsible Partner:

CNR


Deliverable Status:
Draft












www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
2

of
65




www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
3

of
65

Document Information

Project

Project acronym:

DL.org

Project full title:

Coordination Action on Digital Library Interoperability, Best
Practices & Modelling Foundations

Project start:

1 December 2008

Project duration:

24 months

Call:

ICT CALL 3, FP7
-
ICT
-
2007
-
3

Grant agreement no.:

231551



Document

Deliverable number:

D3.3

Deliverable title:

Digital Library Technology and Methodology Cookbook: RFC
Version

Editor(s):

L. Candela

Author(s):

… TB
D




Reviewer(s):

C.
Thanos (CNR) ?

Contributor(s):

… TB
D




Participant(s):

CNR, NKUA, UG

Work package no.:

WP3

Work package title:

Digital Library Models and Patterns

Work package leader:

CNR

Work package participants:

CNR, NKUA, UG

Est. Person
-
months:

6

Distribution:

Public

Nature:

Report

Version/Revision:

1.0

Draft/Final

Draft

Total number of pages:

(including cover)

65

Keywords:

Digital Library; Digital Library System; Interoperability
;

Pattern;
Interoperability Approach; Best Practice;


www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
4

of
65

Change Log

Issue

Date

Description

Author/Partner

0.1

April 2010

First draft

L. Candela

0.2

May 2010

Second draft

G
.
Athanasopoulos
, L. Candela, P.
Innocenti,
A. Nika,

G. Vullo


Record Log

Issue:
0.1

Revision: 1

Reason for change

Page(s)

Paragraph(s)

Drafting of the first version

N/A

N/A

Issue:
0.
2

Revision: 1

Reason for change

Page(s)

Paragraph(s)

Drafting of the second version

N/A

N/A


Document Approval

Person

Partner

Contact Details

Date

Costantino Thanos

CNR

costantino.thanos@isti.cnr.it


www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
5

of
65

Disclaimer

This document contains information on the core activities, findings, and outcomes of the EC
-
funded
project, DL.org, and in some
instances, distinguished experts forming part of the project’s Liaison Group,
six Thematic Working Groups and External Advisory Board. The document may contain references to
content in the DELOS Digital Library Reference Model, which is under copyright. An
y references to
content herein should clearly indicate the authors, source, organisation and date of publication.

This publication has been produced with the funding of the European Commission. The content of this
publication is the sole responsibility of
the DL.org consortium and cannot be considered to reflect the
views of the European Commission.


The European Union was established in accordance with the Treaty on European Union (Maastricht).
There are currently 27 Member States of the Union. It is base
d on the European Communities and
member states cooperation in the fields of Common Foreign and Security Policy and Justice and Home
Affairs. The five main institutions of the European Union are the European Parliament, the Council of
Ministers, the Europ
ean Commission, the Court of Justice and the Court of Auditors.
(
http://europa.eu.int/
)

DL.org is funded by the European Commission under the 7
th

Framework Programme (FP7).


www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
6

of
65

Table of Contents

1 Introduction

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

10

1.1 Interoperability levels and digital libraries

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

10

1.2 Overview of this document

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

12

1.3 Status of this document

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

12

1.4 Feedback

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

12

2 Digital Library Interoperability Model / Framew
ork

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

14

2.1 Digital Library Interoperability Characterisation

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

14

2.1.1

A bit of formalisation (
to be revised
)

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

15

2.2 Digital Library Interoperability Patterns

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

17

2.2.1 Standard
-
based Approaches

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

17

2.2.2 Mediator
-
based Approaches

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

19

2.2.3 Blending Approaches

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

19

2.3 The Interoperability Model in Action

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

19

3 Organisational, semantic and technical interoperability:
Best practices and solutions

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

20

3.1 Content Domain Interoperability Best practices and Solutions

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

20

3.1.1 Information Object Description Publishing/Presentation

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

20

3.1.2 Application Profiles

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

20

3.1.3 Standards for Information Objects / Metadata

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

21

3.1.4 Metadata Mapping / Crosswalks

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

21

3.2 User Domain Interoperability Best practices and Solutions

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

21

3.2.1 Rep
resentation of User Models: Shared Format Approach

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

21

3.2.2 User Models Conversion

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

22

3.2.3 User Profile Mapping

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

22

3.2.4 User Context Modeling

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

23

3.2.5 Authentication/Authorisation Protocols for User Management

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

24

3.3 Functionality Domain Inte
roperability Best practices and Solutions

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

26

3.3.1 Function Interface Reconciliation

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

26

3.3.2 Function Behaviour Reconciliation

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

29

3.3.3 Function Conditions Modelling

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

32

3.4 Policy Domain Interoperability Best practices and Solutions

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

34

3.4.1 Approaches for access policy interoperability

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

34

3.4.2 Approaches for preservation policy interoperability

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

35

3.4.3 Approaches for metadata policy interoperability

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

36

3.4.4 Approaches for Network policy inter
operability

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

37

3.4.5 Approaches for Collection development policy interoperability

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

37

3.4.6 Approaches for Intellectual property policy interoperability

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

37

3.4.7 Approaches for authentication policy interoperability

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

37

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
7

of
65

3.4.8 Approaches for Service Level
Agreements policy interoperability

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

38

3.4.9 Approaches for evaluation and assessment policy interoperability

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

38

3.4.10 Approaches for Policy Representation and Enforcement for policy interoperability

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

38

3.5 Qua
lity Domain Interoperability Best practices and Solutions

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

39

3.5.1 Ontology
-
based Quality Parameters Interoperability

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

39

3.5.2 Quality interoperability frameworks

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

42

3.6 Architecture Domain Interoperability Best practices and Solut
ions

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

44

3.6.1 Architectural Component Profile

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

44

3.6.2 Standard
-
based
Exploitation of third party Architectural Component

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

44

3.6.3 Mediator Services

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

45

4 Common Interoperability Scenarios: Approaches and Solutions

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

46

4.1 Scenario 1: Producing summary

versions of compound multimedia historical documents

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

46

4.1.2 Scenario 2: Developing a "gateway" Digital Library for cross
-
Digital Library Objects Retrieval

48

4.1.3

Scenario 3: Collaborative Digital Libraries

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

50

4.1.4 Scenario 4:

Depositor Choice

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

51

4.1.5 Scenario 5: Audiovisual collection management policies

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

52

4.1.6 Scenario 6: Appraisal Policy

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

52

4.1.7 Scenario 7: Content Replication

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

53

4.1.8 Scenario 8: Policy precision

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

53

4.1.9 Scenario 9: Metadata Evaluation

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

53

4.1.10 Scenario 10: Compliance to Standards

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

54

4.1.11

Scenario 11: Policy Cons
istency

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

54

5 Conclusions

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

56

6

Bibliography

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

57

Appendix A. Glossary

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

61

Appendix B. Index of solutions

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

63

Appendix C. Acknowledgements

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

65



www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
8

of
65

List of Figures

Figure 1. Interoperability Scenario
................................
................................
..............

14

Figure 2. Provider
-
oriented Standard
-
based Approach

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

18

Figure 3. Consumer
-
oriented Standard
-
based
Approach

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

18

Figure 4. Provider
-
side Mediator Approach

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

19

Figure 5. Con
sumer
-
side Mediator Approach

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

19

Figure 6. Third
-
party Mediator Approach

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

19

Figure 7. The DL.org Quality Core Model

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

42




www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
9

of
65

Summary

The demand for powerful and rich Digita
l Libraries able to support a large variety of interdisciplinary
activities as well as the data deluge the information society is confronted nowadays have increased the
need for “
building by re
-
use
” and “
sharing

. Interoperability is a central issue to sat
isfy these needs.
Despite its importance, and the many attempts to address it done in the past, the solutions to this
problem are today, however, still very limited. Main reasons for this slow progress are lack of any
systematic approach for addressing the

issue and scarce knowledge of the adopted solutions. Too often
these remain confined to the systems they have been designed for. In order to overcome this lack,
DL.org promotes the production of this document with the goal to collect and
describe

a portfo
lio of
best practices and pattern solutions to common issues faced when developing large
-
scale interoperable
Digital Library systems. This
document represents the

Request for Comment version

of the “Digital
Library Technology and Methodology Cookbook”
.

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
10

of
65

1

Int
roduction

Digital libraries represent the confluence of many interdisciplinary fields, from data management,
information retrieval, library sciences, document management to web services, information systems,

image processing, artificial intelligence,
human
-
computer interaction, and digital curation.

Its

multi
-
faceted nature has led researchers to offer a variety of definitions as to what a digital library is, often

reflecting on diffe
rent disciplinary perspectives
(Borgman, 2000; Fox, Akscyn, Furuta, & Leggett, 1995;
Fox & Marchionini, 1998; Ioannidis Y. , 2001; Ioannidis Y. , 2005; Ioannidis, et al., 2005; Lagoze C. , 2010)
.

As
(Gonça
lves, Fox, Watson, & Kipp, 204)

have explained the lack of unambiguous clarity on the
boundaries of the term digital library arise because they are essentially complex multi
-
dimensional
applications.
Ross
(Ross S. , 2003)

pinpointed those aspects by characterizing a digital library as “
the
infrastructure, policies and procedures, and organisational, political and economic mechanisms
necessary to enable access to and preservation of digital content
” (p. 5).

Among the curren
t crop of digital libraries
, there is a variety in character and type of content, with some
being homogeneous collections on particular topics or media whereas others have a heterog
eneous
character
(Ross S. , 2003)
. All digital

libraries are systems, and they instantiate particular systems and
information architectures. The lack of agreement on the best design of digital library systems reflects, in
part, a lack of agreement on the nature, functionality, and architecture of such

applications.

The “Digital Library Manifesto”
(Candela, et al., 2006)

and the


DELOS D
igital Library Reference Model


(Candela, et al., 2008)

aimed to address these lacunae. Starting with the DELO
S Reference Model as its
conceptual framework, the EU

funded

project
“DL.org
Digital Library Interoperability, Best Pra
ctices and
Modeling Foundations”

investigates interoperability issues in the context of digital libraries.
Digital
libraries are part of
larger ecosystems and must be able to interrelate within the ecospace and with
other infoecospaces
.

The DL.org project addresses digital library interoperability issues from the perspective of six core
constituent parts

characterising

the digital

library

according to the Reference Model, i.e.

Content,
User
,

Functionality, Policy, Quality, and

Architecture
.

1.1

Interoperability levels and digital libraries

Interoperability is among the most critical issues to be faced when building systems as “collections” of

independently developed constituents (syst
ems on its own) that should co
-
operate and rely on each
other to accomplish larger tasks.

There is no single interoperability solution or approach that is
powerful
enough

to serve the needs of digital library orga
nisations and digital library systems.

Actually, there is no single definition of interoperability which is accepted neither in the Digital Library
community nor by the diverse Digital Library communities and communities facing this kind of problem.

But
as it has been pointed out
,

while full interoperability may have a

plug and play


flavour (connect it
and it works), interoperation can be thought about in terms of different levels of technical and
conceptual agreement, such as agreements at syntactic,
protocol levels, or conceptual and semantic
modeling levels, or overall process level. Even though agreement at conceptual levels may not provide

plug and play

, it can greatly facilitate the configuration of information systems to make components
work to
gether

(Gridwise Architecture Council, 2005)
.

The DL.org project is addressing these multiple digital library interoperability levels, along the
classification of the European Interoperability Framework
(EIF)
for eGovernment
services

(IDABC, 2004)
:



Organisational interoperability

is concerned with defining business goals, modelling business
processes and bringing about the collaboration of
digital library (and their underlying systems)
www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
11

of
65

institutions

that wish to exchange
resources
1

and may have different internal structures and
processes. Moreover, organisational interoperability aims at addressing the requirements of the
user community by making
resources

available, easily identifiable, accessible a
nd user
-
oriented.



Semantic interoperability

is concerned with ensuring that the precise meaning of exchanged
digital
library resource

is understandable by any other
digital library “system”

that was not initially
developed
to deal with it. Semantic interop
erability enables systems to combine received
resources

with other resources and to process
(exploit)
it in a meaningful manner
;



Technical interoperability

is concerned with
the technical issues of linking computer systems and
services

implementing the digital libraries and their resources
.

At an organisational level, interoperability is a property referring to the ability of diverse systems and
organisations to work together
. Today organisational interoperability is considered a key st
ep to move
from isolated digital archives and digital libraries towards a
common information space

that allow users
to browse through different resources within a single integrated environment
(Fox, Akscyn, Furuta, &
Leggett, 1995; Borgman, 2000; Miller, 2000; Ross S. , 2008; Lagoze C. , 2010)
.

Organisation interoperability for digital libraries is a challenging and almost uncharted research area for
digital libraries.

Some studies h
ave been addressing organisational interoperability in fields as diverse as
engineering, military defense, GIS, data grids, open source software, public administration, e
-
learning



e.g.

(Bishr, 1998; Clark & Jones, 1999; Tolk, 2003; Tolk & Muguira, 2003; IDABC, 2004; Gridwise
Architecture Council, 2005; Assche, 2006; Tolk, Dial
lo, & Turnitsa, 2007)

(Ford, Colomb, Grahamr, &
Jacques, 2007; QUALIPSO project, 2008)



and more closer to the digital libraries specific domain
(Dekkers, 2007; Bygstad, Ghinea, &

Klaebo, 2008)

some of them related to addressing digital
preservation
from an holistic point of view
TBA

(Innocenti P. e., 2009)
.

The DL.org project is contributing to the advancement of organisational interoperability r
esearch in
particular from the perspective of the Policy and Quality domains

(Innocenti, Vullo, & Ross, 2010; Vullo,
Innocenti, & Ross, 2010)
.

As far as is concerned with the semantic and technical level, Wegner
(Wegner, 1996)

defines
interoperability as “
the ability of two or more software components to cooperate despite differences in
language, interface, and execution platform. It is a scalable form of reusability, being concerned with th
e
reuse of server resources by clients whose accessing mechanisms may be plug
-
incompatible with sockets
of the server
”. He also identifies in
interface standardization

and
interface bridging

two of the major
mechanisms for interoperation. Heiler
(Heiler, 1995)

defines interoperability as “
the ability to exchange
services and data with one another. It is based on agreements between requesters and providers on, for
example, message passing protocols, procedure names, error codes,
and argument types
”. He also
defines
semantic interoperability

as ensuring “
that these exchanges make sense


that the requester and
the provider have a common understanding of the ‘meanings’ of the requested services and data.
Semantic interoperability is

based on agreements on, for example, algorithms for computing requested
values, the expected side effects of a requested procedure, or the source or accuracy of requested data
elements
”. Park and Ram
(Park & Ram, 2004)

define
syntactic interoperability as “
the knowledge
-
level
interoperability that provides cooperating businesses with the ability to bridge semantic conflicts arising




1

According to the Reference Model (
Athanasopoulos, et al.
,

2010)

a Resource is any entity managed in the Digital
Library universe
.
Instances of the concept of
Resource

are
Information Objects

in all their forms (e.g. documents,
images, videos, multimedia compound objects, annotations and metadata packets, streams, databases,
collections, queries and their result sets),
Actors (
both humans and inanimate entities),
Functions
,
Policies
,
Quality
Parameters

and
Architectural Components
.

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
12

of
65

from differences in implicit meanings, perspectives, and assumptions, thus creating a semanticall
y
compatible information environment based on the agreed concepts between different business entities
”.
They also define semantic interoperability as “
the application
-
level interoperability that allows multiple
software components to cooperate even though
their implementation languages, interfaces, and
execution platforms are different


(Ram, Park, & Lee, 1999)
. In addition to that they state that emerging
2

standards, such as XML and Web Services based on SOAP (Simple Object Acc
ess Protocol), UDDI
(Universal, Description, Discovery, and Integration), and WSDL (Web Service Description Language),
might resolve many application
-
level interoperability problems.

As recognized by Paepcke et Al.
(Paepcke, Chang,
Winograd, & García
-
Molina, 1998)

more than ten year
ago, over the years systems designers have developed different approaches and solutions to achieve
interoperability. They have put in place a pragmatic approach and started to implement solutions
ble
nding into each other by combining various ways of dealing with the issues including
standards

and
mediators
. Too often these remain confined to the systems they have been designed for and lead to

from
-
scratch
” development and duplication of effort whenev
er similar interoperability scenarios occur
in different contexts.

The DL.org project is contributing to the advancement of semantic and technical interoperability
research in particular from the perspective of the Content, User, Functionality and Archite
cture
domains.

[to be completed]

1.2

Overview of this document

The aim of this document is to collect and document a portfolio of best practices and pattern solutions
to common issues faced when developing large
-
scale interoperable Digital Library systems.

Th
e remainder of the document is organised as follows. Section
2

describes a model / framework that
has been conceived to characterise interoperability scenarios and solutions. Section
3

documents a list
of approaches, best practices and solutions that proved to be effective to resolve well identified
interoperability issues. Section
4

discusses a list of common and challenging interoperability scenarios
faced when building large scale digital libraries and the concrete approaches put in place to resolve
them. Finally, Section
5

concludes the document by summarising its content and reporting closing
remarks.

1.3

Status of this document

This document is a Draft of a Request for Comments

version
. It is a work in progress, and should not be
consid
ered authoritative or final; other documents may supersede this document.

1.4

Feedback

The DL.org would like to receive input, suggestions and other feedback on this work from a wide variety
of Digital Library practitioners to improve its quality over time.

By

sending email, or otherwise communicating with DL.org, you (on behalf of yourself if you are an
individual, your institution if you are providing feedback on behalf of a institution, and your community
if you are providing feedback on behalf of a communit
y) will be deemed to have granted to DL.org, the




2

The identified standards were emerging at the time they produced

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
13

of
65

members of DL.org, and other parties that have access to your
f
eedback, a non
-
exclusive, non
-
transferable, worldwide, perpetual, irrevocable, royalty
-
free license to use, disclose, copy, license,
modify, sub
license or otherwise distribute and exploit in any manner whatsoever the
f
eedback you
provide regarding the work. You acknowledge that you have no expectation of confidentiality with
respect to any
f
eedback you provide. You represent and warrant that you h
ave rights to provide this
f
eedback, and if you are providing
f
eedback on behalf of a
n

institution or a community
, you represent
and warrant that you have the rights to provide
f
eedback on behalf of your
institution or company
. You
also acknowledge that
DL
.org

is not required to review, discuss, use, consider or in any way incorporate
your
f
eedback into future versions of its work. If
DL.org

does incorporate some or all of your
f
eedback in
a future version of the work, it may, but is not obligated to include your name (or, if you are identified as
acting on behalf of your
institution
, the name of your
institution
) on a list of contributors to the work. If
the foregoing is not acce
ptable to you and any
institution or company

on whose behalf you are acting,
please do not provide any
f
eedback.

Feedback on this document should be directed to
<insert an email here>
.

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
14

of
65

2

Digital Library Interoperability Model / Framework

One of the main diff
iculties affecting the interoperability domain is the lack of a common model that can
be used to characterise


in a systematic way


the problem facets as well as the existing and
forthcoming solutions and approaches. In this section, it is presented the
interoperability model
underlying this Digital Library Technology and Methodology Cookbook. The
interoperability

approaches,

methodologies,

best practices and solutions described in Section
3

are described with this model as
blueprint.

2.1

Digital Library Interoperability Characterisation

The IEEE Glossary defines interoperability as “
the ability of two or more systems or components to
exchange information and to use
the information that has been exchanged


(Geraci, 1991)
. This
definition highlights that to achieve interoperability between two entities (provider, consumer) two
conditions must be satisfied:
(i)

the two entities must be able
to exchange information and
(ii)

the
consumer entity must be able to effectively use the exchanged information, i.e. the consumer must be
able to perform the tasks
it is willing to by relying on the exchanged information
.

By having this definition as f
irm starting point, we characterised the following three concepts:



interoperability scenario
, i.e. the settings where interoperability take
s

place;



interoperability issue
, i.e. a problem hindering an interoperability scenario;



interoperability solution
,
i.e. an approach aiming at removing an interoperability issue toward
s

an
interoperability scenario.


Figure
1
. Interoperability Scenario

An
interoperability scenario

(cf.
Figure
1
)
occurs whenever the following conditions manifest:



there are
at least two
entities

that have to cooperate in the context of the scenario
, one of the
entities is playing the role of
Provider

while
the other one is playing the role of
Consumer
;



the cooperation envisages the exploitation of a certain
Resource
3



own by the
Provider



to
perform a certain
Task



the work the
Consumer

is willing to do by relying on the third party
Resource
;



to make the
scenario feasible the two entities should be
able to
exchange “meaningful” information
.
There can be no exchange of information without a
communication channel

whose functioning is
regulated by a
protocol
, i.e. a medium enabling information exc
hange and some rules governing its
effective use to pass information among entities. There can be no information without some form of




3

According to the Reference Model it is an
identifiable entity in the
Digital Library

universe.

In includes
Information Objects
, Collections, Resource Set, Functions, Architectural Components.

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
15

of
65

representation
, i.e. information is “carried” or “arises from” a representation
(Devlin, 1991)
.

T
he
meaningfulness

of the information
depends from
the
Resource

and the
Task

characterising the
scenario,
i.e. the

Resource

should satisfy the
Consumer

need
s

and the
Consumer

should acquire the
information
on the
Resource

that is required to perform the
Task

(
Task precondition
s
)
;



the operation of each entity, either
Provider

or
Consumer
, depends from
Organisational
,
Semantic

and
Technical

aspects.
Organisational aspects

capture characteristics

of
business goals

and
processe
s

of the institution operating the entity
.

Examples of organisational aspects are

the type of
policies governing Information Objects consumption, the type of functionality to be exposed to
Consumers,
the quality of service to be supported with respect to a

specific functionality
.

Semantic
aspects

capture characteristics of

the
meaning of exchanged
digital library resource

as well as of the
rest of information exchanged through the communication channel
.

Examples of
semantic

aspects
are
the meaning assigned
to a certain policy, the meaning assigned to a certain quality parameter,
the meaning assigned to a certain value in a metadata record.

Technical aspects

capture
characteristics of

the technology supporting the operation of the entity as well as of the
com
munication channel

and the information exchanged through it
.

Examples of
technical

aspects
ar
e
the DLMS used to implement the Digital Library, the protocol used t
o expose a certain function,
the encoding format of an Information Object.

It is important to
notice that these three levels
influence each other in a top
-
down fashion, i.e. organisational aspects set the scene of the entire
domain characterising the scope and the
overall functioning
, semantic aspects define the meaning
of the entities involved in
the domain according to the organisational aspects, technical aspects
have to put in place / implement the organisational and semantic aspects.

An
interoperability issue

occur whenever the
Task preconditions

are not satisfied. Task preconditions
are not
satisfied whenever the expectations of the
Consumers

in terms of the
Provider

Reso
urce

to
perform the
Task

are not met by the settings of the scenario,
i
.
e
.
the technical, semantic
and/
or
organisational aspects characterising the
Provider

and the
Consumer

for the sake of the
Resource

and
the
Task

are not compatible.

Exemplars of interoperability issues
include:

the format used
by the
Provider
to
represent an Information Object
differ
s

from the format expected by
Consumer to
support a
processing activity
;

t
he interface through which the Information Object access function is supported by
the Provider differs from the one the Consumer is expected to use
for content fetching
;
the semantic of
the search function implemented by the Provider is different from the
semantic the Consumer
aim at
rely
ing

on

to support a cross system search
;
the Policy governing Information Object consumption
supported by the Provider are different from the Policy expected by the Consumer.

(
tbc)



An
interoperability solution

is an appr
oach
aiming at

reconcil
ing

the differences
captured by an

interoperability issue
. It is based on a generic
transformation function

that conceptually acts at any of
the levels characterising
Provider

and
Consumer



organisational, semantic and technical


and unify
the
P
rovider

characteristics with

the
C
onsumer

needs
.

Such transformation function may act on the Provider
characteristics as well as on the Consumer needs as well as on both.
Exemplars of interoperabil
ity
solutions include
: the transformation and exposure of metadata objects through the harvesting protocol
and format expected by the Consumer, the implementation of a search client based on a search
interface specification implemented by the Provider, the

implementation of policies client
-
side and
server
-
side to guarantee the agreed quality of service on a distributed search operation.

(
tbc)

2.1.1

A bit of formalisation

(
to be revised
)

Ambiguity in a natural language is an essential part of it, it is often an ob
stacle to be ignored or a
problem to be solved for people to understand each other. In the following we introduce a formalisation
www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
16

of
65

of some of the most important concepts introduced above to characterize Digital Library
Interoperability.

An
Interoperability
Scenario

IS

is defined as follows:

IS = <P,C
,R,T
>

where:



P

is the
Provider
, i.e. the entity
that is contributing to scenario by providing something (the
Resource
)
. Every Provider is characterised by a set of
facts

F
P
, i.e. assertions on P;



C
is the
Consumer
, i.e. the entity
that is benefitting from the scenario by acquiring something (the
Resource
) for its use (the
Task
)
. Every Consumer is characterised by a set of
facts

F
C
, i.e. assertions
on C;



R

is the
R
esource
, i.e. the “good
s

the two
entities

i
nvolved in the scenario are willing to “
exchange




provide or acquire
. Every Resource is characterised by a set of
facts

F
R
, i.e. assertions on R;



T
is the
T
ask
, i.e. the work the
Consumer

is willing to perform by relying on a third party
Resource
.

Every
Task is characterised by a set of
Task preconditions

TP, i.e. the set of
facts

TP = {F’
P



F’
C



F’
R
}
the Task T requires with respect to the Provider P, the Consumer C and the Resource R involved in
the scenario;

The
facts

characterising a Producer P, a Consumer C or a Resource R are a set of assertions capturing
distinguishing features of the entity they are about. According to the framework previously described
they deal with
Organisational
,
Semantic

and
Technical

aspects.

For the sake of this brief formalisation
aiming at clarifying the meaning of interoperability scenario, issue and solution it is neither needed nor
feasible to list the entire set of features that should be captured. They heavily depends from the
scenario

and are driven by T, i.e. if T poses a certain requirement w.r.t. R then this requirement is
captured by one of the facts in
{F’
R
}

(e.g. R is a metadata record and its schema should be DublinCore)
and it should be verified whether such a fact holds for R
or not.

Given an Interoperability Scenario
IS
(
P,C,R,T
)
,

Interoperability take place
if and only if


satisfy(ISS,TP)

where:



ISS

is the
Interoperability Scenario Settings
, i.e.

the set of
facts

{F
p



F
c



F
R
}

characterising the
Provider
P
, the Consumer
C

and the Resource
R

involved in the scenario;



satisfy(ISS,TP)
iff

{F

P
}



{F
P
}

&
{F

C
}



{F
C
}

&
{F

R
}



{F
R
}
.

Given an Interoperability Scenario IS, an
Interoperability Issue

occur if
satisfy(ISS,TP)=false
.


Introduce an example here

An
Interoperability
Solution

S
is “defined” as follows

S=
<
SP
,
SE
,

>

where:



SP

is the
solution precondition
,

i.e. the set of facts {F
PS



F
C
S



F
R
S



F
T
S
}
on the

Provider P
S
,
the

Consumer CS
,

the

Resource R
S
, and the Task TS characterising the scenario the solution is conceived

for;



SE

is the
solution effect

and
is defined as
the set of facts {F’
PS



F’
C
S



F’
R
S



F’
T
S
} holding on the
Provider P
S
, the Consumer CS, the Resource R
S
, and the Task TS characterising the scenario the
solution is conceived for;

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
17

of
65





is a
mediation

/
transformation function

such that

(
PS
)

F’
PS

&

(CS)

F’
C
S

&

(RS)

F’
R
S

&

(TS)

F’
T
S
.


Given an Interoperability Scenario
IS
(
P,C,R,T
)

such that
satisfy(ISS,TP)=false
,

a
solution S
(
SP
,
SE
,

)

is
effective

iff
:



SP


{ISS


TP}, i.e.
{F
SP
}


{F
P
} & {F
CS
}


{F
C
}
& {F
R
S
}


{F
R
}

& {F
TS
}


{F
T
}

(
the solution is
applicable
)
;



satisfy(

(ISS),

(TP)
)

(the solution is effective).

Introduce an example here

2.2

Digital Library Interoperability Patterns

Although
the plethora of heterogeneous interoperability scenario
s

and
the related
issues existing in
the
Digital Librar
y domain,
all of them can be
resolved

by
relying on two classes of solutions
independently
from their distinguishing characteristics
:
Standard
-
based approaches

and
Mediator
-
based approaches
.

In practice, int
eroperability scenarios and issues are complex and requires the combination of multiple
solutions to be resolved. Even in this case, the constituent solutions are either standard
-
based o
r
mediator
-
based. In some cases
standard
-
based and mediator
-
based approaches blend into each other,
e.g. a mediator
-
service is actually implementing part of its mediation function according to the standard
settings and rules.

2.2.1

Standard
-
based Approaches

The use of standard
-
based approach
es is a first step to achieve DL interoperability.
Standards are
codified rules and guidelines for the creation, description, and management of digital resources
. The
critical importance of standards is widely recognized, as there is considerable movement
globally to
develop specifications to communicate between DL systems.

Interoperability standards

provide the common medium, serving as the “glue” for DL systems. They
offer the following benefits

(The Standards Committee of the Nat
ional Defense Industry Association
(NDIA) Robotics Division, 2007)
:



reduce life cycle costs



the cost to develop, integrate, and support DL systems is reduced by
eliminating custom implementations;



reduce development and integration time



common co
mmunications prevent the reinvention of the
wheel and allow speed integration since proven technology is being employed;



provide a framework for technology insertion



as new technologies are created, those technologies
can be easily integrated with minor to no modification to existing systems.

While the ability to communicate between systems is a pre
-
requisite for interoperability, it is also
necessary to have common

‘dialects’ by which to share actual information. Some existing standards that
are used in the direction to support interoperability are listed below:



XML



the eXtensible Markup Language (XML) was developed by the World Wide Web Consortium
(W3C) to provi
de a common language for
developing systems and communicating between them
. It
should be noted that while XML has been implemented in many systems, there is no agreed
vocabulary (schema) between vendors. This effectively makes the storage of content propri
etary
and limits the value of XML in achieving interoperability.



Web Services



Web services is a name given to a collection of specifications for communication
between systems (as well as information storage and retrieval) using XML and web technologies.
Development in this area is being conducted by the W3C and by many proprietary software
www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
18

of
65

companies. Specifications such as SOAP, WSDL, and UDDI form the core of web services, although
there are too many other specifications to list here;



Metadata Standards



The goal of metadata consistency has been promoted by the
Dublin Core
Metadata Initiative (DCMI)
, which established a base set of metadata elements for all content. This
has been implemented widely and has been included as part of the core HTML standard.



Taxonomies and Ontologies



There are a number of active standards relating to the structuring and
classification of content,

including:

o

Resource Description Framework (RDF);

o

Topic maps (XTM);

o

eXchangeable Faceted Metadata Language (XFML);

o

Outline Mark
up Language (OML);

o

Web Ontology Language (OWL);

o

RDF Schema.

These provide a range of ways to structure information and are valuable tools for interchange of
information between systems.

Unfortunately, there is still a lack of any consensus standards in th
is area and, as Gill and Miller point out
in their article
(Gill & Miller, 2002)
, there is still a tendency to either develop completely new standards
frameworks from scratch, or to adopt a “mix and match” approach, using porti
ons from existing
domains, and “adapting” them for specific applications.
Although local or adapted standards are
certainly better than no standards, this approach can significantly diminish the value of a digital
resource by limiting its interoperability
with the wider networked world
. There is a massive duplication
of effort taking place in the realm of standards for digital resources and the sub
-
optimal nature of this
situation is obvious to anyone involved in developing these frameworks.


Actually, this kind of solution both de facto and de jure


Figure
2
.
Provider
-
oriented
Standard
-
based Approach


Figure
3
. Consumer
-
oriented Standard
-
based Approach

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
19

of
65

2.2.2

Mediator
-
based Approaches


Figure
4
. Provider
-
side Mediator Approach


Figure
5
. Consumer
-
side Mediator Approach


Figure
6
. Third
-
party Mediator Approach

2.2.3

Blending Approaches

Any combination of the

previous, i.e. mixing mediators and standard.

2.3

The Interoperability Model in Action

Each interoperability solution will be described as follows:



Overview
:
few lines describing the context of the proposed approach and providing the reader with
pointers to
extensive descriptions of the proposed approach, best practice or solution;

(TBC)



Preconditions
:
the settings the interoperability scenario must satisfy to make it possible
the usage of
the solution;

(TBC)



Effects
:
the setting resulting from the usage of t
he solution;
(TBC)



Transformation function
:
the hot the effects are achieved;
(TBC)



Assessment
:
a qualitative evaluation
(TBC)

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
20

of
65

3

Organisational, semantic and technical interoperability:
Best practices and solutions

The list of items included in Sections
3.1

to
3.6

result from the input circulated some time ago from the
Working

Group Leaders. It is neither complete nor agreed.

3.1

Content Domain Interoperability Best practices and Solutions

3.1.1

Information Object Description Publishing/Presentation

Xxx

Concrete exemplars of
this kind of interoperability solution are:

OAI
-
PMH

(cf. Section
3.1.1.1
)


a
protocol xxx,
OAI
-
ORE

(cf. Section
3.1.1.2
)


a xxx, and
Linked Data

(cf. Section
3.1.1.3
)


a set of best
practices for publishing and connecting structured data on the Web.

3.1.1.1

OAI
-
PMH

The Open Archives Initiative Protocol Metadata Harvesting
(OAI
-
PMH)
(Open Archives Initiative, 2002;
Lagoze & Van de Sompel, 2001)

provides an application
-
independent interoperability framework for
metadata sharing.

There are two kinds of actors involved in the framework
: Data Providers and Service
Providers. A Data Provider manages a metadata repository and uses the OAI
-
PMH as a means to expose
metadata to harvesters. A harvester is a client application operated by a Service Provider to issue OAI
-
PMH requests to a reposi
tory managed by a Data Provider.

3.1.1.2

OAI
-
ORE

The Open Archives Initiative Object Reuse and Exchange (OAI
-
ORE)
(Open Archives Initiative, 2008;
Lagoze & Van de Sompel, 2008)

defines standards for the
description and exchange of aggregations of
Web resources, i.e. compound objects consisting of a set of related resources. These aggregations may
combine distributed resources with multiple media types including text, images, data, and video. The
goal of t
he standards is to expose the rich content in these aggregations to applications that support
authoring, deposit, exchange, visualization, reuse and preservation.

3.1.1.3

Linked Data

Linked Data is a set of best practices for publishing and
connecting structured data on the Web

(Bizer,
Heath, & Berners
-
Lee, 2009)
. The following rules/principles are the foundational ones and are known as
the Linked Data Principles:



use URIs
(Berners
-
Lee, Field
ing, & Masinter)

as names for things;



use HTTP URIs so that people can look up those names;



when someone looks up a URI, provide useful information, using the standards
namely
RDF

(Klyne &
Carroll)

and

SPARQL
(Prud’hommeaux & Seaborne)
;



include links to other URIs, so that they can discover more things.

3.1.2

Application Profiles

Xxx

Concrete exemplars of this kind of interoperability solution are:


www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
21

of
65

3.1.2.1

Europeana Semantic Element
s (ESE)

Europeana Semantic Elements (ESE) is a Dublin Core
-
based application profile developed in the context
of the Europeana.

It identifies a generic set of DC elements and some locally coined terms, which have
been added specifically to support European
a’s functionalities.


3.1.3

Standard
s

for
Information Objects /
Metadata

Concrete exemplars of this kind of interoperability solution are:

3.1.3.1

Dublin Core

3.1.4

Metadata Mapping / Crosswalks

Xxx

Concrete exemplars of this kind of interoperability solution are:

3.2

User Domain Interoperability Best practices and Solutions

3.2.1

Representation of User Models: Shared Format Approach

The shared format approach for the representation of user models imposes the use of a shared syntax
and semantics to represent user models. The user model
l
ing community has focused recently to
ontology based approaches, which br
ing several advantages. The advantages leading to using ontologies
for user model
l
ing come from the fundamentals of this formalism. Once user characteristics are in
ontological representation, the ontology and its relations, conditions and restrictions pro
vide the basis
for inferring additional user characteristics. By creating an ontology
-
based user model we increase the
probability that user characteristics will be shared among a range of systems. One of the most obvious
advantages of a shared model is th
at one system can use the initialized data for personalization from
other systems preventing the user from entering the same information into every system (e.g., name,
locale settings). However, the key advantage of the shared user model is the availabilit
y of user
characteristics discovered by other systems since user characteristics acquisition is considered to be the
bottleneck of personalization.

3.2.1.1

General User Model Ontology

The current problem of syntactical and struc
tural differences between existing user modelling systems
could be overcome with a commonly accepted ontology, specialized for user modelling tasks. This
ontology should be represented in a modern semantic web language like OWL and thus via internet be
ava
ilable for all user adaptive systems at the same time. Heckmann et al.
(Heckmann, Brandherm,
Schmitz, Schwartz, & M., 2005)

introduced the General User Model Ontology (GUMO). They collected
the user’s dimensions that are modell
ed within user
-
adaptive systems like the user’s heart beat, age,
current position, birthplace, or the user’s ability to swim. Furthermore, the modelling of the user’s
interests and preferences like reading poems, playing adventure games or drinking certain

French
Bordeaux wines is analyzed. The main conceptual idea for the construction of the specialized user model
ontology GUMO was to divide the descriptions of user model dimensions into three parts: auxiliary
-

predicate
-

range. If one wants to say somet
hing about the user’s interest in football, one could divide
this into the auxiliary=hasInterest, the predicate=football and the range=low
-
medium
-

high.

A key feature is that the semantics for all user model dimensions are mapped to the general user model
ontology GUMO. Thus the interoperability between distributed user
-
adaptive systems is granted.

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
22

of
65

The classes and properties of GUMO are employed into the user model exchange language called
UserML
(Heckmann & Kruger, 2003)

w
hich supports the user model data exchange across systems. With
the markup language UserML, Heckmann et al. try to contribute a platform for the communication
about partial user models in a ubiquitous computing environment, where all different kinds of sys
tems
work together to satisfy the user’s needs.

3.2.2

User Models Conversion

The major advantage of the shared format approach is that no syntactic and semantic heterogeneity
issues need to be solved since there is a unified model
that is easily exchangeable and interpretable.
Indeed, user model interoperability is strongly streamlined. However, in open and dynamic
environments, such as the Web or decentralized ubiquitous settings, it is impractical, and in many cases
impossible, to

create a unified user model infrastructure and to enforce applications to adhere to a
shared vocabulary. The opposite approach excludes the use of any semantic representation or of a
shared representation for the user model. On the contrary, it defines pr
oper algorithms and techniques
to convert the syntax and semantics of the user model schema characteristics in one system into those
used in another system.

3.2.2.1

Schema mapping of Generic User model Component

Van der Sluijs et al.
(Van der Sluijs & Houben, 2005)

introduced the Generic User model Component
(GUC) which is a generic component that utilizes Semantic Web technology to provide user model server
capabilities. GUC is a
generic component that offers functionality to store data models for applications
and to exchange user data between those models. Applications can “subscribe” to GUC and then can
request and upload user data of particular users. In order to provide this fu
nctionality for an application,
GUC requires a schema that describes the data structure of the user model for that application. GUC
stores these application schemas in its application schema repository.

In order to exchange user models between multiple app
lications GUC uses the Shared User Model (S
-
UM), which contains the most used concepts within the domain. By creating a mapping to and from
every application and S
-
UM, S
-
UM can be used as a mediator for the exchange of user data between the
applications. A
lso, direct mappings between applications are allowed, such that the need for a more
custom
-
made exchange of application
-
specific information can be fulfilled.

A schema mapping from a schema A to a schema B contains a specification of how all constructs in

schema A are mapped to corresponding constructs in schema B. For example, for the semantical
mapping between birth date and age an interpretation directive has to be given, in this case a formula
that indicates how age can be calculated by subtracting the

value for the birth date from the current
system time. Schema mappings are delivered by the GUC mapping module. For this, the mapping
module requires the source schema, say A, and the target schema, say B. The mappings are generated
based on the similarit
ies between two input schemas and are expressed in the rule language SWRL. As
the mapping between schema A and schema B only has to be constructed once, it can be created by the
(human) designer.

3.2.3

User Profile Mapping

Having a c
ommon model or a way to move a user profile from one DL to another is not enough. One
important issue that should be considered is the issue of data reconciliation, which is related on how to
reconcile different and in some cases even conflicting user prof
ile characteristics. Maybe in a DL the user
has specific recorded preferences whereas in another slightly or importantly different ones. This may be
due to several reasons ranging from how the profile was elicited or explicitly created by the user to
www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
23

of
65

issue
s related to user context.
A data reconciliation rule helps to define what to do if an actual value in
the first DL is different from the corresponding value in the second DL.
General approaches include the
concatenation of the two values,
the
replacement
of the current value
, or
the use of a given formula in
order a decision to be taken
. Examples of such decisions are decisions based on time
-
stamping (e.g.
latest time
-
stamp wins) or based on a trust value (of the user) for the corresponding DL.

3.2.3.1

Instance ma
pping of Generic User model Component

The Generic User model Component
(Van der Sluijs & Houben, 2005)

that was introduced in the
previous section deals also with the is
sue of data reconciliation. GUC is not used solely for the storage of
user models, but also to exchange data on the user between different applications. An application may
request for a particular user the corresponding instance of its application schema.
Such an instance is
called a user application
-
view (UAV). On such a request, GUC will simply send the UAV as the application
last uploaded it. An instance of one application’s UM schema (modelled in OWL) can be translated into a
(partial) instance of anoth
er application’s UM schema. Suppose we want to exploit data from UAV a
within UAV b. To do that, the data of UAV a are first transformed into the structure of UAV b. Second,
this transformed UAV a


has to be integrated into the existing UAV b
. This transfo
rmation and
subsequent integration form an instance mapping. The instance mapping is generated from a schema
mapping.

Data reconciliation is supported by applying the OWL and SWRL techniques. For each application, rules
can be defined that specify how to r
econcile data in the case of a conflict. The data reconciliation rule
type helps to define what to do if a value in the transformed UAV already exists in the UAV that it should
be integrated in: it is possible that the value is concatenated with the curren
t value, or that the current
value is replaced, or that a decision is made based on a given formula.

Whatever the algorithm used for schema matching, the result must be verified and possibly be edited by
hand before it can be effectively used. This is bec
ause semantical structures may not be interchangeable
just like that. Schema elements that seem the same may not be interchangeable on instance level.
Consider for instance the related concepts user
-
name and password. While the semantical meaning of
these
concepts might be completely the same for two applications, the concrete values for these
concepts for a particular end
-
user still might not be interchangeable for those applications.

3.2.4

User Context Modeling

Adequate user modell
ing is the basis for every kind of personalization. Beyond properties of the users
themselves, as they are traditionally captured in user models, information about the users’ situation can
be used for extended personalization support leading to user contex
t models. Cross
-
system
personalization requires a unified approach to user context modelling that captures the relevant facts
about users and their current situation in a way that can be shared by different systems.

3.2.4.1

The Unified User Context Model and the c
ontext
-
passport approach

Niederee et al.
(Niederee, Stewart, Mehta, & Hemmje, 2004)

introduced an extensible Unified User
Context Model (UUCM) that can be used for modelling characteristics of the user and his situation, i.e.
the user context, along different dimensions. T
he basic building

blocks for the UUCM are
user context,
user mode
l facets, core properties for facet description, and user model dimensions.
The UUCM just
defines the principle way a user context profile is described and structured for cross
-
system
personalization. For the description of concrete user context profiles t
he UUCM relies on ontologies (or
vocabularies) for the UUCM dimensions, the UUCM facets and for the facet values.

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
24

of
65

The context passport can be seen metaphorically as an identification that accompanies the user when
navigating through the information space.

The context passport is a compact representation of the
user’s current context model for cross system personalization. It also contains the activities chosen by
the user to be performed in order to fulfil the tasks allotted. It contains ontologically
-
arra
nged
information about the user’s current tasks and related activities, his cognitive patterns (skills, area
-
of
-
interest etc), the environment (time, place, device used), and his personal web of the people and
relationships involved, following the UUCM mod
el for user context modelling. In order to use the
context passport for cross system personalization, the user takes the context passport and “presents” it
to an information system (IS) that the user wants to use. Since the context passport is bound to a s
hared
ontology, there is a chance the IS can partially interpret the context passport using a mediator
architecture. As a result of this partial interpretation, two flows of information are possible: one from
the context passport to the IS, and secondly fr
om the IS to the context passport. The first flow helps the
IS to better understand what the user requires from the IS, since the context passport refers to the task
model, activities and also other information about the user context model. The second flow

arises due
to the interaction between the IS and the user which changes the state of the user’s context. The
purpose of this flow is to update the context passport with the feedback from the interaction.

3.2.5

Authentication/Authorisation Protocols for User Man
agement

In the area of user authentication/authorization there are some successful and widely used
authentication/authorization protocols. An increasingly frequent problem with standards is

that there
are too many of them and unfortunately they are designed in such a way that alignment among them is
significantly difficult to achieve. Consequently, the need for creating interoperable solutions in this area
became imperative. Before enumerati
ng the various proposals, we need to emphasize on the notion of
“federated identity”.

Federated identity, or the “federation” of identity, describes the technologies, standards and use
-
cases
which serve to enable the portability of identity information acr
oss otherwise autonomous security
domains. The ultimate goal of identity federation is to enable users of one domain to securely access
data or systems of another domain seamlessly, and without the need for completely redundant user
administration.
Federat
ion is enabled through the use of open industry standards and/or openly
published specifications, such that multiple parties can achieve interoperability for common use cases.
Typical use
-
cases involve things such as cross
-
domain
web
-
based
single sign
-
on,
cross
-
domain user
account provisioning, cross
-
domain entitlement management and cross
-
domain user attribute
exchange.

3.2.5.1

OpenID

OpenID
4

is an open, decentralized standard for authenticating users which can be used for access
control, allowing u
sers to log on to different services with the same digital identity where these services
trust the authentication body. OpenID replaces the common login process that uses a login
-
name and a
password, by allowing a user to log in once and gain access to the

resources of multiple software
systems.

The OpenID federation mechanism operates in the following manner: The user visits a relying party web
site which displays an OpenID login form somewhere on their page. Unlike a typical login form with
fields for the

user name and password, the OpenID login form has only one field

for the OpenID




4

http://openid.net/

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
25

of
65

identifier. This form is connected to an implementation of an OpenID client library. A user typically will
have previously registered an OpenID identifier with an OpenID ident
ity provider. The user types his
OpenID identifier into the aforementioned OpenID login form. The relying party web site typically
transforms the OpenID identifier into a canonical URL form. Thereafter, the relying party and the
identity provider (optional
ly) establish a shared secret, referenced by an associate handle, which the
relying party then stores. If using checkid_setup, the relying party redirects the user's web browser to
the identity provider so the user can authenticate with the provider. The m
ethod of authentication may
vary, but typically, an OpenID identity provider prompts the user for a password or an InfoCard, then
asks whether the user trusts the relying party web site to receive his credentials and identity details.

There are two types o
f identifiers that can be used with OpenID: URLs and XRIs. XRIs are a new form of
Internet identifier designed specifically for cross
-
domain digital identity. For example, XRIs come in two
forms



i
-
names and i
-
numbers



that are usually registered simulta
neously as synonyms. I
-
names are
reassignable (like domain names), while i
-
numbers are never reassigned. When an XRI i
-
name is used as
an OpenID identifier, it is immediately resolved to the synonymous i
-
number. This i
-
number is the
OpenID identifier store
d by the relying party.

3.2.5.2

Security Assertion Markup L
anguage
(SAML)

The OASIS Security Assertion Markup Language (SAML)
5

standard defines an XML
-
based framework for
describing and exchanging security informat
ion between on
-
line business partners. This security
information is expressed in the form of portable SAML assertions that applications working across
security domain boundaries can trust. The OASIS SAML standard defines precise syntax and rules for
reques
ting, creating, communicating, and using these SAML assertions.

SAML defines XML
-
based assertions and protocols, bindings, and profiles. The term SAML Core refers to
the general syntax and semantics of SAML assertions as well as the protocol used to reques
t and
transmit those assertions from one system entity to another. SAML protocol refers to what is
transmitted, not how (the latter is determined by the choice of binding). So SAML Core defines “bare”
SAML assertions along with SAML request and response el
ements. A SAML binding determines how
SAML requests and responses map onto standard messaging or communications protocols (HTTP, SOAP,
etc). A SAML profile is a concrete manifestation of a defined use case using a particular combination of
assertions, prot
ocols, and bindings. These profiles provide solutions for the two main driving forces
behind the introduction of the SAML standard, namely Single Sign
-
On (SSO) and Federated Identity.

3.2.5.3

eXtensible Access Control Markup Language (XACML)

The eXtensible Access Control Markup Language (XACML)
6

is an OASIS Standard that defines the syntax
and semantics of a language for expressing and evaluating access control policies. XACML describes both
an access contro
l policy language and a request/response language. The policy language is used to
express access control policies (who can do what when). The request/response language expresses
queries about whether a particular access should be allowed (requests) and des
cribes answers to those
queries (responses).

The non
-
normative XACML usage model assumes that a Policy Enforcement Point (PEP) is responsible
for protecting access to one or more resources. When a resource access is attempted, the PEP sends a
description o
f the attempted access to a Policy Decision Point (PDP) in the form of an authorization




5

http://docs.oasis
-
open.org/security/saml/v2.0/

6

http://www.oasis
-
open.org/committees/tc_home.php?wg_abbrev=xacml

www.dlorg.eu

DL.org

This is a
DRAFT copy. Please, do not circulate it.

DL.org

No. 231551

D3.3

Digital Library Technology and Meth
odology Cookbook: RFC Version

Page
26

of
65

decision request. The PDP evaluates this request against its available policies and attributes and
produces an authorization decision that is returned to the PEP. The P
EP is responsible for enforcing the
decision. In producing its description of the access request, the PEP may obtain attributes from on
-
line
Attribute Authorities (AA) or from Attribute Repositories into which AAs have stored attributes. The PDP
(or, more
precisely, its Context Handler component) may augment the PEP's description of the access
request with additional attributes obtained from AAs or Attribute Repositories. The PDP may obtain
policies from on
-
line Policy Administration Points (PAP) or from Po
licy Repositories into which PAPs have
stored policies.

3.3

Functionality Domain Interoperability Best practices and Solutions

3.3.1

Function Interface Reconciliation

Function interoperability heavily relies upon the compati
bility (i.e. composability or replaceability) of the
comprising function interfaces and of the interface specification mechanisms. For example incompatible
inputs/outputs i.e. either with respect to their type or their conveyed info may hinder the interope
ration
of specific functions. Similarly although several mechanisms may be adapted for the semantic and/or
syntactic specification of function interfaces the employment of distinct mechanisms clearly hinders the
interoperation of functions. Therefore, faci
litating the interoperation of functions largely depends on
the use of compatible function interfaces and interface specification mechanisms.

An ample of mechanisms and techniques related to the description and integration of services have
been proposed i
n the service oriented computing domain. Those approaches, which are presented next,
may be easily incorporated and adapted for the DL functionality domain.

3.3.1.1

Function Interface Specification Primitives


S
everal approaches have been proposed to address the interface specification needs of the Service
Oriented Computing domain. These include:



WSDL

(Booth & Liu, 2007)
:

is an XML
-
based language used for
describing func
tional properties of
Web services
. It aims at providing self
-
describing XML
-
based definitions that applications, as well as
people, can easily understand. WSDL enables one to separate the description of a Web service's
abstract functionality from the concr
ete details of how and where that functionality is offered. This
separation facilitates different levels of reusability and distribution of work in the lifecycle of a Web
service and the WSDL document that describes it.

According to the standard the compr
ising primitives accommodate the necessary syntactic info to
facilitate the invocation of services. Additional properties