Functional specification for Europeana Rhine release

toadspottedincurableInternet and Web Development

Dec 4, 2013 (3 years and 8 months ago)

190 views

Functional specification for
Europeana Rhine release





Europeana v1.0


Grant Agreement Number:
558001
Del
iverable number

D3.1

Dissemination level

Public

Delivery date

September 30, 2009

Status

Final

Author(s)

Ruth Bloomberg, Makx Dek
kers, Stefan
Gradmann, Mats Lindquist,
Catherine Lupovici,
Carlo Meghini
, Julie Verleyen




D3.1

Functional specification of Rhine



2

1

Introduction

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

1.1

About this document

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

1.2

The Attachment folder

................................
................................
.............................
6

2

Background and scope

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

2.1

The current prototype

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

2.2

D2.5 functionalities not included in the current prototype
................................
........
7

2.3

Priorities for R
hine

................................
................................
................................
...
9

2.4

The technical roadmap

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

10

3

Europeana end users

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

11

3.1.1

Group characteristics

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

11

3.1.2

Group motivation

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

12

3.1.3

Group expectations

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

13

3.2

External applications/APIs

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

15

3.2.1

Group Characteristics

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

15

3.2.2

Group Expectations

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

15

3.3

Content aggregators/Content providers

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

16

3.3.1

Group Expectations

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

16

3.4

Service providers

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

19

3.4.1

Group characteristics

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

19

3.4.2

Grou
p objectives

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

19

3.4.3

Group Expectations

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

19

3.5

Meta users and administrators

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

19

3.5.1

Group characteristics

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

19

3.5.2

Group expectations

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

19

4

Functional areas

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

21

4.1

Search and results

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

21

4.1.1

Introduction

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

21

4.1.2

The Europeana database

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

21

4.1.3

Simple search

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

24

4.1.4

Advanced search

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

28

4.1.5

Word autocompletion

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

37

4.1.6

Alternative spellings

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

37

4.1.7

Tips and suggestions

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

38

4.2

Browse

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

40

4.2.1

Introduction

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

40

4.2.2

Clustering on the fly

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

42

4.2.3

People are currently thinking about

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

43

4.2.4

Related items

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

44

4.2.5

Subject Cloud/Wall of pictures

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

44

4.2.6

Spatial browsing

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

46

4.2.7

Person browsing

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

48

4.2.8

Index br
owsing

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

48

4.3

Distribution


APIs

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

50

4.3.1

Introduction

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

50

4.3.2

APIs included in the Rhine Release

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

50

4.3.3

Specification for HTTP APIs

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

50

4.4

Facilitation: Europeana Labs

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

52

4.4.1

Introduction

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

52

4.4.2

The Europeana Source Code

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

52

4.4.3

EuropeanaLabs.eu

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

53

4.4.4

Formal requirements for contributing code to EuropeanaLabs.eu

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

53

4.4.5

How to develop at EuropeanaLabs.eu

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

54

4.4.6

Maintenance of the Europeana.eu code
-
base

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

55

4.4.7

Technical requirements for contributing to the Europeana code
-
base

..........

56

4.4.8

Further development of EuropeanaLabs

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

58

4.5

Ingestion

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

58

D3.1

Functional specification of Rhine



3

4.5.1

Inge
stion workflow

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

58

4.5.2

Metadata for digital objects: Europeana Semantics Elements

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

60

4.5.3

Data validation

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

62

4.5.4

Data transfer

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

63

4.
6

Editorial Virtual Exhibitions

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

64

4.6.1

Introduction

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

64

4.6.2

Virtual exhibition functionality
................................
................................
.........

64

5

Europeana Data Model

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

66

6

Future de
velopments
................................
................................
................................
...

67

6.1

Demos on the site

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

67

6.2

Personalisation preferences

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

67

6.3

EuropeanaConnect

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

67

6.4

ASSETS

Search

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

67

6.5

IPR Framework

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

68

6.6

Further browsing opportunities

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

68

6.7

Content
-
based queries on multimedia documents

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

68

6.8

O
ntology queries
................................
................................
................................
...

68

6.9

New facets/better configuration of facets

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

68

6.10

To get help about the semantic net of the descriptor

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

68

6.11

To upload objects from private collections

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

69

7

Appendix 1: Rhine Release Use Cases

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

70

8

Appendix 2: Ingestion Workflow

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

71

INGESTION STEPS

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

75

9

Appendix 3: Rhine Release Requirements

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

80

9.1

Rhine Release Requirements: Search and Results

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

80

9.1.1

Requirement SR1: Refine search

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

80

9.1.2

Requirement SR2: Nested search

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

80

9.1.3

Requirement SR
3: Phrase search

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

80

9.1.4

Requirement SR4: Facets

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

80

9.1.5

Requirement SR5: Precompiled list of available facet searches

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

81

9.1.6

Requirement SR6: Alternative search
terms

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

81

9.1.7

Requirement SR7: Automatic provision of other spellings or proper names

.

81

9.1.8

Requirement SR8: Search tips and suggestions

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

81

9.1.9

Requirement SR9:

Content
-
based query on multimedia documents

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

82

9.1.10

Requirement SR10: Semantic based queries on metadata, expressions of a
logical language including Boolean operators, variables, attributes and associations.

82

9.1.11

Requirement SR
11: Use of social tags in searching

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

82

9.1.12

Requirement SR12: Authority

file use

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

82

9.1.13

Requirement SR13: Ranking of results

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

83

9.1.14

Requirement SR14: Ranking of Results by dominance of larger collections

83

9.1.15

Requirement SR15: Indexing

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

83

9.1.16

Requirement SR16: Personalisation

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

83

9.1.17

Requirement SR17: Sorting of results by specific criteria predefined by the
user

83

9.2

Rhine Release Requirements: Browse
................................
................................
.

84

9.2.1

Requirement B1: Clustering of results

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

84

9.2.2

Requirement B2: People are currently thinking about

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

84

9.2.3

Requirement B3: Timeline

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

84

9.2.4

Requirement B4: Carousel

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

84

9.2.5

Requirement B
5: Related Items

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

85

9.2.6

Requirement B6: Subject Cloud/Wall of pictures/Silverlight*

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

85

9.2.7

Requirement B7: Browse by spatial dimension

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

85

9.2.8

Requirement B8: Sp
atial
-
temporal access


EuropeanaConnect WP3

........

86

9.2.9

Requirement B9: Browse the Europeana database by subject (Who?)

........

86

D3.1

Functional specification of Rhine



4

9.2.10

Requirement B10: Index Browsing

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

86

9.3

Rhine Release Requirements: APIs

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

86

9.3.1

Requirement API1: Deliver APIs to Europeana partners

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

86

9.4

Rhine Release Requirements: Europeana Labs

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

87

9.4.1

Requirement

F1: Facilitation
-

Europeana Labs

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

87

9.5

Rhine Release Requirements: Ingestion

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

87

9.5.1

Requirement CI1: Harvesting process

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

87

9.5.2

Requirement CI2: Europeana Conte
nt Checker

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

87

9.5.3

Requirement CI3: EuropeanaConnect Licensing tool

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

87

9.5.4

Requirement CI4: Europeana
License

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

88

9.5.5

Requirement CI5:
OAI
PMH

Harvesting

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

88

9.6

Rhine Release Requirements: Search
Engine

Optimisation

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

89

9.6.1

Requirement SEO1: To provide search engine optimisation

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

89

9.7

Rhine Release Requirements: Editorial

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

90

9.7.1

Requirement E1: Provide virtual exhibitions

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

90

9.7.2

Requirement E1 Provide Virtual Exhibition API

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

90

9.8

Rhine Release Requirements: Collaborative workspace

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

91

9.8.1

Requirement MyE1 Provide collaborative workspace

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

91

9.8.2

Requirement MyE2 Share with other users

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

91

9.8.3

Requirement MyE3 Implement communities

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

91

9.9

Rhine Release Requirements: End user services

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

92

9.9.1

Requirement EUS1: Mobile access

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

92

9.9.2

Requirement EUS2: eBooks On Demand

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

92

9.9.3

R
equirement EUS3: What’s on?

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

92

9.9.4

Buy the book etc on Amazon, BOL et al

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

92

9.10

Rhine Release Requirements: Personal preferences

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

93

9.10.1

Requirement PP1: Provide

personalisation preferences

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

93

9.11

Rhine Release Requirements: Front End

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

93

9.11.1

Requirement FE1: Interface Modifications

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

93

9.11.2

Requirement FE2: Navigation

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

93

9.11.3

Requirement FE3: About us
................................
................................
.........

93

9.11.4

Requirement FE4: Addition of Add This

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

93

9.12

Rhine Release Requirements: Europeana innovation/ThoughtLab

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

94

9.12.1

Requirement EI1: ThoughtLab

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

94


D3.1

Functional specification of Rhine



5

1

Introduction


This document contains the functional specifications for the first operational
release of Europeana.eu and thus defines the goals Europeana should have
re
ached by the time it goes public in July 2010. The Rhine release aims to give
access to 10 million items of Europe’s cultural and scientific heritage.


The 2011 vision for Europeana is that it will be:




a distributor of: technology (code and services), con
tent and
metadata, and expertise



a facilitator as: an asset store for new aggregators, for repositories
of services, schemas, ontologies, authority files, Europeana
Licensing tool



an innovator: semantic & multilingual search, Europeana Labs



a catalyst: pe
rsistent identifiers, public domain charter.


The Rhine Release of 2010 will start the process of meeting
these
challenges.


1.1

About this document


The functional specifications in this document are based on:




the priorities for the Rhine Release set out in
Priorities for Rhine
.



the requirements set out in D2.5
1

Europeana Outline Functional
Specification

that do not form part of the current prototype, and



the new Requirements for Rhine taken from the User Survey
2

of
May 2009 and the Europeana.eu Feedback Box
.


This document covers:


Background and scope



the current prototype



an outline of the functionality specified in D2.5 that has not been
fulfilled so far



the priorities for the Rhine Release



the technical roadmap; how the Rhine Release will lay the
foundat
ion for the Danube release.


User groups and requirements



a description of the users and systems that will interact with
Europeana, their characteristics and expectations.




1

https://version1.europeana.eu/group/europeana
-
collaboratory/docu
ments?p_p_id=20&p_p_lifecycle=0&p_p_state=maximized&p_p_mode=view
&p_p_col_id=column
-
1&p_p_col_count=1&_20_struts_action=%2Fdocument_library%2Fview&_20_folderId=16767

2

https://version1.europeana.eu/group/europeana
-
collaboratory/documents?p_p_id=20&p_p_life
cycle=0&p_p_state=maximized&p_p_mode=view
&_20_struts_action=%2Fdocument_library%2Fview&_20_folderId=43107

D3.1

Functional specification of Rhine



6


Functional areas



these include new search, results and browse capabilities, externa
l
APIs, Europeana Labs, ingestion, editorial and collaborative
workspace.


The European Data Model



Europeana will incorporate a richer data model, the Europeana
Data Model (EDM for short) in the Danube release to support
advanced functionality, notably ric
h semantic search on its
database.
This section reports the status of the EDM, currently
being developed jointly by WP3 of Europeana version 1.0 and
Europeana:connect, with the contribution of a number of subject
matter experts. The section also points out

to previous versions of
the model.


Future Developments




an outline of the functionalities that will be added to Europeana in
the period following the Rhine Release.


Note
:
Finalisation of this document as a formal deliverable is based on the
assumption
that it will continue to evolve in line with the implementation of
Europeana, a process that will span the whole duration of Europeana v1.0
project..


1.2

The Attachment folder


There are several documents that are related to the present deliverable,
either as

background information or as providing more details.


In order to improve readability of the present document, these documents
have been collected in a dedicated folder on the Project collaborative
platform, located at:


https://version1.europeana.eu/group/europeana
-
collaboratory/documents?p_p_id=20
&p_p_lifecycle=0&p_p_state=maximi
zed&p_p_mode=view&_20_struts_action=%2Fdocument_library%2Fview
&_20_folderId=92152


The folder can be reached from the “Documents” tab of the Europeana
collaborative, (
https://version1.europeana.eu/group/europeana
-
collaboratory/documents
) following the path:


Folders

»
WP3

»
Deliverables

»

D3.1 Functional specifications for
Europeana
Rhine release

»

D3.1

Functional specification of Rhine



7


2

Background and scope



2.1

The current prototype


The prototype of Europeana.eu, launched in November 2008, currently gives
access to nearly 5 million items. The prototype is available in 26 languages and
offers the following user services:




Search



Timeline browsing



Carousel browsing



Search term browsing (People are currently thinking about…)



Some personalisation through My Europeana.


The Europeana prototype is a proof
-
of
-
concept environment designed to
show that it was possible to create a
cross
-
cultural search engine that
would function across archives, audiovisual archives, libraries and
museums. The aim was to:




validate candidate technologies for the v1.0 release:

o

searching

o

aligning semantics in a multidimensional space

o

cross
-
lingual an
d cross
-
cultural information
retrieval



enable hands
-
on experience with ingesting and mapping:

o

metadata formats

o

languages

o

controlled vocabularies etc



enable Europeana to start building a pan
-
European network of content
aggregators and cultural heritage par
tners, and



validate strategies to guarantee the future scalability, maintainability,
agility and extensibility of the Europeana business model.





2.2

D2.5 functionalities not included in the current prototype


The current prototype of Europeana is based on
the functional
specifications produced in the EDLnet project as deliverable
D2.5

Europeana Outline Functional Specification. This section covers the
functions specified in D2.5. that were not included in the prototype. It is
based on the validation analysis performed at the National Library of
Sweden
in autumn 2009.



The D2.5 document lists 26 functional descriptions, grouped under
headings such as Search, Results and Browse. These descriptions were
tested within the prototype to assess whether they were available and how
they functioned.

D3.1

Functional specification of Rhine



8


The D2.5 d
ocument also contains a number of use cases in a variety of
functional areas, which were also tested.


The results of these tests are summarised below in YES/NO/Partly terms
with some comments. For further observations and information, please
see the full
document, Validation of the Europeana prototype against D2.5
and other sources, provided in the folders “Attachments to D3.1”.


Validation results


Functional Area

Description

Avai
-
lable

Comment

Search/Results

Free text search from a single text field for
m

YES


Search/Results

To get help about the semantic net of the
descriptor by eg a topical map feature
including topical based browsing

NO


Search/Results

Execute free text query

YES


Search/Results

Free text search with additional parameters
(eg langua
ge, media type)

NO

Search results can be refined
by facets such as language
and media type.

Search/Results

Precompiled lists for searching in the four
major Europeana facets

NO

Some timeline search
capability

Search/Results

To get a brief view of search
results (text and
thumbnails)

YES


Search/Results

To get a detailed view for a single search
result

YES


Search/Results

To get search tips and suggestions, especially
when there is no result

NO


Search/Results

Filter or sort search results by specific c
riteria
predefined by the user

NO


Search/Results

To get access to full content: read a book

YES

Some problems, eg some
video clips do not play

Search/Results

To get access to similar or related full content

YES

However, some content does
not relate clea
rly to the original
search expression

Search/Results

To display results outside Europeana portal,
eg in a personal blog or a mash up website

NO

Not included due to issues with
data providers over what they
would allow for their metadata

Search/Results

Us
er defines how many results should be
returned

NO


Search/Results

Display Free Text Query

Partly

Partly: clustering within facet
search

Search/Results

Provide a list of queryable attributes [title,
creator, date, subject] in Advanced Search

YES


Search/
Results

Suggest Alternative Query in Advanced
Search

NO


Search/Results

Reevaluate query by facet/Refine query

YES


Search/Results

Find Related Objects


NO

Related objects are displayed
automatically in a panel) but it
is often unclear what
association p
roduced the hit.

Search/Results

View Object with sub
-
cases View Object Info,
View Object Summary, and Play Object

YES


Search/Results

Save Query with sub
-
cases Export Query
Result, Print Object, and Save Query Result
in Europeana.

n/a

Save query works;
Print object
works.


Search/Results

Support the exploration of result sets

YES


Browse

To browse the Europeana database by the
spatial dimension (where)

NO

A facet search by country
exists but is not clearly defined

Browse

To browse the Europeana databa
se by the
time dimension (when)

YES

Timeline search provides some
functionality, as the system
does not distinguish between
time of digitisation, time of
D3.1

Functional specification of Rhine



9

publication and time of event

Browse

To browse the Europeana database
by subject (who or what)


NO

A
search by person name
works sometimes, but the
results can be crude or
misleading, mostly because the
content metadata is imprecise

Browse

To browse through predefined sets of results
on popular subjects

NO


Browse

To browse the Europeana database throug
h a
general index (back
-
of
-
the
-
book index style
and/or subject/object headings.

NO


Browse

To support browsing along three
dimensions: Space, Time and Who
& What

Partly

Partly; the meaning of dates in
the database is not consistent.
Also big issues with t
he quality
and consistency of the
metadata …i.e. not many
providers including geospatial
metadata. This remains true for
Rhine.

Personalisation

To register for a personal Europeana account

YES


Personalisation

To authenticate with Europeana

YES


Persona
lisation

To use and maintain a personal space in
Europeana (MyEuropeana), eg to store
preferred searches, layout or language

YES

It is possible to save searches,
items and tags.

Alerting and
Saved searches

To save search and browse selected results

YES


Alerting and
Saved searches

To retrieve stored searches at a later
occasion

YES


Collaborative
workspace

To start and maintain a community within
Europeana

NO

available as demo

Collaborative
workspace

To join or leave a Europeana community

NO

available a
s demo

Collaborative
workspace

To forward or share saved search and browse
results

YES

via forwarding

Collaborative
workspace

To link to the profiles of other Europeana
users

NO


User oriented
editorial

To tag existing content (social tagging)

Partly

Pa
rtly. Tagging seems to work,
but the tags are not searchable

User oriented
editorial

To upload objects from private collections

NO


Other

External Search Manager (Search gateway)

NO


Other

Community manager

NO


Other

User Content Manager (MyEuropeana)

YES

Shelves such as View are
empty.

Other

Content harvesting via OAI
-
PMH

Partly

It is feasible to harvest
metadata via OAI PMH into
Europeana but many providers
still have not made their
metadata harvestable.

Other

General support to aggregators

NO


Oth
er

System architecture

Partly

Partly: incomplete. User
manager and access manager
most lacking.

Other

Multilingual support

Partly

Interface only. User surface
available in 26 languages.

Other

System monitoring and reports for meta
-
users

NO


Other

Perso
nalisation

NO

some availability in demos




2.3

Priorities for Rhine


The document Priorities for Rhine introduced a number of priorities, mainly
focusing on search and the display of results. These are listed as
requirements in Appendix 3.

D3.1

Functional specification of Rhine



10



2.4

The technical ro
admap


From a technical point of view, Rhine will lay the foundation for Danube.
For this reason, this release will have as its focus the robustness and
stability of the system.



D3.1

Functional specification of Rhine



11

3

Europeana end users

3.1.1

Group characteristics


EDLnet Workpackage 3 has identi
fied five user profiles for end users of
the Europeana service. These profiles are not meant to lead to the
implementation of specific actors in Europeana API. They are considered
insofar each of them brings a specific set of requirements that Europeana
mu
st respond to.


The user profiles are the same regardless of whether the users access the
service through the Europeana website or a third party portal.


These profiles are:


1.

General user

2.

Schoolchild

3.

Academic user (both students and teachers)

4.

Expert re
searcher

5.

Professional user (eg librarian, archivist).


These user profiles can be characterised as follows:


1. The general user


The general user has a generic interest in culture or history. He is familiar
with basic search functionalities, has no spe
cific domain knowledge, is
‘google
-
minded’ and visits sites such as YouTube
3

and Wikipedia
4

that
have large volumes of content to offer.


2. The schoolchild


The schoolchild will make use of the service as part of their schoolwork.
Given that culture and
heritage are incorporated in many school curricula,
Europeana could be used in a variety of educational contexts. The school
child will expect the service to be easily accessible, immediately
appealing, visually attractive or even playful, free of jargon a
nd easy to
use while doing their schoolwork.


3. The academic user


The academic user represents the other end of the educational spectrum.
He may have excellent domain knowledge, or aspires to achieve that. He
will expect the information offered to be com
prehensive, accurate,
representative if not complete, and easy to reuse in the context of
educational assignments.





3

YouTube http://www.youtube.com/


4

Wikipedia: http://www.wikipedia.org/

D3.1

Functional specification of Rhine



12

4. The expert researcher


The expert researcher looks for specific information on a specific topic. He
is to a certain degree skilled in us
ing retrieval services and may make use
of the advanced search button to get the most out of the system. As this
group is most likely to publish the results of the research, it will include
users who are prepared to buy something or travel to visit the con
tributing
institutions.


5. The professional user


The professional user is most likely to be a staff member of a cultural
heritage organisation. He is skilled in using information systems, but has a
different perspective from the expert researcher. He ma
y be interested in
details as well as very generic information, for instance with a view to
improving the information services offered by his own institution.


3.1.2

Group motivation


If we look at the motives of these user groups for using Europeana, it is
pos
sible to identify four initial types of objectives or user scenarios
5
:


1.

The user wants to be entertained.


This group includes users who have time available to browse around
the Internet and have a structural or incidental interest in cultural
heritage. T
hey come to Europeana because they expect to find a lot of
interesting content. For these users it is not important what they find is
as long as it is interesting and entertaining.


2.

The user wants to know more about a cultural or historic
subject or perso
n


This group includes users that have a specific reason for their interest.
This might be a project for school, study or work on a certain subject,
or the fact that they have been made aware of a certain subject
through current news or in a conversation w
ith colleagues, friends or
family. These users are looking for the most relevant results and would
not want to see lots of results that are not relevant to them. To be able



5

(This section is based on information derived from the following
document
s:

Report on the WP1 meeting of 17
-
18 December 2007;

Draft deliverable D3.1 User Use Cases: Functional requirements for EDL
Maquette, dated 6 February 2008;

The DRIVER Functional Specification, dated 15 September 2006; “Klik
naar het verleden” (see: htt
p://www.scp.nl/publicaties/boeken/
9037702791/Klik_naar_het_verleden.pdf)



D3.1

Functional specification of Rhine



13

to determine what is relevant to them, information about the specific
objective of
the user is necessary.


3.

The user wants to know the current location of cultural
heritage


This group includes users that are planning to see the original objects
for research purposes, or users that are about to undertake a trip and
would like to know wha
t cultural heritage they can visit during a tourist
trip or other type of stay. These persons will also be interested in
getting more information on interesting events and collections in the
area, as well as local services such as guided tours.


4.

The user
wants to be part of a community of interest


This group includes users such as students, researchers or members
of a cultural society who want to share their knowledge via an online
environment such as a social platform with a cultural focus. They may
want

to present their opinions and ratings of cultural heritage
resources to their kin as well as share personal items such as
photographs and documents.


With the everyday growth of sites offering services for content sharing
and social networking,
it was de
cided that it was better for Europeana
to facilitate the ability to share content in these sites rather than using
the Europeana resources to re
-
implement these services.


3.1.3

Group expectations


As a large
-
scale international information service on culture,
history and
heritage, Europeana will deal with a wide variety of user expectations,
from one click amusement to in
-
depth research facilities.


One thing all end
-
users have in common is that they are looking for
cultural materials. How they use the Europea
na system to achieve this
depends on their user profile and objectives, as detailed above.


End
-
users also expect to interact with the content in ways such as:




view and download film footage



copy and paste information for a paper they are writing



create

sets of preferred items in the Europeana collection



study details of high
-
resolution reproductions of cultural objects



use social tagging to enrich the description of materials on the site,
and



share interests and comments about the cultural heritage item
s
within communities.


In order to meet these expectations, Europeana should offer the following
D3.1

Functional specification of Rhine



14

functions:


Search for results




free text search from a single text field form



help about the semantic net of the chosen descriptor

Example
: a topical map f
eature including topical based browsing



free text search with a variety of additional search parameters

Examples
: language, media type



precompiled lists for searching in the four major Europeana facets.


Display search results




a simple view of their sea
rch results (short description and
thumbnails)



a detailed view for a single search result



help in the form of search tips and suggestions, especially where
their search has returned no results ('did you mean....')



filtering of search results by specific

criteria predefined by the user



access to the full content of the result

Examples
: read the book, play the video, listen to the audio
recording



access to similar or related full content



display of Europeana results outside the context of the Europeana
po
rtal

Example

in a personal blog or mashup website.


Browse




browse the Europeana database by the spatial dimension (where)



browse the Europeana database by the time dimension (when)



browse the Europeana database by subject, ie “who” or “what”



browse th
rough predefined sets of results on popular subjects



browse the Europeana database through a general index (back
-
of
-
the
-
book index style and/or subject/object headings)


Personalisation




register for a
personal

Europeana account



authenticate the account

with Europeana



use and maintain a personal space in Europeana (MyEuropeana)

Examples:

to store preferred searches, layout or language.


Alerts and saved searches




save searches and browse selected results



retrieve stored searches at a later occasion.


Collaborative workspace

D3.1

Functional specification of Rhine



15




start and maintain a community within Europeana



join or leave a Europeana community



forward or share saved search and browse results.


User
-
oriented editorial




tag existing content (social tagging)



upload objects from the us
er’s private collections.



3.2

External applications/APIs


3.2.1

Group Characteristics


This “user group” consists of software programs that may be part of other
types of system or portal that provide aggregated access. An API, for
example, exists solely to enable

a third party system to view Europeana
and use features within it such as search.


Basically, the objective of these applications will be to integrate
Europeana metadata and/or functionality with other resources.


These applications use machine
-
to
-
machin
e communication that will need,
as a minimum, access to the Europeana authentication and advanced
search functions. The level of access will depend on the sophistication of
the application.


These external applications will be responsible for accessing pr
imary
resources at content providers. They may or may not return
data

to
Europeana such as metadata enrichment or specialised geolocating
services.



3.2.2

Group Expectations


The expectations of this group are likely to be:




to obtain HTTP
6

access to the Euro
peana database and services
through a set of specifications described in the APIs



to request Europeana data according to criteria such as date and
format.



to receive status information from Europeana in addition to/instead
of result sets.





6

HTTP


Hypertext Transfer Protocol: http://www.w3.org/Protocols/


D3.1

Functional specification of Rhine



16



3.3

Content aggreg
ators/Content providers


This user group comprises:


1.

content providers
: organisations which provide metadata directly
to the central Europeana system, and

2.

content aggregators
: organisations that act as collection points
for providers that cannot contribut
e metadata directly to
Europeana. The objective of these users is to contribute metadata
as a proxy to the central Europeana system.


3.3.1

Group Expectations

3.3.1.1

Content providers

A number of content providers interact with Europeana via their content
aggregator
s. Their aim will be to achieve a level of visibility for their
content, while complying with Europeana requirements and any usage
restrictions. They will therefore need to submit the metadata associated to
their content in a controlled and automatic way.


Europeana has defined the OAI
-
PMH
protocol
7

as its standard format for
data collection, and content aggregators will be required to use it to collect
data from providers.

Other technologies, such as P2P, will be acceptable
as additional delivery methods
as long as OAI
-
PMH is supported as the
elementary protocol.


Metadata


the data that describe the basic content items


are
considered as aggregated web resources. Metadata will be modelled
using Resource Maps as defined by OAI
-
ORE
8
.


Some content provid
ers will wish to display their own branding identity
when their content is accessed from within the Europeana portal. This will
happen by default, since users will access the provider’s content from
within its own repository. In addition, as the provider’s

portal will also use
the provider’s own software applications, its brand identity will be evident
to the user.

3.3.1.2

Content aggregators

In this context, content aggregators are the interface between the content
providers and Europeana. Their role is to:





7

OAI
-
PMH


Open Archives Initiative Protocol for Metadata Harvesting:
http://www.openarchives.org/OAI/openarc
hivesprotocol.html


8

OAI
-
ORE Open Archives Initiative Object Reuse and Exchange:
http://www.openarchives.org/ore/1.0/toc.html


D3.1

Functional specification of Rhine



17



coll
ect information about providers and their delivery systems



collect metadata about content



de
-
duplicate, disambiguate, clean and enrich the provided
metadata with meaningful attributes



possibly associate metadata in collections



verify the accessibility of

content



make metadata ready for Europeana ingestion using the OAI
-
PMH
protocol.


Content aggregator requirements are centred on metadata quality.
Services that enhance metadata quality may therefore be of crucial
importance.


3.3.1.3

Europeana expectations

Eur
opeana expects its own brand identity to be displayed when a user
accesses content from within the Europeana portal.


This could be achieved in several ways, including:




framing the object with a Europeana frame, or



pasting the Europeana logo onto the ob
ject.


3.3.1.4

Repository

management and data collection

Europeana will support a number of repository management and data
collection functionalities, as detailed below:.


Data Provision


Europeana will provide content providers and aggregators with the
follo
wing functionalities, to be used when collecting data from other
providers or forwarding data to Europeana:


1)

Registration
: a simple common metadata registration
function, used by the provider to map all necessary
information on the characteristics of the r
epository and the
metadata (format, sets and subjects, etc.) from their
database. The final approval and actual registration
process should be a part of the Europeana system.


2)

Scheduled har
v
estin
g: there will be a means of defining
an automated process fo
r conducting the data collection at
regular intervals.


3)

Incremental harvesting
: Where the repository wishes to
make changes to its metadata, Europeana should collect
only the changes, not the entire repository database. This
is in order to minimise traffic

and enhance performance.



D3.1

Functional specification of Rhine



18

4)

Refresh harvesting
: Repositories will sometimes need to
re
-
upload an entire database. Europeana will support this
function, ensuring that the process is swift and efficient and
will not interrupt collection from other repositori
es.


5)

Automatic error handling and reports
: where necessary,
content providers must be notified with detailed error
reports. They will also have the ability to check the status of
data transfers, either to Europeana or to intermediate
aggregators.




Securi
ty

1)

Access to data repositories should be restricted to
authorised content providers.


2)

Access to content may be restricted in some cases, even
where the content is theoretically available to view.
Metadata collected and forwarded to Europeana should
includ
e information such as the provider’s contact details or
a link to a content access procedure owned by the provider.
This will enable the user to contact the content provider.



Usage


Content providers will require a level of control over the use made of

their
content, in addition to usage statistics. The system must therefore support
the following functionalities:


1)

The ability to enforce usage restrictions such as whether
content may be copied or simply viewed by the user.


2)

Harvesting of reports and sta
tistics to provide system
-
wide
quantitative and comparative data.


3)

Metadata usage reports and statistics to enable providers
to monitor the usage of their own contributed metadata.


4)

User profiling: this may provide an indirect mechanism for
maintaining sta
tistical information. Profiling may also be
structured so as to offer qualitative information.



Support



Data publishers will be provided with the following support tools:


1)

Clear, documented requirements and guidelines for the
delivery of compliant metad
ata.


D3.1

Functional specification of Rhine



19

2)

Tools to prepare and test the compatibility of their metadata
and the reliability of their delivery system.



3.4

Service providers


3.4.1

Group characteristics

This “user group” consists of systems that provide services to Europeana
such as enriched or ass
ociated content to be linked to Europeana
resources.


3.4.2

Group objectives

The objective of this group is to enable users to find and access resources
that are not described and indexed in the Europeana system.


The most important features for this user grou
p are:




the Search Gateway, which translates queries into external
searches, and



the Results Manager, which integrates results from external
sources with those from within Europeana.


3.4.3

Group Expectations

Service providers expect Europeana to provide them

with the information
required to carry a specific task such as data crawling, searching or
harvesting. These should be provided as APIs and toolkits available
online.



3.5

Meta users and administrators

3.5.1

Group characteristics

This user group comprises peopl
e needing access to the Europeana
database and usage statistics in order to monitor its performance and
visibility. These users need access to the system administration functions
of Europeana.


3.5.2

Group expectations

The primary requirement for this user gro
up is to assess the Europeana
system for:




performance: accessibility, reliability



traffic for the different user groups and profiles



data: volume of Europeana objects/original objects/…, number of
content providers/aggregators, traceability of data ing
estion and
D3.1

Functional specification of Rhine



20

distribution



partners: number, domain, country,…



usage of Europeana.


To achieve this, they will need:





configurable monitoring frequency and parameters



statistical reports for the data monitored, exportable in various

formats for re
-
use and

dissemination



detailed reports



access to raw logged data for the purpose of tailored analysis.
These raw data can be accessed by software applications to take
into account configuration settings such as optimisation of queries


Note
: Policy makers are a s
ub
-
group of administrators. Their principal
interest is in evaluation reports showing clear statistical evidence of the
metadata available and its sources (see Policy makers, below).


D3.1

Functional specification of Rhine



21


4

Functional areas


This section contains the specifications for the ind
ividual functional areas
within the Rhine Release.



4.1

Search and results


4.1.1

Introduction



This
section describes the Europeana
database and the search
functionalities to be included in the Rhine Release.


It contains the following topics:




The Europeana
dat
a
base




Simple search



Advanced search



Auxiliary search functions:

o

Word autocompletion

o

Synonyms

o

Query expression specification for advanced search


4.1.2

The Europeana database


The Rhine release of Europeana aims to give access to 10 million items of
Europe’s cul
tural and scientific heritage. The items themselves will be stored in
digital format at the sites of the content providers. The Europeana database will
contain information enabling users to search for and view those items. This
information will be supplied

by the content providers.


The Europeana database consists primarily of:




metadata: information describing the content objects. Examples:
name of artist, date of film release, location of sculpture



views of the content objects, such as thumbnail images



s
emantic resources capturing lexical and domain knowledge in the
cultural sector, such as thesauri, taxonomies, subject heading
systems and ontologies.


The collation process is handled by the ingestion layer. Broadly, the process
works as follows:




The con
tent providers ensure their data complies to Europeana
requirements



The content providers upload the compliant data to Europeana



Europeana collects, normalizes and enriches the data

D3.1

Functional specification of Rhine



22



Europeana integrates the data into the Europeana system.


4.1.2.1

Integration of
data into the Europeana database


This is a three
-
stage process undertaken jointly by Europeana, the content
providers and the content aggregators. The process is as follows:




Europeana v1.0 and Europeana:connect will jointly develop a data
model, the Euro
peana Data Model (EDM). The EDM will provide
high level classes and properties to match the requirements set by
Europeana management, which take into account business
requirements and user expectations.



The content providers will relate the domain
-
specifi
c classes and
properties of their own data models to those of the EDM. In some
cases, the relation will be realized declaratively by specialization
links, by asserting that certain classes or properties of content
providers are, respectively, sub
-
classes o
r sub
-
properties of some
EDM elements. In more complex cases, the relation will be realized
procedurally by a transformation of the original metadata into
instances of EDM, carried out through a possibly complex
transformation algorithm.



The compliant met
adata and mappings collected from the content
providers will be uploaded to Europeana.



Important
: The metadata model used for the Rhine release will be built
using the Europeana Semantic Element (ESE) metadata set. The more
complex European Data Model, i
ntroducing more classes and properties,
will be developed in time for the Danube release, but may require a longer
introduction process to allow for data migration, so may be implemented
and used by providers post Danube.


4.1.2.2

The query mechanism


The query m
echanism of a software system controls how people, software
applications and internal system components identify and extract
information.


A query mechanism consists of three main parts:


1.

Query language


Definition
: this comprises syntax, semantics and pra
gmatics
defining:




the expressions that users can use to extract information from
Europeana



the meanings of these expressions and

D3.1

Functional specification of Rhine



23



their
usage

in accomplishing the tasks defined in the
requirements.


2.

Context definition


Definition
: this specifies the elemen
ts used to extract answers to
queries. These include:




information about the user, such as languages spoken,
preferences, history and communities of interest



a characterisation of the objects being searched, such as
degree of authoritativeness, composition

relations and
equivalence criteria


3.

Query evaluation engine


Definition
: this is a piece of software that
computes the result of
queries according

to the semantics of the query language and the
context.


4.1.2.3

The query mechanism API


The Europeana query mecha
nism will be accessible via a programmatic
interface (API) which the system will use to manage and evaluate queries
and to perform related tasks such as managing query results.


This API will be used by applications serving three different types of user:




end users

who want to search for objects
relevant to their
information needs or to browse the Europeana information space.
These users typically sit behind a graphical user interface such as
the Europeana portal. This interface acts as a mediator between
the end user and Europeana.




external applications that aim to extract the information needed for
a specific application

task or for integration with other information.
Examples
: web search engine crawlers, applications serving meta
users who need access
to logs and statistical information so they
can analyse system performance.




internal components of Europeana that need information in order to
implement a Europeana service.
Examples
:
creation of output
pages, system administration, supporting a particul
ar browse
function.


4.1.2.4

Search APIs


Europeana will offer the following Search APIs:

D3.1

Functional specification of Rhine



24





Simple search



Advanced search



Auxiliary search functions:

o

Word autocompletion

o

Synonyms

o

Query expression specification for advanced search


These functions are considered se
parately below.


4.1.3

Simple search


This section sets out how Europeana will handle the Simple Search
function.


4.1.3.1

Description


From a user point of view, a simple search query is a full
-
text query, like a
typical query on a web search engine. It returns a set

of item descriptors
sorted/ranked by predefined criteria, and can be repeated to refine the

result of a previous query.


4.1.3.2

Syntax


A simple search query consists of three parts:




query expression



query context



result specification.


4.1.3.3

Query expression


This i
s a sequence of words from any of the supported languages,
including social tags. Information retrieval operators, such as boosting,
phrases and windows, may be allowed in a query expression if supported
by the chosen query evaluation engine.

Note
: The qu
ery expression will be specified in detail after the query
evaluation engine has been selected..


4.1.3.4

Query context


This is a set of features that specifies additional conditions to be
considered when computing the final sorting/ranking of the search results.

These features are:


D3.1

Functional specification of Rhine



25



phrase
: when the user has entered a query without isolating any of
the terms as a phrase (eg with quote marks), this binary feature
indicates whether the search engine should consider whether any
sequence of words in the query constit
utes a phrase



size
: this feature indicates whether items coming from larger
collections should be ranked in a special way; this can be
implemented as a set S of triples (p, k, a), where

o

p is the
polarity
, and can be 1 or
-
1

o


k is the
threshold
, and is any
non
-
negative integer

o

a is the
factor
, and is any number in the [0,1] interval.

If the set S is empty, then this feature plays no role. If the set S is
non
-
empty, then The usage of these numbers is as follows:

1.

if p=
-
1, then the score of the items coming fro
m a collection
with size smaller than k must be multiplied by a

2.

if p=1. then the score of the items coming from a collection
with size larger than k must be multiplied by a

As such, the size feature can be used to magnify or shrink the
importance of large
or small collections



region
: this feature is a possibly empty set R of pairs (l, a(l)), where
l is a distinct language and a(l) is an associated factor. If the set R
is empty, this feature plays no role. If the set R is non
-
empty, then
the score of the obj
ects in language l must be multiplied by the
factor a(l), for each language l in the set R



collection
: this feature is a possibly empty set C of pairs (c, a(c)),
where c is a distinct collection and a(c) is an associated factor. If
the set C is empty, this

feature plays no role. If the set C is non
-
empty, then the score of the objects coming from collection c must
be multiplied by the factor a(c), for each collection c in the set C



view
: this feature is a possibly empty set V of pairs (t, a(t)), where t
is
a distinct type of content (thumbnail, snapshot, abstract, etc.)
that an object may have, and a(t) is an associated factor. If the set
V is empty, this feature plays no role. If the set V is non
-
empty,
then the score of the objects endowed with content of
type t must
be multiplied by the factor a(t), for each content type t in the set V.


4.1.3.5

Result specification


This is a set of variables that specifies:





which part of the query result should be displayed to the user, and




how the results should be displayed
.


These variables are:




what is the relative position in the final sorting/ranking of the first
item to be returned



how many items of the final ranking should be returned



by which criteria the displayed items should be sorted



by
which criteria the displ
ayed items should be clustered

D3.1

Functional specification of Rhine



26



whether related items should be returned.


4.1.3.6

Semantics


A simple search query retrieves all objects whose properties contain any
of the words in the query. These objects are sorted/ranked first according
to the query expressio
n, and then may be ranked again according to the
query context.


Ranking based on the query expression should take into account the
following factors:




how many of the query words are matched by an object (the more
the higher);



to what extent any word is
matched, exact match giving the highest
score



how relevant the matching properties are.
Example:
the author
property may be considered more relevant than the title property.


Re
-
sorting/re
-
ranking based on the query context should take these
factors into a
ccount in the order specified. Finally, the result should be
returned according to the indications given in the result specification part
of the query.


Additionally, a set of ranked “related items” can be returned upon request
from the query.


4.1.3.7

Prag
m
atics


The simple search query is the most suitable for the casual user, since no
knowledge of the ESE is required.


Also, because a simple search is non
-
specific, it is particularly useful for
any user whose information need is not expressible in the classica
l ‘who,
what, when, where’ paradigm. (
Example
: “Symbolist music and Montale”.)
As such, simple search can be a powerful tool for genuine discovery.


4.1.3.8

A note on implementation


The specification above implicitly assumes a synchronous interaction
between a cl
ient (caller) and a server implementing the simple search.
This is just a convention; the specification above can be implemented in
an asynchronous fashion provided the syntax and the semantics of the
specification are respected.


D3.1

Functional specification of Rhine



27

4.1.3.9

Example simple search


T
he following use case is given to demonstrate how a simple search
works.

Note
: in this case, the user is executing the search on the website of a
cultural institute. However, the search works in the same way if the user is
searching directly on the Europe
ana portal.


Use
-
Case: API to Simple search

4.1.3.10

Brief description

A cultural institute wants to incorporate Europeana simple search into its portal,
site or mashup. This institute’s customer needs a search functionality that returns
a response with links to th
e institute’s own website.


Note
: all references to search box or website refer to the website of the cultural
institute.


4.1.3.11

Actor Brief Descriptions





User



Cultural Institute Search



Europeana Index



Europeana Simple Search




Rights to material must allow ac
cess and/or reuse.


4.1.3.12

Preconditions




Europeana Branded Simple Search API embedded in local search



Europeana Index



Branding of Europeana results.


4.1.3.13

Basic flow of events


1)

The user enters keywords (eg Mozart) in the search box.


2)

Europeana

returns a set of resul
ts matching the keyword


3)

The results are displayed according to the ranking
mechanism specified by the receiving site.


Note
: if no ranking mechanism is specified, the results are ranked
according to

the Europeana API

default
.


4)

The user clicks on one of t
he Europeana branded results
and sees a picture of Mozart’s father.


5)

The user clicks on this result to see a full display, then opts
D3.1

Functional specification of Rhine



28

to see the object in its original context.


6)

Europeana simple search API returns a link to the object in
its original contex
t.

4.1.3.14

Alternative Flow 1


1)

The user enters keywords (eg Mozart) in the search box.


2)

Europeana returns a set of results matching the keyword


3)

The results are displayed according to the ranking
mechanism specified by the receiving site.


4)

The user clicks on one o
f the Europeana branded results
and sees a picture of Mozart’s father.


5)

The user chooses to save the picture locally.


4.1.3.15

Alternative Flow 2


1)

The user enters keywords (eg Mozart) in the search box.


2)

Europeana returns a set of results matching the keyword


3)

The

results are displayed according to the ranking
mechanism specified by the receiving site.


4)

The user clicks on one of the Europeana branded results
and sees a picture of Mozart’s father.


5)

The user wishes to see more of the same sort of items and
gets a new

set of results of paintings and images relating to
Mozart.


6)

The simple search API returns a response with related and
relevant items
Examples:
children, pictures, birth and
death certificates, books



4.1.3.16

Post
-
conditions


The user returns to the search box.




4.1.4

Advanced search


D3.1

Functional specification of Rhine



29

This section sets out how Europeana will handle the Advanced Search
function.


4.1.4.1

Description


An advanced search query is a formal query describing the desired results
in a logical form, very much like a database query.


The form is a Bo
olean combination of simple clauses. This addresses
classes and properties of objects and their metadata within the EDM.


From the user point of view, an advanced search is similar to a simple
search, except that the query expression is tyically entered in

boxes
associated to attributes (such as author or title), and there is usually the
pssibility of further specifying:




an operator associated to the selected box (i.e. if the selected box
requires a date, the user may specify whether the results must be
B
EFORE or AFTER that date)



whether all the conditions stated are to be satisfied simultaneously
by the results or just anyone of them is to be satisfied.


Advanced search returns a set of results sorted/ranked by predefined
criteria, and can be repeated to
refine the

result of a previous query.


Note
: As the EDM for the Rhine release is ESE, the clauses of an
advanced search are restricted to the ESE metadata elements. The
Danube release will be based on a more complex version of the EDM,
allowing for deeper

advanced search.


4.1.4.2

Syntax


The syntax of an advanced search is the same as that of a simple search
except for the query expression. In its most general form, an advanced
query expression is a Boolean formula in Disjunctive Normal Form; that is,
it consists

of a set of conjuncts in OR:


C
1

OR

C
2

OR


OR

C
n

(
n

greater than or equal to 1).


Each conjunct C
i

is a set of atoms in AND:


C
i
1

AND

C
i
2
AND

… C
i
m
i

(
m
i
greater than or equal to 1).


Each atom is an expression of the form:


property operator value


D3.1

Functional specification of Rhine



30

(for
instance ens:isAbout = theater). Social tags can be specified as value
in an atom.


This syntax may be too general for the underlying query evaluation engine,
in which case a simplified form can be defined.


Note
: The query context and the result specifica
tion of an advanced
search are the same as those of a simple search. For details, see Section
X, Simple Search.


4.1.4.3

Semantics


An advanced search query retrieves all objects satisfying the query
expression in the classical logical sense. In particular:




an at
om
property operator value
retrieves all objects whose
property

value satisfies the condition expressed
operator value
(in
the above example, all objects that have ens:isAbout equal to
theater)



a conjunct retrieves the intersection of the sets of objects r
etrieved
by its atoms



a query retrieves the union of the sets of objects retrieved by its
conjuncts.


An initial sorting/ranking of the retrieved objects may be obtained by
following a best match approach for atoms. The subsequent re
-
ranking
based on the q
uery context is the same as that used for the simple search.
Finally, the result should be returned according to the indications given in
the result specification part of the query.


Additionally, a set of ranked “related items” could be returned upon
requ
est from the query.


4.1.4.4

Pragmatics


Advanced search queries are for those users that have a precise (although
possibly incomplete) mental description of the items they are looking for,
or at least of the way they are represented in the EDM.


The specificati
on of an advanced search requires at least some knowledge
of the EDM, even though a friendly GUI can relieve much of the burden of
query specification. While a simple search tends to favour recall, typically
at the expense of precision, an advanced search
does the opposite. As
such it is a viable tool for users that are more familiar with Europeana or
have a precise idea of what they are looking for.


D3.1

Functional specification of Rhine



31

Searching within a facet is a specific type of advanced search in that it
addresses a specific property of
objects. The specification of this type of
search can be facilitated through pre
-
defined queries.


4.1.4.5

A note on implementation


The considerations on asynchronous implementation of simple search also apply
to advanced search.


4.1.4.6

Example name search


The follow
ing use case is given to demonstrate how a name search works.

Note
: in this case, the user is executing the search on the website of a
cultural institute. However, the search works in the same way if the user is
searching directly on the Europeana portal.


Use
-
Case: API to name search


4.1.4.6.1

Brief description

A cultural institute wants to incorporate Europeana Name Search into its portal,
site or mashup. This institute’s customer requires a search for objects on the
basis of the name of a related person or organ
isation. The API returns a response
with results from within the cultural institute’s own website.



Note
: all references to

search box

or website refer to the website of the cultural
institute.

4.1.4.6.2

Actor brief descriptions




User



Cultural Institute Search



Euro
peana Index



Europeana Name Search

4.1.4.6.3

Preconditions




Europeana Name Search API embedded in local search



Europeana Index



Authority files including name authority files



Branding of Europeana results



Rights to material must allow access and/or reuse.


4.1.4.6.4

Basic Flo
w of Events


1)

The user enters a name (eg Brechnev) in the object search
box.


D3.1

Functional specification of Rhine



32

2)

The user ticks the checkbox “search for objects related to
this person”.


3)

The system returns a set of results that include the name
Brechnev and any spelling variations, such as B
rezhnev. It
also lists the name variations used in the search and
provides a list of matching people and organisations. The
results are sorted according to the Europeana default
method.
Note
: the function returning spelling variations is
specified further.


4)

The user clicks on one of the Europeana branded results
and sees thumbnails of objects that matched the search
term ‘Brechnev’ or its name variations.


5)

The user clicks on one of the results to see a full display,
then opts to see the object in its origin
al context.


6)

The system returns a link to the landing page of the object,
in its original context.


4.1.4.6.5

Alternative flow 1


1)

The user enters a name (eg Brechnev) in the object search
box.


2)

The user ticks the checkbox “search for objects related to