►
From YouTube: 2018-10-23 : DSpace 7 Entities Working Group Meeting
A
Was
for
me
somehow,
maybe
because
you
came
in
first
okay-
well
we're
recording,
anyways,
okay,
so
we'll
go
ahead
and
get
this
meeting
started
here.
Hopefully
we'll
get
a
couple
other
folks
in
the
meeting
as
we
go,
but
before
we
get
started
actually
so
the
agenda
only
really
has
two
topics,
and
admittedly
we'll
see
how
long
each
of
these
take
us
so
I'm
not
sure
phille
will
spend
a
full
hour
or
not,
but
the
two
main
topics
that
I
have
on
here
for
today.
A
Let
me
share
the
agenda
here
with
everybody:
if
you
don't
have
it,
here's
the
agenda
and
the
chat.
So
the
main
two
topics
are
to
look
over
our
D
space
entities,
definition
and
use
cases
document
again.
I'm
I
had
asked
everybody
in
the
last
meeting
two
weeks
ago
to
kind
of
add
feedback
into
that
and
help
us
enhance
these
use
cases.
I
admit
there
was
not
a
whole
lot
of
extra
comments
added
into
there.
A
So
if
there's
anything,
you
hadn't
had
a
chance
to
say
we'll
have
an
opportunity
to
kind
of
talk
through
that
as
the
first
agenda
topic.
The
second
topic,
then,
is
to
start
to
delve
towards
looking
at
the
implementation
work
and
what
we
want
to
do
in
terms
of
the
next
step
steps
on
that.
So
we
can
kind
of
get
things
prepared
as
soon
as
possible
on
the
entities
side
and
starting
to
review
things
and
starting
to
test
things
and
all
that
sort
of
stuff.
A
So
those
are
our
primary
topics
for
today
and
we
should
have
plenty
of
extra
time
near
the
end
or
throughout
the
those
two
topics
to
kind
of
discuss
where
we're
going
next
with
entities
before
we
get
started,
though
I
did
want
to
note.
This
is
a
little
bit
around
topic
number
two
and
I
noted
it
as
as
the
top
thing
there
in
terms
of
a
the
timeline
for
D
space
7
and,
what's
currently
being
discussed
with
the
steering
group.
So
I
just
want
to
make
everybody
aware
of
the
discussions
that
are
going
on.
A
Before
the
end
of
this
year,
which
means
roughly
in
the
next
two
months,
maybe
even
a
little
less
than
that
since
we're
getting
towards
the
end
of
October
and
we're,
the
steering
group
is
currently
looking
at
and
we'll
be
discussing,
what's
going
to
be
included
as
part
of
that
preview
or
alpha
release,
so
we're
definitely
not
going
to
have
all
features
that
are
part
of
D
space.
7
in
that
preview
release
it's
more
of
an
opportunity
to
get
something
in
people's
hands.
A
Let
them
play
around
with
it
give
some
early
feedback
on
how
D
space
7
is
looking
and
development
will
then
continue
into
early
2019,
with
the
goal
of
still
getting
the
final
release
out
in
early
2019,
but
we're
just
not
a
feature
full
release,
yet
that
we
can
do
that
in
2018.
So
my
assumption
right
now,
though,
is
we're
moving
forward
with
the
assumption
that
entities
is
going
to
be
a
part
of
that,
but
that
is
still
a
decision
that
will
are
part
of
that
alpha
release
at
the
end
of
the
year.
A
But
that
is
honestly
a
decision
for
the
steering
group.
So
I
will
let
you
know
if,
if
anything,
changes
in
that
direction,
but
our
goal
really
is
to
try
and
move
as
quickly
as
we
can
with
the
initial
entity
prototype
and
start
to
review
that
and
get
something
ready
so
that
people
can
play
around
with
a
very
early
version
of
what
entities
might
be
before
the
end
of
this
year.
So
it's
still
kind
of
our
overarching
goal.
A
Is
there
anything
else
that
Mick
or
or
Lieven
did
either?
You
wanted
to
note
anything
on
that
higher-level
topic
around
what
steering
is
discussing
before
we
move
into
the
actual
agenda?
Anything
I
missed
since
you're,
both
on
steering
No,
okay,
okay,
so
that
that's
kind
of
where
we're
going
here.
So
to
kick
things
off,
though,
let's
first
talk
about
the
dspace
entities,
definition
and
the
initial
use
cases
document
and
I'm
going
to
share
my
screen
here,
just
because
it
might
be
easier
to
kind
of
walk
through
this
together.
A
A
Let
me
see
if
I
can
bump
up
the
font
here,
just
a
tad
okay,
so
essentially
having
received
no
no
extra
comments.
Since
the
last
meeting
I
wanted
to
give
this
opportunity
for
everybody
to
kind
of
add
any
final
feedback
into
this
before
we
consider
this
sort
of
our
initial
working
draft
of
what
we
are
trying
to
achieve
in
dspace,
Evan
and
I'm
calling
this
sort
of
a
working
draft,
because
I
think
that
there
are
areas
here
that
we'll
still
have
to
make
decisions
on.
A
So
some
of
the
use
cases
we
just
described
here,
it's
possible.
We
may
need
to
make
some
compromises
along
the
way
as
to
what
we
can
actually
reasonably
achieve
in
dspace,
seven
versus
what
parts
of
the
use
case
we
may
have
in
a
future
release,
and
there
may
be
things
that
are
missing
here-
that
will
start
to
enhance,
as
we
move
into
more
of
the
development
phase
or
better
describe
things
in
that
development
phase,
but
I'm
kind
of
considering
this
sort
of
very
early
documentation
of
things
that
you
can
do
with
entities
4d
space
7.
A
A
A
No
problem,
so
that
said,
there
were
some
comments
here
that
that
were
added
prior
to
last
meeting,
that
I've
kind
of
enhanced
into
this
document.
I'm
sure
I'll
touch
on
that
briefly,
but
I
just
want
to
kind
of
skim
through
this
there's
also
a
couple
areas
that
I've
asked
questions
sort
of
to
myself
into
the
group
near
the
top
of
this.
That
would
be
good
to
kind
of
talk
through
very
briefly.
Today.
A
So
some
of
those
just
diving
in
here
really
quick.
These
two
questions
are
very
much
related
in
in
the
fact
that
the
main
question
here
is
really
that
I
think
that
the
term
entity
and
the
term
item
are
going
to
start
to
get
confused
more
and
more
and
what
we
mean
by
each
and
what
what
things
are
within
d
space
and
whether
every
item
is
an
entity
and
whether
we
start
to
call
everything
entities
or
whether
everything's,
really
just
an
item
and
items
now
have
types
and
relationships.
I
think
that's
a
decision.
A
The
reason
I'm
bringing
this
up
is
because
it
keeps
coming
up
in
my
own
mind
that
this
main
statement
here
that
well
these
two
two
things
all
items
have
a
single
entity
type
all
items
are
entities.
So
if
all
items
are
entities
and
all
items
have
a
single
entity
type
and
that
entity
type
is
stored
in
a
metadata
field,
called
relationship
type,
then
then,
what
is
an
item
anymore?
A
Do
we
just
call
everything
entities
or
do
we
call
everything
items,
because
really
everything
is
just
an
item
that
happens
to
have
a
relationship
type
and
that
relationship
type
can
tell
us
what
what
special
type
it
is.
So
this
is
a
question
that
I've
been
grappling
with
myself.
I,
don't
know
if
anybody
has
thoughts
on
this
or
whether
we
want
to
to
move
towards
a
decision
here.
A
C
I
would
expect
that
for
somewhat
positive,
the
entire
concept
of
building
relations
between
two
items
or
entities,
whatever
column
is
not
relevant
and
for
those
use
cases
you
don't
need
to
define
a
type
or
build
any
and
relations.
So
in
those
cases
you
can
say
it's
just
a
normal
lease
paid
site
and
nothing
changed,
I
think
so
we
could
print
and
say
an
entity.
Is
it's
an
item
with
a
type
but
keep
it
as
that?
That
is
something
that
is
not
tight
and
building
relationships
with.
A
And
I
think
that
last
point
is
exactly
what
I'm
getting
at
Ben
is
that
I'm
trying
to
determine
whether
it's
necessary
to
differentiate?
Why
we
have
two
terms
for
the
same
thing
and
if
it
all
comes
down
to
whether
or
not
it
has
a
metadata
field,
its
relationship
type
or
not?
Why
does
that?
Why
does
that
matter
too?
Much
like
like?
Are
these
all
just
items
where
all
these
are
all
just
entities
like
what?
What
is
what
is
the?
What
what
should
be
calling
these
I
don't
know
if
that
makes
sense.
A
D
A
Yes,
that's
accurate,
I,
guess
I'm
bringing
this
up,
though
cuz
it's,
it's
gonna
get
more
and
more
confusing
at
the
user
interface
level,
especially
as
we're
dealing
with
these
sort
of
objects
like
what
we're
calling
things
like
Indy
space
unit
user
interface.
We
have
things
that
are
items.
We
have
things
that
are
collections
and
communities.
Are
we
now
going
to
have
a
fourth
thing
called
an
entity
that
we're
dealing
with
there?
Is
everything
really
just
an
item
and
you
can
create.
B
Be
saying
it's
only
items
doesn't
really
matter,
I
mean.
What's
in
a
name,
it's
an
it,
doesn't
matter
what
you
call
it,
but
given
what
Ben
just
said,
you
know
you'll
still
have
use
cases
words,
just
your
typical
open
access
repository
and
nobody
wants
to
create
when
the
people
don't
want
to
create
the
person
item.
So
you
just
keep
it
at
that
and
we
keep
the
terminology
as
items,
but
we
can
talk
about
it.
As
items
are
now
able
to
represent
specific
entities
such
as
a
person,
something
about
it
right.
D
Entity
is
an
abstraction
that
you
know.
Most
people
are
not
going
to
need
to
think
about
unless
they're
creating
a
new
type
of
entity
yeah.
We
have
this.
You
know
a
thing
that
we
think
of
as
an
entity
in
the
background,
but
what
people
are
going
to
be
working
with
mostly
or
person
organizational
unit
Thunder
or
that
sort
of
thing.
A
Right,
yeah
and
I
agree
with
that
completely
I,
guess:
I'm.
The
reason
I'm
part
of
the
reason
I'm
bringing
this
up
now
is
because
it
can
also
determine
how
we
want
to
structure
things
potentially
in
the
codebase.
To
some
extent
I
mean
we
could
still
call
things
entities
down
in
the
lower
level
and
just
call
them
items
at
the
user
interface,
but
I
think
it's
just
worth
having
this
discussion
early.
A
A
D
A
I,
don't
know
that
that
helps
too
much,
because
I
think
that
I
think
my
problem
is.
We
have
these
two
words
for
the
same
thing
and
I'm
just
starting
to
wonder
once
we
get
to
the
user
interface
level
and
once
we're
dealing
with
these
objects
with
actual
users
and
users.
What
are
we
calling
them
because
I'm
worried
that,
if
we
have
two
two
words
that
two
things
that
mean
the
same
thing
and
the
whole
control,
the
only
thing
that
controls
whether
the
thing
is
an
entity
or
not,
is
a
metadata
field.
A
The
existence
of
a
metadata
field
that
seems
really
fragile
in
terms
of
having
two
different
words
like
it
seems
like
we
should
choose
one
and
go
with
it
and
I've
actually
been
thinking
in
the
way
that
leoben's
been
talking
about
that.
What?
If
we
just
start,
we
can
call
ourselves
the
entities
working
group.
A
We
can
talk
about
entities
as
a
conceptual
abstract
notion,
but
what
if
these
are
all
just
items
and
one
way
when
we
get
down
to
the
user
interface
level
when
we
start
to
talk
about
this
stuff
with
end
users,
we're
really
just
talking
about
items.
Can
now
be
typed,
you
can
now
have
by
default
their
generic,
but
now
you
can
start
to
type
things
and
and
create
specific
relationships
between
items
as
an
optional
extra
feature.
In
order
to
create
the
concept
of
entities
and
whatever
entity
you
want,
but
they're
all
just
items.
D
D
A
My
point
is
that
I
think
that
there's
some
things
that
it's
going
to
be
very
confusing,
whether
they're
an
entity
or
an
item
unless
we
start
to
figure
out
how
we're
talking
about
these
these
objects
like?
Are
we
really
just
enhancing?
The
item?
Object
model
to
deal
with
to
be
more
configurable?
Is
it
really
more
like
configurable
items
rather
than
configurable
entities?
And
it's
not
something
you
have
to
answer
today:
I'm
just
trying
to
to
plant
this
notion
and
everybody's
head
that.
D
A
Beyond
okay,
so
that's
that
was
the
my
main
point
up
here.
I'm
gonna,
think
more
on
this
as
well.
I,
admit,
I've,
started
to
think
more
in
the
line
of
what
leave
it
and
noted
that
that
maybe
we
just
start
to
talk
about
this
more
as
items,
even
though
they,
the
conceptual
model
is
the
abstract
object
is
an
entity.
They
may
not
necessarily
be
called
entities
in
the
D
space
user
interface.
A
The
some
other
questions
that
have
come
up
here
are
from
a
Paolo
who
I'm
not
sure
if
he's
been
able
to
Apollo
is
on
here
now
so
I
closed
out
a
lot
of
issue,
questions
that
were
already
that
I
managed
to
merge
in
into
this
document
already,
but
I
did
want
to
bring
up
a
couple
that
Paolo
brought
up
just
so
that
we're
keeping
them
in
mind.
So
a
lot
of
them
have
been
around
usage
of
oai-pmh
for
entities.
A
But
I
think
it
is
important
for
us
to
just
keep
that
in
mind
that
there
are
going
to
be
other
areas
that
we
want
to
be
able
to
enhance
the
way
this.
This
entity
level
metadata,
gets
surfaced
at
the
oai-pmh
level
and
elsewhere.
So
I
don't
know
if
it's
worth
really
talking
through
this,
but
just
to
kind
of
I
was
leaving
these
here
just
as
sort
of
reminders
that
that
Oei
is
a
is
a
need
here
and
at
the
use
case
level.
A
I
know
there
was
another
question
around
that
that
you
had
write
down
here
as
well,
Paolo
again
having
to
do
with
with
being
able
this
side
doing
a
know.
A
ingest
of
entities
as
well
are
doing
bulk
ingests
of
entities
which
I
think
is
a
use
case
we're
going
to
want
to
support.
I
was
trying
to
keep
the
the
user
stories
relatively
simplistic
here
in
that
and
that
there's
something
we
can
kind
of
grasp
more
initially
and
getting
entities
initially
built
out
at
the
user
interface
level.
A
A
So
these
are
things
that
I've
kind
of
started
to
add
into
here
as
issues
we're
gonna
have
to
grapple
with
as
we're
analyzing.
The
code
and
as
we're
starting
to
test
things
I,
don't
know
if
anybody
has
the
initial
comments
on
this
or
if
there's
anything
we
wanted
to
discuss
here
today,
I'm
just
trying
to
do
a
quick
scan
of
this
document.
B
That
should
be
ready
very
soon,
we'll
discuss
that
an
agenda
point
to
you.
But
what
we've
also
done
for
DC
use
cases
is
list
the
discussion
points,
so
the
points
that
the
current
prototype
doesn't
support
yet
so
that
we
can
have
a
discussion
here
in
the
group
about
which
of
the
use
cases
we
would
meet
or
want
to
be
supported
in
D
space
7
and
which
ones
can
be
tabled
for
D
space
8.
B
So
ideally,
my
thoughts
were
but,
of
course,
steering
and
leadership
have
to
decide
this,
but
I
was
hoping
that
the
prototype
itself
would
already
be
included
in
the
first
alpha
release.
That
supports
a
lot
of
use
cases,
but
not
all
of
the
use
case
sub
points,
but
it
at
least
supports
both
used
cases
to
a
significant
extent
and
that
we,
then
you
know,
have
a
discussion
in
this
working
group
about
okay,
which
are
the
next
steps
for
the
D
space
7
entities
and
which
are
next
next
steps
that
will
leave
4d
space
8.
B
A
I
think
I'd
want
to
get
into
a
gender
point
too.
I
think
the
point
of
this
document
I
agree,
I'm
glad
that
discussions
already
happening
internally
with
an
admirer
I.
Think.
The
point
of
this
initial
document
here
is
to
try
and
detail
as
much
as
we
know
about
these
use
cases
things
people
are
going
to
want
to
do,
but
then
you're
right.
The
next
phase
here
will
be
to
have
to
then
decide
what.
If
what?
If
this,
can
we
reasonably
do
within
dspace
seven?
A
Seven,
to
make
a
really
flashy
awesome
release
in
dspace,
seven
with
entities
but
but
but
note
which
things
may
not
necessarily
be
included
if
any
so
that's
kind
of
where
I'm
going
out
with
this,
but
I
just
want
to
so
I'll
speed.
This
up
here,
I
wanted
to
note
just
that
I
had
added
some
content
here
around
submission,
search
and
deletion
for
that
hierarchy.
Use
case
on
the
author
profiles
use
case
this,
oh
there's,
another
note
here
about
oai-pmh
from
palo
this
one
I,
don't
think
I
enhanced
as
much.
Let
me
see
here.
There
was.
A
A
So
that's
kind
of
where
I'm
going
with
this
document.
I
still
would
like
people
to
add
comments
into
this,
as
we
go
here
in
terms
of
things
that
you
see
that
people
are
going
to
be
expecting
out
of
these
use
cases
so
that
we
can
make
very
useful
decisions
around
what's:
Chiva
Belinda's
Bay
7
and
whether
there's
anything
that
needs
to
wait
for
a
future
release
so
that
we
can
kind
of
respond
to
that
from
the
get-go
with
this
early
release.
A
The
agenda
so
that'll
be
our
living
document.
I'll.
Keep
that
as
a
resource
as
part
of
our
meetings
and
we'll
keep
referring
back
to
that
as
needed,
definitely
feel
free
to
keep
adding
comments
there
if
your
team's
locally
start
to
discuss
these
use
cases
in
more
detail.
So
the
next
stage
here,
as
I
noted,
we
have
this
preview
reel
for
release.
A
We
want
to
start
preparing
for
so
the
big
gap
here
for
us
is:
we
need
to
start
really
digging
into
the
entity's
implementation,
this
initial
prototype
that
at
Meyer's
developed
and
start
to
not
only
test
it
and
play
around
with
it
and
give
feedback
on
it.
But
also
do
things
like
give
a
give
a
code
review
of
the
initial
work
and
start
to
analyze
how
this
will
kind
of
fit
within
dspace
the
dspace
seven
release.
A
So,
as
Leoben
noted,
this
code
is
not
in
the
main
code
base
yet,
but
we
do
have
branches
available
here
that,
where
the
code
will
set
so
the
angular
UI
portion
of
the
entity's
work
is
going
to
go
in
our
angular
UI
development
area.
Under
a
configurable
entities,
branch
whoops,
I
didn't
need
to
click
on
that
it'll
go
under
a
configurable
entities,
branch
and
the
rest.
Api
back-end
work
will
go
under
a
separate
configurable
entities.
B
So
we're
preparing
the
pull
requests
for
both
REST
API
and
the
UI.
The
REST
API
actually
was
finished
two
hours
ago.
It
would
Ben's
gonna
do
a
review
of
that
tomorrow
and
then
we
can
fire
that
pull
request.
That's
gonna
be
definitely
tomorrow
or
absolute
latest
Thursday
and
the
UI
should
also
be
there
hangar.
Aside
to
by
the
end
of
the
week
there
we
add
a
little
bit
more
work
to
do
on
writing
some
documentation,
but
it
will
have
unit
tests
we'll
have
integration
tests,
it's
a
pull
request
as
complete
as
any
other
dspace.
B
A
B
A
So
so
I'm
going
to
admit
here
so
we
we
talked
about
this
a
little
bit
last
week
or
not
last
week.
Let's
maintain
it
and
I
know
mark
you
use
it.
You
volunteered
to
kind
of
help
out
with
this
apollo's
name
and
Alexander
as
well,
to
start
to
try
and
help
out
with
reviews
here
with
playing
around
with
the
code,
with
giving
some
early
feedback
on
the
work
that's
going
on
here
and
even
providing
bug,
fixes
or
patches.
A
Who's
willing
to
kind
of
chip
in
here
is
there.
Anything
I
can
do
to
help
give
this
structure.
Do
we
need
to
have
a
sub
team
here?
Do
we
need
to
have
wikispaces
that
we
can
work
on
here
or
or
wiki
pages,
underneath
our
current
entities
working
group
area
I
mean?
Is
there
any
suggestions
that
you
would
have
and
how
you'd
like
to
move
this
effort
forward?
This
could
come
from
anybody.
Not
just
the
three
folks
listed
here.
A
Yeah
yeah
I
think
that's
that's
an
excellent
point.
I
think
I'd
like
to
hear
from
you
all
as
to
what
would
be
the
most
useful
but
the
ways
I
can
see
doing
this
is
we
could
there's
a
couple
ways
I
could
go.
We
could
do
some
initial
reviewing
in
the
initial
pull
request
themselves:
I'm,
not
sure
how
large
these
pull
requests
are
going
to
be,
but
you
could
start
by
adding
comments
under
there
at
an
inline
code
comments.
That's
one
way
to
just
kind
of
kick
things
off.
A
We
could
create
a
wiki
space
to
start
to
discuss
some
of
this
or
not
a
wiki
space
that
wiki
sort
of
structure
to
discuss
the
pull
requests.
Any
questions
just
a
place
to
log
things.
Log
questions
all
concerns
things
of
that
nature
or
we
could
move
some
of
those
to
JIRA
or
things
of
that
needs,
but
but
I'm
kind
of
I'm
not
sure
if
the
tickets
is
the
right
direction.
D
B
So
I
was
actually
hoping
to
split
this.
The
review
work
up
in
a
little
bit
more
like
bite-sized
pieces,
okay,
that
the
first
review
would
be
just
making
sure
that
you
know
everything
compiles
all
the
tests
are
successful.
Integration
tests
or
code
style
is
okay,
because
the
rest
is
often
topic
for
broader
discussion.
Since
this
is
like
a
very
new
concept,
it's
not
so
clear-cut.
What
is
a
bug?
B
You
know?
What
is
something
that's
missing?
Is
it
really
missing,
or
is
it
something
that
we
just
want
to
add
at
a
later
time?
So
it
would
be
good.
So
if
people
could
first
pitch
in
to
just
go
through
the
code
and
just
try
to
see
if
it's
written
properly,
if
it's
understandable,
if
you
know
everything
compiles
everything
works
and
you
can
use
the
document
that
I
just
pasted
it
in
the
chat
that
actually
explains
the
implementation.
That
has
something
to
tail
and
links
to
implementation
and
what
it
does.
B
So
you
can
get
a
quicker
overview
and
if
certain
people
would
be
able
to
volunteer
for
let's
say
the
rest,
api
part,
the
angular
part
or
the
configuration
of
the
data
base.
Part
that
would
be
great,
and
then
we
could
move
this
along
quickly
and
then
go
back
into
discussing
like
okay.
What
do
we
really
define
as
being
in
scope
for
4d
space
zone.
A
So
it
sounds
like
from
from
that.
It
sounds
like
to
me
that
the
initial
pull
requests,
the
goal
that
you're
proposing
is
that
the
initial
pull
requests
just
get
a
relatively
quick
review
to
make
sure
it
looks
good
enough
to
at
least
get
them
into
these
branches
into
the
configure
bunch
of
these
branches
and
then
kind
of
merge
those
quickly.
A
B
My
suggestion
would
be
in
the
documents
and
that
in
the
the
Google
Doc
and
that
we
then
supplement
that
with
discussions
in
the
meetings.
So
let
me
just
give
a
very
quick
example
of
one
of
these
things
like,
for
example,
name
variance
is
something
that's
included
in
one
of
the
use
cases
we
have
written
down
what
we
would
see
as
an
addition
to
the
current
implementation
in
order
to
support
named
variants,
but
we've
made
some
choices
in
that
proposal.
B
So
and
then
what
we
need
to
do
is
first
of
all,
decide
is
name
variants,
something
that
we
absolutely
need
to
be
supported
in
the
D
space,
7
implementation
and
yes
or
no.
How
would
we
approach
it
and
both
of
those
are
related
to
each
other?
If
we
say
no,
the
support
really
needs
to
be
implemented
in
a
very
you
know,
fundamental
way,
that's
a
lot
of
work.
Then
we
might
want
to
table
it
for
d68.
If
we
say
I
know.
Ok,
this
is
a
something
that
can
be
done
quickly
and
cleanly.
B
A
Yeah
that
that
seems
reasonable
to
me
we
can
add.
We
can
add
comments
into
that
use
case
document
on
specific
use
cases
and
note
that
this
use
case
is
not
currently
implemented
in
the
prototype
and,
as
those
comments
can
either
come
from
admire
or
come
from
testers,
they
can,
they
can
add
their
their
their
notes
into
the
use
cases.
Documents
say
this
does
not
seem
to
be
implemented
or
or
things
of
that
nature,
so
that
we
can
then
touch
on
those
into
in
each
of
these
meetings.
B
Then
we
can
totally
prepare
that
before
the
next
meeting,
which
shouldn't
I
mean
should
be
also
doable
by
the
end
of
the
week,
but
we
were
hoping
that
people
would
be
volunteering
to
at
least
to
review
the
code
in
terms
of
you
know,
does
it
work
you
know,
do
the
tests
work?
Is
the
test
coverage
complete
and,
and
is
the
code
style
okay
so
that
at
least
we
can?
You
know,
have
that
part
of
the
prototype
code
that
we
worked
hard
on
already
in
the
next
stage
and
then
focus
our
discussions
on
these
open
talks.
A
Yeah
that
makes
sense
and
I
think
some
of
those
things
you
mentioned
are
gonna
get
checked
automatically
as
soon
as
you
create
a
pull
request.
Like
code
style
code
coverage,
those
things
are
automatic,
go
automate
it
now,
so
we'll
get
that
feedback
from
github
as
soon
as
the
pull
request
is
created.
But,
yes,
I,
agree.
I
think
that
we
need
to
I'm,
assuming
my
assumption.
I
should
correct
this
assumption.
Is
that
mark
Paulo
and
Alexander
as
soon
as
these
pull
requests
are
created?
A
I
can
point
the
three
of
you
at
them
to
start
to
do
some
very
quick
initial
code
review
just
to
kind
of
make
sure
the
code
looks
reasonable
enough
to
merge
into
this
branch
and
keep
in
mind
that
this
is
not
the
main
primary
master
branch.
It's
more
just
a
work-in-progress
branch,
so
the
code
can
still
be
a
little
bit
work
in
progress,
but
we
want
at
least
have
it
up
to
the
standards
for
Java
code
and
also
sort
of
the
angular
interface
code.
Is
that
accurate
that.
D
A
We
don't
have
to
do
a
whole
lot
of
checks
on
those
sort
of
updating
to
master,
but
we
will
need
to
do
that
on
a
regular
basis
and
I
can
notify
folks
when
major
things
have
gone
in
a
master
where
we'd
want
to
resync,
but
but
but
yeah.
That's
just
something:
gonna
have
to
deal
with
I.
Think
I
can't
think
of
a
better
way
to
do
it.
Okay,
so.
A
I
yeah
I
can
call
for
a
volunteer
if
you
notice,
something
is,
is
vastly
out
with
master.
You
just
have
extra
time
at
the
end
of
a
Friday
Mike
or
something
you're.
More
than
welcome
to
create
a
pull
request.
Just
to
sync
it
back
up
to
master
and
I
will
just
I
can
do
a
quick
thumbs
up
on
it
and
help
get
it
merge
right
away,
but
but
yeah
otherwise,
I
will
keep
an
eye
on
things
and
and
let
you
know
as
soon
as
we
need
to
definitely
resync
and
call
for
volunteers,
for
that.
A
D
A
Okay,
how
about
this?
How
about
I
can
be
in
charge
for
resyncing
this
at
regular
intervals,
and
you
three
concentrate
on
code
reviews
and
getting
the
code
reviewed
and
tested
I'll
do
the
resync
myself
if,
for
some
reason,
I
can't
do
it
one
week,
I'll
ask
one
of
you
to
do
it
for
me,
but
it'll
probably
be
on
a
relative
about
a
weekly
basis.
Okay,.
D
A
Understood
I'm,
just
noting
that's
I
mean
I,
want
your
effort
more
on
the
review
process
than
on
anything
else
like
I
need
more
folks
to
contribute
on
code
reviews.
Frankly,
and
so
I'd
really
appreciate
concentrating
efforts
on
code
reviews
making
sure
things
are
working
well
doing,
testing
because
I
think
that
would
get
it
would
help
also
dspace
seven
to
get
the
three
of
you
more
involved
in
in
doing
that
4d
space,
seven
in
general.
So
let.
D
A
Yeah
go
ahead,
marker
no
yeah,
and
so
when
it
comes
to
actually
resyncing
things,
I,
actually
don't
think
this
is
going
to
be
I
mean
there
are
things
coming
into
the
D
space
seven
code
base
on
a
regular
basis,
but
I
don't
think
this
is
going
to
be
such
a
massive
effort
that
things
coming
in
are
gonna
like
that.
It's
going
to
be
about
a
weekly
effort,
maybe
once
a
week
for
about
an
hour,
resync
everything,
real,
quick,
I,
don't
see
it
happening
much
more
frequently
than
that,
just
based
on
the
current
pace
of
development.
B
A
Exactly
okay,
so
so
we
have
a
direction
here,
for
the
the
pull
request
will
be
coming.
You
through
will
be
in
charge
of
doing
some
code
reviews
there
I'll
keep
an
eye
on
the
syncing
with
master.
We
will
add
feedback
and
questions
into
the
use
cases
document
as
comments.
If
there's
things
that
don't
seem
to
be
implemented
yet
or
if
there's
areas
of
question
or
confusion
with
the
code
versus
the
use
cases,
those
go
in
the
use
cases
document
trying
to
think
there's
anything
else.
We
want
to
touch
on
in
this
topic.
A
B
A
So
we
can
go
into
that
discussion.
We
have
only
have
about
ten
minutes
left
here
before
we
dive
into
that
discussion.
I
just
we
already
have
our
next
meeting
scheduled.
The
one
thing
I
just
want
to
add.
Really.
Quick,
though,
is
that
I
noticed
that
we
are
starting
to
get
to
the
time
of
year
where
daylight
savings
ends
at
different
times
in
different
countries.
D
A
B
A
Starts
as
of
early
November,
so
I
mean.
If
we
wanted
to
move
it,
we
can
move
it
to
16
UTC,
as
of
November
4th
or
as
of
November
6
re
16
UTC,
which
would
keep
it
for
me
us
in
the
states
and
we
keep
it
the
exact
same
time.
I
don't
know
if
it
were
moved
to
an
hour
later
for
you
all
in
Europe
briefly
and
then
move
back
now.
We've.
A
B
A
A
B
I'm,
just
gonna
go
over
the
points
that
need
to
discussion.
I
won't
go
into
any
detail.
Other
things
that
are
not
supporting
the
current
prototype
are
one
name
variance
to
which
is
touched
upon
a
little
bit
in
the
use
cases,
but
I
think
it's
definitely
worth
a
discussion
is
permissions
on
relations.
B
Three
is
how
display
should
how
relations
excuse
me
should
be
displayed.
So
in
your
use
case,
I
forgot
what
the
example
is
exactly,
but
you
said
a
page
valid
sortable
list
with
the
search
box,
and
so
we've
been
thinking
about
this
and
we
actually
have
a
proposal
of
doing
this
more
based
on
the
amount
of
relationships
there
are
between
an
entity
and
other
entities.
So
let's
say,
for
example,
your
own
authored
profile
page
and
there
only
five
articles,
it
doesn't
make
sense
to
have
a
page.
B
Full
browsable
is
to
be
shown
with
the
search
box
and
that
we
just
have
a
simpler
display.
You
have
this
proposal
that
works
a
little
bit
like
you
know.
You
have
just
if
you
know
xml
UI,
like
item
some
review
list.
Few
things
like
that,
then
you
have
different
templates
that
are
used
in
different
situations,
depending
on
how
you
configure
it
now
would
require
a
day
or
three
to
five
of
development.
B
B
Currently,
our
reasoning
is
that
at
least
anything
that
is
virtual
metadata
should
be
copied
over.
So
let's
say
you
have
an
author
profile
on
an
article
and
for
some
reason
you
want
to
delete
the
author
profile
and
in
the
article
item
the
author's
name
is
added
in
as
virtual
metadata
through
that
relation
that
at
least
that
value
gets
copied
in
as
regular
metadata
in
the
article.
B
There
are
cases,
especially
with
here
our
old
data
models,
where
you
might
want
to
delete
connected
entities
like
if
you
want
to
delete
the
journal,
that
you
have
the
option
to
delete
all
the
underlying
volumes
issues
and
articles
related
to
that
journal.
But
we
currently
think
that
that's
not
necessary
for
D
space
7.
B
These
selected
or
highlighted
works
listing
use
case
that
can
be
done
in
several
ways,
but
we
would
say:
I
mean
it
is
possible
in
in
having
a
separate
list
of
highlighted,
works
or
even
in
having
them
on
top
of
the,
for
example,
the
search
view.
If
you
have
a
hundred
articles,
you
want
to
put
like
five
on
top,
regardless
of
how
you're,
sorting
or
searching
or
whatever.
So
we
think
that
that's
not
such
a
hugely
important
use
case.
B
It
can
be
done
through
some
simple
customization
or
by
just
making
the
relation
is
highlighted,
work
and
just
having
a
double
relation
between
author
and
an
article,
so
I
think
that's
not
an
essential
use
case,
and
then
the
biggest
next
step
discussion
is,
of
course,
the
submission,
because
you
know
when
we
started
working
on
the
prototype.
There
was
nothing
of
the
submission
in
the
master
branch.
Yet
it's
now
slowly
but
steadily
coming
into
the
master
branch,
and
there
are
some
questions
about
how
to
intermix
different
values.
B
So
if
you
have,
for
example,
for
an
author,
you
can
have
clean
text
values.
So,
let's
say
ten
UI
Micheli
our
author
of
an
article.
You
know
I
might
be
represented
as
an
author
item
I'm,
not
a
user
identity,
but
author
item
in
the
repository,
so
that's
represented
as
a
relationship
Tim,
you
might
be
part
of
the
institution
that
runs
the
institutional
repository
and
you're
in
the
authority
control
with
your
internal
staff,
ID
and
Micheli,
or
external
and
you're
just
there
as
a
plaintext
value.
B
How
do
we
mix
all
these
three
in
now,
from
a
user
perspective?
Do
you
want
to
provide
input
of
that
metadata?
How
do
we
do
that?
And
how
do
you
make
it
as
usable
as
possible
for
people
who
are
not
necessarily
aware
of
the
fact
that
there
might
be
an
entity
for
my
name
authority,
control,
entry
for
Tim's
name,
for
example,
so
I
think
the
submission,
like
the
the
previous
topics
that
I
touched
on.
We
have
a
proposal
written
down
here
drafted
that
I
can
share
later
this
week.
B
That
I
think
can
be
discussed
quickly
and
a
quick
decision.
Submission
is
a
bigger
thing
where
we
have
to
decide
on.
You
know
some
additions
to
how
things
are
stored,
as
well
as
how
they
are
retrieved
as
how
they're
put
into
the
system-
and
then
permissions
is
also
very
open,
topic
I.
Think
I
don't
want
to
go
over
time.
B
So
two
minutes
permissions
is
a
very
open
topic
where
we
could
go
through
that
very
quickly
and
say:
look
you
know
right
now
in
dspace,
seven,
if
you
have
permissions
added
permissions
on
I
are
on
one
of
the
two
items
that
you're
gonna
relate
to
each
other.
You
can
make
the
relation
theory,
but
in
the
future
we
might
want
to
go
more
granular
and
that
would
need
some
reimplementation.
B
We
have
an
idea
of
how
we
would
do
that
if
we
find
use
cases
where
it's
very
important
that
there
are
permissions
on
creating
those
relations
today,
then
we
can
discuss
that
as
well.
So
those
are
that's
the
more
open
topic,
so
I
think
those
are
the
most
important
ones
that
requires
some
discussion
from
the
group.
Ok,.
A
Yeah
I
would
I
would
like
to
definitely
see
the
document
you've
written
up
based
on
the
number
of
things
you
brought
up
there
I
think
we'll
probably
need
to
prioritize,
which
ones
we
see
as
higher
priority
for
like
D
space
7
and
which
ones
could
wait
till
later.
So,
if
there's
features
that
that
are
not
implemented,
that
we
think
are
are
really
kind
of
almost
required
or
whatever
you
want
a
higher
priority.
We
should
concentrate
on
those
discussions
first
and
potentially
table
others.
If
we
think
that
it's
not
as
high
a
priority.
B
And
then
there
is
one
other
things
like
what
we
do
with
kind
of
showcase
implementation,
because
currently
the
prototype
includes
both
those
data
models,
so
you
could
like
run
script
and
have
either
of
those
two
data
models
of
those
two
use
cases
be
built.
Do
we
want
to
add
something
like
that
in
the
Alpha
and
which
of
the
use
cases?
Are
we
going
to.
B
A
B
Talk
towards
that
yeah,
that's
basically
a
copy/paste
of
your
document
and
then
you
know
links
added
to
the
things
that
are
already
implemented
and
supported
in
the
current
code
and
then
some
details
about
things
that
are
not
supported.
So
that
should
be
not
too
difficult
to
share,
but
I'm
hoping
to
have
the
focus
be
on
review
first.
So
one
would
you
like
to
have
the
opportunity
to
look
into
this
document?
B
A
The
document
you're
talking
about
for
the
use
case,
questions
yeah
I,
think
it
would
be
good
to
actually
get
that
out.
As
soon
as
you
can
honest,
the
review,
I
agree
is,
is
higher
importance,
but
I
think
it's
important
to
get
this
document
in
front
of
a
everybody
as
well,
so
I
think
if
they
came
out
at
the
same
time
this
week,
that
would
be
ideal
waiting
until
next
week.
A
A
Essentially,
okay
and
we're
a
couple
minutes
over
time
here
so
I,
don't
think,
there's
any
other
notes
to
bring
up
here
and
it
sounds
like
our
next
meeting
will
be
touching
on
how
the
implementation
is
going
in
terms
of
the
review
process
and
any
questions
that
come
out
of
that,
as
well
as
the
document
leaving
just
referred
to
in
terms
of
analyzing.
What's
currently
in
the
prototype
and
what
features
or
use
cases
we
want
to
prioritize
getting
completed
in
times
four
time
4d
space,
7
versus
others.