►
From YouTube: 2018-11-06 : DSpace 7 Entities Working Group Meeting
A
A
A
That'll
be
the
second
half
of
the
meeting.
Excuse
me,
but
before
we
jump
into
that,
just
jumping
back
to
our
entities
working
group.
Let
me
pump
this
up
here
page
and
noting
kind
of
our
timelines
here,
so
we
obviously
are
already
into
November,
and
we
have
our.
We
did
the
initial
some
initial
assessment
of
the
early
prototype
and
now
we're
kind
of
have
the
code
to
start
to
work
towards
in
terms
of
actually
getting
a
pull
request
ready
for
dspace
seven,
so
we're
kind
of
moving
along
within
our
timeline.
A
But
I
will
note
that
and
I'm
going
to
keep
having
coffee,
because
it
seems
I
apologize
here.
I
will
note
that,
in
terms
of
our
timeline,
some
of
the
actual
goals
are
a
little
bit
still
up
in
the
air.
Before
the
end
of
November.
We
would
still
love
to
have
an
actual
pull
request
ready
to
go
for
dspace.
Seven,
if
that's
possible,
based
on
our
current
trajectory.
I,
am
personally
not
sure
whether
or
not
we'll
be
to
that
by
the
end
of
November,
but
we'll
see
how
things
progress,
especially
between
this
meeting
and
next
meeting.
A
But
I
did
want
to
note
that
the
current
timelines
for
D
space
7,
just
in
general,
are
under
discussion
by
the
D
space
governance
by
a
leadership
in
steering.
So
it's
worth
kind
of
noting
that
I
don't
recall
if
I
went
through
this
in
this
last
in
the
last
minute,
I
believe
I
did
but
I'm
in
so
many
D
space,
medians
and
I
talk
through
this
so
many
times
and
I'm
kind
of
losing
track
of
where
I've
discussed
this
and
where
I
have
not,
but
a
essentially
the
D
space.
A
Steering
group
and
D
space
leadership
group
have
been
talking
around
whether
or
not
to
have
an
early
sort
of
preview
or
alpha
release
of
D
space
7
before
the
end
of
this
year.
That
decision
is
still
not
yet
been
made
as
of
today,
although
there
is
a
leadership
group
meeting
tomorrow,
where
we'll
probably
discuss
that
in
a
little
bit
more
detail.
A
However,
it's
been
made
very
clear
by
myself
and
through
discussions
within
the
steering
group
that
if
we
go
down
this
path
of
having
some
sort
of
preview
release
of
these
space
7
before
the
end
of
2018,
that
that
release
is
not
going
to
be
feature
feature
complete.
We
won't
have
all
the
features
ready
by
the
end
of
2018
and
that's
just
the
reality
of
where
we
currently
sit
and
based
on
our
current
sort
of
development
and
encode
review
processes.
A
A
Not
here
in
any
so
what
are
our
basic
trajectories
to
keep
moving
forward
as
quickly
as
we
can
and
see
how
quickly
we
can
kind
of
get
configurable
entities
done
and
over
the
next
couple
weeks,
I'll
be
bringing
this
sort
of
our
progress
back
to
steering
and
we'll
have
a
very
good
picture
of
how
quickly
we're
able
to
move
on
this
and
whether
or
not
well
we'll
have
something
in
2018
or
whether
it's
much
more
likely
that
it'll
be
in
early
2019.
So
we'll
just
see
how
we
move.
A
Excuse
me
so
so
the
first
topic
of
this
agenda
is
really
to
kind
of
get
some
initial
feedback
on
the
on
the
entities,
pull
requests
that
have
come
about
and,
as
I
had
noted,
I
saw
that
there's
feedback
from
alexander
mark
and
myself
on
the
rest
api
side.
So
we
might
be
able
to
kind
of
give
just
some
general
discussion
on
the
feedback
there
so
far.
The
sense
that
I
got
just
to
sort
of
summarize
things,
maybe
I'll
share
my
screen
just
so
everybody
doesn't
have
to
bring
this
up.
A
A
If
we
scroll
down
here
I
know,
a
lot
of
the
comments
were
pretty
pretty
minor
overall,
so
I
don't
think
we
need
to
go
through
every
single
comment
and,
as
alexander
noted
here,
he
did
some
actually
test
the
code.
A
compiled
test,
succeeded
and
and
then
made
some
inline
comments
within
things
and
I'm
not
going
to
go
through
the
minor
things
that
Ben
has
already
responded
to
here,
because
some
of
these
are
very
code.
A
Specific
I
think
the
main
point
I
wanted
to
get
to
was
more
around
a
lot
of
this
is
just
minor
things
that
we
can
clean
up
with
in
the
process.
So
I
think
there's
two
main
points.
One
is
around
the
fact
that
there
is
a
lot
of
test
data,
that's
embedded
within
the
pull
request
itself,
which
is
good
for
folks
who
want
to
to
test
it.
So
there's
like
scripts
that
will
actually
create
test
data
for
us
to
allow
us
to
actually
interact
with
it
locally.
A
So
whether
or
not
we
start
to
pull
that
out
now
or
whether
we
pull
it
out
before
we
put
it
into
D
space
I,
don't
think
it
matters
too
much
to
me
of
just
as
long
as
we
know
where
this
test
data
all
sits
so
that
we
don't
accidentally
leave
some
of
it
around
once
we
merge
it
into
D
space
I.
Think
that's
one
point:
I
wanted.
B
Even
know
tear
that
one
verifying
the
script
in
detail.
It
doesn't
seem
to
the
entire
time
I
had
in
mind,
so
it's
incomplete,
so
I
think
I
don't
want
you
to
already
have
to
delete
it
and
check
out
a
different
way
to
make
sure
that
there's
some
kind
of
test
easily
verify
functionality,
because
or
as
I
can
see
it's
not
something
you
can
just
run
and
have
test
data.
In
your
repository.
A
A
Things
like
yeah
mapping
to
specific
handles
collection,
handles
and
stuff
of
that
nature.
Unfortunately,
we'd
probably
have
to
remove
some
of
that
and
maybe
provide
it
externally,
maybe
there's
a
place.
We
can
just
add
these.
If
there's,
if
we
find
a
way
to
create
that
test
data
and
add
this
configuration
in
a
wiki
page
or
something
of
that
nature,
that
might
be
an
easier
place
to
to
make
that
all
work
together.
I
don't
know
the.
C
Idea
was
to
remove
all
of
the
demo
data
of
when
we
would
merge
into
the
master
branch
and
then
create
a
new
set
of
demo
data.
If
you
would
compared
this
to
what
you
now
see
in
the
antes
prototype
live
installation
that
we
have
running
that
the
document
refers
to.
We
added
some
better
examples
and
we
will
provide
those
in
like
a
CSV
import
format,
so
you
can
just
easily
download
a
CSV
import
it
and
and
some
configuration
files
like
the
submission
and
things
like
that.
C
A
I
think
that's
that's!
Okay,
as
long
as
we
know
how
to
use
this
to
test
things
like
I,
don't
if
we
can't
create
the
data
that
we
need
to
make
these
handles
work,
then
it's
not
useful,
that's
kind
of
my
point,
but
if
the
data
is
easy
to
create,
then
then
I'm,
okay
with
leaving
this
around,
but
it
sounds
like
what
Ben
and
said
is
that
it's
not
really
working
right
now
anyways.
A
A
So
that's
the
one
point
I
think
the
only
other
main
point
is
is
really
one
that
mark
made
around
the
idea
of
of
an
entity
the
entity
object,
class
and
the
fact
that
it
was
surprising
to
him
that
entities
in
the
the
entity
object.
Class
is
more
of
a
utility
class
and
it's
not
actually
an
object,
so
he
he
noted
that
he
was
surprised
that
entity
is
not
actually
a
subclass
of
item
and
that
instead,
we've
always
been
talking
about
how
an
entity
is
an
item.
C
There's
also
a
response
to
that
as
yeah.
So
the
thing
is
that
that
class
shouldn't
have
been
named
entity.
It
was
just
a
poorly
chosen
name
and
our
preference
at
the
moment,
because
we
discussed
this
before
this
call
would
actually
need
be
to
move
these
methods
to
the
item
to
the
item
class
because
that's
where
they
belong
items
can
have
relations
and
they
should
be
in
the
item
class
and
a
subclass
of
the
item
class
is
not
necessarily
the
best
design
from
remarks
point
of
view.
C
A
A
That
is
an
entity
in
terms
of
the
word
entity
may
not
have
any
meeting
within
within
the
code
base,
which
means
we
also
may
want
to
look
where
it's
used
elsewhere.
So
is
there
like
I?
Think
the
other
example
is
entity
type
there.
A
database
table
named
entity
type
and
an
object
named
entity
type.
Does
that
still
remain
the
name
entity
type?
If
we
remove
the
idea
of
an
entity
out
of
the
codebase
area,
so
it's
something
to
consider
like
whether
that
needs
to
now
be
an
item
type.
A
Essentially,
if
everything
is
now
an
item
and
we're
just
kind
of
dropping
the
conceptual
object,
that
is
an
entity,
at
least
in
this
code
base
area
and
Kobes
layer,
and
that
also
then
bubbles
to
things
like
the
rest
api.
Whether
or
not
you
actually
have
an
endpoint
that
is
called
entity
and
things
of
that
nature.
So
I
just
want
to
note
that
there
is
an
implication
around
what
we
do
here
and
I.
Don't
know
whether
you've
kind
of
thought,
through
the
full
implication
here
or
whether
you're
just
kind
of
looking
at
this
one.
C
We
were
just
looking
at
this
one
scenario:
no,
but
we'll
take
a
look
at
that
and
I
mean
I
think
it
is
best
to
have
consistent
use
of
terminology
yeah,
so
yeah
well,
we'll
take
a
look
at
all
those
things
and
and
and
let
you
know
what
we
think
is
the
the
easiest
way
to
go.
Unless
you
have
a
strong
preference
to
say,
I
want
everything
to
be
named
with
item
or
item
type
and
not
entity.
A
A
So
I
think
that
the
trajectory
has
been
that
entities
really
are
just
items
that
have
a
type
and
in
that
situation
it
makes
sense
to
me
to
just
call
them
items
if
we
want
to,
but
if
there
is
some
scenario
that
I'm
not
thinking
of
where
it
makes
more
sense
that
they
actually
there
is
an
entity
object,
then
I'm,
not
against
that
I.
Just
want
us
to
have
consistency.
Does
that
make
sense?
Yeah.
A
A
A
What
I
would
lean
towards
is
just
calling
it
item
type
or
seeing
if
that
item
type
table
also
I
know
there
was
questions
early
on
as
to
whether
that
should
really
just
be
a
column
on
the
item
table
I
don't
know,
but
for
now
the
simple
solution
would
be
to
yeah.
Just
call
it
item
type.
If
we're
naming
everything
else
item,
then,
let's
be
consistent
and
really
kind
of
almost
scrub.
A
The
word
entity
from
everything
at
the
Java
layer,
which
would
also
probably
imply
that
it
also
gets
scrubbed
from
the
rest
API
layer,
because,
if
everything's
an
item
then
the
rest
api
is
just
talking
about
items
as
well,
but
I
don't
know
the
implication
of
that.
So
I'm
just
I'm
noting
that
that
that
seems
like
a
reasonable
direction,
but
we
need
to
look
at
the
implication
of
whether
or
not
there's
anything
that
we
can't
really
scrub.
The
word
entity
off
of.
C
Yeah
we'll
do
a
review
of
everything
in
the
code
in
the
database
and
make
a
proposal
by
next
week
for
more
consistency,
but
we'll
hold
off
on
refactoring
all
those
things
until
the
review
is
done
and
just
take
that
as
like
a
feedback
point,
it
has
to
be
processed
before
it
goes
into
the
master
branch.
But
we'll
have
a
proposal
for
that
by
next
week.
Okay
enjoy
sorry
yeah.
A
That
sounds
good
yep
and
it
makes
perfect
sense
to
not
necessarily
keep
changing
this
pull
request
until
all
the
feedbacks
done
so
and
I
think
the
overall
feedback,
the
overall
perception
I
got
was
was
good
feedback.
I
think
this
was
the
most
confusing
point
and
I
think
it
was
a
good
point
of
mark
noticing
that
miss
naming,
which
kind
of
made
me
rethink
all
this
myself.
A
D
A
D
A
Yeah,
it
does
kind
of
require
getting
the
rest
side
up
and
running
first
just
so,
you
can
kind
of
run
the
rest
api
locally,
I'm
and
then
point
the
angular
side
at
that,
but
but
but
yeah
would
still
be
useful.
Although
I
guess
is
there
a
demo
rest
api
that
has,
I
guess
there
is
a
demo
rest
api
that
we
could
potentially
review
the
angular
side
against
correct
sleeve
in
and
then
maybe
there's.
B
B
A
A
So
if
we
tweak
that
configuration
which
I
need
to
find
myself,
we
can
add
instructions
under
that
angular
pull
request
to
to
note
the
configuration
and
what
you
can
update
it
to
in
order
to
use
the
at
meyer
demo
site,
because
that
would
essentially
allow
you
to
not
even
need
to
run
the
rest
api
locally.
You
can
just
install
the
angular
pull
request,
bring
it
up
and
running
and
it'll
use
that
demo
rest
api
behind
the
scenes
and
allow
you
to
to
test
it
out
and
play
with
it.
A
A
A
A
Okay,
now
here's
the
config
file
added
into
the
entities
working
group
channel,
it's
the
environment
default
Jas
and
there's
a
section
for
that
rest
API.
So
if
we
just
update
the
host
information
and
the
namespace
information
there,
the
path
information
there
that
should
work
to
point
at
the
the
at
Meier
demo,
REST
API
for
entities.
A
A
This
is
an
area
that
I
could
really
use
help
and
in
this
review
process,
I'll
also
try
and
get
to
the
angular
pour
request
review
here
over
the
next
week,
but
the
more
eyes
we
can
get
on
just
testing
that,
even
if
you
don't
understand
angular
code,
so
well,
if
you
can
give
it
a
test,
see
how
it's
behaving
and
all
of
that
or
ask
questions.
I
think
that
would
all
be
very,
very
useful
feedback
into
this
process.
But
is
there
any
other
information
anybody
else
wants
here
before
we
close
up
this
particular
topic.
A
Hey
not
hearing
any
so
in
that
case
we'll
go
ahead
and
move
along
to
the
second
topic
on
the
agenda,
and
that
would
be
the
journal
hierarchy
use
case.
Our
initial
use
case
description
and
comparing
that
to
the
original
implementation
that
exists
within
those
those
pull
requests,
and
so
this
is
specific
to
the
journal
hierarchy.
A
Use
case
we're
not
yet
looking
at
the
author
profile
use
case
that
second
use
case
we
had
talked
about
just
because
we
want
to
tackle
one
at
a
time
and
in
each
one
may
provide
a
good
number
of
discussion
points,
but
but
leave
and
I
might
hand
this
over
to
you
here
to
kind
of
walk
through
what
is
sort
of
implemented
versus
what
is
not
implemented
and
I.
Think
the
more
important
part
is
trying
to
get
to
to
where
those
gaps
may
be.
C
So
it's
basically
a
copy
of
your
use
case
points.
So
it
starts
with
the
first
like
five
or
so
points
in
your
use
case.
John
can
be
represented
on
journal,
page,
etc,
etc.
Then
you
have
a
little
bit
below
the
her
icky
users
story
or
it's
more
like
a
narrative
and
then
at
the
end,
there's
a
reference
there,
reference
to
where
the
code
and
the
configuration
is
and
exactly
the
dot.
The
original
documentation
is
because
that
already
included
those
two
use
cases
to
a
certain
extent
and
then
at
the
bottom.
C
C
This
is
a
journal
hosted
in
a
bprous
digital
Commons
and
you
can
browse
through
the
volumes
and
the
issues,
and
we
have
duplicated
the
volume
7
issue
1
and
issue
it's
all
of
its
articles,
so
you
can
drill
down
into
the
volume
you
can
drill
on
to
the
issue,
and
then
you
have
the
articles
in
an
overview
and
then
can
click
on
an
article
to
get
the
metadata
and
to
download
it's
not
so
that
has
been
replicated.
So
here
you
have
a
journal
of
financial
therapy
item
page.
C
You
see
here
at
the
top
the
two
volumes
that
are
associated
with
that
particular
journal.
You
can
go
into
the
first
volume.
You
have
the
two
issues
same
way
as
and
the
other,
as
in
the
B
press
example,
and
you
can
go
into
volume,
7
issue
1
and
then
you
have
your
list
of
articles
in
this
case
without
thumbnails
be
good
after
thumbnails
with
their
abstracts
and
everything.
And
then
you
can
go
into
a
particular
article
and
you're
on
the
landing
page
of
that
article,
and
then
you
can
go
back
up
into
the
volume.
C
I
sorry
into
the
issue
into
the
volume
and
back
up
into
the
journal,
so
it
has
the
same
hierarchy
with
a
little
bit
of
richer
metadata
than
what
you
saw
in,
for
example,
this
page
here
with
the
volume.
So
it
has
the
journal
level
metadata
it
has.
The
logo
has
a
stipulated
in
the
use
cases.
It
has
a
list
of
all
journal
volume
sorted
by
volume
number,
as
you
saw
here
so
volume
7
comes
before
volume
8.
We
could
have
turned
that
around
and
have
the
more
recent
at
the
top.
C
But
the
list
is
not
paginate,
because
in
your
original
use
case
it
said
agitated
list
of
all
journal
volume
sorted
by
volume,
number
or
date,
but
also
searchable,
and
this
goes
into
a
discussion
at
the
bottom,
but
about
how
do
we
display
a
relation?
Because
in
this
original
use
case,
it
always
said
sordid
but
also
searchable
and
then
and
some
other
ones,
paginate,
'add
belief
that
was
in
the
issue
paginating
list
of
all
articles
in
the
journal,
sorted
by
page
number,
but
also
searchable.
C
C
For
example,
in
this
case,
the
issues
there
are
only
two
in
this
volume,
so
Beijing
searching,
is
not
really
useful
and
even
within
the
issue,
the
number
of
articles
is
quite
limited
and
you
can
see
in
their
example
as
well
that
there's
just
an
overview
and
you
can
search
into
in
a
journal
or
across
the
entire
repository.
But
having
a
search
here
might
be
overkill.
C
Pea
pagination
could
have
been
useful
here,
but
we
have
a
proposal
at
the
bottom
of
the
document
about
how
we
can
have
cutoff
points
for
an
configuration
for
specific
item
types
and
it's
try
to
stop
using
the
word
entity.
Item
types
to
say:
okay,
know
for
this
item:
type:
I,
don't
want
it
to
be
in
a
search
or
pagination,
even
though
there
might
be
more
than
X
relations,
for
example.
C
So
then
I
also
showed
you
the
volume
page
already.
The
same
I'm
linking
to
the
same
displayed
for
relations
discussion
section
here,
then
you
have
the
journal
issue
and
there
a
small
comments
about
a
bug
that
is
the
virtual
metadata
from
the
journal
and
the
volume
was
requested
here.
And
if
we
look
at
the
issue
page,
the
data
from
the
journal
volume
is
here,
but
not
from
the
journal
itself.
A
Not
to
stop
here
Levant,
but
real,
quick.
Just
to
note
I
can't
see
all
these
comments
that
you
have
on
your
screen
when
I
look
at
this
particular
document
and
I.
Think
it's
because
you
only
gave
us
a
few
rights
so
I'm.
Just
noting
that
I
think
these
comments
add
some
useful
context.
That
I
was
not
aware
of
when
I
first
reviewed
this,
because
I
can't
see
them.
Okay,
I
will.
C
All
right
don't
take
a
look
at
that
and
that's
basically,
the
commented
reoccurs
on
the
other
levels
as
well.
Of
course,
like
in
the
article
page,
the
journal,
title
and
Isis
and,
and
volume
number
is
not
included
only
the
issue
numbers,
so
everything
that's
a
second
or
third
level
relationship
needs
to
be
fixed,
make
sure
how
to
describe
the
various
entities
created
that
was
already
included
in
our
original
documentation
of
how
you
create
a
data
model
with
the
XML,
etc,
etc.
So,
I
put
a
link
there
to
the
original
documentation
same
for
virtual
metadata.
C
C
Then,
with
the
user
stories,
so
this
explains
a
bit
more
like
your
community
collection
structure
and
how
what
you
do
when
a
new
issue
is
published
and
how
you
can
submit
things
might
be
interesting
to
note
that
we
have
done
submission
through
display6
xml
UI.
So
we
install
that
on
top
of
the
D
space
7
database,
and
we
just
used
that
for
submission
at
the
moment.
So
it
is
possible
to
submit
these
through
a
user
interface,
I'm
just
not
from
the
D
space
7
user
interface.
C
Yet
so
those
examples
have
actually
been
submitted
through
a
user
interface,
but
at
least
a
six
one.
So
that
shows
that
the
concept
does
work
and
that
it
also
is
very
much
in
line
with
how
D
space
has
worked
so
far
like
that.
We
can
use
the
D
space
6
to
do
that.
I
think
there's
much
to
discuss
here.
Just
read
it
in
detail
at
some
point.
If
you
have
any
comments,
feedback
suggestions
feel
free.
C
C
C
That
would
allow
sufficient
control
from
both
sides
right.
So,
if
I
attach
an
article
to
a
journal
issue
that
I
shouldn't
have
attached
it
to
then
at
least
the
person
who's
in
charge
of
the
journal
issue
submitted
that
can
unlink
it.
It's
not
the
perfect
situation,
but
it
would
be
a
workable
situation.
It
also
would
work
for
author
profiles,
but
in
a
section
permissions
on
relations
were
discussing.
C
That
has
in
a
bit
more
detail
where
you
actually
could
have
a
particular
permission
that
is
attached
to
a
relation
that
can
determine
whether
or
not
it
can
be
deleted,
or
things
like
that.
So
that's
a
discussion
point.
That's
that
there
should
be
able
to
submit
a
partial
issue
and
submit
additional
articles
at
a
later
time.
C
C
The
situation
there
is
that,
since
you
know
we're
talking
about
items
and
not
entities,
so
they're
all
items,
an
embargo
can
be
applied
to
each
of
those,
so
it
can
be
applied
to
the
issue
it
can
be
applied
to
all
of
the
articles,
but
it
doesn't
automatically
propagate
through
the
hurricane.
So
if
you
apply
an
embargo
to
the
issue,
it
doesn't
necessarily
propagate
to
the
articles
of
the
issue,
but
you
could
do
it
for
each
individually
and
set
it
to
the
same
embargo.
Date.
C
Alternatively,
you
can
also
let
everything
sit
in
the
word
flow
and
only
like
give
them
the
final
approval
when
everything
can
be
released.
So
I
think
there
are
two
alternatives,
and
we
would
argue
that,
currently,
it's
not
really
it's
more
convenience
to
be
able
to
have
it
propagate
through
the
hierarchy
and
it's
something
that
can
be
quite
easily
added
later
on.
A
Yeah
I
think
that's
a
that's
probably
another
discussion,
point
I
think
to
be
honest,
I
think
we
should
add
that
as
another
point
of
discussion,
because
I
think
that
becomes
important
to
make
it
easy
to
work
with
embargoes,
especially
if
you're
in
debt,
but
it
may
depend
on
the
submission
process.
So,
if
you're
having
to
submit
each
of
these
objects
individually,
then
yeah,
maybe
just
having
each
have
an
individual
embargo
is
good
enough
for
now.
A
But
if
there's
a
way
to
submit
an
issue
with
all
of
its
articles,
then
you
really
need
to
be
able
to
embargo
all
of
them
at
once.
So
but
I
know
we
don't
have
the
submission
all
figured
out.
So
I
think
this
is
a
possible
discussion
point
for
the
future,
but
we
need
to
kind
of
look
at
the
submission
process.
I.
C
C
Yeah,
there's
only
one
other
point,
so
Serge
yeah.
We
still
need
to
add
a
search
through
all
the
articles
in
the
journal,
because
that
is
dependent
on
the
second
and
third
level
of
virtual
metadata.
So
we
need
to
add
identifier
of
the
journal
to
the
article
through
virtual
metadata,
in
order
to
provide
that
search,
but
that's
also
been
scheduled
already
so
that
shouldn't
take
long.
C
See
yeah
the
same
discussion,
maybe
also
should
be
a
discussion
points
is
play,
goal
cheat
deleting
and
withdrawing
objects
yeah,
but
we
are
not
really
sure
whether
you
really
would
want
that.
So
it's
explained
in
more
detail
here,
but
just
very
briefly
summarized.
We
think
that
the
data
model
itself
should
dictate
whether.
C
Deletes
are
what
needs
to
happen
when
an
object
is
deleted.
That
has
relations
with
other
objects
and
the
two
examples
that
we
give
is
like.
It
actually
deletes
everything
else,
so
that
you
know
if
you
have
an
issue
that
you
delete,
that
it
deletes
all
the
articles.
But
you
could
also
want
that
it
that
if
you
delete
the
issue
that
all
the
virtual
metadata
that
has
been
mapped
through
those
relations
first,
second
and
third
level,
and
so
on
to
the
article
are
automatically
copied
into
the
article
itself
as
plaintext.
Right.
C
So
let's
say
your
article
has
the
is
as
a
number:
that's
there
through
virtual
metadata
through
its
connection
with
the
journal.
If
you
delete
the
an
issue,
for
example,
and
you
destroy
the
relation
between
the
journal
and
that
article,
that,
if
that
you
might
not
want
to
delete
the
article,
you
just
want
to
keep
it
but
map
all
of
the
or
copy
all
of
the
virtual
metadata
into
the
article
and
so
I.
Don't
think
we
should
assume
much
about
how
to
handle
deletions
in
at
the
moment.
A
A
So
if
you
need
to
withdrawal
an
entire
issue
for
whatever
reason,
maybe
there's
a
copyright
issue
or
whatever
or
you
need
to
withdraw
an
entire
journal,
does
that
suddenly
mean
you're
having
to
go
in
and
manually
withdrawal
50
objects
instead
of
just
clicking
withdraw
on
the
entire
journal?
That
also
depends
on
on
what
you
want
right.
I
mean
right
now,
I
agree
I'm,
just
noting
that
that,
with
this
concept
of
relationships,
I
think
these
are
all
interrelated.
This
delete
problem,
this
withdrawal
problem
and
the
the
other
one
we
were
talking
about.
A
What
inheritance
of
the
deletion
action
inheritance
of
the
withdrawal
action,
inheritance
of
the
with
embargo
action
action
almost
like
their
parent
objects
and
the
way
that
a
community
collection,
an
item
you
know
had
that
sort
of
hierarchy,
because
when
you
get
into
this
hierarchy,
sort
of
relationship
and
mapping
that
that's
almost
an
expectation
out
of
the
concept
of
a
hierarchy,
at
least
I've
seen
that
expectation
and
that
comes
up
all
the
time
with
communities
and
collections
and
items
within
these
spaces
and
people
complain
about
I
change.
The
permissions
on
my
collection.
A
C
C
A
Yeah
I
agree
I'm,
so
that's
why
I'm
calling
it
like
an
inheritance
or
whatever
it
is
that
some
of
these
relationships
have
some
sort
of
inheritance.
That
is
almost
enabled
that
this
this
relationship
is
very
hard
link
that
it
inheritance
they
here.
It's
things
from
this
upper
parent
object,
whereas
these
other
types
of
relationships
are
more
of
a
soft
length.
They're
just
saying
this
is
related
and
those
soft
link
relationships.
Yeah,
nothing
gets
inherited
across
that
if
you
delete
withdrawal
embargo
doesn't
really
matter.
A
The
other
object
should
not
be
affected,
but
there
are
certain
types
of
relationships
that
people
are
going
to
have
that
expectation
coming
in
that
that
this
inheritance
will
occur
and
I
don't
know
how
to
solve
it
right
now.
I'm,
just
trying
to
note
that
this
is
this
seems
like
a
common
thread
that
we
may
need
to
kind
of
talk
through
more
and
figure
out
whether
we
need
this
in
D
space
7,
whether
we
can
push
it
back.
C
C
The
UI
one
might
be
good
for
the
initial
implementation
and
further
definition
into
the
data
model
might
be
useful
for
the
future,
because
the
UI
one
would
work,
I
mean
people
would
I,
think
be,
or
users
would
be
happy
with
that,
but
it
would
be
more
useful
or
more
usable
if
you
have
it
on
the
the
data
model
level,
so
that
you're
not
presented
with
that
question
every
time
like
hey.
What
do
you
want
to
do
with
the
relations,
and
it
just
happens
as
you've
defined
it
in
in
the
data
model?.
C
Page
I
always
want
to
search
I,
don't
care
if
it's
3,
5
or
200,
for
example.
So
and
that's
something
that
there's
an
implementation
suggestion
there
as
well
of
how
to
tackle
that
in
angular
the
torch
came
up
with
and
since
it
is
24
hours
for
the
basics
of
three
days
for
the
basic
implementation.
We
think
that
it's
useful
to
add
that
now,
because
I
would
make
everything
more
usable
own
user
interface
level,
yeah.
A
I
mean
I.
This
sounds
reasonable
to
me.
To
be
honest,
when
I,
when
I
was
saying
pagination
in
these
various
use
cases,
I
never
meant
that
had
that
paging
always
exists,
I,
always
kind
of
had
the
assumption,
but
I
guess
I
never
wrote
it
down
that
there
had
to
be
a
cut-off
that,
obviously
you
wouldn't
have
pagination
on
five
articles
or
two
articles,
or
something
like
that.
So
it
makes
total
sense
to
me
that
to
implement
this
sort
of
cutoff,
okay,
that
schedule
always.
C
A
To
be
honest,
I
I
think
that
sounds
good
enough
to
me.
I'm
curious
what
others
think,
but
I
honestly
think
that
sounds
good
enough,
because
that
would
allow
administrators
do
anything.
They
wanted,
of
course,
and
then
it
allow
like
authors
to
be
able
to
manage,
particularly
on
their
author
profile
and
link
articles
to
their
author
profile.
It
seems
reasonable
to
allow
that
that
be.
If
you
have
edit
rights
on
either
of
the
two
items
you
can
link
them.
But
what
do
others
think
on
this?
A
D
D
C
And
it
also
it's
related
to
the
two
author
profiles,
so
named
variants
as
well.
So
if
you
would
use
these
space
objects
to
represent
relations,
then
you
would
also
have
metadata
and
types
of
metadata
available,
which
would
also
serve
the
purpose
of
named
variants.
But
it
has
a
significant
refactoring
and
you
have
discussed
it,
but
we
would
like
to
look
into
it
and
a
little
bit
more
detailed
by
our
next
meeting
to
make
sure
that
we
fully
covered
all
the
bases
and
all
of
the
pros
and
cons
that
come
with
it.
C
So
just
to
be
clear,
but
the
author
profile
case.
So
in
the
author
profile
use
case,
you
have
two
use
cases,
one
with
having
a
name
variant
attached
to
your
relation
and
another
one
with
having
a
date
attached
to
the
link
between
a
person
and
auric
unit.
And
so
if
the
relation
would
be
a
dspace
object,
it
would
be
possible
to
say
hey
I'm,
attaching
this
piece
of
metadata
to
this
relation-
and
this
is
an
author
name
and
the
other
one
is
a
date
for
example.
C
So
it
would
have
some
benefits,
but
we're
still
looking
into
what
the
full
implication
of
that
is,
but
it
would
also
be
useful
for
permissions
as
well.
If
we
want
to
go
further,
then
saying
that
if
you
have
added
permissions
on
either
of
the
two
objects
in
a
relation
that
you
can
that
you
have
edit
rights
on
the
relation
itself,.
A
A
C
A
I
think
that's
accurate,
I
think
that's
an
ongoing
sort
of
discussion
point
as
to
whether
or
not
hierarchy
propagation
is.
It
is
a
requirement
or
if
we
can
work
around
it,
like
you
noted,
with
just
having
some
sort
of
option
that
appears
in
the
user
interface
for
those
actions
that
could
propagate
and
just
give
them
the
option
to
apply
it
to
all.
C
A
A
So
for
next
time
around,
we
will
have
some
more
reviews
done
on
the
angular
side
of
things
we
got
to
get
reviewers
and
on
the
angular
UI
and
start
it
start
to
finalize
the
reviews
of
the
rest
api.
So
if
we
can
start
to
move
that
forward,
so
we
have
tasks
on
on
the
actual
code
itself
and
then
from
my
understanding,
leaving
you'll
have
a
similar
document
like
this
on
the
author
profile
use
case
that
we
can
review.
Similarly
like
we
did
with
this
journal
hierarchy.
A
There's
the
I
think
that
I
have
right
now
feel
like
there
might
be
a
third,
obviously
we'll
we'll
add
more
to
it
as
we
go,
but
but
at
least
those
two
will
be
in
our
next
meeting
and
our
next
meeting
again
will
be
in
two
weeks,
so
that
would
be
on
Tuesday.
Oh
I
have
them
date
wrong
in
this
agenda.
Tuesday
November
20th,
not
23rd,
November
20th,
so
two
weeks
from
today
at
the
same
time,
will
be
our
next
meeting.