D13.1 ARIADNE Service Design

Authors:
HellacHollander, KNAW-‐DANS
Maarten Hoogerwerf, KNAW-‐DANS
Ariadne is funded by the European Commission’s
7th Framework Programme.
D13.1: Service Design

ARIADNE
D.13.1
(Public)

Version:
5.0
(final)
19th

December
2014

Authors:
Hella
Hollander

Maarten
Hoogerwerf

KNAW-‐DANS

Contributing
partners:
Franco
Niccolucci,
PIN

Julian
Richards,
ADS

Holly
Wright,
ADS

Roberto
Scopigno,
CNR

Massimiliano
Corsini,
CNR

Frederico
Ponchio,
CNR

Matteo
Dellepiane,
CNR

Carlo
Meghini,
CNR

Dimitris
Gavrillis,
ATHENA

Guntram
Geser,
SRFG

ARIADNE is a project funded by the European Commission under the Community’s
Seventh Framework Programme, contract no. FP7-INFRASTRUCTURES-2012-1-313193.
The views and opinions expressed in this presentation are the sole responsibility of the
authors and do not necessarily reflect the views of the European Commission.

ARIADNE
D.13.1
(Public)

3

1 Table
of
contents

1
Table
of
contents
.........................................................................................................
3

2
Document
history
........................................................................................................
4

3
Introduction
.................................................................................................................
5

4
Related
Work
...............................................................................................................
6

4.1
First
report
on
user’s
needs
(D2.1)
.........................................................................
6

4.2
Use
requirements
(D12.1)
....................................................................................
11

5
Common
Vision
..........................................................................................................
14

6
The
Actors
and
their
stories
.......................................................................................
16

6.1
Introducing
Laura
.................................................................................................
16

6.2
Introducing
Valentino
..........................................................................................
17

6.3
Introducing
Christopher
.......................................................................................
19

7
Use
cases
...................................................................................................................
20

7.1
Search
and
explore
the
registry
............................................................................
21

7.2
Preview
data
........................................................................................................
30

7.3
Access
data
..........................................................................................................
32

7.4
Deposit
data
........................................................................................................
33

7.5
Search
and
access
the
services
registry
.................................................................
34

7.6
Prepare
and
register
a
new
collection
..................................................................
39

7.7
Enriching
Visual
Media
Documents
......................................................................
40

7.8
Manage
accounts
.................................................................................................
45

8
Service
design
model
.................................................................................................
46

9
Synthesis
....................................................................................................................
49

10
References
...............................................................................................................
50

ARIADNE
D.13.1
(Public)

4

2 Document
history

Date
Activity
Contributors

18
December
2014
Edit
after
contributions
from
Hella

and
Holly

Hella
Hollander,
Holly
Wright,

Matteo
Dellepiane,
Roberto

Scopigno

29
November
Final
Editing
Hella
Hollander,
Julian
Richards,

Matteo
Dellepiane,
Roberto

Scopigno

20-‐28
November
Editing
Matteo
Dellepiane,
Carlo

Meghini,
Roberto
Scopigno

10-‐20
November
Editing,
integrating
and
revising
Matteo
Dellepiane,
Carlo

Meghini,
Roberto
Scopigno

10
September
–
13
October

Editing
and
revising
Matteo
Dellepiane,
Carlo

Meghini,
Roberto
Scopigno

24
July
Overall
architectural
design
Dimitris
Gavrillis

7-‐17
July
users’
needs
linked
with
use
cases
Hella
Hollander

23
June-‐7
July
Worked
on
suggestions
and

comments
from
Workshop
in
Rome

Maarten
Hoogerwerf

23
June

users’
needs

Holly
Wright

10-‐13
June
Editing,
including
D.2.1
framework
Hella
Hollander

9
June
Revised
Chapter
8
Roberto
Scopigno

-‐-‐March
Extending
use
cases
Hella
Hollander,

Maarten
Hoogerwerf,

19
march
2014
Material
on
visual
data
added
in

the
doc;
a
new
Chapter
(7)
is

introduced

Roberto
Scopigno,

Matteo
Dellepiane

5
March
2014
Definition
of
use
cases
Hella
Hollander,

Laurents
Seskink

February
2014
Scenario
of
an
archaeologist
Hella
Hollander

January
2014
Structure
of
use
cases
Maarten
Hoogerwerf

December
2013
Draft
structure
of
sd.
Hella
Hollander,

Laurents
Sesink

8
November
2013
Workshop
ARIADNE
(Pisa),
Define

scope
of
service
design
document.

Workshop
members

ARIADNE
D.13.1
(Public)

5

3 Introduction

This
document
aims
to
specify
the
service
design
of
the
ARIADNE
Portal,
and
provide
a

common
vision,
a
user
perspective
on
the
functionality,
and
a
framework
to
identify,
discuss

and
validate
the
requirements
for
the
underlying
technical
services.
As
such,
the
audience
of

this
document
will
be
both
technical
and
non-‐technical.

The
context
of
task
13.1
Service
Design
can
be
visualised
as
follows:

Figure
1:
ARIADNE
tasks
and
Service
Design

This
service
design
was
created
using
the
following
input:
Description
of
Work,
Task
2.1

(Survey
of
users’
needs
and
community
building),
Task
12.1
(Assessment
of
use

requirements),
an
examination
of
existing
portals
and
WP3-‐12-‐13
Workshop
discussions.

The
service
design
will
provide
input
for
Task
13.2
(Build
Services)
and
Task
13.4

(Acceptance
testing).

The
service
design
will
provide
a
common
vision
formulated
in
terms
of
principles,
derived

from
the
mission
statement
in
the
Description
of
Work.
This
will
be
described
in
Chapter
4.

The
functionality
will
be
derived
from
a
user
perspective.
The
users
and
their
concerns
will

ARIADNE
D.13.1
(Public)

6

be
introduced
and
described
in
Chapter
5.
Chapter
6
will
detail
the
activities
of
these
users

in
relation
to
the
ARIADNE
portal
and
describe
their
technical
impact.
A
detailed
description

of
the
components
the
project
necessary
for
the
design
and
implementation
of
visual
media

is
given
in
Chapter
7.
Chapter
8
gives
an
overview
of
the
technical
architecture
with
some

brief
explanation.
Chapter
9
discusses
the
data
model
of
ARIADNE
that
should
support
the

described
use
cases.

4 Related
Work

4.1 First
report
on
user’s
needs
(D2.1)

The
stakeholder
survey
described
in
D2.1
allows
the
detailing
and
prioritization
of
the

functionality
of
the
service
design
in
D13.1.
The
wishes
expressed
can
be
clustered
together

in
five
main
categories
of
user
needs:
data
transparency,
data
accessibility,
metadata

quality,
data
quality,
and
the
international
dimension.

• Data
transparency
needs:
having
a
good
overview
of
available
data(sets)

Inconsistent
interfaces,
insufficient
provenance
information
and
scattered
and

heterogeneous
resources
(D2.1,
Page
49)
are
all
challenges
for
archaeologists
wishing
to
use

data.
To
address
these
challenges,
the
expected
benefits
from
the
ARIADNE
infrastructure

and
services
to
ease
search
and
access
are
to:
“facilitate
a
better
knowledge
of
existing

datasets,
improved
access
conditions”,
“user-‐friendly
queries
and
interfaces”
and
“cross-‐
searching
data
repositories”
(D2.1,
Page
65).

Respondents
suggested
that
ARIADNE
should
establish
a
new
portal
for
data
search.
If
such

a
portal
(on
top
of
existing
data
resources)
is
established,
users
will
clearly
expect
added-‐
value
–
i.e.
it
must
have
other
or
better
features,
or
provide
access
to
more
resources.
While

an
improved
overview,
cross-‐searching
and
filtering
of
data
resources,
would
be
a
good

progression
from
the
current
situation,
the
specific
requirements
are
not
fully
clear
(D2.1,

Page
163).
The
most
commonly
stated
needs
are
searching
across
distributed
resources
and

ARIADNE
D.13.1
(Public)

7

filtering
hit
returns
more
effectively.
Mentioned
is
“Innovative
methods
to
represent
time

and
other
values;
semiautomatic
extraction
of
data
from
texts”
(D2.1,
Page
141).
Not

appreciated:
online
collections
pre-‐culled
by
others
(D2.1,
Page
157).

• Data
accessibility
needs:
the
required
data(sets)
are
available
in
an
uncomplicated

way

Only
few
respondents
felt
the
online
availability
of
research
data
was
satisfactory.
Data

appeared
as
difficult
to
find,
not
available
online,
and
if
online,
difficult
to
access
(D2.1,
Page

63).
Some
respondents
commented
that
they
could
not
rate
the
availability
of
data
they
do

not
use,
while
others
complained
about
lack
of
downloadable
“raw
data”
for
re-‐use
(D2.1,

Page
159).
Informal
contacts
and
networks
play
a
major
role
in
gaining
access
to
the
data

that
haven’t
been
published
yet.
Humanities
scholars
in
general
seem
willing
to
share
some

data
with
other
researchers
but
the
“raw
data”,
such
as
a
database
used
for
the
creation
of

a
scholarly
edition
is
not
usually
shared.
Scholars
wish
to
be
acknowledged,
cited
and

referenced
by
peers
for
their
published
work
(D2.1,
Page
47).
Most
researchers
suggested

implementation
of
open
access
principles,
and
technical
improvements
that
would
allow

easier
searching
and
access.
For
example:
“Large
open
databases,
easily
accessed,
well

managed
(…)
Would
also
make
it
easier
for
me
to
enter
my
material
or
parts
of
my
material

there.”
Among
the
technical
suggestions
were:
“A
coherent
method
of
data
publication,

accessibility
(intelligent
interfaces)
and
transparency
about
the
data
creation
process
(D2.1,

Page
64).”
Concerning
data
that
are
accessible
online,
researchers
mentioned
that
they
are

sometimes
not
as
useful
as
they
could
be,
because
data
is
structured
in
different
ways,
not

up
to
date,
incomplete
or
lacks
important
details
(e.g.
how
it
was
collected
or
processed).

Moreover,
a
lot
of
data
are
not
re-‐usable
but
“canned
content”
(such
as
data
tables
in
pdf

documents)
or
not
available
under
an
adequate
license.
Therefore,
we
believe
that
users
of

the
ARIADNE
portal
would
benefit
from
innovative
mechanisms
that
allow
a
quick
scan
of

data
resources
to
quickly
assess
their
usefulness
(e.g.
previews,
snapshots,
“look
inside”

functionality).
Also
some
pre-‐filtering
or
ranking
services
might
be
provided
(e.g.
only

openly
licensed
data)
(D2.1,
Page
162).

ARIADNE
D.13.1
(Public)

8

Researchers
have
a
predominantly
project-‐centred
view,
rather
than
an
institutional

perspective
on
data.
As
a
result,
the
major
formats
for
organizing
data
are
“project
archives”

(one
per
excavation
site)
and
“database
projects”
of
small
research
groups,
or
even
a
single

researcher.
The
“collection”
format
is
much
less
common.
Unfortunately,
this
does
not

represent
favourable
conditions
for
linking
and
integrating.
To
link
these
project
archives

with
a
common
repository
requires
a
system,
workflows,
and
dedicated
staff,
which
may

not
be
available
in
many
research
institutions.
ARIADNE
will
have
to
focus
on
data
sets
that

are
already
available
in
existing
institutional
repositories
and
national
data
centres
and,
but

on
the
other
hand,
promote
the
flow
of
currently
“dark
data”
into
the
repositories
or

centres.
However,
in
many
countries
national
centres
do
not
exist,
or
may
not
be
optimal

(e.g.
lack
of
Open
Archive
Initiative
compliant
systems).
Hence,
ARIADNE
can
play
a

significant
role
in
leveraging
the
“data
tanks
and
pipelines”
(D2.1,
Page
157).

• Metadata
quality
needs:
the
available
data(sets)
are
well
described.

Most
researchers
seem
not
to
worry
much
about
metadata
(like
repository
managers
do)

and,
consequently,
often
do
not
produce
metadata
for
the
various
data
(data
sets)
they

generate
in
projects.
Researchers
are
aware
and
concerned
that
producing
adequate

metadata
is
a
considerable
additional
effort,
and
that
they
might
lack
required
expertise.
To

allow
for
effective
data
sharing,
these
additional
efforts
(costs)
will
have
to
be
covered

somehow
(e.g.
by
research
grants)
(D2.1,
Page
62).

One
field
of
practice,
which
might
be
enhanced,
is
the
preparation
of
shareable
data
or

datasets.
Profiling
researchers’
practices
will
allow
greater
understanding
of
how
they

prepare
data
(e.g.
to
underpin
a
publication)
and
what
is
understood
to
be
shareable
data,

beyond
just
presenting
summary
tables,
charts,
etc.
in
a
publication.
This
has
been
explored

by
the
Data
Curation
Profiles
project,
in
view
of
enhancing
researchers’
data
sharing

through
repositories
(cf.
3.6.8).
Profiles
like
the
ones
produced
in
this
project
might
also
be

relevant
for
ARIADNE
(D2.1,
Page
48).

ARIADNE
D.13.1
(Public)

9

• Data
quality
needs
in
general:
the
available
data(sets)
are
complete
and
well

organized

Concerning
data
that
are
accessible
online,
several
researchers
mentioned
a
lack
of

usefulness
because
the
data
are
structured
in
different
ways,
not
up
to
date,
incomplete
or

lack
important
details.
For
example:
“the
main
problem
is
the
variability
and
inhomogeneity

of
data
content
and
structure”;
“incomplete
datasets;
online
databases
that
aren’t
kept
up

to
date
(this
is
a
big
problem)”;
“lack
of
details
on
how
data
was
collected
–
it
is
difficult
to

assess
the
quality
of
data
published
online”
(D2.1,
Page
63).
Online
publications
with

supplemental
data
are
seen
as
particularly
important,
equal
to
printed
publications.

However,
the
feedback
indicates
that
it
is
not
the
source
as
such
that
matters
–
it
is
the

quality
of
the
data
contained.
There
is
no
single
most
important
source;
researchers
make

use
of
all
kinds
of
sources
(D2.1,
Page
158).

Archaeologists’
seem
to
seek
improvements
especially
in
the
initial
phase
of
the
data

lifecycle
(field
recording,
data
entry)
and
when
publishing
project
results
online
(D2.1,
Page

50).
The
usefulness
of
a
suggested
new
tool
or
service
is
evaluated
with
regard
to
the

individual
or
group
of
“scholarly
primitives”
it
aims
to
support
(searching,
collecting,

comparing,
annotating,
etc.)
and
what
researchers
are
already
using.
To
invest
time
and

energy
in
learning
how
to
use
a
tool
effectively,
researchers
need
to
be
convinced
that
it
will

not
become
rapidly
obsolete.
(D2.1,
Page
48)
They
do
not
like
significant
changes
in
existing

research
designs,
workflows
or
vocabularies.
Achievement
of
data
compatibility
and

interoperability
are
a
concern,
though
the
willingness
to
adopt
unfamiliar
standards
is

generally
low
(D2.1,
Page
49).
The
need
expressed
as
the
ease
of
documentation
and

metadata
production
is
formulated
as:
“simple-‐to-‐use
tools
for
documenting
and
sharing”;

“a
metadata
ingestion
and
management
tool
(…)
that
can
be
easily
installed
in
our
server
to

organize
the
workflow
during
the
production
phases”
(D2.1,
Page
65).

ARIADNE
e-‐infrastructure
and
services
might
support
first
steps
in
advanced
e-‐research

practices,
for
example,
aggregation,
integration
and
mining
of
datasets.
As
suggested
by
an

archaeological
e-‐science
scoping
exercise,
this
would
require
going
beyond
resource

discovery
across
distributed
datasets
(D2.1,
Page
50).
ARIADNE
services
might

provide/support:

ARIADNE
D.13.1
(Public)

10

• identification
of
available
datasets,
which
could
be
relevant;

• data
aggregation,
search
and
delivery
(e.g.
via
web
services);

• links
to
relevant
tools/workbenches
(e.g.
data
exposure
and
integration
tools);

• deep
and
dependable
linking
between
datasets
and
tools
(beyond
file
level);

• ontologies
for
data
mining,
integration,
and
analysis.

Expected
benefits
from
ARIADNE
are:
“a
common
approach
for
the
presentation
of

archaeological
research
data
(data
structure,
…)”,
and
“…
standardization.
If
metadata…are

produced
in
a
similar
way,
language
barriers
can
be
overcome,
too”
which
could
then
allow

“a
thematic
or
methodological
approach,
rather
than
just
combining
data
in
an
arbitrary

way”.
These
common
approaches
may
enable
comparative
research
to
“make
results,
sites

and
evidence
comparable”,
and
thus
allow
“more
potential
for
quantitative
comparisons”

thus
showing
why
“comparative
data
sets
[should]
be
made
available
for
furthering
and

developing
advanced
research
in
archaeology”
(D2.1,
Page
65).

• The
need
for
an
international
dimension:
having
easy
access
to
international

data(sets)

Having
access
to
international
data(sets)
was
perceived
as
“very
important”.
According
to

the
pilot
interviews,
one
major
reason
for
seeking
data
beyond
national
borders
is

comparative
research
for
broad
synthesis
or
meta-‐analysis.
“The
research
between
different

institutes
(with
different
specializations
and
their
own
databases)
would
benefit
greatly”,

and
“access
to
a
wider
geographical
datasets
will
in
time
help
facilitate
cross
collaboration

and
enhance
funding
opportunities”.

Only
a
few
researchers
mentioned
that
other
languages
are
an
issue
for
accessing
and
using

data
and
datasets.
(D2.1,
Page
64).
There
is
mixed
evidence
concerning
the
question
as
to

whether
data
and
metadata
need
to
be
available
in
different
languages
(other
than
English)

(D2.1,
Page
161).

ARIADNE
D.13.1
(Public)

11

Thinking
beyond
individual
users,
ARIADNE
should
also
be
seen
as
a
service
for
data

repositories,
other
websites
and
for
specific
practitioner
communities.
ARIADNE
may
help

enrich
services
of
underlying
repositories,
by
suggesting
(and
providing)
links
to
similar
or

complementary
collections
or
individual
items
held
by
other
repositories
(for
example).
For

other
websites,
ARIADNE
could
provide
RSS
feeds
on
available
new
data
relevant
to

particular
subjects
or
geographic
regions.
An
Application
Programming
Interface
(API)
would

be
useful
for
application
developers
seeking
to
combine
(mashup)
ARIADNE
data/metadata

with
other
information
resources
(D2.1,
Page
163).

Archaeology
has
close
scholarly
neighbours,
including
classics,
medieval
studies,
epigraphy,

iconology
and
others.
A
multitude
of
directories,
catalogues,
bibliographies,
reference

collections,
text
and
image
corpora,
and
digital
editions
have
been
produced
in
those
fields.

These
resources
have
not
been
fully
considered
yet
by
ARIADNE,
but
the
neighbours
are

relevant
both
as
providers
and
users
of
data
and
knowledge
resources
(e.g.
vocabularies).

Thirty
per
cent
of
the
repository
managers
surveyed
said
their
holdings
include

data/content
relevant
for
corpus
studies
(D2.1,
Page
157).

4.2 Use
requirements
(D12.1)

Task
12.1
of
WP12
pulled
together
the
considerable
information
already
gathered
within

several
other
ARIADNE
tasks
and
their
resulting
deliverables,
with
to
understand
the
nature

of
the
infrastructures
provided
for
integration,
including
an
inventory
of
what
data
and

metadata
will
be
available
within
the
registry,
making
it
possible
to
identify
gaps
that
may

be
present,
and
how
they
may
be
adapted
for
integration.
The
deliverables
analysed
by
12.1

include:

• D3.1:
Initial
Report
on
Standards
and
on
the
Registry

• D3.2:
Report
on
Project
Standards

• D3.3.
Report
on
Data
Sharing
Policies

• D2.1
First
report
on
users’
needs

ARIADNE
D.13.1
(Public)

12

D12.1
formulates
user
requirements
on
Data,
requirements
on
Metadata
standards,

Schema’s
and
Vocabularies
and
requirements
on
Access
and
Sharing
Policies.
The
needs

expressed
by
researchers
regarding
data
are
clear.
The
most
important
type
of
data
is

excavation
data,
(stratigraphy,
description,
images,
finds,
GIS
data,
geophysical
data,

environmental
data,
radiocarbon
data).
Seventy-‐five
per
cent
of
the
respondents
said
that

excavation
data
was
“very
important”
for
them
to
carry
out
their
research
projects.
Also

very
important
for
a
large
group
of
researchers
(about
50%
each)
was
GIS
data,
data

stemming
from
material
or
biological
analysis,
and
data
from
field
surveys
(descriptions,

images
and
finds
data
for
individual
sites,
and
GIS
data,
by
period,
material
and
site
type
for

the
survey
as
a
whole).
These
types
of
data
are
also
the
ones
most
frequently
produced
by

researchers.
More
specific
research
data
mentioned
as
being
searched
for
and
produced

are:
“images,
maps
and
texts”,
“bibliographical
research,
historical
data,
maps,
etc.”,

“artefact
studies”;
“mostly
3D
models
from
3D
survey
and
3D
reconstruction”;

“geomorphology,
geology
and
vegetation
data”;
“14C
dating
and
carbon
and
nitrogen

isotope
analysis”.

A
majority
of
the
researchers
interviewed
said
that
excavation
and/or
the
management
of

archaeological
sites
and
monuments
were
among
their
research
priorities.
For
monuments,

the
data
consists
of
physical
description,
location
data,
images,
access
data,
and

conservation
data.

The
users’
needs
survey
revealed
that
researchers
are
first
struggling
to
know
what
data

exist.
Researchers
are
also
concerned
that
producing
adequate
metadata
is
a
considerable

additional
effort.
The
willingness
to
adopt
unfamiliar
standards
is
generally
low.

Data
transparency
and
data
accessibility
are
seen
as
the
most
important
user
needs,

including
the
recommendation
made
within
D3.3
Report
on
data
sharing
policies,
that
all

ARIADNE
data
resources
have
DOIs
or
the
equivalent.
As
only
three
partners
(ADS,
SNDS
and

DANS)
have
the
ability
to
mint
DOIs
at
present,
how
(and
if)
this
can
be
implemented
will

need
further
exploration.
The
topic
of
access
will
be
part
for
further
strategic
work
within

D2.2.
Second
report
on
users’
needs.
There
will
be
further
requirements
once
users
have

discovered
“useful”
data(sets).
For
example,
if
such
data
has
been
found
users
might
wish
to

also
find
related
publications
from
the
researchers
who
have
shared
it.
Therefore,
as
next

ARIADNE
D.13.1
(Public)

13

steps
we
suggest
having
some
“lead
users”
evaluate
a
larger
number
of
portals
to
identify

where
and
how
various
needs
and
requirements
are
met
(or
not
met),
including
examples
of

existing
innovative
approaches,
and
further
ideas
on
specific
services
or
features
the

ARIADNE
user
community
might
appreciate.

The
interactions
between
the
work
packages
and
relevant
tasks
can
be
seen
in
Figure
2.

Figure
2:
Relationship
of
Task
13.1
with
its
related
WPs
and
Tasks

ARIADNE
D.13.1
(Public)

14

5 Common
Vision

The
Description
of
Work
(DOW)
of
ARIADNE
has
been
taken
as
a
starting
point.
It
formulates

the
following
mission
statement:

“ARIADNE
brings
together
and
integrates
existing
archaeological
research
data

infrastructures
so
that
researchers
can
use
the
various
distributed
datasets
and
new

and
powerful
technologies
as
an
integral
component
of
the
archaeological
research

methodology”.

In
order
to
fulfil
this
mission,
we
now
describe
(1)
the
general
objectives,
and
(2)
the
steps

that
will
be
taken
within
the
context
of
WP13
to
achieve
these
objectives.

Archaeological
research
infrastructures
form
a
very
heterogeneous
and
fragmented

landscape,
in
which
well-‐developed
and
advanced
infrastructures,
catering
to
the
needs
of

broad
research
communities,
coexist
with
much
simpler
infrastructures
offering
basic
data

access
services
to
a
restricted
group
of
scholars.
Along
an
orthogonal
dimension,
we
must

consider
the
heterogeneity
of
the
research
methodologies
that
the
ARIADNE
communities

follow
and
that
inform
the
supporting
infrastructures.
Last
but
not
least,
we
must

acknowledge
the
heterogeneity
of
the
information
technologies
that
are
currently
in
use
in

the
ARIADNE
landscape,
in
terms
of
the
models
and
technologies
for
supporting
data

resources,
and
in
terms
of
the
algorithms,
domains
and
architectures
of
the
service

resources.
These
three
levels
of
heterogeneity
are
the
starting
point
for
ARIADNE.

Under
these
circumstances,
ARIADNE
has
decided
to
pursue
its
mission
by
following
a

pragmatic
approach,
based
on
the
recognition
of
the
existing
data
and
service
resources,

and
on
the
development
of
an
infrastructure
where
data
and
services
resources
can
be

registered,
discovered
and
accessed
in
a
uniform
and
integrated
way,
in
support
of
the

existing
research
methodologies,
and
regardless
of
the
different
architectures
that
support

these
resources
in
their
original
format.
The
resources
that
will
be
discoverable
and

accessible
through
the
ARIADNE
infrastructure
may
be
the
ones
originally
provided,
or
may

be
the
result
of
integrations,
either
at
the
data
or
at
the
service
level.
In
particular,
the

integration
of
the
data
resources
is
planned
and
executed
in
WP12,
while
the
integration
of

ARIADNE
D.13.1
(Public)

15

the
services
will
be
outlined
in
the
rest
of
this
document.
Here,
we
aim
to
outline
the

overarching
vision.

The
general
objective
is
therefore
the
creation
of
a
single,
global
access
point,
which
will
act

as
a
broker
between
the
resource
providers
and
the
resource
consumers,
in
accordance

with
the
nature
of
an
infrastructure.
Resource
providers
will
be
able
to
register
their

resources
and
supply
rich
descriptions
about
them,
following
the
ontology
established
by

the
ARIADNE
Catalogue
Data
Model,
defined
elsewhere.
On
the
other
hand,
resource

consumers
will
be
able
to
explore
the
ARIADNE
data
and
service
space,
either
in
browsing
or

querying
mode,
via
simple
or
structured
queries.
Furthermore,
the
consumers
will
be
able

to
access
the
discovered
resources,
obtaining
data
or
services.

We
would
like
to
stress
that
the
creation
of
such
an
infrastructure
is
already
a
considerable

step
forward
within
the
archaeological
domain,
as
it
implies
the
creation
of
a
unique
space

where
the
currently
dispersed
resources
can
be
uniformly
described,
discovered
and

accessed,
overcoming
the
idiosyncrasies
that
currently
prevent
their
full
exploitation
by

scholarly
communities.
At
the
same
time,
it
represents
a
necessary
step
towards
the
more

ambitious
goal
of
creating
a
unique
knowledge
and
service
base
for
archaeology,
a
long-‐
term
goal
that
still
stands
as
extremely
challenging
and
desirable.

ARIADNE
will
reach
the
above-‐described
objective
in
two
major
steps,
as
established
by
its

Description
of
Work.

In
the
first
step,
it
will
set-‐up
the
infrastructure,
which
will
be
accessible
via
a
portal,

offering
basic
services
for
registering,
discovering
and
accessing
resources.
The
data
and
the

service
resources
will
be
made
available
in
a
raw
form,
with
little
or
no
attempt
at
creating
a

uniform
look-‐and-‐feel,
and
with
little
or
no
attempt
to
integrate
the
similar
data.
In
this

step,
the
emphasis
will
be
on
obtaining
a
complete
population
of
the
resource
space,

regardless
of
how
different
one
dataset
or
one
service
will
look
from
the
others.
This
step

will
be
completed
by
month
24,
resulting
in
deliverable
D13.2.

In
the
second
step,
a
more
advanced
version
of
the
register-‐discover-‐access
services
will
be

offered,
and
access
to
the
available
resources
will
be
harmonized,
so
that
the
user
will

obtain
a
uniform
experience
across
the
whole
ARIADNE
space.
At
the
end
of
this
step,
the

ARIADNE
D.13.1
(Public)

16

data
provided
and
service
resources
that
are
planned
to
be
tightly
integrated,
will
also
be

available.

The
next
sections
are
aimed
at
providing
an
overview
of
the
infrastructure
by
proposing

three
actors,
which
have
been
created
following
the
needs
and
input
documented
by
Tasks

2.1
and
12.1.
The
actors
represent
different
possible
users
of
the
infrastructure.
Each
actor

needs
to
complete
different
tasks:
some
of
which
are
described
and
analysed
in
the
Use

Cases
section.

6 The
Actors
and
their
stories

This
chapter
describes
the
different
users
and
how
their
work
relates
to
the
different
phases

of
the
research
data
lifecycle.

6.1 Introducing
Laura

Laura
Simons
studied
Prehistory
at
Leiden
University
with
a
specialisation
in
the
Bronze
and

Iron
Age
of
the
Netherlands,
graduating
in
2007,
and
continued
her
career
at
a
commercial

archaeological
organisation
for
two
years.
This
was
followed
by
a
PhD,
which
was
financed

by
the
Dutch
Scientific
Organisation
(NWO)
from
2009-‐2013.
After
her
PhD,
Laura
continued

with
a
new
subsidised
project
and
combines
this
with
a
job
as
a
teacher
in
the
Department

of
Archaeology
at
the
University
of
Leuven
in
Belgium.
The
project
will
finish
around
2018.

The
project
is
about
the
habitation
development
along
the
river
Rhine
valley,
with
a
focus

on
eight
sites,
covering
the
timespan
from
the
Stone
Age
to
the
Medieval
Period.
The
digs

took
place
between
1960
and
1990
and
were
not
studied
and
published
before,
thus
the

aim
of
the
project
is
to
work
through
several
of
unpublished
archaeological
excavations.

6.1.1 Searching
collections

Working
on
her
recent
project,
Laura
found
interesting
information
about
a
Dutch
burial
site

from
the
Iron
Age,
and
wants
to
compare
this
to
burial
practices
elsewhere
in
Europe.
Laura

will
publish
on
this
topic.

ARIADNE
D.13.1
(Public)

17

Laura
searches
online
to
collect
detailed
information.
She
is
looking
for
general
and
specific

data.
Laura
can
do
her
research
on
her
own
computer
using
services
available
through
the

work
of
ARIADNE.

Through
ARIADNE,
Laura
can
easily
obtain
a
list
of
all
the
collections
related
to
her
project.

Laura
was
happy
to
see
that
another
archaeologist
put
older
research
with
detailed
data

online
that
was
useful
for
her
work.

By
providing
search
input
to
the
portal,
Laura
is
able
to
obtain
a
detailed
list
of
the

collections
that
include
items
that
fit
the
query.
Advanced
visualization
services

(visualization
on
maps,
timelines)
enable
Laura
to
refine
her
search.

See
use
cases
Discover
data,
Preview
data,
and
Access
data

6.1.2 Accessing
collections

Laura
can
obtain
a
preview
of
the
collections
retrieved
after
the
query.
The
preview

contains
a
set
of
general
information
about
the
collection,
and
possibly
a
representative
set

of
thumbnails.

She
can
access
the
collections
with
a
single
click,
being
redirected
to
their
website.

6.2 Introducing
Valentino

Valentino
De
Angelo
works
as
an
archive
manager
for
a
national
archaeological
research

institute
executing
studies,
surveys
and
excavations.
The
archaeologists
are
depositing
their

data
at
this
institute.

He
is
currently
interested
in
finding
new
ways
to
store
and
visualize
several
types
of
data,

including
high-‐resolution
images,
3D
models
and
GIS
data.

He
is
mainly
interested
in
providing
ways
to
remotely
access
data,
but
at
the
same
time,
he

would
like
to
protect
the
data
by
preventing
items
within
the
collections
from
being

downloaded.

ARIADNE
D.13.1
(Public)

18

6.2.1 Search
services

Valentino
is
trying
to
find
available
services
for
his
collections.
He
would
like
to
know
what

the
different
possibilities
are
to
handle
the
data.

6.2.2 Use
services

Valentino
is
available
to
use
new
services
to
better
store
or
present
the
items
within
the

collections,
and
is
willing
to
use
new
technologies
in
order
to
preserve
and
visualize
data.

6.2.3 Support
collections

Valentino
would
like
to
use
the
services
to
enrich
the
collections,
but
he
would
also
like
to

take
advantage
of
the
server
space,
so
that
the
Ariadne
portal
could
maintain
some
of
the

pages
produced
by
services.

6.2.4 Enrich
collections

Valentino
wants
to
be
able
to
directly
enrich
the
collections,
so
he
would
like
to
take

advantage
of
the
services,
but
he
would
also
like
to
download
the
produced
data
and
store

it
directly
within
the
original
collections

6.2.5 Preserve
data

Valentino
is
worried
that
the
data
formats
of
his
collections
won’t
be
supported
in
the

future
or
that
the
collections
won’t
have
the
resources
to
keep
the
items
online.
He
may
be

interested
in:
accessing
guidelines
about
data
preservation,
making
use
of
services
for

automatic
data
conversion,
and
storing
data
on
an
available
server
that
could
ensure
long-‐
term
preservation.

6.2.6 Add
collections
to
the
registry

Valentino
is
managing
an
archive
that
is
continuously
adding
new
collections.
He
would
like

to
easily
add
them
to
the
Ariadne
Registry,
in
order
to
make
them
available
for
the

community.

ARIADNE
D.13.1
(Public)

19

6.3 Introducing
Christopher

The
infrastructure
employs
Christopher
Moore
as
security
manager.
He
is
responsible
for

the
good
operation
of
the
ARIADNE
portal.

His
main
role
is
to
take
charge
of
the
security
issues,
focusing
on
authentication
and
access.

He’s
also
interested
in
being
able
to
track
the
resource
usage,
and
check
the
availability
of

services.

6.3.1 Authentication
and
authorization

Users
of
the
portal
may
access
the
portal
with
differing
roles.
Christopher
wants
to
be
able

to
control
an
authentication
and
authorization
service.

6.3.2 Attribute-‐based
access
control

Since
those
who
access
the
portal
may
have
different
roles
and
needs
(like
Laura
and

Valentino),
an
attribute-‐based
access
control
is
needed
to
be
able
handle
the
permissions.

Hence,
a
set
of
user
related
attributes
(e.g.
roles,
collections)
and
eventually
environment

related
attributes
(e.g.
country,
date)
are
needed.

6.3.3 Support
for
standards

Christopher
would
prefer
to
have
a
set
of
services
that
could
follow
recognized
standards.

6.3.4 Support
for
data
providers

Christopher
should
also
work
with
data
providers,
to
help
them
prepare
new
collections
for

the
registry,
and
use
the
tools
provided
by
the
ARIADNE
portal.
He
should
at
least
be
able
to

re-‐direct
the
users
to
the
maintainers
of
external
services.

ARIADNE
D.13.1
(Public)

20

6.3.5 Resource
usage
tracking

Christopher
is
interested
in
being
able
to
track
the
use
of
resources
in
the
portal.
This
can
be

useful
to
quickly
produce
reports,
map
the
main
usage
of
the
services
and
eventually
find

improper
behaviours.

7 Use
cases

The
above
actors
presented
above
are
a
starting
point
to
provide
an
overview
of
the
desired

functionalities
of
the
portal,
which
will
be
specified
from
a
user
perspective.
The
Description

Of
Work
will
be
the
starting
point
for
defining
the
user
functionality.
This
will
be
the
basis

for
an
examination
of
existing
portals
as
examples
for
the
generic
portal
approach
of

ARIADNE.
Finally,
a
stakeholder
survey
will
allow
the
detailing
and
prioritization
of
this

functionality,
and
the
functionality
will
be
the
basis
of
the
Framework
for
Requirements.

In
between,
the
functionality
will
be
discussed
within
the
project
and
work-‐packages.
One
of

the
discussions
led
to
the
decision
(November
2013,
Pisa)
to
exclude
annotation-‐support

(the
demand
for
annotation-‐support
was
considered
low,
while
the
implementation
and

maintenance
of
robust
annotation
tools
is
a
cumbersome
task).
It
can
be
considered
in
an

experimental
way
for
3D
models,
to
make
comments
by
researchers
on
non-‐researcher

metadata.

The
requirements
of
the
ARIADNE
portal
are
based
on
use
cases,
to
ensure
that

requirements
are
defined
to
support
the
users.
This
has
been
done
by
first
defining
the

users
(or
actors)
and
their
interaction
with
the
services
(their
scenarios),
broken
down
into

clear
steps.
This
will
allow
structured
analysis
of
the
requirements
for
the
services
to
the

end
users,
as
well
as
to
the
technical
components
that
should
enable
these
services
(like
the

ARIADNE
Catalogue
Data
Model).

The
activities,
their
steps
and
derived
requirements
will
be
prioritized
in
order
to
ensure
a

realistic
and
pragmatic
end-‐result
for
the
project.

ARIADNE
D.13.1
(Public)

21

7.1 Search
and
explore
the
registry

Characteristics
Description

Description
Laura
wants
to
search
and/or
browse
the
portal
to
look
for
archaeological

datasets
she
can
preview
and/or
download.

“Trigger”
Laura
navigated
to
the
ARIADNE
portal,
either
directly
by
entering
the
URI,
or

indirectly
by
using
a
search
engine
like
Google.

Preconditions
Laura
has
general
ICT
skills

Laura
is
an
archaeologist

Primary
Actor
Laura,
in
the
role
of
data
consumer.

Basic
flow

scenario

Step
1:
Navigate
to
search
page.

e.g.
Laura
clicks
on
the
menu-‐item
search

Step
2:
Enter
search
parameters.
(sub-‐steps
can
be
repeated
0
or
more
times):

Step
2a:
Enter
keywords.
Keywords
and
operators
can
be
entered.

e.g.
Laura
enters:
burial
mounds
AND
Iron
Age
AND
France

Step
2b:
Specify
multi-‐linguality.
The
linguality
of
the
keywords
and
the
results
can

be
specified.

e.g.
Laura
ticks
the
multi-‐lingual
option
and
selects
“Dutch”,
“English”
and

“French”.

Step
2c:
Geo-‐integrated
search.
Zooming
and
panning
the
map
can
specify
the

location/area.
This
step
is
integrated
with
the
results
(see
Step
3b).

e.g.
Laura
zooms/pans(moves)
to
the
region
of
Northern
France.

Step
2d:
Specify
collection.
The
collections
can
be
specified.

e.g.
Laura
selects
the
collection
“Burials”.

Step
2e:
Timeline
search.
The
time
or
period
can
be
specified.

e.g.
Laura
selects
the
Iron
Age
from
a
timeline.

ARIADNE
D.13.1
(Public)

22

Step
3:
Show
results.
The
specified
parameters
are
displayed
and
the
matching

results
are
presented
to
the
user.
The
results
can
be
presented
using
different

views.

Step
3a:
The
results
are
displayed
as
a
list.
The
list
has
multiple
pages
and
can
be

ordered.
Each
entry
shows
the
most
significant
metadata
elements
for
the
entry.

e.g.
the
system
shows
the
creator
and
the
title
of
the
first
10
results,
ranked

alphabetically.

Step
3b:
The
results
are
displayed
on
a
map,
according
to
the
coordinates
in
the

indexed
metadata.
Once
one
of
these
results
is
clicked,
a
popup
is
shown

indicating
a
(clickable)
title
and
creator
of
the
dataset.

e.g.
Laura
sees
3
datasets/collections
about
burials
in
the
region
of
Northern

France.

Step
3c:
The
results
are
displayed
on
a
timeline.
Once
one
of
these
results
is

clicked,
a
popup
is
shown
indicating
a
(clickable)
title
and
creator
of
the
dataset.

e.g.
Laura
sees
that
three
datasets
all
belong
to
the
Iron
Age,
starting
X
and

ending
Y.

Step
4:
Laura
clicks
one
of
the
results
(go
to
5)
or
decides
to
adjust
her
search

parameters
(go
to
2).

Step
5:
The
system
displays
a
preview
of
the
selected
dataset
to
Laura
and/or

provides
an
overview
of
the
metadata
of
the
object,
including
a
link
to
download

it.
Laura
has
the
possibility
to
return
to
the
original
search
results.

e.g.
This
overview
includes
(e.g.)
title,
creator,
date
issued,
coordinates,
time

coverage,
language,
access
rights,
persistent
identifiers,
repository,
etc.
There
is

also
a
link
that
allows
downloading
of
the
data.

Discussion:
Discover
=

search
and
browse
(define
collections
and
categorise
in
sub

disciplines:
Indexing)

Source:
User
interface
component
at
ARIADNE
portal.
(DOW)

This
will
include
indexing
and
retrieval,
whenever
required
by
the
amount
and

heterogeneity
of
data.
They
will
take
into
account
issues
like
scalability,
indexing

optimization
(query
caching),
ranking
and
searching
methodologies,
etc.
as
well
as
an

ARIADNE
D.13.1
(Public)

23

interface
enabling
other
services
to
search
and
retrieve
content
from
within
the

infrastructure.
(DOW)

The
resource
discovery
is
obtained
by
searching
on
the
registry
catalogue,
which
contains
a

metadata
description
of
all
the
collections.

We
foresee
faceted
search
functionality
allowing
users
to
explore
their
searches
with
filters.

7.1.1 Navigate
to
search
page

#
Description
Priority

1
Indirect
access
-‐
The
search-‐functionality
can
be
reached
from
any
page
within
the

ARIADNE
portal,
by
clicking
its
menu-‐item.

High

2
Direct
access
-‐
The
basic
search-‐functionality
is
present
at
any
page
within
the

ARIADNE
portal,
e.g.
by
allow
direct
entry
of
keywords
in
small
search-‐interface.
The

results
are
presented
in
the
default
result-‐view.

Medium

Technical
impact:

• No
significant
impact.

7.1.2 Enter
Search
Parameters

#
Description
Priority

1
No
parameters
–
A
search
query
without
parameters
returns
all
datasets,
ordered
by

date,
showing
the
latest
first.

High

2
Multiple
parameters
–
Multiple
parameters,
e.g.
keyword
parameters
and
geographic

parameters,
are
combined
conjunctive
(“AND”,
showing
datasets
that
fulfil
both

parameters).

High

Technical
impact:

• No
significant
impact.

ARIADNE
D.13.1
(Public)

24

7.1.3 Free
text
search

#
Description
Priority

1
Multiple
keywords
–
one
or
more
keywords
can
be
entered

High

2
Boolean
operators
–
the
keywords
can
be
combined
with
operators
such
as
(like,
and,

or,
proximity
search)

High

Technical
impact:

• An
index
is
required.
It
needs
to
support
multiple
keywords
and
operators.

• The
metadata
fields
to
be
indexed
need
to
be
determined.

7.1.4 Multilingual
search

Source:
Integration
of
new
multilingual
thesauri,
to
allow
linking
previous
dataset
across

languages
and
to
enable
new
search
services
(DOW).

Note:
Should
discuss
with
an
expert
on
multi-‐lingual
search.

#
Description
Priority

1
Default
multi-‐linguality
–
The
system
searches
in
all
indexed
descriptions,

independent
of
their
language.

High

2
Specified
languages
–
The
user
specifies
the
language
for
the
keywords.
The
system

looks
for
descriptions
in
those
languages,
as
well
as
descriptions
in
undefined

languages.

Medium

3
Translated
keywords
–
The
user
specifies
to
which
languages
the
keywords
should
be

expanded.
The
system
translates
the
given
keywords
and
searches
the
descriptions

using
the
translated
keywords.

Medium

Technical
impact:

• A
multi-‐lingual
thesaurus
is
required.

• Either
the
descriptions
are
translated
upon
indexing,
or
the
keywords
are
translated
upon

querying.

• The
language
of
the
metadata
descriptions
is
specified

ARIADNE
D.13.1
(Public)

25

7.1.5 Geo-‐integrated
search

Source:
Sophisticated
analyses
of
spatial
features,
combining
the
information
available
in

distinct
datasets;
creation
of
derivative,
GIS-‐based
archaeological
digital
maps,
embracing

vast
regions
and
collecting
together
specific
features
from
different,
and
so
far
separated,

datasets,
e.g.
“digital
map
of
the
distribution
of
Roman
amphorae
in
the
1st
century
AD
in

the
Mediterranean
basin”.
(DOW)

Discussion:
Geo-‐integrated
search
is
usually
a
way
of
presenting
all
datasets
on
a
map,
and

browsing
them
by
either
zooming
or
panning.
Geo-‐integrated
search
could
also
allow

entering
geographic
names,
as
with
Google
Maps,
or
even
to
specify
explicit
distances

(radius
from
specific
point).

#
Description
Priority

1
Geographic
area
–
A
geographic
area
can
be
specified.
Only
datasets
with
a
specified

location
within
that
area
will
be
returned.

High

2
Map
specification
–
the
geographic
area
can
be
specified
by
zooming/panning
on
a

map.
Zooming
specifies
the
height/width
of
the
area.
Panning
specifies
the
location.

High

3
Semantic
location
–
the
geographic
area
can
be
specified
by
entering
a
geographic

name
and
optionally
a
range.

Medium

Technical
impact:

• Coordinates
for
a
dataset
are
required.
Default
coordinate-‐system(s)
needs
to
be
agreed.

• Search
engine
needs
support
for
geographic
search
(based
on
coordinates).

• A
thesaurus
for
location-‐names
is
required.

7.1.6 Collection
search

Identified
collections
are:
“Sites
and
monuments”,
“Events/Interventions”,
“Fieldwork

databases”,
“Scientific”,

“Artefacts”
and
“Burials”.
(Pisa)

ARIADNE
D.13.1
(Public)

26

#
Description
Priority

1
Specify
collection
–
The
user
can
specify
the
collections
that
need
to
be
searched.
This

can
be
one,
multiple
or
all
collections.

High

Technical
impact:

• There
is
a
need
for
a
common/centrally
defined
collection
policy,
incl.
a
list
of
supported

collections.

7.1.7 Timeline
search

In
the
timeline
search,
the
user
should
be
able
to
define
a
search
for
time
period
within
the

collections.
Alternatively,
they
could
visualize
the
collection
on
the
timeline,
and
refine
the

search
by
indicating
periods
or
exploring
it.

#
Description
Priority

1
Specify
period
–
the
period
can
be
specified
using
a
“from”
and/or
“until”.
To
define

open
or
closed
periods.

High

2
Timeline
–
the
period
can
de
specified
on
a
timeline.
High

3
Timeline
zoom/shift
–
The
timeline
can
be
shifted
and
zoom
to
allow
the

specification
of
both
wide
and
specific
time
periods.

High

3
Predefined
periods
–
The
timeline
identifies
predefined
archaeological
periods
from

which
one
can
be
selected.

Medium

Technical
impact:

• Ontologies
for
predefined
periods
are
required.

ARIADNE
D.13.1
(Public)

27

7.1.8 Show
results

#
Description
Priority

1
Display
search-‐parameters
–
The
are
visible
along
with
the

search-‐results
(e.g.
above
search-‐results,
or
next
to
them
(faceted)).

High

2
Alter
–
Allow
users
to
adjust
parameters
at
the
search
result

page.

High

3
Change
views
–
The
user
can
switch
between
the
list,
map
and
timeline
view.

High

4
Multiple
views
–
The
user
can
see
multiple
views
at
the
same
time,
e.g.
map
and

timeline
view.

Medium

Technical
impact:

• No
significant
impact.

7.1.9 Show
results
as
list

#
Description
Priority

1
Ordering
–
The
results
can
be
ordered
on
different
properties
(t.b.d.).
The
default

order
by
relevance.

High

2
Paging
–
The
results
can
be
paged
with
a
configurable
page-‐size.
High

3
Metadata
preview
-‐
The
list
shows
a
summary
of
the
metadata
for
each
entry.
At

least:
title,
creator
and
date…
(t.b.d.).
A
link
is
provided
that
allows
the
user
to

navigate
to
the
preview-‐page
for
the
entry.

High

Technical
impact:

• There
is
an
algorithm
that
determines
the
relevance
of
the
search-‐results.

• The
metadata
elements
to
be
displayed
or
ordered
are
in
the
index.

ARIADNE
D.13.1
(Public)

28

7.1.10 Show
results
on
map

#
Description
Priority

1
All
results
–
The
map
indicates
all
results
on
the
map.
This
implies
that
there
is
no

paging-‐mechanism.

High

2
Point
and
clusters
–
Each
of
the
results
has
an
indicator
on
the
map.
If
there
are
too

many
results
in
a
small
area
of
the
display,
a
special
indicator
replaces
these
and

shows
the
amount
of
results
for
that
area.

High

3
Dynamic
update
–
If
the
map-‐view
changes
(by
panning/zooming),
then
a
new
search

is
executed
and
the
results
are
updated
directly
(within
the
existing
location).

High

4
Point-‐details
–
If
the
user
clicks
on
one
of
the
indicators
then
a
popup
displays
a

summary
of
the
metadata
(equal
to
list-‐view)
and
a
link
to
the
preview-‐page
of
the

entry.

High

5
Cluster-‐details
-‐
If
the
user
clicks
on
a
cluster
then
a
popup
displays
a
list
of
clickable

titles
for
each
of
the
entries.

Note
that
there
is
a
risk
that
there
are
1000’s
of
entries
with
similar
coordinates.

Zooming
will
not
decrease
the
number
of
entries,
and
paging
within
a
popup
will
also

be
difficult.

High

6
Map-‐layers
–
The
user
can
change
the
map-‐layers
(map,
satellite,
…).
This
may

include
historical
maps.

Medium

Technical
impact:

• A
map-‐server
is
available.
Custom
maps
might
require
a
self-‐managed
map-‐server
(rather

than
the
ones
from
Google
or
OpenMaps).

• There
are
multiple
geo-‐referenced
maps
available.

• Quick
zooming/panning
of
the
map
requires
the
metadata
that
to
be
displayed
is
indexed.

• Maps
or
layers
are
geo-‐referenced.

ARIADNE
D.13.1
(Public)

29

7.1.11 Show
results
on
timeline

#
Description
Priority

1
All
results
–
The
map
indicates
all
results
on
the
timeline.
This
implies
there
is
no

paging-‐mechanism.

High

2
Point
and
clusters
–
Each
of
the
results
has
an
indicator
on
the
timeline.
If
there
are

too
many
results
in
a
small
period
of
the
display,
a
special
indicator
replaces
these
and

shows
the
amount
of
results
for
that
period.

High

3
Dynamic
update
–
If
the
map-‐view
changes
(by
shifting/zooming),
then
a
new
search

is
executed
and
the
results
are
updated
directly
(within
the
existing
period).

High

4
Point-‐details
–
If
the
user
clicks
on
one
of
the
indicators
then
a
popup
displays
a

summary
of
the
metadata
(equal
to
list-‐view)
and
a
link
to
the
preview-‐page
of
the

entry.

High

5
Cluster-‐details
-‐
If
the
user
clicks
on
a
cluster
then
a
popup
displays
a
list
of
clickable

titles
for
each
of
the
entries.

Note
there
is
a
risk
of
having
1000’s
of
entries
with
a
similar
time.
Zooming
will
not

decrease
the
number
of
entries,
and
paging
within
a
popup
will
also
be
difficult.

High

6
Time-‐period
–
The
user
can
change
the
ontology
for
predefined
time-‐periods.
High

Technical
impact:

• Similar
to
“show
results
on
map”.

7.1.12 Preview
metadata

#
Description
Priority

1
All
metadata
–
The
page
shows
all
metadata
on
the
selected
entry.

High

2
No
distraction
–
The
page
shows
no
other
information.
Only
essential
branding-‐
and

navigational
information
is
shown.

Medium

3
Back
to
search-‐results
–
The
user
can
directly
navigate
to
the
search-‐results,
with
the

same
view
(page/area/period),
highlighting
the
popup
of
the
entry
that
the
user

previewed.

High

ARIADNE
D.13.1
(Public)

30

4
Source
information
–
The
user
is
informed
about
the
original
repository
and
the

conditions
for
access
of
the
information
at
that
repository
(open
access
or
not).
A
link

to
the
entry
within
its
source
repository
is
provided.

High

Technical
impact:

• The
information
about
the
source
is
registered
in
a
normalized
format.

• There
is
a
common
core
of
metadata
that
the
portal
can
display.

7.2 Preview
data

This
use
case
describes
how
a
researcher
like
Laura
can
view
a
preview
of
a
dataset.

Characteristics
Description

Description
Laura
wants
to
see
a
preview
of
the
data
that
allows
her
to
determine
the

relevance
of
the
data
for
her
research.

“Trigger”
Laura
has
discovered
the
dataset
in
the
ARIADNE
portal
(by
search/browse
within

the
portal,
or
via
Google),
sees
the
metadata
and
sees
the
option
to
preview
the

data.

Preconditions
Laura
has
general
ICT
skills

Laura
is
an
archaeologist

Primary
Actor
Laura,
in
the
role
of
data
consumer.

Basic
flow

scenario

Step
1:
Click
on
the
preview-‐option

e.g.
Laura
clicks
on
the
preview-‐tab
of
a
dataset
that
contains
images
and
a
3D-‐
model.

Step
2:
The
preview
is
displayed

e.g.
Laura
sees
an
overview
of
the
media
elements
in
the
dataset,
visually

presented
by
means
of
low-‐resolution
thumbnails
(produced
from
the
images
or
as

a
pre-‐rendered
image
of
the
3D
model).

Step
3:
The
preview
is
adjusted

ARIADNE
D.13.1
(Public)

31

e.g.
Laura
navigates
through
the
collection
of
thumbnails.

Step
5:
The
preview
is
closed

e.g.
Laura
clicks
the
upper-‐right
cross
and
is
referred
back
to
the
splash-‐page
of

the
dataset.

7.2.1 Click
on
preview
option

Discussion:
When
is
the
preview
made?
Who
creates
the
preview?
Who
serves
the
preview?

#
Description
Priority

1
Availability
–
The
preview
option
is
only
displayed
when
the
preview
is
available

High

2
The
preview
is
generated
in
an
automated
way
for
all
collections
Medium

Technical
impact:

• The
portal
knows
which
previews
exist
(or
can
be
generated
on
the
fly)
and
to
what
dataset

and
file
they
belong.

7.2.2 Display
the
preview

#
Description
Priority

1
Preview
in
browser
-‐
The
preview
is
displayed
within
the
browser

High

2
Preview
in
portal
-‐
The
preview
is
displayed
within
the
portal
High

Technical
impact:

• The
portal
knows
which
previews
exist
(or
can
be
generated
on
the
fly)
and
to
what
dataset

and
file
they
belong.

7.2.3 Adjust
the
preview

Discussion:
Behaviour
is
specific
to
each
preview.
Since
the
preview
may
be
different
among

the
collections,
it
may
also
be
possible
to
adjust
the
visualization
of
the
preview.

ARIADNE
D.13.1
(Public)

32

Technical
impact:

• The
preview
runs
client-‐side
using
static
data
that
is
stored
by
the
ARIADNE
portal.

7.2.4 Close
the
preview

#
Description
Priority

1
Close
–
The
preview
can
be
closed
by
the
user
High

2
Return
to
list
preview
-‐
After
the
preview
is
closed,
the
user
return
to
the
list
preview

page.

High

Technical
impact:

• No
significant
impact

7.3 Access
data

This
use
case
describes
how
a
researcher
like
Laura
can
access
a
database
and
eventually

download
data.

Characteristics
Description

Description
Laura
found
a
database
that
is
of
interest
for
her
research.
She
would
like
to
be

able
to
download
some
of
the
data

“Trigger”
Laura
has
discovered
the
dataset
in
the
ARIADNE
portal
(by
search/browse
within

the
portal,
or
via
Google),
sees
the
metadata,
and
the
option
to
download
the

data.

Preconditions
Laura
has
general
ICT
skills

Laura
is
an
archaeologist

Primary
Actor
Laura,
in
the
role
of
data
consumer

Basic
flow

scenario

Step
1:
Check
if
the
data
are
available
for
download

e.g.
Laura
checks
the
preview
of
the
dataset,
and
she
finds
there’s
the
possibility
to

access
and
download
the
data

ARIADNE
D.13.1
(Public)

33

Step
2:
Check
for
a
link
to
the
dataset

e.g.
Laura
sees
that
a
direct
link
to
the
dataset
is
provided

Step
3:
Access
the
dataset

e.g.
Laura
clicks
on
the
link,
and
she
is
redirected
to
the
dataset

7.3.1 Link
to
downloadable
content

#
Description
Priority

1
The
description
of
the
datasets
shows
there
is
content
to
be
directly
downloaded
High

2
A
direct
link
to
the
download
page
is
provided
Medium

3
The
portal
brings
the
user
directly
to
the
indicated
page
High

Technical
impact:

• In
the
description
of
the
collections,
the
availability
of
downloadable
material
must
be

indicated,
together
with
a
link.

7.4 Deposit
data

This
use
case
describes
how
a
researcher
like
Laura
can
deposit
her
data
in
an
appropriate
archive

Characteristics
Description

Description
Laura
wants
to
deposit
some
of
the
data
she
has
produced
in
an
ARIADNE

compatible
archive

“Trigger”
Laura
has
data,
but
she
does
not
have
an
archive
for
it

Preconditions
Laura
has
general
ICT
skills

Laura
is
an
archaeologist

Primary
Actor
Laura,
in
the
role
of
data
provider

Basic
flow

scenario

Step
1:
Check
if
there
are
archives
available
for
depositing
data

ARIADNE
D.13.1
(Public)

34

e.g.
Laura
searches
for
Ariadne
compatible
archives
that
provide
services
for

depositing
data

Step
2:
Accessing
guidelines

e.g.
Laura
can
access
to
the
general
guidelines
for
depositing
the
data

Step
3:
Access
the
archive

e.g.
Laura
is
redirected
to
the
archive,
where
she
will
be
able
to
deposit
data.

7.4.1 Link
to
archives
which
provide
services
for
depositing
data

#
Description
Priority

1
A
list
of
Ariadne
compatible
archives
is
available

High

2
A
set
of
general
guidelines
for
depositing
data
is
available

High

3
The
portal
brings
the
user
directly
to
the
desired
archive
High

Technical
impact:

• While
guidelines
for
depositing
data
may
differ
between
archives,
a
generic
set
of
rules
is

needed.
When
redirected,
the
user
should
follow
the
specific
guidelines
of
the
archive.

7.5
Search
and
access
the
services
registry

This
use
case
describes
how
a
researcher
can
use
the
ARIADNE
portal
to
discover
tools
and

knowledge
to
support
their
research
/
data
management.

Source:
Services
and
tools
for
the
construction
of
digital
clones
by
digitization
and
modelling

technologies;
services
and
tools
for
processing
sampled
data
(2D,
3D).
MeshLab

(http://meshlab.sourceforge.net/)
might
be
considered
as
the
primary
platform
for

processing
sampled
3D
data.
The
service
provided
will
include:
production
and

dissemination
of
training
material
(text,
slides,
didactical
videos)
and
planning
of
training

sessions;
management
of
the
evolution
and
consolidation
of
the
selected
services

ARIADNE
D.13.1
(Public)

35

(consolidation,
bug
fixing,
extension
of
the
set
of
supported
features,
deployment
of
new

releases).
(DOW)

Characteristics
Description

Description
This
use
case
describes
how
a
user
can
discover
tools
or
best
practices
to
achieve

a
certain
goal.

“Trigger”
Valentino
navigated
to
the
ARIADNE
portal
looking
for
tools
and
best
practices.

Directly
or
via
a
search-‐engine.

Preconditions
Valentino
has
ICT
skills

Valentino
is
an
archive
manager

Primary
Actor
Valentino,
in
the
role
of
an
archive
manager

Basic
flow

scenario

Step
1:
Navigate
to
services
section

e.g.
Valentino
clicks
a
menu
item
on
services

Step
2:
Search
and
Identify
appropriate
services

e.g.
Valentino
searches
in
the
services
catalogue
by
providing
the
information
that

he
is
searching
for
services
that
give
the
possibility
to
handle
3D
models.

Step
3:
Select,
evaluate
and
access
tool

e.g.
Valentino
selects
the
service
for
remote
3D
visualization,
reads
that
it

supports
the
creation
of
webpages
that
support
visualizing
3D
models
and
clicks

on
the
link
of
the
service.

7.5.1 Navigate
and
search
services

#
Description
Priority

1
Navigation
-‐
The
section
for
tools
&
best
practices
can
be
easily
identified
on
the

ARIADNE
portal.

High

2
Search
–
The
service
registry
permits
searching
for
the
service
that
best
fits
the

available
data.

High

ARIADNE
D.13.1
(Public)

36

Technical
impact:

• A
metadata
schema
for
the
services
is
defined.

7.5.2 Identify
appropriate
tool
or
best
practice

Discussion:
the
minimum
implementation
of
this
use
case
can
be
an
authored
webpage
that

provides
an
overview
to
common
tools
and
best
practices.

#
Description
Priority

1
Description
–
The
services
are
displayed
with
basic
metadata
that
helps
to
detect

their
functionality/purpose.

High

2
Filtering
–
The
services
can
be
sorted/filtered.

The
user
can
refine
the
search
by

indicating
some
of
the
metadata
values.
The
user
can
limit
the
set
to
only
items

relevant
for
a
specific
phase
in
the
research
lifecycle
(e.g.
data
creation,
data

processing,
data
curation,
data
storage,
data
publication).

High

3

Multi-‐linguality
-‐
the
services
are
at
least
described
in
a
shared
language,
e.g.
English
Medium

Technical
impact:

• There
is
a
basic
metadata-‐scheme
for
services.

• The
metadata
is
indexed
to
allow
searching/browsing/filtering.

• There
might
be
procedures/policy
for
creating,
updating
and
deleting
entries
for
these
tools

or
best
practices.

7.5.3 Select,
evaluate
and
access

Discussion:
tools
get
frequent
updates.
It
could
be
difficult
to
maintain
entries
for
different

versions
of
a
tool,
or
to
determine
which
tools
are
actually
the
same
(is
windows
7
the
same

tool
as
windows
8?
Is
“ABC’
the
same
tool
as
“ABC
light”?).

#
Description
Priority

1
Description
–
the
ARIADNE
portal
provides
a
page
where
the
service
is
described.
High

ARIADNE
D.13.1
(Public)

37

2
Link
–
The
page
provides
a
link
to
an
external
location
where
the
service
can
be

accessed.

High

3
Remote
services
–
wherever
possible,
the
services
are
organized
in
a
remote
way,
in

order
to
overcome
platform
and
browsers
limitations.

High

4

Multi-‐linguality
-‐
the
tools
are
at
least
described
in
a
shared
language,
e.g.
English
Medium

Technical
impact:

• The
Ariadne
portal
has
to
provide
mechanisms
to
ensure
the
access
to
the
services,
and

check
their
availability

7.5.4 Discovery
services
via
examples

Discussion:
Interlinking
can
be
implemented
among
many
objects,
also
between
services

and
services.
This
comes
with
many
issues,
e.g.
the
way
services
become
linked.
For

example,
if
a
dataset
contains
data
produced
using
the
available
services,
this
can
be

highlighted
to
guide
the
visitor
to
these
services.

#
Description
Priority

1
Link
from
item
–
Users
can
navigate
from
an
item
that
was
produced
with
a

particular
service,
to
the
service
itself

Medium

Technical
impact:

• There
is
an
identification
mechanism
for
services.

• There
is
a
policy/procedure
for
linking
datasets
with
tools
or
best
practices.

7.5.5 Preservation
of
data

Discussion:
Data
formats
and
data
hosting
are
important
issues
in
the
maintenance
and

long-‐time
preservation
of
collections.
The
standard
format
for
different
types
of
data
is
not

always
defined
in
an
official
way,
and
it’s
important
that
a
collection
be
available
in
the
long

term,
regardless
of
financial
and
data
storage
issues.

ARIADNE
D.13.1
(Public)

38

#
Description
Priority

1
Guidelines
for
data
formats
–
The
user
can
access
documentation
regarding
current

standard
formats,
and
possibly
guidelines
to
convert
them.
The
ARIANDE
portal
also

takes
into
account
the
work
on
G2GP
(Guides
to
Good
Practice)
for
the
description
of

guidelines
on
data
formats
and
preservation
metadata.

Medium

2
Services
for
data
conversion
–
The
portal
may
provide
or
give
access
to
services
for

data
conversion,
in
order
to
homogenize
data
formats
and
ensure
long
term

preservation

Medium

3
Data
Seal
of
Approval
–
ARIADNE
supports
and
incorporates
information
about
the

Data
Seal
of
Approval,
an
international
standard
for
data
repositories
with

requirements
pertaining
to
sustainability,
trustworthiness
and
accessibility.
This

certificate
is
granted
after
inspection
and
indicates
that,
according
to
third
parties,

the
archive
is
a
Trusted
Digital
Repository
(TDR)
and
the
research
data
deposited

there
will
continue
to
be
available
and
sharable
in
the
future.

http://datasealofapproval.org/en/

High

4
Data
storage
–
Some
of
the
services
may
also
provide
storage
for
data
within
the

ARIADNE
service,
so
that
those
with
collections
may
take
advantage
of
it

High

5
Link
to
long-‐term
preservation
services
–
Long-‐term
preservation
is
much
more
than

storage.
Even
if
ARIADNE
itself
does
not
undertake
preservation
(other
than
the

preservation
of
metadata
in
the
repository,
as
described
by
ATHENA
in
Task
12.2),

the
ARIADNE
portal
should
point
users
to
partners
who
could
undertake
preservation

on
behalf
of
others,
i.e.
currently
both
DANS
and
ADS,
and
possibly
SNDS
and
DAI
in

the
future.

High

Technical
impact:

• The
standards
of
data
formats
will
need
to
be
discussed
and
provided.

• The
Ariadne
portal
should
ensure
storing
space
and
long-‐term
availability
of
data.

ARIADNE
D.13.1
(Public)

39

7.6 Prepare
and
register
a
new
collection

This
use
case
describes
how
an
archive
manager
can
add
a
new
collection
to
the
Registry.

Characteristics
Description

Description
This
use
case
describes
how
an
archive
manager
can
prepare
a
collection
to
be

added
to
the
collections
registry

“Trigger”
Valentino
searches
for
the
registry
tool,
in
order
to
understand
if
one
of
his
new

collection
can
be
added
to
the
Ariadne
infrastructure

Preconditions
Valentino
has
ICT
skills

Valentino
is
an
archive
manager

Primary
Actor
Valentino,
in
the
role
of
an
archive
manager

Basic
flow

scenario

Step
1:
Navigate
to
registry
tool
section

e.g.
Valentino
clicks
a
menu
item
on
services

Step
2:
Access
the
documentation
to
prepare
the
collection

e.g.
Valentino
can
access
a
set
of
documents
where
he
can
find
information
about

the
preliminary
preparation
of
a
collection,
He
finds
information
about
the

organization
and
preservation
of
data,
in
order
to
understand
if
modifications
are

needed
before
using
the
registry
tool

Step
3:
Import
the
collection
using
the
Registry
tool

e.g.
Valentino
uses
the
Registry
tool
to
add
the
new
collection
to
the
Registry.

ARIADNE
D.13.1
(Public)

40

7.6.1 Prepare
and
register
a
collection

#
Description
Priority

1
Documentation
–
documentation
about
how
to
prepare
a
collection
and
use
the

Registry
tool
has
to
be
provided

(http://ariadne-‐registry.dcu.gr/manual/The%20ARIADNE%20Registry%20tool_manual.pdf
)

High

2
Feedback
from
portal
manager
–
The
data
providers
have
the
possibility
to
get

feedback
from
the
portal
manager
about
the
good
practice
and
the
possible
issues
in

collection
registration

High

3
Registry
tool

–
The
registry
tool
is
maintained
and
made
available

High

Technical
impact:

• Finalization
of
registry
tool

7.7 Enriching
Visual
Media
Documents

This
use
case
describes
how
a
researcher
like
Valentino
can
provide
an
enriched

visualization
of
visual
media.

Characteristics
Description

Description
Valentino
wants
to
inspect
one
of
the
visual
documents
(an
image,
a
3D
model,
a

video,
…)
stored
in
one
of
catalogues
associated
to
ARIADNE
portal.
He
has

already
selected
(by
means
of
the
search
and
retrieval
interface)
the
specific
visual

media
document
of
interest
for
his
research.

“Trigger”
Valentino
has
discovered
a
specific
visual
document
and
he
would
like
to
know
if

one
or
more
of
the
services
within
the
ARIADNE
portal
can
be
used
to
enrich

visualization.

Preconditions
Valentino
has
general
ICT
skills,
but
does
not
hold
specific
skills
on
visual
media

management
(e.g.
has
not
mastered
the
more
common
data
types,
does
not
have

PC
software
tools
for
working
with
images
of
3D
models
installed
on
his
machine).

Valentino
is
an
archive
manager
and
would
like
to
be
able
to
work
on
his
research

ARIADNE
D.13.1
(Public)

41

using
mostly
web-‐based
resources.

Primary
Actor
Valentino,
in
the
role
of
archive
manager.

Basic
flow

scenario

Step
1:
Valentino
searches
in
the
services
catalogue
by
asking
which
are
the

services
that
could
be
applied
on
his
visual
media
(i.e.
a
3D
Model)

Step
2:
A
visualization
web
window
is
displayed,
showing
the
services
that
could
be

applied
on
the
visual
media.

e.g.
a
list
is
presented,
with
a
short
description
of
the
services,
and
possibly
a

couple
of
example
of
the
effects
of
the
services
on
the
item.

Step
3:
Valentino
can
choose
one
of
the
services;
he
will
be
redirected
to
its
page.

ARIADNE’s
contribution
aims
to
provide
tools
and
technologies
for
improving
the

management
of
visual
data
(images,
3D
models,
geospecific
data)
stored
in
the
archives
of

ARIADNE
partners.

These
functionalities
would
be
implemented
as
resources
available
on
the
ARIADNE
portal

and
will
need
collaboration
with
the
reference
archive
manager
(ARIADNE
will
provide
tools

for
the
management
of
visual
media,
but
the
integration
of
the
results
in
each
current

archive
will
be
implemented
by
the
specific
archive
manager).
The
main
goal
is
moving
from

the
old
approach
(i.e.
where
single
visual
media
is
transferred
to
the
remote
user
as
a
plain

file,
they
have
to
store
it
on
their
PC
and
then
select/install
a
proper
application
to
open
the

file)
to
a
more
modern,
web-‐based
approach
(i.e.
the
presentation
of
the
result
set
of
a

query
to
the
archive
will
be
enriched
by
adding
to
each
result
an
URL
that
will
allow
the
user

to
immediately
inspect
the
visual
media
in
a
standard
web
page).

7.7.1 Conversion
and
publishing
of
3D
models

Description:
the
service
is
accessible
as
a
web
application
that
produces
a
multi-‐resolution

version
of
a
set
of
3D
models,
together
with
a
basic
HTML
visualization
page
of
the
given

models.

ARIADNE
D.13.1
(Public)

42

Input:
one
(or
more)
3D
models
in
one
of
the
standard
formats
(.ply,
.obj,
.stl,
.dae…).

Processing:
The
input
models
are
manually
uploaded
by
the
user
(either
one
at
a
time
or

zipped
in
a
single
file,
in
order
to
reduce
upload
time).
The
service
will
perform
simple

cleaning
operations
(e.g.
removal
of
geometric
artefacts),
will
convert
the
models
in
a
multi-‐
resolution
format
(.nxs),
and
will
create
and
publish
a
simple
webpage
that
will
allow
the

user
to
interactively
visualize
the
models
in
a
WebGL
frame
(no
add-‐ons
needed,
working
on

all
the
main
browsers,
except
on
smartphones
and
tablets
for
now).
The
processing
will
be

based
on
3DHOP
components
(http://vcg.isti.cnr.it/3dhop/
).

All
the
operations
will
be
performed
by
local
scripted
executables
(meshlabserver.exe
for

model
preparation,
nxsbuilder.exe
for
nxs
creation,
a
final
script
to
prepare
the
webpage).

Output:
the
URL
of
a
webpage
on
the
ARIADNE
portal
or
a
zip
file
containing
the
multi-‐
resolution
.nxs
model
and
the
HTML/.js
files
of
the
basic
webpage,
or
both.
The
zip
file
is

available
for
download
by
the
reference
archive
manager.

Notes:
models
with
textures
are
currently
not
supported
by
the
Nexus
multi-‐resolution

format.
A
possible
solution
for
this
could
be
to
add
other
automatic
functionalities
to

transform
them
to
colour-‐per-‐vertex.
Since
the
available
3D
formats
are
too
many,
one
idea

could
be
to
select
4-‐5
of
them
for
support,
as
MeshLab
is
able
to
convert
all
the
main
3D

formats.

Notes
for
implementation
(common
to
all
services
described
in
(a),
(b)
and
(c)):
these

services
require
a
quite
simple
input
stream
(that
will
be
managed
by
simple
web
forms
and

file
transfer).
An
important
consideration
will
be
how
to
estimate
the
required
load
for
the

platform(s)
it
runs
upon
(including
defining
specifications
for
processing
power,
disk
size,

transmission
throughput
expected
for
the
server).
In
order
to
define
the
level
of
resources
it

may
consume
and
prevent
bottlenecks
in
future
use
(i.e.
whether
it
may
kill
the
platform
if

its
requested
by
too
many
users
simultaneously)
more
data
should
be
gathered
from

potential
ARIADNE
contributors.
This
activity
will
be
done
as
soon
as
the
status
of
the

specification
is
consolidated.

ARIADNE
D.13.1
(Public)

43

7.7.2 Conversion
and
publishing
of
RTI
Images

Description:
the
service
converts
re-‐lightable
images
into
webRTI,
and
produces
a
basic
html

visualization
page
for
the
given
images
(i.e.
a
version
of
the
image
that
can
be
transmitted

on
the
web
and
visualized
efficiently
on
a
standard
web
page).

Input:
one
(or
more)
RTI
images
in
the
standard
formats
(.ptm
or
.hsh).

Processing:
input
images
will
be
uploaded
to
the
service
available
on
the
ARIADNE
portal,
or

automatically
collected
in
a
batch
(it
will
also
be
possible
to
automatically
compress
them,
in

order
to
reduce
upload
time).

The
service
will
transform
each
image
in
a
web
compliant
format
(similarly
to
Google
Maps,

the
image
will
be
divided
into
chunks
of
different
resolution),
and
create
a
simple
webpage

where
it
will
be
possible
to
navigate
the
model
in
a
WebGL
frame
(no
add-‐ons
needed,

working
on
all
the
main
browsers,
except
smartphones
and
tablets
for
now).
The
processing

will
be
based
on
the
components
of
WebRTI
viewer

(http://vcg.isti.cnr.it/~palma/dokuwiki/doku.php?id=research
).

All
the
operations
will
be
performed
by
local
scripted
executables
(WebRTIBuilder.exe
for

the
processing
of
the
image,
a
final
script
to
prepare
the
webpage).

Output:
a
webpage
already
published
on
the
ARIADNE
server
(in
this
case
only
the
URL
will

be
returned
to
the
reference
archive
manager)
and/or
a
.zip
file
to
download,
containing
the

processed
image
and
the
HTML/.js
files
of
the
basic
webpage.

7.7.3 Conversion
and
publishing
of
high
resolution
images

Description:
the
service
converts
high-‐resolution
images
(uploaded
using
standard
image

formats)
into
multi-‐chunk
versions,
enabling
progressive
transmission,
and
produces
a
basic

HTML
visualization
page
of
the
converted
images.

ARIADNE
D.13.1
(Public)

44

Input:
one
(or
more)
high-‐res
image(s)
in
standard
formats
(.jpg,
.png,
.tiff…)

Processing:
Input
images
will
be
uploaded
to
the
service
available
on
the
ARIADNE
portal,
or

automatically
collected
in
a
batch
(it
will
also
be
possible
to
automatically
zip
them,
in
order

to
reduce
upload
time).

The
service
will
transform
the
image
into
a
web
compliant
format
(similarly
to
Google
Maps,

the
image
will
be
divided
into
chunks
of
different
resolution),
and
create
a
simple
webpage

where
it
will
be
possible
to
navigate
the
image
in
a
WebGL
frame
(no
add-‐ons
needed,

working
on
all
the
main
browsers,
except
on
smartphones
and
tablets
for
now).

All
the
operations
will
be
performed
by
local
scripted
executables
(an
executable
for
the

processing
of
the
image,
a
final
script
to
prepare
the
webpage).

Output:
a
webpage
already
published
on
the
ARIADNE
server
and/or
a
.zip
file
to
download,

containing
the
processed
image
and
the
HTML/.js
files
of
the
basic
webpage.

Notes:
as
there
are
a
lot
of
image
formats,
it
is
advised
to
only
choose
the
main
ones,
but

this
also
depends
on
the
types
found
in
the
collections.

7.7.4 2D
Maps
Visualization
component

This
component
will
be
developed
through
a
responsive
HTML5
(similar
to
Google
Maps)

component
that
can
be
integrated
with
search
query
results.
The
online
portal
will
also

suggest
accessing
and
using
the
ARIADNE
web-‐based
terrain
generator,
and
to
perform

further
searches
on
geoimages
and
DTM
(within
the
ARIADNE
portal
or
a
suggested
global

geo-‐database
-‐
i.e.
Global
Land
Cover
Facility).

Description:
The
front-‐end
component
should
be
based
on
responsive
HTML5
and
PHP
to

visualize
specific
areas
with
list
of
hotspots
(i.e.
obtained
from
search
queries).

Requirements:
geographical
extents
and
hotspot
coordinates.

Status:
PHP
service
and
HTML5
Front-‐End
to
be
developed.

ARIADNE
D.13.1
(Public)

45

7.8 Manage
accounts

This
use
case
describes
how
a
security
manager
can
execute
operations
to
handle
and

control
authentication
and
access.
A
security
manager
like
Christopher
wants
to
have
an

overview
of
the
users,
and
eventually
change
their
attributes.

Characteristics
Description

Description
Christopher
was
asked
(via
a
message
through
the
portal)
to
modify
the
access

attributes
of
a
user.

“Trigger”
Christopher
accesses
the
area
of
the
portal
that
is
dedicated
to
security
managers.

Preconditions
Christopher
has
ICT
skills

Christopher
is
a
security
manager

Primary
Actor
Christopher,
in
the
role
of
a
security
manager

Basic
flow

scenario

Step
1:
Navigate
to
the
user
accounts
list

e.g.
Christopher
navigates
to
the
user
accounts
résumé

Step
2:
Check
the
attributes
of
an
account

e.g.
Christopher
selects
the
account.
The
portal
provides
a
short
description,
with

the
current
attributes
that
have
been
enabled.

Step
3:
Modify
and
add
attributes

e.g.
Christopher
accesses
the
account
information.
He
enables
the
requested

attribute,
saves
the
changes
and
sends
a
message
to
the
user,
confirming
the

update
of
the
account.

ARIADNE
D.13.1
(Public)

46

7.8.1 Navigate
and
search
accounts

#
Description
Priority

1
Navigation
–
The
security
manager
can
navigate
and
access
the
accounts
list
High

2
Search
–
The
portal
enables
the
search
for
the
accounts,
following
different
types
of

queries
(e.g.
name,
attribute,
date)

High

Technical
impact:

• A
data
infrastructure
and
a
set
of
Security
Facilities
are
needed

7.8.2 Visualize
and
change
attributes

#
Description
Priority

1
Visualization
of
an
account
–
The
portal
enables
the
visualization
of
the
account

information
for
each
user,
and
the
list
of
enabled
attributes

High

2
Attribute
enabling
and
disabling
–
The
portal
allows
the
security
manager
to
enable

and
disable
attributes
for
each
account

High

3
Automatic
messaging,
interaction
with
users
–
The
security
manager
will

automatically
contact
the
users
each
time
their
account
is
updated.
The
users
can

take
advantage
of
a
contact
form
to
request
changes
and
clarifications.

Medium

Technical
impact:

• Mechanisms
for
handling
the
user
access
have
to
be
developed
and
maintained

8 Service
design
model

The
service
design
model
below
supports
the
use
case
descriptions.
It
is
the
starting
point

for
the
implementation
phase.
The
use
cases
in
this
document
describe
the
process,
and
the

usability
experts
have
given
suggestions
on
how
best
to
realise
this.

ARIADNE
D.13.1
(Public)

47

Descriptions
of
terms
used
in
the
service
design
model
diagram:

Discover
=
search
and
browse

Distributed
search
=
when
an
external
search
portal
automatically
searches
within
the

ARIADNE
portal

Ingest
=
input
of
(meta)data

Retrieval
=
downloading

Prepare
for
harvest
=
make
set/collection
ready
for
harvesting

Laura
=
archaeologist,
user
of
ARIADNE
portal

Ext
harvester
=
external
harvester,
e.g.
Europeana

DP1=
One
of
the
ARIADNE
Data
Providers

Mapping
1
=
translation
between
data
model
of
data
provider
and
Ariadne
data
model

Ariadne
ontology
=
Ariadne
data
model

Ext
rep
1
=
external
repository

Class
DB=
classification
database

ARIADNE
D.13.1
(Public)

48

PMH
endpoint

=
pmh
endpoint

Sem
Rel
DB=
Semantic
Relation
Database

Index
=
searchable
metadata

Raw
metadata
=
metadata
of
the
data
providers

Store
=
everything
in
store
and
not
searchable
in
index
(e.g.
data
files)

The
use
cases
presented
within
this
deliverable
will
be
supported
by
an

services/infrastructure
arhitecture
like
the
one
presented
in
the
following
diagram.
In
this

diagram,
the
ARIADNE
Catalog
is
depicted
as
the
heart
of
the
system,
along
with
its
data

access
layer.
The
catalog
will
act
as
a
glue,
serving
ACDM
formated
records
across
all

users/providers.
All
data
will
be
available
through
the
ARIADNE
portal,
which
will
provide

users
with
digital
asset
management
tools.
The
various
resource
discovery
elements
(for
use

with
datasets,
archives,
tools)
along
with
the
integration
and
interoperability
services
all

have
important
roles
to
play.
Finally,
preservation,
quality
and
integration
services
will

provide
the
added
value
that
users
require.

ARIADNE
D.13.1
(Public)

49

The
main
technologies
that
will
be
used
within
the
architecture
are
REST
based
services
(in

order
to
glue
all
components
together),
with
RDF
and
SPARQL
to
encode
the
metadata
and

provide
a
standard
mechanism
for
querying
the
graph-‐based
data.

9
Synthesis

D13.1
aims
to
specify
the
service
design
of
the
ARIADNE
Portal.
It
aims
to
provide
a
common

vision,
a
user
perspective
on
the
functionality,
and
a
framework
to
identify,
discuss
and

validate
the
requirements
for
the
underlying
technical
services.

The
service
design
Task
13.1
is
created
using
the
following
input:
Description
of
Work,
Task

2.1
(Survey
of
users’
needs
and
community
building),
Task
12.1
(Assessment
of
use

requirements),
and
WP3-‐12-‐13
Workshop
discussions.

The
stakeholder
survey
D2.1
allows
the
detailing
and
prioritization
of
the
functionality
of
the

service
design
D13.1.
The
expressed
wishes
can
be
clustered
together
within
five
main

categories
of
user
needs:
data
transparency,
data
accessibility,
metadata
quality,
data

quality,
and
the
international
dimension.

D12.1
formulates
user
requirements
on
Data,
requirements
on
Metadata
Standards,

Schema’s
and
Vocabularies
and
requirements
on
Access
and
Sharing
Policies.

The
topic
of
access
will
be
part
of
the
further
strategic
work
within
D2.2.
Second
report
on

users’
needs.
“Lead
users”
will
be
asked
to
evaluate
a
number
of
portals
to
identify
where

and
how
various
needs
and
requirements
are
met
(or
not
met),
including
examples
of

existing
innovative
approaches,
and
further
ideas
on
specific
services
or
features
the

ARIADNE
user
community
may
appreciate.

D13.1
provides
a
common
vision
formulated
in
terms
of
principles,
derived
from
the
mission

statement
in
the
Description
of
Work.
Different
users
(data
consumer,
data
producer,
portal

manager,
archive
manager)
and
how
their
work
relates
to
the
different
phases
of
the

research
data
lifecycle
are
described.
The
functionality
will
be
specified
from
a
user

perspective.
The
requirements
of
the
ARIADNE
portal
will
be
based
on
use
cases,
to
ensure

requirements
are
defined
to
support
the
users.
This
was
done
by
first
defining
the
users
(or

actors)
and
their
interaction
with
the
services
(their
scenarios),
broken
down
into
clear

ARIADNE
D.13.1
(Public)

50

steps.
This
allowed
structured
analysis,
discussion
and
prioritization
of
the
requirements
for

the
services
to
the
end
users,
as
well
as
the
technical
components
that
should
enable
these

services
(like
the
ARIADNE
Catalogue
Data
Model).
The
activities,
their
steps
and
derived

requirements
were
prioritized
(High,
Medium,
Low)
in
order
to
ensure
a
realistic
and

pragmatic
end-‐result
for
the
project.

A
separate
section
of
the
document
presents
possible
components
for
visual
media.
The

section
on
the
service
design
model
offers
a
view
of
the
overall
services
architecture
of

ARIADNE.

It
is
the
starting
point
for
the
implementation
phase.
The
use
cases
in
this

document
describe
the
process,
,
but
advising
the
usability
expert
to
give
suggestions
how

best
to
realise
this.
The
service
design
will
provide
input
for
Task
12.2
(Infrastructure

Design),
Task
13.2
(Build
Services)
and
later
on
Task
13.4
(Acceptance
testing).

The
ARIADNE
registry
service
is
developed
within
WP3-‐12-‐13
and
uses
the
ARIADNE

Conceptual
Data
Model
(ACDM).
Ingesting
the
metadata
into
the
registry
will
make
it

possible
to
evaluate
this
service,
and
to
see
if
adaptations
of
the
model
are
necessary
to

support
the
described
use
cases
described
in
Deliverable
13.1.

10
References

Ariadne
Description
of
Work”-‐
DoW

Ariadne
deliverable
D2.1
“First
report
on
Users’
Needs”
http://ariadne-‐
infrastructure.eu/Resources/D2.1-‐First-‐report-‐on-‐users-‐needs

Ariadne
deliverable
D12.1
“Use
Requirements”
http://ariadne-‐infrastructure.eu/Resources/D12.1-‐
Use-‐Requirements

ARIADNE
website:
www.ariadne-‐infrastructure.eu

D13.1 ARIADNE Service Design

More Related Content

Viewers also liked (14)

Similar to D13.1 ARIADNE Service Design (20)

More from ariadnenetwork (20)

Recently uploaded (20)

D13.1 ARIADNE Service Design